expert
Expert with best answer

Sidi

100% Recommendation Rate

311 Meetings

1,789 Q&A Upvotes

USD 319 / Coaching

How about starting the case structuring with key questions before structuring the key buckets areas to look at?

Anonymous A asked on Aug 12, 2019 - 2 answers

Hello all,

So, recently I realised that I like to always first write the key questions in my case structure and then divide the structure into the key buckets in order to first give a very high-level picture of what we are trying to achieve. I wanted to know your reactions to this kind of approach.

Eg: Let's say we have to see why a newly launched product has failed to deliver the expected sales and recommend what can be done about it. So, this is how I would go about the structure:

1. What are we selling? - Company - Product/ Price - Revenues- Distribution (related deep-dive questions)

2. How does it fit with the market? - Market attractiveness, Customers, Competition (related deep-dive questions while drawing a comparison)

>>> Deriving a conclusion on the basis of fit mis-match!

3. How can we improve sales? - Comparison of operational capabilities with that of competitors/ market/ customer expectations and solution building

4. Conclusion/ Recommendation

Any suggestions are more than welcome!

Thank you.

2 answers

  • Upvotes
  • Date ascending
  • Date descending
Best Answer
Sidi
Expert
updated his answer on Aug 12, 2019
McKinsey Engagement Manager & BCG Consultant | Interviewer at McK & BCG for 7 years | Coached 100+ candidates secure MBB offers
Book a coaching with Sidi

100% Recommendation Rate

311 Meetings

1,789 Q&A Upvotes

USD 319 / Coaching

Hi,

I believe you have a problem in your thinking. It starts with understanding the purpose of a structure: structuring a case does NOT mean to tell the interviewer what you're going to look at! This is not a structure - it's just a bucket list... and a pretty random one most of the time!

Structuring a case means to explain to the interviewer the LOGIC according to which you will answer the question at hand. "Areas to look at" are just a byproduct of this logic.

So one of the worst things you can do is to start with defining qualitative "buckets" to look at (e.g., "I'm going to start with looking at the market, then I want to understand the customers etc."). This is nothing but unspecific and completely random, with no rigorous logic from which your areas are derived. It is, essentially, the opposite of how you should work as a strategy consultant. Defining buckets and then hoping to find something interesting in there is pure explorative working - another word for this is GUESSING.

One of the fundamental things that you need to learn in order to rigorously disaggregate the value drivers of a business and, hence, business-related questions, is how to set up rigorous driver trees. The driver tree allows you to identify the numerical drivers and sub-drivers of your focus metric (e.g., profits or sales). The qualitative elements (such as consumer demand, market structure, company operations, etc.) then have to be mapped to the sub-branches of the tree!

Hence, your analysis has two steps. Imagine you want to run a diagnostic on why profits have fallen. First you need to identify the numerical driver of the problem (e.g., customer base is shrinking). This gives you an understanding of the WHAT. The second step is the understanding of the WHY! To do this, you have to examine the qualitative elements that link to the "number of customers"-sub-branch in your driver tree (e.g., competitive situation, market entries, new substitutes, relative price point, customer preferences, product/service properties vs. competition, etc.)

You can think of these qualitative elements as the typical business situation framework elements (see V. Cheng et al.) - but here, they are not hanging in the air, but they are embedded in a rigorous thinking frame which emerges from the disaggregation of value drivers and linking it to qualitative reasons.

Cheers, Sidi

(edited)

That‘s awesome, personally I share absolutely the same opinion! How do several candidates get into MBB with such approaches though (like „first I‘m gonna look at a, then at b etc“)? (Personally I know a classmate who passed McK 1st round this way, and even got a few prep sessions from actual McK consultants...) Is the logic you explain indeed what all interviewers are looking for (and with other mindsets there is no chance to pass the interview)? — Anonymous B on Aug 12, 2019 (edited)

Mit tip: stop asking yourself what an interviewer might be looking for! What he/she IS definitely looking for is the rigor in your thinking. And this is demonstrated by setting up a clear criterion-based logic to answer the precise question at hand, and not by defining whatever buckets. People have been brainwashed into this thinking since the canonical casebooks packed with frameworks were published 10 or 15 years ago. But it's a very flawed (and very junior) way of thinking and places the candidate at an enormous risk, since you will always need luck to solve a case, let alone perform well during the process. — Sidi on Aug 12, 2019 (edited)

Vlad replied on Aug 12, 2019
McKinsey / Accenture / Got all BIG3 offers / More than 300 real MBB cases / Harvard Business School
Book a coaching with Vlad

98% Recommendation Rate

350 Meetings

4,995 Q&A Upvotes

USD 319 / Coaching

Hi,

I would love to see the specific types of analysis in your structure, otherwise, the structure is too broad. E.g. instead of just looking at the competitors, I need to see it one level deeper and I would love to understand their size, growth rates, unit economics, key capabilities, etc

Best

Related BootCamp article(s)

Focusing on The Core: Mock Interviews

It is to practice as many cases as possible - both as interviewee and as interviewee. Here are a couple of guidelines to help you get started

Case Studies

The case study is the most important element of the case interview, which you'll have to nail in order to get into strategic consulting. Here you can learn the specific skills and concepts necessary to solve them.