Issue Tree

Like a scientist uses an experiment to test a hypothesis, a consultant uses a framework called an issue tree. An issue tree lays out a set of logical conditions that, if proven correct, prove the hypothesis correct. The term “issue tree” comes from the way this framework looks when diagrammed on paper – like a tree on its side.

Another way to look at an issue tree is as a logical argument that can be tested with data.

The logic of an issue tree and a hypothesis is analogous to the “if/then” statement common in arguments and proofs:

Issue tree branches = if

Hypothesis = then

If these three factors (Branch 1, Branch 2, Branch 3) are true, then the hypothesis is true. The if/then construction provides a clear, logical structure that can be proven or disproven with data. This is the essence of problem structuring using issue trees – you make a logical argument based on the hypothesis that can be easily validated with concrete data.

Your Hypothesis

More important than memorizing the main case frameworks is the ability to take your hypothesis and build an issue tree (or customize a standard framework) that will test your hypothesis in this specific case.

The MECE Test

MECE is a principle used by management consulting firms to describe a way of organizing information. The MECE principle suggests that, to understand and fix any large problem, you need to understand your options by sorting them into categories that are:

Mutually Exclusive – Items can only fit into one category at a time

And

Collectively Exhaustive – All items can fit into one of the categories

MECE is a systematic framework that helps solve complex problems. By creating an issue tree where each branch represents an exclusive group of factors, you will be able to narrow it down to the single factor that is causing the problem. If there is an overlap in categories, you won’t be able to specifically point out which area the problem is arising from.

To put it simply, a MECE set is one that has no overlaps and no gaps.

Using Issue Tree’s in a Case Interview

What follows is a question I received recently from a user on how to use issue trees in a case interview I am including the student’s question as well as my response.

Reader Question on Using an Issue Tree:

First, I would like to thank you very much for your LOMS program. I found it very helpful.

Your emails are also very useful for me to learn many new things from other people’s experiences.

My questions is about how to structure a case after a case question is given.

I am a PhD student and my most comfortable way of setting up a structure is to use the issue tree as you presented in the LOMS program.

However, when I was mock-interviewing with MBA students, I found my structures are very simple compared to what they have.

For example, when I was given a profit case, I only wrote on my paper, revenue, cost, and the components of the two.

Then I started to ask for information around these factors and move along the case.

While the MBA students I interviewed tended to write down many other factors that could cause the drop of the profit and also possible ways to solve the profit decline.

Basically, everything they can think of.

This approach looks to me more or less like brain-storming. But one reason my MBA practice partner told me is that writing down many factors shows the interviewer the breadth of thinking.

I am not sure which way would be better. Since a structure in a case interview is so important, I hope you can help me out here and explain a little bit more what you think of the two approaches.

Also, how many layers should I structure initially in a issue tree?

Thank you and look forward to your reply!

My Reply:

As you know from LOMS, one of the big differences between candidates who “ace the case” vs. those that don’t is that the structure used by a strong candidate can be drawn as an issue tree.

Starting off a case with an issue tree that has multiple layers is a good idea provided 1) you can do it, and 2) you’re able to realize if you did it wrong and adapt.

It is not always easy to do, and it is easy to screw up.

What you do not want to do is have an unstructured brainstorm of every possible reason for why say a company might be unprofitable.

That would be a mistake.

You do not want a laundry list of every possible way a company can be unprofitable and you especially do not want a laundry list of solutions for how to fix a company’s profitability problem until after you have isolated the specific cause of the problem.

But, if you have a very structured issue tree that is MECE and you can anticipate which ways you would want to structure the 2nd and even 3rd layer of your issue tree, it’s worth doing… especially if you have a very specific hypothesis in mind.

If you feel the need to discover more before going down a few extra layers in the issue tree, on balance I think it will not hold you back from getting an offer if you got the case right using this approach.

There are some downsides to be mindful of.  If you outline three layers of an issue tree before you get any data, you have to keep in mind the possibility that you structured layers 2 and 3 in a sub-optimal way.

So, you have to be open to the idea that you might change your structure as you discover data in layer 1.

Maybe you know sales are down, you could segment sales by country, by product, by division, by sales channel.

Which one is the right way?

If you do the structure up-front and pick country for the 2nd layer, and then realize the key issue is a difference in sales growth by sales channel, then you have a sub-optimal structure.

This, by itself, is not a problem. It is only a problem if you set up a sub-optimal structure and don’t realize it is sub-optimal once you have enough information to determine it.

When I interviewed, I did not lay out 2nd and 3rd layers of issue trees up-front and simply decided on them as I went.

I am hearing that some candidates are doing this today (I guess people are much more prepared these days then when I was interviewing some years ago).

If they can pull it off without confusing themselves, it does come across well to the interviewer.

