In today’s post we will explain the steps to build hypotheses in a more effective, methodical and,

for a lack of a better word, a more MECE (mutually exclusive and collectively exhaustive) way.

When we do cases with candidates, even our own clients, what always surprises us is how
messy their hypotheses can be.

Its almost as if people are just throwing out ideas they have without any real understanding of
how to create a structure, with a help of a decision tree, to ensure the hypotheses derived from
the structure are on point and MECE.

I think most people are right brain thinkers by nature. That means that they will throw out an idea
first and then decide if it solves the problem they are trying to address. They are
basically brainstorming in a traditional sense of this word. In a very messy way without priorities
and a link to the issue.

And what I find with most hypotheses is that they are very ill considered, they have poor structure
beneath them and most importantly they are not collectively exhaustive nor are they mutually
exclusive.

And by their very nature hypotheses are difficult to make mutually exclusive or collectively
exhaustive.

Think about it. You are developing these ideas and then you have to explain why the problem
exists, which is hard by itself. And then you have to compare each hypothesis with the next
hypothesis you develop to make sure you have listed every possible hypothesis.

You also have to make sure the issue you covered in one hypothesis doesn’t overlap in another
hypothesis. Trying to package issues into hypotheses while trying to get all the issues listed and
in the right order is naturally going to be very difficult.

This is not something that is taught in MBA programs or any training programs that we know of
outside of leading management consulting firms.

HYPOTHESES VS. A DECISION TREE APPROACH. WHICH

APPROACH DOES MBB PREFER?
Leading management consulting firms, whether it is BCG, McKinsey or Bain (collectively
called MBB), like the hypotheses-led approach. This is also called the answer-first approach. The
Although, BCG tends to also be accepting of a decision tree-leading-to-hypotheses approach to
solve the case. We also have had candidates who interviewed at McKinsey and used a decision
tree approach to solve the case and did well. They basically did not go into formal hypotheses.

The approach of using a decision tree is usually less appropriate at Bain where they tend to be
quite frigid in wanting hypotheses upfront.

At McKinsey it depends on how well you use the decision tree approach. If you use it poorly they
probably would think you couldn’t develop hypotheses. That is why you avoided the hypotheses.
And at BCG it is again like at McKinsey. They are not adamant they want hypotheses. They are
OK with the decision tree approach as long as you use it effectively to arrive at the likely
problem.

Case Interviews, Consulting & Rankings

Receive exclusive content, giveaways, private Q&As podcasts, toolkits, videos and more to
using TCO 1 & 2 and regular updates on our rankings of the firms, their offices and their
leadership.

first name last name

email address

Where else can you learn from ex-partners?

Sign up to receive a 3-part complimentary video training series from
TCO 1 & 2. Start now:

Sign Up
Privacy Policy
And in fact, if you use the decision tree approach very well they generally would be very happy
with the technique.

You can also avoid decision trees to build hypotheses, but I have yet to see anyone build neat
and logical hypotheses without using a decision tree. Even I do not do that, and I was a
corporate strategy partner.

AN EFFECTIVE TECHNIQUE TO BUILD HYPOTHESES USING A

DECISION TREE – THE BEST OF BOTH WORLDS
So what I want to talk you through today is a very effective technique we teach all of our clients in
terms of how to build hypotheses that are MECE, by using a decision tree.

In our strategy training program we teach, in depth, how to go through the entire process from
defining the issue, all the way through structuring the problem, developing hypotheses, building
an analysis plan, conducting analyses, synthesizing and providing the recommendation. In The
Consulting Offer training program we teach the part of this process applicable to case interviews.

At a very high level, the strategy engagement structure can be simplified into 6 basic steps,
keeping in mind that it is an iterative process (shown in the exhibit below). Structuring the
problem (developing a decision tree) fits within the step 2 of this process and developing
hypotheses fits within the step 3, as shown in the diagram below.
The technique we teach candidates is to develop a key question upfront – define the problem
(step one in the exhibit below). Then from your key question brainstorm out the sub-drivers of the
key question, which gives you the first-level branches of your decision tree.

For each sub-driver/branch of the first level of the decision tree brainstorm the drivers of that
particular driver. This part of the approach is called structuring the problem or brainstorming
(refer to a step 2 in the exhibit above called structure the problem). Each level of
drivers/branches of the decision tree must be mutually exclusive and collectively exhaustive
(MECE).

All the drivers/branches are collectively called the framework/structure for the case. An example
of a decision tree is shown below.

Finally when you complete the decision tree, the branches must be prioritized and hypotheses
are developed ONLY for the prioritized branches. You can sometimes solve a case without
hypotheses because the drivers are so specific and point out the problem. Only use hypotheses
Hypotheses, for the prioritized branches/drivers, should be worded as follows:

1. Event causing the observable phenomenon…

2. Observable phenomenon…
3. Event caused by the observable phenomenon…

An example of a properly structured hypothesis is below:

