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

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,

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

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 there,

The short answer is practice, practice, practice.

At this stage, I can framework most things in 30 seconds. However, years ago I simply could not. The more I've done it, the better I've gotten!

Additionally, here's some reading to help: https://www.preplounge.com/en/articles/how-to-shift-your-mindset-to-ace-the-case

Now, what are some techniques for you?

Ask clarifying questions. Not only does this buy you time, but it also actually helps you frame the question/context.
Do 1 bucket/theme at a time - you don't need to know your whole structure immediately!
Leverage buckets you already know exist (and modify).
Grab ideas that pop into your head and figure out what larger theme they fit into.

I also think that you might be thinking about cases/problem-solving wrong.

It is not about coming up with a bunch of questions/ideas, but rather using a logical breakdown/approach (almost a pathway) for solving the problem.

My course covers the end to end journey in detail: https://www.preplounge.com/en/shop/prep-guide/consulting_recruiting_course

Also take a look at the 2 cases in this article, and the associated videos, to see how I drive a case forward using an issue tree: https://www.preplounge.com/en/articles/candidate-led-cases-what-to-expect-and-example-cases

This case will also help show you issue trees (wait for my candidate feedback): https://www.preplounge.com/en/management-consulting-cases/candidate-led-usual-style/intermediate/bcg-bain-vets2u-healthcare-based-case-with-video-solution-305

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

It’s brutal to fall at the first hurdle, especially when you feel like you're carrying the weight of being first-gen. But take that Project Leader’s feedback seriously—at MBB, we don't tell people to come back for the full-time cycle unless we genuinely believe they’re a high-potential hire who just needs more reps. You’ve already cleared the hardest bar: proving you belong in the room.

The BCG failure wasn't about your intelligence; it was a cortisol spike. These assessments (McKinsey’s PSG and the Bain test) are stress tests designed to make you panic so the firm can see how you prioritize under fire. They aren't looking for a perfect score; they are looking for consistent logic and the ability to not "shut down" when the data gets messy. The "average" voice in your head is just your brain's response to an unfamiliar pressure cooker.

Since you have CaseCoach, stop "studying" and start "simulating." Spend 80% of your time on the McKinsey Redrock/Ecosystem game simulations and high-speed mental math drills. For Bain, focus on the "Data Interpretation" modules. Do these in 20-minute sprints without distractions. You need to desensitize yourself to the timer so that when the real test starts, your brain stays in solve mode rather than survival mode.

You've got the talent, now you just need the muscle memory. All the best!

You are asking the right question. Most candidates stop improving here because they keep doing more cases instead of fixing structuring directly.

You go too broad on telecom because you start from generic buckets like customer, product, competitor. Those are templates, not problem-specific drivers. Always start from the objective. "Grow revenue from existing customers" leads to ARPU times number of customers, which opens into retention, upsell, cross-sell, price. Tighter than customer or product.

Your top-level drivers should be a clean equation tied to the objective. Revenue equals price times volume. Profit equals revenue minus cost. Start from math, then add behaviour and market.

For business models, build five or six templates. Subscription, transaction, marketplace, manufacturer, retailer, services. Spend a week drawing trees for companies you know, no prompt, just the model. Apple, Netflix, Uber, Walmart. Builds intuition fast.

Simple rule on tree types. Profitability tree for profit and margin. Root cause tree for diagnosis. Market tree for entry or strategy. The prompt tells you which.

Drills that help. Structuring drills, not full cases, 90 seconds each, 5 to 10 a day. PrepLounge has some. Reverse engineer cases from casebooks. Talk your tree out loud, weak branches show up faster.

Stop relying on memorised templates. Frameworks are crutches. Build trees from the math of the problem.

Good luck.

hi Mustafa! 

The fastest way to improve your case structuring is to stop thinking in terms of “templates” and start thinking in terms of “engines.” Every business problem has an underlying engine that drives the outcome, and your job in the first 3–5 minutes is simply to identify that engine and break it into its first‑principle components.

For growth cases, focus on the growth engine. For telecom revenue from existing customers, the engine is retention, ARPU, and upsell/cross‑sell. If you anchor yourself there, you avoid going too broad.

For margin pressure, focus on the margin engine: price, volume, cost. Then adapt it to the business model. A low‑cost entrant usually affects price and volume first, so your structure naturally becomes cleaner.

A good drill is to take 10–15 industries and write down the revenue and cost engines for each. Once you know the engines, the issue trees become much easier to build from scratch. You’re not memorizing, you’re recognizing patterns and adapting them to the case in front of you.

Alessa

Learning first principles structuring is the one area where it's absolutely worth it to invest in working with a coach. 

The challenge with it is that it's difficult to learn without tailored feedback. 

AI is a bit better than just learning it with case books, but it still misses the interactive element and the ability to challenge your structures (because most AI models were fed case books, so it's effectively repackaging the same content for you). 

I run a targeted session on this with my candidates. Specifically taking them through several examples of case starts, different prompts, and flexibly coming up with different structures based on core principles of structuring. 

If you need help, do reach out and I can explain more. 

Best,
Cristian