Continuous Discovery (Opportunity Solution Trees)

Key takeaways

Continuous discovery replaces periodic research projects with a weekly trio habit — at least one customer touchpoint per week, attended by the PM, designer, and engineer together, so that customer evidence updates decision-making directly rather than through a handoff document.
The Opportunity Solution Tree externalizes the team's current understanding as four connected layers: one specific measurable outcome, the customer opportunities that support it, candidate solutions, and experiments that test the riskiest assumption behind each solution.
Framing opportunities in customer language — not solution language — is the discipline that keeps the solution space open and prevents premature convergence on the first idea the team generates.
Every solution should be preceded by the smallest experiment that can validate its core assumption; this is the mechanism that connects discovery to delivery without requiring the team to build before they learn.
The most common program failure is the trio fracturing: when only the PM attends interviews and shares summaries, the shared customer mental model that drives good decisions dissolves within weeks.

The full lesson

Most product teams treat discovery as an event: a research sprint each quarter, a round of interviews before a big redesign, a usability study after engineering commits to a spec. This creates a predictable gap. Decisions made between studies rely on gut instinct and whoever shouts loudest. By the time research surfaces problems, the team is already mid-build.

Continuous discovery — popularized by Teresa Torres — reframes discovery as a weekly team habit, not a project phase. Paired with an Opportunity Solution Tree (OST) as a living visual map, it connects customer evidence directly to business outcomes and the solutions the team is betting on.

What Continuous Discovery Actually Means

“Continuous” does not mean endless research for its own sake. It means the product trio — typically a product manager, a designer, and a software engineer — runs at least one touchpoint with a real customer every week. A touchpoint can be a short interview, a usability session, a contextual inquiry, or a recorded session review.

The critical rule: the trio attends together, not through a handoff. When the people making product decisions hear customers speak in their own words, they update their mental model directly. No synthesis document gets in the way.

This is a break from the research-as-handoff model, where a researcher delivers a report that gets half-read, selectively quoted, and quietly forgotten. Continuous discovery trades some methodological rigor for much higher absorption of customer evidence across the whole team.

The Opportunity Solution Tree: Structure and Purpose

The Opportunity Solution Tree (OST) is a visual map that externalizes what the team currently understands about the problem space, and how that connects to solutions and experiments. It has four layers.

Outcome (root). A specific, measurable change in customer behavior the team is pursuing right now — not a feature, not an output, but an outcome. Example: “Increase the percentage of new users who complete their first transaction within seven days.” This is the team’s North Star for the current cycle. It should tie to a real business or product metric.
Opportunities (branches). Customer needs, pain points, and desires that, if addressed, would move the outcome. Write these in customer language, not solution language. “Users don’t know whether their submission was received” is an opportunity. “Add a confirmation email” is a solution. That distinction is load-bearing — more on it below.
Solutions (leaves). The specific interventions the team is considering for each opportunity. One opportunity can have multiple candidate solutions. Solutions are hypotheses at this stage, not commitments.
Experiments (attached to solutions). The smallest possible test the team can run to validate or invalidate the key assumption behind each solution. An experiment is not a prototype of the full feature; it is a targeted probe of the riskiest assumption.

The tree is built incrementally. It is never “done.” Each customer touchpoint adds, refines, or removes nodes. The tree is a shared decision-making artifact — always current because you update it continuously.

Why the Opportunity Layer Is the Most Valuable

Most teams jump straight from outcome to solution. “We want to improve activation — let’s add an onboarding checklist.” The opportunity layer forces a better question: what is the specific customer problem that an onboarding checklist would solve?

Naming the opportunity does two things. First, it opens the solution space. If the opportunity is “users don’t know what to do when they first land in the product,” an onboarding checklist is one solution — but so is a contextual coach mark, a first-run video, or a more self-evident default state. Second, it creates a falsifiable hypothesis. If you deploy a solution and the opportunity disappears (confirmed by research or behavioral metrics), you have real evidence of causality.

Frame every opportunity from the customer’s perspective — their pain, need, or desire, not the team’s internal problem.
Keep the outcome specific and measurable so you know when the cycle is complete; vague outcomes produce unfocused, endless discovery.
Update the tree after every customer touchpoint, not only at sprint end.
Involve the whole product trio in both interviews and tree updates — shared exposure to customer evidence is most of the value.
Scope the tree to one outcome at a time so the team makes real prioritization decisions rather than collecting every possible opportunity.

Don't

Don’t use solution language in the opportunity layer. “Users need a dashboard” is a solution. “Users can’t tell at a glance whether their account is healthy” is an opportunity.
Don’t treat the tree as a research deliverable to hand off. It is a decision-making tool owned by the full trio.
Don’t skip the experiment layer. Committing to build a solution without testing its riskiest assumption is exactly the failure mode continuous discovery is designed to prevent.
Don’t attach a solution to an opportunity you’ve heard from only one customer. Validate the opportunity across at least three to five touchpoints before investing in solutions.
Don’t conflate opportunities with backlog items. An opportunity is a customer truth, not a unit of work.

Running the Weekly Touchpoints

