Opportunity Solution Tree: How to Build, Test & Update One

An Opportunity Solution Tree is a visual model of the team's current Product reasoning: a desired outcome at the root, a structured space of customer needs, pain points and desires beneath it, candidate solutions for a chosen target opportunity, and assumption tests that help the team decide what to do next. Read as a whole, it is a decision trace, a record of why the team believes one path is worth pursuing and what evidence would change its mind.

Drawing the four layers is easy. Keeping outcome, opportunity, solution, assumption and evidence from collapsing into one another is the hard part. Most trees fail at exactly that boundary: a feature request becomes an "opportunity", one idea is the only solution, and a finished test gets relabeled "validated" without changing anything.

A good OST is a decision trace, not a decorative map. Its value is not that it looks organized. Its value is that every branch stays traceable to customer understanding and the tree changes when that understanding changes.

The Opportunity Solution Tree framework was developed by Teresa Torres and is documented on Product Talk. CraftUp is not affiliated with or endorsed by Teresa Torres or Product Talk. This guide teaches the reasoning behind a trustworthy tree and adds a CraftUp decision-trace extension for explaining what happens between the canonical layers.

Quick answer

• An OST shows how a desired outcome connects to customer opportunities, which connect to solution options, which connect to the assumptions you intend to test.
• Each layer answers a different question. Mixing them is the most common source of a malformed tree.
• An opportunity is a customer need, pain point or desire, not a feature. A solution is one candidate way to address an opportunity.
• The opportunity space is a tree because parent-child and sibling relationships let you compare opportunities of different shapes and sizes instead of ranking a flat list.
• The target opportunity is the team's current focus, not a permanent winner. New evidence should be able to move it.
• Tests belong to assumptions, not to whole features. Record evidence direction as supports, contradicts or inconclusive, and let the result change the tree.
• There is no universal number of opportunities, solutions or tests, and no required weekly meeting. The tree updates when the team's understanding or decision changes.

Table of contents

• The direct answer: an OST is a decision trace
• The four core layers and the decision-trace extension
• OST Branch Debugger: inspect one branch layer by layer
• Is this actually an opportunity? The Opportunity-Framing Clinic
• Opportunities come from customer understanding
• Why the opportunity space is a tree, not a flat backlog
• Structure is a hypothesis too
• Choosing a target opportunity without flat-score theater
• A target opportunity is current focus, not a permanent winner
• Solution divergence: compare before you converge
• Assumptions before tests
• Test the assumption, not the framework
• Evidence direction: supports, contradicts, inconclusive
• The Living Tree Review Protocol
• Cadence: a rhythm for learning, not a weekly ceremony
• Tree shape is a diagnostic, not a score
• An OST is not a roadmap
• An OST is not a prioritization engine
• An OST is not a research repository
• An OST is not a feature request backlog
• AI-generated trees are candidate structure, not customer evidence
• Copyable artifact: the Opportunity Solution Tree living review
• Worked decision trace: one branch, six decisions
• Decision clinic: common OST situations
• Common mistakes and how to repair them
• References and further reading

The direct answer: an OST is a decision trace

An Opportunity Solution Tree is not a backlog hierarchy and it is not a roadmap. It is a model of why the team believes a path is worth pursuing, and it earns its place only when three things stay true:

1. Each layer keeps its own meaning. The outcome is the change you want to create. Opportunities are customer needs, pains and desires. Solutions are candidate ways to address one opportunity. Assumptions are the beliefs a solution depends on. Tests are how you learn about an assumption.
2. Every opportunity can be traced back to customer understanding. If you cannot say where an opportunity came from and what context it came from, it may be an internal guess wearing customer language.
3. New evidence changes the tree, not just a status field. If a test result, a new customer story or a strategy shift never moves the tree, the tree has stopped being a decision model.

The useful mental model is a chain rather than a checklist:

Desired Outcome → Opportunity Space → Target Opportunity → Solution Alternatives → Assumptions → Assumption Tests → Learning → Decision / Tree Update

A team does not have to walk that chain in one sitting. It can run discovery on one branch while building another, and it should expect to loop backward when something it learns contradicts an earlier belief. The point of the tree is not to look tidy. It is to make the reasoning inspectable so the team can act on it and revise it.

If you eventually want to build and audit the working artifact, with evidence provenance, target rationale, assumptions and tests in one place, the Opportunity Solution Tree Builder is built for that job. This page owns the method behind it.

The four core layers and the decision-trace extension

Product Talk's current guide describes four components: a desired outcome at the root, the opportunity space of customer needs, pains and desires, the solution space of candidate solutions, and assumption tests that evaluate which solutions are most likely to create customer value while driving business value.

That four-layer picture is the canonical framework. CraftUp teaches a slightly wider decision trace, shown above, that makes three things explicit between those layers:

