Why This Opportunity Solution Tree is Changing the Way Product Teams Work August 10, 2016 by Teresa Torres 39 Comments

I’ve found a visual aid that is profoundly changing the way teams work.

It’s working so well that I feel compelled to write a book about it. But that’s going to take time and I want you to have it today.

So I’m going to scratch the surface in this blog post.

I suspect you are going to have one of two reactions. You will either skim this post, conclude it’s obvious and that you already do it, and miss the point entirely. Or you will be left wanting more.

For those in the first camp, I encourage you to slow down. To look for what’s new here and to give it a try. 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.

For those of you in the latter camp who will be left wanting more, I’m writing as fast as I can. I hope to have the book ready by early 2017 and I’ll be blogging bits and pieces along the way.

Let’s get on with it. Please humor me, as this is going to take some setup.

It all started a few months ago…

The Messy Challenge of Modern Product Discovery Several teams within a week or two of each other started telling me that while they were learning a lot in our sessions together, they were struggling to see the big picture.

We would jump from reviewing interview guides one week to discussing experiment results the next.

Each piece in its own right was helpful, but the teams weren’t learning how to string it together on their own. I always had to tell them what to do next.

My goal as a coach is to get teams doing continuous discovery on their own as quickly as possible. So I knew something had to change.

I kept asking myself, how do I decide what comes next? And more importantly, how do I teach this to teams?

I started by trying to be more explicit about what modern product discovery is. That led to this video.

But that didn’t entirely solve the problem.

It’s easy for teams to work along both dimensions of product discovery—working to understand their customer’s context and iteratively testing their ideas—but that doesn’t mean they know how to connect the two sets of activities.

Over time, I started to reframe the two dimensions as discovering opportunities and discovering solutions.

Good product discovery requires discovering opportunities as well as discovering solutions. – Tweet This

This helped as most teams can articulate how to connect the dots between opportunities and solutions. But they didn’t necessarily do so in practice.

I still saw teams entertaining solutions that weren’t connected to the opportunities they were finding through generative research.

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

Ericsson has spent his career studying what makes experts stand apart from novices and Peak summarizes his perspective on the research today.

It gave me a lot of food for thought about how we develop expertise in product discovery.

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

The Power of Mental Representations Ericsson argues that better mental representations are what set experts apart from novices.

Better mental representations set experts apart from novices. – Tweet This

He defines a mental representation as a “mental structure that corresponds to an object, an idea, a collection of information, or anything else, concrete or abstract, that the brain is thinking about.”

That might be a little too vague for those of us who aren’t cognitive scientists. He further explains:

“… these representations are preexisting patterns of information—facts, images, rules, relationships, and so on—that are held in long-term memory and that can be used to respond quickly and effectively in certain types of situations.”

It’s this latter part of his definition that most intrigues me. If we develop better mental representations, we’ll be able to respond more quickly and effectively.

Much of Ericsson’s work compared novices to grandmaster chess players. In one study, he showed both novices and grandmasters a chessboard that represented a game midway through play.

To the novices the chessboard looked as if the board was set up at random. But to the grandmasters, they were able to understand what moves led to this position and were able to cycle through next moves and their potential outcomes. They were better able to predict which player might win the game.

In fact, as a result of studies like these, Ericsson concluded:

“… that the advantage better players had in predicting future events was related to their ability to envision more possible outcomes and quickly sift through them and come up with the most promising action.”

The grandmasters relied on stronger mental representations of chess games to consider more possibilities.

Ericsson further explains:

“… 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.”

But it’s not just grandmaster chess players who have this advantage.

“The superior organization of information is a theme that appears over and over again in the study of expert performance.”

This raises the question, is there a superior way of organizing information about product discovery that allows us to move quickly and more effectively?

I believe there is.

The Mental Representations of Expert Product Managers I started to wonder if I relied on a mental representation to decide what to do next.

If I did, perhaps I could externalize it and use it to guide teams.

My theory was that over time, they would learn to adopt the same mental representation and become self-sufficient.

More importantly, I started to wonder if I could find evidence in the world of a shared mental representation used by many experts.

Perhaps this could be the key to teaching product discovery.

Are expert mental representations the key to teaching product discovery? – Tweet This

This line of inquiry reminded me of Bernie Roth. Bernie is a Professor of Engineering and the Academic Director at the d.school at Stanford University.

I met Bernie at a design event hosted by the Stanford Alumni Association. He led a session that stood out to me.

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.

He gave us a minute to write down our answers. Then he asked us another question. He said, “If you had whatever you wrote down today, what would that do for you?”

For example, if you had a house today or a better job today, why would you be better off?

This was a powerful question.

