Product Discovery
The process of determining what to build — through user research, prototyping, and testing — before committing engineering resources to delivery.
What is Product Discovery?
Product discovery is the work product teams do to decide *what* to build and *why* before they build it. It sits upstream of delivery — its output is a validated understanding of user problems, not shipped features.
Marty Cagan's framing: discovery is about answering four questions before coding starts:
- Value — Will users buy or use this?
- Usability — Can users figure out how to use it?
- Feasibility — Can engineering build it in a reasonable time?
- Business viability — Does it work for the business?
Discovery vs. Delivery
| Discovery | Delivery |
|---|---|
| What should we build? | Build the thing we decided to build |
| High uncertainty, fast learning | Low uncertainty, high execution |
| PM + Design lead | Engineering leads |
| Output: validated decisions | Output: working software |
Core discovery activities
- Customer interviews — 1:1 sessions to understand problems and workflows
- Usability testing — watching users interact with prototypes
- Prototyping — making ideas tangible without engineering cost
- Assumption mapping — identifying and ranking risky assumptions
- Concierge tests — manually delivering the solution to test demand
Free templates for Product
Frequently asked questions
How much time should discovery take?
Discovery should be continuous, not a phase. Dedicate 20–30% of PM and design capacity to ongoing discovery even while delivering features. Separating discovery from delivery with a 'big design up front' phase is a common antipattern.
What's the output of a discovery sprint?
Not a document — a decision. Discovery produces validated answers to specific questions: 'users will pay for this', 'users can complete onboarding without help', 'the API latency is acceptable'. These answers unlock the delivery work.
Apply Product Discovery to your real product data
PMRead ingests customer feedback, interviews, and Slack threads — and generates PRDs grounded in real evidence.
Related terms
Jobs to Be Done (JTBD)
A framework that explains why customers buy products — not because of what the product is, but because of the progress they're trying to make in a specific situation.
MVP (Minimum Viable Product)
The smallest version of a product that delivers enough value to attract early adopters and generate validated learning about your core assumptions.