L3VLUP
Guides/Consulting

Case Interview Frameworks, and Why Memorising Them Fails

Interviewers have heard every standard framework several thousand times. What they are listening for is whether yours was built for this problem.

By Surojit Chakraverti has hired and trained graduate analystsUpdated 19 September 202611 min read

Framework is a word that has done real damage to case preparation. Candidates learn six of them, apply the nearest one, and produce a structure that is comprehensive, generic and unusable. The frameworks are not the problem. Treating them as answers rather than as raw material is.

What a structure is for

A structure does one job: it breaks a question too big to answer into parts small enough to investigate, in a way that does not miss anything and does not double count.

That is why interviewers care about it so much. A consultant who cannot decompose a problem cannot plan a workstream, cannot brief a junior and cannot tell a client what the team is going to do. The framework is not being marked. The decomposition is.

The classics, and what each is actually good for

Standard frameworks as raw material
FrameworkGenuinely useful forWhere it goes wrong
Profitability treeAny "profits are down" caseAlmost none; this one is a real tool
Revenue = price x volumeDecomposing a revenue problemStopping there instead of going deeper
Fixed and variable cost splitCost cases and break-even workListing cost types with no sizing
Four PsPrompting on a marketing questionUsed as a whole structure; it answers nothing
Porter five forcesAssessing industry attractivenessApplied to a company problem, where it says little
Three CsA sanity check that you have not forgotten the customerPresented as a structure; it is a checklist
Value chainOperational and cost-to-serve casesReciting stages with no hypothesis
Market entry checklistPrompting on entry casesGeneric; every entry case differs on one axis

The profitability tree, which genuinely works

One framework survives contact with real cases, and it is the simplest. Profit equals revenue minus cost. Revenue equals price times volume, and volume can be broken by segment, channel, geography or product. Cost splits into fixed and variable, and each into its components.

It works because it is arithmetic rather than a taxonomy: every branch is a number, the branches sum, and testing one narrows the problem definitively. Used well, it turns a vague complaint into a located issue in about four minutes. Most cases that arrive as a profitability problem are solved by driving this tree carefully and then asking why the located issue exists.

Building a structure for the case in front of you

The alternative to reciting is a repeatable method that produces something bespoke each time. It takes about ninety seconds once practised.

  • Restate the objective as a question with a measurable answer. "Should the client enter the German market" becomes "will entering Germany earn more than the cost of capital within five years".
  • Ask what would have to be true for the answer to be yes. Those conditions are your branches, and they are automatically specific to this problem.
  • Sense-check for completeness: could the answer be no for a reason not covered by any branch? If so, add one.
  • Sense-check for overlap: could the same fact appear under two branches? If so, merge or redraw.
  • Order them by which you would test first, and say why. The ordering is where judgement shows.

A worked example

Take a case where a supermarket chain is considering launching its own delivery service. A recited framework produces market, competition, capabilities, financials, which is true of every case ever set.

The what-would-have-to-be-true method produces something else. For this to work: enough customers must want delivery and be willing to pay something towards it; the cost to serve a basket must be below the margin on that basket; we must be able to build or buy the capability without damaging the store business; and competitors must not be able to undercut us immediately. Four branches, each testable, each obviously about this decision. That is the same analytical ground covered in a structure the interviewer has not heard before.

How to use frameworks properly

Learn them, then stop presenting them. Their value is as a private checklist during the ninety seconds when you are building your own structure: a quick internal sweep for anything you have missed.

The tell that gives a recited framework away is that it fits too neatly and contains a branch you never return to. If you present four branches and only explore two, the interviewer learns that the other two were decoration, which is worse than not having mentioned them.

Common structural failures

  • Branches that overlap, so a fact belongs in two places and the analysis goes round in circles.
  • Branches that miss an obvious driver, usually the customer or the competitor response.
  • Too many branches. Six is not thorough; it is a sign you could not decide what mattered.
  • A structure with no hypothesis attached, presented and then abandoned as soon as the first piece of data arrives.
  • A structure so abstract it could be read out for any case. If it would work for a hospital and an airline and a software company, it is not a structure.

Frequently asked questions

Should I memorise case interview frameworks?

Learn them and stop presenting them. Their value is as a private checklist while you build a structure for the specific problem. Interviewers have heard each standard framework thousands of times and are listening for whether your decomposition was built for this case.

What is the best framework for a profitability case?

The profitability tree, which is the one classic that survives real use: profit equals revenue minus cost, revenue equals price times volume, volume splits by segment or channel, and cost splits into fixed and variable. It works because every branch is a number and the branches sum.

How do you build a bespoke case structure?

Restate the objective as a measurable question, then ask what would have to be true for the answer to be yes. Those conditions become your branches. Check for gaps and overlaps, then order them by which you would test first and say why.

How many branches should a case structure have?

Three or four. Six is not thoroughness; it signals that you could not decide what mattered. Every branch you present should be one you intend to explore, because a branch you never return to tells the interviewer it was decoration.

Related guides

Want this applied to your recruiting?

Reading is the easy part. For practitioner feedback tailored to your situation, work 1:1 with Suro.