A Guide to Using Opportunity Solution Trees

Soon into my new role as Chief Product Officer at Zava - a leading European health-tech startup - I realised we had a problem with Product Discovery. Our product teams were smart and committed, but they were struggling to tie team objectives and key results to research insights, ideas and the day to day work of the squad.

After asking around, Marty Cagan and two others recommended Teresa Torres. After checking out her blog and having a few calls to discuss her team coaching offering we brought her on to coach two of our squads in Product Discovery through a mixture of face-to-face coaching, exercises and online learning.

Having now used them for around 3 years I'd like to share a short guide to using them effectively. 

Part 1: Context

What are opportunity solution trees?

Opportunity Solution Trees are visual tool to help teams develop a mental representation for product discovery. It was developed by Teresa Torres, an experienced product discovery coach and outlined in a blog post in 2016.

I like to define them as follows:

A visual tool that helps product teams follow rigorous product discovery techniques and ensures solutions built deliver outcomes

What format do they take?

Opportunity-solution trees have four basic, connected components connected as follows:

Diagram of an opportunity solution tree
The basic format of an Opportunity Solution Tree

The 4 components


A quantifiable measure of success for the team.


Problems, needs, desires and pain points you've identified through customer research and analysis.


Potential solutions you could build that exploit an opportunity in a way that delivers the outcome


Activities the team runs to test key assumptions

How to build an opportunity solution tree

To build your opportunity solution tree, follow these 8 steps:

Step 1: Define a clear product outcome

Step 2: Map customer opportunities to your outcome that you've identified in your research

Step 3: Size and prioritise the opportunities

Step 4: Pick one or two opportunities to focus on

Step 5: Generate solutions with your product team to exploit the selected opportunities

Step 6: Surface and prioritise assumptions to test for each of your solutions

Step 7: Run experiments to test assumptions and compare/contrast potential solutions

Step 8: Repeat until you discover a solution that delivers your outcome

Why should product teams consider using them?

1. Shared understanding

Shared understanding amongst team members is crucial for effective product discovery. When built collaboratively, OSTs act as an easy-to-understand visual guide to the discovery work of the team.

Unlike documents or wikis, having the tree on a physical or virtual 'space' is easier for the brain to process and 'connect the dots'.

2. Collaborative discussions

Some product teams struggle to explain clearly how what they're doing in product discovery connects to the objectives they've been asked to work towards. This applies to stakeholder conversations and conversations within the team.

The OST makes that easy. As each experiment is visually connected to the outcome it's easy to explain, understand and discuss the work.

3. Avoiding common thinking traps

Product teams often fall into 2 common thinking traps:

  • Falling in love with our solutions
  • Jumping to a solution

Whilst still possible, this is harder to do when work is oriented around an Opportunity Solution Tree. You can instantly spot if a single solution has been generated for a particular opportunity or if there are no experiments associated with a solution.

4. Outputs connected to Outcomes

Many traditional organisations measure teams' success by how much output they have, rather than the the impact they have on the business. Although outputs are important and fast shipping is critically important for effective product teams, blindly delivering outputs without defining outcomes is a slow, painful route to waste and failure.

A better approach is for product teams to focus on ensuring that their outputs deliver outcomes.

Diagram showing how outputs drive outcomes, which in turn drive impact
How outputs drive outcomes, which in turn drive impact

Opportunity-solution trees help by ensuring that outputs are validated through product discovery work.

Part 2: How to make them work

Now you know what they are how do you make them work?

1. Ensure your team has a well-framed product outcome

Opportunity solution trees don't work without product outcomes. The tree makes no sense at all if a teams isn't using it to drive towards an outcome - that's the whole point.

I've also seen product teams struggle when an outcome is poorly framed. One team I was working with had an objective that was akin to "grow company revenue" - an objective so broadly framed (and lagging) it would have resulted in an enormous tree.

When advising teams on product outcomes, I recommend checking they have the following criteria:

  • Connected to the Product Strategy
  • Measurable
  • Agreed at the start of the effort
  • Reflect an observable user behaviour
  • Not too broad
  • Within the team's control
  • A leading indicator, not a lagging indicator

2. Build it collaboratively with the product team

There is little more demotivating for a product team than to be told to go and build someone else's ideas. It's also a horrendous waste of human energy, talent and company resources. Yet this often happens.

If you're on a product team and introducing opportunity-solution trees for the first time, it's 100% OK to bring ideas to the table - but make sure you do the construction of the tree with the team the first time, rather than on their behalf.

Even if you end up pursuing an opportunity and set of solutions along lines you originally envisaged, you'll get a huge energy and motivation boost if the team understand and are bought into the direction.

3. Ask for feedback from business partners

The most successful product teams I've worked with have developed high trust with peers, senior managers and execs. One of the most effective ways I've seen them develop that trust is by explaining their thinking, asking for feedback and genuinely taking it into consideration.

Proactively scheduling a session to walk through an OST is a great way of facilitating that sort of conversation.

4. Colour code impact

As your team progresses with experiments, you'll discover things that work and don't work. A nice twist I've seen a few teams deploy is colour coding results. Deploying a little red and green to distinguish between experiments that have been successful and unsuccessful can give a near-instant clue as to what's working and what isn't.

An example of an opportunity solution-tree with colour-coded experiment results
An example of an opportunity solution-tree with colour-coded experiment results

5. Align your processes to your tree

The work you'll come up with in when developing your tree doesn't happen in isolation from other parts of your process. Depending on how you work, there are likely multiple areas where the work you do using your tree directly links to other areas of your process.

Here are a few examples:

  • Replacing 'feature'-based roadmap items with outcomes or opportunities from your tree
  • Aligning a sprint or cycle to one / multiple experiments testing a solution
  • Using Os from OKRs as your outcome
  • Discussing learning from activities during Review sessions
  • Using demos to get stakeholder feedback on solutions the team are developing

I'd recommend synchronising your internal processes to the work you do in your tree so it becomes a core part of how your teams works instead of "yet another" thing for a team to do.

An example of an opportunity solution tree developed by a team who aligned their solutions to design sprints.
An example of an opportunity solution tree developed by a team who aligned their solutions to design sprints.

6. Avoid the 'part team' anti-pattern

Occasionally, product teams don't have a PM, Tech Lead and Designer. If it's a PM and Designer, this is sometimes justified as "getting ahead of the engineers" or saving precious engineering time. Unfortunately, it's a false economy and I've never seen it. The reality of discovery is you need the combination of all 3 skillsets to ensure solutions generated are valuable, feasible, usable and viable. So, if you don't have a minimum of a Tech Lead, a Product Manager and a Designer on your team, pause and sort that first.

Part 3: Wrapping up

Remember they're just a tool - use your judgement

Occasionally product teams fall victim to magical thinking after discovering and getting excited about a new tool or technique. It's important to remember that opportunity-solution trees are just another tool. They are not the work itself, and they aren't the only tool you'll need to use from your discovery toolbox. Remember to engage your brain, adapt it to suit your purposes - and use it in the appropriate context.

Learn more!

If you're wanting to read more about OS Trees, I'd highly recommend reading Theresa Torres' blog - producttalk.org or employing her services. I doubt you'll regret it.

Get the latest posts in your inbox

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.