Last Updated on June 8, 2026
By Florian Smeritschnig, former McKinsey Senior Consultant · Updated June 2026
A case interview framework is the custom structure you build at the start of a case to break a business problem into testable parts. The frameworks that win offers at McKinsey, BCG, and Bain are not memorized templates from a book. They are broad (they cover the whole problem with no gaps), deep (they drill from the symptom down to the root cause), and insightful (they are tailored to this exact client and led by a hypothesis). Master those three properties and you can structure any case, including one you have never seen.
I spent five years at McKinsey as a Senior Consultant, now scoring candidates from the other side of the table, and have run more than 2,200 case interviews. Here is what I can tell you that no case interview book will: interviewers spot a memorized template immediately, and modern cases are deliberately built to break templates. This guide shows you the standard a great structure has to meet, and the exact thinking techniques to hit it live.
Key Takeaways
- A case interview framework is a custom structure you build live, not a template you memorize from Victor Cheng or Case in Point.
- Every winning framework is broad, deep, and insightful. That is the standard interviewers actually grade against.
- Broad comes from applying the right lenses from first principles (e.g., components, processes, segmentations), not from one canned bucket set.
- Deep comes from laddering “what drives this?” until each branch is testable. Insightful comes from tailoring and leading with a hypothesis.
- Memorizing the 4Ps, 3Cs, Porter’s Five Forces, a market entry or growth framework, or a profitability template is one of the fastest ways to get cut at MBB.
What a case interview framework actually is
A case interview framework breaks a client problem into clear, manageable components. It is the roadmap you define at the start of the case to guide your analysis and decision-making.
You outline the key areas to investigate in order to identify the root cause of the problem or answer the client’s core question.
A case interview framework does three jobs at once. Miss any one of them, and the interviewer notices.
- It is an investigative roadmap. It maps where you will look first to find the answer to the client’s question, so you test drivers in a logical order instead of chasing data at random.
- It is a communication device. It shows the interviewer how you think before any analysis happens. A clear structure makes everything after it read as organized.
- It is the main analytical test. Interviewers grade the structure itself, not just what you do with it. Structuring is usually the most heavily weighted moment of the case.
Here is the distinction the prep industry blurs.
A framework is not a list of topics. It is a hypothesis about what drives the problem, expressed as a tree of testable sub-questions.
At StrategyCase I use “structure” for the thinking and “framework” for the output you present, and I avoid the word “template” entirely, because a template implies copying, which is the exact opposite of the skill being tested.
The standard that wins: broad, deep, and insightful
Forget memorizing structures. Learn the standard every structure has to meet. Knowing the evaluation criteria of strong frameworks, and after thousands of mock cases, the same three properties separate the frameworks that earn offers from the ones that get a polite “thanks, let’s move on.”
A great framework is broad, deep, and insightful, in that order of how candidates usually fail.
Broad: cover the whole problem with no gaps
A broad framework covers the entire problem space at the top level, with buckets that do not overlap and leave no major driver out. This is where memorized frameworks fail first, because a canned bucket set almost never fits the specific case.
You do not get broad by guessing. You get broad by applying a lens to the problem. Each lens is a different way to cut the problem into clean, complete pieces. Learn these three and you can build a broad top level for almost any prompt:
| Lens | The question it asks | Best for |
|---|---|---|
| Component | What parts make up this system? | Tangible objects, operations, a P&L |
| Process | What are the steps, in sequence? | Customer journeys, workflows, operations |
| Segmentation | How can I split the area of investigation? | Customers, products, regions, channels |
First-principles thinking means starting from what is true about this specific case and building up, rather than starting from a template and forcing the case to fit. The objective informs the areas to consider, not the other way round.
Two techniques do most of the heavy lifting and, applied case by case, replace an entire framework library.
Technique 1: Component deconstruction
Break the business, product, or system into its parts. Useful when the case involves a tangible object, operation, or static structure.
Example: An airline wants to improve on-time performance. Components that impact this outcome might be internal components such as aircraft, crew, ground operations, support systems, and external-dependencies like airport infrastructure/capacity, weather, and regulation. You evaluate each as a potential driver of delays.
Component deconstruction forces you to engage with the physical or organizational reality of the business. No template can produce the right components; you have to build them from the prompt itself.
Technique 2: Process deconstruction
Map the sequence of steps a customer, product, or workflow moves through. Useful when the case involves a journey, operation, or time-ordered process.
Example: A hotel chain wants to improve guest satisfaction. The process might be: booking, check-in, stay experience, post-stay follow-up. Each step is a potential intervention point.
Process deconstruction works well for customer experience cases, operations improvement cases, and anything involving a sequence. Again, no template can produce the right steps; you have to reason from the specific workflow.
Both techniques force you to engage with the specifics of the case. You cannot execute them on autopilot. That’s the point: the interviewer watches you reason, which is what they’re grading.
Also, only by following this approach can you identify where the issue lies and how large it is (the what), then drill down into why it occurs (the why), and ultimately develop a solution (the how). First-principles thinking enables you to break a problem into its fundamental components and systematically rebuild it into a clear, actionable answer.
There are additional techniques, but in my experience, these two are sufficient to handle roughly 95% of all case interviews. We cover more examples of component and process deconstruction as well as other first-principles lenses in our Structured Frameworks and Brainstorming Course.
Deep: drill to the root cause, not the symptom
A broad framework that stops at the first level is shallow, and shallow reads as superficial thinking. Depth means each top bucket keeps splitting until you reach something you can actually test or measure. Two to three levels is the right range for a case you have 20 to 30 minutes to crack.
The technique is a ladder: for every branch, ask “what drives this?” and split again, until the leaf is concrete enough to attach a number or a data request to. A profit drop is a symptom. “Variable cost per unit is up” is a driver. “Our main supplier raised raw-material prices 12%” is a root cause you can act on. Stop at the symptom and you have a topic list. Reach the root cause and you have a structure.
One discipline keeps depth honest: restraint. A 14-branch tree with 40 sub-drivers is not deep, it is unworkable. Go deep on the branches your hypothesis says matter most. Depth signals rigor; restraint signals judgment, and interviewers grade both.
Insightful: tailor it, and add what the textbook misses
This is the property almost nobody teaches, and it is the one that turns a “good” structure into an offer. An insightful framework makes the interviewer think, “I had not considered it that way.” A memorized template, by definition, can never do that. You can be exactly as good as the book and no better.
Insight is partly creativity, and creativity here is trainable. Five techniques produce it:
- Tailor to this specific client and industry. Name the real drivers, not generic ones. A streaming service and a steel plant do not share the same customer experience, so their trees should not look the same.
- Add non-obvious branches. Second-order effects, competitor reaction, customer behavior, regulatory risk, cannibalization. The branch the textbook omits is usually where the insight lives.
- Prioritize out loud and lead with a hypothesis. Say which branch you would test first, why, and how. Judgment, not just coverage, is what senior interviewers reward. This is the answer-first habit Bain prizes, and it works at every firm.
- Think from the client’s or customer’s seat. Ask what the CEO would actually worry about. That instinct comes from seeing real structured business thinking, which is also what brainstorming practice builds.
- Use an analogy: Change the setting of the case to something similar where you are more familiar with. For instance, finding up a distribution center and finding your own apartment share many of the same core problem drivers (budget, size, equipment, location, infrastructure connection,…).
The quick quality checklist
Before you present, pressure-test your structure against five fast checks. They are just broad, deep, and insightful made operational:
- MECE: no overlaps, no gaps (broad and deep)
- Actionable in the time you have: 3 to 4 buckets, not 14 (deep, with restraint)
- Coherent: every leaf clearly rolls up to the root question
- Tailored: it could not be pasted onto a different case (insightful)
- Hypothesis-driven: you can say what you expect to find before you look (insightful)
Match your structure to the question type
Before you build, notice which of two jobs the case is asking for. Pick the wrong type and you will answer the wrong question well.
| Diagnostic framework | Evaluative framework | |
|---|---|---|
| The question | “Why is this happening?” | “Should we do this?” |
| Example prompt | “Customers are leaving. Why?” | “Should we enter the European market?” |
| Shape | A driver tree you rule branches out of | A decision tree weighed against a goal |
Candidates who have only drilled diagnostic trees freeze on evaluative cases, and the reverse. Practice both.
Why memorizing case frameworks gets you rejected
The prep industry still sells 2000-era framework books as if cases have not changed. They have. Here is why plugging in a template backfires at MBB.
- You get no credit for the hard part. The skill being tested is the thinking, not the output. A memorized framework shows a structure without showing you can structure, which leaves the most heavily weighted dimension blank.
- Modern cases are built to break templates. Firms caught up on template-matching over a decade ago. Today’s prompts are off-archetype on purpose: non-profit sustainability, cross-industry operations, digital transformation, AI implementation, customer experience, with no clean cookie-cutter bucket mapping. Generic structures produce incoherent trees on these.
- Templates cap your upside. The best structures are insightful, and a template cannot be.
- You cannot defend your choices. When the interviewer asks “why this bucket?”, first-principles logic lets you answer. A paraphrase of Case in Point does not.
So treat the classics and their frameworks, the profitability template, the 3Cs, the 4Ps, Porter’s Five Forces, the BCG matrix, McKinsey 7S, as vocabulary that builds business intuition, never as answers to deploy.
You are working with an operator of a specific type of machines that exhibit different breakdown rates across locations. What factors could explain these differences?
Example of a Real McKinsey Case Interview Framework Questions
Which cookie-cutter framework idea would you present here to the interviewer? There isn’t a single predefined bucket in common case literature that fits this problem.
Here’s how a sample framework could look like instead.
Our review of the best case interview books covers where each one helps and where it quietly hurts.
The 4-step method to generate and deliver a framework in the interview
This is the delivery method I have refined across thousands of coaching hours. It works across McKinsey, BCG, Bain, and the Big 4 because it mirrors how strong consultants structure ambiguous problems.
1. Clarify the objective
Start by paraphrasing the client question in one sentence to confirm the scope.
For example:
“So the client wants to understand why machine breakdowns have increased across several sites and what they should do about it.”
Ask one clarifying question only if it materially changes your structure. Do not ask three generic questions just to buy time. A strong candidate clarifies the problem, not the entire business context.
2. Take thinking time and build the structure
Ask for 60 to 120 seconds to structure your thoughts. During that time, write the question in shorthand, then build 3 to 4 top-level buckets that cover the full problem.
Under each bucket, add 2 to 3 concrete sub-drivers. The goal is not to create a long list. The goal is to create a logical map of the problem.
Before you speak, decide where you would start. This prevents your framework from sounding like a static checklist.
3. Present the framework top-down
Start with the overall architecture before going into details.
For example:
“I would structure the problem around three areas: first, whether the machines themselves differ; second, whether usage and maintenance differ across sites; and third, whether local operating conditions or data quality explain the variation.”
Then walk through each bucket in order. Use clear signposting:
“Starting with the machine side…”
“Second, on usage and maintenance…”
“Finally, on external conditions and data quality…”
This makes your answer easy to follow and shows the interviewer that you can lead a structured discussion.
4. Prioritize and link it back to the case
Do not end after listing the buckets. Close with a hypothesis and a next step.
For example:
“Given that the issue appears to vary by site, I would start by comparing usage intensity and maintenance practices across locations, because these are usually more variable than machine design. The first analysis I would request is breakdown rate per operating hour by site, split by machine model and maintenance history.”
This final step is where many candidates lose points. A strong framework is not just broad and detailed. It also tells the interviewer where to look first and why.
How McKinsey, BCG, and Bain grade your framework
McKinsey runs an interviewer-led case format, which means structuring is tested more heavily and more explicitly than at BCG or Bain.
Typical timing in a McKinsey case:
- Up to 2.5 minutes to draft your structure after hearing the prompt
- 5-6 minutes to present your framework and discuss it before moving into analysis
There is no single “correct” structure. Interviewers evaluate four dimensions:
- Breadth. Have you covered the full problem space without gaping holes?
- Depth. How far do your sub-branches go? Shallow frameworks read as superficial thinking.
- Insight. Is there at least one bucket or angle that shows genuine business thinking, not just mechanical decomposition?
- Hypothesis quality. Before moving into analysis, can you say which branch you’d prioritize and why?
Strong candidates use the drafting time actively. They write, revise, and pressure-test their own structure before presenting. Weak candidates write out a memorized template, check the time, and start presenting with no critical review.
For the full picture of how McKinsey runs cases and what interviewers evaluate, read the McKinsey case interview guide.
Bain and BCG use the same evaluation criteria, yet expect less depth and communication time. Fore more, see our BCG case interview guide and Bain case interview guide.
How to practice building structures the right way
You cannot memorize your way to this skill, but you can train it deliberately. This is the sequence I use with coaching clients who go on to land MBB offers.
- Learn the building blocks, not the frameworks. Understand the different approaches to first-principles thinking and how to apply them in a case interview: component perspective, process perspective, stakeholder considerations, supply and demand approach, as well as others and variations of each. These are the conceptual building blocks of framework creation. This is not about memorizing a framework. It’s about having the vocabulary to build one live.
- Do structure-only drills before full cases. Hear a prompt, give yourself 90 seconds, sketch a framework, then critique it against broad, deep, and insightful. Do 40 to 50 of these, which is exactly what our structuring drills are built around, before you touch a full case.
- Practice on real, varied cases. Work through authentic prompts across profitability, market entry, operations, M&A, and pricing so no single archetype becomes a crutch. Our case interview examples library pulls from real McKinsey and MBB cases.
- Get honest feedback. Self-practice reinforces bad habits if you can’t see them. Every candidate I’ve coached to an MBB offer went through 1-5 sessions of targeted feedback on structuring (and cases as a whole). If you don’t have a coach, practice with a peer who’s prepared to call out weak MECE, missing hypotheses, and template creep. You can use our Case Interview Feedback Sheet for you case practice.
- Interpret real business. McKinsey Quarterly, Harvard Business Review, and The Economist train your brain to frame problems in structured terms, which lifts framework quality with no extra case reps. Use these articles to critically think about current situations and problems as well as suitable frameworks to analyze them.
Incorporate framework creation into your case interview preparation plan.
Frequently asked questions
What is the best framework for case interviews?
There is no single best framework, and that is the point. The best structure is the one you build for the specific case in front of you: broad enough to cover the problem, deep enough to reach root causes, and tailored enough that it could not be pasted onto another case. Learn the method, not a model answer.
How many case interview frameworks should I memorize?
Zero. You should understand how a business operates and how first-principles thinking works, then apply it to different problems until structuring becomes second nature to you so that you can always build a custom structure live. Thinking clearly beats reciting 30 templates.
Are case interview frameworks still relevant in 2026?
Yes, as a way of thinking, not as memorized templates. Breaking a problem into MECE parts with a hypothesis is central to how McKinsey, BCG, and Bain evaluate you. The canned templates from Cosentino and Cheng are what interviewers filter out.
What is the difference between a framework and a structure?
Structure is the thinking, the act of deconstructing the problem. Framework is the output you present. I avoid “template” on purpose, because it implies copying, which is the opposite of the skill being graded.
How long should my framework be?
It’s less about the quantity and more about the quality. For a typical MBB case, aim for enough general top-level buckets that cover the problem fully, then add sufficient depth. If done through first-principles thinking, this will usually end up with 3-4 top-level categories with 2 to 3 sub-branches each. Fewer reads as shallow; more cannot be worked through in the time you have. Depth signals rigor, restraint signals judgment.
Can I prepare frameworks in advance for common case types?
You can prepare concept libraries (what drives profit, what moves market share, what shapes a customer journey), but not finished frameworks. Every case has specifics that demand a case-specific structure, so the preparation lives in the concepts, not the templates.
Should I use Victor Cheng or Case in Point frameworks?
No. Both have educational value for understanding what frameworks look like, but the specific templates they promote are recognized and rejected at MBB and other consulting firms. If you use them verbatim, interviewers will flag template-matching within two minutes. If at all, read them to build concept awareness; don’t deploy them in interviews.
Are interviewers only evaluating my frameworks?
No. Interviewers also care about your exhibit and data interpretation, case interview math skills, and communication.
Related guides
- The complete case interview guide: how structuring fits the full skill stack
- What makes candidates succeed: the habits behind case interview offers
- Reading charts and exhibits: turning your structure into analysis
- Case interview math: the quantitative half of the case
- Brainstorming in a case: the other important structuring element in a case interview
Final word
Case interview frameworks are not something you memorize. They are a live demonstration of structured thinking, and the ones that win offers share three properties: they are broad, deep, and insightful. Build the business vocabulary underneath, drill first-principles thinking and the lenses until they are automatic, and pressure-test every structure against those three words before you present it.
That is the craft that separates the 1% who get offers from the 99% who do not. Start with StrategyCase’s Case Interview Academy, which covers structure-building, the breadth lenses, 100+ drills, and authentic cases with feedback. Build your frameworks from first principles, and memorize nothing.
About the author: Florian Smeritschnig is a former McKinsey Senior Consultant and the founder of StrategyCase. He spent five years at the firm, and has since run more than 2,200 mock case interviews and coached hundreds of candidates into McKinsey, BCG, Bain, and other top firms.
