Guide to Making Opportunity Solution Trees Come to Life

What is an Opportunity Solution Tree?

The Opportunity Solution Tree, also referred to simply as Opportunity Tree or by the acronym OST, is an approach to linking problem and solution discovery. It is based on an artefact that is structured like a tree. At the top is the Outcome, one single goal to focus on. Next come one or a couple of levels with Opportunities, a combination of user activities, pains, needs and desires. Next come Solutions, as concrete possible ways to address the Opportunities. Finally Experiments are added to the tree, things needed to do to validate the Solutions.

This article draws heavily on the work by Teresa Torres, who came up with the approach and described it in even more detail in her book Continuous Discovery Habits, one of the best books on product management.

At Delibr we regularly host training programs for Product Managers who want to learn how to work with Opportunity Solution Trees in order to become more outcome-driven and increase their autonomy. You can find a list of the upcoming training programs at the Delibr Academy.

‍

Benefits of Opportunity Solution Trees

By having the outcome (the desired business goal) at the top of the Opportunity Solution Tree the requirement that all solutions in the tree should link up to that outcome is made clear. That makes it easy to check that each solution plausibly drives the outcome, tracing the lines up through the tree. This nudges product teams to be more outcome-driven, helping them move away from being a feature factory.

It is tempting to go directly from outcome to solution, not taking the time to think about the user perspective. The rules of working with Opportunity Solution Trees state that an Opportunity (a pain point, need, want, or desire that users have) must come between the Outcome and the Solution in the tree. This goes further than Impact Mapping method, where it is only necessary to think about what type of user will drive the business goal (formulated as the "Actor").

When starting to look into different Opportunities, i.e. pain points, needs, wants, and desires that users have, it is easy to get overwhelmed. To understand enough about an Opportunity to develop a good Solution for it you will need to investigate it further. However, you will quickly find hundreds of Opportunities, and it will neither be possible nor worthwhile to investigate each of them further. To handle this the Opportunity Solution Tree method is to merge and structure all opportunities into a tree, with high-level opportunities, or even roles or steps at the top, with more granular opportunities further down. Doing this enables you to prioritize top-down in the tree, not even looking twice at sub-problems to unimportant high-level problems.

There are always lots of things to potentially research, investigate and validate. It is great to interact with users, but product teams that do, run the risk of doing it for the sake of doing it. Having an Opportunity Solution Tree where it is clear what opportunities and solutions the team is focusing on also helps to put experiments in context. It helps the team make sure that the right underlying assumptions are actually verified, and avoid producing research that lands "on the shelf". The OG on the lean/agile block Toyota Production System put the underlying principle really well: "Use the 'pull' system to avoid overproduction."

‍

How to work with Opportunity Solution Trees

The 6-steps of working with Opportunity Solution Trees

1. Negotiate Outcome with Leadership

At the top of the tree is the Outcome. To be able to work with an Opportunity Solution Tree, you will need some stability here. That is what allows you to work with and iterate on the tree below. It does not mean that you cannot change it if you make radical new findings, but that you should at least have an agreed ambition with leadership that the Outcome should stay for a couple of months. If that is not possible it is better to have two Outcomes than to not have any stability. From a starting point of more than one Outcome, it is often possible to move to a Now-Next-Later roadmap, with all Outcomes except one in the Later column.

When finding a good Outcome to work towards, it is important that it both feels appealing to leadership and feels possible for your product team to work towards. This means that it is often a good idea with a bit of back-and-forth to find a good Outcome. If you are working with OKRs, it is often a good idea to use the OKR as the top of the Opportunity Solution Tree, provided it has been formulated in a way that you can work with. If you have found a good North Star metric, it is often possible for that to stay at the top of the Opportunity Solution Tree for a longer period of time (in fact, that can be a good way to evaluate whether it is a good North Star metric).

2. Discover Opportunities by talking to Users with Product Team

