MECE depending on the point of view

Question

Hi everyone.

Could you please give clearance on how a point of view can make the framework MECE/not MECE?

When talking about MECE framework structuring, I see the point in the definition (and I am aware it is not always possible to make it MECE), but I do not always understand if it is just not possible to make it MECE, or if I have to improve my skills.

Example (I won't go too deep to keep it brief):

Let's say I have to analyze a process of production. I can:

Set a framework on “steps”
Set a framework on “topics”

Starting with “steps”, 3 steps: input > transformation > output.

For both input and output I could list different points, but in common they would have, for example:

Transportation
- timing
- costs (in & out)
- risks (e.g. refrigeration)

And this would make the structure MECE from the steps side, but not MECE for the topics side, as I am repeating the transportation.

I would then try the “topics” framework, so I can at least have the transformation as an independent bucket. If I structure the case instead looking at different topics (e.g. resources, capabilities, transportation, packaging), I would find under resources (e.g. quality controls) and transportation the sub buckets:

To the facility (so input)
Out of the facility (so output)

So in the “steps” framework, transportation is not MECE as listed in 2 steps, and in the “topics” framework, transportation is not MECE as both input and output, would be listed in resources as well.

This is the most frequent reason why I may go over time and forget to focus on tailoring to the case, while giving more importance to the MECE exercise.

Answer 1

Hi there,

First of all, it's ALWAYS possible to make a structure perfectly MECE but shouldn’t always be your goal. In fact, most people apply MECE in the wrong way.

The concept was famously invented by a McKinsey consultant and I used to live and breathe this during my time at the firm. As for McKinsey interviews, it's fundamental to case openings, which I will lay out below. If you're using MECE in the context of interviewing with other firms, I actually wouldn't generally recommend it but that's a bit of a longer discussion…

WHAT MCKINSEY DOESN'T WANT: McKinsey doesn't want you to solve the case! Correspondingly, their case openings are not about an actionable framework that leads you down an analytical path of exploration and discovery to solve the case.

WHAT MCKINSEY DOES WANT: McKinsey wants you to answer questions about a case, which is different from solving a case. Firm interviewers will ALWAYS ask you a question after the prompt, which is generally a version of “What do you think are the important things to consider in situation XYZ?". In this case, you're NOT being asked to solve the case but to hypothesize as to what the answer to the question could be. You are asked to come up with ideas that are well formulated thoughts as to what may drive a certain situation and those thoughts have to fall within MECE categories. However, you have to internalize first the principle of answering the question and not wanting to solve the case. Once that's done, MECE will be SO MUCH EASIER.

By the way, as a McKinsey interviewer, I was much more interested in people being able to formulate hypotheses and coming up with good ideas in response to my starting question. However, most people spent their energy on structures that were very nice and tidy but hollow and void of well formulated thoughts. If I had to choose between great ideas or a great structure, I would choose great ideas (with a bit of a messy structure) any day of the week!

I have a video on this particular topic with plenty of exercises and specialized sessions. Feel free to get in touch if interested.

Best of luck!
Moritz

_______________________________________________________
>> Need a specialized McKinsey coach & mentor?
See my full profile
>> Need real McKinsey cases?
Zero Carbon Mine (hard)
Car Convenience (Intermediate + brand new)

Answer 2

When it comes to making a framework MECE, it's important to consider both the steps and the topics you choose. In your example of analyzing a production process, you initially structured it based on steps: input, transformation, and output. While this may make the structure MECE from the steps side, it becomes not MECE from the topics side because transportation is repeated under both input and output.

To address this, you then attempted to structure the case based on different topics such as resources, capabilities, transportation, and packaging. However, you found that transportation still appeared in both the input and output sections, making it not MECE in this framework as well.

In situations like this, it's important to recognize that achieving complete MECE-ness in every aspect of the framework may not always be possible. It's a balancing act between ensuring a logical and comprehensive structure while also tailoring it to the specific case at hand.

Improving your skills in structuring MECE frameworks comes with practice and experience. As you encounter different cases and gain more exposure to various industries and problem types, you'll develop a better sense of how to structure frameworks that are both MECE and tailored to the specific case.

Remember, the MECE principle is a guiding framework, but it's not a rigid rule. The ultimate goal is to have a structured approach that allows you to analyze the problem effectively and provide valuable insights to the client. So, don't get too caught up in achieving perfect MECE-ness in every aspect of the framework, but rather focus on delivering a well-structured and insightful analysis.

I hope this clarifies the role of a point of view in making a framework MECE and provides some guidance on improving your skills in structuring MECE frameworks. Keep practicing and refining your approach, and you'll continue to grow as a consultant.

Answer 3

Always making a structure perfectly MECE is possible, but not necessarily the goal. The concept, originating from a McKinsey consultant, is significant in McKinsey interviews, particularly in case openings. However, for interviews with other firms, it may not be the best approach.

McKinsey doesn't expect you to solve the case but to answer questions about it. Interviewers will often ask what factors are important in a given situation, and your response should consist of well-formulated thoughts falling within MECE categories. The key is to prioritize answering questions over solving the entire case.

As a McKinsey interviewer, I valued candidates who could formulate hypotheses and generate good ideas in response to my initial question. While some focused on creating tidy structures, I preferred candidates with messy structures but excellent ideas. In this context, great ideas trumped a perfect structure.

Answer 4

I do strongly recommend a coaching session to really take your structuring to the next level - it's very very hard to go from good to great in this category without help. This is especially true if you're trying to practice non-classic case questions.

Now, in terms of tips, #1 most important thing is to be objective-driven. Not hypothesis-driven, but objective driven. Remember that there are 2 objectives: 1) the objective of the case (what is the question I'm trying to solve) and 2) The objective of the client (what are their needs, wants, desires. What does "good" look like)

Furthermore, 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, you should absolutely be prepared to either enter a new piece of your framework or change your framework altogether as new information comes in. How do you handle this?

Well, first, you can really just articulate what you're doing. You can say "Oh, interesting, so if looks like we have some information on y. I don't want to forget about x, but let's see what y brings us first. Ok, looks like it's about..." Then, when you've "finished" with y, you can check to see if there's any info on x. If there isn't, move to z :)

Second, you can re-summarize/iterate where you are. This is especially useful if you have the change the entire framework. Say "Ok, so it looks like now we actually need to look a 3 key things to solve this"

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.

Answer 5

Hi!

You're asking a lot of great questions, but a forum post might not be the best format to get quality answers on them.

Sharing though a guide on structuring techniques that you might find helpful:

Expert Guide: Mastering Structuring & Brainstorming

Good luck!
Cristian

———————————————

Practicing for interviews? Check out my latest case based on a first-round MBB interview >>> CodeWave

Answer 6

Please do not overly obsess with MECE. As Moritz correctly pointed out, at McK the focus isn't on this clearly. Feel free to ping me for a free coffee chat so I can show you practically how to navigate this one. Best, Frederic

Answer 7

Hi there, and thanks for asking, Indeed, setting up the framework for a profitability case can be a bit confusing, ho... (read entire answer)

Hi there, and thanks for asking, Indeed, setting up the framework for a profitability case can be a bit confusing, however, I would advise you not to think of “THE” framework wh... (read entire answer)