Why This Opportunity Solution Tree is Changing the Way Product Teams Work

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.

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.

The Power of Mental Representations

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

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.

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.

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

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.

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?”

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.

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

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.

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

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

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.

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.

The Opportunity Solution Tree

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.

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.

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.

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.

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.

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.

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.

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.

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?

It’s harder than it looks. Give it a shot and let me know how it goes in the comments below or via email.

This is great article that helps describe the challenge of knowing the problem before you start looking for solutions. The really hard part about the process is actually being able to write the problem as a problem.

Here is where your example falls into the same trap:
The rationale “I would feel more grounded in my community” is a benefit or outcome that owning a house may potentially deliver, but the key thing here is that it is NOT a problem statement. The Problem is going to be more personal an uncomfortable. It will be the barrier or friction that is preventing this customer from currently “feeling more grounded in their community”. We need to gently (and sometimes not that gently) into the “WHY” of the problem.

Why don’t they feel grounded in the community? This will also uncover a deeper understanding of the actual customer that you are considering?

For example:
1) Someone who has just been released from prison after serving jail time wants to reintegrate to with the community. The problem might be that they are afraid of what other will think of them, or that they are actively being excluded or are feared in the community.
2) A family who has just migrated from a different country ans speaks a different language.
3) A retiree who is moving in to a retirement village or community.

Any of these may have the desired outcome of “wanting to feel more grounded in my community” but the underlying PROBLEM that they have in each case may be very different. It can be very difficult to tease out the actual problem that is the most valuable one to solve, but this activity will deliver far higher returns to a business than testing solutions.

Thanks for taking the time to write such a detailed comment. I agree with your argument. You’ll see in future posts as I get into how to frame opportunities more of what you highlight will be discussed. In the example that Bernie highlighted, he actually took us through his set of questions twice to help to better get at the what you highlight. This is also similar to the five whys exercise. In this particular post, my focus was on capturing the structure of the whole tree and that doesn’t allow going into as much detail in each of the parts. That’s why this is turning into a book.

At @brainmates we use a combination of asking “Why?” and “So what?” to flip flop between root cause analysis and impact assessment. This creates a similar tree structure that can help prioritise the problems that are worth solving before the solution thinking starts. I look forward to seeing this as a book.

Really liked this post and it aligns with a lot of thinking I’ve been doing around Problem Space vs. Solution Space. It also feels like the Jobs To Be Done interview can be a nice augment to this and help get to the “personal and uncomfortable” things that Nick describes. I read your article back to back with this one and it made me see a lot of connections and opportunities:

I’m going to try this structure as a way to work through a measure/learn phase with a client that is new to the whole process. So thanks, as this gave me some just-in-time ideas on my flight from YYZ to LAX!

Thanks for the comment. I agree that it is very complementary with Job to Be Done. My goal is to be framework / tool / methodology agnostic. There are a lot of ways to discover opportunities. There are a lot of formats that are great for communicating opportunities. I find that some work better in some contexts vs. others. What’s most important is that opportunities emerge from an understanding of customers needs.

I thought it is “End-Means Diagram” with a new name but I find there is a lot more to your present proposal / method. I started reading closely and found it keeps stretching. I have browsed the entire article and decided to revisit.

I liked your “Test of Pure Requirements: Does it tell you How to meet any of the requirements?” “If yes, it is NOT a pure requirement.” That’s really smart and simple.

Awesome Teresa. This is great. I can see myself in most of the mentioned mistakes. This helps me a lot to understand why they happen and how to address them.
Looking forward to put it in practice! And yes, will provide feedback when it will be meaningful.
Thank you

One thing I’m struggling to fully understand are the opportunities, how they surface from research, how they relate to the outcome and how do you differentiate similar opportunities. Hopefully you’ll expose more in further write-ups.

(I think the struggle might be related to me not being a native speaker)

Each of your questions have long answer, but I promise it will all be in the book. In the meantime, I’d start with the following:

For writing a desired outcome, look into OKRs (Objectives and Key Results). A key result maps nicely to my desired outcome.

For making strategic decisions about opportunities, I’ll have a blog post out soon about assessing opportunities, but in the meantime, I’d recommend looking into Mary Cagan’s post on opportunity assessments. A quick Google search should bring it up.

And for prioritizing solutions, the key is to surface the underlying assumptions and to test them and to use what you learn to inform which solutions are most promising.