• Target opportunity. Which opportunity the team is focusing discovery on right now, and why.
• Assumption. The specific belief a solution depends on, made visible instead of hidden inside a generic "experiment".
• Learning and decision. What the evidence changed, the step that determines whether the tree stays as it is, reframes a branch or changes the bet.

This expanded trace is CraftUp's decision-trace extension for explaining the reasoning between the canonical layers. It is not the canonical Product Talk diagram, and it is not attributed to Teresa Torres.

Treat the layers as different kinds of statements that must not contaminate each other:

• An outcome is a result the team wants to influence.
• An opportunity is a customer's need, pain or desire.
• A solution is something you might build or do.
• An assumption is a belief that must hold for the solution to work.
• A test is a method for learning about that belief.
• A learning/decision is what the evidence changed.

If a node could belong to two layers at once, the node is usually misclassified. The next section is a layer-by-layer way to find that out.

OST Branch Debugger: inspect one branch layer by layer

The fastest way to repair a tree is to walk one branch from the root down and ask the same five questions at every node: What is this? What supports it? What does it not prove? What is the common category error? What question comes next?

Use the same lens on your own tree. Trigger example wording below is hypothetical.

1. Desired outcome

What this node is. The desired change that scopes discovery. In the canonical framework the root is the business need the team can create value against; in practice the best-scoped outcome is one the team can actually influence, stated as a direction rather than a feature.

What evidence supports it. Baseline data or a clear business rationale connecting the outcome to the team's remit. Product Talk distinguishes business outcomes, product outcomes and traction metrics, and generally recommends a product outcome (a customer behavior or sentiment) at the root because it sits within the team's control.

What it does not prove. It does not tell you which customer opportunity matters or what to build. A perfectly stated outcome can still be attacked through many different opportunities.

Common category error. The root is an output or a feature name: "launch the AI assistant", "ship the mobile app", "deliver the redesign". Those are things you plan to make, not changes you want to create.

The next question. What customer opportunity, if addressed, could move this outcome?

2. Opportunity

What this node is. A customer need, pain point or desire, ideally expressed in the customer's own terms and in context. Product Talk's definition is deliberately broad: unmet needs, pains and desires all count.

What evidence supports it. Direct customer stories are the richest source. Observed behavior, support/sales patterns, analytics and survey signals can motivate an opportunity, but they usually lack the context that explains the underlying need.

What it does not prove. It does not prove a particular solution, it does not establish prevalence by itself, and it does not prove that addressing it will move the root outcome. One vivid story is evidence in context, not a segment-wide fact.

Common category error. The "opportunity" already specifies an implementation: "customers need a dashboard", "we need to add SSO", "users want dark mode". That is solution-shaped. Ask what situation makes that solution valuable.

The next question. Is there more than one way to address this, and if not, is this actually a solution?

3. Target opportunity

What this node is. The opportunity the team has chosen to focus discovery on now. It is a working focus, not a verdict about which opportunity is universally "best".

What evidence supports it. The team's current understanding of importance, reach, satisfaction with existing alternatives, strategic relevance and plausible impact on the outcome, held as separate judgments rather than multiplied into one score.

What it does not prove. That other opportunities are invalid, that this one is permanently correct, or that it is the only one worth eventually pursuing.

Common category error. Selecting a target because it is the loudest request, the largest count, the most recent interview, or a flat score computed from incomparable inputs, with no recorded rationale and no alternative considered.

The next question. Why this branch now, what else did we seriously consider, and what uncertainty are we accepting by choosing it?

4. Solution

What this node is. One candidate way to address the target opportunity. Solutions can be products, features, services, workflows or documentation.

What evidence supports it. Prior evidence, design work, technical feasibility findings or analogies from comparable situations. That is enough to justify exploring a solution, not to conclude it works.

What it does not prove. That it is buildable, usable, desirable or that it will move the outcome. Those are separate beliefs that need separate evidence.

Common category error. Only one solution exists, or a solution was decided before the target opportunity and the tree was reverse-engineered around it. Both remove the comparison that makes the method useful.

The next question. What is a meaningfully different way to address the same opportunity, and what belief does this solution depend on?

5. Assumption

What this node is. A belief that must be true for the solution to create the intended value. Common types include desirability/value, usability, feasibility, viability and ethical/safety assumptions.

What evidence supports it. Whatever you already know, plus an honest note of how weak that evidence is. Product Talk's assumption-testing work treats assumptions as the object you evaluate before committing.

What it does not prove. That the whole solution is viable. An assumption is one lever, not the bet.

Common category error. A vague or untestable belief, "users will like it", "this is obviously better", or no assumption at all, jumping straight from solution to test.

