Opportunity Solution Tree: Build One From Real Customer Calls (2027)

Most product trios know the opportunity solution tree. Far fewer can say where the branches on their own tree came from. This guide shows how to build one from recorded customer calls, transcribed by hand or captured with BuildBetter Recordings. Every opportunity on the finished tree links back to a verbatim quote, a timestamp and a named account. It includes a step-by-step method, a copyable HTML template and a worked B2B onboarding example built from 14 calls.

What Is an Opportunity Solution Tree?

An opportunity solution tree (OST) is a visual map that connects one desired outcome to the customer opportunities that could drive it, the solutions that could address each opportunity, and the assumption tests that show whether a solution will work. Opportunities here means unmet needs, pain points and desires.

Your team may already have one on a whiteboard. Most of these trees are built from memory, sales anecdotes and whoever argued hardest in the workshop. Ask where a branch came from and nobody can name the call where a customer said it.

The method comes from Teresa Torres, product discovery coach and founder of Product Talk. She wrote about the tree on her blog around 2016 and made it the center of her 2021 book Continuous Discovery Habits. The book pairs the tree with several other habits:

• weekly customer touchpoints run by the product trio (PM, designer and engineer)
• story-based interviewing
• interview snapshots
• assumption testing

The tree has four levels:

• Desired outcome: one measurable product outcome the team can influence.
• Opportunities: needs and pains stated from the customer's point of view, never as features.
• Solutions: specific ideas that address one target opportunity.
• Assumption tests: small experiments that check the riskiest belief behind each solution.

This guide focuses on inputs, because a tree can only be as good as the evidence it is built on. The method below builds every opportunity node from a recorded customer call, with the quote and timestamp attached. That way you can trace each branch back to something a customer said.

Opportunity vs. Solution vs. Outcome: The Distinction Most Trees Get Wrong

An opportunity is something a customer could say about their own work without knowing your product exists. If the statement names a feature, it is a solution. Torres places opportunities in the problem space and solutions in the solution space. A statement that only makes sense once your product exists is a solution in disguise.

Three contrast examples:

• Opportunity: “I don't know which integration to set up first.”
• Solution disguised as an opportunity: “Needs a setup wizard.”
• Outcome disguised as an opportunity: “Increase activation.”

Opportunities also nest. A parent opportunity is a broad need, such as “I can't get to first value on my own.” Child opportunities are the specific moments inside it, such as “I don't know where to start” or “I can't tell if the import worked.” Torres recommends working down to a solvable child opportunity before you generate ideas. A parent as broad as “onboarding is hard” tends to produce generic solutions. A specific moment usually makes the right fix much easier to see.

The root of the tree needs the same discipline. Torres separates three kinds of metrics:

• Business outcomes, such as revenue or retention.
• Product outcomes, which measure a change in customer behavior inside the product.
• Traction metrics, which measure use of one specific feature.

A good root is a product outcome the trio can move. One example is the share of new accounts completing their first integration within 14 days. Revenue sits too far from team decisions to work as a root. A traction metric already assumes a particular solution.

Why Most Opportunity Solution Trees Break

Most opportunity solution trees fail because of their inputs, not their structure. The diagram looks right, but the evidence underneath it is weak or missing. These are the usual failure modes:

• Built from memory. The team rebuilds opportunities in a workshop. Recency bias and the loudest stakeholder decide what appears on the tree.
• Paraphrased into product language. “Confusing onboarding” replaces what the customer actually said. The specific moment, the workaround and the context disappear, so the solutions become generic too.
• Counted by mentions, not accounts. One frustrated customer who raises the same issue four times in one call ends up outweighing four accounts that each raised a different issue once.
• Solutions in the opportunity layer. “Bulk edit,” “SSO” and “better dashboard” show up as opportunities. At that point the tree is a feature backlog drawn as a diagram.
• No assumption tests. The team picks a solution and goes straight to building it. The tree never changes and becomes a one-time workshop output.
• Too many outcomes. A single tree tries to serve activation, retention and expansion at the same time, so it has no clear target.

Each of these problems is fixed by the same discipline. Capture what customers said, keep the source attached, and count distinct accounts.

How to Build an Opportunity Solution Tree From 10-20 Recorded Customer Calls (Step by Step)

