Product Discovery Guide
(2026 Edition)
The 6-phase discovery process for finding the right problems before investing in solutions — with user interview templates, assumption testing, and the OST framework.
Practice Discovery Scenarios — Free →01. Define the Outcome
Before talking to users, be clear on what business or product outcome you're trying to improve. Discovery without a target outcome produces interesting insights that never turn into decisions.
How to do it
Write: 'We want to improve [metric] because [reason]. We believe [user segment] holds the key.' This frames who you need to talk to and what you're listening for.
⚠️ Common mistake: Starting discovery with 'let's just talk to users and see what we find.' Open discovery rarely generates actionable insight — only validation of existing hypotheses.
02. Map the Opportunity Space
Generate a list of user needs, pain points, and desires that are blocking the outcome. Not solutions — opportunities. An opportunity is a user need that, if addressed, would move your metric.
How to do it
Use the Opportunity Solution Tree (Teresa Torres): Outcome → Opportunities → Solutions → Experiments. Each opportunity is an unmet need, not a feature request.
⚠️ Common mistake: Confusing opportunity with solution. 'Users want push notifications' is a solution. 'Users forget to come back because nothing reminds them' is an opportunity.
03. Run User Interviews
Talk to real users about specific past experiences — not hypothetical preferences. What they say they want and what they actually do are often completely different.
How to do it
5 interviews per opportunity area is usually enough to find patterns. Ask: 'Tell me about the last time you [situation].' Never ask: 'Would you use a feature that...?'
⚠️ Common mistake: Leading questions that confirm your hypothesis. 'Don't you find it annoying when...?' — you've already told the user what to say.
04. Surface Assumptions
Every solution rests on assumptions about users, technology, and the business. Listing them makes them testable — and prevents building on a foundation that turns out to be false.
How to do it
For each proposed solution, list the 3 riskiest assumptions. Rank by: if this assumption is wrong, does the whole solution fail? Those are your priority tests.
⚠️ Common mistake: Treating assumptions as facts. 'Users will switch from WhatsApp to our chat because our UX is better' is an assumption until tested — not a given.
05. Run Rapid Experiments
Test your riskiest assumptions with the smallest possible investment of time and engineering before building. The goal is to generate signal quickly — not to validate a finished solution.
How to do it
Fake door test, landing page test, concierge MVP, Wizard of Oz prototype, or user testing a Figma mock. Match experiment type to assumption type.
⚠️ Common mistake: Building an MVP when a prototype would have tested the same assumption in 1/10th the time. An MVP is not the smallest possible test — it's the smallest possible product.
06. Synthesise and Decide
Bring together insights from interviews and experiments to decide which opportunity to invest in. Discovery creates a backlog of validated opportunities — prioritise them like any other work.
How to do it
Use an impact/evidence matrix: high impact + strong evidence = build now. High impact + weak evidence = run more experiments. Low impact = park.
⚠️ Common mistake: Continuing to discover when you have enough evidence to decide. Discovery is a means to de-risk decisions — not an end in itself.
5 User Interview Questions That Actually Work
Ask these in order. Don't deviate. Let the silence breathe.
“Tell me about the last time you tried to [goal]. What happened?”
Gets a specific story, not a generalisation
“What was the hardest part of that experience?”
Surfaces the actual pain point
“What did you try to do about it?”
Reveals their current workaround — often the real competitor
“What would a perfect solution look like?”
Directional, not prescriptive — helps understand the job-to-be-done
“Is there anything I haven't asked that you think I should know?”
Catches unexpected insights and makes users feel heard
FAQ
How much time should PMs spend on discovery vs delivery?
Continuous discovery means it's not either/or — discovery runs in parallel with delivery. Teresa Torres recommends 1 user interview per week per PM team as the minimum sustainable cadence. This takes ~2 hours/week and dramatically reduces the chance of building something nobody wants. Discovery that only happens before a project starts misses the ongoing learning that changes what you should build next.
What's the difference between product discovery and user research?
User research is one tool within product discovery. Discovery is the full system: defining outcomes, mapping opportunities, running research, testing assumptions, and deciding what to build. You can do user research without discovery (interesting insights that don't connect to decisions) or discovery without formal user research (using analytics and sales data as your input). Best practice: combine both.
How do you do product discovery at an early-stage startup with no users?
Talk to potential users — people who have the problem you're solving, even if they've never heard of your product. Your first 20 user interviews should happen before you write a line of code. Use your personal network, LinkedIn outreach, or subreddits/communities where your target users hang out. No users is not an excuse to skip discovery — it's the moment discovery matters most.
Build Discovery Habits in 2 Minutes a Day
Daily scenarios that sharpen user empathy, assumption testing, and opportunity framing.
Start Free Trial →