Hi Aviv, 

Let me clarify some points here. The purpose of a structure is to clearly explain the logic according to which you will arrive at a well substantiated answer to the client’s question. It serves as a roadmap for the case-solving process, delineating the specific analyses required by the underlying logic.

Drafting a logic / roadmap, does NOT mean SPECULATING on what the answer to our client could be, especially at the beginning of a case when you have very limited information on the situation. Your understanding of “hypothesis” is definitely off and it reveals a purely explorative mindset, which is the OPPOSITE of rigorous and hypothesis-driven thinking!

Claiming that the statement of a hypothesis is a requirement at the start of a case is fundamentally wrong. In fact, stating a hypothesis for the overall problem only makes sense if you really have something to ground your hypothesis on! This is very rarely the case, since case prompts tend to be quite vague at the beginning. Just stating a hypothesis for the sake of it serves no purpose! It would just be a shot from the hip - and this is something you should avoid at all cost during an MBB interview!

If the question is about finding the reasons for an observed phenomenon (e.g., fallen profits), then you can rather say “I would like to first identify the numerical driver of the problem, which can sit either on the revenue or on the cost side (or both). Based on this initial assessment, I would build a hypothesis on the underlying reasons for the detrimental development, then verify the hypothesis, and subsequently derive measures to address these reasons in order to reverse the trend.”

If the question is essentially a go- or no-go-decision (e.g., "Should we enter the Brazilian market?"), then a MUCH better approach than a blank "Yes/No"-Hypothesis (which feels stupid anyway, right?) is to define the criterion according to which the question can be answered. This implicitly comprises hypothesis-thinking, but in a much cleaner way. All you have to do is to:

1. Narrow down the question
2. Define the criterion according to which the question can be answered with "yes”
3. Outline how you can test whether the criterion is met

That's it! This is how you address strategic questions without shooting out unsubstantiated hypotheses (or rather wild guesses!), while still being super top-down and super efficient.

Hypotheses then are used all along the way of performing the actual analyses! But it is not hypotheses on the overall question, but hypotheses on the various sub-aspects which you need to test in order to eventually answer the overall question.

I hope this helps.

Cheers, Sidi

_______________________

Dr. Sidi Koné 

(🚀 Ex BCG & McKinsey Sr. Project Manager, now helping high potential individuals join the world's top Strategy Consulting firms (McKinsey | BCG | Bain))

I am personally a big fan on the hypothesis stating! 

Not before the structure, but at the same time with the structure. Something like “My hypothesis is XXX and here is the structure I would use to prove or disprove this hypothesis”. At that point in the case your hypothesis does not have to be even remotely correct, and that's fine. 

Now, I will be the first to admit that in some cases it feels very forced + in my experience as interviewer I did not automatically discount candidates that did not use a hypothesis, but otherwise had an excellent structure. 

But I did give (mental) points to any candidate that used a hypothesis. And from my informal chats with other interviewers it seemed they all very much appreciated it. 

So I would encourage you to push yourself when practicing (at least) to use a hypothesis as a way to stress-test your framework. 

Hope this helps, 

Ariadna 

Aviv, 

I have a very strong opinion on this.

There is lots of confusion around this topic, but when in doubt about how the interview goes, you should look at how the work of a consultant goes in practice.

You will never go to a client, listen to a 5-minute description of their problem, then say that your ‘hypothesis is X and now you’re going to either approve it or disprove it'. If you do that, they're likely going to show you the door. 

You should only come up with a hypothesis the moment you have evidence to support it. 

This sort of evidence you come up with in the course of the case. You almost never have this evidence based on the prompt given to you by the interviewer.

Think about it as a dining table. 

It's only a table if it stands on legs. 

The legs represent the evidence. 

You need to find more ‘legs’ i.e., arguments to support that hypothesis in order to even communicate it as an emerging hypothesis. 

If you have no legs, you have no table, thus you have no hypothesis. 

Best,
Cristian

Hi Aviv,

Q: I'm eager to hear your thoughts on the importance of stating your hypothesis after asking clarifying questions and before outlining your structure. 

I don’t see reasons to state a hypothesis before presenting the initial structure – it would be like a random guess at that stage.

Instead, I would recommend using hypotheses when there are:

1. Multiple drivers that could be responsible for an outcome (eg there was a decline in profits and this might be due to either revenues or costs)
2. Not enough data to identify the driver responsible for it (eg you don’t have the data on how revenues and costs changed)

Therefore, to start the case, you can first present a structure showing the drivers that you would like to analyze to answer the question. Then, when you don’t have enough data to identify the correct driver, present the hypothesis to make explicit which area you would like to prioritize, out of those you have defined in the structure.

Additionally, I would not recommend just stating a hypothesis but also explaining how you would like to verify it and asking for the relevant data. In this way, you can identify whether the hypothesis is correct right away.

As an example, let's say the interviewer asks where you want to start a cost analysis. Then you can:

1. Present a structure
2. State a hypothesis on the main area of analysis
3. Ask for data to verify the hypothesis

Bad example (no structure and the hypothesis is not verified with data):

“My hypothesis is that this could be a fixed cost problem, so I would like to start there.”

Good example (structure is present and the hypothesis is verified with data):

“Well, costs can be divided into fixed and variable costs. My hypothesis is that this could be a fixed cost problem; to verify this, I would like to know how fixed and variable costs changed. Do we have any information on that?”

Hope this helps,

Francesco

Hi there,

There is no good reason to do this so early in the case.

Rather, provide your initial structure, which covers all elements you want to analyze to understand the issue at hand/find an answer to the case question.

Then, prioritize and state what area you would want to analyze first, why, and how.

First broad, then focus. This way, you are implicitly showing your hypotheses as you point the interviewer to where you think the key areas are (also in a less awkward way).

Cheers,

Florian

Hi Aviv,

To iterate on what others have said: No need to state hypotheses before stating your structure. However, you can (and should) definitely tie your hypotheses into your structure. 

Best,

Oliver

Your issue on stating the hypothesis early-on - would be applicable only for diagnosis cases. In which case, I can say that it is NOT necessary to quote a possible hypothesis upfront. In fact your framework is the place that should be full of all the possible hypotheses for diagnosis.

For other cases such as brainstorming and decision-making - you would not be facing the issue of whether to state the hypothesis early-on or not.

Let me know if you have a specific case which challenged you - happy to give you bespoke solutions on your cases over a master-class.