How to make case structure "MECE"?

Question

Hi experts, would like to seek your advice on the “MECE” of a case structure. I'm unclear how strictly “MECE” should the structure be. Should the first bucket be perfectly parallel? Is it suitable to say that, as long as the structure covers critical elements to look into, then it is “MECE” enough?

There are two ways to form a structure. One is to use “nouns” as the first buckets, while the other one is to state the first buckets as “key questions”. Can you provide a suggestion on whether the 2 structure stated below is “MECE”?

In a case that I've done, I am analyzing whether we should implement an initiative to turn around the loss-making business. The initiative, though sacrificing each individual's customer experience, will provide the company with additional revenue sources from earning advertising revenue.

(1) First approach: customer, company, financial

Obviously, financial is not the same “category” as customer and company, and the structure doesn't seem MECE. However, placing financial assessment within the “company” will be too packed. Any better way to optimize the structure?

(2) Second approach:

1. Are the customers acceptable to this growth initiative? (e.g. key is to prove that the initiative will not cause a magnificent customer attrition as customer experience will drop due to this initiative)

2. How can the company mitigate negative impact and grow revenue? (e.g. brainstorm new revenue sources and risk mitigation approaches)

3. Can this growth initiative turn around the loss-making business? (e.g. with the information collected in the first two buckets, we can now run through the math to see whether the initiative makes sense or not financially)

Thank you!

Answer 1

First:

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.

I'm unclear how strictly “MECE” should the structure be. Should the first bucket be perfectly parallel?

Yes

Is it suitable to say that, as long as the structure covers critical elements to look into, then it is “MECE” enough?

No

There are two ways to form a structure. One is to use “nouns” as the first buckets, while the other one is to state the first buckets as “key questions”.

Neither of these are correct - you have a fundamental misunderstanding of frameworking.

Question on your 2 structures

Neither is correct. Financial is not MECE (as you've flagged!). That implies customer and company have nothing to do with financial implications

For your second approach, this is better, but it's still not MECE and hollistic. You cannot just ask about customer/company in the way you have. There's more to it! Your 3rd point is literally the entire question being asked….it's not a bucket that's allowed

=======================================

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 2

Hello,

I fully agree with Ian’s feedback! There’s a lot to learning frameworks that’s hard to communicate effectively in a Q&A forum. My additional two cents is that it seems to me like your two approaches are somewhat similar in that the #1 and #2 buckets of approach 2 are basically the ‘customer’ and ‘company’ buckets of approach 1. So the approaches you outline are not really that different – the distinction is more about how you frame the buckets (with a noun or with a question), but the content and sub-bullets are the same. You do need to have parallel buckets, and you do want to focus on being MECE.

Answer 3

Hi there!

Lots of great answers below.

Sharing with you an additional resource you might find useful:

Free Guide: Mastering Structuring & Brainstorming

You'll find in there several structuring techniques that you could apply and which will bring more clarity to your situation.

Best,
Cristian

…………………………………………………………………………………………………………………………………………

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

Answer 4

Hi, here some tips and tricks as well as explanations of what the interviewer expects: 1. General Approach to Struc... (read entire answer)

Hi, here some tips and tricks as well as explanations of what the interviewer expects: 1. General Approach to Structuring a Problem Instead of relying on rigid structures, I e... (read entire answer)