Opportunity Solution Tree

Teresa Torres tool for Product Development Framing: connecting big desired-outcomes to specific pains/opportunities, to solutions/hypotheses, to experiments....

This smells like a promising framework to define a Product Strategy-based Development Queue instead of a classic RoadMap.

She notes it's a good reactive process, taking an "idea" (solution) and

  • defining a problem/opportunity it addresses
  • prioritizing of that problem/opportunity
  • generating/prioritizing other possible solutions to that problem/opportunity

tree

Aug'2016: Why This Opportunity Solution Tree is Changing the Way Product Teams Work

I’ve been coaching product teams for three years on modern product discovery and this single change has had a bigger impact on how teams work than everything else I do with them combined.

The Messy Challenge of Modern Product Discovery

they were struggling to see the big picture

I started to reframe the two dimensions as discovering opportunities and discovering solutions

Fortunately, around this time I was reading Peak: Secrets from the New Science of Expertise by Anders Ericsson.

His chapter on the role of mental representations (Model) in expert performance is what led to my breakthrough

The Power of Mental Representations

“… the key benefit of mental representations lies in how they help us deal with information: understanding and interpreting it, holding it in memory, organizing it, analyzing it, and making decisions with it.”

The Mental Representations of Expert Product Managers

He asked attendees to identify something that they wanted in their life. He gave a few examples, a house, a better job, more leisure time.

This line of inquiry reminded me of Bernie Roth.

Then he asked us another question. He said, “If you had whatever you wrote down today, what would that do for you?”

“If I had a house today, I would feel more grounded in my community.”

He then used this next answer to ask an even more powerful question. “How else might you feel more grounded in your community?”

This final question is powerful because it disrupts our fixation on a single solution—owning a house—and helps us to think expansively about other ways we might get the same benefit—feeling grounded in our community.

If we widen our own lens from the world of product management to the world of problem solving—remember, product managers are problem solvers—we see this mental representation show up again and again

Jonassen argues that ill-structured problems are problems that have many solutions. There are no right or wrong answers, only better or worse ones. The solver must start by defining the goal and constraints of the problem before exploring potential solutions.

The short of it is that the problem solver, in our case, the product manager (or even better, the product team), must start by framing the problem. This is exactly what Bernie is doing with his powerful questions

Multitracking should sound familiar to long-time readers as well. Chip and Dan Heath talk about the value of multitracking in their book Decisive

4 Common Gaps in Our Thinking Today

Gap #1: We don’t examine our ideas before investing in them

Gap #2: We don’t consider enough ideas.

We often justify our favorite solution by arguing it drives a desired outcome. We often start with a single idea and work backwards to consider our desired outcome.

But we we often skip the step of asking (like Bernie teaches us to), “What else could we do to drive our desired outcome?”

Gap #3: We don’t multitrack in a systematic way.

By jumping straight to solutions, even when we do consider multiple options, we often compare solutions that shouldn’t be compared against each other. Many of us have had the experience where we find ourselves arguing over the merits of two different solutions only to later find that we were each framing the problem differently

Instead, we want to consider which problem each solution solves and instead make a decision about which problem leads to a more valuable opportunity

A systematic approach requires that we consider multiple solutions that deliver on the same opportunity

Gap #4: Our solutions don’t connect to an opportunity or our desired outcome at all.

Taking the time to externalize this visual structure will help you to catch these errors.

The Opportunity Solution Tree

Building the 4 Sections of Your Opportunity Solution Tree

Section #1: Good product discovery starts with a clear desired outcome.

If your team doesn’t use OKRs, you can use any single metric that you want to improve—metrics like engagement, retention, revenue, customer satisfaction, NPS, etc.

I find it easier to create separate trees for each, but technically you could include them both on the same tree.

If you do focus on more than one goal at a time, make it clear which is the priority

Aligning around a clear desired outcome is hard work. Don’t skip over it. If you get the start wrong, the rest of the tree will be a waste of time.

Section #2: Opportunities should emerge from generative research.

We’ve talked a lot about how we might each frame the problem, but if we want to build successful products, what matters most is how our customers frame their own problems. Generative research helps us to uncover that.

Section #3: Solutions can and should come from everywhere (as long as they are bounded by an opportunity).

As previously mentioned, most product teams jump from a desired outcome to generating solutions. But we don’t want to do that. We want to be continuously seeking opportunities in our market. Every day we learn more about customers, their needs, and their pain points

solutions should only be considered if they help us deliver on one of our target opportunities. If they don’t connect to the tree, they should be considered a distraction.

Section #4: Experiment to evaluate and evolve your solutions

Experiments reflect the work that you are doing to test the riskiest assumptions behind your solutions

This helps us escape the trap of over relying on A/B tests to test the whole solution.

Using Your Opportunity Solution Tree to Guide Product Discovery

I want to cover enough to help illustrate why this tree helps. Let’s look at a few scenarios

Scenario #1: You’ve got a backlog full of ideas and you are struggling to prioritize them.

Scenario #2: You have a clear desired outcome, but are still struggling to prioritize the ideas in your backlog.

One area where the tree can be immensely valuable is to help us see the big picture of how we are approaching our work.

Scenario #3: You fixate on one opportunity, one solution, and one experiment at a time.

take some time to expand your tree horizontally at all levels.

we want to avoid “whether or not” decisions. That requires that we have multiple options to consider at each decision point.

You’ll notice that the green rows are missing from this tree and this tells me that you need to spend time exploring the problem space. You need to do generative research to understand which opportunities exist. Strategic decisions about which opportunities to pursue are what helps us prioritize solutions.

Scenario: #4: You consider way too many opportunities, solutions, and experiments at once.

We don’t want to test every idea we have.

A Framework for Continuous Product Discovery

The goal isn’t to first discover opportunities and then discover solutions. Instead, we want to be continuously doing both.


Edited: |

blog comments powered by Disqus