How to build an opportunity solution tree

Most opportunity solution trees die two ways. The first is on a Miro board in week one, drawn in a half-day workshop, never updated. The second is in week six, when the weekly customer interview the tree was supposed to feed quietly stops happening. Both failure modes look like a beautiful diagram and a roadmap that did not change.

This is a working guide on how to build an opportunity solution tree that survives a quarter. What the framework is, why most teams' trees decay, the six-step build, and the discovery cadence that keeps the branches honest. The piece sits inside the wider voice user research guide and pairs directly with the playbook on continuous discovery interviews.

What an opportunity solution tree is

An opportunity solution tree is a visual artifact that connects a measurable product outcome at the top, to the customer opportunities (unmet needs, pains, and desires) discovered through interviews, to the candidate solutions that could address each opportunity, and to the assumption tests that decide which solutions to ship. The framework was developed by Teresa Torres and documented in Continuous Discovery Habits (2021); her canonical write-up lives on Product Talk.

Four layers, top to bottom. The outcome is a single, measurable change the team is trying to produce. Opportunities are the customer-side reasons that outcome is not yet met, grouped by relationship. Solutions are the things the team could build, written specifically enough to fit on a card. Assumption tests are the smallest experiments that would tell you whether a solution would actually work.

The tree is read top-down for prioritisation and bottom-up for evidence. The reason it works as a thinking artifact (and not as a slide) is that every level can be challenged from the level below it. A solution is allowed to live only if it traces up to a real opportunity. An opportunity is allowed to live only if there's customer evidence behind it. An outcome is allowed to live only if it represents something the team can actually move.

Why most opportunity solution trees fail

Three failure modes show up across teams that drew a tree and never used it again. All three are structural; effort doesn't fix them.

The tree is brainstormed, not discovered

The first failure mode is starting from the team's existing opinions about what customers want. A product trio sits in a room, sticky-notes opportunities they have already heard about from sales, support, and internal Slack, and clusters them into branches. The result is a tree that confirms what the team already believed. It looks like discovery. It is documentation of the team's existing roadmap, with a new visual.

The fix is to anchor every opportunity to a specific moment from a recorded customer interview. If the trio cannot point to a transcript, a timestamp, or a participant who said the thing, the branch is a hypothesis, not an opportunity. Label it as such and move on, or run the interview that turns it into evidence.

The outcome at the top is an output in disguise

The second failure mode is the outcome. Teams routinely put outputs ("ship feature X by Q3", "increase signups by 20 percent") in the outcome slot. A proper outcome is a behavioural change in customers that the business cares about: "more first-week users complete their first invoice", "more trial accounts return on day three", "fewer cancellations cite the same friction." Outputs and outcomes look similar on a sticky note. The tree built under an output is a backwards-engineered justification for what the team was going to do anyway.

A useful check: ask whether the outcome could be moved by multiple, unrelated solutions. If the answer is no, the "outcome" is actually a solution in a hat.

Discovery cadence cannot keep up with the branches

The third failure mode is operational. The tree is supposed to be updated continuously as new evidence arrives. New evidence arrives from weekly interviews. Weekly interviews require recruitment, scheduling, four calendars and a customer, and they almost always slip when the team is shipping. By week six, the rhythm is gone, and the tree turns into a snapshot of one week's understanding, ageing in a Figma file.

This is the variable a working tree-and-discovery system has to solve, and it is the variable continuous discovery interviews covers in operational detail. The tree only works if the interview cadence works.

How to build an opportunity solution tree, step by step

Six steps. The order matters: the temptation is to start with solutions (step four) because solutions feel concrete, and starting there is what produces the brainstormed tree.

01 · Anchor on a measurable outcome

Pick one outcome. The product trio (product manager, designer, engineer) agrees on a single behavioural change in customers, measurable, time-bound, and within the team's actual control. "More first-week users complete onboarding" is an outcome. "Reduce churn" is too broad. "Launch the new pricing page" is an output.

Three sanity checks before you commit:

• Behavioural, not opinion-based. The outcome describes what customers do, not what they think. "Customers feel the product is easier to use" is a survey result and not an outcome.
• Movable from multiple angles. Several unrelated solutions could plausibly affect the metric. If only one specific change could move it, you have written a solution.
• Owned by the trio. Marketing-led pipeline metrics and pricing decisions made by finance are not outcomes the product trio can be accountable for. Pick something the team can actually move.

The outcome belongs on top of the tree, written in one line. Everything below is in service of moving it.

02 · Surface opportunities from real participant talk

This is the load-bearing step and the one most teams shortcut. An opportunity is a customer-side reason the outcome is not yet met, expressed in the participant's words, anchored to a moment in a transcript. The piece on how to write user research questions covers the prompt-craft side; the rule of thumb for OST work is to ask the customer to walk through a recent attempt to do the thing the outcome describes, and to mine the transcript for friction.

