In some cases the prompt is clearly analytical (e.g. "why is profitability declining?") , while in others it sounds more operational (e.g. "what should we do in the next 12-18 months?"). How do you adapt the top-level structure while keeping it MECE ,without jumping to solutions?

Hi Annadele,

The key is to anchor your top level structure to the decision being made rather than the wording of the prompt. Even when a question sounds operational like “what should we do in the next 12–18 months,” the interviewer is still expecting structured diagnosis before action.

For analytical prompts like declining profitability, your top level structure naturally starts with drivers and root causes. For more action oriented prompts, you can stay MECE and avoid jumping to solutions by structuring around decision criteria rather than actions. For example, what options exist, what would make each option attractive or unattractive, and what risks or constraints matter. You’re not prescribing solutions yet, you’re defining how you would evaluate them.

A useful rule of thumb is to ask yourself “what do I need to understand before recommending anything?” and let that guide your structure. This keeps you analytical and hypothesis driven while still clearly moving toward an answer.

Happy to help you practice through this thinking - feel free to reach out!

Best,
Evelina

This is an excellent point. The language of the prompt often deliberately masks the underlying strategic problem, and if you jump straight to action, you miss the required diagnostic phase—which is what the interviewer is really scoring.

The way we manage this inside the firm is by understanding that operational questions ("what should we do?") are still fundamentally rooted in strategic choice architecture. Your top-level structure for an operational case should not be a list of suggested actions, but a MECE breakdown of the Strategic Levers or Decision Spaces that must be evaluated before committing resources.

For example, if the prompt is "What should we do in the next 18 months to grow revenue?", avoid immediately structuring around 'Product Launches' or 'Pricing Changes.' Instead, structure your diagnosis around the core dimensions that determine which action is right: (1) Opportunity Sizing/Market Attractiveness, (2) Internal Capabilities/Organizational Fit, and (3) Risk Profile and Financial Viability.

This approach keeps you analytical and hypothesis-driven because under each lever, you are diagnosing constraints and opportunities, not prescribing solutions. You clarify scope by immediately asking, "What is the client's objective function for the next 18 months? Is it high growth, or profitable growth?" Once the goal is set, you use the structured decision spaces to determine the highest impact path. This maintains the essential Diagnosis $\rightarrow$ Recommendation logic required in every case.

Hope this clarifies how to pivot your framework without sacrificing rigor! All the best.

Think of it this way.

If the prompt asks "why is this happening," you're in diagnostic mode. Break the problem into pieces and figure out what's actually causing it before you suggest anything.

If the prompt asks "what should we do," you're in decision mode. Think about what options they have, what matters most to them, and what's realistic given their situation.

Either way, don't jump straight to solutions. Even when they ask what to do, you still need to understand the context first.

A quick rule: "why" questions mean start with understanding. "What should we do" questions mean start with options and trade-offs.

And keep it MECE. Make sure your buckets don't overlap and together cover everything that matters. That works for both types.

Indeed. Great question. 

Basically, the core criteria you should have at the back of your mind is: 'Is this structure useful for solving the client's problem?' 

If the answer is yes, then you're heading in the right direction. And then there are different ways of making it more or less useful. 

Your structure should always be tailored to the question and address the question directly, which is why template structures don't work anymore, or when they do, they at best provide an average performance. 

These are a few of the principles that should underpin every structure. 

If you have any specific questions, don't hesitate to reach out. 

Best,
Cristian

Well, the adage goes the client doesn’t necessarily know the rule causes even if they know the symptoms. 

you want to go in assuming something for the sake of hypothesis, but having the flexibility to pivot to the other if your single bat goes wrong for you to explore other options. That is what MECE does.

Hi Annadele :)

I usually adapt the top level by mirroring the question intent, so for analytical prompts I structure around drivers and root causes, and for more forward looking prompts I structure around objectives, constraints and options without yet recommending anything, which keeps it MECE and avoids solution jumping while still matching what the interviewer is asking; happy to discuss examples anytime. best, Alessa :)

Hi there,

This is the crux of learning how to structure a problem, regardless of it being analytical, operational, etc. You should ask yourself what are the key areas of information you'll need in order to help you make a decision. Each area should be integral in changing or maintaining your hypothesis on what that decision is.