Opportunity solution trees are a powerful tool to help you plan and manage the messiness that accompanies the product discovery process.
However, opportunity solution trees are often misused.
There are a few common anti-patterns that not only limit the effectiveness of your discovery process, but derail your whole product.
In this article, you will learn what opportunity solution trees are, the most common anti-patterns associated with them, and how you can avoid these.
An opportunity solution tree is a discovery visualization tool designed to help product teams determine the best path to achieve a desired outcome. An OST also helps PMs communicate their desired outcome along with the potential obstacles and strategies to overcome them:
The starting point of the opportunity solution tree is the product outcome — a change in user behavior you want to drive to achieve your business outcomes, such as an increase in engagement or adoption.
Then, you have unarguably the most essential element — the opportunity. This represents a distinct user problem that we can solve to drive the outcome.
Opportunities often also have children opportunities, that is, more atomic problems that solve a part of the parent problem.
For each opportunity, you can map potential solutions to the problem, and for each solution, you can test individual assumptions to de-risk before a bigger investment.
You can then use the opportunity solution tree to:
The building blocks of opportunity solution trees are relatively straightforward and unsurprising
However, the true power of opportunity solution trees lies in nuisance. For the same product, you could build a very insightful, powerful opportunity solution tree or just waste time ineffectively mapping your problem and solution space.
To avoid wasting your time, keep the following anti-patterns in mind:
Mixing the problem and solution space is very common.
A good sanity check is to stress-test each opportunity by checking if there’s more than one unique way to solve a given problem. If there isn’t, that’s probably a solution in disguise.
For example, if you define “I’d like to skip ads” as an opportunity to solve, there’s an already implied solution — skipping ads:
That’s a solution in disguise.
But if you dig deeper and understand better why users want to skip ads, you might learn that most of them believe watching ads is a waste of time.
That’s a problem you can solve in numerous ways, such as letting them skip, improving ads relevance, making ads more engaging, and so on:
Always stress-test if there’s more than one potential solution to a problem. If there’s not, you usually need to dig deeper to truly understand your problem and underlying opportunities.
The best opportunity solution trees are feature agnostic. That is, they don’t focus on the features and functionalities you have, but instead on what users need to do.
For example, imagine a user who says, “I get too many notifications.”
This framing focuses all your attention and ideation around notifications.
Dig deeper to understand why the notifications are the problem and where they come from. You might learn that some users find them distracting and irrelevant, especially if they concern conversations that don’t matter to them.
The true opportunity here isn’t “I get too many notifications.” You should focus on the opportunity of “I don’t want to get interrupted by conversations that don’t matter”.
While the former narrows down the focus on a particular feature, the latter focuses on a bigger problem that can be solved in more impactful ways.
Always try to avoid generic and vague opportunities.
Let’s say you learned your users are getting too much spam.
Although “I’m getting too much spam” is a relevant opportunity, it’s too big and vague on its own. Spam means different things to different people, and various forms of spam might bring different doses of pain.
In these cases, make sure to identify more focused opportunities:
For example, under the “I’m getting too much spam” problem might lie a set of smaller problems, such as:
These are different problems with different complexity and most likely impact different groups of users.
Prioritizing and working on these children’s opportunities will be easier and more tangible than handling a vague “I’m getting too much spam” challenge.
Imagine you are trying to improve user satisfaction with your calendar app.
One of the problems you might frequently hear is that people are overbooked. There are two problems with this opportunity.
First, it’s pretty vague. “Being overbooked” can mean different things to different people, but let’s not focus on that now.
The second issue is that opportunities live in distinct moments in time.
It’s a different problem if you are overbooked when trying to add something to your calendar or overbooked when reviewing your calendar to prepare for the day:
These opportunities most likely have different severity and potential impact, not to mention you’d solve these problems differently.
In practice, these are at least two distinct opportunities that live in distinct moments in time. You shouldn’t treat them as the same problem to solve.
Product teams tend to think about the product every time. This makes it easy to get stuck in thinking from the product perspective when framing opportunities.
For example, very few customers would really say that they “wish to have more calendars to manage,” but they might say they want to keep their personal and work separate.
The first framing is not only a solution in disguise, but it’s also feature-focused and ignores the most relevant part — the ultimate goal the user wants to achieve.
A good stress test to make sure you don’t project your product thinking into the opportunity solution tree is to investigate each opportunity and ask yourself:
Think from the user perspective, not a product perspective.
Exploring all opportunities, ideating dozens of solutions, and mapping as many assumptions as possible might sound tempting.
Most likely, you don’t have the capacity to tackle all these opportunities at once. Creating a “backlog for the future” also makes little sense. Your product, users, and market constantly evolve and change, and what you map today might be irrelevant in a month or two.
I’d recommend sticking to the 80/20 rule when developing your tree:
That should ensure a good balance of staying focused while not limiting yourself to only a handful of solutions at a time.
As a rule of thumb, you should map and briefly explore at least five unique opportunities before diving deeper.
If you fall in love with the first user problem you encounter, there’s a high chance you’ll miss out on more impactful and relevant issues to solve:
Avoid tunnel vision by first going wide and only then going deep.
In practice, there are at least a hundred anti-patterns that might slip into your opportunity solution trees.
In this article, I focused on the most common ons:
Did you notice a pattern?
Out of the seven most common anti-patterns, five of them concern the way you frame opportunities. The reason is that opportunity framing is usually the most challenging part.
Let’s face it, leadership often sets outcomes in a top-to-bottom fashion. Coming up with a list of potential solutions is usually the easiest part of the job, and you’ll quickly notice you missed some critical assumptions if the solution doesn’t perform as expected.
It’s a different story with opportunities.
You might spend months working on a poorly-defined opportunity without even realizing you are trying to solve the wrong problem.
When working with opportunity solution trees, put 80-90 percent of your effort into genuinely understanding, stress-testing, and properly framing the opportunities you want to pursue.
Make sure they are specific, live in distinct moments in time, are framed from the user’s perspective, don’t focus on features, and can be solved in multiple ways.
Even if you make a dozen other mistakes along the way, you should still be good to go as long as you work with properly framed opportunities.
Ultimately, well-defined opportunities are the key not only to effectively using opportunity solution trees, but also to a healthy and fruitful product discovery.
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
A fractional product manager (FPM) is a part-time, contract-based product manager who works with organizations on a flexible basis.
As a product manager, you express customer needs to your development teams so that you can work together to build the best possible solution.
Karen Letendre talks about how she helps her team advance in their careers via mentorship, upskilling programs, and more.
An IPT isn’t just another team; it’s a strategic approach that breaks down unnecessary communication blockades for open communication.
Learn more →
