Opportunity Solution Tree: How to Use It, Step by Step

8 min read · 2026-10-10

An opportunity solution tree is a visual map that links one outcome you want to reach to the customer needs that could drive it, the solutions that could address those needs, and the small tests that show which solutions work. To use it, you start with a single measurable outcome at the top. Then you add opportunities found in customer interviews, pick one opportunity to focus on, list several solutions for it, and test each one before you build anything.

Product discovery coach Teresa Torres created the framework and describes it in her book Continuous Discovery Habits. Its main job is to stop teams from jumping straight from a goal to a favorite feature. Below you will find a 6-week roadmap to build your first tree, a worked example, how to choose what to work on, and the mistakes that make trees useless.

Definition: An opportunity solution tree is a four-level diagram that connects one measurable outcome to customer opportunities, possible solutions and the assumption tests that check them.

The roadmap at a glance

Goal: Build a working opportunity solution tree and use it to choose and test your next product bet. Duration: 6 weeks, then a weekly update habit

  1. Pick One Outcome (Week 1)

    Agree on the single result the tree will serve.

    • List the outcomes your team is currently asked to move.
    • Choose one that your team can influence directly, such as activation or retention of a feature.
    • Write it as a measurable sentence with a starting value you can check today.
    • Get your manager or leadership to confirm it in writing.

    Milestone: One outcome is written at the top of the tree and approved.

  2. Interview Customers (Weeks 1-3)

    Collect real stories about how customers behave today.

    • Book short interviews with recent users, two per week.
    • Ask about a specific past moment, such as "Tell me about the last time you…", not about opinions or future wishes.
    • After each call, write a one-page summary with the needs, pains and wishes you heard.
    • Keep quotes in the customer's own words.

    Milestone: At least six interview summaries are saved in one shared place.

  3. Map the Opportunity Space (Week 3)

    Turn interview notes into a clear structure of customer needs.

    • Pull every need, pain and wish from your summaries onto cards.
    • Merge duplicates and rewrite each card from the customer's point of view.
    • Group related cards under broader parent opportunities.
    • Draw a simple journey map so each branch follows a step the customer goes through.

    Milestone: The tree shows three to seven parent opportunities, each with child opportunities underneath.

  4. Choose a Target Opportunity (Week 4)

    Pick the one need you will work on next.

    • Compare parent opportunities first, then children inside the winning branch.
    • Score each one on how many customers have it, how much it matters to them, and how well it fits your strategy.
    • Choose the smallest, most specific opportunity you can solve in a few weeks.
    • Write down why you chose it so you can revisit the decision.

    Milestone: One target opportunity is highlighted on the tree with a written reason.

  5. Generate Solutions and Assumptions (Weeks 4-5)

    Explore several ways to solve the target opportunity.

    • Brainstorm alone first, then as a team, aiming for many ideas.
    • Keep three solutions that address the opportunity in different ways.
    • For each one, list the assumptions that must be true: will people want it, can they use it, can you build it, does it help the business.
    • Mark the riskiest assumption for each solution.

    Milestone: Three solutions sit under the target opportunity, each with its riskiest assumption named.

  6. Test and Update the Tree (Weeks 5-6, then weekly)

    Learn which solution deserves to be built.

    • Design a small test for each risky assumption: a prototype, a one-question survey, a fake door or a data check.
    • Set a pass or fail line before the test runs.
    • Run the tests in parallel so you compare solutions, not judge one alone.
    • Update the tree with results, and drop or rework what failed.

    Milestone: One solution has passed its tests and moves to your delivery roadmap.

The Four Levels of the Tree, Explained Simply

Each level answers a different question. If you keep the questions in mind, it becomes easy to know where a sticky note belongs.

The tree reads from top to bottom. Every solution must hang under an opportunity, and every opportunity must connect to the outcome. If you cannot draw that line, the idea does not belong on the tree yet.

  • Outcome: what result do we want? For example, increase the share of new users who complete a lesson in their first week.
  • Opportunities: what customer needs, pains or wishes could move that result? For example, "I forget to practice after the first day."
  • Solutions: what could we build or change to address one opportunity? For example, a daily reminder at the time the user chose.
  • Assumption tests: how do we check quickly that a solution will work? For example, ask ten new users to pick a reminder time in a prototype and see how many do it.

A Worked Example: A Language Learning App

