Opportunity Solution Trees: Visualize Product Decisions

An opportunity solution tree is a single diagram that connects one measurable business outcome to the customer opportunities that could move it, the solutions you're considering for each opportunity, and the experiments that test whether a solution actually works. It replaces a flat feature list with a structure that traces every idea back to evidence, instead of back to whoever argued for it loudest.

Quick Answer: An opportunity solution tree has four layers, read top to bottom: the outcome at the root, opportunities (unmet customer needs, pains, or desires) as the first branch, solutions (product ideas that address an opportunity) as the second branch, and experiments (the smallest test that reduces risk on a solution) as the leaves. Teresa Torres introduced the technique in Continuous Discovery Habits to keep every product decision traceable back to a specific piece of customer evidence.

Most teams don't actually lack ideas. What they lack is a way to see which idea is genuinely connected to the outcome they're chasing, and which one just sounded good in a meeting. An opportunity solution tree makes that connection visible on a single page, which is why it turns up as a recurring tool inside the startup validation toolkit for teams that have moved past the initial idea stage and into an ongoing rhythm of discovery.

How an Opportunity Solution Tree Works: The Four Layers

Read the tree from the root down: one outcome, several opportunities branching off it, several candidate solutions per opportunity worth considering, and several experiments per solution worth running before anyone commits to building it.

• Outcome (the root). A single, measurable, customer- or business-level metric you're trying to move — not a feature, and not an activity. "Increase the percentage of trial users who convert to paid within 14 days" is an outcome. "Add a better onboarding flow" is not, because it already presupposes a solution before the team has established what problem it's solving.
• Opportunities (the first branch). Unmet needs, pains, and desires surfaced directly from customer conversations — never brainstormed from a whiteboard in a conference room. Each opportunity is phrased from the customer's point of view ("I can't tell if this tool actually saved me time until the invoice shows up") rather than the team's point of view ("we need better analytics"). A healthy tree usually holds far more opportunities than any team could act on at once, and that's the point: the tree makes the backlog of unaddressed needs visible instead of letting it hide in one researcher's notebook.
• Solutions (the second branch). Concrete product ideas that could address a specific opportunity, positioned directly under the opportunity they respond to. A single opportunity can carry several candidate solutions at once — this layer is deliberately not where the team commits to a build. It's where options get generated before one gets chosen.
• Experiments (the leaves). The smallest test that produces real evidence about whether a solution actually resolves the opportunity underneath it, run before engineering time gets committed. This is where an assumption test, a prototype, a concierge stand-in, or a small-batch build happens — the mechanics of designing that test are the same ones that apply to any lean experiment.

Torres pairs the tree with a habit of continuous interviewing — talking to customers on a regular, ongoing cadence rather than in one research sprint before a planning offsite — so the opportunity layer keeps getting refreshed with new evidence instead of calcifying into an assumption made once and never revisited. A tree built from a single round of interviews and then left untouched for two quarters has already drifted from what customers actually need; the framework only holds its value if the top layer stays current.

A Concrete Example: Building a Tree From Real Discovery Notes

Here's how the four layers look once you build them from an actual round of customer interviews, using a hypothetical subscription meal-kit business as a worked example.

Outcome: Increase the percentage of new subscribers who are still active at day 60.

Synthesizing a batch of interview transcripts — the step covered in turning raw interview notes into prioritized product insights — surfaces three recurring opportunities, each one mentioned independently by multiple customers rather than volunteered by a single enthusiastic outlier:

• Subscribers forget to pause deliveries before travel and end up wasting a box.
• Subscribers can't tell whether tonight's recipe will realistically take 20 minutes or 50 until they're already halfway through it.
• Portion sizes rarely match what the household actually eats, so people either over-order or run short.

Each opportunity then branches into candidate solutions, and each solution branches into an experiment designed to test it cheaply before anyone builds it:

• Opportunity: forgotten pauses before travel
  • Solution: a calendar-synced auto-pause → Experiment: a two-week concierge test where the team manually pauses boxes for a small group of lapsed users and asks whether it would have prevented last month's wasted delivery.
  • Solution: a text-message pause reminder → Experiment: a short email/SMS opt-in test measuring how many subscribers who received a reminder actually paused before their next scheduled box.
• Opportunity: unclear recipe time commitment
  • Solution: a difficulty-adjusted prep timer shown before checkout → Experiment: a clickable prototype test measuring whether seeing the timer changes which recipe subscribers pick.