The development of decision trees and hypotheses are the core skills behind strategy consulting.

On an actual consulting study, when the hypotheses are developed the team comes up with
analyses necessary to test the hypotheses. They then build the work plan, conduct the analyses,
synthesize the findings and present the final recommendation to the client.

All well planned studies work this way. If you are on a study that does not follow this approach,
you are almost certainly doing unnecessary analyses.

Lets look at an example of applying the technique of developing hypotheses using

a decision tree

Let’s assume I gave you a case whereby I told you that a famous French restaurant, a single
restaurant in downtown Manhattan, faced a steep drop in profits over the last three years. Their
profitability has gone from something like $10,000 a day to about $2,000-$1,000 dollars a day
and they think it has a lot to do with the changes in the way they’ve altered their opening times,
the menu, the clientele they serve and so on.

And most of all, they think the drop in profitability is driven primarily by the change in working
hours. They went from being open during lunch and dinner to being open throughout the day
from 10am to 1am in the morning. They want you to solve the case.

Help them address the problem. Maybe try to solve this case before reading the solution below.
The way we would teach candidates to apply hypotheses with decision tree approach is to start
by taking some time to think about clarifying questions. Then come back once you’ve got your
clarifying questions.

Now, it is possible you have no clarifying questions, but if you do, always take some time to think
about it.

A clarifying question is a question to understand the information provided to you. It is NOT to dig
for more new information to solve the case. It is to understand what you have. If you ask
clarifying questions to gain new information without understanding and using the information
already provided, the interviewer will wonder what is the value of providing you with new
information if you could not use the information initially offered.

You could ask interviewer, “Is it possible for me to go through my clarifying questions. I have four
of them. They could help me develop my structure or would you prefer to see my structure
upfront knowing full well that my clarifying questions, if answered, may change my structure a
little bit.”

That is a good technique because it gives the interviewer an option with regards to which
approach they prefer and they can guide you.

Let’s assume the interviewer said, “It’s okay. Ask your clarifying questions.”

You can go ahead. Ask no more than four. If you come up with additional questions during this
discussion you can say, “I asked the four but two more came up based on the conversation we
had.” Most of the time the interviewer will allow you to ask it. But don’t go into 7, 8 or 10
questions. Don’t try to solve the case. That is for later. You want to merely understand what you
have been given.

The clarifying questions are not there to solve the case. They are used to identify the key
question.

Then you would take the information from the clarifying questions and you rephrase the initial
problem statement to say, “Okay, I’m going to paraphrase what you’ve given to me. We need to
figure out how can a French restaurant located in downtown New York move from $1,000-$2,000
of profits to $10,000 of profits without altering its menu and without changing the cuisine it offers”.

Assume that not altering its menu and the cuisine it offers are the answers to the two of the
clarifying questions. So you have to build in the information you received from asking clarifying
questions.

Please do not present the key question without using the answers from your clarifying questions.
If you did that, what would be the point of even asking the clarifying questions? They would be
wasted since you are not using them to narrow down the problem statement.

Narrowing down the problem statement makes the case really easy to solve. Most candidates
struggle in a case since they do not understand the problem statement.
step may not be needed. BCG tends to have broader questions and this step may be needed. In
general, if the problem statement is vague, you want to narrow it down.

Next you could say, “What drives profitability? Well clearly it will be revenue and cost. And what
are the drivers of revenue and cost? The drivers of revenue are different revenue streams. So its
food, alcoholic beverages and non-alcoholic beverages. It will also be the time of the day that the
restaurant is open. The drivers of cost will be fixed and variable cost.”

What many candidates would do is they would simply ask the clarifying questions up front and
throw out hypotheses. Don’t do that. Your hypotheses would be too vague at this point.

Develop your key question. Develop your decision tree to the second level of branches.

The first level of branches would be revenue minus cost. The second level of branches would be
the drivers of revenue and the drivers of cost.

Once you have the drivers of revenue and the drivers of cost, you can develop a hypothesis for
each prioritized branch that you think is important to solve the case. Not all the branches will be
important. Use your judgement and information provided in the case to prioritize the branches.

So develop a hypothesis for the food revenue stream, the nonalcoholic beverage revenue
stream, the alcoholic beverage revenue stream, and the hours when the restaurant is open. Then
develop hypotheses for fixed cost and for variable cost. That is assuming you wanted to prioritize
them all. You could just as easily have prioritized fewer branches.

Lets go through some hypotheses. I would say, “Since the restaurant is open longer hours, they
may have alienated some clientele, attracted new clientele and also incurred higher cost, which
is not compensated by higher revenue. That is one hypothesis.

This steep drop in revenue is probably driven by the fact that there is a different clientele coming
in which is demanding different prices.”

On the alcoholic beverage side I would come up with a similar hypothesis, and on the fixed as
well as variable cost side.

“Let’s look at the variable cost side. I would hypothesize that it is possible that although variable
cost have decreased due to the drop in revenue it have not decreased sufficiently to compensate
for the drop in revenue.

