Product Discovery
Product discovery is the continuous work of deciding what is worth building. Discovery is not a phase that precedes delivery and it is not requirements gathering — it is a habit of talking to users every week and mapping what you learn as opportunities, so that solutions compete against each other rather than arriving pre-decided. This page covers the trio, the opportunity tree, assumption mapping, the four risks and the cheapest tests for each.
- Cadence
- Weekly, continuous
- Unit of work
- Opportunity
- Risks to test
- Value · Usability · Feasibility · Viability
Continuous, not a phase
The traditional shape is a discovery phase that produces requirements, followed by a delivery phase that builds them. It fails for a specific reason: the most valuable thing you learn about a product is what happens when people use it, and that information only exists after delivery has started.
Continuous discovery runs the two in parallel. A small trio — product, design, engineering — talks to at least one customer every week, and what they learn feeds the next decision rather than a document. The cadence matters more than the volume: one interview a week for a year beats twenty interviews in a fortnight, because the point is to keep a live model of the user rather than to complete a study.
Why it has to be three people
The trio is not a coordination convenience. Each role hears something the others do not: the product person hears the business consequence, the designer hears where the mental model breaks, the engineer hears which constraint just became irrelevant or just became fatal. Send one of them and you get a summary of an interview, which is a different artefact — most of what is useful in a customer conversation is the thing you did not know to write down.
The engineer's presence is the one most often traded away, and it is the most expensive to lose. An engineer who has heard the problem proposes cheaper solutions to it — including the ones that require no interface at all — and does so before anyone has fallen in love with a design. An engineer who receives the solution afterwards can only estimate it.
The reason continuous discovery usually stops being continuous is logistics, not conviction. Recruiting a participant by hand takes longer than the interview does, so the week it gets busy is the week it stops. The fix is to make recruiting automatic: an in-product prompt shown to users who just did the relevant thing, a scheduling link, a small incentive, and a standing slot in the calendar that exists whether or not anyone has booked it yet.
The opportunity solution tree
The tree is the structure that keeps discovery honest. One outcome at the root, the opportunities that could move it underneath, and competing solutions under each opportunity — so that a solution is always compared against alternatives for the same need, rather than judged alone.
An opportunity is a need, pain point or desire stated in the customer's terms — "I lose track of which invoices are unpaid", not "add an invoice dashboard". Keeping the layer free of solutions is what makes the tree work, because the moment an opportunity is phrased as a feature, the alternatives underneath it can only be variations of that feature.
The discipline is in the middle layer. When a stakeholder arrives with a feature, the question is not "should we build this?" but "which opportunity does this serve, and what else could serve it?" A feature with no opportunity above it has no argument for existing; a feature that is the only child of its opportunity has not been thought about yet.
The other job of the tree is to make scope refusable without an argument. A request that does not connect to the outcome at the root is not rejected on taste or capacity — it is visibly outside the thing the team agreed to move this quarter. That is a far easier conversation than "we do not have time", and it is the same reason an outcome at the root has to be a real, measured number rather than a slogan.
From idea to test: assumption mapping
A solution is never wrong as a whole — it is wrong because one belief underneath it does not hold. Assumption mapping is the step between "we could build this" and "here is what we will test": write down every belief the idea depends on, then sort them.
Sort on two axes: how important the assumption is — if it is false, does the idea die? — and how much evidence you already have. The assumptions that are important and unevidenced are the only ones worth testing. Everything else is either safe to proceed on or not worth the argument, and separating them takes about twenty minutes with the trio and a wall.
The four risks
Before committing engineering time, four questions need at least a cheap answer. Teams reliably test the third and skip the first, which is the wrong order — feasibility is the risk engineers can see, and value is the one that actually kills products.
Value — will anyone want it?
The risk that gets skipped and the one that kills products. Test with a real choice: a landing page, a price, a commitment — something where saying yes costs the person something.
Usability — can they figure it out?
Five people attempting the task on a prototype will surface most of it, long before anything is built. Watch them do it; do not ask them whether it was clear.
Feasibility — can we build it?
A timeboxed spike, not a debate. Engineers should be in discovery for this, not consulted after the fact.
Viability — should our business do it?
Legal, support cost, margin, brand, the sales model. The one that surfaces late and expensively when skipped.
Each risk has an owner, and the ownership is what stops them being everyone's vague responsibility: value and viability sit with product, usability with design, feasibility with engineering. Viability in particular is nobody's job by default, which is why it tends to be discovered by the legal review a week before launch.
The ladder of tests, cheapest first
| Test | What it answers | Cost and caveat |
|---|---|---|
| Ask the data | Does this behaviour already happen and how often? | Hours. Free, and skipped more often than any other step. |
| Story interview | Is the problem real, and how is it worked around today? | A week. Tells you about the past, not the future. |
| Prototype test | Can people complete the task with this design? | Days. Answers usability, says almost nothing about value. |
| Fake door | Would people choose this if it existed? | Days. Strong signal; handle the disappointment honestly. |
| Concierge / Wizard of Oz | Does the outcome help once they actually get it? | Weeks of manual work. Does not scale — that is the point. |
| A/B test | Which version moves the metric, by how much? | Build cost plus traffic. Needs the sample to conclude anything. |
Work down the ladder only as far as the decision requires. The common mistake is jumping to the bottom rung — building the thing and A/B testing it — for a question the top rung would have answered on Tuesday afternoon.
How this shows up in real delivery
The honest reason discovery is skipped is that it looks like not shipping. A quarter spent building four features feels productive; a quarter spent testing eight ideas and building two feels slow — right up until you count how many of the four were used. The industry-standard figure that makes the argument is uncomfortable and well replicated: something like half to two-thirds of shipped features move no metric at all.
The second thing worth saying out loud: discovery does not remove the need to decide under uncertainty, and a team that keeps testing rather than choosing has replaced one failure mode with another. The purpose of a test is to make the next decision better, not to make it safe. If a week of research would not change what you do on Monday, do the thing on Monday.
Where it degrades
- Interviews that ask what people want instead of what they last did.
- A discovery phase with an end date, which turns it back into requirements gathering.
- Opportunities phrased as features, so every alternative underneath is a variation of one idea.
- One solution per opportunity, so nothing was actually compared.
- Engineers excluded until the solution is chosen, which makes feasibility a late surprise.
- Recruiting done by hand, which is why the cadence dies in the first busy week.
- Research that would not change Monday, run anyway, which is procrastination with a method.
When to use it
Use it when
- You have access to real users and can talk to them regularly.
- The team has room to decide what to build, not only how.
- The problem space is uncertain enough that being wrong is likely.
- You can ship small experiments and measure what they do.
- An engineer can be in the room, not briefed afterwards.
Avoid it when
- Scope is contractually fixed — there is nothing left to discover.
- The work is a defined technical migration with a known target.
- No access to users, which reduces discovery to opinions with a process around them.
- Leadership has already decided and wants discovery run as validation theatre.
Found this useful?
Share it with someone who is working on the same problem.