Back to overview

How to structure broad cases asking for root causes and improvement levers at the same time?

Hello! 

Recently, I was confronted with a - at first glance - straightforward case again:

"A low-cost airline in the UK is facing declining absolute profitability and is asking me to help them turn things around."

Of course, I started by asking clarifying questions to narrow things down before structuring, but I didn't really receive any useful information, nor were there any limitations on what the client would be able or willing to do. The only piece of context I got was that other low-cost competitors had recently entered the market. However, the interviewer explicitly said this might not be the sole reason for declining profitability.

The issue I had when structuring was twofold

  1. I had to integrate both the identification of root causes and potential improvement levers into one issue tree.
  2. Given how broad the scope was, I could not really tailor my structure to the specific situation 

My structure

1st level:  revenue and cost (no tailoring here to keep it clean at the top level)

2nd level: quantitative breakdown to identify where the issue sits (diagnostic)

  • Revenue: passenger volume × revenue per passenger
  • Cost: fleet + flight operations + sales & overhead

3rd level: potential reasons / hypotheses

  • External:
    • Competitors: Are the new entrants capturing some of our market share? Are they offering at even lower prices or better quality?
    • Market: Is the market as a whole facing declining profitability (e.g. due to sustainability concerns)?
    • Customers: Are customer preferences shifting toward paying more for better service, e.g. more leg room?
  • Internal:
    • Are there capacity constraints on our side preventing us from leveraging market demand?
    • ...

...and the same hypothesis structure mirrored on the cost side...

4th level: potential improvement levers

  • Each lever is connected to a hypothesis from the 3rd level, framed as "if X, then the client could do Y." For instance, if the new competitors are indeed capturing our market share in this local market, I would suggest exploring the opportunity to expand geographically or target more premium customer segments.

As you can see, my structure got super extensive and I was essentially shooting in every direction given the lack of initial information. So my questions to you are:

  1. How would you integrate root cause identification and solutions within one framework? The prompt implicitly asks for both, and of course it only makes sense to think about improvement levers after identifying the issue, as the root cause should inform the starting point. Sometimes I also see cases that explicitly ask for both.
  2. Do I really have to stay "collectively exhaustive" at the 3rd and 4th level? There could be a huge range of issues and even more potential levers if we get creative. Should I instead name just a few high-probability reasons and levers and frame them as "examples"? For instance, here I would first focus on the fact that the entrance of competitors has likely harmed our business. I just feel uncomfortable leaving out potential points...

Apologies for the long question - I would be super grateful for any advice, as this is something I am often struggling with! 

1
< 100
0
Be the first to answer!
Nobody has responded to this question yet.
Top answer
Profile picture of Franco
Franco
Coach
13 min ago
Ex BCG Principal & Global Interviewer (10+ Years) | 100+ MBB Offers | 95% Success Rate

This is actually a very common type of case and your instinct is directionally right. the main issue is that your structure became too deep and complex to communicate effectively

My first point: going to a 4th layer is usually overkill. In an interview setting that level of detail is hard to deliver clearly without losing the interviewer. In most cases,a solid 2-layer structure plus a 3rd layer of supporting hypotheses is more than enough

Coming to your questions:

1) Integrating root causes and improvement levers

You have two clean options:

  • Category-based approach (classic):
    Structure by revenues (price, volume, mix) and costs (fixed vs variable) For each bucket explain that you will first diagnose what is happening, and then identify improvement actions based on the findings. This keeps diagnosis and solutions logically linked without overcomplicating the structure
  • Process-based approach (often easier to communicate):
    1. Diagnose the current situation (revenues and costs)
    2. Identify improvement levers (based on the diagnosis)
    3. Define an implementation roadmap (prioritization, impact vs effort)
    4. Assess risks and required capabilities

This second approach is often more intuitive especially in broad cases like this one, becaus it mirrors how a real project would be executed.

2) How exhaustive should you be?

Levels 3 and 4 (which, again, I would compress into one hypothesis layer) should not be fully MECE. If you try to be exhaustive there, your structure will become unmanageable and hardto communicate.

Instead:

  • Keep levels 1 and 2 MECE
  • Use level 3 for a few high-probability, well-chosen hypotheses

Think of hypotheses as examples you want to test not an exhaustive list The goal of the framework is to simplify complexity, not to show that you can list every possible issue.

A common trap is trying to “boil the ocean”; strong candidates prioritize and focus on the most likely drivers rather than covering everything.

If you want to discuss further feel free to DM me
Best,
Franco