The Casebook Opens With Frameworks. The Interview Checks If You Moved Past Them

An unconventional-ish take on preparing for consulting cases, from someone who gave and took more of them than was probably healthy

Every casebook you’ll get your hands on starts the same way. IIM A, B, C, L, FMS, ISB, doesn’t matter. Open any of them and the first section is frameworks. Profitability, market entry, market sizing, M&A, the whole starter pack, laid out like recipes.

I don’t think that’s wrong. I think it’s misunderstood. And the misunderstanding is what quietly wrecks a lot of people’s prep, so let me try to untangle it.

Why every casebook starts with the profitability case

The first case anyone gets handed is almost always a profitability case, and there’s a good reason for it. It’s the most structured, most framework-friendly case there is, which makes it the perfect teaching tool for someone who has genuinely no idea what a case interview even is.

You know the drill. Profit is revenue minus cost. Revenue breaks into units sold times price per unit. Cost breaks into fixed and variable. And so on down the tree. It’s clean, it’s logical, it fits on a page, and a beginner can follow it.

But here’s the thing people miss. The profitability framework is not there to teach you profitability. It’s there to teach you what mutually exclusive, collectively exhaustive actually means, using the friendliest possible example. The profit tree is just the vehicle. MECE structuring is the cargo. If you walk away from the profitability case having memorized the profit tree instead of having internalized how to break a problem into clean, non-overlapping, nothing-missed pieces... you learned the wrong thing, and you learned it confidently, which is worse.

The cases that actually matter don’t live in the casebook

Here’s the uncomfortable part. Most cases an actual consultant faces cannot be solved by a framework sitting on page four of a casebook.

Real problems are unstructured. Unconventional. They arrive as a vague mess, and you spend a good while just asking iterative clarifying questions before you even understand what problem you’re being asked to solve. There is no page-four template for that.

And the interviews know this. By the time you reach the later rounds, the partner rounds, Day Zero, the cases stop being tidy. Partners often don’t even run a “case” in the textbook sense. They just have a conversation with you, poke at how you think, watch how you approach an open-ended mess. None of that can be driven by a pre-memorized framework, and the moment a partner sees you reaching for one, they know exactly what you are... someone who learned the scaffolding and mistook it for the building.

Use the framework only when it actually earns its place

I want to be fair to frameworks here, because the point isn’t to throw them out.

If a framework genuinely adds value to the problem in front of you, use it. No prizes for reinventing structure when a perfectly good one fits. That’s not the failure mode. The failure mode is the reverse: the framework exists, it’s vaguely related to your problem, so you force-fit it in and bend the actual problem to match the tool. That’s backwards, and it’s obvious to anyone watching. The problem leads. The framework serves, if it’s useful, and stays out of the way if it isn’t.

So why do casebooks have a hundred solved cases?

Not so you can memorize them. Let me say that again because people genuinely get this wrong. You are not meant to memorize the cases.

The cases exist so you can see the variety. The sheer range of what someone might throw at you. You go through fifty cases not to bank fifty solutions, but to stop being surprised by shape. So that when something unfamiliar lands, some part of you goes “okay, I’ve seen this general species of weird before” instead of freezing.

And the best cases in any book are the disguised ones. A case that opens looking exactly like a profitability problem, and then somewhere in the middle you realize... this was never about profitability at all. It’s about something else entirely, and you only found that out because you kept clarifying instead of charging ahead with the profit tree you locked onto in the first thirty seconds. That moment, the quiet oh, this is not what I expected, is the whole skill in miniature. The casebook’s job is to give you that moment enough times that it stops rattling you.

A few things that actually help

I’m wary of turning this into its own framework, which would be funny in the worst way. But there are genuine best practices, so here they are, loosely.

Get the problem statement right before anything else. The single best move is to play the problem back in your own words. Not parrot what the interviewer said, but restate it in your own understanding, so both of you confirm you’re solving the same thing. Then ask clarifying questions. Relevant ones.