He explained why by extending his example. If you wrote down that you wanted a house, you might have answered the second question with something along the lines of, “If I had a house today, I would feel more grounded in my community.”

Tree chart with feeling grounded in your community as the root node and buying a house with two unknown ideas as children How else might you feel grounded in your 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.

Tree chart with feeling grounded in your community as the root node with children buy a house, join social club, and volunteer. Bernie teaches a simple structure for expanding your options.

For example, we might become more active in our church community or with a social club. We might volunteer at our children’s schools or start attending neighborhood events.

Bernie taught a very simple way to widen your lens, to avoid fixating on a single solution.

Learn a simple way to widen your lens, to avoid fixating on a single solution. – Tweet This

I had never seen reframing taught so simply and so effectively.

But there’s more power behind this exercise. Through his teaching, Bernie is revealing his own mental representation for how he solves open-ended problems.

Product Managers are Problem Solvers Bernie isn’t the only expert to expose this mental representation.

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.

If you’ve been reading Product Talk since the beginning of the year, you might remember David Jonassen’s work on problem solving. See this article.

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.

I argued in this article that the hard problems that product managers face are ill-structured and borrowed from Jonassen’s model for solving ill-structured problems.

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. He helped us uncover the implicit framing of the problem (feeling grounded in our community) behind our desired solution (buying a house).

By making the problem framing explicit, Bernie shows us how we can question it (reframing) and use it to generate alternative solutions (multitracking).

Make your problem framing explicit. So you can both question it and use it to generate more solutions. – Tweet This

Multitracking should sound familiar to long-time readers as well.

Chip and Dan Heath talk about the value of multitracking in their book Decisive—a summary of the research on decision making. I’ve written twelve blog posts about this book—you can find them here.

But Bernie’s exercise is about more than multitracking. He’s multitracking in a systematic way.

His first question, “What would you have if you had that?” creates a structure between “I want a house” and “I want to feel grounded in my community.”

His second question, “How else can you feel grounded in your community?”, expands that structure.

This systematic approach is important. Remember, John Dewey in How We Think, encourages us “to maintain the state of doubt and to carry on a systematic and protracted inquiry—these are the essentials of thinking.”

Bernie’s simple example is starting to give us a window into how expert problem solvers use framing to support multitracking in a systematic way.

And as Ericsson argued, they are relying on better mental representations to help them do so.

4 Common Gaps in Our Thinking Today Let’s start to translate all of this to the world of product management.

Gap #1: We don’t examine our ideas before investing in them. Bernie asked us, “What do we want in our lives?” As product managers we ask, “What should we build next?”

In both cases, what follows is an idea. Maybe two or three, if we are lucky.

Let’s use a product example to illustrate this. Imagine you work at Facebook and you are responsible for newsfeed stories.

You might answer the question, “What should we build next?” with an idea, “Let’s add a dislike button.”

Some of us rush off and build that first idea or two. That’s akin to rushing off and buying a house before examining why we want one.

Gaps in our thinking #1: We don’t examine our ideas before investing in them. – Tweet This

Gap #2: We don’t consider enough ideas. Some of us might slow down and examine our thinking. We might ask, “Why do I think this idea is worth building?”

My idea will drive this desired outcome. Adding a dislike button will increase engagement. 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.

Returning to our Facebook example, we might look at our idea and argue, building this idea will increase engagement on newsfeed stories.

In other words, the answer comes in the form of “My idea will drive some desired outcome.”

It sounds good.

Tree chart with Desired Outcome as the root and Idea A, and two unknown ideas as children. Second tree chart with increase engagement as the root and add a dislike button and two unknown ideas as the children. We don’t consider enough ideas.

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

We don’t consider enough ideas.

We ignore the advice of Chip and Dan Heath where they advise us to avoid “whether or not” decisions (i.e. should we build this idea or not?) by multitracking. And we ignore the advice of John Dewey by not “maintaining the state of doubt” or carrying out a “systematic and protracted inquiry.”

Gaps in our thinking #2: We don’t consider enough ideas. – Tweet This

Gap #3: We don’t multitrack in a systematic way. Tree chart with desired outcome as root and Ideas A, B, and C as children. Second tree chart with Increase Engagement as root and Add a dislike button, highlight past stories to share, and turn off story notifications as children. 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.

You might argue that highlighting past stories to share is a more compelling solution than adding a dislike button, whereas I prefer adding the dislike button.

We can argue all day, but we won’t make any progress if we spend all of our time debating the merits of each solution.

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

Before debating the merits of different solutions, agree on a common way to frame the problem. – Tweet This

Tree chart with desired outcome as the root node with children opportunity x and y, each with their own idea children. Take the time to discover opportunities before jumping to solutions.

