Engaging Stakeholders with Opportunity Solution Trees: 3 Tactics to Try

Two and a half years ago, I introduced the opportunity solution tree. It’s been a blast seeing product people put it into practice.
Today, I’m excited to share Hope Gurion’s thoughts on using opportunity solution trees. Like a true Agilist, she hasn’t just adopted the tool, but has iterated on it to better suit her needs.
I first met Hope in 2014 when she asked me to coach her product teams at CareerBuilder. When she moved on to BeachBody, she brought me in to work with her teams there as well. You might remember Hope from this video interview that I did with her about her work at CareerBuilder.
In fact, I was working with one of her teams at BeachBody when they expressed that they didn’t know what to do next in discovery and they felt that they relied on me too much to guide their work. It was this conversation that inspired me to sit down and externalize my thinking in a way that led to the first opportunity solution tree.
Since leaving BeachBody, Hope has worked as a product consultant and coach. She uses my continuous discovery curriculum to coach product teams just as I do.
She’s given me feedback on the opportunity solution tree from the very beginning and has used it in her own coaching practice. I’m excited to share some of her thoughts with you. I’ve weighed in with some additional commentary to provide my take.
Hope Gurion: I use opportunity solution trees to align, communicate, and collaborate on product discovery. The link to recognizable company goals—and the fact that it looks nothing like a Gantt chart—facilitates a healthier discussion about choices the teams are making with finite resources.
Here are three “riffs” on how to illustrate the value product leaders realize when using the opportunity solution tree:
- Fight organizational amnesia with color-coding
- Improve stakeholder collaboration
- Co-create with customers
Fight Organizational Amnesia with Color-Coding
Hope: I find that some product teams and leaders spend an inordinate percentage of their time trying to keep the organization informed and aligned about what they’re learning or what is/isn’t important/urgent to prioritize to achieve their desired outcomes.
Discovery is a messy learning process with many twists, turns, and dead-ends. It can be challenging to keep leadership and key stakeholders informed along the way.
Product leaders and teams use many strategies to be transparent. They hold product/progress update meetings. They write emails. They produce reports. They share interview notes, video clips, and prototypes. And yet the organization typically can’t absorb and retain the information being shared.
The original opportunity solution tree has color-coding designed to help teams distinguish between opportunities, potential solutions, and experiments to identify the most promising solutions:

I’ve iterated on the opportunity solution tree to add in color-coding to distinguish between what looks promising (validated, high potential impact on goal) vs. what isn’t promising (invalidated, or low potential impact or infeasible) vs. unknown. Here’s an anonymized example from a client:

This outcome and opportunity-level of the opportunity solution tree was used in an executive product review of a recently acquired European product. The executive team had some hypotheses about which North American customers would want this product and why. After interviewing 20 customers, we uncovered new value proposition opportunities (highlighted in green) and invalidated a couple of original hypotheses (highlighted in red). Presenting this view with supporting customer quotes effectively communicated and aligned the leadership and product team to pursue the most promising value propositions in the go-to-market planning.

Here’s another theoretical example of a security-related opportunity solution tree. In this view, we are much earlier in the discovery process with more hypothetical opportunities that haven’t yet been validated (green) or invalidated (red) and therefore are unknown (clear/white). This evolving color-coded view helps keep the cross-functional team aligned if they are not actively participating in the discovery efforts firsthand.
Teresa: Like Hope, I’ve seen the need for product teams to clearly communicate the status of different opportunities and solutions. I like her iteration of using different colors to visually communicate that.
However, I also see teams struggle with the difference between an opportunity and a solution. I think it’s important to visually distinguish that as well. Building on Hope’s idea, I would do something like this:

