Case Interview Framework: A 5-Step Method for Consulting and PM Interviews

McKinsey accepts fewer than 1 percent of applicants. BCG rejects roughly 90 percent of candidates who reach the case interview round. The failure is almost never arithmetic—it is structure. Candidates who win case interviews impose a framework on the problem in the first two minutes, state a hypothesis before they request any data, and close with a crisp recommendation rather than a list of findings. This guide walks through the five steps that separate the candidates who get offers from the ones who walk out thinking the math went fine.

Practice this out loud. Get scored in 30 seconds.

Voice mock interview with AI scoring — built because ChatGPT can chat, but can't pressure-test you or grade you.

Try the demo →

Why this matters

Consultants, PMs, and strategy analysts are hired to bring structure to unstructured problems. Not to execute a process that has already been defined—to figure out which process to apply. The case interview simulates exactly that challenge under time pressure. Interviewers at McKinsey, BCG, Bain, and top product companies are not grading arithmetic speed. They are grading whether you decompose the problem correctly, whether you form a hypothesis early and lead with it rather than gathering data aimlessly, and whether you close with a crisp 'so what' recommendation rather than a summary of what you analyzed. Candidates who skip straight to calculations demonstrate the opposite of what firms need: bottom-up, data-first thinking that produces output without a point of view. One missed step—never stating a hypothesis, or closing with 'it depends' instead of a recommendation—can flip a hire to a no-hire at the debrief. The evaluator's notes read 'no hypothesis formed' or 'never landed a clear answer,' and those notes travel to every future interview at that firm. ChatGPT can walk you through a case framework, but it cannot simulate an interviewer interrupting your structure or scoring whether your recommendation was crisp. That pressure is what Odin's AI mock sessions are built to replicate.

What to think about

  • A profitability case where you open with an Issue Tree splitting revenue decline from cost increase before pulling any numbers from the interviewer.
  • A market-sizing question where you state your approach and key assumptions out loud before calculating, so the interviewer can redirect if your structure is off.
  • A go-to-market case where you frame a hypothesis in the first 60 seconds: 'My hypothesis is that the addressable market is large enough but the go-to-market motion is wrong—let me test that.'
  • A pricing case where you structure around value-to-customer, competitive benchmarks, and cost floor before asking for any data.
  • A growth case where you issue-tree the revenue formula and then prioritize which branch to drill into based on where the client has leverage, rather than exhaustively covering everything.

The framework

Step 1 — Restate and clarify: Paraphrase the problem in your own words and ask one or two targeted clarifying questions. This shows active listening and catches any misunderstandings before you invest ten minutes in the wrong direction. Step 2 — Structure: Build an issue tree that decomposes the problem into mutually exclusive, collectively exhaustive branches—the MECE principle. Verbalize your structure or draw it on paper before you start analyzing anything. The structure is what you are being graded on more than any other single step. Step 3 — Hypothesis: Before you pull any data, state your best guess at the answer. 'My hypothesis is that this is a cost problem, not a revenue problem—let me test that.' This is what separates top-down, hypothesis-first thinkers from bottom-up data-gatherers, and it is the single trait consulting firms prize most highly. Step 4 — Analyze: Work through the highest-priority branch of your issue tree first. Ask for data, perform the math out loud, and narrate your reasoning so the interviewer can follow and redirect. Step 5 — Synthesize: Close with a crisp, one-sentence recommendation. State what the client should do, why, and what the main risk is. Do not summarize—summarizing recaps what you analyzed. Recommending says what should happen next. This distinction is the difference between a consultant and an analyst.

Common mistakes

  • Jumping into calculations before building a structure. Math without structure is data without meaning, and interviewers will interrupt or mark you down for it.
  • Skipping the hypothesis step. Saying 'let me gather more data first' signals bottom-up thinking. Top consulting firms explicitly train for hypothesis-first reasoning.
  • Treating the case like a quiz with one correct answer. Cases are ambiguous by design. The interviewer rewards your reasoning process and communication, not finding the 'right' number.
  • Exhaustively analyzing every branch of your issue tree instead of prioritizing. Identify which branch is most likely to be the problem and go there first with explicit reasoning.
  • Summarizing instead of recommending at the close. 'In summary, revenue is down 15 percent due to pricing' is a summary. 'My recommendation is to raise SMB prices by 8 percent in Q1 while protecting enterprise contracts' is a recommendation.

Bad answer vs strong answer (scored)

Weak answer