Interviews in a continuous discovery cadence are shorter and more focused than a traditional generative research study. They typically run 20 to 30 minutes. The goal is not to map the entire user experience. It is to answer specific questions about the current opportunity space while staying open to new ones.

Effective touchpoints follow a loose structure:

Warm-up (3–5 min). Brief context-setting: what does the participant do, and how does the product fit into their work?
Story elicitation (10–15 min). Ask the participant to walk through a recent, specific experience related to the outcome you’re pursuing. Specific past stories are more reliable than opinions or hypotheticals. “Tell me about the last time you tried to complete a transaction and something didn’t go as expected” gives better data than “How would you feel if we changed the checkout flow?”
Opportunity probing (5–10 min). When the participant mentions friction, confusion, or workarounds, dig in. These are signals of unmet needs. “You mentioned you opened a spreadsheet to track that — tell me more about why the product wasn’t enough.”
Assumption testing (optional, 5 min). Once the team has candidate solutions and experiments, a touchpoint can include a quick concept test or assumption probe. “We’re considering X — what would that mean for the way you currently do Y?”

This cadence demands continuous participant recruitment. The modern solution is a standing panel: an opt-in pool of customers who’ve agreed to participate in research, maintained in a research repository or CRM. This turns the per-study recruiting scramble into an ongoing operational investment that pays off over time.

Opportunity Sizing and Prioritization

As the tree grows, it will have more opportunities than the team can pursue. To prioritize, you need two inputs: how many customers experience this opportunity (prevalence) and how much it affects the outcome you care about (severity).

A practical prioritization heuristic combines three factors:

Factor	Question to ask	Evidence source
Prevalence	How many customers in the target segment experience this?	Interview count, behavioral analytics
Outcome relevance	How directly does this opportunity affect the current outcome?	Team judgment, correlated behavioral data
Addressability	Can we plausibly address this with solutions in our control?	Engineering and design feasibility

A common mistake is defaulting to the loudest voice: the opportunity mentioned most in the last two weeks, or the one raised by a high-value customer. Frequency in recent interviews is a weak signal. Cross-validate with behavioral data — analytics, session recordings, support tickets — before committing an opportunity to active solution development.

This is the mixed-method discipline applied at the tree level: qualitative touchpoints reveal what the opportunities are and why they matter to real people; behavioral data confirms whether they are prevalent enough to be worth pursuing.

Connecting Discovery to Delivery

One of the most common failure modes is that discovery runs in parallel to — but disconnected from — actual delivery. The tree fills up with opportunities and solutions, but the sprint backlog is driven by roadmap commitments made weeks earlier, before the current evidence existed.

The connection mechanism is the experiment. Before any solution moves into the development backlog, the team runs the smallest test that reveals whether the solution’s core assumption holds. The right experiment format depends on the type of assumption:

Assumption about whether the problem exists: A structured, story-based interview with targeted probing.
Assumption about whether customers want the solution: A concept test, a landing page, or a paper prototype with four to six customers.
Assumption about usability: A task-based usability test with five participants from the target segment.
Assumption about actual behavior change: An A/B test or a fake-door test, once the feature exists in at least skeletal form.

The experiment result feeds back into the tree. If the assumption holds, the solution moves toward development. If it doesn’t, the solution is deprioritized or revised — without spending engineering time building something customers won’t use. The tree keeps the team from mistaking “we built it” for “we solved the problem.”

Common Failure Modes

Continuous discovery programs fail in predictable ways. Spotting these patterns early prevents the program from quietly collapsing back into the quarterly-research model.

The trio fractures. The PM runs interviews alone and shares a Slack summary. The designer and engineer stop attending because “research isn’t my job.” Within a month, the shared customer empathy that makes the program work is gone. The fix: make attendance a team norm, not optional enrichment. If the trio can’t attend the same sessions, rotate so everyone leads at least occasionally.

Opportunities are too broad. “Users are confused by the product” is not addressable. It is a symptom. Keep probing until the opportunity is specific enough that a single solution could plausibly address it. “Users who land on the project list from a notification don’t have enough context to know which project needs their attention” is specific and addressable.

The tree becomes a museum. The tree grows large, nothing gets prioritized, and observations pile up without synthesis. Fix this with a weekly review ritual — not a formal meeting, but a standing 20-minute conversation after the week’s touchpoints where the trio updates the tree and names which one or two opportunities to advance next.

Research and delivery stay disconnected. Experiments get skipped because “we already know enough” or “there’s no time.” Treat experiment time as a standard sprint line item, not something that happens when bandwidth appears.

Metrics for the Program Itself

A continuous discovery program should be evaluated. The goal is not perpetual research activity; it is better product decisions. Useful program-level metrics:

Interview cadence: Did the trio complete at least one touchpoint per week? This is a leading indicator of program health.
Opportunity validation rate: Of opportunities added to the tree, what percentage were validated by at least three independent customer touchpoints before solutions were developed?
Experiment completion rate: Of solutions that reached active development, what percentage had at least one experiment run first?
Outcome movement: Is the specific measurable outcome the team defined actually moving? This is the ultimate test. If discovery is working, the team should be making better bets and the outcome should trend in the right direction.

These metrics surface operational problems early, before the program degrades into the quarterly research pattern it was designed to replace.