The next question. What has to be true for this solution to create the intended value, and which of those beliefs could change our decision?

6. Assumption test

What this node is. A method chosen to learn about one specific assumption: a prototype session, a one-question survey, a data-mining check, a technical spike, a concierge test, or, when it is genuinely warranted, a controlled product experiment.

What evidence supports it. The assumption it targets, an observable signal defined before you run it, and a decision rule for what different results would mean.

What it does not prove. That all solution risk is gone, or that the Product outcome will move in production. A test removes some uncertainty around one belief.

Common category error. The test is chosen because it is familiar or impressive rather than because it addresses the uncertainty. Running a control-group experiment on a usability question, or a usability session on a technical constraint, is a mismatch between method and risk.

The next question. What observable result would make us change our minds, and is this the cheapest method that can produce it?

7. Learning and decision

What this node is. What the evidence changed: the result, your interpretation of it, the limitation of the test, and the next Product decision.

What evidence supports it. The recorded result and reference, kept separate from the interpretation. Record even inconvenient results.

What it does not prove. Very little on its own, which is exactly why it must be written down. A result that isn't interpreted cannot change a decision.

Common category error. The test is complete but nothing changes. Or the result is labeled "validated", the evidence is dropped, and the tree keeps its shape no matter what the team learned.

The next question. What in the tree or in the Product decision is different now, and if nothing is, why did we run the test?

Is this actually an opportunity? The Opportunity-Framing Clinic

Opportunity framing is interpretation, not transcription. A team hears a story, abstracts it into a need, and writes that need on a node. That abstraction is useful, and it is exactly where solution-shaped language, vague summaries and lost context creep in. The rule is simple: preserve the original customer evidence so the reframe stays auditable. Never present a rewritten sentence as a customer quote.

The test Product Talk suggests is a good one: is there more than one way to address this? If the only way to address "users need dark mode" is to build dark mode, it was never an opportunity. If "I cannot tell whether my export finished" could be addressed by a status indicator, a notification, a clearer completion state or a different export flow, it is an opportunity.

Two cautions keep the clinic honest:

• A feature request is not automatically an opportunity. "Add export scheduling" may hide a real need ("I have to stay online until exports finish"), or it may be a single customer's preferred implementation. Investigate before promoting it.
• A rewritten opportunity is not a quote. Keep the observation separate from the interpretation. The Opportunity Solution Tree Builder stores evidence records with source type, directness and context so the reframe can be re-checked later.

Opportunities come from customer understanding

The strongest source of opportunities is a customer story or an observed customer context that reveals a need, pain, desire, workaround or expectation gap. Story-based interviews are especially effective because the need arrives attached to the situation that produced it: when it happened, what the customer was trying to do, and what got in the way.

Product Talk is explicit that opportunities should not simply be generated from what a team already believes about its customers. When opportunities are invented off the top of people's heads, biases and half-truths come with them, and the team risks addressing needs that were never real.

That does not make other signals useless. Analytics, support themes, sales objections, churn reasons, search behavior and operational issues are valuable investigation leads. They tell you where to look. They do not automatically reveal the customer's underlying need or context, and they should not be silently promoted into customer evidence.

Keep the provenance types distinct, as the builder does:

• Direct customer evidence, a story or observation with real context.
• Indirect evidence, analytics, support, sales or survey signals that raise a question.
• Internal assumption, the team's belief, labeled as a belief.
• Unknown provenance, legacy or imported nodes you have not yet traced.

Product Talk uses the same distinction: sales conversations, support tickets, feature requests and behavioral analytics can inspire what to explore, but they are often missing the context needed to fully understand an opportunity. Use them to plan the next interview, not to replace it.

If you need to gather better context, start with the customer interview questions that get real stories or the complete Product Discovery interview workflow. If your notes are already messy, synthesize them before forcing them into branches, the Insight Clustering Helper exists for that job.

Why the opportunity space is a tree, not a flat backlog

Opportunities arrive in different shapes and sizes. Some are subsets of others. Some are related but genuinely distinct. A flat list invites you to compare incomparable things, "I cannot find something to watch" against "I'm out of episodes of my favorite show", and that comparison is not a prioritization, it is a category mistake.

A tree encodes two relationships that make the space tractable:

Parent-child and sibling relationships

• A parent-child relationship represents a subset. The child opportunity is one more specific reason, expression or component of the parent. In Product Talk's example, "I'm out of episodes of my favorite show" is a child of "I can't find anything to watch", but not the only child.
• A sibling relationship represents similar-but-distinct alternatives under the same parent. Siblings should be comparable in kind, and you should be able to address one without addressing another.

