How to effectively structure a case?

Good question, and your diagnosis is already half the answer. The fix is a discipline to anchor the tree to the actual question asked.

Three things that helped my candidates the most:

1. Start from the objective equation, not from drivers Before writing any branch, restate the objective as a math equation. "Grow revenue from existing customers" = # customers retained × ARPU. That single line forces you to stay inside the revenue engine and rules out competitor/product branches that do not map to the equation. If the branch does not multiply or add into the objective, it does not belong in the first level

2. Use 2 trees, not 1, and pick consciously

• Profitability tree when the question is quantitative and the equation is clean (revenue, cost, margin)
• Root-cause tree when the question is diagnostic ("why is X happening") and you need market, competitor, internal lenses The low-cost entrant case is a root-cause case dressed as a margin case. Structure: why is margin dropping (price vs cost vs mix) → then why is price dropping (competitor move, customer switching, channel pressure). Profitability first, root-cause second, nested

3. Drill: 20 prompts, 3 minutes each, structure only Take 20 prompt one-liners from Casebook or PrepLounge. For each, write only the equation and first-level branches in 3 minutes. No second level, no analysis. Do 5 per day for a week. You will stop reaching for templates because you will have built the muscle of deriving level 1 from the objective itself

The second level comes naturally once level 1 is tight. Most weak trees are weak at the top, not the bottom.

Happy to review a few of your trees if useful

Hey there,

Great question, and a really common struggle. Before diving in, let me start with an assumption: I'm reading this as a question about how to structure cases, not so much about drills/exercises or the first discussion after the structure. If that's wrong, ping me and I'll re-angle.

The reason a broad structure helps is precisely because it lets you set up the conversation in a divergent way first: you gather qualitative and quantitative info on the things that actually matter (market dynamics, customer trends, competitive position), and only THEN you converge on the answer. The reason you feel "lost" is probably not that you're going too broad, it's that you're mixing up three different framework types and overthinking which one to pick:

1. Areas of analysis
2. Levers
3. Process

Let me walk through them using your telecom example: "A telecom operator wants to grow revenue from its existing customer base."

1. Areas of analysis

The easiest approach is to see buckets as "areas of analysis" you want to explore during the case. They don't need to map 1:1 to a sub-question of the prompt — they should give you a wide pool of analyzed data to then converge on the solution. I always tell my coachees to start here because it's just simple and easy: if you start overthinking at 01:00, you're in for a looong interview :)

For your telecom case, I'd suggest something like:

Market

• Size, growth, profitability of the relevant telecom segment(s)
• Customer segments (e.g., consumer vs. SMB vs. enterprise; prepaid vs. postpaid)
• Competitive dynamics (e.g., are competitors struggling? Is a low-cost MVNO disrupting? Is the market consolidating?)

Existing customer base

• Customer composition (high-ARPU vs. low-ARPU; long-tenured vs. new)
• Behavioral trends (churn rates, usage, product penetration, NPS)
• Unmet needs and pain points (what are they buying elsewhere, what are they complaining about?)

Revenue plays available

• Retention (reducing churn on profitable segments)
• ARPU expansion (price-up, plan upgrades, premium tiers)
• Cross-sell / upsell (broadband, TV, mobile-fixed bundles, B2B add-ons)
• Inorganic options (e.g., M&A on a struggling competitor)

Financials & feasibility

• Expected revenue uplift per play
• Investment / cost to serve
• Payback and ROI

Risks

• Regulatory / pricing scrutiny
• Customer backlash from price moves
• Competitive response

Why this type of structure helps:

A. It's comprehensive. You're starting with a frame that covers everything one would actually look at. Can you really answer "how do we grow revenue from existing customers" without checking competitive dynamics, customer segmentation, ARPU mechanics, and feasibility? No stone left unturned.

B. It's easy for the interviewer to follow. You're not taking a flashy/unusual angle — you're using something that probably 95 out of 100 McKinsey Senior Partners used in their own interviews 15-20 years ago.

