Sign inGet started
Skills / Product-management

Continuous Discovery

The best discovery teams have at least one touch point with a customer every week. Not one person on the team — the team. It has to be a team sport.

Continuous Discovery is Teresa Torres' prescriptive framework for embedding ongoing customer research into the daily rhythm of product teams. Rather than episodic research sprints, the methodology builds a weekly cadence of story-based customer interviews whose findings are organized into an Opportunity Solution Tree — a structured visual that connects business outcomes to customer opportunities, candidate solutions, and assumption tests. Designed for product trios (PM, designer, engineer), it replaces guesswork-driven roadmaps with a repeatable habit of evidence-grounded product decisions.

By Teresa Torres · Free
Specimen 01 · Live diagnosisContinuous Discovery
Input

“We're trying to improve week-4 retention for new users. It's sitting at 32% and we need to get it to 45%.”

Diagnosis
Let's build out your Opportunity Solution Tree.
Full transcript ↓
Calibrated referenceagent-skills.ai
The gap

Interview customers every week, map what they actually need, and only build what the evidence supports

The Continuous Discovery framework is organized around the Opportunity Solution Tree (OST), a four-layer visual artifact: a single desired outcome at the top, an opportunity space of customer needs, pain points, and desires discovered through weekly story-based interviews, candidate solutions mapped to specific opportunities, and experiments designed to test the riskiest assumptions before any code is written. The team conducts at least one customer interview per week — asking customers to recount specific past experiences rather than share opinions or preferences — and uses those findings to continuously update and prioritize the opportunity space. Assumption mapping categorizes each solution's risks as desirability, viability, or feasibility assumptions, and the smallest viable experiment is designed to de-risk the most critical one first. Discovery is a joint responsibility of the product trio (PM, designer, and engineer), not delegated to researchers alone.

The problem

Most product teams do discovery episodically — a user research sprint before a big initiative, a round of interviews when something goes wrong — which means build decisions are made on stale, sparse, or biased evidence. When teams do interview customers, they ask opinion and preference questions ('Would you use this?' / 'How important is X?') that produce unreliable answers instead of the rich experience data that reveals real opportunities. The result: roadmaps full of solutions that address imagined problems rather than mapped customer needs.

The solution

Work through the Continuous Discovery framework to build an Opportunity Solution Tree for your current product area — starting from a clear desired outcome, surfacing real customer opportunities from interview data, and designing experiments that test your riskiest assumptions before you commit to building anything.

You bring
  • A product or feature area you are currently working on
  • A desired outcome or business goal you are trying to move
  • Raw customer interview notes, feedback, or observations if you have them
  • A solution idea or hypothesis you want to pressure-test
You get
  • A structured Opportunity Solution Tree with outcome, opportunities, solutions, and experiments mapped out
  • A story-based interview guide with questions rewritten from opinion-seeking to experience-eliciting
  • A prioritized opportunity list framed from the customer's perspective, using compare-and-contrast evaluation
  • An assumption map for a candidate solution — categorized by desirability, viability, and feasibility — with a minimum viable experiment designed for the riskiest assumption
In action

Watch the methodology work.

Three specimens from a single real session: the same situation, unaided and calibrated, the full transcript, and the skill answering live in the channel where the work happens.

Fig.01The same situation, two ways
Specimens A · B
Specimen AVague
Unaided

“Your team has a vague sense that users are churning because onboarding is confusing. You have a backlog full of competing solution ideas — a new onboarding flow, better tooltips, an email sequence, an in-app checklist — with no shared view of which customer problem each one is solving. The roadmap was built from stakeholder intuition and a handful of NPS comments, not a mapped opportunity space. The last two features you shipped didn't move retention, and you're about to plan the next sprint with the same process.”

×Vague — nothing concrete to act on.
Specimen BCalibrated
With Continuous Discovery

“Your product trio runs one 30-minute customer interview every Tuesday. Your Opportunity Solution Tree shows week-4 retention as the outcome, four distinct customer opportunities mapped from six weeks of story-based interviews, and three solution candidates each attached to a specific opportunity node. You ran a two-day experiment to test the riskiest assumption behind the top-priority solution — and got a clear disconfirming signal before writing a line of production code. Your team pivoted to a different solution with the evidence to explain why.”