You can build an evidence-based opportunity solution tree with recordings or transcripts, a spreadsheet and a shared document. No specialized tool is required. If you work manually, expect roughly 30-45 minutes of extraction for each hour-long call.

Step 1: Pick one desired outcome

Write it as a measurable product outcome with a timeframe. Reject any outcome the trio cannot influence directly. Build one tree for one outcome.

Step 2: Select 10-20 recorded calls relevant to that outcome

Mix the call types:

• discovery interviews
• onboarding calls
• support escalations
• churn or save calls

Prefer a variety of accounts over many calls with one account. Record the account name for every call.

Step 3: Extract opportunity statements in the customer's words

For each statement, capture:

• the verbatim quote
• call ID and timestamp
• account
• speaker's role
• any workaround the customer described

Do not paraphrase yet. When a customer asks for a feature, leave it off the opportunity list. Log it in a separate “solution hints” column instead.

Step 4: Rewrite each quote as a first-person need

Keep the original quote attached to the rewrite. For example, “we spent two days guessing which connector to try first” becomes “I don't know which integration to set up first.”

Step 5: Cluster into parent and child opportunities

Group statements that describe the same underlying need, and aim for 4-8 parents. Each child should sit under only one parent. If a statement fits two parents, it is probably two separate statements.

Step 6: Size by distinct accounts, not mentions

For each parent, record three numbers:

• statement count
• distinct accounts
• segment fit, meaning whether those accounts match your target customer

Sort by distinct accounts first.

Step 7: Choose one target opportunity

Filter the candidates on four criteria:

• Breadth: how many distinct accounts raised it.
• Outcome connection: whether solving it moves the root metric.
• Ability to act: whether the trio controls the fix.
• Strategic fit: whether it serves the segment and direction you are betting on.

Write a one-sentence rationale and keep it on the tree.

Step 8: Generate at least three solutions

Torres frames this as a compare-and-contrast decision, not a yes-or-no decision. Three options force real tradeoffs and keep the team from committing to its first idea. Include at least one option that is non-software or cheap to build.

Step 9: Write the riskiest assumption for each solution

Use Marty Cagan's four risks as prompts:

• Value: will they want it?
• Usability: can they use it?
• Feasibility: can we build it?
• Business viability: does it work for the business?

Torres's five categories (desirability, viability, feasibility, usability, ethical) work just as well. Pick the one assumption that would kill the solution if it turned out to be false.

Step 10: Design the smallest test

These options are listed from weakest to strongest evidence:

1. a follow-up conversation
2. a prototype walkthrough
3. a fake-door or concierge test
4. a small working release used in the customer's real workflow

Set a pass/fail threshold before you run the test. Testing protects you from your own confidence: Kohavi and colleagues found that only about one-third of ideas tested at Microsoft improved the metrics they targeted.

Step 11: Update the tree weekly

Each new call can add statements, change account counts or create new child opportunities. Archive any opportunity that gets no new evidence for 6-8 weeks.

Opportunity Solution Tree Template (HTML Table You Can Copy)

A table is the best format for an evidence-based opportunity solution tree because it keeps the quote, source and account count attached to every node. Sticky notes lose all three as soon as the board gets crowded. Copy this structure into a spreadsheet or document:

The table maps one-to-one onto Torres's visual tree. Indentation or a “parent ID” column preserves the hierarchy. You can sort by distinct accounts, filter by status and draw the diagram later for presentations. Keep the table as the source of truth and treat the diagram as a view of it.

Worked Example: B2B Onboarding Tree From 14 Calls

This is an illustrative walkthrough with realistic numbers, not a customer case study. It shows how the steps play out on a typical B2B onboarding problem.

Outcome: Increase the share of new accounts that connect their first integration within 14 days of signup.

Inputs: 14 recorded calls across 12 distinct accounts. The set included onboarding kickoffs, support escalations and two churned-trial interviews. Extraction produced 31 opportunity statements, each with a quote and timestamp. It also produced 9 feature requests, which were logged as solution hints.

The mentions-vs-accounts trap: In the debrief, opportunity 3 felt like the biggest problem, because one account raised it four times in a single escalation call. Ranked by distinct accounts, it comes in fifth.

