A better way to figure out what to build
The "Opportunity Solution Tree"
This is a newsletter about building a software company, written from the trenches of building one.
I write brief essays to reflect... and to counter all the startup myths and “hacks” peddled by influencers looking to make a quick buck.
This week, I’m covering a product management framework that’s been insanely helpful organizing our roadmap: The Opportunity-Solution Tree
Roadmaps, backlogs, scrum boards… and I still don’t know what to build
How many different tools does it take to know your software product’s roadmap is heading in the right direction?
Backlogs don’t help. They’re just parking lots for ideas.
Roadmaps are usually glorified backlogs, sequentially prioritized.
Product narratives (I wrote about them here) are useful to make sure you’re building towards a coherent whole, versus a bunch of features. But they don’t tell you much about order, nor are they super flexible when new ideas emerge.
And “project management” tools (Scrum boards, etc.) are useful at organizing processes, but bad at assessing the substance of what needs to be built.
Which means, you can have all of these things in place and working effectively and STILL not have a structured picture of how the different things you’re building work together.
And that means when opportunities and feature ideas get recommended, you don’t really have a structure for organizing them and prioritizing them. Result: The loudest person’s opinion usually wins in your product prioritization meetings.
Visualize options with the Opportunity Solution Tree
I believe the tree first came from Product Talk, a great blog for product leaders. Their first blog on the Opportunity Solution Tree is here.
In short, it’s a way to deconstruct and organize the different opportunities you could pursue - and the different features you could build. Here’s a picture of an Opportunity Solution Tree:
The Desired Outcome is the impact you want to make in your user’s life. If you have multiple user types, you’d make multiple different trees.
The Opportunity is a way that you could go about achieving the desired outcome. These are needs and pain points, not features.
The Solution is the feature - everyone loves features!
And the Experiment is a way to assess whether the solution will help you achieve the opportunity.
There are two useful exercises I’ve done with this:
Created the Opportunity Solution Tree by myself and put all the meaningful features in our roadmap and ideas we’ve thrown out on the tree. (I used Miro for this.) Which opportunities are we actually pursuing? Are these the most impactful ones?
Walked our leadership team through the tree and asked: Which opportunities should we actually be pursuing? Do we need to reprioritize?
These were useful activities. And now, whenever someone (AKA me) has a harebrained feature idea, we can go in to our Opportunity Solution Tree, put it in its rightful position, and realize that we shouldn’t prioritize it because it’s on a branch we’re not focused on.
There’s much more depth on Product Talk’s blog if you’re interested in digging deep. Highly recommend.
One risk I’d highlight is that this is a reductionist approach. Which means, when you do an opportunity solution tree, you risk prioritizing opportunities that are individually helpful but collectively incoherent. After prioritizing your opportunities, take a step back and make sure all the pieces fit together in a narrative that makes sense to you and your customers.
-Rob
PS: for some reason, I’m giving a talk about Product-Market Fit at Harvard this week. Here’s my “takeaway” slide - a few pieces of advice and books that I wish I’d internalized before building / raising money. What would you change?
