A general introduction to opportunity solution trees
In this article
What are Opportunity Solution Trees, why should you use them, and how are they used at Delibr
If you're looking for a practical guide on how to create OSTs in Delibr, click here.
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 opportunity tree, opportunity map, or by the acronym OST, is an extremely powerful technique for visualizing and informing the path towards achieving a desired outcome. The OST is 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 pain, or fulfil 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 calls these bets, or features. At the bottom of the tree sits 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 and 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's five products teams in total, each teams 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 whom 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 an desired outcome
A 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 goes 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 with 50% (from current levels), by the end of the year.
Sidenote: We're saying percentage of activated teams, not 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 with 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 amount of signups with 50%.
Opportunities are pain points, unfulfilled desires or needs that our users experience that, if we can adress them in a good way, will help us get closer to 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 does 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 goes 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 where too many steps. I just wanted to see the tool, not answer questions about myself"
- "Our current notes, documents, and user flows live 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.
Solutions are the bets that we can think of that will help our users, and in turn us, reach the desired outcome.
Some thoughts about bets:
- Strive towards adding multiple bets to any single opportunity. And since one bet can potentially solve multiple opportunities, it's OK to add the same bet to each applicable opportunity. This might even help you prioritize bets later on.
- Involve the entire team in brainstorming possible bets. 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 maintain code over time. Try thinking about bets from the perspective of things that does 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 bets. Add the bets 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 refers to an array of things that we can do to better understand if we should, or should not, invest in any specific bet. Examples of experiments:
- Further user interviews to better understand the solution space
- 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 bets 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 bets, show them to the users we talk to, and so on.
One of the resons 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 with 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
- The desired outcome of the work you do. An outcome is a business goal such as an OKR or a KPI.
- To help you structure your Opportunities you can make use of Steps, as in steps of what you want the user to do
- To help you structure your Opportunities you can make use of Role, as in role or segment of the users you are targeting
- Opportunities are user needs, pain points, desires, wants that you uncover when speaking with your users
- The solution is the feature you are looking to develop to capture an Opportunity
- 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.