Opportunities show up in three reliable patterns: unmet needs ("I wanted to do X and could not"), pains ("doing Y took longer than I expected"), and desires ("I wish I could Z"). Each opportunity is a candidate branch. Resist the urge to combine related ones at this stage; the clustering happens in step three.

"I wanted to add the rest of my team but I didn't know if their invoices would get billed to me or to them. So I just... didn't. I made one more invoice and then I forgot about the import for a few days."

That answer is one opportunity. Not "users want clearer team billing" (that's the team's gloss). The opportunity, written as the customer described it, is "I cannot tell who gets billed when I invite teammates, so I stop." The verbatim is what survives later challenge, and the framework that gets you from the transcript to the named opportunity is in how to analyze user interview transcripts.

03 · Map opportunities into a hierarchy

Opportunities are not flat. The same customer often has a parent need (set up the team) and a child friction (don't understand billing splits) and a grandchild blocker (the invite link doesn't say). Cluster them by relationship, not by topic. The shape that emerges is a hierarchy where parent opportunities are the higher-level customer goals and child opportunities are the specific frictions blocking them.

The clustering pass is also where the team kills redundancy. Two interviews surfacing the same friction become one opportunity with two pieces of evidence, not two branches. Aim for breadth at the top of the hierarchy and depth at the bottom, not a flat row of forty equally weighted leaves.

A common signal that the clustering is working: when you say each opportunity out loud, the parent describes the customer's goal and the children describe the obstacles. If a child opportunity doesn't trace up cleanly to its parent's goal, it belongs elsewhere on the tree.

The general thematic clustering pass that powers this step is covered in how to synthesize user research. The OST-specific substitution is that the codebook is "what is the customer trying to do?" and "what is in the way?" rather than an open code set.

04 · Brainstorm solutions per opportunity, not per quarter

Solutions live one level below the opportunity they would address. The constraint is strict: each solution must trace upward to a specific opportunity. A team that brainstorms a list of solutions and then retrofits them onto opportunities has done the workshop backwards and ends up with a tree shaped like the original backlog.

Aim for at least three to five candidate solutions per priority opportunity, before any prioritisation. Quantity matters. Most useful solutions only become visible when the lazy first three are off the table. Solutions can be tiny (a copy tweak in the invite modal), middle-sized (a billing-split toggle on the team setup screen), or large (a new pricing-by-seat model). Mix sizes deliberately. Small ones are a hedge against the large one failing.

This is also where solutions stop being feature names and start being intent. "Show billing owner clearly on invite" is more useful as a solution-card than "billing UX improvements." Specificity at this layer pays back at step five.

05 · Run assumption tests, not generic experiments

Below each solution sits its assumptions. An assumption test is a small experiment built to invalidate the riskiest belief a solution rests on, before the solution is built. Torres' framework names four assumption categories worth checking against, and they are useful as a checklist even outside her exact language: do customers actually want this, will they use it, is it feasible to build, is it viable for the business.

Pick the riskiest assumption first. Most product teams default to feasibility, because engineering is in the room, but the assumption that most often kills a solution is the desirability one: customers said they wanted X in the interview but will not click the X button when it's in front of them. The cheapest test for desirability is rarely a build. It is a concept brief, a fake-door click test, or a small unmoderated test with a clickable mockup. The methodology piece on concept testing covers the desirability side; for the participant-level setup how to recruit user research participants covers who to put in front of the test.

Each assumption test should be small enough to run inside a week. If it isn't, you are running a build, not a test.

06 · Keep the tree alive with weekly discovery

The tree is not an artifact, it is a practice. The trio meets weekly, looks at the tree, and updates it with the evidence collected since the last meeting: new opportunities surfaced from the week's interviews, new solutions invented against the active opportunity, assumption-test results, and any branches that have been falsified and can be pruned.

The interview cadence is the input. Without it, the tree calcifies in week three. With it, the tree gets messier in week four (more branches than the team can build against) and then gets cleaner in week five as the trio prunes the falsified branches and re-prioritises. That cycle is the practice. The whole point of the tree is to be wrong about something this week that it was right about last week.

Why opportunity solution trees pair with continuous discovery

The opportunity solution tree was never designed to stand alone. Torres' framework places it inside a wider practice in which the product trio talks to customers at minimum weekly, and the tree is the artifact that captures what they hear. Decoupling the tree from the rhythm is the most common single mistake teams make: they build the tree, then never feed it.

The cadence problem is mostly a calendar problem. A live customer interview costs four calendars (trio plus participant) and roughly an hour of round-trip time, which compresses on a launch week and disappears on the weeks where the team is shipping. The cadence does not collapse all at once; it thins, and then the tree thins with it.

The async voice version of continuous discovery changes that variable. The participant answers four to six prompts on their own time, in voice, text, choice, or rating, whichever fits the question. The trio listens together at a standing slot that does not require the participant's calendar. Adaptive follow-up prompts catch the polite first answers and push them into the honest second ones. The interview rhythm survives the launch week, and the tree gets its weekly input. The shape of that pipeline (recruitment, prompts, listening rhythm) is in continuous discovery interviews and the wider voice user research guide.

