Structuring Order

Hi,

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!

Second, you must understand what the purpose of a structure IS and what IS NOT. The purpose of a structure is NOT to simply list a number of buckets and qualitative bullet points you would like to look into. Instead, 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.

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:

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

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.

Cheers, Sidi

___________________

Dr. Sidi S. Koné

Former Senior Engagement Manager & Interviewer at McKinsey | Former Senior Consultant at BCG | Co-Founder of The MBB Offer Machine™

Hi there,

Q: During structuring, should I prioritize setting the main buckets first then filling them, or coming up with the hypothesis then/key issues then aggregate them into buckets ?  

I would recommend the following: 

1. Present the first level of the structure
2. After that, present the components/drivers for each first level. When needed, you can explain the reason why you are including them

When you start to analyze the drivers, if you don’t have data, you can state a hypothesis and then ask for data to verify it. 

Hope this helps,

Francesco

Hi there, 

Indeed, you do need to first communicate what the buckets are. You are also right that it is more intuitive to just share your thoughts … and this right there is exactly the reason why so many people struggle with top down communication: it simply does not came naturally for most. 

It is just something that takes practice to do, but is totally possible and then it becomes a habit! (you might even realize you get slightly annoyed when people around you don't communicate top-down enough)

Good luck, 

Ariadna 

Hi there,

First of all, I am sorry to hear about your issues with the initial structure!

I would be happy to share my thoughts on your question:

• First of all, while both of the approaches you mentioned are valid, it is rather rare that you can develop a meaningful hypothesis from the outset.
• Moreover, unless you are specifically asked for dimensions, please do not develop an initial structure in “buckets” (aside from the fact that the word is just awful).
• Lastly, given the rather fundamental issues you seem to have with the intial structure, I would highly advise you to consider working with an experienced coach on this. I developed the “Case Structuring Program” to help exactly such candidates like you who struggle with properly structuring any case study.

If you would like a more detailed discussion on how to best prepare for your upcoming interviews, please don't hesitate to contact me directly.

Best,

Hagen

There are really few to no cases that enable you to come up with a hypothesis from the get-go. 

In most cases, you will collect sufficient information to launch a hypothesis only mid-way through the case.

So in that sense, it makes sense to start the case with a structure that enables you to do this drilling towards this solution. 

You might also find this guide helpful:

Expert Guide: Mastering Structuring & Brainstorming

Best,
Cristian

Hi there,

Although it might not come naturally for you to think about structuring your thoughts first, this is the preferred way to do it. 

With enough practice, top-down communication will become second nature. I found it useful to push myself to do the high level structuring and zoom out in my mind first as the initial ideas came to get my brain used to the way consultants think when I was practicing for interviews.

Feel free to message me if you would like to practice!

Yousef

A structure is not a collection of random topic collated into buckets. 

A structure is always top down, always follows an issue tree. 

Maybe you shouldn't be using “buckets” and then filling them, but breaking down the problem into smaller problems.

I guess they whole issue is that you are trying to fill in generic buckets, instead of thinking about the 3-4 critical things that would lead you to a recommendation.

When making your framework - you can apply any technique that makes you do it fast and good.

While presenting/explaining/speaking the framework to the interviewer - it is always ideal to use the pyramid approach.