Issue Tree in Consulting: A Complete Guide (With Examples)


What’s the secret to nailing every case interview? Is it learning the so-called frameworks? Nuh-uh.

Actually, that secret lies in an under-appreciated, yet extremely powerful problem-solving tool behind every real consulting project. It’s called the “issue tree”, also known as “logic tree” or “hypothesis tree” – and this article will teach you how to master it.

What is an issue tree?

An issue tree is a pyramidal breakdown of one problem into multiple levels of subsets, called “branches”. It can be presented vertically (top-to-bottom), or horizontally (left-to-right). An issue tree systematically isolates the root causes and ensures impactful solutions to the given problem.

The issue tree is most well-known in management consulting, where consultants use it within the “hypothesis-driven problem-solving approach” - repeatedly hypothesizing the location of the root causes within each branch and testing that hypothesis with data. Once all branches are covered and root causes are found, impactful solutions can be delivered.

The issue tree is only part of the process used in case interviews or consulting projects. As such, it must be learned within the larger context of consulting problem-solving, with six concepts: problem, root cause, issue tree, hypothesis, data & solution, that strictly follow the MECE principle.

Every problem-solving process starts with a well-defined PROBLEM...

A problem is “well-defined” when it is attached with an objective. Let’s get straight to a business problem so you can get a good perspective on how it is done. So here’s one:

Harley-Davidson, a motorcycle company, is suffering from negative profit. Find out why and present a solution.

Now we’ve got our first piece of the tree:

 ...then tries to find its ROOT CAUSES…

To ensure any solution to the problem is long-lasting, consultants always look for the root cause.

Problems are often the last, visible part in a long chain of causes and consequences. Consultants must identify the very start of that chain – the root cause – and promptly deal with it to ensure that the problem is gone for good.

The diagram is a simple representation. Real problems can have multiple root causes. That’s where the issue tree comes to the rescue.

Since Harley has been reporting losses, it tried to decrease cost (in the simplest sense, profit = revenue - cost) by shutting down ineffective stores. As you may have imagined, it wasn’t very effective, so Harley set out to find the real source of the problem.

...by breaking it down into different BRANCHES of an issue tree

An issue tree ensures that all root causes are identified in a structured manner by breaking the problem down to different “branches”; each branch is in turn broken down into contributing sub-factors or sub-branches. This process is repeated through many levels until the root causes are isolated and identified.

For this problem, Harley deducted that losses must be due to decreasing revenue or increasing cost. Each branch is in turn segmented based on the possible reasons

For a branch to be included in the issue tree, there must be a possibility that it leads to the problem (otherwise, your problem-solving efforts will be wasted on the irrelevant).

To ensure that all possibilities are covered in the issue tree in a neatly organized fashion, consultants use a principle called “MECE”. We’ll get into MECE a bit later.

A HYPOTHESIS is made with each branch…

After we’ve developed a few branches for our issue tree, it’s time to hypothesize, or make an educated guess on which branch is the most likely to contain a root cause. 

Hypotheses must adhere to 3 criteria:

  1. It must follow the issue tree – you cannot hypothesize on anything outside the tree 

  2. It must be top-down – you must always start with the first level of the issue tree

  3. It must be based on existing information – if your information suggests that the root cause is in branch A, you cannot hypothesize that the root cause comes from branch B

Once a hypothesis is confirmed as true (the root cause is inside that branch), move down the branch with a lower-level hypothesis; otherwise, eliminate that branch and move sideways to another one on the same level. 

Repeat this process until the whole issue tree is covered and all root causes are identified.

Harley hypothesized lower revenue is either due to losing its customers because they came to competitors or they weren’t buying anymore, or it couldn’t attract new buyers

But wait! A little reminder: When solving an issue tree, many make the mistake of skipping levels, ASSUMING that the hypothesis is true instead of CONFIRMING it is. 

So, in our example, that means from negative profit, we go straight into “losing old customers” or “can’t attract new customers” before confirming that “decreasing revenue” is true. So if you come back and reconfirm “decreasing revenue” is wrong, your case is completely off, and that’s not something consultants will appreciate, right?

Another common mistake is hopping between sub-branches before confirming or rejecting one branch, so that means you just jump around “losing old customers” and “can’t attract new customers” repeatedly, just to make haste of things. Take things very slowly, step-by-step. You have all the time in the world for your case interview.

But testing multiple sub-branches is possible, so long as they are all under the same branch and have the same assessment criteria.

