Six best practices for maximizing the value of the Opportunity Solution Tree (OST)

Last week in this space, I explored the Opportunity Solution Tree (OST) and its use in product development, specifically in product discovery. This visual method is incredibly useful, as it helps focus on the users’ issues (instead of feature requests) and clearly links the ideas the team comes up with to the overall outcomes it is trying to achieve. Additionally, the opportunity solution tree helps in prioritization, encourages solving problems in iterations, and leads to better solutions.

Email address:

Leave this field empty if you're human:

A quick refresher on the opportunity solution tree

Before we get to the main idea of this text, I want to quickly recall how the opportunity solution tree works. The below picture shows the structure of the OST.

At the top are the outcomes the team is trying to achieve. Below 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. Under that are the possible solutions for a given opportunity. At the very bottom of the Tree are the experiments for validating assumptions about the solutions. 

Having already covered the why, how and what of the opportunity solution tree, I will not expand further on the basics here. Today, I will instead focus on the best practices that I have found to be crucial in maximizing the potential of the OST. Let’s get to it.

(In case you are not familiar with the OST, it really makes sense to read the explanation first. The best practices will make much more sense 😊) 

My best practices in using the OST

The six topics I will cover are:

• If you don’t know where to start, build from the bottom of the tree
• Continuously adapt and evolve the opportunity solution tree
• Customize the tree to fit your needs
• Use the OST as a roadmap
• Don’t test the ideas, but the hidden assumptions
• Come up with as many solutions as possible before reducing to three

If you don’t know where to start, build from the bottom of the tree

In theory, the opportunity is built from top to bottom, starting with the outcomes, through multiple levels of opportunities, all the way to the solutions and to related experiments. However, many teams lack the deep customer knowledge to truly understand user needs, desires, and pains. Many teams don’t even know where to start.

In such cases, a helpful approach is to start by brainstorming and collecting all ideas while leaving the opportunities section of the OST to be filled in later. Almost all teams have a plethora of ideas in their heads and backlogs. Thus, building from the bottom is commonly easier.

Whatever knowledge about customers is available can then be used – along with common sense – to fill in the different levels of opportunities the solutions are addressing. This way, the team can link its ideas to the desired outcomes.

There is obviously a lot of guessing involved here. The team needs to eventually build deeper knowledge through interviews, usability testing, observing users, or gathering usage data. The opportunity space in the OST will not be correct and likely need to be significantly overhauled later on.

Until the deep knowledge is there, though, building from the bottom is a decent starting point. It at least forces you to think from the customer’s point of view and you may already uncover some interesting insights just by visualizing the ideas the team has and attempting to connect them to the outcomes.

Continuously adapt and evolve the opportunity solution tree

The opportunity solution tree is not something that is set in stone once created. It is a living document that evolves with every new insight discovered. Whenever you learn something new about the users or whenever you gain fresh perspective, update the tree. 

The OST is a document that represents the current understanding of the opportunity space. By continuously updating the OST, you are embracing a mindset of continuous improvement, ensuring that the OST remains an accurate and effective representation.

Customize the tree to fit your needs

While the base structure of the OST proposed by Teresa Torres is valuable and perfectly sufficient for the vast majority of teams, it’s important to remember that you can customize it to align with your specific needs and circumstances. 

I encourage you to tailor the tree to suit your team’s unique context and workflow. Some teams may add the assumptions directly in the tree, others will add more than one level of outcomes.

This adaptation to current circumstances is at the heart of agile development. The flexibility allows you to create a framework that works seamlessly for your product development process.

Use the OST as the roadmap

The most obvious use of the opportunity solution tree is as a working document for the team to understand users’ problems, to discuss and iterate on potential solutions. However, it is not only that. With its visual nature the OST is also a means of communication. 

By using it as a shared reference, you foster transparency and encourage effective collaboration. You can use it to show stakeholders the overall goal, what the team is currently working on, where the dependencies to others are, and what the next opportunities are that you will address. 

This is exactly the same overview that a roadmap delivers – in a different format. Thus, instead of creating two documents, I recommend to use the opportunity solution tree as the roadmap. 

