Opportunity Solution Tree – a simple visual for organizing opportunities

The opportunity solution tree (OST) was invented by Teresa Torres as a means to collect and visualize the opportunity space. It is a model or mental representation that clearly links product goals through user needs to the options for solving those needs. In product discovery, it is a powerful tool for creating a clear structure of what the team wants to achieve.

Recently working with a team to create an opportunity solution tree showed me how powerful the method can be. This gave me the impetus to summarizing the idea in this space. 

I will first explain what it looks like, why it is so helpful, and finally share how to work with the opportunity solution tree in product development.

The Backlog is a bi-weekly newsletter about the undervalued and overlooked in modern product development. It covers product development, self organization, and productivity. I include methods, books, and write about my own experience. The target audience are Product Owners, Scrum Masters, Developers, and project leaders. The Backlog is about getting the most out of product development.
Subscribe to get new posts straight to your inbox. 

The structure of the opportunity solution Tree

As the name suggests the OST has a tree structure with nodes connected by branches as shown in the picture below. 

There are a couple of rules to follow. The “parent” nodes can have multiple “child” nodes but each “child” is only connected to a single “parent”. “Children” are not connected amongst each other. 

On the highest level are the outcomes we want to achieve with the product. In case of using OKRs these are usually the key results. The picture only shows one outcome. Many teams, though, will have a handful of top level outcomes that form the basis of the tree. An example could be “Increase time spent on a specific site by 10%”.

Below the outcomes are all the opportunities connected to them. An opportunity is framed from the user’s point of view. Each one describes a need, pain point, or desire the users have. They are deconstructed over several levels along a branch into the smallest possible issue our customer has (that we can later think about solving). 

An example of an opportunity could be “I am unable to find the information I need right away” or “I am unsure which version of the product I want to buy”. Breaking down the latter example might result in the child opportunities as shown below.

A visual connection between the parent opportunity "I am unsre which version of the product I want to buy" into and the three children opportunities "I am unable to compare different versions", "I don't know enough about the product", and "I don't understand the pricing".

Under the lowest level of the opportunities are the possible solutions, the ideas we have for satisfying the customer needs and desires. These are the features or outcomes we could implement to solve the pain points. Examples are “Create a landing page with the most important information” or “Suggest products to the user based on past purchases”.

Below the solutions are the connected experiments we plan on running. The tests aim to validate the assumptions about whether our solution will work in practice and to check if it actually addresses the linked opportunity.

That’s it. The OST is not overly complicated and easy to understand but it is extremely helpful. Let me try to summarize why that is the case.

How does the opportunity solution tree help?

Overall, the opportunity solution tree gives a clear structure to our opportunity space. It is a simple visual that gives an overview of the team’s ideas on how to reach a desired outcome. That, by itself, is already an immense help for many teams.

Moreover, the two main and most obvious benefits of the OST are focusing on opportunities from the customer’s point of view and clearly displaying the connecting between every solution and the overarching goals. 

Additionally, with its distinct structure the OST helps with three issues in product discovery.

  • It helps in prioritization 
  • It encourages solving problems in iterations
  • It leads to better solutions

It helps in prioritization

The tree structure allows us to quickly eliminate many possibilities when prioritizing where to spend time and resources. We don’t need to compare all of the hundreds of opportunities and deciding where to focus our energy. Instead, we can simply go from the top of the tree and compare only the few that are on the same level. 

Choosing one of these few means we can focus on the branch below the opportunity we chose. We can ignore entire branches consisting of tens and sometimes hundreds of other opportunities. Moving down along one branch we are repeatedly discarding opportunities on sub-branches. We are always only comparing a small number of options on the same level.

We do this one level at a time until we arrive at the lowest level of opportunities and finally choose a single one to focus our energy on. Compared to an unstructured approach where we try to decide between possibly hundreds of things to focus on, using the opportunity solution tree therefore allows for a much smoother prioritization process.

Additionally, if we may come across an opportunity or solution for which we can’t find a connection to a higher level in the tree. It probably makes sense to remove it from our opportunity or solution space, respectively. At the very least it gives us a reason to question if it should be part of the team’s scope. (This helps greatly when discussing unwanted feature requests from powerful stakeholders 😉)

It helps solving problems in iterations