C. It still follows a logical process. In a real engagement (and I've done quite a few telecom revenue projects), you'd do exactly this: workstream 1 on the market, workstream 2 on the customer base, then identify the plays, then build the business case, then flag risks and implementation.

2. The Levers approach

This is the trap I think you're falling into when you say you should "stay close to the revenue engine." Let's say you go straight to (i) Retention, (ii) ARPU, (iii) New customers as your top-level buckets.

A few issues:

1. You're converging way too fast. You've jumped into "how do we pull revenue levers" before understanding whether the market even rewards that. If competitors in the local market are bleeding subscribers, the right move might not be organic ARPU expansion — it might be M&A (acquire a struggling rival's customer base at a discount, or pick up a regional player). You'd never surface that with a pure levers tree, because M&A isn't a revenue lever — it's a strategic option that only emerges once you understand market context.
2. You skip the market entirely. Telecom is defined by competitive dynamics, regulation, and infrastructure economics. A levers tree treats the operator as if it lives in a vacuum. The interviewer will feel that.
3. You're not fully MECE / on-prompt. "New customers" doesn't really fit "grow revenue from existing customers." Levers trees often force you to either drift off-prompt or feel artificially constrained.
4. You sound mechanical. A big part of MBB work is taking what the client says and reframing it into the right plan of attack. If you just echo "revenue = retention × ARPU × volume," you sound like a calculator, not a strategic thinker — and I'm sure you're a more nuanced thinker than that!

→ Is the Levers approach always wrong? No! It shines when the case is genuinely a contained profitability or revenue-decomposition problem (e.g., "our ARPU dropped 8% last quarter — why?"). But for an open-ended strategic growth question, it converges before you've understood the problem.

3. The Process approach

If you tried Process with telecom, you'd end up with something like: (i) Diagnose, (ii) Design initiatives, (iii) Pilot, (iv) Scale. Same issues as before:

1. The "Diagnose" bucket is so broad you'd basically need to recreate the Areas-of-analysis frame inside it.
2. Buckets 2-4 depend entirely on Bucket 1 — you can't say anything about pilot design until you've picked the play.
3. You're assuming the client cares about implementation, which often isn't the question being asked.

→ Not always wrong, but rarely the right fit for a strategic growth case like yours.

Conclusion

On your three specific worries

• Choosing the right top-level drivers: default to Areas of analysis. The drivers come from the case context, not from the objective alone. "Grow revenue" + "telecom" + "existing customers" → Market + Customer base + Revenue plays + Feasibility + Risks.
• Adapting to the business model: the bullet points under each bucket are where the tailoring happens. For telecom, you mention churn, ARPU, bundles, MVNOs. For a SaaS case you'd swap in NRR, expansion ARR, logo retention. Same buckets, different sub-bullets.
• Broader tree vs. pure profitability tree: if the prompt is "diagnose why X dropped," go profitability/levers. If the prompt is "should we / how do we [strategic action]," go broad. "Grow revenue from existing customers" is a how-do-we, so go broad. Your second example ("low-cost entrant causing margin pressure") actually has both flavors — a profitability tree on margin AND a competitive/strategic angle on the entrant — so it warrants a hybrid.

Takeaways

• Start with Areas of analysis. It's the safest, most comprehensive default.
• Every framework must be fully tailored (i.e., main buckets and underlying bullets) to the specific case.
• Think of frameworks as puzzle pieces you assemble, not templates you memorize.
• Your "I keep getting lost" feeling is almost certainly overthinking, not under-structuring :))))
• Only after the structure and after picking up a few info, you can layer on a hypothesis: "My initial hypothesis is that the operator should prioritize retention of high-ARPU segments and selective cross-sell -- unless competitors are weakening, in which case M&A may be the higher-NPV play"

Hope this helps! 

Best, 
Tom

Hi Mustafa, very common challenge — and honestly what you describe is exactly the shift from “using frameworks” to actually structuring.

A few thoughts.

1. Start from the objective, not from case types
Most structuring issues come from asking:
“Which framework fits?”

Better question:
“What drives this objective mechanically?”

For your telecom example, if the objective is revenue growth from existing customers, start from the equation:

• customers × revenue per customer

Then maybe:

• retention
• upsell / cross-sell
• pricing / ARPU

Very clean.

In other words: follow the economics of the problem first, not a generic business framework.

2. Use broad root-cause trees only when the question calls for diagnosis
Simple rule I use:

• If the question is improve X → start with drivers of X
• If the question is why is X deteriorating → root-cause tree can make sense

So for “margin pressure due to low-cost entrant,” I’d probably still start:

• revenue pressure
• cost pressure

And only then go into competition if needed.

Many candidates go external too early.

3. Don’t aim for perfect trees in minute one
Good candidates don’t have a perfect issue tree from the start.

They have:

• a clean top layer
• a strong logic
• then they refine

That’s enough.

4. Best drill I know (very effective)
Take random business prompts and spend 2 minutes only on first-level structure.

No full case.

Just practice:

• objective
• 2–3 top-level drivers
• one level below

Do 10 of those and you improve faster than doing 2 full cases.

Also a good exercise:
force yourself to start every structure from one of these:

• equation
• process
• decision split

It trains first-principles thinking.

And one last thought: the fact that you notice when you go “too broad” is already a very good sign. That’s actually the hard part.

If helpful, happy to help you practice this — structuring is very trainable once the logic clicks.

Hi Mustafa,

I think you’re actually asking the right questions — this is exactly where most people struggle with structuring.

What usually causes the issue is trying to pick the right framework first. That’s what leads to those “too broad” structures you mentioned.

A better way (and much more reliable) is to start from the logic of the problem itself.