The decision: The trio chose opportunity 1. It has the most distinct accounts (7 of 12), it sits directly on the path to the first integration, and the fix is within the trio's control. Opportunity 2 also affects several accounts, but solving it depends on customers' IT processes. Opportunity 4 is the runner-up and is recorded as the next target.

Three solutions for opportunity 1:

• (a) A signup question about the customer's primary use case that recommends one first integration.
• (b) A guided setup checklist ordered by use case.
• (c) A 20-minute done-with-you setup call offered to new accounts.

Riskiest assumption and smallest test for each:

• (a) Value: customers will accept a recommendation instead of browsing. Test: ship the recommendation to a slice of new signups for two weeks and compare their first-integration rate with everyone else's.
• (b) Usability: customers will follow a checklist without abandoning it. Test: a prototype walkthrough with 5 new users. Nielsen's model suggests 5 users surface about 85% of usability problems.
• (c) Business viability: CS can staff the calls without delaying other work. Test: offer the call to 10 accounts and measure the hours booked.

What the team records afterward: which test passed, how the tree changed (new children, updated counts, archived nodes), and the next target opportunity.

Why a Small Working Release Is the Strongest Assumption Test

A small working release used in a customer's real workflow is the highest-confidence evidence an opportunity solution tree can hold. Interviews and prototypes measure what customers say they would do. A release measures what they actually do.

This is the Ship First loop:

1. A customer asks for something.
2. You build a small working answer.
3. They try it in their own workflow.
4. What happens next tells you what to improve.

The loop's three themes map onto the tree:

• Start with the customer's job: keep the real request, the workaround and the person attached to every statement (Steps 3-4).
• Choose the right experiment: match conversations, prototypes, surveys or releases to the specific assumption you are testing (Steps 9-10).
• Follow the release through: check whether customers complete the job, whether they return, and whether they benefit from the next iteration (Step 11).

Several other methods fit alongside this one:

• Continuous Discovery Habits supplies the tree.
• The Lean Startup supplies the testing mindset through build-measure-learn and validated learning.
• Shape Up uses appetite and shaping to size the solution you ship.
• Cagan's four risks frame the assumptions.

Common Opportunity Solution Tree Mistakes

Most opportunity solution tree mistakes put the team's opinion where customer evidence should be. Watch for these:

• Starting with solutions, then working backward to find opportunities that justify them.
• Paraphrasing customers before clustering, which strips out the specific wording that makes good solutions obvious.
• Sizing by mention count, or by how emotional a call felt, instead of by distinct accounts.
• Choosing more than one target opportunity at a time. This spreads the trio thin and makes test results hard to read.
• Generating one solution per opportunity, which removes comparison and anchors the team on the first idea.
• Testing the easiest assumption instead of the riskiest one.
• Treating the tree as a one-time workshop output instead of updating it after each new call.
• Drawing only from sales calls or only from support tickets, which skews the tree toward one stage of the customer journey.

How Many Customer Interviews Do You Need for an Opportunity Solution Tree?

Ten to twenty calls is enough for a first opportunity solution tree around one outcome. After that, keep adding calls weekly, in line with Torres's habit of weekly customer touchpoints.

Research on qualitative interviewing supports this range:

• Guest, Bunce and Johnson (2006): 12 interviews reached thematic saturation, and the basic meta-themes appeared after 6.
• Hennink and Kaiser (2022): a systematic review found saturation typically within 9-17 interviews.
• Griffin and Hauser (1993): 20-30 interviews in one homogeneous segment surfaced roughly 90-95% of customer needs. If your segments vary, keep going past 20.

The saturation signal: Watch the last 3-4 calls. If each one adds statements only to existing parents and no new parents appear, the top of the tree is stable enough to pick a target.

You do not need to start new interviews to get there. Onboarding calls, support escalations and churn calls already on file are valid sources, as long as they relate to the outcome.

For B2B teams, count accounts, not people. Three users from the same account count as one account for sizing.

When You Need Tooling for an Evidence-Based Opportunity Solution Tree

The manual method works for one trio handling up to about 20-30 calls a month. Past that volume, extraction time and lost timestamps become the bottleneck. The same happens once evidence also lives in support tickets and Slack threads.

Signs you have outgrown spreadsheets:

• quotes that can't be traced back to a call
• duplicate statements across teammates' sheets
• account counts that go stale
• evidence split across calls, tickets and Slack

