Product Discovery in Two Days Instead of Two Weeks

Two weeks used to be the minimum honest estimate for a product discovery sprint. Not because the research takes that long. Because structuring the thinking takes that long. You need a competitive analysis that finds the real gap, not just a list of features. You need an assumption map that surfaces what you're most wrong about, not just what you believe. You need an experiment design that would actually kill your riskiest assumption if the result came back bad.

That structure is what eats the time. And it's exactly what Claude is good at.

With the right prompts, I can run a full discovery sprint in an afternoon. Competitive analysis, assumption mapping, experiment design. Three hours of focused work, not two weeks of calendar negotiation.

But there's a catch that nobody talks about honestly.

The Output Is Only as Rigorous as Your Ability to Judge It

Claude will always find a market gap if you ask it to find one. It will always produce an assumption map. It will write you a crisp XYZ hypothesis with kill criteria and everything. The structure will look right. The logic will be plausible.

What it can't do is know whether the gap it found is real, whether the assumptions it surfaced are the dangerous ones, or whether the experiment it designed would actually produce a decision. That judgment is yours. And if you don't have it, the two-day sprint produces a document that looks like discovery but isn't.

This is the distinction that matters: AI compresses the scaffolding. It doesn't replace the judgment that makes the scaffolding worth building.

Which means the people who benefit most from this aren't people who've never done discovery. They're people who've done it the slow way enough times to recognize when the output is shallow. They use Claude to go faster because they already know what fast-and-wrong looks like.

What Rigorous Discovery Actually Requires

Teresa Torres's opportunity solution tree is the clearest framework I know for thinking about this. Before you design a solution, you need to understand the opportunity: what user need or pain exists, why it matters, and what you're betting on about the world.

That bet has eight dimensions of risk. Desirability: do people actually want this? Viability: can the business support it? Feasibility: can you build it? Usability: can users actually use it? And four more that most teams never name explicitly: ethical, safety, legal, data privacy.

Most discovery processes cover the first three. The rest get assumed away.

Claude is genuinely useful for the assumption mapping step because it externalizes what you're taking for granted. When you describe your product idea and ask it to map your assumptions by risk category, it will surface things you didn't know you believed. The unstated assumptions are usually the most dangerous ones.

But it can only surface what you gave it. What you didn't think to mention, it can't flag. That's why the output requires a second pass where you ask: "What am I assuming that I didn't even think to tell you?"

Where Claude Lies (and How to Catch It)

Competitive analysis is the most dangerous prompt in the discovery sprint. Ask Claude to find the market gap and it will find one, every time. Because that's what you asked for. It's pattern-matching on your framing, not independently discovering that an opportunity exists.

The antidote is the follow-up: "Steelman the case that this gap doesn't actually exist." Ask it to argue against its own finding. Make it explain why a well-funded competitor might have deliberately left that segment unserved rather than overlooked it. The quality of its pushback tells you how solid the original finding was.

Experiment design is the other place to be careful. Claude will produce clean hypotheses. "We believe X will result in Y for Z users. We'll know we're right when [metric]." Looks great. The problem is the kill criterion: most first-draft kill criteria are too vague to actually produce a decision. "Users don't engage" is not a kill criterion. "Fewer than 15% of users who see the onboarding email click through within 48 hours" is one.

If you can't commit to stopping if the result comes back bad, you don't have an experiment. You have a hope with a timeline.

The Three-Prompt Workflow

The discovery sprint I run now has three stages in sequence. Each one builds on the output of the previous one.

Start with competitive analysis: map who's in the space, what they're ignoring, and where the underserved segment lives. The key instruction: label everything inferred rather than cited. You want to know the confidence level before you treat it as fact.

Then assumption mapping using the eight risk categories. Give Claude your product concept and ask it to surface every assumption you're making. Then manually add the ones it missed. The ones you forgot to mention are the ones most worth testing.

Then experiment design: take your highest-priority assumption (high risk, low confidence) and design the smallest test that would give you a real answer. Write the kill criterion before you write the success criterion. If you can't name what would make you stop, you haven't finished the design.

The full prompts and example outputs are in the discovery sprint workflow. Start there.

When Two Days Is Actually Enough

Two days is enough when the sprint produces a decision, not a document. The question at the end isn't "do we have good discovery artifacts?" It's "do we know what we're testing and what would make us change direction?"

If you can answer that with specifics, the sprint worked. If you have a competitive analysis and an assumption map but no clear experiment and no kill criteria, you have research theater, not discovery. It looks like the two-week version. It produces the same non-answer.

The compression AI enables is real. Use it. But the judgment that makes it valuable has to come from you. That part doesn't get faster until you've done it wrong enough times to recognize what right looks like.