Product discovery, end to end
Discovery is the part of product work where you decide what is worth building. Delivery is where you build it well. Most teams are better at the second than the first, partly because delivery produces visible progress and discovery mostly produces decisions, including decisions not to do things.
This note is an overview of the whole discovery cycle. Each stage has its own note, linked below.
Why it is worth the effort
Any team that measures what it ships learns the same lesson quickly: a good share of ideas do less than hoped, and some do nothing at all. That is not a failure of talent. Customers are hard to predict, and the people closest to a product are the worst placed to see it as a newcomer does.
Discovery is a way of finding out which ideas are weak while they are still cheap: a sketch, a conversation, a fake button. Throwing away a prototype costs an afternoon. Throwing away a shipped feature costs a quarter, plus the maintenance of everything built on top of it in the meantime.
The stages
- Frame the outcome. Agree what change you are trying to cause and how you will measure it. Not “build a dashboard”, but “reduce the time managers spend preparing the weekly report”. See Outcomes, not features.
- Understand people and context. Talk to customers, read support tickets, look at usage data. The goal is to learn how people currently get the job done and where it hurts. See Customer interviews that teach you something.
- Map the opportunities. Turn what you learned into a structured list of needs and pain points, then choose one to work on. See Mapping opportunities.
- Generate solutions. For the chosen opportunity, come up with several ways to address it. The first idea is rarely the best one; it is just the first.
- Test the assumptions. Work out what has to be true for each solution to succeed, then test the riskiest of those assumptions as cheaply as possible. See Testing assumptions before you build.
- Decide. Commit, change direction or drop the idea. Whatever survives is handed to delivery with the evidence attached.
The order is a guide, not a ritual. Interviews often reshape the outcome; a failed test sends you back to the opportunity map. Going backwards is not a sign that something went wrong. It is the process working.
It is not a phase
The most common misreading of discovery is to treat it as a block of research that happens before development starts: three months of interviews, a report, then a hand-over. By the time the report is finished, the questions have changed.
It works better as a continuous habit that runs alongside delivery. A few customer conversations every week, small tests running all the time, decisions made in days rather than quarters. People often call this dual-track: one track learning what to build, the other building what has already been learned.
Who does it
Discovery is not the product manager’s private activity. The most effective setup I know is a small group: someone responsible for the product, someone responsible for design and someone from engineering. Teresa Torres calls this the product trio.
Engineers in particular are often brought in too late. They are the ones who know that an idea which sounds expensive is in fact trivial, or that an innocent-looking request would require rebuilding the billing system. Hearing that before the idea has a launch date saves everybody a difficult meeting.
What comes out of it
Not a slide deck. The useful outputs of discovery are small and practical:
- a clear outcome and how it is measured;
- a map of opportunities with the chosen one marked;
- the assumptions that were tested and what happened;
- a sketch of the chosen solution, good enough to start a spec.
If someone new joins the team, these should be enough for them to understand why the team is building what it is building.
Knowing when to stop
You will never reach certainty, so the question is how much confidence is enough. The answer depends on the cost of being wrong. A change that can be rolled back in an hour needs little evidence; a pricing change or a data migration needs a lot.
There are signs of doing too little: building starts before anyone can state the outcome, or the only evidence is that a senior stakeholder likes the idea. There are also signs of doing too much: the same questions keep getting asked in new interviews, or tests are run to postpone a decision rather than to inform it. When new research stops changing your mind, it is time to build.