Opportunity solution trees

This is the exact file agents read, including the credit header and licence notice. Save it as opportunity-solution-trees/SKILL.md.

---
name: opportunity-solution-trees
description: Build and maintain an opportunity solution tree that links one product outcome to the customer opportunities that drive it, then to solutions and the assumption tests that de-risk them, using Teresa Torres's continuous discovery method. Carries the real rules: a product outcome at the root, not a business metric or a feature click-rate; opportunities framed as a customer would say them and traced to evidence; the solution-in-disguise test; comparing only sibling opportunities on sizing, market, fit and importance; five opportunities before going deep and three solutions per target; assumption tests with a pass threshold set in advance and a go/no-go rule. Use it when someone says build an opportunity solution tree, OST, map our discovery, which customer problem should we solve, or we keep jumping to solutions. Do NOT use it to rank features already decided (see prioritisation-frameworks), to sequence chosen work over time (see product-roadmapping), or to build a tree with no customer interviews to draw on.
---

# Opportunity solution trees

An opportunity solution tree is a simple map that keeps a team honest about why it is building anything. At the top sits one product outcome. Below it sit the customer opportunities, the needs, pains and desires that, if addressed, would move that outcome. Below each targeted opportunity sit solution ideas, and below those sit the assumption tests that tell you whether a solution will work before you build it. The method comes from Teresa Torres's continuous discovery work, and its whole point is to stop a team jumping straight from an outcome to a favourite feature.

This skill makes an AI agent build and maintain that tree from real customer evidence, pick one opportunity to pursue with defensible reasoning, generate and compare solutions, and design tests that produce a clear go or no-go. It decides which customer problem is worth solving. It does not rank features that are already chosen, and it does not sequence work into a plan. Ranking is the prioritisation-frameworks skill. Sequencing and communicating the plan is the product-roadmapping skill. A good roadmap often starts from the opportunity this tree selects.

## When to use this skill, and when not to

Use it when someone needs to connect product work to a customer outcome, make sense of a pile of user interviews, decide which problem to solve next, or stop a team committing to a solution nobody has tested. Use it when someone says build an opportunity solution tree, make an OST, map our discovery, we keep arguing about features, which problem should we pick, or turn these interview notes into something we can act on.

Do not use it to score or rank a set of features that have already been chosen; that is the prioritisation-frameworks skill, which carries RICE, WSJF, Kano and the rest. Do not use it to lay out chosen work over time or communicate a plan to stakeholders; that is product-roadmapping. Above all, do not use it to invent a tree from nothing. An opportunity solution tree is built from customer stories. With no interviews, surveys or support data to draw on, the tree will be a list of guesses dressed up as a diagram, which is the single most common way the method fails.

## What the agent needs from you before starting

Ask for these before building anything. Do not proceed on assumptions.

1. The product outcome. A measure of customer behaviour or sentiment inside the product, such as "share of new users who complete setup in week one" or "weekly active teams". If you are handed a business metric like revenue, narrow it to the customer behaviour that drives it. If you are handed a single feature's click-rate, widen it. Ask: "What customer behaviour, if it changed, would you count as success?"
2. Who the target customer is. One segment, described well enough that you could recognise one. A tree that mixes segments produces opportunities that contradict each other.
3. The customer evidence. Interview notes or transcripts, support tickets, survey verbatims, sales-call notes, or product analytics. You need enough to hear real stories. If there are fewer than three customer conversations to draw on, say so and recommend running three to four short interviews first, because the tree cannot be trusted below that.
4. Any constraints. Deadlines, a fixed team, regulatory limits, or a strategy the work must serve.

If the outcome or the evidence is missing, stop and ask for it. Do not fabricate customer quotes, opportunities or numbers to fill the gap.

## How to build an opportunity solution tree, step by step

Follow these in order. The thresholds are deliberate; they are what stop the tree becoming wishful thinking.

### Step 1. Set the root outcome