For example, I might argue that adding a dislike button encourages people to engage with existing stories, whereas you might argue that adding a highlight stories to share feature encourages people to share more stories—a different type of engagement.

We can look at how well we engage people around existing content and how well we engage people to share new content and ask ourselves which of these opportunities is more valuable.

This helps us make a strategic decision about where to invest our time, before we debate the merits of our solutions.

We then only want to compare solutions that deliver on the same opportunities. Instead of debating the merits of each solution, we want to ask ourselves, “Of these solutions, which is most likely to deliver on the target opportunity?”

Only compare solutions that deliver on the same opportunity. – Tweet This

When we compare solutions that ladder up to different opportunities, it feels like we are multitracking because we are considering multiple solutions. But we aren’t multitracking in a systematic way.

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

Gaps in our thinking #3: We don’t multitrack in a systematic way. – Tweet This

Gap #4: Our solutions don’t connect to an opportunity or our desired outcome at all. Tree chart with desired outcome as the root node with children opportunity x and y. Opportunity x has children ideas A and B. Opportunity y has no children and Idea C has no parent. Watch out for orphaned solutions.

The most egregious gap in our thinking is when we consider a solution that doesn’t connect to an opportunity at all. We can’t identify a problem that it solves. We just like the idea.

This sounds crazy, but we all do it.

Oftentimes, it’s not a result of us just going off the rails. It happens in a step-by-step manner where each step seems reasonable.

I have a silly example that illustrates these types of errors.

Tree chart with cross the Atlantic as the root node with children prevent scurvy and safely navigate. Prevent scurvy has children oranges and grapefruit. Safely navigate has no children and apples has no parent. Don’t compare apples with oranges.

Imagine you are the captain of a ship crossing the Atlantic in the 1500s and your crew comes to you and tells you that several crewmembers have come down with scurvy.

You now have an opportunity to cure scurvy amongst your crew. So you start to generate ideas.

You suggest, “Citrus is supposed to cure scurvy. Let’s give them oranges.”

A crewmember responds, “Oranges could work. But I prefer grapefruit. Let’s give them grapefruit.”

To which another crewmember responds, “I don’t want to clean up all those peels. Let’s give them apples.”

And the crew concludes, “Let’s give them apples.”

We end up with a solution that doesn’t deliver on the opportunity, which means we don’t deliver on our desired outcome—crossing the Atlantic safely.

Now each objection that took us from oranges to grapefruit to apples was reasonable. They were important constraints that should be considered. But they led to an outcome where we land on a solution that doesn’t solve the target problem.

This happens all the time. I see it every week. Taking the time to externalize this visual structure will help you to catch these errors.

Gaps in our thinking #4: Our solutions don’t connect to our opportunities or our desired outcome. – Tweet This

The Opportunity Solution Tree A visual that maps out the connections between your desired outcome, the opportunities that if addressed will improve that outcome, the solutions that deliver on those opportunities, and the experiments you need to run to test those solutions. An opportunity solution tree visualizes what you are learning in discovery and the decisions you are making along the way. Click to view larger image.

In the previous examples, we are building out what I call an opportunity solution tree.

It’s a simple way of visually representing how you plan to reach a desired outcome. It helps you to make your implicit assumptions explicit.

An opportunity solution tree is a simple visual that helps you reach a desired outcome. – Tweet This

We tend to think in solutions. We all do it.

The power of Bernie’s questions is that they help us move from a solution (buying a house) to the implicit opportunity (feeling grounded in your community), through to generating new ideas.

This simple structure can be repeated over and over again, to explore how we might reach a desired outcome.

Bernie’s questions aren’t new. Reframing has been a part of our practice for as long as we’ve been designing complex solutions.

What is new is the simple visual that helps us externalize our thinking. That externalization helps us to examine our thinking, it allows others to critique our thinking, and it can guide us toward what to do next.

When we visually externalize our thinking, we can examine it and others can critique it. – Tweet This

It’s what I’ve found has been missing in this new world of product discovery.

And it’s radically changing the way teams work.

Building the 4 Sections of Your Opportunity Solution Tree Before we can start exploring how to use your opportunity solution tree to guide product discovery, we have to cover how to build your tree.

Section #1: Good product discovery starts with a clear desired outcome. That might sound easier than it is. I see many teams struggle to define what success looks like.

If your team uses OKRs, you might start with one of your Key Results.

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.

Some teams focus on more than one goal or metric at a time. 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. If you had to make trade-offs, which would win?

This advice definitely falls into the obvious camp, but it’s harder than it looks. 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.

Good product discovery starts with a clear desired outcome. – Tweet This

Section #2: Opportunities should emerge from generative research. 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.

We want to frame these needs as opportunities and capture them on our tree.

