Product Discovery for Stage-0 Operators: What’s Worth Building

Product discovery, translated out of product-management language

For a Stage-0 operator, product discovery means deciding what is actually worth building, for whom, before you spend real money and months on version one. That is it. Not a workshop. Not a template. Not a tool.

It is also not requirements gathering in disguise. Requirements gathering assumes the problem is already known and the job is to document it. Discovery exists because the problem may be real, but the shape of the solution is still uncertain.

The common advice you will find online is not wrong; it is just written for someone else. Most of it assumes a product manager, a research function, design support, a backlog, live users, and a delivery team waiting for work. At Stage 0, you are all of those roles at once. You have conviction, context, maybe even a working AI-built demo, but you do not have the machinery that makes corporate discovery feel tidy.

Why the standard advice does not fit a Stage-0 operator

The usual product discovery process is some version of: understand users, define the problem, ideate, prototype, test. That sequence is useful. It is also incomplete for a founder or domain expert deciding whether to commit the first serious build.

Why it fails in practice:

• It assumes you can recruit easily and repeatedly.
• It assumes there is existing usage data to inspect.
• It assumes the build team is separate from the discovery team.
• It ends at “validated prototype,” as if that were the real decision.

For a Stage-0 operator, the real decision is more severe: what gets into the first release, what gets cut, and how the first release is instrumented so usage answers the next question.

That is the gap this article fills. Talking to users is not discovery. Grading the evidence is discovery.

The evidence ladder: what actually predicts that something will be used

Use this ladder to place any signal you collect. The higher the rung, the more predictive it is that the thing you build will matter.

The evidence ladder, weakest to strongest

• Opinion — “I like this idea.”
• Stated intention — “I would use this.”
• Observed behaviour — they do something today that reveals the need.
• Existing workaround — they already cobble together a process.
• Time or money spent on the workaround — the workaround costs them real resources.
• Willingness to trial — they will try the thing in a real workflow.
• Willingness to pay — they exchange money or budget authority.
• Repeated use — they come back because the thing fits the job.

The rule is simple: never let a build decision rest on anything lower than a workaround. “People said they liked it” is not evidence. “People are already using three spreadsheets and a Slack channel to do this manually” is evidence.

Here is the same idea at three different rungs:

• Opinion: “This would be helpful for our team.”
• Workaround: “We have a weekly spreadsheet ritual because the system cannot do this.”
• Paid use: “We currently pay two coordinators 10 hours a week to maintain this process.”

The first is flattering. The second is interesting. The third is build-worthy.

Six weeks, not six months: a Stage-0 discovery procedure

This is a practical continuous discovery loop compressed for a founder or operator with a real deadline. The point is not to “finish discovery.” The point is to reduce uncertainty enough to scope a first version that can prove or disprove the core bet.

Weeks 1–2: find the workaround

Talk to people who actually live the problem. Prioritize users who already pay for a workaround, lose time to the problem, or are responsible when it fails.

Ask questions that surface past behavior, not future politeness:

• “Walk me through what happened yesterday.”
• “Show me the spreadsheet, doc, or system you used.”
• “What did you do the last time this went wrong?”
• “How often does this happen?”
• “Who feels the pain when it fails?”
• “What does it cost you in time, money, or error?”

Stop asking questions that produce compliments instead of evidence:

• “Would you use this?”
• “Do you like the idea?”
• “If I built it, would you buy it?”

Those questions are not evil. They are just weak. They tell you what people want to sound like, not what they do.

Weeks 3–4: quantify the pain

Once you have seen the workaround, turn it into numbers. Founders often skip this because the pain feels obvious. It is obvious to you; it is not yet legible to the customer’s budget holder, investor, or future internal champion.

Quantify in the language the business already understands:

• hours per week
• error rate
• revenue leaked
• headcount absorbed
• cycle time delayed
• risk exposure

This is where discovery becomes decision-grade. A pain that costs 2 hours a week is one kind of product. A pain that costs 2 people half their week is another. A pain that creates compliance risk or lost revenue is stronger still.

You are not looking for perfect statistics. You are looking for a credible story with enough magnitude to justify a first build.

Weeks 5–6: cut the scope to the smallest thing that produces evidence

This is where most Stage-0 teams go wrong. Discovery findings expand scope instead of narrowing it. Every interview uncovers a “nice to have,” and the first version grows until it becomes a diluted platform.

Cut ruthlessly. For each proposed feature, ask one question: does this feature produce evidence, or only comfort?

