The Opportunity Solution Tree: A 2026 Guide for Continuous Discovery

14 min read

The Opportunity Solution Tree: A 2026 Guide for Continuous Discovery

TL;DR

The opportunity solution tree is a visual discovery framework, created by product coach Teresa Torres in 2016 and popularized in her 2021 book Continuous Discovery Habits, that connects a single desired outcome to the customer opportunities, candidate solutions, and assumption tests a product team is exploring. The tree has four layers: the desired outcome at the top, opportunities (unmet customer needs, pain points, and desires) branching beneath it, solutions mapped to each opportunity, and experiments that test the riskiest assumptions. Its purpose is to make product decisions a "compare and contrast" exercise instead of a "whether or not" debate, keeping teams outcome-focused rather than output-focused. The opportunity layer is only as good as the customer conversations that feed it — and that is where most trees stall, because teams treat discovery as a one-time phase rather than a weekly habit. Torres' minimum bar for continuous discovery is at least one customer touchpoint per week by the team building the product. This 2026 guide explains how to build a tree layer by layer, the mistakes that flatten it into a feature list, and how always-on AI customer interviews keep the opportunity space fresh.

What Is an Opportunity Solution Tree?

An opportunity solution tree is a visual map that links one measurable desired outcome to the customer opportunities, possible solutions, and assumption tests a product team is considering, so the team can see the full decision space at a glance. Teresa Torres introduced the framework in 2016 and detailed it in Continuous Discovery Habits (2021), where it functions as the central artifact of continuous discovery — the practice of weekly customer touchpoints in pursuit of a product outcome.

The tree is read top to bottom. At the top sits the desired outcome: a single business or product metric the team is trying to move. Below it branch opportunities — unmet needs, pain points, and desires expressed by real customers, phrased in their language, never as features in disguise. Under each opportunity hang solutions that could address it. And under the most promising solutions sit assumption tests: small experiments that check whether the solution will actually create the value you expect before you commit engineering time.

What makes the framework durable is not the diagram — it is the discipline it enforces. By forcing every solution to attach to a mapped customer opportunity, the tree blocks the most common failure mode in product work: building things nobody needs. According to Pendo's Feature Adoption Report, roughly 80% of product features are rarely or never used, and Microsoft research on its own experimentation platform found that only about one-third of ideas tested actually improved the metrics they were designed to improve. The opportunity solution tree exists to shrink that waste by anchoring delivery to validated need. If you want the broader context for how this fits the modern stack, see the continuous discovery stack for AI-first product teams.

Why the Opportunity Solution Tree Matters in 2026

The opportunity solution tree matters because it operationalizes outcome-oriented product work at a moment when the cost of building the wrong thing has never been more visible. Industry data has long shown that the majority of features fail to move the metrics they target, and that requirements problems are a leading driver of waste — the Project Management Institute's Pulse of the Profession research attributes a significant share of failed projects to poor requirements gathering and misaligned scope. The tree is cheap insurance against both.

Three shifts make it especially relevant now:

  • Roadmaps are moving from outputs to outcomes. Teams are being measured on whether a metric moved, not whether a feature shipped. The tree starts at the outcome by design, which is why it has outlasted most planning fads. The death of the roadmap council in favor of continuous discovery is the organizational version of this shift.
  • Discovery has gone continuous. The annual research project is being replaced by always-on listening. Our 2026 continuous discovery report on always-on research found teams are running research as a weekly cadence rather than a quarterly event.
  • The opportunity space is now the bottleneck. Most teams can brainstorm solutions all day. What they lack is a steady stream of well-articulated customer opportunities — which only comes from talking to customers constantly. The 2026 product discovery trends from 300 teams show the same pattern: the constraint has moved from "what should we build" to "do we actually understand the problem."

This is the gap Perspective AI is built to close. The tree is only as good as its opportunity layer, and the opportunity layer is only as good as your conversation volume.

The Four Layers of the Tree

The opportunity solution tree has four layers, each answering a different question: the outcome answers "what are we trying to move," opportunities answer "whose problem are we solving," solutions answer "how might we solve it," and assumption tests answer "is this true before we build it." Below is a summary table, then a walk-through of each.

LayerQuestion it answersSource of truthCommon failure
Desired outcomeWhat metric are we moving?Strategy + business goalsVague or output-shaped ("ship feature X")
OpportunitiesWhose unmet need are we solving?Customer interviewsFeatures disguised as needs
SolutionsHow might we address it?Cross-functional ideationBrainstormed before opportunities exist
Assumption testsIs this solution true before we build?Small experimentsSkipped; team builds on faith

