Opportunity Solution Tree - Benefits and Challenges for Continuous Discovery Tracking
For a while now, I have kept track of the initiatives and experiments I am working on with my team in an Opportunity Solution Tree. As a Product Lead, I have been using it to keep track of all of the possible and actual opportunities which are available. Even in a small product, there are a huge volume of possible paths to take, so having something like this is essential to navigate a path forward.
I have been using this as part of an autonomous team, given outcomes as our objective, and being given the room to work towards that outcome. We’ve been given a change to make, but haven’t been given the solutions. In many cases, the outcome is pretty broad and we need to narrow down to find our way there.
I want to spend some time outlining how I use the Opportunity Solution Tree specifically, and describe some of the benefits and some of the challenges. For more about what an Opportunity Solution Tree is, check out this thorough explanation by Teresa Torres on ProductTalk.org. For more about how this fits into Continuous Discovery Habits, have a read of her invaluable book as well.
Using the Opportunity Solution Tree
I use the opportunity solution tree pretty much as described in Continuous Discovery Habits.
As a team, we’re working towards outcomes which are defined by the business / domain within which our team sits. Some of these are driven by a key metric we need to hit, and some of these help to drive that key metric. Typically we’d have 3 outcomes / goals which may evolve per quarter, but generally stay the course.
Working with my team, I used the OST to map out the opportunities within each of those outcomes. The opportunities came from team / group / domain insights, user research, survey results, product analytics data, input from sales, marketing and other teams internally.
Within each of those opportunities we documented out the possible solutions, in progress solutions and completed solutions in order to keep track of them. I generally tried to colour code or use stickers to keep track of progress and success.
I started to include the impact within each solution, but this is where it gets tricky, and the limits of Miro were met. The impact invariably ended up in a separate Google Sheet which definitely helped lay out that data in an easier way.
Opportunity Solution Tree Benefits
Let’s dig into some of the details of what I find useful about tracking experiments, initiatives and changes with the OST.
Visual - The primary benefit for me, as someone who is a very visual person, is that this is a great visual way of representing product discovery, and seeing it evolve. The layout helps me jump to specific sections with ease, and my memory more easily recalls items based on the layout.
Autonomous - Merely having the chance to start using an Opportunity Solution Tree puts you in the category of teams who are more autonomous than others. Working towards outcomes is super important for learning, growing and succeeding as a Product Manager. This is where it starts.
Focused - It’s easy to stay focused on the opportunities you have, the solutions you’ve tried and tested, and you can see how much effort you’ve put in to try and fail quickly, to see what works and what doesn’t.
Collaborative - The tree layout makes it easy to see all that is on the table, and collaborate with other people, including involving stakeholders. It’s quick to make sure everyone is up to date and understands the lay of the land and the options available.
Organic and evolving - Opportunity Solution Trees evolve naturally and organically as you start to evolve your plan. Each one is different and evolves on its own.
Connected - Everything ladders up to what matters. It’s clear and connected as to how each solution ties back to the outcomes which are important. There could be hundreds of potential solutions, each doing their part. It’s also easy to re-prioritise from one outcome to another if the quarterly priorities change.
Opportunity Solution Tree Challenges
The initial tree may take a small amount of time to create. If you’re starting part way through the creation of a product, I don’t recommend mapping all historic outcomes, opportunities and solutions. That would take too much time, and be too overwhelming.
No, it’s best to start with where you are. What are this quarter’s outcomes? Even, what is the most important outcome we must focus on at the moment? Then start mapping from there.
The challenging part isn’t creating the initial tree. The challenging part is maintaining and growing it as it evolves and as your understanding grows. Here are a few challenges I’ve uncovered:
Historical data - Whilst Miro and other tools have versions, file update notifications and you can trace how things have changed, it’s difficult to see how old some things on the tree are. Plotting dates against each item in a tree will add a lot of noise, but could be useful.
Understanding priority - Yes, you can prioritise with colours or re-arrange order, but that changes how the tree is used and laid out. Moving the tree around constantly makes it hard for collaborators to see what’s changed (see point above), as well as see the priorities. Prioritisation isn’t always as simple as 1, 2, 3, 4. There are different criteria to take into account, which it’s tricky to map against each of these nodes in a tree.
Decision making - During a synchronous call, a lot of decisions can take place in a very short space of time. Trying to catch up on these decisions takes time, and isn’t easily understandable. The OST isn’t the easiest place to plot out decisions being made, and what has changed.
Experiment results - Results are complicated, often multi-faceted and generally live in a separate tool such as Amplitude, Looker, Mixpanel or other analytics tool. They might even be spread across multiple different analytics tools, especially where campaigns are needed. Plotting experiment / solution results against these in something like Miro is easy, but it gets very messy. It’s also not easy to see where and when the result was added.
Multiple Solution Insights - When testing our assumptions for multiple different solutions, we often group these together.
Opportunity and solution process - Each opportunity has it’s own process it must go through to validate that it’s a healthy opportunity to pursue, as does each solution. How does the group know which have been validated, what work has already gone into it, and what the end result / decision is?
Continuous dialogue - Within Miro and other tools like Figma’s FigJam, there are ways to comment on each of the nodes within the diagram. However this isn’t necessarily attached to the node very well and is open to being moved, discarded or lost as part of the process.
In conclusion
Overall, many of the challenges I have experienced are related to adding additional data to the OST. Being able to link the data from, say, Miro, to another tool such as Google Sheets, would alleviate this somewhat, but I haven’t tested this in too much detail yet.
With every evolution of the tree, there is some data behind it, some test involved, or some result at the end of it. Being able to link and group this data, the tests and the results would have a significant benefit for OST power users, and would contribute to a much more powerful framework.
The main challenge is that this is a framework for making decisions which ties in nicely to the process of continuous discovery, but (as of yet) none of the tools which help with Product Management have yet to adopt this way of working as part of their tool specifically.
I’ll continue using this, and look at how to make optimisations with a view to overcome these challenges and make a more thorough system for tracking outcomes, opportunities and solutions through continuous discovery habits. I highly recommend this type of system for any Product Manager as well.