I'd look at revenue and costs. Revenue could be down because fewer people are flying or because ticket prices are lower. Costs might have gone up. I'd want to see their financial statements to understand the numbers better. Fuel costs are usually a big driver for airlines. I'd also look at what competitors are doing.

What's wrong

  • No structure is stated before diving in. The candidate lists ideas rather than building a framework, so the interviewer cannot follow the logic or redirect efficiently.
  • No hypothesis is formed. The candidate defers to 'I'd want to see the data' rather than leading with a directional view, which is the core skill being tested.
  • The close is absent. There is no synthesis or recommendation—the candidate describes a process of looking at things rather than demonstrating structured problem-solving with a point of view.

Stronger answer

Let me restate: profits are down 20 percent over two years—I want to confirm that's operating profit, not net, and whether this is industry-wide or specific to this airline. Assuming it's company-specific, I'd split the issue tree into revenue decline and cost increase. My hypothesis upfront: given that the airline industry recovered post-2022, this is more likely a cost problem—specifically fuel or labor—than a demand problem. I'll test the revenue branch first to rule it out: load factors, yield per seat, and route mix. If revenue is stable, I'll move to costs: fuel hedging, labor contracts, and maintenance. Based on what you've told me, I'd recommend we start with cost structure. What does their fuel-cost-per-ASM look like versus peers?

9/10
structure
8/10
specificity
9/10
relevance
9/10
delivery

Related practice

Quick answers

Do I need to memorize case frameworks like the 4Ps or BCG matrix?

Knowing standard frameworks as starting points is useful, but reciting a memorized framework robotically is a red flag that experienced interviewers immediately notice. The 4Ps, profitability framework, and BCG growth-share matrix are useful mental checklists, but they rarely map perfectly to any real case. Interviewers want to see you build a structure that is specific to the problem at hand, using standard frameworks as inspiration that you then customize. A candidate who builds a case-specific issue tree from first principles—even imperfectly—often scores higher than one who applies a memorized framework that does not quite fit the situation, because it demonstrates genuine structured thinking rather than pattern-matching.

How important is mental math in case interviews?

Important enough that you must be reasonably fast and accurate, but mental math is not the primary evaluation criterion and improving it should not consume most of your prep time. Rough estimates with clear, stated assumptions consistently beat precise calculations presented without a framework or structure. The key habit is to narrate your math out loud—'I'm estimating the US market at 330 million people, roughly 250 million adults, of whom maybe 15 percent have the relevant condition'—so the interviewer can follow your logic and correct your assumptions rather than just watching you calculate silently. Always sanity-check your final number: 'That gives us $2 billion, which seems plausible given the industry context.'

What's the difference between a case interview at a consulting firm versus a PM interview?

Consulting case interviews focus heavily on financial modeling, market sizing, profitability analysis, and operational recommendations. The grading is rigorous and interviewers have detailed rubrics. PM case interviews shift toward product strategy, user empathy, prioritization trade-offs, and go-to-market thinking. The 5-step framework applies to both, but the PM version weights the question 'who is the user and what do they actually need' much more heavily than pure revenue-and-cost analysis. PM interviewers also evaluate whether you can make a product decision under ambiguity without the benefit of a complete dataset—which is closer to the daily reality of the job.

Can I structure a case interview without saying the framework name out loud?

Yes—and at top firms, not naming the framework is often stronger. Saying 'I'll use the profitability framework' signals pattern-matching. Building a custom issue tree that happens to include revenue and cost branches—without announcing what it's called—signals genuine structured thinking. The interviewer cares about the quality of your decomposition, not whether you labeled it correctly. Where candidates go wrong is trying to silently apply a memorized framework without vocalizing the structure at all. Verbalize the branches: 'I'd split this into two sides—revenue drivers and cost structure—and within revenue I'd look at volume versus price.' That is a live structure, not a labeled framework, and it lands better.

How do I practice case interviews effectively?

The single best practice method is live sessions with real-time feedback—not solo reading of case books or watching YouTube walkthroughs. You need to practice speaking your structure out loud under time pressure, handling unexpected data from an interviewer who may redirect you, and synthesizing a recommendation with thirty seconds left. Solo prep builds knowledge but not the skill of thinking under pressure while communicating clearly. Odin's AI mock interviewer simulates the interactive pressure of a real case session and scores your structure, hypothesis quality, and recommendation crispness on every attempt—so you build the feedback loop that solo practice cannot provide.