Product Discovery

What is Product Discovery?

Product discovery is the work of figuring out what is worth building before you commit engineering time to building it.

The term is commonly attributed to Marty Cagan, who has written that he started experimenting with "discovery" around 2005 and committed to it fully while writing the first edition of Inspired in 2007. He borrowed the word from pharmaceutical drug development, where the industry openly accepts that most candidate treatments will fail before one is proven safe and effective (SVPG). Cagan liked that "discovery" was neutral about technique and pushed teams to weigh risk across value, usability, feasibility, and viability, rather than starting from a fixed list of requirements.

Discovery is defined in contrast to delivery. In Cagan's framing, discovery exists to produce evidence that a solution is worth building at all, so that when engineers move to production-quality code, that effort isn't wasted. Delivery is the separate job of making that validated solution scalable and reliable enough that the team can release it with confidence (SVPG). Teresa Torres later built on this with continuous discovery, which she defines as weekly touch points with customers by the team building the product, running small research activities in pursuit of a specific outcome (Product Talk). Where Cagan's original framing treats discovery as a phase you move through, Torres treats it as a habit you keep running for as long as the product exists. Produck's glossary uses discovery in this second, ongoing sense.

Why it matters for product-market fit

Discovery is the engine of Produck's Diagnose step. Once Listen has pulled in raw feedback, Diagnose is where you turn that feedback into a testable belief about what to build next, before it becomes a roadmap commitment in Decide.

Most teams treat discovery as something that happens once, before a big launch, then go quiet until the next one. That's the gap we wrote about in why the PMF stack is broken: tools that log feedback without ever routing it back into a discovery habit just build a bigger backlog, not a clearer picture of what your users actually need. Continuous Discovery closes that gap by making discovery a standing weekly practice instead of a pre-launch ritual.

Two techniques do most of the work inside discovery. The User Interview is how you hear the problem in a customer's own words instead of guessing at it from a support ticket. The Jobs to Be Done lens is how you turn what they said into the underlying job they're trying to get done, which is usually more durable than the specific feature they asked for. Run both consistently and Diagnose stops being a guessing game and starts being the thing that actually moves you toward Product-Market Fit.

When it works, and when it doesn't

It works when:

• The team building the product talks to customers directly, instead of relying only on secondhand research reports or personas.
• You're testing a specific, falsifiable belief about a customer problem, not just gathering open-ended opinions.
• Discovery and delivery run on separate clocks, so learning fast doesn't force engineering to cut corners on production code.
• Findings feed a decision that's actually on the table soon, so what you learn gets used while it's still fresh.

It falls short when:

• Nobody owns turning the conversations into a decision, so interviews pile up and nothing changes on the roadmap.
• It's run as a one-time research phase before a launch, then dropped until the next big bet.

How to apply it

1. Pick one desired outcome for the next few weeks, something like reducing churn in a specific segment or lifting activation for a new feature.
2. Book a standing weekly slot for customer conversations tied to that outcome. Torres's baseline is weekly; less often and the habit tends to die.
3. Bring a specific belief into each conversation, not a blank slate. Ask what the customer is actually trying to get done, not just what feature they want.
4. Log what you hear in one place your whole team can see, tagged to the outcome it relates to, so patterns across conversations are visible instead of scattered across notes and Slack threads.
5. Once a pattern repeats across several conversations, write it up as a testable hypothesis and hand it to Decide.
6. Keep the weekly slot running after you ship. The next round of discovery is what tells you whether the decision actually worked.