When the Outcome is clear the next step is to take the perspective of the user, and try to explore the specific pain points, needs, wants, and desires that users have, that is preventing them from acting in a way that drives the Outcome - i.e. the Opportunities in the Opportunity Solution Tree.

The main way of exploring Opportunities is by interviewing users and potential users. Setting up a good flow of interviews is key to success. Having at least one per week a good benchmark. It is valuable to involve more than one person in the interviews. Teresa Torres suggests that at least a core Product Trio consisting of PM, Designer, and Tech Lead should conduct the interviews.

When exploring Opportunities it is helpful to explore and different use cases, and then for these use cases to explore what steps they consist of, and to try to always map an Opportunity to a step in a use case. This approach makes the Opportunities more concrete and specific which allows for learning more deeply what is actually going on, including relevant context and the nuances of the user's motivations.

It can be helpful to use Roles and Steps as nodes in the tree to add structure to the Opportunities.

• Roles can be different user types, cover different customer segments or different personas - all depending on what is helpful to differentiate their needs (as explained really well in this article by Hope Gurion).
• Steps can be anything from different but adjacent jobs-to-be-done down to more specific steps in a use case or a user flow.

You should work towards having a tree of Opportunities that is MECE (mutually exclusive, collectively exhaustive), meaning that the nodes are distinct from each other (mutually exclusive), yet together sum up to the whole of the step above (collectively exhaustive). The "collectively exhaustive" part is especially important for the top levels, i.e. that all the major areas of problems that users face are covered, and if roles/steps are used, that all relevant roles/steps are covered.

3. Prioritize Opportunities in the tree with Team and Stakeholders

It is easy to get overwhelmed when looking across the different Opportunities. And for working with an Opportunity to be useful, you'll need to drill down a bit into the Opportunity, generate several Solutions to discover, validate and refine further. That's why you need to prioritize already at the Opportunity level, before you move on to generate Solutions.

Because you already have the Opportunities organized in a MECE tree, it is possible to prioritize top-down, working yourself down in the tree until you have one prioritized Opportunity. Start at the top, look down at the children, and select Role/Step/Opportunity to prioritize, then go deeper until you have one single Opportunity to focus on.

By doing this, you don't have to evaluate and compare all the opportunities (as an opportunity that is a part of a lower prioritized opportunity is by definition also lower opportunity). This saves a lot of time and allows for increased focus.

There are a couple of different approaches to compare opportunities. One approach, borrowed from the JTBD methodology, is to look at how important it would be for the pain, need, want, desire to be fixed, and then at how well it is served with current solutions. Another approach is something akin to "RIC", i.e. RICE without the E, since Effort is nonsensical for opportunities where the Solution is not known. And in reality, "strategic focus" often guides the prioritization of the very top level, especially if that is a role or a step.

4. Create multiple Solutions for top Opportunity with Product Team

Even when focusing on a single Opportunity, to avoid falling back on the feature factory trap, and to really find the best solution, it is critical to open up the solution space. This solution discovery is a core part of the double diamond philosophy. It is often the case when generating a lot of solutions, that the first couple of solutions are not the best, but the really good ideas start to come up as you force yourself to go beyond ten ideas.

The suggestion is not to create fifteen Solutions in perfect detail. The ideas at the far end of the long tail are often just expressed as a single user story or a lo-fi sketch. Many ideas are often easy to dismiss, and only a few need to be refined further, with a written PRD, a proper user story map, and hi-fi designs.

5. Identify and assess risks across Solutions with Team and Stakeholders

As the strongest candidate Solutions are expressed in more detail, it becomes possible to identify their risky assumptions across the big four risks - Value risk (users won't buy or want to use it), Usability risk (users won't be able to use it), Feasibility risk (it will be harder to build than thought), and Business Viability risk (it will not fit with our overall business model).

These risky assumptions can then be mapped across two scales, impact (if risk materializes) and uncertainty (knowledge about whether the risk will materialize). If there are risks with high impact-high certainty they either need to be handled by adapting the solution or by addressing them in the rollout plan, or if not possible, by either accepting them or by dropping the solution. The risks with high impact-high uncertainty needs to be evaluated further.