In this tree, we are still using green to designate opportunities, yellow to designate solutions, and orange to designate experiments. Next to each item is a status symbol. A green check indicates we have evidence that supports the opportunity, a blue circle indicates we are still collecting evidence, and a red x indicates we have evidence that suggests the opportunity isn’t significant or the solution won’t work.
This allows us to keep the distinction between an opportunity and a solution clear while also communicating the status of each item.
Improve Stakeholder Collaboration
Hope: Inevitably this color-coded opportunity solution tree sparks stakeholders to ask the question, “How did you decide what is green/promising vs. red/not promising?” I encourage teams to work with their stakeholders to define clear lines in the sand that would justify pursuing or rejecting an opportunity or a solution. This guards against “Monday-morning quarterbacking” and statements like “Well, you only talked to 8 people, so I still think we should consider it.”
The criteria for what constitutes a “big enough” opportunity or an impactful solution should be determined with the cross-functional product team and stakeholder partners who will live with the decisions of the product team. (You can read more on defining the pass/fail or “line in the sand” criteria for solution experiments in Teresa’s article on How to Improve Your Experiment Design (And Build Trust in Your Product Experiments)).
Some examples of lines in the sand you might consider for opportunities include:
- Expressed (unaided) as a pain point by at least ? of target customers
- Chosen as one of the top three problems they’d like solved in a “Buy a solved problem” exercise (variation on “Buy a Feature”)
- Most frequently asked question in pre-sales demo discussions with prospective customers
- Top three reason for calling customer support in the last two weeks
Some examples of lines in the sand for solutions include:
- Design preferred by at least 60% of users in usability testing
- Experiment variation increases conversion rate by at least 15% (if it doesn’t, we’ll keep status quo or create another variation)
- New purchase funnel increases average order size by 10% while maintaining our conversion rate
Externalizing and documenting the criteria ahead of time helps the team avoid falling victim to confirmation bias in pursuit of their favorite opportunities or solutions. If you maintain your opportunity solution tree in a shared workspace, such as Miro, you can easily remind team members and stakeholders of the agreed-upon “line in the sand” criteria in context as they’re reviewing what the team has learned.

Teresa: Hope hits the nail on the head with this suggestion. I am a big advocate of having teams define success criteria upfront. It guards against confirmation bias and helps to align everyone on the team. As Hope argues, it’s also a great way to align stakeholders around your future decisions.
To put this into practice, for each of your opportunities, ask, “How will we know if this opportunity is real?” Then draw a line in the sand. Do you need to hear it in every interview? At least five interviews? How salient does it need to be?
Most teams struggle with these lines in the sand because they can feel like wild guesses. But good teams realize they are going to make these decisions eventually and they are far better off making them before they collect the data than after.
Co-Create with Customers
Hope: More product teams are using the opportunity solution tree as a planning and collaboration tool inside the walls of their organization. Yet for product teams in B2B companies, it can also facilitate powerful customer collaboration.
Recently, a product leader I was coaching was just beginning to flesh out an opportunity solution tree for his product suite. He shared with me that he was about to meet with an upset client who was frustrated with their product. I encouraged him to leverage the meeting to learn from this client using the opportunity solution tree.
During the meeting, the product leader drew on the whiteboard the portion of the opportunity solution tree that specifically related to the client’s role as a sports team travel director and invited him to improve upon it.
During the whiteboarding session the client clarified his success metric as a travel director. He added in problems that were inhibiting him from achieving his goals and crossed out what wasn’t as important to him. The product leader invited the travel director to choose which opportunity stood out as his most urgent/important need. Once they chose a target opportunity, they used a “How Might We?” exercise to identify potential solutions.
Here’s an illustration of what this opportunity solution tree looked like:

The product leader and client collaborating on the opportunity solution tree achieved two benefits. First, this product leader realized several opportunities/context he was previously blind to. Second, the client learned more about capabilities he already had in the product he wasn’t fully using.
Moreover, the client left the meeting feeling confident that he was working with the right business partner. He saw the commitment of the product leader actively working to understand his goals and collaborating on options to help his client achieve success.
Teresa: I love this idea. I often have teams draw miniature opportunity solution trees that reflect the needs they hear in a single customer interview. It’s a great way to find patterns across multiple interviews. Hope extends this even further by building the tree with the client.
One of the key principles behind the opportunity solution tree is to externalize your thinking so that you can examine it. When we do this with our product teams, it helps us align around what we know and gives us a strong foundation for team decisions. When we do this with customers, it helps us confirm what we are hearing, builds trust, and gives the customer confidence that we are building toward their needs.
I want to thank Hope Gurion for taking the time to share her iterations on the opportunity solution tree. Her thoughts always push my thinking and I love seeing the great work she is doing with her clients.
Have you adopted opportunity solution trees in your organization? I’d love to hear how it’s going in the comments. Maybe we’ll share your stories in a future article on Product Talk.
Comments ()