Often whilst performing a case, my solution lacks structure and I often go back and in random directions without any structure. Also I am unable to apply MECE structure in my cases. What should I do?
How to structure my case properly and use MECE structure?
Hi there,
This is literally what you're case prepping for!
It is the hardest thing in casing and why people prep for months.
It's also why consulting firms get paid millions of $ and why they invest a ton of time/effort/money in training their teams!
Hire a Coach.
Seriously. It is extremely rare that I meet someone that actually figures out frameworking on their own.
=============================================
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 there,
It's difficult to give you advice knowing so little about you, but usually, candidates struggle with the following regarding structuring:
They don't know what good looks like
OR
They don't know how to make a good structure happen
The first one is the easier one to learn. Try to work through quality cases either here on the platform or from consulting books. Consider working with a coach to do targeted exercises on this - this is actually one of the targeted sessions I usually run with candidates.
With time, you'll get the hang of it, but it's indeed impossible to learn structuring without discovering through trial and error, and under the right guidance, what ‘good’ structuring feels like.
You can learn more about structuring also from the following guide that I designed with this in mind:
Best,
Cristian
This is because you are most likely thinking about all of the things that you have to analyze ("buckets" or as I prefer to call them: “areas of investigation”), whereas this is not how you should approach a case.
Put yourself in the shoes of an investor or other relevant decision maker: HOW WOULD YOU DECIDE ON THIS? HOW DOES A GOOD DECISION LOOK LIKE?
A good decision does not sound like “I want to look at customers, competitions, products and company”.
It sounds like:
- I want a market that is growing
- I want a product that is well suited for a relevant market segment (and for that I will need to understand my product, my competitors' offers, what are relevant customer segments, and what customers are looking for)
- I want a good distribution channel
- I want to good brand
- I want to be able to manage operations with an adequate margin.
Now I've listed a lot of generic stuff, because I am not solving a real case. This could apply to a real case, but will not apply to the other 98%. Everything has something unique about it. Let me give a different example. Let's say I want to make a new product:
- Is there a market (demand) for that product?
- Is there room for a new offer? If the space is occupied, can I be the winning value proposition?
- Are my current brand and distribution channels appropriate?
- Does it make financial sense (what margins - price vs. cost, what investments do I need to do?; or if you prefer: how does the price are production cost compare with my current offering)
- Will I face relevant cannibalization? Will it impact my brand or current offering in any way (manufacturing, distribution, etc.)?
- How will competition react?
Of course, I am writing this in a “non-organized way”. To be clearly MECE it needs to be better structured:
- Can I win in the market? (1) (2) (3)
- (If I can win in the market) Does it make financial sense by itself? (4)
- (if it does…) Does it have a positive or negative impact in the existing business? (5) (6)
Hope this is is useful example!!!
Hi there,
would be helpful to know a bit more about how you tackle it and where the exact pain points are. Might be worthwhile for you to get a diagnostic of your current approach, then you can get more specific advice.
Feel free to reach out via DM to me or the other coaches, if you'd like to learn more.
Regards, Andi