I have been learning the fundamentals and nuances in terms of the case interviews. Having started working on several cases just by myself, I found myself not able to have the structure or framework similar to the answer. Sometimes, especially for a broad public sector or market entry case, I tend to think a little narrow at structuring the key categories, while for other cases such as profitability or M&A, I could be better just focusing on a few categories I listed such as price and cost without spending much time or even mentioning the other drivers. Usually, based on my frameworks, people can relate to the answers but might either not be specific or comprehensive enough. My question is, should I get better by recognizing the type of case I am likely solving AND recognize that some types of case can and need to expand more than others?
How to balance the breath and magnitude of case structuring
Hi there,
there are many important points/misconceptions to address here.
- Practicing cases by yourself has zero benefits. Without expert guidance and feedback, you're essentially navigating in the dark. Similarly, seeking feedback from non-professionals won't provide the insightful critique necessary for improvement.
- Relying on solutions from casebooks is a dead-end strategy. Answers from casebooks are absolutely flawed and should not be used to evaluate your performance or guide your approach.
- The categorization into “Profitability Cases”, “Market Entry Cases” etc. is complete nonsense and mirrors the lack of understanding of most established casebook authors.
If you want to come up with a specific approach or "framework" for each of these types (or even more), then I believe you have a big problem, since this would show that you have not yet understood how to think about business issues. I know that this is how,. e.g., Cosentino is approaching cases in his book "Case in Point", but frankly, this book is a prime example of how a strategy consultant would and should NEVER work!
Essentially, instead of trying to map frameworks to case types, you have to understand the internal principles that underlie strategic issues (there are very few of them!), and then apply them to the situation at hand.
For example, it doesn't make any sense to have different "frameworks" for M&A cases, Market Entry Cases, Product Launch Cases, Capacity Expansion cases, etc.. All these situations share the same core issue and the LOGIC according to which they need to be solved is 100% identical! Without understanding this, a candidate will never ever be able to rigorously approach cases and always remain a "framework monkey" who has to rely on luck and gets confused as soon as some unforeseen notions appear in the case which don't fit the framework.
This is the big tragedy with the available case literature (which I have seen) - it teaches a fundamentally flawed way of thinking (or lack thereof).
Cheers, Sidi
_______________________
Dr. Sidi Koné
Former Senior Engagement Manager & Interviewer at McKinsey | Former Senior Consultant at BCG | Co-Founder of The MBB Offer Machine™
Hi there,
You are approaching this from the wrong end.
It's not about recognizing what type of case you are dealing with (this is a very Case in Point which has not been relevant since at least 15 years in consulting recruiting) but to understand
a. what problem you are trying to solve
b. what information is needed for you to understand the problem
Based on this, you need to create a framework that is
- broad (covers the problem fully without boiling the ocean)
- deep (analyzes the necessary drivers)
- insightful (relevant and tailored)
Please note that cases have become so granular and specific, that building your framework around "specific case types" is losing battle.
All the best,
Florian
‘I found myself not able to have the structure or framework similar to the answer’ >>> you shouldn't even aspire to do that.
Often times the sample answer in case books was written by an MBA student who is also struggling to get into consulting.
At best, you should see it as a potential answer and try to figure out what you can take from it to make your own better.
The skill that you need to develop for a distinctive performance in the structuring part of the interview is thinking from first principles.
I explain at the link below more about but do feel free to reach out if you have questions:
Best,
Cristian
I fully agree with Florian on the better way to approach cases!
However, if you still continue to solve cases by yourself and are tempted to analyze the differences in the frameworks, I would recommend you to focus on trying to understand why those elements were chosen in the answer.
Are they really the most important ones?
Are they MECE?
Then you can re-evaluate if you still like your answer better or the one provided in the case study. Your answer could really be the better one!
But at least in this way, you train your muscle for critical thinking and figuring out what is the right level of depth to go into the framing.
Good luck,
Ariadna
Here we go again… Sorry, it is clear you are doing the #1 mistake in case practice. Trying to memorize frameworks and thinking of one-size-fits all approaches. This leads to disaster.
You always have to start with a well defined case objective, a build a specific approach that will allow you to solve the case.
Sure, the stuff you have in your buckets or frameworks may be helpful in terms of content, but it is not useful as a problem solving approach.
Always start with the case objective. Ignore “case types”, as this is quite misleading and similar “case types” may require completely different approaches - these will depend on the specific goal, specific industry and specific context.
It will get better by practice - 100%.
You are already much self-aware of the improvements required - so keep going at it.
But remember, the case solutions may not always be the best, or always be correct. If your framework makes sense and helps solve the case question - then it is an alright framework.
Happy to discuss more details of your structuring experiences - let me know.
Expert case by