Imagine a team behind a language learning app. Their outcome is to increase the share of new users who complete five lessons in their first week. They run interviews over three weeks and hear stories that form three parent opportunities: "I don't know what level to start at", "I forget to practice", and "The lessons feel too long on busy days."

Under "I forget to practice", they find child opportunities such as "I don't have a fixed time to study" and "I only remember when I open my phone for something else." The team picks "I don't have a fixed time to study" because it came up in most interviews and is small enough to solve quickly.

They then list three different solutions: let users choose a study time during sign-up, send a short lesson by notification at that time, and offer a two-minute "busy day" lesson. Each has a risky assumption. For the first, it is "new users will take the time to choose a study slot." A simple clickable prototype tests it in a few days. Only the solutions that pass move to the delivery plan.

How to Write Good Opportunities

Most weak trees fail at the opportunity level. Teams write solutions disguised as needs, such as "Users need a dashboard." A dashboard is an answer, not a need. Ask what problem the dashboard would solve, and you get the real opportunity, such as "I can't see if I'm making progress."

A good opportunity comes from something a customer actually did or said. It is written in their voice, and more than one solution could address it. Use these checks before adding a card:

  • It describes a need, pain or wish, not a feature.
  • It comes from an interview or real behavior data, not from a guess.
  • At least two different solutions could solve it.
  • It is specific enough that you could solve it in a few weeks, or it has children that are.

How to Choose Which Opportunity to Work On

Comparing opportunities is easier than judging one in isolation. Look at sibling opportunities on the same branch and ask which one matters most right now. You are not looking for the perfect answer. You are looking for a good next bet you can learn from.

Use simple, honest criteria and discuss them as a team.

Write down your choice and the reason. If tests later show you were wrong, you can return to the tree and pick the next sibling without starting from scratch.

  • Size: how many of your customers face this need, and how often.
  • Importance: how much it hurts or helps them when it happens.
  • Market factors: whether solving it would help you stand out or simply catch up.
  • Company fit: whether it supports your strategy and what your team is good at.

How the Tree Connects to Your Roadmap

An opportunity solution tree is a discovery tool. A roadmap is a delivery and communication tool. They work best together. The tree tells you which problems are worth solving and which solutions have evidence behind them. The roadmap shows when you plan to deliver them and in what order. If the difference is still blurry, see roadmap vs project plan.

A practical way to link them is to put opportunities, not features, in the near-term part of your roadmap. For example, a "Now" column can say "Help new users build a study habit" instead of "Build reminders." As tests confirm a solution, you add it as a step under that opportunity with a milestone. This keeps stakeholders focused on the problem and gives your team room to change the solution when tests fail. For layouts that work this way, browse these product roadmap examples or start from the steps in how to make a roadmap.

Common mistakes to avoid

  • Setting an outcome your team cannot influence, such as total company revenue, so pick a product outcome like activation or feature retention instead.
  • Filling the opportunity level with features, so rewrite each card as a customer need and move solutions one level down.
  • Building the tree from internal opinions, so base every opportunity on interviews or real usage data.
  • Testing only one solution at a time, so compare at least three solutions for the same opportunity to avoid falling in love with the first idea.
  • Treating the tree as a one-time workshop output, so update it every week after new interviews and test results.
  • Choosing an opportunity too broad to solve, so go down the branch until you reach a need you can address in a few weeks.

Frequently asked questions

What is an opportunity solution tree in simple terms?

It is a diagram that connects one goal to the customer needs behind it, the ideas that could meet those needs, and the tests that check those ideas. It helps teams choose what to build based on evidence. The format was created by Teresa Torres for continuous product discovery.

Who should use an opportunity solution tree?

Product managers, designers and engineers who work together on discovery use it most. Founders also use it to decide what to build next with limited time. Any team that talks to customers regularly and must pick between many ideas can benefit from it.

How long does it take to build one?

A first version can take about six weeks if you include interviews, mapping and the first round of tests. After that, it is a living document that you update weekly. Small teams with existing interview notes can sketch a first tree in a single working session.

What tools can I use to create an opportunity solution tree?

You can start with sticky notes on a wall, a whiteboard tool such as Miro, or a page in Notion. What matters is that the whole team can see it and that it is easy to move cards around. Keep it in one shared place so it stays current.

Generate this roadmap with AI