On this page
Product discovery is the work a team does before building to learn which problem is worth solving, for whom, and which solution people will use and pay for. A product discovery process turns that work into a routine you can repeat: frame the decision, learn how people work today, test the riskiest assumptions, then decide. This guide covers the process we run with startup teams and the product discovery techniques that fit each step. It also gives you the questions to ask users, a simple framework and a template you can copy.
It is the same process we follow when a founder asks us for help with feature discovery. You can run it without us. You need someone who owns the decision, someone who can run interviews and an engineer who can judge cost, each giving it a few hours a week.
What is product discovery?
Product discovery is how a team decides what to build next with evidence instead of opinion. It starts from a problem, not a feature request, and it ends with a decision: build it, change it or drop it. Along the way the team talks to the people who have the problem and watches what they do today. It checks the data it already holds and puts cheap prototypes in front of users. Discovery is different from delivery. Delivery asks how to build something well. Discovery asks whether it is the right thing to build at all.
Discovery is also different from validating a business. Validation asks whether a market exists and will pay. Discovery assumes a market and asks which problem, for which users, solved in which way. If you still need to prove that anyone has the problem at all, first use our guide to validate business idea assumptions with real buyers, then come back here.
Public digital teams treat discovery as a formal phase. The UK government's Service Manual says there is no set length, but around 4 to 8 weeks is typical. It says you should not start building during it, and that stopping at the end is not a failure when the research points that way. Canada's federal Digital Standards make the same point in their first standard, design with users. It asks teams to learn users' needs and the problems to solve through research with them. Startups can borrow that discipline at a smaller scale: one question, one owner, one decision.
The product discovery process in four steps
Each step has one job and one output. If a step has not produced its output, it is not finished, however many meetings it took.
Step 1: Frame the decision
Write down the decision discovery must support, who makes it and by when. "Should we build team accounts this quarter?" is a decision. "Learn about our users" is not. Then list what you believe: who has the problem, how often it happens, what it costs them and why they would switch. Rank those beliefs by how much damage it would do if each one turned out to be wrong. The output is a one-page brief, like the template further down.
Step 2: Learn how people work today
Talk to people who have the problem and watch how they handle it now. Ask about the last time it happened, not about your idea. Review the evidence you already hold: support tickets, sales call notes, search terms and product analytics. The UK Service Manual names the same three sources: existing evidence, interviews and observation, and people who work with users every day. The output is a short list of problems, each backed by what people said and did, and grouped by who has them.
Step 3: Test the riskiest assumptions
Take the beliefs at the top of your ranked list and design the cheapest test that could prove each one wrong. That might be a clickable prototype, a landing page with a sign-up button, a manual version of the service run by your team, or a pricing conversation. Build only enough to learn. The UK guidance for the phase after discovery says to expect to throw away the code and many of the ideas you test, and that is healthy. The output is a result for each assumption: held, failed or still unclear.
Step 4: Decide and hand over
Go back to the decision you framed in step 1 and make it, in writing, with the evidence beside it. Build, change direction and stop are all good outcomes. If you build, hand engineering the problem statement, the user segments, the prototype and the open questions, not just a list of tickets. Then put the first slice on the plan and agree how you will measure it after release.
A simple product discovery framework
A product discovery framework is the fixed shape of the work: the same steps, questions and outputs every time. That way the quality of discovery does not depend on who runs it. Ours is the four steps above. It sits inside the Double Diamond from the UK Design Council, which describes design as two rounds of opening up and narrowing down. First you discover and define the problem, then you develop and deliver the solution.
The table below is the version we keep in front of the team. Each row says what the step answers, what it produces and how you know it is done.
| Step | Question it answers | Output | Done when |
|---|---|---|---|
| Frame | What decision are we making, and what do we believe? | A one-page brief with ranked assumptions | The owner has agreed the decision and the date |
| Learn | Who has the problem, and how do they handle it now? | A problem list with evidence, grouped by segment | New interviews stop changing the list |
| Test | Which of our riskiest assumptions hold? | A result for each risky assumption | The top assumptions are held or failed, not unclear |
| Decide | Build, change direction or stop? | A written decision and a handover pack | Engineering can estimate the first slice |
Product discovery techniques and when to use them
There are dozens of product discovery techniques. Most startup teams need six. Pick each one for the question you are answering, not out of habit.
- Evidence review. Read support tickets, cancellation notes, sales calls and analytics before you talk to anyone. Do it first: it is cheap, and it sharpens your interview guide.
- Problem interviews. One-to-one conversations about the last time someone faced the problem. Use them in the learn step, and keep adding people in a segment until the answers start to repeat.
- Observation. Watch someone do the task in their own tools, in person or over a shared screen. Use it when what people say and what they do might differ.
- Assumption mapping. List every belief behind an idea and rank each one by risk and by how little evidence supports it. Use it in the frame step to choose what to test.
- Prototype tests. Put a clickable mock-up or a paper sketch in front of users and ask them to complete a task. Use it to check that a solution makes sense before anyone writes production code.
- Demand tests. A landing page, a waitlist, a pre-order or a service you run by hand. Use them to see whether people will act, not just say yes. Be honest with anyone who signs up about what exists today.
Usability work sits right next to discovery. Once you have a prototype, the types of usability testing you choose decide what you learn about whether people can use it.
Product discovery questions to ask users
Good product discovery questions ask about real past events. Opinions and predictions cost the speaker nothing, so they tell you little. Ask what happened, what people did about it and what it cost them.
About the problem
- Tell me about the last time this happened. What were you trying to get done?
- How often does it come up?
- What happens when it does not get solved?
- Who else is involved when it happens?
About what they do today
- Walk me through how you handle it now, step by step.
- Which tools, spreadsheets or people do you rely on?
- What have you tried that did not work, and why did you stop?
- Which part takes the most time?
About value and money
- What does the current way cost you in time or money?
- Have you paid for anything to fix this? What made you choose it?
- Who would have to approve spending money to fix it?
Questions for your own team
- What would we have to believe for this idea to be worth building?
- Which of those beliefs has the least evidence behind it?
- What result would make us stop?
- What is the smallest thing we could ship to learn more?
Leave out "Would you use this?" and "How much would you pay?". A polite yes costs nothing, and it is the answer people think you want to hear.
A product discovery template you can copy
This product discovery template fits on one page. Fill it in during the frame step, update it as evidence arrives, and attach it to the decision at the end. The examples are hypothetical: a seed-stage team selling booking software to physiotherapy clinics.
| Field | What to write | Hypothetical example |
|---|---|---|
| Decision | The choice this discovery supports, who owns it and the date | Build group bookings this quarter or not; the product lead; end of the month |
| Users | Who has the problem, as specific segments | Front-desk staff at clinics with three or more practitioners |
| Problem | The problem in the user's own words, with no solution in it | "Moving a class means calling every patient one by one." |
| Beliefs | What must be true for the idea to work, ranked by risk | Clinics run group classes every week; staff will trust automatic messages to patients |
| Evidence so far | What you already know and where it came from | Support tickets that ask for class scheduling |
| Tests | The technique, who you will talk to and how many | Interviews with front-desk staff at several clinics, then a clickable prototype |
| Stop signal | The result that would make you drop or change the idea | Most clinics run classes rarely, or already manage them in another tool |
| Result | The decision, the evidence behind it and the open questions | Filled in on the decision date |
Common product discovery mistakes
- Starting with the solution. If the brief names a feature, rewrite it as a problem and a decision.
- Interviewing only fans. Happy customers explain why you won. People who left or chose another tool explain what is missing.
- Leaving engineering out. An engineer in the room spots ideas that are cheap to test but expensive to run, and the reverse.
- No decision at the end. Discovery that ends in a slide deck instead of a decision has to be repeated later.
- Discovery that never ends. Set the decision date in step 1. When it arrives, decide with the evidence you have.
From discovery to the roadmap
A discovery decision is only useful if it changes the plan. Turn the result into a roadmap item with its problem statement and evidence attached, so the reason survives when priorities shift. Our guide on how to create a product roadmap shows how to keep that link between evidence and plan. After release, keep a light version of discovery running. Hold a few customer conversations each month and take a regular look at the numbers for the problem you set out to solve.
Frequently asked questions
What is product discovery?
Product discovery is the work of deciding what to build before you build it. A team learns who has the problem, how they handle it today and which solution they will use and pay for. It then tests its riskiest assumptions with interviews, data and prototypes. The output is a decision backed by evidence, not a feature list.
What questions should you ask in product discovery?
Ask about real past behaviour rather than opinions. Useful product discovery questions include: when did this last happen, what did you do, what did it cost you, what have you tried, and who else was involved. Avoid asking whether someone would use or buy an idea, because a polite yes costs them nothing.
What is a product discovery framework?
A product discovery framework is a fixed sequence of steps and outputs that makes discovery repeatable. Ours has four: frame the decision, learn how people work today, test the riskiest assumptions, then decide. Public frameworks such as the Design Council's Double Diamond follow the same pattern of exploring a problem before narrowing to a solution.
When is product discovery finished?
Discovery for a question is finished when you can make the decision you framed at the start, with evidence you would defend to a doubtful colleague. The answer might be build, change direction or stop. If new interviews no longer change your view, you have enough. Discovery as a habit carries on after launch.
Who should take part in product discovery?
A small cross-functional group works well. It includes the person who owns the product decision, a designer or researcher who runs the sessions, and an engineer who judges what is feasible and what it costs. Founders should join interviews themselves. Sales and support staff add useful evidence because they hear customer problems every day.
