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.

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.

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.

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  

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