Great article, Teresa.
I am a product manager in China. Very excited to see your post. I am planning to share this post with my team, and we’ll use your framework to discover product opportunities and solutions.

Great article Teresa. I am enjoying your simplified versions (and universal language) to describe something really complex and hairy. A lot of this is similar to what we have taught teams around the difference between Needs (which is getting closer to a problem statement) and Solutions. I have found the teaching with Needs as VERBS (feeling connected to community) and Solutions as NOUNS (a house) to be helpful for teams when trying to articulate problem vs. solution spaces. I also use the CNVC universal human needs for folks to articulate this: https://www.cnvc.org/Training/needs-inventory. How do you feel the Needs language or the 5 Whys compares with your model? I could see yours as a theory framework and then there are lots of other tools frameworks that assist at different points in the problem/solution continuum!

I could see yours as a theory framework and then there are lots of other tools frameworks that assist at different points in the problem/solution continuum!

This is exactly what I am going for. There are many tools for discovering opportunities: Jobs-to-be-Done interviews, customer observations, customer discovery (as in Steve Blank’s work) interviews, many of the design thinking empathy activities, etc. I’m always looking for more tools, but fundamentally I just want to see that teams are doing SOMETHING to discover opportunities before jumping to solutions.

Thanks for the article! My main thought was linking this to the value proposition canvas. This is pains and gains of the customer mapped to your features. You could then add you tree for those pains and gains to generate new solutions. What do you think? Thanks, Tim

Hi Teresa
Nit-picking on a side point but its important so will do 🙂
“Product Managers are Problem Solvers” is a incomplete statement. I discovered this in a discussion with a VC. His comeback was, “well everyone is a Problem Solver”.
We need to have a better articulation e.g. Solvers of Consumer Problems by ideating and creating Products to solve those problem which also produce business value for their company?
The Next comeback in this is Consumers do not really know what they want. So their articulation of problem is poor. E.g. who wanted an iphone before it was built by Apple?
See where I am going?
your thoughts please.
Thanks
Ujwal

I agree that all people are problem solvers. A product manager’s job is to solve customers’ problems while creating value for their business. Steve Jobs did say that customers don’t know what they want. But he meant they are not technology experts, they don’t know what solutions are possible. However, they do know what problems they have.

Hello Teresa. Thank you for an eye-opening post.
I am pretty new to product discovery, but I think I got the idea of the Opportunity Solution Tree thanks to the examples. Could you, however, please give me some example of an experiment?
You mentioned that “Experiments reflect the work that you are doing to test the riskiest assumptions behind your solutions—not your whole solution.”
What would be examples of few experiments for the “Add dislike button” solution? I must be missing the point here because the only I can think of is doing an A/B test to see whether the variant with the dislike button performs better than the variant without it. But from the quote I can tell that this is the exact opposite of what experiments are supposed to be.

A/B tests are experiments, but they are the slowest way to learn. You have to build the new functionality before you learn whether or not it works. But we have lots of ways to experiment other than a/b tests. Try looking up concierge tests, wizard-of-oz tests, smoke screen or fake door tests, for a few.

Thanks a lot for the post. We have been figuring out ways to structure our discussion on our product and this looks like an interesting way for us. More so because we have been working in a similar way but had few blocks missing in the tree and the description above makes really clear as to what we were missing :). I have a question though. When you want to prioritise one solution for an opportunity over other, how do we decide between improving a solution and creating a new one. We are currently at a stage where we have 2-3 big solutions residing in our product and we might want to prioritise between improving the existing ones vs. creating a new one. Where does that aspect sit in the tree?

Hi Teresa, once again thanks for this excellent post. Since I work with a remote development team I’d like to visualize the tree online. Which tools would you recommend to use? I have tried Realitimeboard and Draw but moving stuff around is not so easy there.

I see teams using RealtimeBoard, Draw.io, and Mural, but there are plenty of digital whiteboards to try out depending on your preferences. I use Draw.io and while it’s a bit clunky it does support real-time editing by multiple people quite well.

Teresa is a product coach helping teams adopt user-centered, hypothesis-driven product development practices. She works with companies of all sizes on integrating user research, experimentation, and the right analytics into the product development process resulting in better product decisions. Read More…

Search Product Talk

Teresa is a product coach helping teams adopt user-centered, hypothesis-driven product development practices. She works with companies of all sizes on integrating user research, experimentation, and the right analytics into the product development process resulting in better product decisions. Read More…