Layer 1: The Desired Outcome

The desired outcome is a single, specific, measurable metric the team commits to moving — and it belongs at the top of the tree as its trunk. Torres' guidance is to narrow to one outcome so it reads almost like a Key Result: "increase the percentage of new users who complete onboarding in week one," not "improve onboarding." A good outcome is a product outcome (customer behavior the team can influence), not a business outcome like revenue that is too far downstream to act on. One tree, one outcome — if your team has three outcomes, you have three trees.

Layer 2: Opportunities

Opportunities are unmet customer needs, pain points, and desires — phrased in the customer's own words — that, if addressed, would move the desired outcome. This is the layer that distinguishes the framework from every roadmap tool, and it is the layer teams get most wrong. An opportunity is "I never know if my teammates saw my message," not "add read receipts." The second is a solution wearing an opportunity's clothes.

Opportunities come from one place: customer conversations. You surface them by interviewing customers about specific, recent, concrete experiences — the Mom Test approach to customer discovery questions keeps those interviews honest — then group and nest them into a hierarchy and prioritize which branch to pursue. This is where AI-moderated interviews earn their place: surfacing a rich opportunity space requires volume and follow-up, probing every "it depends" until the real need surfaces, and the jobs-to-be-done interview guide for product teams shows how that structured questioning maps onto the opportunity layer.

Layer 3: Solutions

Solutions are the candidate ideas — features, flows, content, or process changes — that could address a specific mapped opportunity, and each one must attach to exactly one opportunity. The rule is non-negotiable: a solution that does not link to an opportunity is, in Torres' framing, a distraction. This turns product debates from "should we build this or not" into "which of these three solutions best addresses this opportunity." Solutions are also the right place to involve the full product trio — product manager, designer, and engineer — generating several competing options per opportunity rather than committing to one too early.

Layer 4: Assumption Tests

Assumption tests are small, fast experiments that validate the riskiest assumptions underneath a solution before the team invests in building it. Every solution rests on assumptions — that customers want it, can use it, will value it, and that it is feasible. The tree makes you list those assumptions explicitly (a step impact mapping leaves implicit) and test the riskiest ones first with the lightest possible experiment: a prototype, a fake-door test, a concierge test, or a few targeted interviews.

This layer is what keeps the tree honest end to end. For a deeper treatment of testing solution assumptions against real customer evidence, see how AI conversations replaced the discovery call.

How to Build an Opportunity Solution Tree: A 5-Step Process

You build an opportunity solution tree by starting at the outcome and working down, never the other way around. Here is the step-by-step process.

Step 1: Define one measurable outcome. Pick a single product outcome you can influence and measure. Why it matters: one trunk keeps every downstream branch accountable to the same goal. Common mistake: choosing an output ("launch the new dashboard") instead of an outcome ("increase weekly active users of reporting").

Step 2: Interview customers and capture opportunities. Run regular interviews and extract unmet needs in the customer's words. Why it matters: the opportunity space is the entire foundation; a thin one produces a thin tree. Pro tip: tag each opportunity with the interview it came from so you can trace it back. Common mistake: doing ten interviews up front and never returning — the single most common reason trees go stale.

Step 3: Structure the opportunity space. Group related opportunities, nest sub-needs under parent needs, and prioritize the branch most likely to move the outcome. Why it matters: an unsorted pile of needs is not a tree. Common mistake: prioritizing by gut instead of by impact-on-outcome.

Step 4: Generate solutions for the target opportunity. With the trio, brainstorm three or more solutions for the single opportunity you chose. Why it matters: comparing solutions beats defending one. Common mistake: attaching a beloved pet feature to an opportunity it does not actually serve.

Step 5: Test assumptions before building. List each solution's assumptions, rank by risk, and run the smallest experiment that could falsify the riskiest one. Why it matters: this is where you avoid shipping into the 80% of features that go unused. Common mistake: skipping straight to delivery because the solution "feels obvious."

The tree is never finished. As always-on customer discovery without hiring a research team becomes the norm, the tree becomes a living document you revisit weekly, not a deliverable you present once.

Common Mistakes That Flatten the Tree