For example, in your telecom case: “grow revenue from existing customers.”
If you pause for a second and think about how revenue works, you’ll naturally land on:

• keep customers (churn / retention)
• increase revenue per customer (price, usage, upsell)

That’s already a solid structure. You didn’t need “customer/product/competitor” — that’s why it felt too broad.

Same with the margin pressure case. Instead of thinking “which framework fits,” just go back to basics:
profit = revenue – cost

Then ask:

• are we being forced to lower prices or losing volume?
• or are our costs higher than the low-cost player?

From there, you can expand cleanly.

On your specific points:

• Picking top-level drivers:
  If your buckets don’t directly answer the question, they’re probably too generic. Starting from a simple equation (revenue, profit) usually fixes that.
• Adapting to the business model:
  Just ask yourself “how does this company make money?” and reflect that in your structure. It doesn’t need to be perfect — even a rough version helps.
• Broad vs focused:
  If the question is precise (like your telecom example), stay close to the driver. If it’s vague (“profits are down”), then it makes sense to start broader.

What helps a lot in practice is doing short structuring drills. Just take a prompt, spend a few minutes building a structure, and stop there. You improve faster doing that than running full cases every time.

If I had to sum it up: don’t try to remember frameworks — just rebuild the logic from the question. That’s usually what makes the structure click.

Best,

Soheil

Hi,

Thanks for your question.

You are on the right track to think about building your framework from first principles. That is a great starting point since many candidates cannot go past using  templates or familiar frameworks which works only if the problem statement is very generic. What you need to refine is the the execution piece and knowing how deep is deep enough. 

Before you build any framework, think of what is the objective of the framework. It is to guide you through the case to solve the business problem, where the objective is your north star. Thus, the more comprehensive but also specific your structure is, the more efficient it is going to be, to help you solve the problem. But comprehensive and specific don't often go hand in hand. So you need to think a little differently to incorporate both.

Below are some tips to address the challenges you shared.

1. struggle with choosing the right top-level drivers for the objective

The fundamental drivers for a business problem are mostly going to be the same, but depending on the problem statement, you may need to eliminate some or all of the drivers upfront if not relevant. 

So to build the first level framework, you can think about it as a two step process by asking yourself these two questions -

i. What are the key/foundational elements of this business problem type 

ii. Is the problem I am solving for more nuanced, in which case I need to tailor my framework to fit that.

In the examples you have shared, if you apply the above, a case like “grow revenue from existing telecom customers,” I would  see that the problem is nuanced and thus, my generic framework will not apply. HOWEVER, it still has the "revenue" element. So instead of thinking about the entire market, I would look at the drivers that generate "revenue" for existing customers - the focus becomes more internal.

First level  is still - Revenue = volume * price

But underlying buckets are driven by more internal vs. external factors since we have already acquired these customers.

Drivers of volume - 

Customer - what is my customer retention/churn rate?

Product - What is the quality of my product/service? What services do we provide? Can we provide additional services?

Marketing - can we increase revenue through promotions, upsell?

Drivers of Price:

Price - do we have potential to increase the price? How is the pricing pressure in the market? 

In the second example, “low-cost entrant causing margin pressure,” this seems to be a more standard problem, assuming you are trying to solve for low profitability or loss of revenue issue. In that case, you start with the first level of the profitability framework - Profit = Revenue - cost. Going to step 2 of the process, the problem statement has a little bit more information. It states, the issue is due to a low cost entrant... so you may want to start with the cost side drivers first and then look at the revenue side drivers, if needed, to solve this problem.

1. adapting the tree to the business model, and

   >> I addressed this in the above response. In order to build a structure that fits the business model, you need to know about the industry to make it more specific to the business. I would start with seeing if you can find  primers for different industries. Some case books may have it. For continuous improvement, start reading business articles form sources such as Barrons, WSJ etc. Often sell side analyst articles available for free online on stocks are a great resource to learn about the industry. 

   3. knowing when to use a broader competitive/root-cause tree vs. a pure profitability tree.

   I am not sure what you mean by a competitive or root cause tree. Assuming question is root-cause vs. a broader framework, then that again ties to the objective. If your problem statement is to find the cause of the problem first, root cause tree may be required. If the problem is more generic, then you keep your structure broad. But there is no option A, and if not option B. Even when solving a broad profitability issue, you need to understand what is driving the issue. So instead of thinking in lines of which type of tree/framework/structure to use when, think about do you have a framework that will help you solve the "specific" problem at hand.

   Practicing yourself by going through case prompts and spending 3 -5 minutes to build a framework using first principles, and then reviewing the solution, is an efficient way to improving structuring a problem. It not only helps you practice the drill, but also exposes you to different kind of problems and industries in a short time.

   Feel free to reach out if any questions.

   Thanks,
   Soh