Frameworks are useful for building structure, not for copying out in the interview. Memorise profitability or market-entry trees as raw material, then build a structure tailored to the specific question, because interviewers reward tailored thinking and penalise recycled templates. McKinsey's own interviewing guidance makes the same point: there is no single logical solution, and candidates should listen carefully and give tailored answers rather than standard frameworks.
Why do candidates rely on frameworks in the first place?
Frameworks lower anxiety. Facing an ambiguous business problem with a stranger watching is stressful, and a pre-built tree feels like a safety net. Classics such as profitability (revenue minus costs), the 3Cs (company, customers, competitors), Porter's Five Forces and the 4Ps all describe real drivers of business performance, so learning them isn't wasted effort.
They go wrong when the candidate uses them to avoid thinking. If a hospital asks why patient waiting times have doubled and you answer with "customers, competitors, company, product", the interviewer learns you have memorised a template and nothing about how you think.
When do frameworks genuinely help?
They are most useful in three situations:
- Recurring case types. Profitability declines, market entry, M&A screening and pricing come up often enough that a mental checklist stops you missing whole areas, for example forgetting fixed costs in a profitability case.
- The first 60 seconds of structuring. Knowing the main drivers lets you build a MECE (mutually exclusive, collectively exhaustive) tree quickly.
- Checking your own tree. Comparing your bespoke structure with a familiar framework is a quick way to find gaps before you present it.
When do frameworks hurt you?
Are you forcing the problem into the template?
The most common failure is a mismatch between the template and the question. "Should our client, a regional bus operator, launch on-demand minibuses in suburban areas?" isn't a textbook market-entry case. The real questions are about route density, driver costs, council contracts and cannibalisation of existing routes. A generic "market, competition, capabilities, financials" tree technically covers them but shows no insight.
Do your buckets overlap?
Templates stitched together on the fly often double-count. Splitting "customers" and "market demand" into separate branches usually puts the same analysis in both. Interviewers notice.
Do you sound scripted?
Experienced interviewers have heard "I'd like to look at this through four lenses" thousands of times. Delivery matters too: reading out a memorised list in the same cadence every time signals rehearsal rather than judgement.
How do you build a tailored structure instead?
Use a three-step habit:
- Restate the objective precisely. "So the question is whether the minibus service can break even within three years without reducing ridership on existing routes. Is that right?"
- Ask what has to be true. Turn the objective into the conditions for success: enough demand at a viable price, an operating cost per trip below that price, no material cannibalisation, and regulatory or council approval.
- Break each condition into testable drivers. Demand splits into the target population, adoption rate and trips per user. Cost per trip splits into driver, vehicle and dispatch technology costs.
This is a hypothesis-driven issue tree built from the client's own words. It may still cover the same ground as a framework, but it reads as bespoke, and it is.
Can you still use framework language?
Yes. Saying "fixed and variable costs" or "willingness to pay" is fine. These are just accurate business terms. The point is to put the right concepts in the right places, not to avoid particular words.
How do candidate-led and interviewer-led formats change this?
In candidate-led cases (common at BCG and Bain), your structure is your roadmap for the rest of the case, so a poor one costs you more. In interviewer-led cases (McKinsey's style), the interviewer asks a sequence of specific questions. A huge structure up front wastes time, and you will often need smaller, question-specific structures at several points. Our guide to candidate-led vs interviewer-led cases covers both formats in detail.
How should you practise moving beyond frameworks?
- Structure unfamiliar prompts. Take a news headline ("Airline cuts regional routes", "Supermarket trials checkout-free stores") and give yourself 90 seconds to build a tailored tree out loud.
- Get feedback specifically on structure. Ask your practice partner whether your buckets were MECE, whether they were specific to the problem, and whether you prioritised.
- Practise prioritisation. After presenting your structure, say where you would start and why. That single sentence separates strong candidates from template users.
An AI interviewer such as caize.ai is useful here. You can run many first-two-minute structuring drills on varied prompts and get immediate feedback on whether your tree was tailored or generic, which is hard to get from a busy human practice partner.
What does a strong answer sound like?
Take a weak opening and a strong one for the same prompt: "A UK gym chain's profits fell 20% last year."
Weak: "I'll look at revenue and costs. Revenue is price times volume, and costs are fixed and variable."
Strong: "Gym economics are driven by membership numbers, churn and average yield per member, against a largely fixed cost base of rent, staff and equipment. So I'd test three things: did we lose members or fail to replace churned ones, did yield fall through discounting or a shift to off-peak plans, and did fixed costs rise, for example energy or rent reviews? Given energy price volatility, I'd start with the cost side, but I'd like to check membership trends first because that's quick."
The second answer is still revenue minus cost underneath, but it shows industry understanding, prioritisation and judgement.
FAQ
Should I memorise any frameworks at all?
Yes. Learn the common drivers of profitability, market entry, pricing, M&A and operations so you never miss a major area. Treat them as checklists, not scripts.
Do interviewers penalise using a framework by name?
Rarely for the name alone. They penalise a structure that doesn't fit the question or that you can't explain.
What does MECE mean?
Mutually exclusive, collectively exhaustive: your buckets shouldn't overlap, and together they should cover the whole problem.
How long should structuring take?
Usually around one to two minutes of thinking time, though norms vary by interviewer. Ask for a moment to organise your thoughts. It's expected.
Is it better to have three or five buckets?
Whatever the problem needs. Three to four well-chosen buckets usually communicate better than six thin ones.
