Hi there,

Two main things that you could take into consideration

1) Always tailor your framework (even the basic Company, Competition etc.. a la Cheng mode) to make it seem specific to the problem statement and company at hand e.g. via

- Substituting/adding key cues for interviewers to the main buckets (e.g. "I will look at competitors e.g. in the medical devices segments in the core geo for company X , instead of saying just I will look at competition)

2) Adding the “why this bucket is relevant from a business point of you” immediately beyond your stating of the key buckets (e.g. I will look at prices for each of company X products since an increase in pricing pressure due to change in regulations and/or new entrats could have been the partial trigger of the XX% reduction in profitability we are talking about) 

3) As a simple “behavioural hack”: we as human are trained to learn stories, therefore repeated contents/reference help. So

- try to maximize in your presentation of the framework the use of terms that the interviewer used in the prompt (e.g. name of company, location, other info) - the exact same words. This tricks the brain just a little bit and give a (false?) impression of coherence and structure

Just 1st layer of answer - feel free to PM me if you want to deep dive

All the best for your interview journey!

P.

Hello there,

My suggestion here is to be more goal oriented and less generic. Here there is a very brief summary of the approach you should have:

• Define the problem of the client and the target, covering every detail:
  • Do you have a problem of profits or profitability?
  • Is this problem related to a specific business line?
  • What's the target? In how much time?
     
• Highlight the drivers that could impact your profitability. At this point is very important to understand first of all where is the problem and what's the problem
  • Revenues decreasing (more than costs). You can split this into volume or price segment
  • Costs increasing (more than revenues). You can split this into variable and fixed cost
     
• Give some qualitative reasons that could be behind each driver and suggest some potential analysis you could run

Please avoid any “scholastic approach” that is not tailored on the case and that sounds repeated by hearth. TO double check if something should be in your structure, I suggest to challenge yourself asking “Why do I need this information? How would this drive my analysis/output?”

Feel free to text me if you want to discuss this more,

Luca 

Hi there,

This is indeed an interesting question which is probably relevant for quite a lot of users, so I am happy to provide my perspective on it:

• Generally speaking, I would advise you to have a look at the micro and the macro environment of the client in order to derive the root cause of the problem.
• Still, and more importantly, there is no need to structure the root cause of the problem (as well as the intiatives that would follow) in detail since there simply is no possibility to know where the situation will lead to at the beginning of the case interview. Instead, I would advise you to exactly state it like this, for instance by saying “Once I have identified the numeric driver and its magnitude of the profitability decrease, I will identify the root cause of the problem by examining the closer and wider environment of the client” (obviously in the most customized way possible).
• Lastly, I would advise you to always present the inital structure as customized as possible by implementing e.g. examples or your hypotheses. While there is no need to customize the written structure in detail, this is definitely required during the presentation which also provides you with great opportunities to display business judgement.

In case you want a more detailed discussion on how to properly structure any type of case study questions, please feel free to contact me directly.

I hope this helps,

Hagen

Root cause analysis is not a bucket.

This is very important to understand: You are approaching frameworks wrong. Every single project/framework is about figuring out the root cause, opportunities, options, prioritizations, next steps, risks, etc. These are not buckets.

Your buckets should be your approach to solving the problem. So, it should be “through what lens am I looking to solve this”