Siblings are how you handle context differences honestly. "I want to watch my shows on my flight" and "I want to watch on my train commute" are similar; whether they are one opportunity ("watch on the go") or two siblings depends on whether the constraints differ enough to matter. A tree lets you show both the similarity and the distinction instead of flattening or duplicating them.

A worked mini-example

Hypothetical example, for structure only.

Root outcome:

Reduce the time it takes workspace admins to reach first value.

A flat list of things the team heard:

• permissions confusion
• setup takes too long
• approval delay
• cannot find the integration
• security review
• import errors

The same evidence, structured provisionally:

• I cannot get the workspace ready without external help
  • I am blocked waiting for access
    • I do not know who must approve the integration
    • I cannot tell which permission is missing
  • I cannot tell whether setup is complete
    • connection status is unclear
    • an import failure is hard to diagnose

The structure is not objectively "the truth". It is the team's current best attempt to organize what it heard. New customer evidence may split a branch, merge siblings, move a child, rename a node or remove a branch entirely. Product Talk quotes the cognitive scientist Barbara Tversky on exactly this: structure "gets done, undone, and redone."

Structure is a hypothesis too

The most underrated idea in opportunity mapping is that the structure itself is an interpretation that can be wrong.

Product Talk describes the opportunity space as a messy synthesis process: collect the stories, build an experience map of the moments, map those moments to top-level opportunities, group individual opportunities under the moment where they occurred, then structure each branch one at a time. None of that is automatic. The team imposes order on customer evidence, and the order can be revised.

That leads to three practical rules:

• Traceability beats neatness. A slightly messy branch you can trace to source is more useful than a tidy branch you cannot explain. Keep the story, observation and context linked to the opportunity.
• Re-structuring is normal. When evidence changes, a parent-child relationship may change, a sibling distinction may sharpen, an opportunity may become broader or narrower, or two segments may need to be separated.
• A neat tree is not proof of a correct tree. Visual tidiness can hide invented structure. Product Talk's own recent AI work found that adding a parent that merely restates its child adds noise rather than clarity, a "fake structure" that looks organized and teaches nothing.

The tree is a mental model the team shares. Treat the model, not the drawing, as the thing under review.

Choosing a target opportunity without flat-score theater

Most teams that struggle here are not missing a template. They are trying to make a strategic decision with a ranking formula.

Product Talk's approach is to prioritize in the opportunity space, before jumping to solutions. Instead of ranking every opportunity against every other, compare opportunities at the same level of the tree, row by row, using the information you have now. Then move: choose a target, explore solutions, and revisit the choice when new information arrives.

The assessment lenses worth keeping separate, none of which collapses cleanly into the others, include:

• customer importance;
• frequency or reach, where it is actually known;
• satisfaction with current alternatives;
• strategic relevance;
• plausible impact on the outcome;
• strength and directness of evidence;
• segment or context.

Product Talk groups its own assessment factors into opportunity sizing, market factors, company factors and customer factors. Note what is deliberately not on the list: effort. Effort belongs to solutions, not opportunities. Any opportunity can have both easy and hard solutions, and ruling an opportunity out because it "sounds hard" before you have explored solutions is a common waste. If your ranking formula mixes opportunity value with solution effort, it is producing a number that answers neither question.

A few rules:

1. Keep the lenses separate. Do not multiply subjective inputs into a synthetic winner score. The builder preserves comparison lenses instead of computing an "opportunity score".
2. Compare like with like. Prefer row-by-row comparison over a single global ranking of different shapes and sizes.
3. Act on current information. Do not wait for perfect data. A "crummy first draft" plus an explicit uncertainty is more useful than an analysis that never ends.
4. Record the choice. Write down why this branch now, what meaningful alternative you considered, and what remains unresolved.

A target opportunity is current focus, not a permanent winner

Choosing a target opportunity is a reversible decision. It means "we are focusing discovery here now", not "this is mathematically the best opportunity" and not "the others are invalid".

Teams should design for reappraisal. Revisit the target when:

• new customer stories change the structure of the opportunity space;
• the desired outcome or strategy changes;
• the evidence supporting the target weakens;
• solution testing reveals the opportunity itself was misunderstood;
• segment differences emerge that the original framing blurred;
• a sibling opportunity starts to look more influential.

Because the tree keeps alternatives visible, changing the target is a normal move rather than a failure. A tree that can never move its target is usually a roadmap wearing tree shapes.

Solution divergence: compare before you converge

If there is only one solution under the target opportunity, the team is likely evaluating the idea it already wanted. A single solution removes the comparison that makes the method useful.

Teresa Torres's current guide commonly uses three solution ideas as a practical compare-and-contrast starting point, and recommends considering more than one solution for the target opportunity. That is a useful heuristic, not a universal law. Three is not a magic number and it is not a Page Win score threshold. The important principle is meaningful divergence before convergence: the alternatives should be genuinely different ways to address the same opportunity, not cosmetic variations of one idea.