On the fixed cost side I would hypothesize that due to the longer operating hours our fixed cost
may have increased to carry the longer operating hours.”

Notice how specific hypotheses for the sub-drivers are. They are more useful than throwing out
drivers for revenue.

Your hypotheses need not have all three parts as in the image above, but they MUST be tightly
linked to the issue in that one branch. This prevents overlap with other branches.

The point I am trying to make here is that if you build your hypotheses off the branches of the
decision tree you maximize your chances to build useful hypotheses because you will have to
make sure that your decision tree is mutually exclusive and collectively exhaustive.

So if you build your hypotheses off your decision tree, and if you did a thorough job, your
hypotheses by default would be collectively exhaustive. And if your decision tree is mutually
exclusive your hypotheses would also be mutually exclusive.
case and the clarifying information you have collected when you asked clarifying questions up
front.

This is an effective and simple technique to build hypotheses in a mutually exclusive and
collectively exhaustive way. If you just throw hypotheses out without deriving them from a
decision tree you will have no way of knowing whether they made sense and whether they are
MECE.

Our clients are trained to do all of this in 60 – 120 seconds flat. That is pretty fast and will only
work if you understand the process. This video teaches this entire process above in great detail
for generalist interviews.

This additional video is for experienced hires where you can use the same approach to
demonstrate how you could structure teams to run studies. This is necessary to show the firm
you can hit the ground running and add immediate value. Those interviewing for Deloitte S&O,
Roland Berger, McKinsey Implementation, etc. are strongly advised to watch this second video.

HOW TO APPLY HYPOTHESES WITH THE DECISION TREE

TECHNIQUE AT MBB
When you get to a McKinsey interview you follow the process above, but you need not show the
interviewer the entire process. That is key. With the McKinsey interviewer or Bain interviewer you
don’t tell them what your key question is because for McKinsey and Bain the key question in the
case is very obvious. The clarifying questions are largely redundant because they tend to give
you the key question very clearly up front. So there is no reason to narrow it or rephrase it.

The case is not conceptually difficult as, for example, a BCG case.

Therefore, for McKinsey and Bain you build out your decision tree as we thought you above. Yet,
you don’t discuss your key question, your clarifying questions and your decision tree. What you
do is you build your key question and your decision tree purely to help you develop a framework
and then based on prioritized branches of your decision tree you develop hypotheses.

Therefore, just explain your hypotheses and very briefly how you created them.

To recap, in McKinsey and Bain interviews they are not going to see your key question. They
may want to see your approach. But what you really want to show them is your hypotheses.

QUESTION(S) OF THE DAY: Which part of the hypotheses with decision tree technique do you
find most challenging? Please share in the comments.

SPREAD THE WORD! Like this? Please share it.

Also, remember to visit our iTunes account to rate us and post comments on what more you
would like to see.

COME HANG OUT WITH US: Facebook / Twitter / LinkedIn

Image from Alan Turkus under cc, cropped, text added.

RELATED ARTICLES:

10 Case Interview Tips

Case Interview Plan
Applying to McKinsey
Comments
4 responses to How to Build MECE Hypotheses Using a Decision Tree

Michael Boricki said on December 8, 2015

Hello Adriana!

I think some things may give you comfort here. Nothing in business is truly
MECE. Sure, we say it is, but it is not. So, it needs to be reasonably
acceptable or not flagrantly unacceptable.

In fact the McKinsey guide-book specifically asks for the “broad buckets”
you will analyze. We teach you to build very specific drivers since that
makes you far better at cases, but the interviewer will not penalize you if you
do not!

So provided it is reasonable and you are not double counting, you will be
fine. The double-counting part is much more important than where the driver
will go. Also, getting the main question right is also important.

When it comes to creating good drivers, it really is a question of being well

read. The more you read the more creative you will be. No matter how
logical you are, you need to apply the logic to some content so you need
you increase the amount of content to which you can apply the logic!

So read a lot. I hope that helps.

Michael

Adrianna H said on December 7, 2015

Hi Michael,

For me there are two reasons why applying this technique is challenging.
These reasons are in reference to cases that are not simply profitability
problems (where the two largest branches are revenues and costs).

1. I find it difficult to truly make my branches mutually exclusive. For

example, in the first level of the issue tree, one branch may be “competitors”
and another branch may be “product”. Then, in the next level of this issue
tree, you may want to include the driver of “product differentiation from
competitors”. At this point, I am not sure which branch to fit this next driver
on. In other words, I start overthinking the drivers in my head and I start to
convince myself that few of the drivers are one hundred percent mutually
exclusive.

2. I find it difficult to create insightful and useful drivers in the first level of my
issue tree within 30 seconds. Sometimes, the only thing that comes to my
head under that time pressure is some framework that I can previously
recall, rather than “buckets” that are tailored to the case and unique enough
to set me apart from other candidates. For example, if nothing better comes
to my head I often merely jump to the Competitors Customers Company