What are opportunity solution trees?

In this article

You'll learn what opportunity solution trees are

If you're looking for a practical guide on how to create OSTs in Delibr, we recommend this article.

A short introduction

In this article, we'll introduce the concept of opportunity solution trees. You will learn what they are, what components they are made up of, how to create them, and why they are an awesome tool for any product team to use in their discovery workflow. 

An Opportunity Solution Tree also referred to simply as an opportunity tree, opportunity map, or by the acronym OST, is a powerful technique for visualizing and informing the path towards achieving the desired outcome. The OST is structured like a tree, as can be seen in the illustration below. At the top of the tree sits the Outcome, one single goal to focus on. Below the outcome sits a set of Opportunities, a combination of user pains, needs, and desires. If we can help alleviate a user's pain or fulfill a desire/need, we're moving closer to achieving our desired Outcome. Next up are the Solutions, which are concrete possible ways to address the Opportunities. Some teams call these bets or features. At the bottom of the tree sit the Experiments. Experiments are activities we can do to increase our certainty that any given Solution is worth pursuing. They could be customer interviews, A/B tests, Wireframes, risk mapping, validation, etc. 

A hands-on example of how to create an OST

If you're completely new to OSTs, allow us to paint a picture using an example.

Setting the stage

Let's imagine that you're working as a Product Manager at Delibr. Delibr's overall mission is to:  Help product teams think better, together.

There are five product teams in total, each team has a main area of responsibility defined by one of the pirate metrics (AARRR). The team you're working on is responsible for the second A, Activation. Activation means helping new users get going in Delibr. 

There's one KPI that has been identified as more important than others for measuring success in this area: The percentage of new teams who become activated* within their first week. This is the team's Northstar metric.
*Activated is defined as reaching 50 in-app activities. 

This is the context you're operating in. Building an app to help product teams think better, together with their team and stakeholders, focusing on activation.

Defining the desired outcome

The desired outcome is something we want to achieve. A goal. It could be a business goal, but it could also be a goal that we know customers have. OSTs can be used for mapping the path to any type of goal.

To build on our example, assume that we know that 5% of all new users go on to become activated. However, the business needs this number to increase to 7.5% in order to match our growth ambitions over the coming year. 

We could then phrase the desired outcome as: Increase the percentage of new teams that become activated by 50% (from current levels), by the end of the year. 

Sidenote: We're saying the percentage of activated teams, not the number. This is because there's another team working on acquisition, meaning the inflow of new teams. They might be working towards a similar desired outcome, e.g. increasing the inflow of new users by 50% by the end of the year. Thus, if we said number instead of percentage, we could in theory achieve our goal without really doing anything - as long as the other team successfully increased the number of signups by 50%. 

Identifying opportunities

Opportunities are pain points, unfulfilled desires, or needs that our users experience that, if we can address them in a good way, will help us get closer to our goal. Opportunities are (almost always) uncovered by interacting with users in one way or another. This could be done through user interviews, analyzing user data, conducting user surveys, and so on. By doing these types of activities, we're learning about the opportunity space.

In our scenario, we might conduct interviews with the people who sign up to our platform and who do not go on to become activated, in order to better understand why they churn. During these interviews, we acquire a better understanding of the reasons why 95% of the people who create an account with us never go on to perform 50 in-app activities. We can add these insights (pain points, unfulfilled needs, or desires) as opportunities to our OST. 

In the interviews we heard the following things:

• "I never completed the signup process because there were too many steps. I just wanted to see the tool, not answer questions about myself" 
• "Our current notes, documents, and user flows life in Confluence and Miro. I didn't find a way to import this to Delibr, and it would be too cumbersome to migrate it manually, so I left" 
• "I didn't understand where to start. The first page of the app was overwhelming and I felt lost"

We take these opportunities and add them to the OST, as in the example above. As we continue to talk to users it's highly likely that we will uncover adjacent opportunities. To make the OST manageable, we recommend that you start grouping insights into categories as you uncover more like we've done under "Import to Delibr" below. 