Two failure modes matter more than the count:

• Premature convergence. One solution exists because the team fell in love with it early. CraftUp's builder flags a single-solution target as a convergence warning; it does not force an arbitrary count.
• Fake divergence. Three near-identical options satisfy the number while preserving the bias. Ask whether the alternatives would lead to different tests, different risks and different trade-offs.

Divergence is most valuable when the solution carries risk, when the opportunity is a differentiator, or when you need an innovative answer. When the change is small and well understood, say so honestly instead of manufacturing options.

Assumptions before tests

A lot of "experiments" fail before they start because they test a whole solution instead of the belief underneath it. Strengthen the chain:

solution → underlying assumption → test

Ask the question in plain language:

What has to be true for this solution to create the intended value?

The answer is an assumption you can examine. Common types include:

• Desirability / value, customers want this and would choose it.
• Usability, people can actually get value from it.
• Feasibility, the team can build and operate it.
• Viability, it works for the business, legally and operationally.
• Ethical / safety, it does not create unacceptable harm or risk.

Do not force every type onto every solution. Focus on the assumption that could change the Product decision. A belief that stays true whether or not you test it is not worth testing first.

Making assumptions first-class matters for the record, too. If the assumption is invisible, a completed test cannot be interpreted: you cannot say whether the belief was supported if the belief was never written down. This is why CraftUp's builder keeps assumptions as explicit nodes between a solution and its test rather than hiding them inside a generic "experiment".

Test the assumption, not the framework

A test should be chosen because of the uncertainty, not because it is familiar. Match the method to the belief:

• "Admins understand the setup checklist." A prototype usability session can show whether the meaning lands.
• "The integration can complete within the technical constraints." A technical spike or load check is the relevant method, not a user interview.
• "This workflow removes the actual blocker." A concierge test, pilot or prototype can test the mechanism, depending on the uncertainty.
• "The change moves real behavior." This may eventually require a controlled production experiment or observational release evidence.

Two rules keep tests honest:

1. Define the observable signal and the decision before you run the test. If you cannot say what result would change your mind, the test cannot decide anything.
2. Do not turn every assumption into an A/B test. Controlled experiments are one method among many and only make sense when the uncertainty is genuinely causal and measurable at the required precision. When the next test really is a controlled product experiment, detailed planning belongs in the A/B Test Plan Generator.

A test that is small, specific and tied to one belief produces usable learning. A test that tries to prove a whole feature produces a demo.

Evidence direction: supports, contradicts, inconclusive

"Validated" implies a certainty that qualitative discovery rarely delivers. It also encourages a team to stop thinking. Use more precise language.

For a test result, record an evidence direction:

• Supports, the evidence is consistent with the assumption.
• Contradicts, the evidence argues against it.
• Inconclusive, the test did not discriminate; uncertainty remains.

Then record, separately:

• the result (what you observed);
• the interpretation (what you think it means);
• the limitation (what the test could not show);
• the next decision (what changes as a result).

A narrow assumption can be falsified or supported by evidence. A complex customer opportunity or a whole Product bet rarely becomes "proven". Treating "inconclusive" as "validated" is one of the most damaging habits in discovery, it converts a genuine unknown into false confidence.

This is the same semantics the Opportunity Solution Tree Builder enforces: a completed test carries supports, contradicts or inconclusive plus the result, learning and next decision.

The Living Tree Review Protocol

The tree should change when the team's understanding or decision changes, not on a fixed calendar. This protocol replaces a rigid weekly meeting with a set of triggers and a repeatable review. The artifact at the end of this section is copyable.

Review triggers:

• New customer story. Ask: is this a new opportunity? Does it strengthen an existing branch? Does it reveal a segment or context distinction? Does it change a parent-child or sibling relationship?
• Target choice or change. Record why this branch now, the alternatives considered, and the unresolved uncertainty you are accepting.
• New solution. Ask: which target opportunity does it address? What assumption must hold? Are we converging too early?
• Test result. Record the evidence direction, the learning, and what changes in the tree or the decision.
• Outcome or strategy change. Ask: does the root still scope the right discovery? Should the tree be reframed or retired?
• Delivery learning. Ask: did production evidence change an opportunity, a solution assumption or the desired outcome?

Teams may run this weekly, asynchronously, event-driven, or inside an existing Product review. What matters is that the review produces decisions, not status updates. A review that only recolors status is ceremony.

Cadence: a rhythm for learning, not a weekly ceremony

If a team adopts continuous discovery, it will usually update its tree more often, not because a calendar demands it, but because new evidence arrives often and the tree is downstream of that evidence.