Write one product outcome at the top. Test it against two limits. If it is so broad that no single team could move it alone (company revenue, overall retention for the whole product), it is too high; push it down to the behaviour your team owns. If it is so narrow that it only measures one feature being clicked, it is too low; pull it up to the customer behaviour the feature was meant to serve. One tree has exactly one outcome. If the team owns two clearly separate outcomes, build two trees.

### Step 2. Turn the evidence into an experience map

Read every interview or note and pull out the moments the customer describes: what they were trying to do, where they got stuck, what they wanted. Lay these out as the steps of their experience, in the order they happen. These moments become the top level of your opportunity space. Group related opportunities under the moment they occur in, because the same complaint at two different points in a workflow is two different opportunities.

### Step 3. Frame opportunities as the customer would say them

Every opportunity is a need, pain or desire in the customer's words, not a feature and not a business wish. Run three checks on each one:

- Would a customer actually say this? "I can't tell which invoice is unpaid" passes. "Users should adopt our billing dashboard" fails; that is a business wish.
- Is it a solution in disguise? If there is only one obvious way to address it, it is a solution, not an opportunity. Reframe it as the underlying need. "Add a bulk-export button" becomes "I need to get my data out quickly".
- Does it trace to evidence? Every opportunity must point to at least one real customer statement. Tag each with its source, for example "Interview 4, Oct 2026". An opportunity backed by a single interview is low confidence; mark it and do not target it until one or two more conversations confirm it.

### Step 4. Give the tree breadth before depth

Explore at least five distinct opportunities across the tree before going deep on any one. Committing to the first problem you find is tunnel vision. At the same time, do not map everything: apply an eighty-twenty rule at each level and only expand the branches that look most promising. A tree that tries to capture every possible opportunity, solution and assumption wastes effort, because priorities shift as you learn.

### Step 5. Choose one target opportunity, comparing siblings only

Pick a single target opportunity to pursue. Compare only opportunities that sit at the same level under the same parent; never compare across different branches, because they are not alternatives to each other. Assess each sibling on four factors, as qualitative judgements rather than a false-precision score:

- Sizing: how many target customers feel this, and how often.
- Market: how addressing it would affect your position against alternatives.
- Company fit: how well it serves the vision, mission and current strategy.
- Customer importance: how much the customer cares, including how intense the pain is and whether they would pay to remove it.

Then ask the deciding question: how much would closing this opportunity move the root outcome? Resist the urge to turn these into a weighted spreadsheet. The more you quantify soft judgements, the more the team treats the resulting number as truth. Record a short written rationale for the pick instead. Treat the choice as a two-way door: it is reversible, and you will learn more by acting than by deliberating.

### Step 6. Generate and compare at least three solutions for the target

Only now brainstorm solutions, and only for the chosen opportunity. Do not brainstorm across the whole tree. Produce at least three distinct solutions. If you can only think of one, the opportunity is still a solution in disguise; return to step 3. Keep each solution small enough to ship on its own. Note several options and defer the final choice until tests tell you which assumption holds.

### Step 7. Find the riskiest assumption under each solution and test it

For each promising solution, list the assumptions it depends on: that customers have the problem, that they would use this solution, that it is feasible to build, that it is viable for the business. Find the one that would sink the solution if it were false. Design a test for it with every field filled in:

- Hypothesis: what you believe and why.
- Signal: the specific metric or behaviour the test will move.
- Pass threshold: the number that counts as success, set before you run it.
- Sample and duration: how many people and how long, and prefer a test that runs in two weeks or less.
- Action on pass, and action on fail: both decided in advance.

Prioritise tests by how much they would move the outcome, how large an assumption they de-risk, and how little time they cost.

### Step 8. Apply the go/no-go rule

A solution only graduates from test to build when its riskiest assumption clears the pass threshold you set in advance. If the signal falls short, either iterate the solution and retest, or drop it and walk back up the tree to the next opportunity. Never let a tie, a blank success field or a hunch decide this. Committing engineering to a solution, or publishing it on a roadmap, is a resource decision: put it to a human for explicit confirmation rather than treating a passed test as an automatic build order.

### Step 9. Keep the tree alive