If the multi-layer issue tree structure implicitly commits them to a particular problem-solving approach and they are not sophisticated enough to realize when there’s a mismatch between their initial structure and the data they are discovering early in the case… and if this causes them to not solve the case because of their confusion, then I would say it’s not worth doing.

In other words, as you refine your hypothesis, it is to be expected that your issue tree structure may change.

Some people will find it harder to change an issue structure if they’ve already “committed” to it to the interviewer.

In reality, it is not a problem to change the issue tree structure in the middle of a case — it is done all the time in real client engagements.

It is more important to solve the case in a structured way than it is to show a multi-layer issue tree and not solve the case.

As an example, the issue trees diagrams used to solve the hardest cases in Look Over My Shoulder^® all ended up with multiple layers to the issue tree.

Those issue trees were created throughout the interview — built a piece at a time. If you are able to see deeply enough into the issue tree to draw the entire issue tree up-front, then do it.

Otherwise, it is okay to start with 1 to 2 layers beneath your hypothesis.

The most important thing is that you finish the case with the right issue tree. When you draw out certain pieces in the issue tree is secondary to getting the right issue tree.

Also, I will add that it is easier to do a multi-layer issue tree when the case is very numerical such as in a profitability case. It is harder to do this well in a case that is more conceptual, like business situations.

In a more conceptual case, there is not a finite number of items in the next level of the issue tree or framework.

The risk of going too deep in layers up-front in the case is you end up with an unstructured brainstorm that is not directly related to testing the hypothesis.

You will notice in my issue tree samples in LOMS that I always put my hypothesis at the top.

This is very important.

You will also notice that the branches in the issue tree under the hypothesis will always, always prove or disprove the hypothesis.

I disagree with the characterization that you want to show breadth of thinking by brainstorming every possible reason for a particular client situation.

This is nowhere near as important as being hypothesis-driven, highly analytical and structured in terms of how you test the hypothesis.

Also, in looking at how you describe what your MBA friends are doing in their cases — proposing solutions to the profit problem in a case — that is a very common mistake that, with sufficient practice with LOMS, you will be quick to realize.

You fundamentally cannot solve a problem until you have defined it.

This is a classic mistake that you will see repeated over and over again in the LOMS examples. I call it the “pet theory” mistake where the candidate has a pet theory as to the right solution to solve the client’s problem.

Never ever propose a solution to the case until you have determined the problem!

Never ever propose a hypothesis that is a solution.

A hypothesis should almost always be a hypothesis about either a) the problem, or b) the problem + the solution.

A hypothesis should almost never be a solution without an explicit statement of the problem.

For example, a bad hypothesis is:

1) My hypothesis is that the client should lay off 20% of its employees to improve profitability.

A good hypothesis (which might still be disproved mind you) is this:

2) My hypothesis is the client’s labor costs have increased much more than its competitors as a % of sales and that the right course of action is to layoff 20% of employees.

What is the big difference between these two hypotheses?

The first does not explicitly state the problem.

The second one does.

Notice also how much it easier to prove or disprove the second hypothesis.

All you need to do is compare labor costs as a % of sales for the client vs. competitors. You immediately know if that’s the problem or not.

If you look at the first hypothesis, how do you prove that a 20% layoff is analytically the right decision or not?

It’s just an opinion that is difficult, or at least much more confusing, to prove one way or another.

I refer you back to the Look Over My Shoulder® cases for many examples of candidates using both “good” and “bad” hypotheses.

I would recommend going through the LOMS cases one more time, this time specifically focusing on the hypothesis and issue tree structuring.

By the way, one of the reasons that I recommend going through LOMS five times is that each time you go through it you can focus on a different aspect of the case.

For example, in your situation, you are now very aware and focused on the issue tree setup. In all likelihood, when you went through the LOMS cases for the first time, you were probably focused on just getting a sense of how a case is supposed to be done.

Now that your skills have improved, when you go through LOMS again you have sufficient skills to notice new things — bad habits to avoid & good habits to emulate.

Okay, a final point on this.

Be careful to avoid assuming that your friends with MBAs know what they are talking about just because they have an MBA and you don’t.

The problem with MBAs, and one of the reasons that McKinsey started the PhD recruiting program many years ago, is that some MBAs are good at talking but not that good at problem-structuring.

McKinsey thought that it was easier to teach business terms and concepts to someone who had very strong analytical and problem-structuring skills than it was to teach problem-structuring to someone who was already familiar with business concepts.

From McKinsey’s perspective, it’s best to find someone who is both excellent at business concepts and problem-structuring, but the firm found that they ran out of candidates that were good at both to meet their recruiting goals.

Good ideas without good structure are not useful in consulting for the simple reasons that clients already often have good ideas without structure.

The reason they get stuck and need consultants is they don’t know how to structure their decision-making process — but consultants do.

That’s why top firms look for candidates with strong case structuring skills. And, it is also why I emphasize its importance so much in my emails, in the free Case Interview Secrets videos, and in Look Over My Shoulder^®.