Keep the definition precise, because it is frequently distorted. Product Talk defines continuous discovery as weekly touchpoints with customers by the team building the product, where the team runs small research activities in pursuit of a desired outcome. That is a specific practice with three requirements: the people building the product talk to customers directly, the research is small enough to run alongside other work, and the work stays focused on outcomes.

It is not the same claim as "every OST needs a 60-minute weekly meeting". A team practicing continuous discovery may revisit its tree frequently because learning is frequent; another team may review on a different rhythm and still maintain a trustworthy tree. The calendar ceremony is not the method.

Product Talk's own guidance on tree updates is a good default to borrow without turning into law: revisit the opportunity space as new stories accumulate (their default is a handful of interviews), and start a new tree only when the directional outcome changes, not when a target moves. Treat that as a sensible rhythm, not a universal requirement.

Tree shape is a diagnostic, not a score

The shape of a tree can suggest what to do next. Read it as a set of symptoms, not a health percentage.

• Shallow opportunity space. Customer understanding may be thin. Next: gather more generative evidence before converging.
• Huge, unstructured opportunity space. You may need structure and narrowing more than more collection.
• One solution under the target. Possible premature convergence. Ask whether the alternatives are genuinely distinct.
• Many solutions, no explicit assumptions. Ideation without evaluative learning. Name the beliefs before designing tests.
• Many tests, no recorded learning. Experiment theater. Check that results, interpretation and decisions are being written down.
• Old root outcome. The tree may no longer match the strategy. Revisit the root before refining branches.

Product Talk's own AI tree-generation work does look at tree shape, counts of nodes, children per parent, depth, distribution, but uses those observations as internal rules of thumb and still relies on human judgment about whether the structure is meaningful. There is no universal tree-health score, and turning one into a number would hide the judgment it is meant to support. The builder follows the same principle: it produces categorized audit findings and no global score.

An OST is not a roadmap

These two artifacts answer different questions.

• An OST asks: how do outcome, customer opportunities, solution alternatives, assumptions and learning relate?
• A roadmap asks: which selected bets are we communicating and sequencing over time?

An OST can inform a roadmap, a selected, tested solution may become a roadmap item. But an OST should not contain Now/Next/Later columns, delivery dates, sprint assignments, release commitments or feature status as its primary structure. If your tree is organized by delivery time, it is a roadmap with a branching metaphor. Route sequencing to your roadmap owner only after Product choices are ready; the Now Next Later Roadmap is CraftUp's artifact for that step.

An OST is not a prioritization engine

An OST helps you structure the opportunity space, compare related opportunities and choose a current target. It does not own cross-bet capacity decisions across a portfolio.

Generic prioritization owns questions like: across competing initiatives, bugs, compliance work and platform investments, where should limited capacity go? Do not rank OST opportunities, roadmap bets, bugs and platform work inside one fake OST score. Keep the sibling boundary clear: the tree prioritizes within an opportunity space; a prioritization method allocates capacity across a portfolio.

An OST is not a research repository

Do not try to put every transcript and quote into the tree. The tree should preserve just enough traceability to answer three questions:

• Why does this opportunity exist?
• What source evidence supports it?
• What context belongs to it?

Detailed raw research can live elsewhere. If your notes are messy, synthesize them with the Insight Clustering Helper before distilling them into opportunity branches. A tree that tries to be a repository becomes unreadable, and an unreadable tree stops being a shared mental model.

An OST is not a feature request backlog

A feature request and a customer opportunity are not one-to-one.

• Feature request: "Add export scheduling."
• Possible underlying opportunity: "I have to stay online until exports finish."

The request may point at a real need, or it may be one customer's preferred implementation. Preserve the request as evidence, then investigate the need before deciding it is an opportunity. If the starting problem is a request inbox, use Feature Request Triage to route and decide. The OST begins after there is enough Product context to map a customer opportunity.

AI-generated trees are candidate structure, not customer evidence

CraftUp and Product Talk both work in a world where AI can draft an opportunity solution tree from interview transcripts. Product Talk's current work on AI-generated trees is a useful reference: it shows how much judgment and quality control still sits behind a tree that merely looks well-formed.

AI can help by:

• extracting candidate opportunities from research;
• clustering candidate branches;
• proposing a structure;
• surfacing source excerpts so a human can check the origin.

AI does not automatically establish:

• correct opportunity framing;
• correct parent-child relationships;
• target priority;
• customer prevalence;
• the Product decision.

The durable guardrail is source-linked human review. Every generated node should be checkable against the evidence that produced it, and a human should own the framing, the structure and the choice. An AI-generated tree is a draft to review, not customer evidence and not a decision.

This section is deliberately narrow. Deeper questions about AI in interviews, bias and research provenance belong with the human-AI research control guide and the interview method owners, not here.

