how to build hypotheses

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 answer being the hypothesis.

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.

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.

We get a lot of questions from our audience about how to use this technique well and how to adopt it for case interviews with firms so this post should provide some clarification.

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.

hypotheses firmsconsulting strategy consulting 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.

brainstorming decision tree

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 if the decision tree is not generating an answer quickly.

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:

hypotheses example

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.

hypotheses firmsconsulting strategy

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.

It must be noted that Bain and McKinsey tend to have very clear problem statements and this 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.

And obviously your hypotheses are dependent upon the information they have given you in the 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

Free Case Interview Material

Receive a free chapter of Bill Matassoni's Memoir and exclusive preview access to FC Insider case interview and strategy video /audio training programs. This is the ONLY way to sample Insider material.

Where else can you learn from ex-partners?

Sign up to receive preview FC Insider videos and podcasts. Start now:



Privacy Policy

Comments

4 responses to How to Build MECE Hypotheses Using a Decision Tree

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

  2. 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, and Product framework (or the “Business Situation” framework).

    Thank you in advance for your thoughts and time. All of your material on the Firmsconsulting site is truly outstanding.

    Adriana

  3. Thanks Anna.

    I think this will be the main problem most readers will find. The technique takes some time to master and therefore there is a tendency to just revert to random insights.

    Michael

  4. Michael,

    I would say the hardest thing for me in applying this technique is to stick to it during an interview and go through it in order in which you teach us to go through it. The technique is solid. It works. It impresses interviewers but it is so easy to just get off the drill, and start following my natural inclination to jump from one piece of the case to another to get to the solution.

    Yet I noticed, when I did follow this technique, interviewers without exception are impressed. I just have to fight my natural inclination to start solving the case “my way”, in an unstructured way, which usually gets me to the right answer but takes longer and is not what interviewers are looking for. They are looking for structured, logical thinkers. And this technique helps to come across as a structured, logical thinker.

    Thanks.

    Anna

Leave a reply

You must be logged in to post a comment.