Specific, grounded, and ends with one clear next step.
Fig.02A real session, unedited
In-app · assistant
Continuous DiscoveryClaude
Continuous Discovery
Let's build out your Opportunity Solution Tree. To start, I need your team's desired outcome — not a feature or a project name, but a measurable result you're trying to move. It should be something you can read off a dashboard: an activation rate, a retention metric, a revenue number. What outcome is your team accountable for right now?
We're trying to improve week-4 retention for new users. It's sitting at 32% and we need to get it to 45%.
Good — that's a clean desired outcome. Week-4 retention at 45% goes at the top of your OST. Now let's populate the opportunity space beneath it. The opportunities on your tree should be customer needs, pain points, or desires that — if addressed — would plausibly move that retention number. These must be framed from the customer's perspective, not as features. For example: 'Users don't know what to do after initial setup' is an opportunity. 'Add onboarding tooltips' is a solution — it doesn't belong in the opportunity layer. Have you done any customer interviews recently? Tell me what you heard and I'll help you extract real opportunities from it.
We've done a few interviews. Users keep saying they feel lost after the initial setup — they complete onboarding but then don't know what to do next. Some said they forgot why they signed up in the first place.
Two distinct opportunities are emerging here. Let me name them in customer-framing: (1) 'After setup, users have no clear path to their first meaningful outcome' and (2) 'Users lose sight of the original goal that motivated sign-up.' These are different needs — the first is about orientation and next steps, the second is about motivation and reconnection to intent. Before we map these to the tree, though: did your interviews include story-based questions like 'Tell me about the last time you logged in after onboarding and weren't sure what to do?' — or were they more like 'How often do you feel lost after onboarding?' The story-based version gives you evidence you can trust; the opinion version gives you noise.
Honestly, we asked things like 'Do you ever feel confused after onboarding?' That's probably the opinion version.
'Do you ever feel confused?' invites a yes/no that tells you almost nothing about what's actually happening. Here's how to convert that to story-based: 'Walk me through what happened the last time you logged into [product] after your first week.' Or: 'Tell me about a time you opened the app and weren't sure what to do next — what did you actually do?' These prompts surface the specific context, workarounds, and friction points of the real experience. The opportunity you map from a story is far more reliable than one mapped from a self-reported rating. Want me to build out a full story-based interview guide targeting week-4 drop-off so you're ready for your next customer call?
Yes. Also — we already have one solution idea: an in-app 'What to do next' checklist for new users. Should I put that on the tree?
Yes, but attach it to the right opportunity node. A 'What to do next' checklist addresses opportunity (1) — users lacking a clear path to first value — so map it beneath that branch, not floating at the top level. Now let's assumption-map it before anyone starts building. The checklist is betting on at least three things: desirability — that users will actually engage with a checklist rather than dismiss it the way most onboarding checklists get ignored; viability — that completing checklist items correlates with the specific actions that drive week-4 retention; and feasibility — that your team can build and instrument a personalized version in a reasonable sprint. Which of those feels riskiest to you right now?
Reply to Continuous Discovery
What the skill is doing
01Opportunity Solution Tree Builder
02Story-Based Interview Coach
03Opportunity Space Mapper
Fig.03The same skill, in the channel you already use
WhatsApp · live
9:41
CDContinuous Discoverytyping…
Messages are end-to-end encrypted. No one outside of this chat can read them.
Today
We're trying to improve week-4 retention for new users. It's sitting at 32% and we need to get it to 45%.9:14✓✓
Let's build out your Opportunity Solution Tree.9:14
To start, I need your team's desired outcome — not a feature or a project name, but a measurable result you're trying to move.9:15
It should be something you can read off a dashboard: an activation rate, a retention metric, a revenue number.9:15
Message

The same skill, where the work happens.

No new app to learn. The methodology runs over the WhatsApp Business API, so the answer lands as a reply in the thread you’re already in — same rigour, zero context-switch.

Reads the situation, names the pattern, returns one concrete next move.
Delivered in seconds, inside a conversation that already exists.
Specimen · WhatsApp Business API · live
Capabilities

What it does, specifically.

Each capability is a distinct move drawn straight from the source methodology — not a generic assistant guessing.

CapabilityC-01

Opportunity Solution Tree Builder

Guides you layer by layer through constructing an Opportunity Solution Tree: first establishing a single, measurable desired outcome, then populating the opportunity space from customer interview findings, mapping candidate solutions to specific opportunities, and identifying the experiments needed at the leaf nodes. The result is a living artifact that makes your team's discovery logic explicit and auditable.

