Problem solving is at the very heart of any role, especially product management. But although problem solving is a skill — it's never taught.

Over the last 50 years, prestigious consulting firms have refined an approach to problem solving that can be applied to any business problem. And core to this problem solving methodology is the concept of hypothesis trees.

## What is a hypothesis tree?

A hypothesis tree is an approach to deconstruct a problem statement into logical and testable hypotheses.

As we continue to break down each hypothesis, we will naturally sprout more and more branches of our tree. And we stop when we have a bunch of simple hypotheses that we can test.

But the operative word here is *logical*. As we deconstruct the problem statement, we must continually test each new branch to ensure that it follows a simple principle called the MECE Principle.

## What is the MECE principle?

The MECE Principle (pronounced mee-see) stands for:

**Mutually exclusive**. Concepts are independent and there is no overlap between them. This ensures we don’t double count anything.**Collectively exhaustive**. When put together, the concepts encompass the entire parent concept. This ensures that we don’t miss anything.

If you don’t understand the MECE Principle right away, don’t worry. There will be plenty more examples to come, and you *will* be able to grasp the concept with some more practice.

## Deconstructing the first layer of our hypothesis tree

Now to the bread-and-butter, let’s deconstruct a problem statement.

Let's assume we have the following problem statement:

How do we increase monthly revenue by 25% within the next six months?

It’s time to think through how we can break this problem statement into hypotheses. There are multiple approaches that we could take and, as long as they are MECE, none of them are wrong.

In this case, we can see that our problem statement is a revenue question. So a sensible approach would be to ask ourselves *what is revenue made up of?*

Well, revenue is essentially just sales multiplied by price. So we could break down our problem statement into the following hypotheses:

- Increase the number of sales
- Increase the average revenue per sales

We can be confident that our breakdown is MECE because:

- Revenue = Number of Sales x Revenue Per Sale. There is nothing missing from this formula, so we can be confident that the breakdown is collectively exhaustive.
- We know that Number of Sales and Revenue Per Sale are distinct concepts, there’s no overlap. So we can be confident that the breakdown is mutually exclusive.

Perfect! We’ve deconstructed the first layer of our hypothesis tree and it passed our test of MECE-ness. Now we are ready to break down each of the new branches, and continue building out our tree.

## Breaking down the next layer

Let’s start with our next hypothesis: *increase number of sales. *

There are a number of ways that we could choose to break this one down. A few examples include:

- Breaking down sales into each different sales channel (i.e. total sales = online sales + in-store sales + app sales)
- Breaking down sales into customers and purchases (i.e. total sales = number of customers * frequency of purchases)
- Some other way?

Again, so long as our breakdown is MECE, then there’s no right or wrong answer. Choose the breakdown that makes best aligns with how you think.

In my case, I think the most logical breakdown of *increase number of sales* is:

- Increase number of customers
- Increase purchase frequency

But is this breakdown MECE? Let’s take a look:

- Total sales = number of customers x sales per customer, and there’s nothing missing from the formula (collectively exhaustive)
- Number of customers and sales per customers are clearly distinct concepts, there’s no overlap (mutually exclusive).

## Breaking down the breakdowns

From here, we continue to break down each hypothesis into lower-level hypotheses. And every time we do that, we check the breakdown to ensure that it satisfies the MECE Principle.

Instead of breaking down each hypothesis individually, I’m going to fast-forward to show you what our hypothesis tree might look like after we’ve broken down a few more levels of hypotheses.

But before we get there, I suggest that you have a go at breaking down our hypotheses tree yourself. You can check your working against the worked example below.

## Stop breaking down hypotheses when they are small and measurable

Although hypothesis trees apply science to problem-solving, there’s still some degree of art involved. And there is an art in knowing when to stop breaking down hypotheses.

In the hypothesis tree above, I decided to stop at increase new customer prospects and improve prospect conversion rate.

But how did I make that call?

The general rule of thumb is to break down hypotheses until they are discrete concepts and easily measurable. This is because your next step to test each of the hypotheses.

Technically, I *could* continue to break down hypotheses. For example, *increase new customer prospects* could be broken down into different sources (e.g. prospects from paid advertising, prospects from organic search, etc).

However, those things aren’t really discrete concepts. They belong to a discrete concept called *prospects.*

It might be a little confusing right now, I get that. It's tricky to explain. But rest assured, as you practice your own hypothesis trees, you’ll naturally start to get a feel for what constitutes a discrete concept and when you should stop breaking down.

Plus, worst case scenario: you either remove some breakdowns if you’ve gone too granular, or you continue to break down hypotheses if you’ve stopped to early.

## Prioritise your hypotheses

We’ve successfully broken down our problem into a number of simple hypotheses.

Ideally, we would have the time and resources to rigorously test every hypothesis. However, the reality of working in tech (and especially in a startup) is that we don’t always have the luxury of infinite time or resources.

But we’re good product managers! And regardless of the circumstances we’re in, we will have to work around it. We can do this by making sure that we focus on the hypotheses that are most important.

So the nest step is to prioritise our hypotheses. There's a number of ways to do this, including:

- [Quantitative analysis]
- [Pain-gain matrix]

Regardless of which method you use, one thing to keep in mind is ‘close enough is good enough’. Don’t agonise over being too specific or accurate.

## Build-up solutions with solution-focused hypothesis trees

Now comes the fun and creative part!

We should treat each of our prioritised hypotheses as new problem statements, and build out new solution-focused hypotheses trees for each of them.

Let's build-up solutions for the hypothesis: *Improve our new prospect conversion rate.*

Like when we broke down our problem statement earlier, we need to make sure that we apply the MECE Principle at every level.

...and eventually we might come up with something like this!

## What's next?

By this stage, we’ve successfully done two things:

- We’ve successfully narrowed down a big, nebulous problem into a prioritised list of solutions. Based on our prioritisation efforts, we are also confident that we have picked the
*correct*solutions. - Thanks to the logic of the hypothesis tree and application of the MECE Principle, we also know that we have not missed any potential solutions.

In our specific case, we have a prioritised list of ways we can improve revenue by 25% within the next 6 months.

Now we work through the detail of executing on these potential solutions.