So for our example, if you are assessing the sales of each motorcycle segment for Harley, you can test all of them at once.

The hypothesis is then tested with DATA... 

A hypothesis must always be tested with data.

Data usually yield more insights with benchmarks – reference points for comparison. The two most common benchmarks in consulting are historical (past figures from the same entity) and competitor (figures from similar entities, in the same timeframe).

Using “competitor benchmark” to test if competitors are drawing away customers, Harley found that its competitors are also reporting losses, so it must be from something else!

...to find an ACTIONABLE SOLUTION

After the analyzing process, it’s time to deliver actionable solutions. The solutions must attack all the root causes to ensure long-lasting impact – if even one root cause remains untouched, the problem will persist.

Remember to deliver your solutions in a structured fashion, by organizing them in neat and meaningful categories; most of the time, solutions are classified into short-term and long-term.

So Harley found that it is losing its traditional customer base - old people, as they were the most vulnerable groups in the pandemic, so they stopped buying motorcycles to save money for essentials, or simply didn’t survive. 

Harley also found that it can’t attract new, younger buyers, because of its “old-school” stigma, while also selling at premium price tags. So the short-term solution is setting more attractive prices to get more buyers; and the long-term solution is renewing itself to attract younger audiences.

Our case was a real problem for Harley-Davidson during the pandemic, whose sales plummeted because its target audience were either prioritizing essentials, or dead. So now, Harley has to change itself to attract younger people, or die with its former customer base. 

 

What Is MECE and How Is It Used in an Issue Tree?

A proper issue tree must be MECE, or Mutually Exclusive, Collectively Exhaustive.” Mutually exclusive means there’s no overlap between the branches, and collectively exhaustive means all the branches cover every possibility. This is a standard all management consultants swear by, and together with the issue tree, a signature of the industry. 

To answer whether an issue tree is MECE or not, you need to know all the basic and “advanced” rules of the MECE principle, and we’ll talk about those here. If you want a more comprehensive guide on MECE, check out our dedicated article on MECE.

Basic rule #1: Mutually exclusive

Every branch and sub-branch in an issue tree must be cleanly separated from others on their level.

Adherence to this rule ensures that there will be no duplicated efforts, leading to maximum efficiency in problem-solving. It also allows the consultant to isolate the root cause more easily; otherwise, one root cause may manifest in multiple branches, making it harder to pinpoint.

For example, an apparel distributor trying to find out the cause of its decreasing unit sales may use the cleanly-separated product segments: High-end, mid-range, and entry-level. A non-mutually exclusive segmentation here would be: high-end products and footwear.

Basic rule #2: Collectively exhaustive

The branches and sub-branches in an issue tree must cover all possible factors (there must be no gap in the tree), ensuring that all root causes can be identified so the problem will be solved with maximum effectiveness. 

A collectively exhaustive issue tree also covers only the relevant factors - if one factor is not related to the problem, it must not be included. 

If the aforementioned apparel distributor omits any of the product segments in its analysis, it may also ignore one or a few root causes, leading to ineffective problem-solving. But even if it produces runway-exclusive, not-for-sale pieces, those are not included in the issue tree because they don't contribute to unit sales.

Advanced rule #1: Parallel items

This rule requires that all items are on the same logical level.

High-end, mid-range, and entry-level are three parallel and MECE branches. But if we replace the first two with “high-and-mid-range”, the whole issue tree becomes non-parallel and non-MECE, because the new branch is one level higher than the remaining “entry-level” branch.

Advanced rule #2: Orderly List

This rule requires that all items are arranged in a logical order.

So for our apparel distributor, the branches can be arranged as high-mid-low or low-mid-high. Never go “high-low-mid” or “mid-low-high”, because this arrangement is illogical and counter-intuitive.

Advanced rule #3: The “Rule of Three”

The ideal number of branches on any level of the issue tree is three - the most intuitive number to the human mind.

Three items are often enough to yield significant insights, while still being easy to analyze and follow; segmentations into 2 or 4 are also common. 5 is acceptable, but anything more than that should be avoided.

Our apparel distributor may have dozens of product lines across the segments, but having that same number of branches in the issue tree is counter-intuitive and counter-productive, so we use the much more manageable 3 segments.

Advanced rule #4: No Interlinking Items

There should be minimal, and ideally no connections between the branches of the issue tree. 