Based on Torres' OST framework, which structures discovery as a four-layer hierarchy — outcome, opportunity, solution, experiment — ensuring every solution traces back to a real customer need and every customer need traces back to a business goal.
CapabilityC-02

Story-Based Interview Coach

Converts the interview questions you're currently planning to ask into story-based, experience-eliciting questions that produce richer, more reliable insights. Reviews your draft guide for opinion-seeking or hypothetical questions and rewrites each into a prompt that asks customers to recount a specific past experience, then shows you how to follow the story with structured probing questions.

Based on Torres' story-based interviewing technique, which holds that customers cannot reliably predict future behavior but can accurately describe past experiences — making 'Tell me about the last time...' a far more reliable signal than 'Would you use a feature that...?'
CapabilityC-03

Opportunity Space Mapper

Takes raw customer interview notes or observations and helps you cluster them into discrete opportunities — needs, pain points, and desires — framed from the customer's perspective rather than as solutions in disguise. Applies Torres' compare-and-contrast framing to help you evaluate which sub-opportunity in your tree deserves focus next.

Implements Torres' distinction between the opportunity space (what customers need) and the solution space (what your team might build), and her compare-and-contrast prioritization method that avoids the false precision of numerical scoring.
CapabilityC-04

Assumption Excavator

For any solution idea you're considering, surfaces the hidden assumptions it depends on and categorizes each as a desirability assumption (do customers want this?), viability assumption (does this work for our business?), or feasibility assumption (can we build it?). Ranks assumptions by risk so you know which to test first before investing in delivery.

Based on Torres' assumption mapping practice, which distinguishes three categories of assumption risk and pairs each with appropriate experiment types — explicitly separating assumption testing from usability testing.
CapabilityC-05

Minimum Viable Experiment Designer

Designs the smallest possible test that would meaningfully reduce uncertainty about your riskiest assumption before you write production code. Outputs a concrete experiment definition: the assumption being tested, the method (prototype, fake door, concierge, data query, etc.), the success metric, and the decision rule for what you'll do if the test passes or fails.

Applies Torres' principle that experiments should be designed to de-risk specific assumptions — not to validate the overall solution — using the cheapest method that produces sufficient evidence for the decision at hand.
Tested

Graded before it shipped.

Every skill is scored against independent scenarios for methodology fidelity before it goes live — not vibes, a rubric.

What it produces
OutputD-01

Opportunity Solution Tree

A four-layer map connecting your team's desired outcome to the customer opportunity space, candidate solutions for each opportunity, and experiments at the leaves. Makes the full logic of your discovery visible in one place — showing what you know, what you're betting on, and what you're still testing.

OutputD-02

Story-Based Interview Guide

A tailored interview script built around experience-eliciting questions for your specific product context, with a warm-up sequence, main story prompts, and follow-up probes designed to surface the narrative customer data that populates your opportunity space.

OutputD-03

Assumption Map

A structured breakdown of every assumption your candidate solution depends on, sorted into desirability, viability, and feasibility buckets and ranked by risk — with a recommended experiment type for each high-priority assumption.

OutputD-04

Experiment Brief

A one-page definition for a single assumption test: the assumption being challenged, the experiment method, the metric, the timeline, and the explicit decision rule — so your team agrees in advance what the test result means before you run it.

The source

Grounded in the original work.

Every answer traces back to a real source and the practitioner who wrote it — not a secondhand summary. Here is the source of record.

Source authorA-01

Teresa Torres

Teresa Torres is a product discovery coach and the author of Continuous Discovery Habits (2021), the defining text on embedding customer research into modern product practice. She founded Product Talk Academy, a structured online training program for product teams, and writes at producttalk.org — one of the most widely read resources in the product management community. Her Opportunity Solution Tree framework and story-based interviewing techniques have been adopted by product teams at technology companies across the industry.

Status · Inspired by Teresa Torres’s work — not yet claimed. Are you Teresa Torres?
Primary sourceS-01

Continuous Discovery Habits (2021)

by Teresa Torres

Author of Continuous Discovery Habits (2021); founder of Product Talk Academy; product discovery coach; creator of the Opportunity Solution Tree framework.

Read the original ↗
Citationproducttalk.org
In the build queue

Be first to run it.

Continuous Discovery is being built right now. Leave your email and we’ll tell you the moment it goes live.

Notify meEmail
At launchI want to build an Opportunity Solution Tree for my product area. We're trying to improve trial-to-paid conversion and I have some notes from customer interviews last month. Can we start by setting the desired outcome and then map the opportunity space from what I heard?