Product Discovery

What it is

Product discovery is the work that happens before a team commits to building: research to find a problem worth solving, and cheap experiments to find out whether a proposed solution actually solves it. It ends with a decision — build, change the approach, or stop — rather than with a document.

Why it matters

Delivery is good at answering “can we build this well?” and blind to “should we build this at all?”. Discovery is the discipline that asks the second question while the answer is still cheap. The economics are stark: a week of discovery against a quarter of engineering, where the commonest outcome is that the original idea was slightly wrong and the fix costs a day. Note that it starts from user research rather than replacing it — see User Research for the methods; this topic is about what discovery does with them and where it sits in a product’s decisions.

In this track

1. Finding a problem worth solving (04-product-process/04-product-discovery/01-finding-a-problem-worth-solving) — turning evidence into a problem statement with a size and a consequence.
2. Testing a solution cheaply (04-product-process/04-product-discovery/02-testing-a-solution-cheaply) — experiments that produce a decision rather than a demo.

Prerequisites

• User Research (03-design-ux/05-user-research)

Go deeper

• Product Management (04-product-process/03-product-management) — read this first; discovery answers the questions the decision role has to settle.
• The evidence behind a decision (04-product-process/03-product-management/03-the-evidence-behind-a-decision) — how discovery’s output becomes a written prediction.
• Lean UX (03-design-ux/37-lean-ux) — the same build-measure-learn loop run continuously inside a delivery team.
• Design Thinking (03-design-ux/02-design-thinking) — the wider loop discovery borrows its stages from.