How I Pressure-Test a Product Idea Before Building Anything

The question I keep getting this year goes something like this: “AI can build my prototype in a weekend. Do I really still need to do all that validation stuff first?”

It’s a fair question. And I have an unfair advantage in answering it, because I already ran the control group: on myself.

This is the first post in a series I’m calling Running Lean: AI Edition. Same principles, new tactics, re-tested one at a time on a live product. Whatever comes out of it, I’ll share the learning here.

I already ran this experiment (the slow way)

At WiredReach, I fell in love with an idea for a collaboration platform. Rather than test it, I stuck my head in the sand and spent the next 6-9 months building it. No customer conversations. No experiments. Just me, my conviction, and a lot of code.

The market’s reaction did not match 9 months of conviction. That’s when it registered that the risk was never in whether I could build the product. It was in whether anyone wanted it, a question no amount of building answers.

Steve Blank’s Four Steps to the Epiphany gave me the corrective: get out of the building. His Customer Problem Presentation shaped my first real interview practice: rank the problems you believe customers have, then put them in front of actual customers and watch what happens. Where I diverged was the “presentation” part. I found that the moment slides came out, customers reacted to my deck instead of describing their world. So I kept Steve’s problem-ranking structure and dropped the pitch. Just a conversation, their words, my notes.

I put that practice to work on my next product, CloudFire. It took me 6 weeks to interview 30 moms about how they shared photos and videos of their kids. Six weeks felt agonizingly slow to the builder in me. It was also, pound for pound, the highest-yield 6 weeks I’d spent on any product to that point. I wrote it up in October 2009 as “How I built my Minimum Viable Product.” Eric Ries would soon give this kind of output a name: validated learning. By 2011 I had compressed the practice into a rule I published in “The 10x Product Launch”:

“Plan on talking to 100 prospects to find the right 10 early adopters.”

So that’s the old doctrine. The question in front of me now: how much of it survives AI?

What AI actually changed (and what it didn’t)

Here’s the thing: building really has gotten dramatically cheaper. Which means the temptation to skip straight to building has gotten dramatically stronger. And that’s precisely backwards.

AI collapsed the cost of building. It did nothing to collapse the cost of building the wrong thing.

The wrong thing still costs you what it cost me at WiredReach: months of your life, your savings, your team’s belief. You can now build ten wrong products in the time it used to take to build one. That is not progress. That’s faster waste.

But the doctrine doesn’t survive untouched either, and pretending otherwise would be its own kind of head-in-the-sand. The honest answer is that AI moves the bottleneck. In 2009, both halves of validation were slow: getting the conversations AND making sense of them (me, a notepad, and evenings spent tagging patterns across 30 interviews by hand). Today the sense-making half is exactly the kind of work AI should take off your plate: finding patterns across a pile of interview transcripts in minutes instead of evenings. The sitting-across-from-a-customer half survives untouched. That part was never about labor. It’s where the surprises live.

Interrogate the model before you build the product

So here’s how I pressure-test a new product idea today. You need paper and a pen. That’s it.

Step 1: Sketch the business model, not the product. One page, 20 minutes. I use Lean Canvas (I’m biased, I made it), but use whatever format works for you. The point is speed: your idea externalized where you can attack it, before you’ve invested enough to get defensive.

Step 2: Cross-examine it on four questions. For every answer, ask “what’s my evidence?”

• Clarity. Can you state the problem and customer in one sentence that a stranger nods at? If you can’t say it simply, no interview will rescue it.
• Desirability. Why would customers switch from whatever they do today? “They’ll love it” is not evidence. Existing workarounds are.
• Viability. Do the numbers work? Price, customer count, what it costs to reach them. Napkin math beats no math.
• Feasibility. Can you actually deliver the result that makes switching worth it? Note this comes last. It’s the question we builders answer first, and it’s almost never where products die.

Wherever your evidence is thinnest, that’s your riskiest assumption. That’s what you test first, not what you build first.

Step 3: Buy evidence with conversations. This is where Steve’s practice still earns its keep: interviews about their problems, not your solution. My 2011 exchange rate (100 prospects to find 10 true early adopters) is one of the numbers I’m currently re-testing. My hunch is AI shortens the analysis, not the denominator. I’ll report back.

The live experiment

I’m not teaching this from a podium; I’m running it. I am building LEANSpark, an AI-native validation platform that implements exactly this loop: canvas, evidence-scored assessments across those four questions, and interview analysis. I’m dogfooding it on LEANSpark’s own business model, including running my content marketing as a recorded experiment. This post is itself one of those experiments (whatever the numbers say, I’ll share them here).

The uncomfortable part of scoring your own canvas is that an assessment demanding evidence doesn’t care how attached you are to your answers. Neither did the 30 moms. That’s the feature.

Counterintuitive?

I know what some of you are thinking: if building is nearly free, why not just ship it and see?

Because a launch to silence is the most ambiguous signal in this business. Wrong product? Wrong channel? Wrong headline? You can’t tell. I couldn’t at WiredReach. A customer conversation, by contrast, tells you why. When you pitch problems instead of solutions, the customer does the pitching: their problems, in their words, with the workarounds they’ve already paid for. That’s evidence you can build on.

Customers care about their problems and not your solution.

That was true when I learned it the expensive way, and every AI-era experiment I’ve run so far has only sharpened it. Next post, I’ll share what the interview-analysis experiments on our own model are turning up, including which of my 2011 rules break first.

-Ash

P.S. If you want to pressure-test one of your own ideas, sketch the canvas and run the four questions on paper this week. Or run it through LEANSpark and tell me where the assessment gets it wrong. Fifteen minutes of your feedback shapes what I build next. THANKS!