Product Discovery for Stage-0 Operators

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, and we wrote this for the operator. 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 Product Discovery Advice Does Not Fit a Stage-0 Operator

The usual product discovery process runs from understanding users to defining the problem, ideating, prototyping, and testing. We think that sequence is useful. It is also incomplete for a founder or domain expert deciding when 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. It is 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 Discovery Evidence Ladder That Predicts What Gets Used

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

The Evidence Ladder, Weakest to Strongest

• Opinion sounds like “I like this idea.”
• Stated intention sounds like “I would use this.”
• Observed behavior means they do something today that reveals the need.
• Existing workaround means they already cobble together a process.
• Time or money spent on the workaround means the workaround costs them real resources.
• Willingness to trial means they will try the thing in a real workflow.
• Willingness to pay means they exchange money or budget authority.
• Repeated use means 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. Nielsen Norman Group makes a related point, which is that people misremember the past and mispredict the future.

Here is the same idea at three different rungs:

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

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

A Six-Week Stage-0 Discovery Procedure

We compress a practical continuous discovery loop 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.

1. Weeks 1 to 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.

2. Weeks 3 to 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.

3. Weeks 5 to 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? That cut is the core of MVP development, and how to decide what to cut from your MVP scope goes deeper. For the longer founder-side view, see The Founder’s Playbook.

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 if the core workflow is used, it is not a first-version feature. It is scope inflation.

What a Working AI 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. We think 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. We cover the written side in how to write a PRD when you already have a working demo, and SVPG frames discovery as finding out if real users want the product.

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. Product Talk describes weekly customer contact as the baseline for continuous discovery.

Five Ways Discovery Goes Wrong for Founders With Conviction

We watch for these five patterns.

• 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 common category error, which is mixing up product discovery and requirements gathering. Requirements gathering documents known needs. Discovery determines if 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

We find 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 if the market will actually adopt the workflow.”

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

Start With the Workaround People Already Use

Product 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. Start with the workaround people already use, put a cost on it, and cut the first release to the smallest thing that can prove the bet.

If you want help turning the findings into a first version, we do this work at Better Software.

Frequently Asked Questions

What Is Product Discovery?

We define product discovery as 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, we expect it to 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. Longer than that often becomes avoidance.

What Questions Should I Ask in a Discovery Interview?

We 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. We avoid hypothetical questions such as “Would you use this?” because they produce compliments instead of evidence.

What Is the Difference Between Product Discovery and Requirements Gathering?

Requirements gathering documents an already agreed need. Product discovery tests if the need is real, painful, and worth solving now. We run discovery before committed scope, because it can still change what gets built and what gets cut.

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. We keep discovery going until real usage tells us what matters.