Do you structure the case in buckets or in 'questions'?

First of all congrats on passing the first rounds on more than one MBB! I guess this doesn't happen by chance so I would suggest keeping on doing what you have done so far, including the way you structure your cases.

To be more precise in my opinion, it's always better to structure the case in buckets. How do you choose what buckets to use? By using the questions you mentioned.

For example, you can ask yourself "what are the drivers for X?" and then use the actual answer to this question (i.e. the drivers) as the framework to solve the case.

Hope it helps,

Franco

Generally speaking you should start with the problem statement.

That problem statement can break down into various categories (buckets). Now you can use questions in your head to arrive at what those buckets should be, e.g. Should the company enter the market depends on how much competition there is, what is the regulatory regime, what is the market size potential ->

- Competition

- Regulation

- Market size and growth

Neither is right or wrong where it does really vary by case. Generally speaking, framing as 'questions' does mean you are being more specific and tailored in your structuring which is a good thing!

In a cases, such as profitability, where the structuring is more standard then buckets make more sense. On the other hand, cases where you are answer an overarching question for the client, such as market entry, then framing as sub-questions means you are being much more specific with your structuring which is a good thing. Instead of just saying "the market", its more meaningful to say "Is it a growing market where we can sustain a meaningful market share?" where you would double-click on the "usual supsects".

I'm going to take a step back and answer the question you're really asking: How do I use frameworks in a case?

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.

Ways to not say "buckets"

• Segments
• Areas
• Main focuses
• Approaches
• Don't even use a specific word "So, first I'd like to look at x, then y, then z"

Think Process vs. Content. 

The questions help you to make sure your entire structure on paper covers the entire case and gives a step-by-step process to solve the case, talk about solutions, or implementation, however desired in terms of scope by the interviewer. This is where most candidates in my experience struggle already. Why? They think way to quickly and depend too much on CONTENT (which is of course important) but you can then use your array of perhaps 5-6 Qs or so to fill every question with a CONTENT framework , i.e. subject-driven buckets / trees / formulas etc.

Go Q first, once the entire case and required scope has been sufficiently and MECE solved, then go deep on content.

This is exactly what I train with my candidates here in PL - exhaustive structuring exercises focusing on the process first, then content. 

Best,
Denis

Hi, there are no golden rules applicable for every case.

Generally speaking I usually structure my frameworks in buckets, divide each bucket in bullets or questions

Best,
Antonello