Hi there,

Framework Overview

If there's anything to remember in this process, it's 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.

Objective-Driven Frameworks

Your framework is your structure for approaching the problem. It consits of a few main areas you'd like to look at. Inherent in your framework is a view that "If I answer A, B, and C, then we have an answer"

So, for market entry:

1) If the market is big, and it's growing, then we still want to considering entering

2) If #1 = yes, then let's see if it's attractive...can we win there? Is our product good/better than our competition's? Etc. If yes, let's definitely consider entering.

3) If #1 and #2 = yes, then, when we do enter, are we sure we can win? I.e. do we have the right plans. Will implementation actually pan out? Do we have the expertise, capital, etc.? In other words, if #2 is the thearectical, #3 is the reality.

Then, your summary becomes "I believe we should enter the market, if we can prove it's a good market, the it's attractive to us specifically, and that we will win it".

^Now this is a hypothesis/structure :)

Read these 2 Q&As for some great context + discussion:

https://www.preplounge.com/en/consulting-forum/interviewer-led-case-interview-hyposthesis-and-ideas-7390

https://www.preplounge.com/en/consulting-forum/forming-a-hypothesis-case-in-point-vs-victor-cheng-7311

Hope this helps! This is a tricky topic that's difficult to properly answer in writting...if you want a more thorough explanation, and training in the mindset shift required here, don't hesitate

Hi there,

Some good answers already so let me complement with an important distinction between frameworks, namely those organizing “areas of analyses” and other organizing “specific ideas”. Candidates very often get this super wrong!

• Areas of analyses: If there's an overall objective in the case prompt, and you have not much background information yet, your structure serves as a guide that organizes area of analyses. This means a list of things you'd like to explore in the next 30 min in order to better understand the problem and subsequently devise a solution. You need to be pragmatic and have a hypothesis as to what the top areas to look into should be, because you can't “boil the ocean” and analyze everything in 30 min. In this case, your structure is the roadmap for the interview and every end-point of your MECE structure is an area you'd like to investigate going forward.
• Specific ideas: Alternatively, you may be asked for a structure to provide some ideas. At McKinsey for example, the first question is often a version of “What do you think are some of the factors affecting [something specific relating to the prompt]. In this case, you shouldn't create a framework to organize areas you'd like to explore. Instead, you should give very specific examples of whatever was asked e.g. factors, ideas, reasons, etc. For example, if profit is down in an airline, don't just create a revenue bucket and say you want to look at price and number of tickets sold. Those are not ideas! Those are areas of analyses! A much better answer would include a long list of detailed reasons as to why either revenue was too low or costs too high. In this case, every end-point of your MECE issue tree is an idea, which is ultimately a mini-hypothesis at the most granular level.

Hope this helps a bit! Best of luck!

Dear candidate,

try this:

a) structure conceptually by the actual underlying drivers (your potential answers)

b) structure by business process

c) structure by business segment

d) structure algebraically

These are easy ways to come up with structures only the first one is tricky, and if you stall in an interview try any of these to get you going. best regards

The simplest way to structure things is to think backward from the end.

Start from what you want to achieve, then identify obstacles between you and what you want to achieve.

List the obstacles, and then ensure this list is MECE and “answer first”.

If you want to know more, just schedule a session with me.