Product Discovery Process
Product discovery is the continuous practice of deciding WHAT to build before delivery teams build it. Marty Cagan's framing at SVPG: discovery answers four risks — value (will customers buy/use it?), usability (can they figure it out?), feasibility (can we build it?), and business viability (does it work for our business?). Teresa Torres' Continuous Discovery Habits formalized the cadence: weekly customer interviews, opportunity mapping, and small-but-frequent assumption tests. Companies that run discovery in parallel with delivery (dual-track agile) ship 2-3x fewer features but those features get adopted at 4-5x the rate of feature-factory peers. Discovery is the difference between shipping software and shipping outcomes.
The Trap
The trap is treating discovery as a one-time phase that happens before sprint planning, then never again. Teams 'do discovery' for two weeks, then disappear into a 6-month build cycle, only to launch features nobody uses. The opposite trap is 'discovery theater' — running interviews and workshops to validate decisions you've already made. Teresa Torres calls this 'confirmation discovery': you ask leading questions, ignore disconfirming evidence, and walk away feeling validated. Real discovery means being willing to kill your favorite roadmap item when the evidence says it solves no problem.
What to Do
Adopt Torres' minimum-viable cadence: (1) Interview at least one customer per week per product trio. (2) Maintain a shared Opportunity Solution Tree mapping the desired outcome → opportunities → solutions → assumption tests. (3) For every solution, list the riskiest assumption and design the smallest possible test (a Figma prototype, a fake door, a manual concierge service) that could falsify it. (4) Review the tree weekly with the trio and prune ruthlessly. (5) Run discovery and delivery in parallel — never block delivery while discovering, never skip discovery to feed delivery.
Formula
In Practice
When Teresa Torres started coaching Hope (a product team at a B2B SaaS company), they were shipping one major feature per quarter and seeing <10% adoption. Torres made them commit to one customer interview per week and one opportunity-tree update per week. Within 6 months, they were shipping smaller features more frequently, but adoption per feature jumped to 35%+. The team killed two roadmap items mid-sprint because interviews revealed the underlying opportunity didn't exist. (Source: Continuous Discovery Habits, Teresa Torres)
Pro Tips
- 01
Marty Cagan's rule: 'The product manager's job is to discover a product that is valuable, usable, feasible, and viable.' If you're only validating ONE of those four risks, you're not doing discovery — you're doing a partial sanity check.
- 02
Run discovery on next quarter's bets while delivery ships this quarter's bets. The most common failure mode is sequential ('first we discover, then we build'), which produces feast-and-famine cycles.
- 03
If your interviews keep producing the same insight, you're either talking to the same persona or asking the same questions. Rotate both. Torres recommends touching 3 different segments in any 4-week window.
Myth vs Reality
Myth
“Discovery is a UX research function”
Reality
Discovery is a triad function: PM owns value/viability, designer owns usability, engineer owns feasibility. Outsourcing discovery to a research team produces shelfware reports nobody acts on. Cagan's data: teams where engineers attend customer interviews ship features adopted 2x more often than teams where engineers only see the spec.
Myth
“We don't have time for discovery — we need to ship”
Reality
Teams that skip discovery don't ship faster; they ship more code that gets thrown away. Pendo's 2019 study found 80% of features in B2B SaaS are rarely or never used. The 'shipping' was illusory — most of the work was waste. Discovery is how you stop building the wrong things at full speed.
Try it
Run the numbers.
Pressure-test the concept against your own knowledge — answer the challenge or try the live scenario.
Scenario Challenge
You're a PM at a 30-person SaaS company. Your CEO has approved a 12-week build of a new analytics dashboard based on three sales calls where prospects asked for 'better reporting.' The engineering team starts on Monday. You have one week.
Industry benchmarks
Is your number good?
Calibrate against real-world tiers. Use these ranges as targets — not absolutes.
Customer Interviews per PM per Week
B2B SaaS product triosContinuous Discovery (Torres standard)
1+ per week
Healthy
2-4 per month
Sporadic
1-2 per quarter
Feature Factory
0 — only at kickoff
Source: Product Talk / Continuous Discovery Habits research
Real-world cases
Companies that lived this.
Verified narratives with the numbers that prove (or break) the concept.
SVPG (Marty Cagan)
2008-present
Marty Cagan codified product discovery in Inspired (2008, revised 2017) based on observing how Google, Apple, Amazon, and Netflix actually built products. His core finding: the best product teams don't get a roadmap of features from the business; they get a set of business problems and the autonomy to discover the right solution. Cagan estimates that for every 10 ideas tested in discovery, only 1-2 actually move the metric they were designed to move — meaning teams that skip discovery are wrong 80% of the time.
Ideas Tested → Ideas That Work
~10:1 to 5:1
Top Teams' Discovery:Delivery Split
~50:50 of PM time
Inspired Copies Sold
200K+
Common SVPG Coaching Lift
2-3x feature adoption
If 8 out of 10 untested ideas don't work, then a team shipping every idea on its roadmap is producing 80% waste. Discovery is the cheap filter that prevents the expensive build.
Teresa Torres / Product Talk
2017-present
Teresa Torres' Continuous Discovery Habits (2021) formalized the weekly cadence: every product trio runs at least one customer interview per week, mapped to a specific desired outcome on an Opportunity Solution Tree. The framework shifted discovery from a quarterly research project to an always-on team habit. Teams Torres coaches typically take 6-12 weeks to install the cadence; once installed, they report 30-50% reductions in features that fail post-launch.
Minimum Cadence
1 interview/week per trio
Common Adoption Lift
30-50%
Time to Habit
6-12 weeks
Trio Definition
PM + Designer + Engineer
Discovery isn't a project — it's a weekly habit. The teams that win install a cadence so reliable that 'we haven't talked to customers this week' feels as wrong as 'we haven't deployed this week.'
Decision scenario
The Roadmap You Inherited
You're a new Head of Product at a Series B SaaS. The team has a 9-feature roadmap committed to the board for the next 2 quarters. Engineering capacity is fully booked. The roadmap was built from sales asks 4 months ago, with no customer interviews. The CEO expects you to 'execute, not re-plan.'
Roadmap Items Committed
9 features / 2 quarters
Customer Interviews in Past Quarter
0
Avg Feature Adoption (last year)
12%
Engineering Capacity
100% allocated
Decision 1
You have 4 weeks before the next board update. The team wants direction. You can either start delivering on the inherited roadmap or carve out time for discovery on the items still 8+ weeks from build.
Execute the roadmap as committed — re-planning so early would damage credibility with the board and the teamReveal
Keep delivery moving on the next 2-3 items, but install a weekly discovery cadence on items 4-9 — re-scope or kill any that fail discovery✓ OptimalReveal
Related concepts
Keep connecting.
The concepts that orbit this one — each one sharpens the others.
Beyond the concept
Turn Product Discovery Process into a live operating decision.
Use this concept as the framing layer, then move into a diagnostic if it maps directly to a current bottleneck.
Typical response time: 24h · No retainer required
Turn Product Discovery Process into a live operating decision.
Use Product Discovery Process as the framing layer, then move into diagnostics or advisory if this maps directly to a current business bottleneck.