Revisit the tree every three to four new interviews. The top-level moments should settle over time while detail grows further down. Start a new tree only when the directional outcome itself changes, not when the target number moves. Give each team its own tree and its own outcome; avoid one giant company-wide tree that no single team can act on.

## Worked example

Outcome handed over: "increase monthly revenue." Too broad. The agent narrows it with the team to a product outcome: "raise the share of trial teams that invite a second member in week one," because activation through a second user is what the data links to paid conversion.

Target customer: operations leads at small logistics firms, drawn from eight recent trial interviews.

From the interviews the agent builds the opportunity space under three moments: setting up the account, inviting the team, and running the first shipment. Opportunities, each tagged to evidence, include "I don't know who on my team should be in here" (Interviews 2, 5, 7), "I set it up at night and my team never saw the invite" (Interview 3, low confidence, single source), and "I wanted to try it myself before pulling others in" (Interviews 1, 4, 6, 8).

Breadth check passes: six distinct opportunities, more than the five-minimum. The agent compares the three siblings under "inviting the team". "I wanted to try it myself first" is large and intense across four interviews and sits close to the activation outcome, so it is the target. The single-source invite-visibility opportunity is marked low confidence and parked for more interviews.

Solutions for the target, at least three: a guided "invite later" path that still allows a solo trial, a sample dataset so a solo user sees value before inviting anyone, and an in-product nudge that suggests the right second user based on the account domain. The riskiest assumption under the sample-dataset solution is that a solo user who sees value will then invite a colleague at all. Test: show a sample dataset to half of new solo trials; signal is week-one second-member invites; pass threshold is a lift from 18 to at least 28 per cent; run for two weeks across roughly 120 trials; on pass, build it properly; on fail, drop it and test the "invite later" path. The agent writes the tree, the rationale and the test plan, and asks the human to confirm before engineering time is booked.

## Templates you can use verbatim

Tree, as indented text any tool can hold:

```
OUTCOME: <product outcome, one customer behaviour>
  OPPORTUNITY (moment): <need in the customer's words>  [evidence: Interview x, y]
    OPPORTUNITY (child): <narrower need>  [evidence: ...]
  OPPORTUNITY (moment): <need>  [evidence: ...]
    SOLUTION: <small shippable idea>   (target branch only)
      ASSUMPTION TEST: <riskiest assumption>
        hypothesis / signal / pass threshold / sample + duration / action on pass / action on fail
```

Assumption-test card:

```
Solution: <name>
Riskiest assumption: <the belief that, if false, sinks this>
Hypothesis: We believe <X> because <evidence>.
Signal: <the one metric or behaviour we will watch>
Pass threshold: <number set in advance>
Sample and duration: <n participants, <= 2 weeks>
If it passes: <action>   If it fails: <action>
```

Opportunity quality prompt, to run on each node: "Would a target customer say this out loud? Is there more than one way to address it? Which interview does it come from? If any answer is no, reframe or drop it."

## Common mistakes and how to avoid them

1. Inventing opportunities from the team's head. The tree looks full but none of it traces to a customer. Spot it when nodes have no evidence tag. Fix it by refusing to add any opportunity without a real source, and by gathering three to four interviews before the first tree.
2. Solutions dressed as opportunities. "Add single sign-on" is a solution; the opportunity is "logging in across our tools is a hassle". Spot it when a node has only one obvious fix. Fix it with the solution-in-disguise test and reframe to the underlying need.
3. Ranking solutions instead of opportunities. Teams build a spreadsheet that scores feature ideas on value and effort and skip the problem space entirely. Spot it when the tree has solutions everywhere and few opportunities. Fix it by choosing the opportunity first and only then generating solutions for that one branch.
4. False precision. Four soft judgements get multiplied into a single decimal and the team treats it as fact. Spot it when the pick rests on a number nobody can defend. Fix it by comparing siblings qualitatively and writing a short rationale instead of a score.
5. A tree that never changes, or one so vast it is abandoned. Spot staleness when the tree has not moved in a month of interviews; spot sprawl when every branch is expanded to the leaves. Fix both by revisiting every three to four interviews and expanding only the one or two branches you are actually pursuing.