To get started you can capture what you think the opportunities are in your problem space. But you’ll want to quickly refine these with 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.

Opportunities should emerge from generative research. Tweet This

Section #3: Solutions can and should come from everywhere (as long as they are bounded by an opportunity). We’ve all had the experience where we’ve had to manage an executive’s pet idea. This is why we have the HiPPO acronym (Highest Paid Person’s Opinion).

These experiences tend to make us shy to engage others in idea generation.

But there’s plenty of research that shows everyone can and should contribute to idea generation.

Fortunately, the tree helps us do that in a structured way. Every solution should connect to an opportunity.

In other words, 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.

Again, this sounds simple. But it’s very challenging in practice.

Solutions can and should come from everywhere (as long as they are bounded by an opportunity). – Tweet This

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—not your whole solution.

By giving experiments their own row on the tree, it encourages us to think about sets of experiments that will allow us to test a single solution. This helps us escape the trap of over relying on A/B tests to test the whole solution.

Experiment to evaluate and evolve your solutions. – Tweet This

Using Your Opportunity Solution Tree to Guide Product Discovery I want to be clear. I just skimmed over how to build your tree. A full answer will require a book. There’s a lot to unpack here. But 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. Many free-floating ideas with no organization. Too many ideas with no clear prioritization.

Many teams are here. So first, you aren’t alone. However, your odds of driving meaningful product outcomes will be low.

Start by defining your desired outcome. What’s the most important metric your team can impact? You want to pick an outcome that will drive the most value for your business right now.

Then start to enumerate the opportunities that might drive that outcome. Remember to stay in the problem space. If you can, do some generative research to frame the opportunities in the same way your customers would.

Finally, try to connect each of your solutions to those opportunities. If you have some solutions that don’t connect, look for a missing opportunity or set the solution aside. It’s a distraction for now.

And don’t forget to use your new view of the problem space (the opportunities you identified) to generate new solutions.

Scenario #2: You have a clear desired outcome, but are still struggling to prioritize the ideas in your backlog. Tree chart with desired outcome as the root and Ideas A through G as children with no order. You have a desired outcome, but no strategy for how to reach it.

As we make the shift toward autonomous product teams, more of our work is being guided by a clear desired outcome. The recent popularity of OKRs is helping to accelerate this.

But this doesn’t always mean we approach our work in a structured way. We still often find ourselves with too many ideas and no way to prioritize them.

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. We want to only consider solutions that deliver on our target opportunities. And within an opportunity, we want to prioritize based on how likely each solution will deliver on that opportunity.

Scenario #3: You fixate on one opportunity, one solution, and one experiment at a time. Tree chart with desired outcome as root with one child opportunity. It has two solution children, one of which has an experiment child. You fixate on a single solution.

One area where the tree can be immensely valuable is to help us see the big picture of how we are approaching our work. Both this and the following scenario are ones in which we aren’t balancing the depth and breadth of our tree.

When our tree is too deep (at the cost of breadth) as we see here, we fixate on one opportunity, one solution, and one experiment. This is the opposite of multitracking.

It you find yourself in this situation, take some time to expand your tree horizontally at all levels. Do more generative research to identify more opportunities, engage people in idea generation to generate more solutions, and run several experiments to test the riskiest assumptions associated with your target solutions.

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

Scenario: #4: You consider way too many opportunities, solutions, and experiments at once. Large opportunity solution tree with too many options in each section. You consider too many options in each section.

However, don’t take multitracking too far. It’s easy to stay in the problem space for too long, trying to identify every opportunity. Idea generation is fun, but once we have some promising ideas, the return on the investment starts to peter out. We don’t want to test every idea we have.

If we don’t move vertically down our tree, we’ll never ship a viable product. We have to balance horizontal expansion with vertical depth.

Our discovery has to lead to delivery.

Discovery has to lead to delivery. – Tweet This

A Framework for Continuous Product Discovery And finally, don’t think about this as a linear process.

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

Every week you want to be doing some activities that support discovering and refining new opportunities and every week you want to be doing some activities that support discovering and refining solutions.

And, of course, every week you want to be delivering value to your customer.

Nobody said dual-track was easy. But it does lead to better products. And isn’t that what we all want?

Give It a Try There is so much more I could write about this opportunity solution tree.

Next week, I’ll write more about how to use the structure to communicate your work, to make better decisions, and to better collaborate with your team.

In the meantime, I encourage you to try using it.

Consider the following questions:

Does your team have a clear desired outcome? Are you engaging in generative research to identify compelling opportunities in the market? Are you always entertaining new solutions? Are you running experiments every week? And most importantly, can you connect the dots between all these activities using this structure?

Source: producttalk.org