The most common mistake is treating discovery as a phase rather than a habit, which starves the opportunity layer and quietly turns the tree into a prioritized feature list. Torres' work and practitioner reports converge on a short list of anti-patterns:

  • Front-loading discovery. Running a burst of interviews at project kickoff and then never talking to customers again. Continuous discovery means at minimum weekly touchpoints by the team building the product.
  • Solutions masquerading as opportunities. Putting "add a filter" in the opportunity layer instead of the underlying need ("I can't find the records that matter to me"). If your opportunities are features, you have a roadmap, not a tree.
  • One person owning all the conversations. When a single researcher recruits and runs every interview, the trio loses shared context and the tree becomes one person's interpretation.
  • Sharing raw notes instead of synthesis. Sending teammates pages of transcripts rather than structured opportunities defeats the alignment purpose of the framework; moving from gut instinct to systematic discovery is the modern fix.
  • The week-twelve stall. Practitioner data shows most teams that attempt continuous discovery stall around week twelve — not from lack of will, but from infrastructure: recruitment that takes weeks, manual analysis that piles up, and no central home for findings. It is an operational problem, not a motivation problem.

Feeding the Tree with Continuous Conversations

The opportunity layer stays fresh only when customer conversations are continuous, high-volume, and synthesized fast — and that is exactly the bottleneck that kills most trees. Manual interviewing caps a team at a handful of conversations per week until the opportunity space goes stale.

Perspective AI removes that bottleneck by running AI-moderated customer interviews at scale. Instead of one researcher fitting in three calls a week, an AI interviewer agent can hold hundreds of conversations simultaneously, following up on vague answers and probing the "why" behind each pain point — the exact behavior the opportunity layer depends on. Transcripts are analyzed automatically and surfaced as structured themes you can drop straight into opportunity branches, addressing both the synthesis bottleneck and the week-twelve stall. Built for product teams, it turns "we should talk to customers more" into a weekly habit that holds.

Teams replacing static research with conversational methods — documented in our tactical migration guide for replacing surveys with AI — report that the constant inflow of opportunities is what finally makes continuous discovery stick. For the wider category shift, see how AI conversations are replacing surveys and scripts in product discovery and the 2026 state of AI customer discovery tools across 500 product teams.

Frequently Asked Questions

Who created the opportunity solution tree?

Teresa Torres, a product discovery coach and author, created the opportunity solution tree in 2016 and detailed it in her 2021 book Continuous Discovery Habits. She developed it as the central visual artifact of continuous discovery, her framework for weekly customer touchpoints aimed at a product outcome. The framework is widely taught through her company, Product Talk, and has become a standard tool in modern product management.

What is the difference between an opportunity and a solution?

An opportunity is an unmet customer need, pain point, or desire expressed in the customer's own words, while a solution is a specific idea you might build to address that need. "I can never tell which version of the file is current" is an opportunity; "add version history" is a solution. The core rule of the framework is that every solution must attach to a mapped opportunity, which prevents teams from building features that solve no real problem.

How is an opportunity solution tree different from impact mapping?

An opportunity solution tree is more tactical and customer-problem-focused, while impact mapping is higher-level and organization-focused. Both start with a desired outcome, but impact maps identify actors and the impacts you want them to have, whereas opportunity solution trees break the outcome into prioritized customer opportunities and explore multiple solutions per opportunity. The tree also lists solution assumptions and tests explicitly, while impact mapping leaves those assumptions implicit.

How often should you update an opportunity solution tree?

You should update an opportunity solution tree continuously, ideally every week, as new customer conversations surface new opportunities and experiments validate or kill solutions. Teresa Torres' minimum bar for continuous discovery is at least one customer touchpoint per week by the team building the product. Treating the tree as a one-time deliverable is the most common reason it decays into a static feature list within a few months.

Do you need special software to build an opportunity solution tree?

You do not need special software to build an opportunity solution tree — a whiteboard or any diagramming tool works for the visual itself. The real tooling need is upstream: a reliable, high-volume source of customer conversations and fast synthesis to keep the opportunity layer fresh. Most trees fail from a thin opportunity space, not a bad diagram, so tools like Perspective AI that feed the interviews and analysis matter far more than the diagramming surface.

Conclusion

The opportunity solution tree, created by Teresa Torres, remains the clearest way to keep a product team anchored to outcomes instead of outputs: one measurable outcome at the top, customer opportunities beneath it, competing solutions under each opportunity, and assumption tests that catch bad bets before they reach engineering. The framework's logic is sound, but its power depends entirely on the opportunity layer — and that layer goes stale the moment customer conversations stop. The teams that succeed with the tree in 2026 make discovery a weekly habit rather than a kickoff phase, and solve the synthesis and recruitment bottlenecks that stall most teams by week twelve.

If your opportunity solution tree keeps drying out between planning cycles, the fix is not a better diagram — it is a steady inflow of real customer voice. Start a continuous discovery study with Perspective AI and keep your tree rooted in what customers actually need.

More articles on Product Discovery & UX Research