Product discovery guide
How to find the right problems before building solutions
Product discovery is the process of figuring out what to build before you build it. Here is the framework that separates great PMs from order-takers.
The difference between discovery and delivery
Delivery is building things. Discovery is figuring out what to build. Many product teams skip discovery and go straight to delivery — resulting in perfectly executed solutions to the wrong problem.
Discovery answers:
Is this a real problem?
Do enough people have it?
Is this the right solution?
Will it work technically?
Will the business support it?
Most teams do too much delivery and too little discovery. A week of discovery prevents months of wasted development.
The opportunity framing
Before jumping to solutions, frame the opportunity. This framing prevents the most common mistake: building solutions before understanding the problem.
Who has the problem? How often?
What do they currently do instead?
What is the cost of their current solution?
How would their life or work be better if this problem was solved?
Discovery techniques
These four techniques cover the core discovery work that precedes any build decision.
Problem interviews
Talk to 6–10 people who have the problem you think you are solving. Ask about their current behavior, not hypothetical preferences. ‘Walk me through the last time you needed to do X.’ Do not pitch your solution.
Opportunity sizing
Estimate the size of the problem. How many people have it? How often? What is the value of solving it in time, money, or risk reduction? Rough math (‘back of envelope’) is enough — directional accuracy is the goal.
Solution prototyping
Build the cheapest possible version of your solution to test the riskiest assumption. A landing page, a Figma prototype, a Wizard-of-Oz test. The goal is learning, not building.
Kill criteria in advance
‘If fewer than 30% of users complete this flow, we will not build this.’ Defining failure criteria in advance prevents post-hoc rationalization.
The dual-track model
Many product teams run discovery and delivery in parallel — one track discovers what to build next while the other track delivers what was already decided. This prevents the “we finished the roadmap, now what?” problem and reduces the delay between learning and building.
Discovery track
What should we build next?
Problem interviews, prototyping, opportunity sizing
Delivery track
Build what we already decided
Engineering, QA, deployment, release
Next steps
Apply discovery skills in the PM track
Discovery is one layer of the product manager skillset. The PM track covers prioritization, roadmaps, stakeholder management, and the full interview playbook.
Explore PM career