Copyable artifact: the Opportunity Solution Tree living review

Paste this into your working document and fill it in during a review. It is deliberately scoreless.

# Opportunity Solution Tree, Living Review

Desired outcome:
[...]

What changed since the last review?
- New customer story:
- New behavioral/support evidence:
- New strategic constraint:
- New test result:

Opportunity-space change:
[No change / reframe / split / merge / move / new branch]

Current target opportunity:
[...]

Why this target now:
[...]

Meaningful alternative considered:
[...]

Solution options still in play:
- [...]
- [...]

Riskiest assumption:
[...]

Evidence / test:
[...]

Evidence direction:
[Supports / Contradicts / Inconclusive]

What did we learn?
[...]

What changes in the tree or Product decision?
[...]

What remains unknown?
[...]

The last two fields do the most work. "What changes in the tree or Product decision?" forces the review to produce a decision instead of a status update. "What remains unknown?" keeps uncertainty visible instead of pretending the evidence settled more than it did.

Worked decision trace: one branch, six decisions

This is an explicitly hypothetical B2B onboarding case. It exists to show how the method changes a decision, not to describe any real company or to publish customer data. Every observation below is illustrative.

Decision 1, Scope the root outcome

Desired outcome:

Increase the share of eligible new workspaces that reach a defined first-value event, without increasing setup-related support burden.

Two deliberate choices: the outcome describes a change in customer/business behavior rather than a feature to ship, and it carries a guardrail ("without increasing setup-related support burden") so success cannot come from dumping work onto support. Both the first-value event and the guardrail need honest measurement boundaries; where a number is genuinely unknown, it stays unknown rather than being invented.

Decision 2, Map the opportunity space from stories

Early customer stories (illustrative) surface several distinct struggles:

• I wait for security approval before I can connect an integration.
• I do not know which permission is missing.
• I cannot identify who owns the integration on my side.
• I misread the connection status and thought setup was complete.

A provisional structure:

• I cannot get my workspace ready without external help
  • I am blocked waiting for approval
    • I do not know who must approve the integration
    • I cannot tell which permission is missing
  • I cannot tell whether setup is actually complete
    • the connection status is misleading

The structure is provisional. It is the team's interpretation of the stories, not the stories themselves.

Decision 3, Choose a target opportunity

Target:

"I cannot tell what is blocking setup."

Why this branch now:

• Direct stories connect the need to the root outcome: admins who cannot see the blocker stall.
• The team can plausibly influence visibility without waiting on external security processes.
• Several different solution shapes are possible, so comparison is meaningful.

Meaningful alternative considered: "I am blocked waiting for approval." It is real and important, but part of it depends on an external process the team may not control, which makes it a different kind of bet.

Unresolved uncertainty the team is accepting: how common this is across self-serve teams versus enterprise accounts. The team records it rather than pretending it is settled. The choice is framed as current focus, not a permanent verdict.

Decision 4, Diverge into solution options

Three candidate solutions, deliberately different in kind:

1. A setup-status checklist that shows dependency states.
2. Permission diagnostics that name the missing permission.
3. A guided integration handoff that routes the right person to the right step.

They are not cosmetic variations. Each depends on different beliefs and would fail for different reasons.

Decision 5, Name assumptions and test one

For each candidate, the team names one important belief:

• Checklist: "Admins understand why a step is blocked when the dependency is shown."
• Diagnostics: "A named missing permission is actionable for the admin."
• Handoff: "Routing to the right owner removes the coordination delay."

The riskiest, most decision-relevant belief is the checklist's usability assumption. The test is a prototype comprehension session, matching the method to the uncertainty. The observable signal is defined up front: participants can explain the blocked dependency without the facilitator answering for them.

Decision 6, Let contradictory learning change the tree

Illustrative result: the prototype helps admins identify a missing permission, but it does not resolve the external security-approval delay. The evidence partly supports one belief and contradicts the assumption that visibility alone unblocks setup.

The team does not label the opportunity "validated" or "invalidated". Instead it updates the tree:

• It refines the opportunity structure, separating "missing permission visibility" from "external approval dependency".
• It retains the permission-diagnostics candidate for the visibility branch.
• It reconsiders the target's scope, because part of the original blocker is external.
• It narrows the Product bet to the part the team can influence, and records the external dependency as a known limitation.

The lesson is the whole point of the method: good OST work changes the map, not just the status color.

Evidence trace for the worked opportunity

Any opportunity on a real tree should be inspectable. For the worked target opportunity:

Keeping source, observation, interpretation, context and confidence boundary separate is what prevents an interpretation from masquerading as a customer quote.

Decision clinic: common OST situations

Use these as quick routing rules.