## Quality bar: check the output against this before handing it over

- The root is a single product outcome, not a business metric and not a feature click-rate.
- Every opportunity reads as something a customer would say and carries at least one evidence tag; single-source opportunities are marked low confidence.
- At least five distinct opportunities were explored before any branch went deep.
- Exactly one target opportunity is chosen, compared only against its siblings, with a written rationale rather than a manufactured score.
- The target branch has at least three distinct, small solutions.
- Each tested solution names its riskiest assumption and a test with a hypothesis, a signal, a pass threshold set in advance, a sample and duration, and predefined actions for pass and fail.
- No opportunity, quote, baseline or test result is invented; every number traces to a source.
- A note tells the human that committing to build is theirs to confirm, and when the tree will next be revisited.

## Guardrails

- Irreversible actions need a human. Booking engineering time, committing a solution to a roadmap, or telling customers something is coming are resource and reputation decisions. Default to proposing tests and a recommendation, and ask for explicit confirmation before anything is committed.
- Never fabricate evidence. If there are no interviews, the honest output is "we cannot build a trustworthy tree yet; here are the three interviews to run first", not a tree of guesses.
- Protect customer data. Interview notes hold names, employers, emails and voices. Do not paste raw transcripts or personal details into the tree or into third-party tools. Reference each interview by an anonymised label such as "Interview 4, Oct 2026" and keep the source material where it already lives.
- Mind the cost of discovery. Interviews and tests cost people's time. Prefer tests that run in two weeks or less, run the cheapest test that can kill the riskiest assumption, and review the whole tree's direction after about every three experiments.
- Stay in scope. This skill selects a problem and designs tests. It does not rank chosen features (prioritisation-frameworks) or sequence work into a plan (product-roadmapping). Hand off to those skills by name.

## Tool-specific appendix

The core method above is tool-agnostic: the tree is just an outcome, opportunities, solutions and tests, and the indented-text template holds it anywhere. For a visual tool such as a whiteboard or a dedicated discovery app (FigJam, Miro, Vistaly, or similar), lay the outcome at the top, opportunities as a branching layer beneath, solutions under the target opportunity only, and assumption tests as leaves. Keep the evidence tags on the opportunity cards. For a product-analytics tool (Amplitude, Mixpanel, or similar), wire the root outcome to a real metric and label each experiment by the opportunity and solution it belongs to, with a validated or invalidated marker, so the tree and the data stay in step. Whatever the tool, the rules in the steps above do not change; the tool only decides how the tree is drawn and stored.

## Sources

- Teresa Torres, "Opportunity Solution Trees: Visualize Your Discovery", producttalk.org/2016/08/opportunity-solution-tree. Last verified 11 November 2026.
- Teresa Torres, "How to Prioritize Opportunities" (compare siblings; sizing, market, company and customer factors; avoid false precision), producttalk.org/prioritize-opportunities. Last verified 11 November 2026.
- Clement Kao for Amplitude, "Opportunity solution tree: a visual tool for product discovery" (metric choice, predefining test thresholds and actions, review cadence), amplitude.com/blog/opportunity-solution-tree. Last verified 11 November 2026.
- Bart Krawczyk for LogRocket, "Opportunity solution trees: a list of anti-patterns to avoid" (solution in disguise, features framing, specificity, moment in time, explore at least five), blog.logrocket.com. Last verified 11 November 2026.
- Kasper Junge, opportunity-solution-tree skill (ranking by frequency, intensity, willingness to pay; cheap two-week tests). Last verified 11 November 2026.
- Dean Peters and W. David Turner, opportunity-solution-tree SKILL.md implementations reviewed for structure and gaps. Last verified 11 November 2026.

---
1.0.0, 11 November 2026: first release. Use, adapt and share this skill under CC BY 4.0: credit Afeez Adebayo, link afeezadebayo.com and the skill's download page. This is decision-support guidance, not a substitute for talking to your own customers.