Case Interview Frameworks: The Ultimate Guide (2026)
If you've googled your way here, you've probably already seen the promise: memorise these 20 frameworks and you'll pass your case interview. Some books are built entirely on it. Some coaches sell it.
So let's answer the question directly. Do you need to memorise a stack of case interview frameworks to get into McKinsey, BCG, or Bain?
In short: No! And leaning on memorised frameworks is one of the fastest ways
we've seen candidates fail.
We spent 6+ years each at McKinsey, first as consultants and later as interviewers scoring cases from the other side of the table. We've watched hundreds of candidates structure problems. The ones who reach for a memorised template are almost always spotted within the first 90 seconds. Why? Because we've heard that same template a hundred times before and we notice when a candidate tries to fit a case around a memorised framework. The ones who get the offer do something different: they think, and they build a structure that fits the specific problem in front of them. This not only helps them for the case interview but also later in their career.
This guide covers the frameworks you should know, why they exist, why memorising them backfires, and the method that actually works. The one that keeps paying off long after the interview is over.
First, What a "Framework" Actually Is
Strip away the jargon and a framework is just a structure: a way of breaking a big, messy problem into smaller, logical pieces you can actually work through. In a case interview, you draw this as an issue tree: the problem at the top, then branches, then sub-branches.
A good structure does two things, and only two things:
It's well-adapted to the case in front of you. The branches reflect this client, this industry, this exact question/problem.
It's logically coherent. The branches don't overlap and, together, they cover the whole problem. That's the principle behind the word you'll hear everywhere: MECE (mutually exclusive, collectively exhaustive). We've written a full post on MECE if you want the deep dive.
That's it. Every "framework" you've ever seen is just someone's attempt to package a common structure so you don't have to reinvent it each time. Useful as a starting point but dangerous if you solely rely on them.
The Classic Consulting Frameworks (and Why They Exist)
Here are the frameworks that come up again and again. Learn them. Not to recite, but to understand why each one is built the way it is. Once you see the logic underneath, you can rebuild any of them from scratch and tailor them to the actual case you are trying to solve:
Profitability. The workhorse. Profit = Revenue − Cost, so if profit is falling, either revenue dropped, costs rose, or both. From there you split revenue into price × quantity, and costs into fixed and variable. Roughly 40% of cases have a profitability core, which is exactly why interviewers are so tired of hearing it recited raw. The logic is gold. The generic four-buckets-of-revenue recital is not.
Market entry. "Should our client enter market X?" The very common case type. The underlying logic: is the market attractive (size, growth, competition), can we win in it (our capabilities vs. what's required), and is it worth it financially (the profit maths, plus how we'd enter: build, buy, or partner)?
Mergers & acquisitions. Should the client buy this target? Or more specifically: is the target itself a good business, does the combination create value (synergies, minus the cost and risk of integration), and are there better uses of the money?
Pricing. How should we price this product? Three lenses that are worth knowing by name: cost-based (your costs plus a margin), competitor-based (what similar products sell for), and value-based (what it's worth to the customer).
3C / Business situation. Sub-questions in many cases require an assessment of the business situation. The 3Cs (i.e., Company, Customers, Competitors) are a smart way to scan a business landscape.
4P (marketing mix). The 4Ps (i.e., Product, Price, Place, Promotion) is one of the most common frameworks applied in business. It is handy specifically when the question is about how to sell or launch something.
Porter's Five Forces. An oldie but goldie. A tool for judging how attractive an industry is: rivalry, new entrants, substitutes, buyer power, supplier power. Great in a strategy classroom. In a 30-minute case it's usually overkill unless the question is squarely about industry attractiveness. Understanding the buckets is nonetheless helpful as the criteria help in answering many questions.
Notice the pattern. None of these is a form to fill in. Each is a reasoning path someone else already walked. And the reason these frameworks are MECE is that they follow the basic principles about how businesses work.
Why Memorising Frameworks Backfires
Here's what happens on the interviewer side of the table when a candidate memorises frameworks.
They hear the prompt, pattern-match it to the nearest template, and start applying it: revenue drivers, cost drivers, the same buckets in the same order. And if an aspect of the case doesn't really fit the framework, they manage somehow to squeeze it in. Two problems with this approach:
First, we've seen that exact structure a hundred times. When you parrot a memorised framework, we know immediately, and it reads as "this person learned the choreography but can't actually think." Interviewers at McKinsey, BCG, and Bain have all heard the standard frameworks so many times that recognising one makes their alarm bells ring. Candidates are then genuinely surprised they didn't pass.
Second, and this is the deeper failure, a memorised framework makes you squeeze the case into a shape it doesn't fit. You end up applying a super-generic structure to a specific problem, missing the parts of the case that actually matter, because your template didn't have a branch for them. We've seen many candidates stumble when drawing up the issue tree once they realise that parts of the case just don't fit the standard format. You optimised for looking prepared and lost the thing being tested: clear and tailored thinking applied to a unique business problem.
The tell is always the same. A memorised structure is generic. A great structure is obviously built for this case.
What to Do Instead: Tailor The Frameworks & Don't Memorise
So if the approach for mastering the case interview is not memorising 20+ frameworks, what is the approach then? The right approach is to learn a repeatable method for building a structure on the spot. Here's the one we teach:
1. Clarify and narrow the solution space. Before you structure anything, ask 2–3 questions that actually change your approach. Not generic questions for the sake of asking. But questions whose answers rule things in or out. What does success look like to the client? What's in and out of scope? Good clarifying questions shrink the problem before you draw a single branch. And when walking the interviewer through the issue tree you can clearly point at branches and mention, that this will likely not solve the problem based on what you have learned from your questions.
2. Anchor on the real objective. Every structure hangs off the actual question. "Which renewable project should we invest in?" is a different tree from "why are profits down?" Write the objective at the top and make every branch serve it.
3. Break it down from first principles. Start from a logic you understand, not a template you memorised. Profit really is revenue minus cost. So if that is at the core of the objective and the logic fits, use it. But derive it, don't recite it. When you build from first principles, you can always defend why your structure looks the way it does. The tailoring to the case often comes at the second level of the issue tree.
4. Make it MECE and case-specific. This is where you win or lose. Take the skeleton of the your customised issue tree and weave in light, relevant industry knowledge so the branches are unmistakably about this case. A branch called "non-financial factors: permits, local resistance, logistics" beats "external factors" every time.
5. Sequence it. Tell the interviewer which branch you'd explore first and why. Even in McKinsey's interviewer-led format, where the next question is often predetermined, signalling your priority shows you're driving the case, not waiting to be driven.
Do this five-step move enough times and it becomes muscle memory. That's the goal. Nt a library of templates in your head, but a reliable process for building the right structure every time.
Worked Example: Generic vs. Tailored
Let's make this concrete with a case we designed ourselves and use in our full worked walkthrough: a mid-sized Spanish utility wants to pilot a renewable-energy project on a Mediterranean island, and the CEO needs to know which type of project to invest in.
The memorised approach.
A candidate reaches for the profitability framework: revenue minus cost, four buckets of revenue drivers, three buckets of cost drivers. Technically correct. And it would bore the interviewer to death within 90 seconds. Bbecause it says nothing about renewables, nothing about this island, nothing about this decision.
The tailored approach.
Here's the structure a strong candidate actually built in the live case. First level: Wind, Solar, and a cross-cutting business-model bucket. For each energy source, a split into financial and non-financial factors. The financials break down into power generated (turbines × performance × wind or sun conditions) times the selling price, minus depreciation, maintenance, and land lease. The non-financials are the interesting part: permits, environmental approvals, neighbour resistance, the "not in my backyard" (NIMBY) problem, and the logistics of getting turbines onto an island. The business-model bucket captures things like rooftop rental models, power purchase agreements (PPAs), and green bonds.
Both trees are MECE. Both would technically be scored as "structured." But only the second one tells the interviewer two things in a single move:
You can think clearly
You have business common sense
That second signal is what separates the candidates who pass the first round from the ones who don't, and it's completely invisible to anyone who only memorised templates.
Real Cases Mix Frameworks
One more reason memorisation fails: real cases rarely fit a single framework cleanly. A market-entry case often needs you to size the market first, then run a profitability analysis, then weigh a competitive response. A profitability case might turn into a pricing question halfway through.
That's normal. The skill isn't picking the one right framework. It's pulling the relevant pieces from several and combining them into one coherent structure. Use the profitability logic to locate where the money problem sits, borrow the 3C lens to understand the competitive dynamics behind it, and keep the whole thing tailored to the case. Candidates who think in templates freeze when a case won't fit one box. Candidates who think in business principles just build what the problem needs.
Why This Skill Pays Off Long After the Interview
Here's the part almost no framework guide mentions. The ability to take a vague, messy problem and break it into a clean, tailored structure isn't an interview trick. It is the job.
As a consultant, and later in any senior role, you're handed ambiguous problems with no template attached: a business unit is underperforming, a market is shifting, a decision has to be made with incomplete data. Understanding what truly matters and structuring your way to an answer efficiently is the skill that makes you useful. In the interview, on your first project, and in every leadership role after that. The case interview tests it precisely because the firms know how much it matters on the actual job.
So when you practise structuring, you're not cramming for one exam. You're building a way of thinking you'll use for decades.
How to Actually Practise This
Reading about structuring builds nothing. Doing it does. A few drills that work:
Structure-only reps. Take a stack of case prompts and, for each, spend two minutes building an issue tree. Then stop. You don't need to solve them. You just need reps at turning a vague prompt into a tailored, MECE structure.
Compare against a strong answer. After each rep, look at how a top candidate structured the same prompt and ask what they included that you missed. Usually the case-specific, business-common-sense branches. But don't worry if your solutions slightly deviate from the sample solution. There is no one single solution for a case. As long as your structure is MECE and you are specific to the case you are on the right track.
Say it out loud. In a real case you have to walk the interviewer through your structure. Practising in silence hides the exact weakness that sinks candidates. Clumsy explanations can turn a great structure into an interview going sour. Talk to an imaginary interviewer, even if it feels silly.
Do this with authentic, interview-level cases. Many old business-school case books and peer-made cases will be misleading. We covered the reasons why some case material is better than other in another blog post.
The Bottom Line
Frameworks are worth learning. But only as thinking tools, not scripts. Understand why profitability, market entry, and the rest are built the way they are, and you'll never need to memorise a 20+ framework catalogue. What interviewers actually reward is a structure that's MECE, built for the case in front of you, with a tailored structured with a bit of business common sense. Memorise templates and interviewers spot it in 90 seconds. Learn to think, and you'll pass the interview and be better at the job that follows.
Structuring is a skill you build through reps on realistic cases with feedback on what a top candidate would have done differently. Our Case Interview Mastery course on Udemy gives you 7 full McKinsey-style cases. Each with a do-it-yourself version, a model solution, and a feedback version where we pause and explain why every structuring move was made. Taught by us, two former McKinsey interviewers. It's the prep we wish we'd had.