6. Validate assumptions in User Experiments with Product Team

For the risky assumptions with high impact and high uncertainty, the uncertainty can be reduced with product validation techniques. The experiments should ideally be designed to test assumptions rather than solutions.

It is often the case that several Solutions share the same risky assumption. This means that a single experiment can test aspects of several different solutions. Taking a value risk as an example, it does not matter what Solution is used to show users a login history, if users are not interested in looking at past logins.

It is also way faster to test assumptions than to test solutions. The type of experiments to depends on the type of risk. Taking a feasibility risk as an example, it is much cheaper to test writing a call to an API and making sure the response makes sense, rather than building the entire Solution - which makes a big difference if it turns out that the API did not return the information needed.

If the underlying assumptions were identified properly, that means that when all assumptions have been validated, the solution itself has also been validated.

Do one cycle and then continue iterating

As you start working with Opportunity Solution Trees, work through all steps 1-6, then iterate across 2-6 to deepen the understanding. As you get validated and refined Solutions, continue into to development. Then come back to and evaluate the whole chain across Outcome, Opportunities, Solutions, and Experiments.

The Outcome should remain stable for some time - but whenever it changes, either because it is fulfilled, because of some radical discovery, or because of a change in strategy - start over from step 1, potentially with an entirely new Opportunity Solution Tree.

An Opportunity Solution Tree example

To illustrate the above, here is a simplified example of what an Opportunity Solution Tree can look like.

In reality, if steps are used, there are often at least 4-5 steps, with several opportunities below, and often with sub-opportunities below the major opportunities, and like discussed there should be many more solutions for the top opportunity, and then experiments below.

‍

How to use Opportunity Solution Trees to get a Product-Led Process

Becoming Product-Led with Opportunity Solution Trees

Generally, it can be said that new features or solutions come into play in at least one of three different ways.

• Top-down via Leadership / Sales - a.k.a. "Just build this". Typically for a specific customer (we will get or get to keep X customer if we do Y), or based on a new business requirement (e.g. need to adapt to GDPR).
• Bottom-up via User feedback from customer support. Any up-and-running product with users and customer support will get bombarded with feedback and customer requests. To handle this inflow something like RICE is often applied.
• Product-led via Discovery of Opportunities and Solutions based on an agreed Outcome.

As Product Managers use Opportunity Solution Trees and build more trust they move towards more autonomy, which means that a larger share of what they develop comes into play in this Product-led way.

For PMs to be able to work in this way with Opportunity Solution Trees, they have an agreed business goal to work towards, it must be possible to link the goal to some specific type of user trying to achieve something specific, and it must be ok to not have a predetermined feature to develop (it's ok to have a hypothesis, but it must then be possible put that as a Solution in an Opportunity Solution Tree, and to then let it go if a better Solution is found).

Including Opportunity Solution Trees in the Product Management Process

When laying the steps of working with Opportunity Solution Trees on top of the Product Management Process, it is clear that for Product Managers that use the method, it is absolutely central to their work.

‍

Pitfalls when working with Opportunity Solution Trees

‍

Help us help PMs work with amazing Opportunity Solution Trees

In theory, working with Opportunity Solution Trees is pretty straight forward. But in practice, there are a lot of nitty-gritty details to get it right, and many teams want to but don't quite manage to get going.

At Delibr, we pride ourselves on working really closely with our Product Manager community. And lately, we heard more and more PM interest in Opportunity Solution Trees. We dug into this with lots of interviews and prototyping, and now have a good solution for working with Opportunity Solution Trees (you have seen some hints from it earlier in the article).

But we want to nail it! To do that we must learn even more about what stops PMs from getting started with Opportunity Solution Trees, and what prevents them from working smoothly with the full Outcome-Opportunity-Solution-Experiment chain once they are up and running.

So, help us help PMs level up in the ladder of autonomy. Join our beta and put the theory of opportunity solution trees into practice with Delibr.