This reinterpretation of the Opportunity Solution Tree helped me bring the product mentality to conversations successfully.

Not all companies do Product management (Product) the same way. Ideally, a few do it well, while the majority do it poorly. Some do it worse than others, to be fair, but in theoretical terms most are wrong.

The main culprit seems to be companies practicing the feature factory mentality.

In the year of 2019, before the world went ‘bananas’, I met what would become the backbone of my prioritization mindset — The Opportunity Solution Tree by Teresa Torres.

The Opportunity Solution Tree is just a way to make alignments with stakeholders easier, but its simple and yet comprehensive essence allowed me to go above and beyond with its applications.

I’ve been a product manager at all sorts of companies, but I always find some use for it, especially within businesses with a feature factory mentality, although, I had to make some adaptations.

Disclaimer: sharing something that was tested solely by my personal experience should be enough for you to take this article with a grain of salt.

Despite that, let me make it clear: It’s not guaranteed that anything of what I’m about to present below will work or can be reproduced in your reality. Reader discretion is advised.

What’s an Opportunity Solution Tree?

The Opportunity Solution Tree is a framework that breaks Product outcomes into opportunity streams so that stakeholders have a better understanding of what you are proposing and can better help you prioritize.

This roughly translates Teresa Torres’ thesis. If you’re interested in the core material, check out her original blog post. If you prefer video, you can watch her excellent presentation at Mind the Product 2019.

According to Teresa, the Opportunity Solution Tree should help you step away from the feature factory mindset of ranking solutions based on importance. Instead, it allows you to upgrade your conversation with stakeholders.

What is implied behind the tree, is that you and all your stakeholders have a clear notion of the outcome to be reached by your team. This outcome waterfalls down naturally into opportunities to be discussed and experiments are appended just for reference and tracking.

Unfortunately, this is far from true.

Opportunity Solution Trees can’t exist inside feature factories

As I’ve said earlier, few companies do Product well. Experimentation, opportunity, outcome — those are words that belong to books in most organizations. The norm is low product maturity, not the other way around.

A consequence of this Product immaturity is that product teams tend to jump to conclusions before assessing opportunities. Even worse, teams often don’t even come up with their own ideas. Marketing or sales department submits a list of requirements that should be implemented as features. That’s it.

One way or another, Product teams have a bunch of disconnected demands on their hands and are responsible for prioritizing that mess. Bogged down by discussions on what should be the “most Agile” way to deliver those features, a war between managers start and whomever shouts louder, wins.

Stakeholders don’t want to discuss opportunities, participate on prioritization, let alone do discovery. Product is transforming itself on this sort of project 2.0 and teams simply give up building anything close to an Opportunity Solution Tree when they are met with resistance. What if we deal with stakeholders on their own terms?

Let’s turn the Opportunity Solution Tree upside down.

The Outcome Identification Tree

The demands stakeholders threw at you didn’t come from nothing. There is some strategy behind all the chaos, and it normally comes from straight forward goals defined by the C level: profit or revenue, in most cases.

Inside low product maturity organizations, “discovery” frequently means untangling the reasoning behind requests from sales or marketing teams. Even though demands were not born from assessed opportunities, you can reverse engineer most of them and reach the same opportunities.

Enters the Outcome Identification Tree:

The Outcome Identification Tree, is a framework to assess Product outcomes starting from loose features. it’s a discovery tool more than a communication one, but it serves both purposes.

First, try and cluster the list of demands you have based on context. You may have several demands from different teams due to a new software being implemented. Perhaps, a new player is hurting your customer base and you must catch up, hence the features requested by the sales team.

After clustering everything, bind them to an initiative, which would be analogue to a hypothesis. Using the two examples mentioned above, an initiative for the software change would be having it implemented. For the competitor case, maybe it’s acting on the gap between the two of you, or doubling down on your differentials.

Once the Initiatives are settled, you identify what are the most important metrics to track in order to assess if you are being successful or not. Having a software implemented is not a metric, but the amount of internal active users is. Likewise, having all the features of your competitor means nothing, but tracking churn might be an interesting proxy to define success.

Once the metrics are established, look for your objective (i.e. the desired outcome). What is the one thing your team should look up for in order to become great within your company? If you’re implementing that software, maybe it’s revolutionizing how your company works. If we’re talking about the competitor situation, maybe you want to recapture 20% of the market.

Having your Outcome Identification Tree built and aligned with company goals, it’s way easier to engage with your stakeholders and justify your prioritizations.

Having a crystalized strategy on top of the list of demands sent to you is a very powerful tool to defuse insistent stakeholders based on data instead of power. Likewise, it’s a way safer method of doing Product inside immature companies to ensure success.

If somebody was to look at your tree after completion, it wouldn’t be possible to know if you built it from top to bottom or the other way around. For all intents and purposes, it’s a perfect Opportunity Solution Tree, but the stakeholder knows what you are talking about now.

Is the Outcome Identification Tree a replacement for the Opportunity Solution Tree?

No! Sticking only with the Outcome Identification Tree presumes that all opportunities to be seized were already identified by your stakeholders. This is never true. Stakeholders are an amazing source of ideas, yes, but they are biased. When voicing the customer, a lot can get lost in translation.

Traditional methods of opportunity discovery such as user interview, data interpretation and prototype testing are still fundamental sources of insights.

The Outcome Identification Tree objective is to put those stakeholders demands on equal grounds with your own discoveries. You can use it to communicate with the parts less interested with Product culture and use the Opportunity Solution Tree to deal with your boss and other product teams.

It’s about adapting for context.