Working from the top of the tree down to the last level of opportunities, we are essentially breaking down large problems into smaller, more manageable problems to solve. This gives us a chance to a) better understand complex problems and b) iteratively solve our user’s issues.

Focusing on solving one small opportunity at a time means we are automatically adopting an agile mindset. We are iteratively providing value in small increments by constantly solving the small problems our users have, instead of focusing on large goals that are solved by a huge release after an extended time of development. 

It leads to better solutions

In solving problems, the first idea one comes up with is probably not the best idea. It is usually the most obvious one. However, many teams – often unknowingly – simply chose to implement the first option they come up with. 

Generally speaking, most teams are not lacking ideas of things to build. In fact, their backlog is usually full with all kinds of features to implement. For most teams, each of these ideas is the first solution that came to mind for one specific opportunity. It is most likely not the best one (or at the very least it hasn’t gone through a rigorous selection process).

The OST encourages us to come up with at least three solutions for each opportunity. This means the team needs to think more deeply about the solution space and actually generate those three ideas. More often than not, this will lead to better solutions.

In her book Continuous Discovery Habits, Teresa Torres actually suggests generating 15-20 ideas per opportunity. She encourages determining the top three solutions out of those and running experiments in order to decide which option to implement. 

Working with the opportunity solution tree

Having explained the structure and (hopefully) convinced you that there are good reasons to try the method, let’s try to understand how to work with the opportunity solution tree.

Building the OST base

The opportunity solution tree is built from the top down. This means we will start with the goals and first add the main nodes, the most high level opportunities. Those main nodes should be based on distinct moments in time the user interacts with the product. 

Below the main nodes, we will add all of the opportunities associated with them, working our way down the tree and breaking the big issues down into more manageable needs and pain points.

For this, we obviously need to have some knowledge about our customers. Ideally, the product team interviews users every week to learn about their pain points and needs. Anything learned there can be added to the opportunities.

The opportunity solution tree is a living document that we will update regularly with growing knowledge of our users. 

Focus on one opportunity at a time 

After structuring the opportunity space it’s time to think about solutions. This is done one opportunity at a time. As mentioned above, in order to determine which opportunity to focus on, we will move down the tree comparing the handful of opportunities on the same level until we are able to zero in on a single one.

In weighing the opportunities against each other, we can use various prioritization methods, e.g. R.I.C.E, Eisenhower Matrix, or MoSCoW.

Regardless of the chosen method, it is important to consider

  1. how many and how often users are impacted
  2. the product’s situation in the market
  3. the strategic context in the company
  4. and the importance to customers.

Once we have figured out which single opportunity to focus on, the team needs to come up with possible solutions. It’s best to come up with as many as possible and then reduce the number. In the end we should come up with at least three solutions for the given opportunity.

Running experiments and choosing what to implement

Now, all that is left to do is deciding which solution of the three to implement. In order to do this, we will run lightweight experiments to test the solutions and the hidden assumptions about them and the chosen opportunity.

This is often done using various prototypes to simulate a specific situation. A common setting for these experiments is moderated user interviews or usability tests. However, since the experiments should be as lightweight and as numerous as possible, we need to limit the time we spend in face-to-face testing. 

Two tools to mention in this context are unmoderated user testing and one-question surveys, in which we ask about past user behavior. These two are options for getting feedback from many users in a very short period of time. 

Finally, after testing the assumptions about our solutions and the connected opportunity, we can either choose a solution to implement or discard the solutions, e.g. because they don’t work or the assumptions about the user needs were wrong.

Then begins product delivery and actually building the solution.

Theory and practice

In product development, we are trying to solve our user’s problems. In product development we also have limited resources and never enough time to implement all of our ideas. It is therefore crucial to make sure we focus on the right problems.

The opportunity solution tree is a powerful tool to help in exactly that, in deciding which problems to focus on and which solutions to prioritize. It helps us frame the problem in such a way that we clearly understand the issue from the user’s point of view and are able to connect our ideas to high level outcomes. 

The above is very focused on the theory of the OST. In the interest of getting this text out the door and keeping it at manageable length, I had to cut my best practices in using the OST. These will be included in one of the next editions of The Backlog. Stick around to and check back soon to learn more about the opportunity solution tree in practice.

(Update: I wrote the follow up.)