Using a framework without sounding canned

Name the structure in one line, then let the facts of this particular case cut it down — and say each cut out loud.

the idea

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.

watch a framework collapse onto a case

The same thirteen-branch diagnostic tree, dropped onto three different situations. Step through and watch which branches survive.

13 branches recited (if you tour the whole framework)
0 branches actually pursued

dropped out loud: 0  ·  not yet touched: 13

how it works

  1. Name the structure once, in one line, using the situation's own nouns — "is the number real, who moved, which step broke" — not the framework's brand name.
  2. Land one specific fact that discriminates between branches. Ask for it, or use one you were given. A fact that can't kill a branch isn't worth saying yet.
  3. Prune out loud, with the reason attached. "Revenue is flat, so the demand branch is closed." The clause after so is the whole signal.
  4. Restate the question, now smaller. This is how the listener knows you're navigating rather than reciting.
  5. Size what survives before you go deep. A branch you keep should plausibly cover the gap you were handed; a branch that covers 2% of it is not the story.
  6. Spend the rest of your airtime on one or two live branches — and name the condition that would reopen a pruned one.

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.

when to use it

situationwhat naming-then-pruning buys you
open-ended metric diagnosisa 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 questionssignals you know which trade-offs are live here, not which ones exist in general
updates to an expert audiencerespects their time: they watch you skip what they already know, on purpose
the trade-offpruning 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.

watch out for

worked example

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.

check yourself

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?