Name the structure in one line, then let the facts of this particular case cut it down — and say each cut out loud.
A framework is scaffolding, not a script. It holds the shape of your thinking while you build the real answer, and then it comes down.
The canned version recites every branch at equal weight. The good version says the structure once, in the nouns of this situation, and then starts cutting as the specifics land.
Pruning is the part that reads as judgment. Nobody can tell whether you chose a branch until they hear you drop the ones beside it — and hear why.
The same thirteen-branch diagnostic tree, dropped onto three different situations. Step through and watch which branches survive.
dropped out loud: 0 · not yet touched: 13
Step 5 is where most people skip. Sizing is cheap arithmetic and it turns a plausible branch into a demonstrated one:
sizing a branch before you keep it — coffee chain
revenue 100.0 (flat vs last year)
cost of goods 30.0
of which dairy+beans 16.5
other operating costs 55.0
operating profit 15.0
dairy + beans renewed at +18% per unit
16.5 x 0.18 = +2.97 of cost
profit 15.0 - 2.97 = 12.03
change = -19.8% ~ the -20% asked about
this branch alone covers the gap -> keep it, and say so
demand branches are flat, so they cover 0.0 of it
-> drop them, out loud
Now the framework has done its job and can disappear. What the listener hears is a claim with a number behind it, not a tour of a tree.
| situation | what naming-then-pruning buys you |
|---|---|
| open-ended metric diagnosis | a shared map in fifteen seconds, then evidence-led narrowing instead of guess-listing |
| case interview (profitability, entry, sizing) | shows you can both structure and choose — the second half is what separates levels |
| domain or design questions | signals you know which trade-offs are live here, not which ones exist in general |
| updates to an expert audience | respects their time: they watch you skip what they already know, on purpose |
| the trade-off | pruning needs evidence. With no data and no domain feel, an early cut is a guess — ask the one question that settles it, or flag it as an assumption and say what it costs you if it's wrong. In a coverage-scored screen, prune fewer branches and prune them faster. |
You're asked: weekly active users are down 12% week over week; a new Android build shipped Tuesday. What's going on?
Open with the structure in one breath: "Three questions — is the number real, who moved, and which part of their week broke. And I'd start where something changed on Tuesday." That's the whole framework, spent.
Then cut. "Pipeline health is green and the WAU definition hasn't changed, so measurement is out." "iOS and web are flat and it's even across regions, so this is platform, not geography." "New installs are on trend and the loss is returning users, so it isn't acquisition or activation — it's the return trip." "Catalogue, pricing and capacity are unchanged; nothing shipped on the supply side." "Same week last year has no dip and competitor ranks are flat."
Ten branches gone in about twenty-five seconds, each with a reason attached. What's left is small enough to be useful: Android, returning users, since Tuesday's build — so you pull crash-free rate and login errors by build version and spend the remaining four minutes there. The interviewer never heard a framework. They heard someone choose.
The interviewer says: profit is down 20%, revenue is flat. Which opening sounds least canned?
You've checked and the measurement branch is clean. What's the strongest way to handle it?