Does your structure/issue true needs to have sub-branches and each sub-branch needs to have a hypothesis?
Also, how do you build such an extensive tree in like ~2 mins?
Hi there,
great questions - effective structuring of a case is one of the single-most crucial skills needed to master case interviews, hence thanks for sharing!
1. Does your structure need to have sub / branches and each sub-branch needs a hypothesis?
Simple answer is, the level of granularity / detail of the structure you will require is really dependent on the question / problem at hand.
A structure / tree does nothing but provide the (dynamic) frame for you to break down & investigate that question / problem. Depending on the complexity of the latter, you may sometimes need more (4+), sometimes less layers (2-3) and hypotheses to tackle - whatever is the minimum sufficient granularity to identify the root cause & develop a solution / conduct a sizing. There really is no standard answer.
2. How to you build such an extensive tree in 2min?
Simple answer - this is not the expectation. You don't have to develop the fully-fledged tree during initial structuring. Rather, you can do this step by step, meaning it's sufficient to draw the initial 2-3 layers to align on on direction and get buy-in from the interviewer - that's enough to get started and you can then (and always should!) gradually refine & detail out the structure / frame as you progress the case and more info / clues become available.
Especially in situations when you have no initial view on the details / lack the information to form that view upfront, it's a very good approach to avoid rabbit holes and stay on track throughout the case. Develop, refine & update the structure. progressively.
Hope this helps - feel free to reach out via PM if you'd like to learn more about how to most effectively structure problems & how to apply hypothesis-driven approach to crack any case. Happy to help, and I'm sure other coaches will be too - this is our bread and butter.
Regards, Andi
Hey there,
Yes, you should include sub-branches. There is a difference though if you are working on a McKinsey structure or a candidate-led structure, which is often misunderstood.
Since others have focused on candidate-led cases, let me brief you on structures relevant to McKinsey.
At the core, McKinsey wants to see creative ideas communicated in a structured manner, the more exhaustive and concrete the better.
Your goal should be to come up with a tailored and creative answer that fits the question. The framework should - broadly speaking - follow these three characteristics:
You really need to list all the ideas you have here (exhaustiveness!) and can actually take up to 6-8 minutes to present your structure, your qualification, and your hypotheses. This is due to the interviewer-led format that McK employs. The interviewer might interrupt and will only ask 'what else' if you
The firm wants to see exhaustive and creative approaches to specific problems, which more often than not do not fit into the classic case interview frameworks that were en vogue 10 years ago...
Again, this only applies if everything you say
The difference in format and way of answering a question is the reason why I recommend preparing very differently for McK interviews vs. other consultancies.
Cheers,
Florian
Hi there,
Remember that a framework and an issue true are 2 separate things.
Generally for cases you don't need a fully fleshed out issue tree (there just isn't enough time to make one!). Rather, you need a framework with sub-buckets.
Some case reading can be found here: https://www.preplounge.com/en/articles/how-to-shift-your-mindset-to-ace-the-case
How to Framework
If there's anything to remember in this process, is that cases don't exist just because. They have come about because of a real need to simulate the world you will be in when you are hopefully hired. As such, remember that they are a simplified version of what we do, and they test you in those areas.
As such, remember that a framework is a guide, not a mandate. In the real-world, we do not go into a client and say "right, we have a framework that says we need to look at x, y, and z and that's exactly what we're going to do". Rather, we come in with a view, a hypothesis, a plan of attack. The moment this view is created, it's wrong! Same with your framework. The point is that it gives us and you a starting point. We can say "right, part 1 of framework is around this. Let's dig around and see if it helps us get to the answer". If it does, great, we go further (but specific elements of it will certainly be wrong). If it doesn't, we move on.
So, in summary, learn your frameworks, use the ones you like, add/remove to them if the specific case calls for it, and always be prepared to be wrong. Focus rather on having a view, refering back to the initial view to see what is still there and where you need to dive into next to solve the problem.
Hi there,
If you’re building an issue tree, I’m assuming you’re doing so to answer a specific question, such as “What are some of the factors that could contribute to x” or “What are some ideas you can think of for y”. This is very typical of McKinsey case opening questions.
In this situation, your structure is not a blueprint for later analysis (like the opening framework in a typical interviewee led case) but rather a well organized list of very concrete ideas.
Every idea is ultimately a hypothesis because you don’t know. It’s just important to not be generic or too high level here. Being concrete and creative is important!
As for the structure that contains your ideas/issues, it should of course be MECE at every level and this means typically somewhere like 2-4 buckets, maybe 2-3 sub buckets each, and then very concrete ideas at the end. However, numbers are just indicative and there’s no rules, except being MECE!
Just be aware that the structure is important but the ideas at the end of the structure is what really matters, which most candidates get wrong.
Hope this helps a bit. Best of luck!
Expert case by