"A stakeholder asked for dark mode, is that an opportunity?" It is a solution/request. Ask what situation or problem makes another display preferable, and write that as the opportunity.

"Our goal is to improve activation, where does that go?" That is an outcome or metric direction, not an opportunity. Use it as the root or a scope statement if it is well-defined.

"Analytics shows onboarding drop-off, but we have no customer stories." Useful signal, not enough context to invent a customer opportunity. Investigate the drop-off and gather customer understanding before mapping the need.

"Support says 30 customers requested export scheduling." That is request evidence. It does not automatically become one opportunity. Preserve the source and context, then investigate the underlying need.

"Our opportunity siblings overlap heavily." Restructure rather than reaching for a flat score. Compare the parent-child and sibling relationships, and merge, split, move or rename branches.

"We chose the target because the CEO asked for it." Record the constraint honestly. A mandated focus can be a legitimate input, but do not dress it up as evidence-backed priority.

"We only have one solution." Flag premature convergence and look for meaningfully different alternatives. Do not invent a rigid count; when the decision is low-risk, one option can be legitimate.

"We have three solutions, so we are fine." Not because the count is three. Inspect whether the alternatives are genuinely distinct.

"This solution has no explicit assumption." Ask what must be true for it to create value before designing any test.

"Our prototype contradicted the usability assumption." Record the contradictory evidence and change or refine the solution or the assumption. Do not invalidate the opportunity.

"The test was inconclusive." Preserve the uncertainty. Do not relabel it as validated. Decide whether to re-test, change method or accept the risk explicitly.

"New stories show two segments experience different problems." Restructure the opportunity space and consider segment context rather than averaging the two into one blurred need.

"The root outcome changed after a strategy shift." Revisit whether the current tree still belongs under the new root, and reframe or retire it. Do not keep a stale structure out of habit.

"The team wants to put sprint dates on the OST." Route sequencing to the roadmap or delivery artifact. The OST remains a discovery decision model.

"AI generated an OST from our transcripts." Treat it as candidate interpretation. Preserve source traces and have a human review the opportunity wording and structure.

"How many opportunities are enough?" There is no universal number. Enough structure to make a useful decision, with ongoing learning. Stop when the next review can produce a decision.

"How often should we update the tree?" Update when evidence or decisions change, and choose a sustainable review rhythm. There is no mandatory weekly ceremony.

"Does one customer quote validate an opportunity?" No. A quote or story is evidence in context, not prevalence and not universal proof.

Common mistakes and how to repair them

• Building the tree once and never updating it. Repair: treat the tree as a living decision model and review it on the triggers above, not once a quarter.
• Writing opportunities as features. Repair: apply the "is there more than one way to address this?" test and rewrite as a customer need.
• Using proxy evidence as customer evidence. Repair: keep analytics, support and sales as investigation leads, and mark the branch as needing customer context.
• Testing a whole feature. Repair: name the assumption first, then design the cheapest test of that belief.
• Letting a test complete without changing anything. Repair: require a recorded learning and next decision for every completed test.
• Using impact versus effort to rank opportunities. Repair: assess opportunities on their own lenses; effort belongs to solutions.
• Turning the tree into a roadmap. Repair: remove dates, sprints and release commitments; keep those in the roadmap owner.
• Inventing a global OST score or readiness percentage. Repair: keep categorized diagnostics; preserve the judgment behind the target choice.
• Letting a target become permanent. Repair: define explicit revisit triggers and act on them.
• Treating the tree as a research dump. Repair: keep enough traceability to explain the branch and move raw research elsewhere.

References and further reading

These are methodology and point-of-view sources, not empirical universal law. Use them to sharpen judgement, then apply them to your own context.

• Product Talk, Opportunity Solution Trees, the canonical structure, prerequisites, target-opportunity reasoning, solution comparison and update guidance.
• Product Talk, Opportunity Mapping, parent-child and sibling relationships, why a flat list fails, and why structure is done, undone and redone.
• Product Talk, Prioritizing Opportunities, compare and contrast, row-by-row prioritization, and revisiting the target when new information arrives.
• Product Talk, Opportunity Solution Tree glossary, concise four-component definition and the idea that new information can lead a team to evolve a solution, choose a new opportunity or pursue a different outcome.
• Product Talk, Sourcing opportunities from other insights, why sales, support, feature requests and analytics are leads rather than complete customer context.
• Product Talk, AI-generated opportunity solution trees, why a well-formed-looking AI tree still needs human judgment and quality control.

When you want to build the actual artifact, with provenance, target rationale, assumptions and tests in one auditable workspace, continue with the Opportunity Solution Tree Builder. When you want the end-to-end discovery system rather than this method alone, continue with the Product Discovery course. If the next question is how discovery and delivery interact around one bet, that boundary belongs to the discovery and delivery guide.