Zero-to-One Without the Six-Month Discovery Theater

There is a particular ritual the large consultancies sell at the start of every new product: the discovery phase. Three to six months of workshops, personas, journey maps, and a deck thick enough to stop a door, ending in a recommendation to start building the thing you already knew you needed. It is theater, and you are paying for the tickets.

What discovery theater actually optimizes for

Discovery theater is not designed to reduce your risk. It is designed to reduce the vendor's risk and maximize the vendor's billing. A long discovery phase de-risks the contract by getting you to sign off on a giant scope document, so that everything after it is a billable change request. It produces artifacts that look like progress — beautiful journey maps, a prioritization matrix, a roadmap with confident quarters on it — none of which have survived contact with a single line of running code or a single real user.

The tell is that nothing in a discovery phase is falsifiable. A persona cannot be wrong in any way that costs the vendor money. A working prototype can be wrong in front of a user on a Tuesday, which is precisely why the theater avoids producing one.

The only questions worth answering early

Real de-risking on a zero-to-one product means answering the small number of questions that can actually kill it. Most of them are not answerable by a workshop. They are answerable by building the riskiest slice first and watching what happens. For most new products, the genuine unknowns are a short list:

Everything else — the full persona set, the five-year roadmap, the exhaustive edge-case catalog — is work you can do later, cheaper, once you have a real thing in front of real people. Doing it first is just sequencing the cheap, reversible work ahead of the expensive, irreversible learning.

• Does the core technical assumption hold? Can we actually get this data, hit this latency, integrate with that ancient system?
• Will a real user do the one action the whole business depends on?
• Is there a wedge — a single workflow we can own completely — rather than a broad shallow product nobody adopts?
• What is the irreversible decision (the schema, the core domain model) and have we thought about it for more than an afternoon?

Build the spike, not the deck

The replacement for discovery theater is a focused build sprint, usually one to three weeks, aimed squarely at the riskiest assumption. Not a clickable Figma prototype — a thin vertical slice of the real product, with a real backend doing the one hard thing, in front of someone who would actually use it.

This is now cheap enough to be the default. With AI-native scaffolding, the boilerplate that used to consume the first month — auth, data layer, a deployable skeleton — is a couple of days, which means the team spends its real time on the part that is actually uncertain. You learn more from one working spike that a user touches than from a hundred pages of speculative requirements, because the spike can prove you wrong, and being proven wrong in week two is the entire point.

Discovery becomes continuous, not a phase

The objection is reasonable: don't you still need to understand the user, the domain, the constraints? Yes. The argument is not against discovery, it is against discovery as a gated phase that must complete before any code exists.

In a healthy zero-to-one build, discovery is continuous and interleaved with delivery. You learn about the domain by modeling it in code and watching where the model strains. You learn about the user by putting the spike in front of them every week and watching where they get confused. The understanding compounds because it is grounded in artifacts that can be wrong, instead of accumulating in a document that never has to face reality.

Where a short runway still demands caution

Compressing discovery does not mean being reckless about the things you cannot undo. The two areas that still deserve slow, deliberate thought up front are the domain model and any regulatory or data-residency constraint that would force a rebuild if you got it wrong. These are cheap to think about and brutally expensive to reverse, so they earn real whiteboard time even in a two-week sprint.

The skill is telling the irreversible decisions apart from the reversible ones. Most product decisions are reversible — the button color, the onboarding copy, even most of the UI flow. A small number are not. Spend your early caution budget entirely on the few that are not, and refuse to spend a single week of it on the many that are.