🔁Continuous Discovery — Advanced
Teresa Torres's full playbook. The discipline that separates 'we did some user research' from a real discovery practice.
Most teams do discovery sporadically. The teams that do it continuously ship dramatically better products and have much higher hit rates on bets. The discipline is hard to build but compounds for years.
Continuous discovery is the practice of touching customers weekly, structured through an Opportunity Solution Tree, with rigorous assumption testing. The output is a constantly-updated map of customer opportunities and the team's confidence in the solutions for each.
The Teresa Torres core practices
Weekly customer touchpoints. Not 'when we have time.' Every week, every team member talks to at least one customer. Non-negotiable.
The Opportunity Solution Tree. A visual map: business outcome at top, customer opportunities below, candidate solutions for each, and the tests/experiments validating each solution. Updated weekly.
Assumption mapping. For every solution, list the assumptions that must be true. Identify the riskiest. Design the cheapest test that would invalidate it.
Test before build. No solution moves to engineering without at least one assumption-validating test.
Setting up the practice
Week 1: meet with team, commit to weekly interviews and the OST as the team's central artifact. Week 2-4: schedule recurring interview slots (3-5 per week per PM/designer/researcher). Build the OST v0. Month 2: synthesize opportunities, start identifying solution candidates and assumption tests. Month 3-onward: ongoing rhythm — interviews, OST updates, assumption tests in flight.
Common failure modes
- Stopping after a month. Teams that don't establish a real rhythm by month 3 collapse back to ad-hoc research.
- Treating OST as a document, not a tool. It should be referenced in every prioritization conversation.
- Skipping assumption tests. Going straight from opportunity to building is the failure mode discovery is supposed to prevent.
- PM doing it alone. The whole trio (PM + design + engineer) should participate. Otherwise insights get lost in translation.
The metrics that prove discovery is working
- Hit rate. % of shipped features that achieve their hypothesized impact. Without discovery, ~30%. With discipline, 60-70%.
- Time-to-kill. How long it takes the team to abandon a bad idea. Should drop from quarters to weeks.
- Customer touch frequency. PM minutes per week in customer conversations.
Tools and rhythm
- Dovetail / Enterpret for interview repos.
- Notion or Mural for OST visualization.
- Calendly for self-scheduled customer interviews — power move that removes coordination overhead.
Senior-leader implementation
The hardest part is leadership patience. Discovery feels 'slow' in month 1-2. Hit rate doesn't move until month 4-6. Leaders accustomed to 'just ship it' often kill the practice before it can prove itself. Pre-sell the timeline.
Key frameworks
Outcome → Opportunities → Solutions → Tests. The central artifact of continuous discovery.
For each solution, list assumptions, prioritize by risk, design tests for the riskiest.
Real-world examples
Productboard's PM team treats continuous discovery as the operating system. Customer interviews are scheduled weekly, the OST is on every wall, and roadmap conversations always reference the tree. The discipline is part of why Productboard has shipped at the pace it has.
Go deeper — recommended reading
Interview questions (1)
Q1How would you build a continuous discovery practice from scratch in a team that's never done it?leadershipsenior▼
Six-step rollout over 3-4 months:
- Get leadership buy-in. Pre-sell the 3-6 month payoff. Without this, the practice dies in month 2.
- Pick one team to start. Don't roll out org-wide on day 1. Prove it in one team first.
- Set the weekly cadence. Every member of the trio (PM, designer, EM) commits to one customer interview per week. Calendly-driven self-scheduling.
- Build the OST. Whiteboard or Notion. Outcome at top, opportunities below, candidate solutions, tests. Update weekly.
- Run assumption tests on the riskiest items. No solution goes to build without validating the riskiest assumption.
- Measure hit rate. Track % of shipped features that achieve hypothesized impact. After 6 months, you'll have data showing the practice works.
Once the pilot team has a 6-month track record of better hit rate, roll out to other teams. Don't roll out by mandate — let the success story sell itself.