• Opportunity: portions don't match the household
  • Solution: a household-size input at signup → Experiment: a fake-door test adding the input field and tracking how many new signups use it before the feature is actually built.

None of this happened by guessing in a room. Every opportunity in the tree traces back to a direct pattern from the interview synthesis step — if that layer is built from assumptions instead of transcripts, everything below it inherits the same unearned confidence, no matter how organized the resulting diagram looks. The tree is only as trustworthy as the research underneath its first branch.

Opportunity Solution Tree vs. Product Roadmap

A product roadmap and an opportunity solution tree answer different questions. A roadmap says what ships and when; a tree says why a given solution is even under consideration, and what evidence supports it. Most teams need both, not one instead of the other.

The tree sits upstream of the roadmap: it's where a solution earns the right to become a line item on the roadmap in the first place. A roadmap entry that never passed through a validated opportunity or a real experiment is a bet made on confidence rather than evidence — which is exactly the failure mode the tree exists to catch before it turns into a shipped feature nobody asked for.

When It Matters for Validation: Choosing Which Branch to Test

The tree matters most at the exact moment you have more opportunities and solutions than you can test at once — which, for almost every team, is most of the time. It forces you to defend one specific branch instead of defaulting to whichever idea is loudest in the room that week.

A few criteria help narrow a wide tree down to the branch worth testing next:

• Evidence weight. An opportunity independently mentioned by multiple interviewees carries more weight than one raised once by a single enthusiastic customer. Count how many separate conversations surfaced it before you treat it as a priority.
• Leverage on the outcome. Opportunities closer to the root — the ones that plausibly move the outcome metric the most, if resolved — outrank opportunities that are real but marginal to the number you're actually trying to shift.
• Cost of the cheapest viable experiment. Between two similarly promising solutions, the one with a cheaper, faster experiment usually wins the next slot, simply because it returns evidence sooner without committing more resources.
• Reversibility. Favor experiments you can walk back easily if the result comes back negative — a fake-door test or a concierge stand-in over a shipped feature you'd have to un-ship.

Once you've picked a branch, treat the resulting experiment the same way you'd treat any other lean test: decide what result counts as a pass before you collect a single data point. How to set success metrics for lean experiments covers the mechanics of picking a threshold you'll actually stand behind once the numbers come in, rather than negotiating with yourself after you've already seen them.

The tree also does useful work after the experiment ends. A failed experiment prunes a branch — the solution comes off the tree, and either a different solution under the same opportunity gets tried next, or the opportunity itself gets deprioritized if nothing under it is working. A passed experiment promotes a solution toward an actual build. Either outcome keeps the tree honest, which is a different discipline from a roadmap that only ever grows and rarely gets pruned.

Key Takeaways

• The tree has four layers — outcome at the root, opportunities and solutions as branches, experiments as leaves — and each layer must trace back to the one directly above it.
• Opportunities come from customer conversations, not brainstorms. An opportunity phrased in the customer's own words is falsifiable; one phrased in the team's words usually isn't.
• A tree is not a roadmap. It sits upstream of one — a solution earns a place on the roadmap only after an opportunity and an experiment support it.
• Breadth before depth. A wide tree with many unexplored opportunities is healthier than a narrow one that jumped straight to a single favored solution.
• Prioritize branches by evidence weight and experiment cost, not by whichever idea generated the most enthusiasm in a planning meeting.
• The tree stays alive. Failed experiments prune branches, new interviews add them — treat it as a working document that changes weekly, not a one-time artifact filed away after an offsite.

Frequently Asked Questions

Who created the opportunity solution tree, and where does it come from?

Product coach Teresa Torres introduced the opportunity solution tree in her book Continuous Discovery Habits. It grew out of her work helping product teams shift from output-focused roadmaps toward outcome-focused, evidence-based discovery.

How is an opportunity solution tree different from a customer journey map?

A journey map documents an existing experience step by step; a tree is a decision-making structure for choosing what to build next. Some teams use a journey map as one input for surfacing opportunities, but the tree itself is about prioritization and traceability, not chronology.

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

No. A whiteboard, a sheet of paper, or a basic diagramming or mind-mapping tool is enough — the value is in the discipline of tracing each item back to the layer above it, not in the tool used to draw it. Dedicated product-discovery software exists but isn't a prerequisite to start.

How often should a team update its opportunity solution tree?

Continuously, ideally alongside a regular rhythm of customer conversations rather than a single research push. A tree built once for a planning offsite and never revisited stops reflecting reality within a few weeks, which defeats its purpose as a live map of current evidence rather than a snapshot of what was true last quarter.