Opportunity-Solution Tree (OST): a Product Manager’s Guide

Product discovery is a complex process filled with insights from customers, executives, and teams across the company.

Without a way to structure all this data, you won’t be able to capture all of it, let alone consider it, before making a decision about your product. 

To avoid such gaps, you can use a mental model called Opportunity Solution Tree. It helps product teams effectively discover and capture valuable information. In this article, we’ll show you this model and how to use it to simplify decision-making.

The origins of the opportunity solution tree

The Opportunity Solution Tree (OST) visually represents your plan to reach a desired outcome. 

This system came to life as a way to organize information about product discovery that helps product teams make decisions faster and more effectively.

Teresa Torres, a renowned product management expert, created OST after she noticed that product teams constantly work in two dimensions – trying to understand their customer’s context and test ideas iteratively.

As she describes in one of her blog posts, her team would jump between reviewing customer interviews and experiment results every other week. Each activity was helpful, but the team couldn’t connect the dots and wasn’t sure about the appropriate next steps.

To solve this, Teresa devised a way to connect those two dimensions. The external insights from the users became Opportunities. The team’s ideas to solve those problems became the Solutions. 

Above them, you place a desired outcome – any single metric you want to improve, such as engagement, revenue, NPS, etc. This defines the success of your experiments.

Here’s how the beginning of your OST may look:

OST helps structure the product management process – from ideation to the first experiments. But you should remember that it doesn’t include any way to prioritize solutions against each other. It’s a complimentary method for decision-making and works best when you mix it up with other prioritization techniques.

Building the opportunity solution tree

Let’s build your tree now, diving deeper into each element.

Desired outcome

First, you must define a clear, desired outcome for your OST. This is one goal you want to achieve with the project.

Usually, it’s about improving specific business metrics like retention or customer satisfaction.

Starting with this is crucial. It limits your efforts to initiatives with a clear impact on business objectives.

A good desired outcome must also be close to your team’s expertise. You can’t pick a goal like “improving financial performance companywide” because it has too many potential solutions. 

On the other hand, if you pick an outcome too close to the product, your team might overlook the customers’ pains or goals influencing this metric. 

For example, an outcome like “increase the number of people using a button” might shift your team’s focus on driving the numbers up while ignoring the customer pain underlying a low click rate for the button.

A good desired outcome combines the user value with the business value. It might be about increasing the number of monthly active users or daily logins to the app.

When you come up with yours, put it at the top of your tree:

Opportunities

Once you have the desired outcome defined, we need to define the opportunities of your tree. It’s vital as it takes your focus out of the company and on your customer’s pain points.

The catch is that you’re not looking for things to build here but for signs of your customers experiencing pain or looking to achieve a goal.

Suppose you’re working on a fitness app where users can monitor their weightlifting progress. 

Many customers complained about the lack of a rest timer inside the app, making monitoring the time between the exercises difficult. Now, “rest timer” isn’t an opportunity. It’s an idea for what you should build – a solution.

The “rest timer” might point to many different user pains, such as:

• It’s annoying to switch between apps to count the break times
• I want to measure my training time as precisely as possible
• I don’t like picking up my phone all the time while training

For each opportunity, you can come up with many different solutions. Yes, “rest timer” might solve all three of those, but you won’t know if it’s the optimal solution unless you consider other options.

To identify the right opportunities, you can use several methods you most likely know already:

• 1:1 interviews
• Outbound surveys
• Product data analytics

The same rule applies to any internal conversations you have about your product’s features. Before you jump into the building phase, ask yourself: “What pain do we resolve with this feature?” 

Then, after considering different solutions for this pain, you can clearly decide on the next steps.

Solutions

To come up with the perfect solutions to your customer’s problems, you need to keep a few things in mind.

First, don’t settle for just a handful of ideas. Try to generate as many solutions to every opportunity as possible. 

Yes, some of them will suck – but a bunch of “meh” ideas may spark the fundamental “hell yeah!” ideas.

Also, keep in mind you’re not planning your work here. So, don’t worry about how hard it’ll be to ship the idea – set your imagination free and think of solutions that may appear wild at first. During the experimentation stage, you’ll determine how crazy you want to get.

Don’t forget to ask other teams in the company for insights. Your Design team might tell you about the alternative solutions your customers use to solve the problem. Engineering may expand your viewpoint, showing how this pain is related to a bigger problem at a system level.

Returning to the fitness app example, Engineers can point out that “rest time” can also indicate the user’s need to monitor their overall performance. With that in mind, they can propose a more comprehensive time-tracking system that will help various user groups.

Tests & Experiments

You’ve now got a bunch of exciting ideas on your tree. But if you were to execute each one, you’d probably become broke after a week. Instead, you should test each assumption through low-effort experiments. 

For the fitness app, before implementing an entire time tracking system, as suggested by the Engineering team, you need to de-risk this initiative and break it down into smaller assumptions.

One of them might be, “We think users want to edit the time spent on any exercise mid-workout manually.” If that’s the case, you should develop an appropriate UI to accommodate this need.

But another assumption might also appear: “Users don’t care about manual time correction.” This means you shouldn’t build any new UI.

To test this, you might experiment with users testing both scenarios and sharing their thoughts on both.

To conduct a proper experiment, you need to:

• Specify your assumptions about the feature, customers, technology, etc.
• Clarify the signs of success or failure for each experiment
• Outline the next steps based on the success or failure of the experiment

Okay, but how do you decide which experiments are more significant than others? Generally, you should prioritize them based on their influence on the desired outcome. The more an experiment moves us to the final decision, the more critical it is. 

Other factors are the size of the assumptions (the bigger the assumption challenged, the more important the experiment) or the time and effort needed to experiment.

Should I use the opportunity solution tree?

OST can be a valuable tool for any PM trying to solve complex problems or make tough decisions. 

This method helps you break down broad goals into smaller steps. This clarifies the immediate next steps, keeping them aligned with the overarching objectives.

It also facilitates collaboration across departments, helping everyone understand the rationale behind each decision. This is especially useful if you need to present an idea to executives and highlight the benefits of your solutions vs. the alternatives.

But arguably, the most important is OST’s flexibility. You can apply this tool in various situations to solve various problems. And as a PM, you know how wide this range can sometimes get.

The PM’s hot take

If you are showing stakeholders your OST, congrats, you’ve made it! You might have just made your product roadmap digestible to execs and decision-makers who have less than 5 minutes to grasp your life’s work. The problem? Trying to visualize what are you working on now, and what’s next. In short, the tree doesn’t really show the now-next-later side of things.

Conclusion

The Opportunity Solution Tree, conceptualized by Teresa Torres, offers a structured yet flexible approach to decision-making and problem-solving in product management. 

You can use it to break down complex challenges into manageable parts without losing track of the most important business goals. 

Try implementing OST using Fibery’s whiteboard and bring clarity and effectiveness to your product management strategies.