Product discovery is the work you do between deciding something might be worth building and committing to build it. Its purpose is narrow: find out whether the assumption the idea rests on is true, cheaply enough that being wrong costs a week instead of a quarter.
Most discovery goes wrong in the same way. A team picks the technique it is comfortable with, runs it thoroughly, and learns something true about an assumption that was never the risky one.
Start From the Riskiest Assumption
Every proposed feature carries four assumptions, and they fail differently.
| Assumption | The claim | How it fails |
|---|---|---|
| Desirability | People want this solved | It ships, works, and nobody uses it |
| Usability | They can actually operate it | Adoption stalls and support volume rises |
| Feasibility | We can build it in something like the estimate | It takes three times as long or gets cut |
| Viability | It works for the business | Used and loved, and it costs more to run than it returns |
Write the four out for the item you are considering and mark which one, if false, kills the idea. That is the riskiest assumption, and it decides the technique. A team that runs interviews on something whose real risk is feasibility has spent two weeks confirming that people want a thing you may not be able to build.
The common pattern is that teams over-test desirability, because talking to users is the discovery activity everyone recognises, and under-test usability and viability, because those need something built or costed.
The Techniques
| Technique | Best question it answers | Cost | Speed | Evidence type | Main limitation |
|---|---|---|---|---|---|
| Customer interviews | Why do they do it this way now | Medium | Days | Qualitative | Answers about the future are speculation |
| Support ticket analysis | What breaks repeatedly, for whom | Low | Hours | Qualitative at volume | Only shows people who wrote in |
| Surveys | How widespread is a known pattern | Low | Days | Quantitative, stated | Confirms what you already suspected; poor at discovery |
| Usability tests | Can they operate this | Medium | Days | Behavioural, observed | Needs something to test, even paper |
| Prototype tests | Does the proposed solution fit the job | Medium | 1 to 2 weeks | Behavioural, simulated | A prototype forgives problems the real thing will not |
| Fake-door tests | Would they take this action for it | Low | Days | Behavioural, real | Measures interest in a description, not in a product |
| Product analytics | Where do they actually drop off | Low once instrumented | Hours | Behavioural, real | Shows what happened, never why |
| Cancellation interviews | Which problems cost accounts | Low | Weeks | Qualitative, high signal | Few will talk, and they are the least motivated to |
| Sales call analysis | What blocks a purchase | Low | Days | Qualitative | Reflects buyers, who are often not users |
| Feedback board analysis | What people ask for unprompted | Low | Hours | Stated demand | Self-selected toward the vocal |
| Concierge or manual test | Would this be valuable if it existed | High per user | Weeks | Behavioural, real | Does not scale, and that is the point |
Two things to read off this table. Fake-door and concierge tests produce real behavioural evidence for a feature that does not exist, which is the only category that does. And analytics and interviews are complements rather than alternatives: analytics tells you where, interviews tell you why, and either alone produces a confident wrong answer.
Match technique to risk:
- Desirability at risk? Fake-door, cancellation interviews, board analysis, concierge.
- Usability at risk? Usability tests and prototypes. Nothing else answers this.
- Feasibility at risk? A technical spike. No amount of customer research helps.
- Viability at risk? Pricing conversations, cost modelling, sales calls.
The Evidence Ladder
Not all evidence is the same weight, and teams routinely act on rung one while describing it as rung four.
4. Validated behaviour people did the thing, with the real product or a
convincing stand-in, without being asked to
^
3. Behavioural pattern usage or support data shows it happening at scale,
unprompted
^
2. Repeated qualitative several independent people, unprompted, described
the same problem
^
1. Single anecdote one person said something, possibly persuasively
Rung one is where ideas legitimately start. It is not where commitments belong. The dangerous move is a rung-one anecdote from someone senior or from a large customer, which arrives with authority attached and skips the ladder entirely.
Climbing a rung usually costs less than people expect. Going from one to two is often an afternoon of searching existing support tickets for the same phrasing.
Resist scoring this. Discovery evidence does not reduce to a number, and a scoring rubric mostly produces the appearance of rigour. The useful question in review is which rung the evidence sits on and what the next rung would cost.
A One-Week Discovery Sprint
A realistic shape for a team that cannot stop delivery to research.
Monday, half a day. Write the four assumptions. Mark the riskiest. Search existing sources first: support tickets, board posts, cancellation notes, analytics. Roughly half the time, the answer is already there and the sprint ends here, which is the best possible outcome.
Tuesday. Pick the technique matched to the risk. Book whatever it needs. Interviews book slowest, so book them now even if you may not need them.
Wednesday and Thursday. Run it. Five to six interviews, or one usability round, or a fake door left live. Write notes the same day, before the memory reshapes them.
Friday, half a day. Answer one question: is the riskiest assumption still standing. Then one of three outcomes. It held, so the item can take a roadmap slot with the evidence attached. It failed, so the item goes back to the opportunity list and you have saved a quarter. Or it is unresolved, in which case name specifically what is unresolved and what would settle it, rather than scheduling more research in general.
When to Stop
Discovery has a failure mode of its own: research as a way of not committing. Three tests for whether you are done.
You can predict the next answer. If you can guess what interview seven will say and you are right, the interviews have converged.
Nothing would change the decision. If the item ships either way, further discovery is a cost with no option value attached.
The remaining uncertainty is cheaper to resolve by building. Some questions only the real thing answers. At that point, build the smallest version that answers it.
The corresponding failure in the other direction is stopping at rung one because the answer was the one you wanted.
What Discovery Does Not Do
It does not tell you what to build. It tells you which assumptions survived, and survival is not a priority. An idea can clear every assumption and still lose its slot to something with a weaker case and a stronger strategic fit. That call belongs to prioritisation, which weighs validated ideas against each other.
It also does not remove the need for judgement about who you talked to. Six interviews with your six most engaged customers describe the needs of your six most engaged customers. Discovery that only samples the people already succeeding with the product reliably confirms the current direction, and running interviews well is mostly about avoiding that.
Where discovery is skipped entirely, the roadmap fills with the customer's proposed solutions rather than their problems, which is one of the ways roadmaps fail.
FlagUp is useful for the cheap first step: existing requests, support signals and cancellation feedback in one searchable record, so the Monday search actually returns something. See what each plan includes.
Frequently Asked Questions
What is product discovery?
The work between thinking something might be worth building and committing to build it. Its job is to test whether the assumption the idea rests on holds, cheaply enough that being wrong is survivable.
How do you choose a discovery technique?
Write the four assumptions, desirability, usability, feasibility and viability, and find the one that kills the idea if false. That assumption picks the technique. Usability risk needs a prototype; feasibility risk needs a spike, not a customer conversation.
How many customer interviews are enough?
Enough that you can predict the next answer. That is usually five or six for a narrow question and more when the segments genuinely differ. Counting interviews is a worse stopping rule than noticing convergence.
Is a fake-door test dishonest?
It becomes so if people are led to believe something exists that does not. Keep it to measuring interest, say plainly that it is not available yet, and follow up with anyone who asked to be told when it is.
What is the difference between discovery and validation?
Discovery is open: what problems are worth solving. Validation is closed: does this specific solution work. Running validation first is how teams end up carefully proving the merits of the wrong idea.
Can small teams do product discovery?
The techniques with the best cost-to-signal ratio are the ones that need no research function: reading your own support tickets, asking cancelling customers one question, and watching a person use the thing. Discovery is more often skipped for lack of a slot in the week than for lack of headcount.
FlagUp helps teams keep requests, support signals and cancellation feedback in one place, so discovery starts with what you already know. Start free.
Related articles
- How to Run User Interviews That Actually Change What You Build
- Why Most Product Roadmaps Fail, and How to Fix Them
- What Is Feature Prioritization?
- How to Collect User Feedback That Actually Shapes Your SaaS Roadmap
- How to Turn Support Complaints Into Product Roadmap Signals
- Building a Data-Driven Product Roadmap From User Signals