Include in the first version:

• the core action that replaces the workaround
• the minimum input required to create value
• the output the user will judge immediately
• instrumentation that captures usage, repeat behavior, and drop-off

Cut from the first version:

• secondary workflows
• admin polish that does not change the core test
• edge cases that do not affect the first evidence signal
• anything added “because we might need it later”

If a feature does not help you learn whether the core workflow is used, it is not a first-version feature. It is scope inflation.

The AI demo question: what a working prototype proves and what it does not

Many Stage-0 operators arrive with something already built in Lovable, Cursor, Bolt, Claude, or a similar stack. That is good. A demo is an excellent discovery instrument. It is also a dangerous source of false confidence.

What a demo can prove:

• people understand the concept
• the interface makes sense
• the workflow is explainable
• users can click through without immediate confusion

What it does not prove:

• that anyone will change how they work
• that the data model survives real usage
• that the problem is painful enough to adopt a new habit
• that the product fits into a real operating environment

In other words, a prototype can validate comprehension. It cannot validate adoption. That is why you need the evidence ladder before you start celebrating interface feedback.

Discovery does not stop when the build starts

The strongest evidence only appears after real people use the real thing. So the first release needs to be built for learning, not just shipping.

Before launch, decide three things:

• What will be instrumented? Core actions, repeat usage, drop-off points, completion rates.
• What will we ask users? A small number of usage questions you define in advance.
• How often will we review? A fixed cadence for deciding what to keep, cut, or change.

This is where discovery and delivery connect. Discovery is not complete when the prototype looks good. It is complete when the first version is designed to produce evidence from actual use.

Five ways discovery goes wrong for founders with conviction

• Interviewing friendly people. Friends and supporters do not pay the evidence tax.
• Asking about the future. Future intent is cheap. Past behavior is expensive, and therefore useful.
• Confusing enthusiasm with a workaround. Interest is not the same as urgency.
• Using discovery to delay commitment. Six months of “research” can be disguised avoidance.
• Letting findings expand scope. Discovery should narrow the first release, not turn it into a wishlist.

There is also a category error that appears constantly in search results and tool pages: product discovery vs requirements gathering. Requirements gathering documents known needs. Discovery determines whether the need is real, costly, and urgent enough to deserve a build at all.

What good looks like: from conviction to a working first version

A strong Stage-0 process usually looks less dramatic than people expect. You start with conviction. You talk to users who already work around the problem. You see the workaround in practice. You quantify the cost. You cut the first scope until it only includes what is needed to test the core behavior. Then you instrument the release so the next week’s data can challenge your assumptions.

What changes is not your confidence; it is your precision. You stop saying, “I think this is a good idea.” You start saying, “This is the smallest version that can prove whether the market will actually adopt the workflow.”

That is the real output of product discovery at Stage 0: not a workshop recap, but a decision about what deserves to exist first.

Frequently asked questions

What is product discovery?

Product discovery is the process of deciding what is worth building for a specific user, before you invest heavily in development. For Stage-0 operators, it means using evidence to choose the first version, not just generating ideas.

How long should product discovery take?

At Stage 0, it should usually take weeks, not months. A focused six-week process is enough to identify the workaround, quantify the pain, and cut a first scope that can produce real evidence.

What questions should I ask in a discovery interview?

Ask about the last time the problem happened, what they did then, what workaround they use now, how often it occurs, and what it costs them. Avoid hypothetical questions like “Would you use this?”

What is the difference between product discovery and requirements gathering?

Requirements gathering documents an already agreed need. Product discovery tests whether the need is real, painful, and worth solving now. Discovery comes before committed scope.

Do I need product discovery if I already have a working prototype?

Yes. A prototype may prove that people understand the idea, but it does not prove that they will change behavior, adopt it in context, or pay for it. Discovery continues until real usage tells you what matters.

Who does discovery when there is no product manager?

At Stage 0, the founder or operator does it. If you are the buyer, the domain expert, and the person funding the build, you are the discovery function.

What is a product discovery workshop?

A workshop is a format. Discovery is a decision process. A workshop can help surface assumptions, but it does not replace evidence from user behavior, workarounds, and usage.

What is continuous discovery?

Continuous discovery is a habit of ongoing customer contact and evidence review while building. For a Stage-0 team, it matters only if it is tied to actual decisions about scope, instrumentation, and release changes.

Discovery for a Stage-0 operator is not about collecting more opinions. It is about graduating evidence until the first version has earned the right to exist.