A word of advice in this context. The full OST tends to be too large to quickly grasp for those not working regularly with it. When using it as a communication tool it’s therefore important to focus on specific branches or a set of opportunities to avoid confusion and make sure everyone is on the same page.

Don’t test the ideas, but the hidden assumptions

This one isn’t really my best practice. It is more or less as described by Teresa Torres in her book Continuous Discovery Habits. However, the concept is not intuitive and hard to understand at first (it certainly took me a while to fully grasp it). Thus, I want to go into the details here as well. 

When running experiments, don’t test the possible solutions to the opportunities themselves, test the hidden assumptions behind the proposed solutions. 

This is a bigger topic, so I will split it up. Let’s start with why we need to do it.

Limiting the effort

The reason for this is simple, effort and limited resources. It’s much quicker for the team to test assumptions than the full solution. The experiments should be as lightweight as possible.

Instead of building a full prototype or the actual working solution you can use various simple tests (e.g. concierge tests, wizard-of-oz tests, smoke screen or fake door tests) to validate the most important assumptions. Two additional tools to mention in this context are unmoderated user testing and one-question surveys.   

Testing multiple ideas at once

Also, the different ideas for solving a given opportunity, might share assumptions. Thus, testing a single assumption can mean that you are simultaneously derisking multiple solutions at once. This is how it is possible for the best teams to test 15-20 ideas a week, as Marty Cagen states in his great book Inspired. (I never understood how this is possible until realizing that it is the assumptions they are testing, instead of full-fledged solutions.)

Uncovering assumptions

In order to test the hidden assumptions, you need to uncover them first by analyzing each step in the process of users interacting with our product individually (e.g. with a User Story Map). One step at a time, write down all implicit assumptions for that specific interaction. After doing that for the entire process, choose the assumptions that are most important but weak in evidence. Those are the ones to test.

A example of testing assumptions

Since I find the concept of assumption testing hard to grasp, I want to illustrate it with an example. Assume you have an e-commerce shop and you have found out that customers are unsure about which version of the product to buy. You have identified the lowest level opportunity “I am not sure how the product actually works” that you want to focus on. 

The team now came up with the following three options for solving this opportunity

1. Add additional information about the specs on the product page
2. Create a series of blog posts highlighting the product and linking to those from the product page 
3. Sending products to relevant influencers in the space asking to show what the product does for them and link to those reviews from the product page

Mapping out the solutions and determining the hidden assumptions that are most impactful and least certain, you may identify the following assumption that you would like to test. “The user wants to click on a link and get additional information from another website”, an assumption valid for the second and third solution.

To easily test this, you could simply create a link (“click for more product info”) on the product page that leads to an empty page stating that the additional info does not yet exist. You can even add a form where the users can leave their Email address, so that you can inform them once it is built. 

Monitoring how many people click on the link tells you if the assumption is valid or not. In case no one follows the link, you have learned with very little effort that the assumption was wrong. Thus, you can eliminate solution 2) and 3) and after validating other assumptions focus on solution 1).

Come up with as many solutions as possible before reducing to three

Most teams have a backlog full of ideas. For many, unfortunately, each idea is the first solution that came to mind for a single opportunity. It is rarely the best one.

While it may be tempting to settle for the first solution that comes to mind, it’s crucial to explore multiple options to find the best approach. Generating a variety of solutions for each opportunity allows for greater creativity and enables you to consider different perspectives and potential trade-offs. By evaluating multiple solutions, you increase your chances of finding innovative and effective ways to address the identified opportunities.

Thus, it is important to brainstorm as many ideas as possible – up to 20 per opportunity – before whittling down a large number to the three that the team is most confident in. These are the three to test later on.

By expanding your range of options, you increase the likelihood of finding the most suitable and impactful solution for your users.

Conclusion

The opportunity solution tree is an extremely useful tool in product discovery work, helping us make strategic decisions from our customer’s point of view. The OST gives the opportunity space a visual, easy to understand structure. 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. 

Applying the covered best practices, you can unlock the full potential of the OST in your product development process. Remember, with the OST, the sky’s the limit—reach for the branches and watch your ideas bloom!

Coverphoto by Johann Siemens on Unsplash