If the branches are interlinked, one root-cause may manifest itself in multiple symptoms across the tree, creating unnecessary confusion in the problem-solving process.

 

Variants of an issue tree

Beside the “why tree” we used to solve why Harley was reporting losses, there are two other common trees, the “which tree” and the “how tree.” The which tree answers which you should do among the choices, and the how tree answers how you should do something.

Why tree helps locate and attack root causes of a problem

We’ve shown you how a why tree could be used to break down a problem into smaller pieces to find the root causes, which involves several important concepts, but in short there are 3 things you need to do:

  • Locate root causes by narrowing down your search area. To quickly locate root causes, use breakdown by math, process, steps or segment, or any combination of those. We’ll talk about that a bit later

  • Identify root causes from what you’ve hypothesized. Remember, all hypotheses must be tested with data before reaching a conclusion

  • Suggest solutions to attack the root causes to eliminate the problem for good. However, sometimes the root causes cannot be solved effectively and efficiently, so we might also try to mitigate their effects

Which tree helps make the most suitable decision

The which tree is a decision-making table combining two separate issue trees – the available options, and the criteria. The options and criteria included must be relevant to the decision-maker. When considering choosing X over something, consultants might take a look at several factors:

  • Direct benefits: Does X generate more key output on its own?

  • Indirect benefits: Does X interact with other processes in a way that generates more key output?

  • Costs: What are the additional costs that X incur?

  • Risks: Can we accept the risks of either losing some benefits or increasing cost beyond our control?

  • Feasibility: Do we have enough resources and capability to do X?

  • Alternative: Are there any other alternatives that are better-suited to our interests?

Additionally, the issue tree in “Should I Do A or B” cases only contains one level. This allows you to focus on the most suitable options (by filtering out the less relevant), ensuring a top-down, efficient decision-making process.

How tree helps realize an objective

The how tree breaks down possible courses of action to reach an objective. The branches of the tree represent ideas, steps, or aspects of the work. A basic framework for a how tree may look like this:

  • Identify steps necessary to realize the objective

  • Identify options for each steps

  • Choose the best options after evaluations

Again, like the two previous types of issue trees, the ideas/steps/work aspects included must be relevant to the task. 

A restaurant business looking to increase its profitability may look into the following ideas:

 

Consulting frameworks – templates for issue trees

Don’t believe in frameworks…

In management consulting, frameworks are convenient templates used to break down and solve business problems (i.e. drawing issue trees).

So you might have heard of some very specific frameworks such as the 4P/7P, or the 3C&P or whatever. But no 2 cases are the same, and the moment you get too reliant on a specific framework is when you realize that you’re stuck.

The truth is, there is no truly “good” framework you can use. Everyone knows how to recite frameworks, so really you aren’t impressing anyone.

The best frameworks are the simplest, easiest to use, but still help you dig out the root causes.

Simplest, easiest to use” means you can gain a sufficient amount of insights by using the fewest branches in the issue tree. It also means all the necessary information to test the hypothesis must exist and be easy to find.

“Simplest, easiest to use” also means you can flexibly combine frameworks to solve any cases, instead of scrambling with the P’s and the C’s, whatever they mean.

“Simplest, easiest to use” frameworks for your case interviews

There are 5 ways you can break down a problem, either through math, segments, steps, opposing sides or stakeholders.

  • Math: This one is pretty straightforward, you break a problem down using equations and formulae. This breakdown easily ensures MECE and the causes are easily identified, but is shallow, and cannot guarantee the root causes are isolated. An example of this is breaking down profits = revenues - costs

  • Segments: You break a whole problem down to smaller segments (duh!). For example, one company may break down its US markets into the Northeast, Midwest, South and West regions and start looking at each region to find the problems 

  • Steps: You break a problem down to smaller steps on how to address it. For example, a furniture company finds that customers are reporting faulty products, it may look into the process (or steps) on how its products are made, and find the problems within each steps

  • Opposing sides: You break a problem down to opposing/parallel sides. An example of this is to break down the solution into short-term and long-term 

  • Stakeholders: You break a problem down into different interacting factors, such as the company itself, customers, competitors, products, etc. 

To comprehend the issue tree in greater detail, check out our video and youtube channel:

Read next

Scoring in the McKinsey PSG/Digital Assessment

The scoring mechanism in the McKinsey Digital Assessment

Scoring in the McKinsey PSG/Digital Assessment

The scoring mechanism in the McKinsey Digital Assessment

Related product