BuildBetter Recordings captures Zoom, Meet, Teams and Webex calls with a bot or with local no-bot recording, and also records on mobile. It transcribes each call automatically and extracts signals that keep the quote, timestamp and account intact. Support tickets, surveys and Slack threads flow into the same place. Once the trio picks a target opportunity, BuildBetter can draft the PRD in Documents and create Linear or Jira tickets with the evidence attached.

None of these tools is required. The eleven steps above work with a spreadsheet and a set of recordings.

Opportunity Solution Tree FAQ

Who created the opportunity solution tree?

Teresa Torres, product discovery coach and founder of Product Talk. She introduced it on her blog around 2016 and made it central to her 2021 book Continuous Discovery Habits.

What are the four levels of an opportunity solution tree?

• Desired outcome: one measurable product outcome.
• Opportunities: customer needs, pains and desires, stated from the customer's view.
• Solutions: specific ideas addressing one target opportunity.
• Assumption tests: small experiments checking the riskiest belief behind each solution.

What is an opportunity in an opportunity solution tree?

An unmet need, pain point or desire that a customer could describe about their own work without knowing your product exists. If the statement names a feature, it is a solution. If it names a metric, it is an outcome.

How is an opportunity different from a feature request?

A feature request is a customer's proposed solution. The opportunity is the need behind it. Log the request as a “solution hint,” work out what need prompted it, and put that need on the tree.

What makes a good desired outcome?

A product outcome the trio can directly influence, measured within a timeframe. One example is the share of new accounts connecting their first integration within 14 days. Revenue is too far removed from team decisions to serve as the root.

How do you prioritize opportunities on the tree?

Size each opportunity by the number of distinct accounts affected. Then filter by connection to the outcome, the team's ability to act and strategic fit. Pick one target opportunity at a time.

How many solutions should each opportunity have?

At least three, so the team compares options instead of committing to the first idea.

How often should an opportunity solution tree be updated?

Weekly, as new customer conversations add evidence. Archive opportunities that get no new evidence for 6-8 weeks.

Further Reading on Product Discovery

1. Ship First: How to Build Self-Improving Products by Spencer Shulem. Free, 24 chapters, PDF and EPUB. Part 1 covers continuous discovery and shaping the bet. Part 2 covers grounded personas and prototypes. Part 3 covers the shipping loop, onboarding and adoption.
2. Customer-Led Development by Spencer Shulem, the longer book that Ship First accompanies.
3. Continuous Discovery Habits by Teresa Torres.
4. Inspired, Empowered and Transformed by Marty Cagan.
5. The Lean Startup by Eric Ries.
6. The Four Steps to the Epiphany by Steve Blank.
7. Shape Up by Ryan Singer.

Sources and Further Reading

• Teresa Torres, Product Talk: https://www.producttalk.org/
• Shape Up by Ryan Singer (free online): https://basecamp.com/shapeup
• Lean startup (Wikipedia): https://en.wikipedia.org/wiki/Lean_startup
• Customer-Led Development on Kindle: https://www.amazon.com/dp/B0HM3FMZLN
• Guest, Bunce & Johnson, “How Many Interviews Are Enough?”, Field Methods, 2006
• Hennink & Kaiser, “Sample sizes for saturation in qualitative research,” Social Science & Medicine, 2022
• Griffin & Hauser, “The Voice of the Customer,” Marketing Science, 1993
• Jakob Nielsen, “Why You Only Need to Test with 5 Users,” Nielsen Norman Group, 2000
• Kohavi et al., “Online Experimentation at Microsoft,” 2009

Get Ship First Free

Ship First is written by Spencer Shulem, cofounder and CEO of BuildBetter, who has nearly twenty years of experience in product and user research. The book explains how to turn customer evidence and small working releases into a repeatable improvement loop. That loop is the natural next step once your opportunity solution tree has picked a target.

It is free, with 24 chapters and 6 illustrations, available as PDF and EPUB with an email signup.

Get Ship First free →

Make churn optional.

BuildBetter records every customer call, with or without a bot, and connects each call to your tickets, Slack threads and surveys. Every opportunity on your tree stays linked to the quote and account it came from, and the target you choose can become a PRD and tickets.

Make churn optional. Book a demo →