How to address "Identification & Counter Measures" cases?

This is a very common issue, and I think the key mistake is treating diagnosis and solutions as two separate steps. In good interviews, they’re linked from the start.

At the structuring stage, you’re not expected to know the root cause yet. But you are expected to show that you understand where solutions would come from once the root cause is clear.

1. Don’t list actions early. Define where actions could come from.
Instead of saying “first I diagnose, then I think about countermeasures”, I find it more effective to structure around the main cost buckets and, for each, the types of levers that could exist.

For an airline, that could be:

• Major cost buckets (fuel, labor, fleet, ops, overhead)
• For each bucket: what kind of levers exist (eg. structural vs short-term)

This already embeds the solution logic without committing to specific moves.

2. Use the constraints in the question
The question already gives you guidance:

• 25% cost reduction is big
• 3 years limits what’s feasible
• Airlines have safety, union, and brand constraints

I explicitly test which cost areas could realistically deliver savings of that size under those constraints. That makes the structure feel tailored, even before you know the exact issue.

3. Be conditional, not prescriptive
Generic brainstorming usually happens when people jump straight to actions.

Instead of: “We should cut labor”

Say: “If labor costs are above benchmark and flexibility exists, labor productivity or workforce levers could be relevant”

Same idea, but much more structured.

4. Don’t postpone countermeasures completely
Saying “I’ll think about solutions later” is usually weak. In real projects, you always have a rough view on where the answer might land, even on Day 1. You just don’t lock into it yet.

Rule of thumb:

• Diagnose the problem
• Show how findings would translate into actions
• Commit only when the data supports it

That balance usually lands well in interviews.

Hey there,

This is a very good question and a common problem. However, the problem you are describing seems slightly different than the example case you offered. Here's how you could think about the different types of cases:

1. Client has a problem but doesn't know what the problem is (what you describe in your initial paragraphs): Here, I would suggest going with your approach of putting together an issue tree to identify potential root causes for the problem. As you go through the tree, you can offer some hypotheses regarding where the problem may be and what could be some potential solutions, without going into them in-depth yet (in a real consulting project, this would be your 'Day 1 hypothesis' or 'Day 1 answer'; the final solution might be different, but it's good to have somewhere to start looking). As you go through the case, you will identify the problem and come up with more concrete solutions for that specific problem you identified
2. Client has a problem, they know what it is, and they want you to find solutions (what your case seems to be looking for, at least the way it's framed here): In these situations, the client has already identified the problem, e.g., suboptimal cost structure, and they are looking for a solution (how to cut costs by 25% in 3 years), so this is a more general cost cutting strategy case. Here, you can focus on listing potential ways to cut costs and you can prioritize solutions based on impact (e.g., size of cost bucket and how much can you cut) and feasibility (how easy it is in terms of complexity, resources, timeline, etc.). You might still want to use benchmarking to figure out how much you want to cut, but the framing is less about finding where the issue is and more about optimizing company performance

This is why understanding the prompt and the problem the client is trying to solve is important. You need to understand whether the client is looking for you to try to find where the problem is first or to find solutions for a problem they already identified. If the client wants to you identify the problem first, then you can create an issue tree and offer a 'Day 1 hypothesis' as you go through.

Best,

Maria

Don't aim to develop the content of the 'strategy' component before you completed the actual diagnostic. Instead, explain high level how you would go about defining the strategy component. 

That's about it. 

If you take a step back, the whole purpose of a framework is to provide a working methodology for an effective problem solving with the client. You're basically creating the scaffolding for a thinking exercise. So ask yourself what format / shape this structure should have to be genuinely useful for your discussing with the client. 

If you're looking to improve this area, do reach out and I'm happy to help.

Best,
Cristian

The interviewer knows you cannot give a tailored strategy before you understand the problem. They want to see a logical path, not a magic answer in the first two minutes.

Your instinct is right. Start with diagnosis. Find the big cost buckets. Benchmark them. Identify what is driving the gaps. Then develop countermeasures. That is not a flaw. That is how consulting actually works.

At the start, just acknowledge both parts. Say something like "I will first identify where the biggest cost opportunities are. Once I understand the root causes, I will develop reduction levers and evaluate them on impact, feasibility, and risk." That shows you heard the full question.

Do not brainstorm generic fixes before you know the problem. That is just guessing. Interviewers see through it.

For the airline case, your approach works. Break down the costs, benchmark, find the gaps. If you discover maintenance is 20 percent above industry because of an aging fleet, now you can propose real solutions: renegotiate contracts, renew the fleet faster, consolidate suppliers. That is tailored. That is what they want.

Saying "I will diagnose first, then recommend" is not lazy. It is honest. Just make sure you actually circle back to strategy once you have the facts.

Clear thinking is sequential. Own it.

hey there :)

You are thinking about this exactly the right way and this is a very common advanced level issue. What interviewers want to see is that you separate diagnosis and action conceptually but already connect them logically from the start. The cleanest way is to structure primarily around identification, while explicitly stating that the goal of the diagnosis is to prioritize actionable levers later. In the structure you can anchor this by saying you will identify and size the biggest cost drivers and in parallel keep clear evaluation criteria for future countermeasures, like impact, feasibility and risk. That way you are not brainstorming solutions too early, but you are also not purely sequential or generic. In practice, you should not detail specific actions upfront, but show that every analysis step is designed to inform a concrete decision at the end. This is exactly what strong candidates do and your airline example is already very well framed. Happy to discuss this further if you want.

best,
Alessa :)

This is a fantastic observation, and it highlights the single biggest difference between a purely academic case structure and a consulting engagement. You're right—it feels generic because you don't have the data, but the interviewer wants to see you build the framework for the solution, not just the framework for the diagnosis.

The risk of focusing solely on the diagnostic is that you appear to be delivering a report, not a strategic recommendation. When the initial question embeds both parts, your opening structure must reflect both the analysis phase and the strategic action phase. Avoid the "sequential project plan" trap by grouping your high-level buckets correctly.

In the Airline example, your structure should pivot from identifying opportunities to defining the evaluation criteria for the required transformation. Instead of framing your second bucket as "Countermeasures for underperforming cost levers," try framing it as "Developing and Evaluating Strategic Solution Levers."

This signals to the interviewer that once you identify the area (e.g., procurement costs are 15% too high), you immediately know how to filter and select the right action. Your action framework should thus include two vital sub-bullets:

1. Universe of Potential Levers: Grouping the types of solutions (e.g., operational efficiency, sourcing optimization, structural transformation).

2. Strategic Go/No-Go Criteria: This is the most crucial part. You correctly identified them (Impact, Feasibility, Risk/Brand Damage). By defining these upfront, you show that every data point gathered in the diagnostic phase will be immediately mapped to a strategic choice later, turning a generic list of actions into a highly tailored decision tool.

Essentially, you are presenting a two-part integrated plan: Where to focus the analysis, and How that analysis will translate into a final decision. You don't need the answers, but you must define the machine that will generate them.

Hope it helps!