Clarify to narrow, not to perform. This is where I’ve watched the most people trip. They ask clarifying questions not because the answer helps them, but because they were told good candidates ask clarifying questions, so they run down a checklist. If the problem is about internal people and processes, asking about the company’s product sub-segments is noise. It doesn’t narrow anything. It just shows you’re following a script. Now, if the products turn out to be tangled up in the issue, then sure, dig in. But ask because the answer moves you closer to the problem, not because asking is a box to tick.

Be structured. Every single time. No exceptions. Guesstimate, profitability, market entry, M&A, due diligence, or some unconventional thing nobody has a name for... always impose structure. When you lay out options for the interviewer, do it so cleanly, so exhaustively, that they can’t come back with “it’s neither of those.” The moment they can say that, your structure had a hole in it, and now you’re standing there with nowhere to go. Collectively exhaustive isn’t a buzzword. It’s what stops you from getting stuck.

Kill the laundry list. People love to reel off “well it could be this, or this, or this, or maybe this.” A pile of possible causes with no spine. A list is not a structure. You can have the list, but hang it on a structure, always, so it’s clear why those are the branches and that the branches actually cover the space.

Clarify any ambiguous term immediately. If a word in the prompt could mean two things, do not guess which one and build an answer on the guess. Ask. Half the disasters I’ve seen came from someone confidently solving the wrong definition of a word the interviewer used casually.

And then just practice a lot. There’s no shortcut hiding behind that sentence. Structured thinking under pressure is a muscle, and the only way it gets strong is reps. Out-of-the-box but structured, imaginative but MECE, fast but clarifying. Those aren’t contradictions once you’ve done enough cases that they stop feeling like a checklist and start feeling like how you think.

The one line I’d leave you with

Learn every framework in the book. Then stop trusting them.

The frameworks are how you learn to think in structure when you don’t yet know how. Once you do know how, they become optional... a tool you pick up when it fits and leave alone when it doesn’t. The candidate who cracks the hard rounds isn’t the one with the most frameworks memorized. It’s the one who understood, somewhere along the way, that the casebook was never the point. The structure in your own head was.

What I actually used

Everything above is the philosophy. This is the toolkit. Consistent with the whole argument, none of it is meant to be memorized. It’s meant to get you fluent in structure and comfortable with variety, and then to be quietly forgotten when you’re actually in the room.

A note on how to use this before the links: watch and read to understand shape and method, not to bank answers. The casebooks in particular are for wandering through different framework possibilities, practice cases, and industry primers... not for cramming solutions. If you find yourself memorizing a specific case’s answer, stop, you’ve drifted back into the trap the whole post is about.

I’ve put the full set together in one place here, roughly in the order I’d approach it:

Start here, to understand what a case even is

• Understanding Case Types & Frameworks (playlist): a clean starting point if you’re at zero

• Solved Case Examples (playlist): to see cases actually worked through, end to end

• Key Starting Points — sheet alignment, solution elements, structuring strategies: not an example video, but one of the most useful in that second playlist. Don’t skip it because it isn’t a “case”

To build perspective on good vs. bad solving

• Case Interviews Cracked (channel): genuinely useful for seeing how not to solve a case, which is underrated. Watching someone do it badly teaches you more than another clean solve

• CSC, IIM Lucknow (channel): very well presented, worth your time

Reading, if you want the theory without the full video slog

• You do not need to sit through Victor Cheng’s entire series. If you want the summary, his slide deck and frameworks PDF cover it

Casebooks (for variety, not for memorizing)

• The Indian Tier-1 set: ISB, IIM A, IIM B, IIM C, IIM L, FMS. Use these mainly to walk through the range of frameworks, practice cases, and industry primers

• One other I’d single out as excellent: Case Interviews Cracked

That’s it. It looks like a lot, and it is, but remember what it’s for. Not a syllabus to complete. A gym to get reps in, until structured thinking stops being something you do on purpose and becomes the way you think.