Ideating solutions

Solutions are features linked to specific opportunities. Sometimes one solution will be helpful in solving several opportunities. 

Some thoughts about solutions:

• Strive towards adding multiple solutions to any single opportunity. And since one solution can potentially solve multiple opportunities, it's OK to add the same solution to each applicable opportunity. This might even help you prioritize solutions later on.
• Involve the entire team in brainstorming possible solutions. Collective intelligence is much more powerful than any one single brain, and different functions (engineers, designers, business stakeholders) engage with problem-solving from different starting points.
• Building things always have a cost. Not only the time it takes to build, but also to maintain code over time. Try thinking about solutions from the perspective of things that do not require new code to be implemented as well. Sometimes removing code could help in reaching an outcome.

Continuing on our example, let us assume that we had a workshop with the team where we brainstormed solutions. Add the solution to your OST, under the corresponding opportunities. 

We now have a map with a set of opportunities that, if we can deliver solutions addressing them, will help us get closer to our goal. Some opportunities might be more valuable than others. We recommend that you focus on these. To prioritize these we recommend talking things through in the team, with external stakeholders, and perhaps even try scoring opportunities using an applicable framework like RICE or similar.

Reduce risk and cost with experiments

Experiments refer to an array of things that we can do to better understand if we should, or should not, invest in any specific solution. Examples of experiments:

• Further user interviews to better understand the solution space
• Surveys
• Getting input on wireframes
• Assumption mapping
• Risk validation
• Simply talking to key stakeholders

Let us go back to the example outlined above, where we now have arrived at three solutions for the problem "Can't import Miro boards to Delibr". At this point, it might be a good time to do a second round of user interviews, this time specifically targeting churned Miro users, in order to better understand this specific opportunity and solution space. We've narrowed our discovery efforts, which will be helpful for extracting meaningful insights. We could create wireframes for each of our solutions, show them to the users we talk to, and so on.

One of the reasons that we want to conduct experiments is that they are generally much cheaper to do than actually building the solutions. Thus, we can for a quite low cost reduce the risk of betting on the wrong solutions. 

Goals with opportunity mapping

What are the goals of opportunity mapping?

• Ensuring that developed features actually drive business goals
  • Opportunity Solution Trees help product teams better connect the features they develop with their high-level business goals. It helps them do this by nudging them to do three things:
  • The benefit of opportunity solution trees is, in a nutshell: ensuring that developed features actually drive business goals.
  • Help avoid becoming a Glossary: Feature factory
• Focus on Opportunities
  • Focus on Opportunities (user needs, pain points, desires, wants) as a necessary step between the Solutions (the features to develop) and the Outcome (the business goal)
• Prioritize Opportunities top-down rather than from a long overwhelming backlog
  • Group the Opportunities into a MECE hierarchical tree structure, allowing them to prioritize them top-down rather than from a long overwhelming backlog
• Conduct the right Experiments
  • Conduct Experiments based on identified risky assumptions to validate that the Solutions will actually drive the Outcome, before doing actual development

Efforts across the map

• Outcome
  • The desired outcome of the work you do. An outcome is a business goal such as an OKR or a KPI.
• Step
  • To help you structure your Opportunities you can make use of Steps, as in steps of what you want the user to do
• Role
  • To help you structure your Opportunities you can make use of Role, as in role or segment of the users you are targeting
• Opportunity
  • Opportunities are user needs, pain points, desires, and wants that you uncover when speaking with your users
• Solution
  • The solution is the feature you are looking to develop to capture an Opportunity
• Experiment
  • Experiments are performed to test risks and problems you have found during the validation phase. 

Want to learn how to work with OSTs in Delibr? 

Here's an article to help you get going. 

Want help getting started? 

Pick a time in the scheduler and let one of our experts help you get started.