A second reason the pairing matters: a tree fed by interviews is also a tree fed by a synthesis layer. The opportunities that show up on the tree are not raw quotes; they are themes that recur across participants. The thematic-analysis playbook covers the clustering pass that turns ten transcripts into three opportunities.

When the opportunity solution tree doesn't help

Three cases where the tree is the wrong tool, and using it anyway makes a team feel rigorous while producing the wrong answer.

Pre-PMF, no customers yet. A team without paying customers cannot anchor opportunities to interview evidence, because the relevant participants don't exist. The right tool at that stage is closer to jobs to be done interviews on people who switched from a workaround, or assumption testing on the founding team's beliefs. Trying to draw an OST on a pre-PMF product produces a tree of guesses dressed as a tree of opportunities.

One-off bets the team is going to build regardless. Some decisions are not discovery work. A platform migration, a regulatory feature, a partner-driven integration: these can be planned with a roadmap and a Gantt chart. Forcing them onto an OST adds ceremony without adding signal. Use the tree for the discovery surface, not the planned-work surface.

Sales-led B2B where the buyer and the user are different people. OSTs assume the customer in the interview is the customer making the decision. When the buyer (a procurement lead, an exec sponsor) is not the user, branches built off user interviews can be valid and the product still won't sell, because the deal-breaking opportunities live with the buyer. The fix is to interview both sides, treat the buyer side as a separate cohort on the tree, and accept that the merged tree will be heavier on assumption tests than on observed opportunities.

The further out from a stable customer base you are, the less the tree carries its weight. Once a steady interview cadence is possible, it earns its keep again.

FAQ

What is an opportunity solution tree?

An opportunity solution tree is a four-level visual artifact that connects a measurable product outcome (top), to customer opportunities discovered through interviews (middle), to candidate solutions the team could ship (below opportunities), to the assumption tests that would prove or disprove each solution (bottom). It is read top-down for prioritisation and bottom-up for evidence. The framework was developed by Teresa Torres and documented in Continuous Discovery Habits (2021); it sits inside a wider practice in which a product trio talks to customers at minimum weekly and updates the tree with what they hear.

Who created the opportunity solution tree?

Teresa Torres created the opportunity solution tree as part of her continuous discovery framework, popularised through her Product Talk blog and her 2021 book Continuous Discovery Habits. The framework draws on earlier product-discovery work in the lineage of Marty Cagan and the Silicon Valley Product Group, but the specific tree structure (outcome, opportunities, solutions, assumption tests) and the discipline of grounding every opportunity in a recorded customer interview is Torres' contribution.

How is an opportunity solution tree different from a product roadmap?

A product roadmap is a list of what the team is going to ship, ordered in time. An opportunity solution tree is a structured argument for why the team has chosen what's on the roadmap, anchored to customer evidence at every level. Roadmaps survive board meetings; trees survive the question "but why are we building this?" The two are not interchangeable. A team that ships from the tree maintains both: the roadmap is the output, the tree is the reasoning behind it. The tree changes weekly. The roadmap changes when the tree's evidence tips a decision.

How many opportunities should be on an opportunity solution tree?

Typically six to twelve active opportunities at any given time, clustered into a hierarchy. Fewer than six suggests the team isn't actually doing discovery; more than fifteen usually means the team is treating every quote as a branch, instead of clustering related frictions. The right tree is wide at the top (a handful of customer goals tied to the outcome) and deeper than it is wide as you go down (specific frictions and obstacles under each goal). Pruning is half the work. Branches that no longer have evidence behind them should come off the tree, not stay on it indefinitely.

How often should you update an opportunity solution tree?

Weekly, in the same standing meeting where the product trio reviews the previous week's interview snapshots. Each update is one of three actions: a new opportunity gets added (a participant said something the tree didn't already capture), a solution gets added or refined under an existing opportunity (the trio invented a candidate), or a branch gets pruned (an assumption test invalidated a solution or a re-read of evidence undermined an opportunity). A tree that goes more than two weeks without an update is no longer a discovery artifact; it has become a snapshot.

---

Opportunity solution trees fail when they are drawn once, hung on a wall, and disconnected from a working interview cadence. They work when the trio commits to a single measurable outcome, anchors every opportunity to a recorded participant moment, prunes the branches that lose their evidence, and updates the tree weekly from a live discovery pipeline. The artifact only carries its weight if the pipeline behind it does. Talkful is built for that pipeline: a study link goes out, participants answer in voice, text, choice, or rating on their own time, an AI interviewer probes the polite first answers into the honest second ones, and a synthesis engine streams themes and quotes back ready for the trio to plant on the tree. The wider voice user research guide covers where the practice sits in a continuous product-research rhythm.