Hypothesis-Driven Problem Solving

Branch: Structuring & Problem-Solving, the Consulting galaxy ( Yellow belt, cn-structuring) · Node CN1.02 · ~10 focused hours · Gate: quiz ≥ 85% + mapped case

Picture two teams handed the same brief. A client's flagship product line is losing margin, and the client wants to know why, in two weeks. Team Alpha spends the first four days pulling every dataset the client has: five years of transactions, every SKU, every region, every channel. Then it starts building a model big enough to explain anything. Team Beta spends the first four hours on the phone and with the trial balance. It forms a single sentence it believes is probably the answer, writes down what evidence would prove that sentence wrong, and spends day one running the cheapest test that could kill it. By day three, Team Beta has an answer, a dated confidence level, and a lean, targeted analysis that took a fraction of the effort. Team Alpha, three days later, is still building. When they finally land, the two teams reach the same conclusion. One of them got there for a tenth of the cost, days earlier, and never once looked less rigorous for it. You're going to learn to be Team Beta, on purpose, every time.

The whole method is short enough to say out loud, and you'll spend ten hours learning why it holds. You don't analyze your way to an answer. You guess the answer on day one, and then you spend every hour after that trying to kill your own guess. That sounds backwards if you were trained to link rigor with exhaustiveness. Surely a real analyst gathers the facts first and lets the conclusion emerge? In an academic setting with unlimited time, perhaps. A client engagement runs on a fixed clock and a fixed budget, and there that instinct is a failure to prioritize dressed up as rigor. The MECE issue tree you've already built maps every possible explanation for a problem, the entire space of "it could be this." Hypothesis-driven problem solving is what you do with that map. You bet on which region of it holds the real answer, and you state the bet in a form that can be proven wrong. Then you spend your scarce hours trying hard to prove yourself wrong. A hypothesis that survives a serious attempt to kill it is worth vastly more than one you never really tested.

You'll come away with four tools that work as one system. The first is the day-one hypothesis, a testable bet that is neither a guess nor a framework recital. The second is the driver tree and its bridge, the arithmetic that turns "I think it's the input costs" into a number you can defend. The third is the minimum killing analysis: run the cheapest test that could prove you wrong before you run anything expensive. The fourth is the one-day answer and ghost deck. You always hold a current, provisional point of view, and you sketch the shape of your final answer before you have the evidence, so the analysis you run is the analysis you need. Hold all four together and you have the standing defense against boiling the ocean, the most common and most expensive failure in this line of work. Everything downstream is this same cycle run faster, under pressure or on higher stakes: case interviews under a stopwatch, commercial due diligence, the partner capstone. Learn it once, here, at a pace where you can see every step.

Learning objectives

By the end you can:

1. Explain, from first principles, why hypothesis-first problem solving reaches better answers faster than exhaustive research-first approaches on a fixed-time, fixed-budget engagement, and state the module's core discipline in one sentence.
2. Form a testable, falsifiable day-one hypothesis from limited information (a client conversation, pattern-matching against analogous situations, a quick first data pull, or an industry base rate), and state its kill criterion before you analyze anything.
3. Distinguish a driver tree from an issue tree, build both additive and multiplicative driver trees for a given metric, and know which form applies to which kind of decomposition.
4. Decompose a period-over-period change in a driver-tree metric into a full three-term bridge (a base-price/base-volume effect, an incremental effect, and an interaction/mix term) by hand, verify that the three terms reconcile exactly to the actual change, and correctly interpret the interaction term's sign.
5. Design the minimum killing analysis for a hypothesis: rank candidate analyses by directness and cost/time, and choose the cheapest test that could kill the hypothesis first, before reaching for anything slower or more elaborate.
6. Produce and defend a one-day answer (a current, dated, falsifiable best-answer stated in one sentence with an explicit confidence level) and update it as evidence arrives, without treating it as either a final verdict or an excuse to withhold judgment.
7. Build a ghost deck: reverse-engineer a lean workplan from a hypothesized answer, and apply the guardrails that keep it a private planning tool rather than a source of anchoring bias.
8. Recognize the symptoms and root causes of boiling the ocean, and apply the four-tool discipline (hypothesis, driver tree, minimum killing analysis, ghost deck) as the standing defense against it.
9. (Productivity objective.) Use an AI assistant to accelerate drafting a first-pass hypothesis list, driver tree, or ghost-deck skeleton, while keeping the prioritization, the kill-test judgment, and every final number your own, verified against a primary or client source. AI proposes; you dispose.

Prerequisites & connections

Builds on. CN1.01 (Issue Trees & MECE) is the direct foundation. The issue tree maps every possible explanation for a problem, built MECE. Here you learn what to do with that map: bet on which region holds the answer, and test it fast. Read CN1.01 first if you haven't. CN0.01 (The Consulting Mind) supplies the six-stage engagement cycle this method lives inside. You'll be working at its prioritize and analyze stages. Those six stages run define, structure, prioritize, analyze, synthesize and recommend. CN0.01 also gives you the galaxy's honest-scope framing. If you've already run E11.03 (The Consulting Case-Interview Lab), the Cycle-2 taster, you'll recognize the one-line version: its objective on hypothesis-first structuring gave you a compressed, interview-length version of the same method. This page is the deep, MBB-partner-depth expansion of that one line, and it doesn't repeat the taster. You get real bridge mathematics with the interaction/mix trap made explicit, the ghost deck, the one-day-answer rhythm, and a diagnosis of why teams boil the ocean. From the Finance galaxy, M4.01/M4.02 (business-model anatomy and unit economics) supply the vocabulary your driver trees decompose into. The seventeen sector playbooks in M5.01–M5.10 hold the industry base rates that make a hypothesis credible instead of arbitrary. Cross-link them, because sector economics isn't re-taught here.

Feeds forward. CN1.03 (The "So What": Synthesis & the Answer-First Storyline) takes the hypothesis you've confirmed, refined or replaced, plus its evidence, and turns it into Minto's pyramid, which runs from the governing thought down through the key line to the support. M10.03 teaches Minto's Pyramid Principle in full. The work here deliberately stops at "a validated point of view with evidence" and never reaches a polished client storyline. That hand-off is spelled out wherever the two could be confused. The one-day answer and ghost deck are private working tools and aren't client-ready output. CN2.01–CN2.04 (casing) reuse this entire cycle under a stopwatch. A case interview is this method compressed to thirty minutes, and the mapped Case-Engine case, CC-PROF-02 (SkyBridge Airways Route P&L), is a profitability case built on the same bridge logic. CN3.03 deepens the diagnose-before-prescribe stance you start with here, citing Rumelt directly. CN5.01/CN5.03 apply the same method to due diligence, where the hypothesis is a deal thesis and the kill test is a piece of commercial due diligence. CN6.01 hypothesizes about deal value the way you'll learn to hypothesize about a metric's movement. CN7.03 (Partner Capstone) asks you to run this entire cycle, unaided, under time, on a company you've never seen.

Core teaching content

The bridge: turning a driver tree into a change decomposition

Once you have two periods of data, the driver tree becomes a bridge, also called a waterfall. It splits the change in the metric into the part attributable to each driver. For an additive tree that's trivial and exact, as you've just seen. A multiplicative tree is the common case, since Price × Volume is the atom of almost every profitability question, and there the arithmetic needs care. A naive approach hides an error without telling you.

Take Revenue = Price × Volume. Call the base period P0, V0 and the new period P1, V1, so ΔP = P1 − P0 and ΔV = V1 − V0. The true change in revenue is ΔR = P1V1 − P0V0. It's tempting to call the volume effect ΔV × P0 and the price effect ΔP × P0, both against the base period, and simply add them. That sum doesn't match the true ΔR. The shortfall is ΔP × ΔV, the interaction term (or mix effect). Price and volume didn't move in isolation. They moved together, each against the other's new value, and that joint movement is a real economic effect you can't wave away as rounding. The complete decomposition is exact and always true by algebra:

ΔR  =  (P0 × ΔV)   +   (V0 × ΔP)   +   (ΔP × ΔV)
        volume        price          interaction
        effect        effect         / mix term

Each of the first two terms holds one driver's change at the other driver's base-period value. The third term is the piece left over when both drivers moved at once. Together the three always reconcile exactly to ΔR, with nothing hidden. Check it once for yourself on any numbers and you'll trust the formula for life. Two clean worked examples do that below (Worked Examples 1 and 2), one in India ₹ and one in US $.

Watch out for a shortcut that looks fine. It computes only two terms: "volume effect at base price" plus "price effect at new volume" (V1, not V0). That version also reconciles exactly to ΔR, and that's what makes it dangerous. It looks just as rigorous, but it has folded the entire interaction term into the price-effect number by using the new volume in place of the base one. Whichever variable you compute "second", using the other's new value, absorbs the whole interaction. That's a real distortion and more than a matter of style, since it changes which lever gets the credit or the blame. The fix is to always compute and disclose the interaction term as its own line, so nothing gets absorbed. That's the professional convention you're learning here, and your mapped case will grade you on it.

The sign of the interaction term is a diagnostic in its own right. When price and volume move in opposite directions, the ordinary downward-sloping-demand pattern, the interaction term is always negative, since it's a positive times a negative. A large negative interaction isn't noise. It says the volume change was concentrated at the new price level, which tells you something about how price-sensitive the lost or gained volume really was. When price and volume move in the same direction, the interaction is positive. That's the unusual case, and it's worth a second look. It might be a real premiumization success, or a sign that the data is miscategorized. Either way, a positive interaction should make you stop and ask why.

The minimum killing analysis

You now have a sharp, falsifiable hypothesis and the arithmetic to test it. The next question is a different one. Of every analysis you could possibly run to test this hypothesis, which one should you run first? The answer is never "the most thorough one." It's the cheapest analysis that has a real chance of killing the hypothesis, and it has a name: the minimum killing analysis.

Think of it as a differential diagnosis. A competent doctor facing a patient with several plausible conditions doesn't order the most expensive, invasive test first "to be thorough". They order the cheap, fast, common test that would rule the likely condition in or out, and they escalate only if that test is inconclusive. A consulting engagement runs on the same logic. Cheap, fast, high-directness tests come first. The expensive, slow ones run only if you really need them.

Two properties determine whether a candidate analysis deserves to go first:

• Directness: does this analysis test the hypothesis itself, or only something next to it? A test that could kill your specific claim outranks one that would merely be "interesting context." Say your hypothesis is about a stockout in one category. A regression on macro traffic trends is interesting, but it isn't direct. Even a perfect answer to "how did traffic move" wouldn't confirm or refute "was footwear specifically out of stock."
• Cost/time: how many hours or days does the analysis take? And how much of that is marginal, a fresh pull the client's own systems could produce this afternoon, against a whole new undertaking such as a survey, a bespoke model or a dataset the client doesn't already hold?

A simple heuristic helps here, as a guide for judgment and never as a rigid formula. Rank candidates by directness divided by time, and start with whichever high-directness, low-cost tests you can run in parallel today. Escalate to slower or less direct options only if the fast ones come back inconclusive. Worked Example 3 runs this ranking on a full table of candidate analyses, in US $. Every expert takes the larger point to heart. Exhaustiveness isn't evidence of rigor, and a well-aimed attempt to kill your own claim is. A team that ran one cheap, sharp test and updated its answer did better work than a team that ran twenty expensive tests and never once asked which of them could prove it wrong.

The ghost deck: reverse-engineering the workplan from the hypothesized answer

Once you have a one-day answer, you can do something powerful with it before a single further hour of analysis. Sketch what the final output would look like if your hypothesis turns out to be true. That sketch is the ghost deck, also called a skeleton deck, dummy deck or pinboard. It's a small set of placeholder slides. Each one carries a headline stated as an answer and never as a topic, a rough description of the exhibit that would prove that headline, the data source needed to build it, and the person who owns pulling it.

A ghost-deck slide isn't "Slide 3: Cost Analysis". That's a topic label, and it's useless because it commits to nothing that could be wrong. A real one is closer to "Slide 3: Input costs for the top 2 SKUs rose ~9% while list prices rose only ~4%, opening a 500bp margin gap ([placeholder bar chart, illustrative until real data lands]) data needed: 8 quarters of purchase-order pricing by SKU: owner: [name], due [date]." That single sentence is the workplan. It tells the team what analysis to run, on what data, and by whom, because the slide can't be filled in any other way. Reverse-engineer the rest of the workplan like this, one ghost slide per major claim the hypothesis needs to support, and you'll move far faster than you would from a blank page.

Two guardrails keep the ghost deck a speed tool and stop it turning into a trap. The first is that its numbers are placeholders, so mark them as such. A ghost deck is never shown to a client with invented figures presented as real. It's an internal planning artifact, full stop. The second is subtler: a killed ghost slide is a success. Say real data doesn't support the input-cost story. The team hasn't wasted the effort. It has eliminated a branch fast and cheaply, which is what the minimum killing analysis is supposed to do. The right response is to redraw that slide against the next-most-likely hypothesis and stop looking for a way to save the original story. A team that treats its own ghost slides as sacred has simply moved confirmation bias into a prettier format.

{
  "skill": "Sketching a ghost-deck skeleton fast so the team's actual analytical hours go exactly where the hypothesis needs them",
  "use": "Have a chat assistant draft placeholder headlines and exhibit shapes for 3-4 ghost-deck slides that would need to be true if your day-one hypothesis holds, so you get a fast first skeleton to critique, cut, and reassign, rather than starting from a blank page.",
  "tools": ["Chat assistants — Claude, ChatGPT, Gemini", "Slide/outline drafting tools that turn a bullet list into a placeholder deck shape"],
  "prompt": "My day-one hypothesis is: <HYPOTHESIS>. Draft 3-4 ghost-deck slide headlines that would each need to be true for this hypothesis to hold, each stated as a specific, falsifiable claim (not a topic label). For each, suggest a rough exhibit shape, the data source that would be needed to build it, and mark every number as an illustrative placeholder, not a real figure.",
  "verify": "An AI-drafted ghost deck can smuggle in a plausible-sounding 'placeholder' number that quietly anchors your team before you check anything — treat every suggested figure as fictional until real data replaces it, and never let a slide's fluency stand in for evidence. When real data lands, trace it to the client's own systems or a named primary source, match its scope/period/unit to the claim, recompute anything derived, and cite it (Guardrail 1-5) before the slide leaves 'ghost' status.",
  "diy": "You must already be able to state, unaided, what a testable slide headline looks like versus a topic label, and you must own the judgment of when a killed ghost slide means 'redraw' rather than 'defend' — that discipline is this section's entire point.",
  "market": "US"
}

Putting the cycle together

The five tools aren't run once, in sequence, and then abandoned. They form a loop that repeats, tightening each time, until the evidence is strong enough to hand off to synthesis:

Client problem statement
        │
        ▼
Issue tree (CN1.01, MECE)  ──  the full space of possible explanations
        │
        ▼
Day-one hypothesis  ──  pick the most credible branch(es); state a kill criterion
        │
        ▼
Driver tree / bridge  ──  quantify the claim; isolate which lever actually moved
        │
        ▼
Minimum killing analysis  ──  run the cheapest test that could kill it, first
        │
   ┌────┴────┐
   ▼         ▼
KILLED     SURVIVES
   │         │
   ▼         ▼
pick the   state/update the one-day answer (dated, falsifiable, confidence stated)
next            │
branch          ▼
   │       ghost deck  ──  reverse-engineer the remaining lean workplan
   │            │
   └─────┬──────┘
         ▼
repeat the loop at every team huddle until evidence is synthesis-ready
         │
         ▼
hand off to CN1.03 (governing thought → pyramid → client recommendation)

Two things about this loop are worth holding onto. First, it really is a loop. Most hypotheses survive their first kill test in modified form instead of dying whole. When that happens, refine the hypothesis and run the cycle again. Don't declare victory on a technicality. Second, the loop gets faster with repetition, because each pass eliminates a branch and sharpens the team's read on the business. A hypothesis-driven team's second and third passes move noticeably quicker than the first. A research-first team's effort keeps costing the same flat rate all the way through.

Common mistakes & how experts think differently

1. Treating the hypothesis as something to defend, not something to kill. The beginner falls in love with the first plausible story and spends the engagement finding evidence for it. The expert treats a hypothesis as a target. The most valuable thing you can do with a claim is find the fastest, cheapest way to disprove it, and a claim that survives real attempts to kill it earns trust because it was attacked.
2. Forming an unfalsifiable hypothesis. "Margins are down because of market conditions" or "the industry is changing" can't be tested by any analysis, because no observation could ever contradict them. On hearing any hypothesis, their own included, the expert asks straight away: what would prove this wrong, specifically, and how would I find that out? If no answer comes quickly, the hypothesis isn't sharp enough to use yet.
3. Confusing an issue tree with a driver tree. The beginner builds a beautiful MECE list of qualitative possible reasons and calls the exercise "quantified" because it looks structured. The expert knows a driver tree hasn't been built until an actual number (a price, a volume, a rate) sits at every leaf. Until then, nothing has been measured.
4. Hiding or ignoring the interaction term. A two-term bridge that folds the cross-effect into whichever lever was computed second makes that lever look bigger or smaller than it really is. And when the interaction is the story, skipping it means missing the actual explanation. Worked Examples 1 and 2 both show it as a large share of the total change. The expert always computes all three terms and states the interaction's sign and size out loud.
5. Running the expensive analysis first because it feels more rigorous. Commissioning a survey or a bespoke model before pulling data the client's own systems already hold is the most common avoidable delay. The expert ranks candidates by directness against cost/time and runs the cheap, direct ones first, in parallel, before escalating.
6. Getting the one-day answer wrong in either direction. Some teams defend a provisional answer past the point the evidence justifies, which is premature conclusion. Others refuse to state any position "until the analysis is done", which is paralysis dressed as humility. The expert holds a dated, falsifiable, confidence-scored one-day answer throughout and updates it, cheerfully, the moment good evidence says to.
7. Polishing the ghost deck until it becomes a real deliverable, then quietly stopping testing it. Once placeholder numbers look plausible, the team can start defending the ghost deck instead of interrogating it. That's confirmation bias moved into a prettier format. The expert marks ghost-deck numbers as illustrative and treats a killed ghost slide as a cheap win.
8. Wearing "I looked at everything" as a badge of rigor. Exhaustiveness isn't evidence of quality work. Often it's evidence of a missing hypothesis to prioritize against. When an expert hears "we looked at everything", admiration isn't the response. A question is: "what did that buy you that a sharper hypothesis wouldn't have told you for a tenth of the cost?"
9. Running the cycle once and then executing on autopilot. A team that forms a day-one hypothesis, tests it once, and never revisits its one-day answer as new evidence arrives has turned a living method into a one-time ritual. The expert treats every team huddle as a fresh pass through the loop. Does the evidence gathered since we last spoke still support today's one-day answer, or does it need to change?

Run through all nine and one thread shows. The expert never confuses effort with evidence, confidence with correctness, or a polished-looking claim with a tested one. The four tools (hypothesis, driver tree, minimum killing analysis, ghost deck) exist so that judgment doesn't have to lean on willpower alone to catch these failures in the moment.

Worked examples

Worked example 1: Forming and stress-testing a day-one hypothesis (India, ₹)

A mid-sized Indian consumer-durables company, Amba Home Appliances (synthetic), reports that gross margin on its flagship mixer-grinder line has fallen roughly four percentage points over the last two quarters. The client's operations head mentions, almost in passing, that "our aluminium and copper costs have been all over the place lately." Your issue tree for "why did gross margin fall" has five MECE branches. They are input-cost inflation, a price cut or unabsorbed discounting, an unfavorable shift in product mix (more of the lower-margin variant selling), a one-off write-off, and a change in manufacturing yield or wastage. You have one afternoon before the next client call.

Solution. Step 1. Form the day-one hypothesis. The operations head's comment is a real signal, and its source is client intuition. Commodity-input volatility is also a well-known driver of margin swings in small-appliance manufacturing. That's an industry base rate, the kind of fact the sector playbooks would sharpen further. Put the two together into a specific claim: "the margin decline is driven primarily by input-cost inflation in aluminium and copper outpacing the price increases actually taken on the flagship SKU, not by discounting, mix shift, a one-off, or a yield problem."

Step 2. State the kill criterion before doing anything else. When you pull the actual purchase-order data, this hypothesis dies if input costs for these two commodities turn out to have risen no faster than the price increases the company took over the same period. Whatever moved margin, it wasn't this. Notice that the hypothesis also narrows the issue tree without saying so. It predicts the other four branches (discounting, mix, one-off, yield) contributed little, which gives you four secondary things to sanity-check quickly. You don't need to go deep on them.

Step 3. Guard against confirmation bias, on purpose. You expect the input-cost data to confirm the story. Before you pull it, spend five minutes looking for the fastest way to kill it. First, check whether the company took any price increase at all in the period. If the price line never moved, the interaction with cost inflation would look different than assumed. Second, glance at the discounting and promotions calendar. A quiet increase in trade discounts could produce an identical margin symptom with a completely different cause.

Read it. Notice what this hypothesis isn't. It isn't "there are several possible reasons for the decline", which is unfalsifiable and useless. Nor is it a demand to research all five branches equally, the ocean-boiling instinct it's there to prevent. It's one specific, testable sentence, with a kill criterion stated before the confirming data was ever pulled. Worked Example 2 tests it with real numbers.

Worked example 2: Testing the hypothesis with the three-term bridge (India, ₹)

Back to Amba Home Appliances. To test the hypothesis from Worked Example 1 directly, you pull eight quarters of purchase-order pricing and sales data for the flagship mixer-grinder SKU. Compare the base quarter with the current one. List price rose from ₹120 to ₹135 per unit, so a price increase was taken, contrary to one of your disconfirming checks. Unit volume fell from 50,000 to 42,000, a real drop. A plausible reason is that the price increase pushed some price-sensitive buyers to trade down to a competitor's cheaper model.

Solution. Step 1. Set up the bridge. P0 = ₹120, V0 = 50,000; P1 = ₹135, V1 = 42,000. Base revenue is R0 = 120 × 50,000 = ₹60,00,000 (₹60 lakh), and new revenue is R1 = 135 × 42,000 = ₹56,70,000 (₹56.7 lakh). The actual change is ΔR = 56,70,000 − 60,00,000 = −₹3,30,000. Revenue on this SKU fell by ₹3.3 lakh despite the price increase, because volume fell faster than price rose.

Step 2. Compute all three terms. ΔP = 135 − 120 = 15; ΔV = 42,000 − 50,000 = −8,000. The volume effect is = P0 × ΔV = 120 × (−8,000) = −₹9,60,000. The price effect is = V0 × ΔP = 50,000 × 15 = +₹7,50,000. The interaction is = ΔP × ΔV = 15 × (−8,000) = −₹1,20,000. Now check the reconciliation: −9,60,000 + 7,50,000 − 1,20,000 = −₹3,30,000, which matches ΔR exactly.

Step 3. Read what the arithmetic says. If volume had held steady, the price increase alone would have added ₹7.5 lakh, so it didn't fail on its own terms. The volume decline alone cost ₹9.6 lakh at the old price. The negative ₹1.2-lakh interaction isn't noise. Price and volume moved in opposite directions, so the interaction is mechanically negative. Its size, roughly a third of the price effect, says the volume loss was concentrated among buyers reacting to the new, higher price. That's a real elasticity signal.

Read it. This kills the pure "input costs, full stop" version of the hypothesis from Worked Example 1. The price increase was real and did not fully absorb the cost inflation. But a meaningful share of the margin story is now a volume and elasticity effect that the price increase itself triggered. So you're looking at a refinement more than a full kill. The next move is to refine the hypothesis and check whether the input-cost side still holds, which is the loop described at the end of the core teaching.

Worked example 3: Ranking the minimum killing analysis (US, $)

Bramwell Outdoor Co. (synthetic), a US specialty outdoor-gear retailer, reports same-store sales down 6% this quarter. Your day-one hypothesis comes from a five-minute call with the VP of Merchandising: "the decline is concentrated in the footwear category and is driven by a stockout problem in roughly a quarter of stores, not by a broader decline in customer traffic." Here's the kill criterion. If footwear in-stock rates are normal and the sales decline is spread evenly across categories and stores, the hypothesis is dead. Four candidate analyses are on the table.

Solution. Step 1. Lay out the candidates with directness and cost.

Step 2. Rank by a directness-to-time heuristic, then apply judgment. Score directness from 1 to 5 (A=5, D=3, B=2, C=2) and divide by days. A scores 5 ÷ 0.5 = 10 and D scores 3 ÷ 0.25 = 12. C scores 2 ÷ 10 = 0.2 and B scores 2 ÷ 15 ≈ 0.13. D and A are both far ahead of B and C. A and D are independent and cheap, and both go straight at the same hypothesis, so run them in parallel today. Don't mechanically pick "the single highest score" and stop.

Step 3. Decide when, if ever, to escalate. Suppose A and D both support the stockout story with a plausible magnitude. Then the hypothesis has survived a real, cheap kill attempt. You don't need B or C. Running them anyway "to be thorough" is the ocean-boiling instinct in its purest form. If A and D come back against the story, the hypothesis is dead, and only then is a broader-traffic explanation worth its cost.

Read it. The heuristic is a starting point for judgment and doesn't replace it. The two cheap, direct tests that can run in parallel should almost always go first, whatever small gap separates their scores. Hold the expensive tests in reserve, and trigger them only when the cheap ones give an inconclusive result.

Worked example 4: Building a ghost deck around a route-profitability bridge (US, $)

TransCoast Air (synthetic) operates a Denver–Austin route that has been losing money. After a short call with the route-planning team, you form this day-one hypothesis: "the route's revenue decline is driven mostly by a fare increase that triggered a larger-than-expected passenger drop, not by a change in the competitive schedule." The kill criterion works two ways. If passenger volume held roughly steady despite the fare change, or a competitor added capacity on the same route at the same time, the hypothesis is dead or needs a rival explanation. Quarter over quarter, average fare rose from $210 to $225 and passengers fell from 18,000 to 16,500.

Solution. Step 1. Run the bridge first, so the exhibit is real. P0 = $210, V0 = 18,000; P1 = $225, V1 = 16,500. R0 = 210 × 18,000 = $37,80,000... written the US way, R0 = $3,780,000, and R1 = 225 × 16,500 = $3,712,500. ΔR = 3,712,500 − 3,780,000 = −$67,500. ΔP = 15; ΔV = −1,500. The volume effect is = 210 × (−1,500) = −$315,000. The price effect is = 18,000 × 15 = +$270,000. The interaction is = 15 × (−1,500) = −$22,500. Check: −315,000 + 270,000 − 22,500 = −67,500, which matches ΔR exactly.

Step 2. Build the ghost deck around this exhibit. Before the full analysis is finished, sketch three slides. Each headline is a claim the eventual data must support or kill:

Step 3. Apply both guardrails. Every number above comes from the Step 1 bridge you've already finished, so it's real. The exceptions are Slides 2 and 3. Their exhibits are marked "to be built" until the booking-class and competitor-schedule data arrive, and they stay placeholders, never shown to a client as they are. And if Slide 3's data shows a competitor did add capacity, that slide gets killed and redrawn. Nobody defends it. The team treats the news as new information earned cheaply and doesn't see it as a threat to the story.

Read it. The mapped Case-Engine case for this topic, SkyBridge Airways Route P&L (interviewer-led, US, profitability format), runs this same route-bridge logic on a full P&L with more drivers, while a live interviewer pushes back on your prioritization. This worked example is your by-hand rehearsal for that skill, at a scale you can check with a pencil.

Worked example 5: The one-day answer, done badly and done well (India, ₹)

Kavach Logistics (synthetic), a mid-sized Indian B2B trucking and warehousing company, has seen customer churn tick up over the last two quarters. The CEO wants to know why before the next board meeting, three days away. Your team has a day-one hypothesis: a service-reliability problem concentrated among mid-size shippers. It has also run one minimum killing analysis, a quick pull of on-time-delivery rates by customer segment. That pull shows mid-size-shipper on-time performance down 11 points while large-account performance is flat. The engagement manager asks: "where are we, if I had to tell the CEO right now?"

Solution. Step 1. A bad one-day answer, and why it fails. "We're looking at a few different angles, service levels, pricing, competitor activity, and should have a clearer picture soon." That's the paralysis failure mode. It commits to nothing, states no confidence level and names no evidence, and it could have been said on the first day of the engagement or the last. It fails the elevator test completely, because the doors would close before the CEO learned anything usable.

Step 2. An equally bad one-day answer, in the opposite direction. "Churn is definitely being caused by service failures with mid-size shippers, we're confident, no need to look further." Here you've got the premature-conclusion failure mode. It treats one cheap, directionally supportive data pull as if it were a completed investigation, and it states false certainty. It also shuts down the very next question a good CEO would ask. Is 11 points actually large enough to explain the churn rate observed? And could something else, such as a competitor's price cut aimed at that same segment, be operating alongside it?

Step 3, the one-day answer that passes the elevator test. "Our current best read, at roughly 70% confidence: churn is concentrated in mid-size shippers and tracks an 11-point drop in on-time delivery for that segment over the same period, a real, sizeable gap. We haven't yet ruled out a competitor pricing move hitting the same segment at the same time, and we'll know by Thursday once we've pulled the win/loss notes from sales. If that shows competitor pricing as the bigger factor, we'll revise this." This states a specific claim, a confidence level, the evidence behind it, the explicit thing that would change it, and a date.

Read it. The third version doesn't rest on "more research" than the first two. It uses the same evidence the team already had in hand at that moment. The gain comes from the habit of stating a position, at a stated confidence, with a stated update trigger. That habit keeps a three-day-old investigation from either freezing or overclaiming.

Worked example 6: Ocean-boiling, quantified (US, $)

Go back to Bramwell Outdoor Co. and its 6% same-store-sales decline from Worked Example 3. Two synthetic teams get the same brief, three weeks apart, with no contact between them, so you can see how differently one problem can be worked.

Solution. Step 1. Team Alpha's path. Team Alpha (three analysts) spends two weeks building an all-inclusive regression model across all 200 stores and twelve merchandise categories. It folds in weather, unemployment and competitor store-opening data, on the theory that "we should understand everything before we conclude anything." After four weeks and roughly 3 analysts × 4 weeks × 40 hours = 480 person-hours, the headline finding is that the decline is "concentrated in footwear, in stores where in-stock rates fell". That's real, but it surfaced only through the full, everything-included model.

Step 2. Team Beta's path. Team Beta (two analysts) spends thirty minutes forming the same footwear-stockout hypothesis from Worked Example 3. It runs the two cheap, direct tests in parallel over day one and confirms the pattern by day two. Days three and four go on building the bridge and the client-ready exhibit. Total effort: roughly 2 analysts × 4 days × 8 hours = 64 person-hours.

Step 3. Compare the outcomes, not just the effort. Both teams reach the same substantive conclusion. Team Alpha spent 480 ÷ 64 ≈ 7.5× the effort for an answer delivered three and a half weeks later. The part that stings is that its all-inclusive model is no more actionable than Team Beta's targeted one, since both point at the same fix. The extra four hundred-plus hours bought polish and false thoroughness. They didn't buy better decisions.

Read it. This is boiling the ocean made concrete and countable. Team Alpha didn't fail for lack of skill. It was missing a hypothesis to prioritize against, so every category and store looked equally worth modeling. Team Beta had the tools you've been learning: a sharp hypothesis, a ranked minimum killing analysis, and the willingness to stop once the diminishing-returns test said to. The rest of the consulting work assumes you can be Team Beta on demand, and the case in your Mastery check will time you on it.

Practice set

Work each problem fully before you read its solution. Bridge problems reconcile exactly, so check your arithmetic against the stated total before moving on. All companies are synthetic and illustrative unless stated otherwise.

P1 (guided). The one-sentence discipline. State the core method you've learned here in one sentence. Then explain, in one more sentence, why it's more rigorous than gathering all the facts before concluding anything.

Solution. You guess the answer on day one, in a testable form, and then spend every hour after that trying to kill your own guess. It's more rigorous because a hypothesis you've tried hard to disprove, and which survived, has been tested. A conclusion that merely "emerged" from exhaustive, unprioritized research was never stress-tested against a stated alternative. It's far more likely to end up reflecting whatever the researcher expected to find.

P2 (guided). The three-term bridge by hand. A consulting firm's staffing arm bills an hourly rate that rose from $80 to $85, while billed hours fell from 500 to 460 over the same period. Compute the volume effect, the price (rate) effect and the interaction term, and confirm they reconcile to the actual change in revenue.

Solution. R0 = 80 × 500 = $40,000; R1 = 85 × 460 = $39,100; ΔR = −$900. ΔRate = 5; ΔHours = −40. Volume effect = 80 × (−40) = −$3,200. Rate effect = 500 × 5 = +$2,500. Interaction = 5 × (−40) = −$200. Check: −3,200 + 2,500 − 200 = −900, matching ΔR. Reading it: the rate increase alone would have added $2,500, and the volume loss alone cost $3,200. The negative $200 interaction confirms the small decline in hours was mildly concentrated at the new, higher rate.

P3 (guided). Issue tree or driver tree? A client says "our customer churn is up, is that a segmentation issue, a pricing issue, a product issue, or a service issue?" Decide whether this is an issue tree or a driver tree, and say what you'd need to add to turn it into the other.

Solution. It's an issue tree: a qualitative, MECE list of possible reasons churn rose, with no arithmetic anywhere in it yet. To turn it into a driver tree, you'd decompose the metric itself algebraically, e.g. Churned customers = Customers at risk × Churn rate, or Revenue lost to churn = Churned customers × Average revenue per customer. Then an actual number sits at each leaf, and you can attribute a change in the metric to a specific, measured driver.

P4. Sharpening an unfalsifiable hypothesis. A junior analyst proposes: "our profits are down because the market has gotten tougher." Explain why this fails as a day-one hypothesis, and rewrite it as one that would pass.

Solution. It fails because no observation could ever disprove it. "The market got tougher" can absorb any result, so it has no kill criterion and points to no specific analysis. A passing rewrite narrows it to something testable: "profits are down because our top competitor's price cut six months ago pulled volume away from our mid-tier product line specifically, not because of a broad market-wide decline." This version dies cleanly if volume losses turn out to be spread evenly across all product tiers and competitors. The hypothesis predicts they'll be concentrated.

P5. The bridge, India ₹, a price cut that grew revenue. A regional Indian snack brand cuts its ₹80 SKU to ₹76, and volume rises from 20,000 to 23,000 units over the same period. Compute all three bridge terms and the net revenue change. Then explain in one sentence what the interaction term's sign tells you here.

Solution. R0 = 80 × 20,000 = ₹16,00,000; R1 = 76 × 23,000 = ₹17,48,000; ΔR = +₹1,48,000. ΔP = −4; ΔV = +3,000. Volume effect = 80 × 3,000 = +₹2,40,000. Price effect = 20,000 × (−4) = −₹80,000. Interaction = (−4) × 3,000 = −₹12,000. Check: 2,40,000 − 80,000 − 12,000 = 1,48,000. The interaction is negative because price and volume moved in opposite directions, price down and volume up, which is the ordinary pattern. Its size says part of the extra volume came in specifically at the new, lower price, so the whole gain isn't "free."

P6. Ranking kill tests. You have three candidate analyses for a hypothesis: (A) a 1-day pull from the client's own CRM, directness 4/5; (B) a 4-week third-party market study, directness 5/5; (C) a half-day call with the sales director, directness 3/5. Rank them using directness ÷ days. Then say which you'd actually run first and why, which isn't simply "the highest score".

Solution. Scoring gives A = 4 ÷ 1 = 4, B = 5 ÷ 20 = 0.25 (4 weeks ≈ 20 business days) and C = 3 ÷ 0.5 = 6. The ranking is C, then A, then B. Run C and A in parallel today. Both are cheap and reasonably direct, and nothing stops you doing both at once, so there's no reason to wait on C alone just because its score is highest. B has the highest raw directness, but you hold it back for later and use it only if C and A together are inconclusive.

P7. Critiquing a one-day answer. A teammate offers this one-day answer: "We think it's probably a few things combining, but we want to run more numbers before saying anything definite." Name the failure mode, then rewrite it as a passing one-day answer using this evidence: a client's regional sales are down 9%, and one region, accounting for 60% of the shortfall, recently lost its top two sales reps.

Solution. The failure mode is paralysis. The answer commits to nothing, states no confidence and cites no evidence, so it fails the elevator test. A passing rewrite: "Current best read, ~65% confidence: the 9% regional shortfall is mostly (roughly 60% of it) attributable to one region's loss of its top two sales reps; we'd revise this if the remaining reps' pipeline in that region turns out to be healthy once we pull it, which we'll have by Wednesday."

P8. Sketching a ghost-deck slide. Your hypothesis: "a SaaS company's revenue dip is driven by a pricing-page redesign that increased churn among small accounts, not by a competitor's product launch." Sketch one ghost-deck slide (headline, placeholder exhibit, data needed, owner) that would need to be true for this hypothesis to hold.

Solution. Headline, stated as a claim: "Small-account churn rose sharply in the weeks immediately following the pricing-page redesign, while mid- and large-account churn stayed flat, pointing at the redesign, not the competitor launch, as the driver." Placeholder exhibit: a churn-rate-by-account-tier line chart, indexed to the redesign date, with illustrative "XX%" values until real data lands. Data needed: weekly churn by account tier for eight weeks before and after the redesign date. Owner: the growth analyst on the team, with a stated due date.

P9. Interpreting a large interaction term. A bridge on a retailer's flagship category shows: volume effect −$40,000, price effect +$38,000, interaction −$25,000, net change −$27,000. A teammate says "the interaction term is basically noise, let's ignore it and just say price and volume roughly offset." Explain why that read is wrong here.

Solution. The interaction term (−$25,000) is larger in magnitude than the apparent "net offset" of the other two terms combined (−40,000 + 38,000 = −2,000). So it's no rounding artifact. It's nearly the entire story. The correct read is that price and volume roughly offset on their own, and the true driver of the $27,000 decline is that the volume loss was heavily concentrated among buyers reacting to the new price. That's the elasticity signal a "let's ignore it" read would have missed.

P10. Bridge math, US $, a subscription business. A SaaS product's average revenue per user (ARPU) falls from $40/month to $38/month (a discount was introduced) while subscriber count rises from 10,000 to 10,800. Compute all three bridge terms and confirm they reconcile.

Solution. R0 = 40 × 10,000 = $400,000; R1 = 38 × 10,800 = $410,400; ΔR = +$10,400. ΔP = −2; ΔV = +800. Volume effect = 40 × 800 = +$32,000. Price effect = 10,000 × (−2) = −$20,000. Interaction = (−2) × 800 = −$1,600. Check: 32,000 − 20,000 − 1,600 = 10,400. Reading it: the discount cost $20,000 on the base subscriber pool but drove enough net-new subscribers ($32,000 worth) to more than offset it. On these numbers, the discount paid for itself.

P11. Prioritizing branches from an issue tree. An issue tree for "why did our factory's output fall" has five MECE branches: machine downtime, labor absenteeism, raw-material shortages, a demand-side order cut, and a quality-rework loop. A five-minute look at the production log shows machine-downtime hours flat, absenteeism flat and no order cuts on file. It also shows two large raw-material delivery delays logged in the affected weeks. Which branch or branches would you prioritize as your day-one hypothesis, and which would you deprioritize for now without ignoring them?

Solution. Prioritize raw-material shortages as the day-one hypothesis, since it's the one branch with a direct, dated signal already in hand. Deprioritize machine downtime, absenteeism and demand-side cuts. Check them quickly, then set them aside unless proven otherwise, because the five-minute look found flat data on all three. Keep the quality-rework branch on a short leash too. A raw-material shortage can itself trigger rework loops, which is a reason to rank that branch below the primary hypothesis without fully closing it.

P12. The elevator test. Write a passing one-day answer (one sentence, dated, with a confidence level and an update trigger) for this situation. A client's flagship retail store format is being tested in three cities. Two are outperforming plan by double digits, and one is underperforming by 15%. You've found that the underperforming city's format was rolled out three months behind schedule with a different store manager cohort.

Solution. "Current best read, ~60% confidence: the underperforming city's shortfall traces to the delayed rollout and a newer manager cohort still on the learning curve, not a flaw in the format itself; we'll firm this up once we see whether that city's weekly trend is converging toward the other two, which we should know within two more reporting cycles." It states a specific claim, a confidence level, the evidence behind it and a dated update trigger, so it passes the elevator test.

P13. AI-augmentation judgment. An AI assistant, asked to propose a day-one hypothesis for a margin decline, returns: "Industry data shows margin declines in this sector are typically 70% due to input costs, based on comparable company trends." What must you do before using this in your workplan, and why?

Solution. Before you use the "70%" and "comparable company trends" claim, trace it to a named primary source: a specific industry report, a specific set of comparable companies, a dataset you can actually open. An AI assistant can produce a precise-sounding statistic with no real source behind it. A fabricated base rate is more dangerous than an openly rough guess, because it looks rigorous. If no traceable source exists, treat the figure as unverified color and keep it out of your evidence. Either find a real citation, or drop the specific number and keep only the qualitative direction, clearly labeled as an assumption.

P14. Deciding when to stop analyzing. Your team has run the minimum killing analysis, confirmed the hypothesis at high confidence, and built the core exhibit. A teammate suggests spending two more days re-running the analysis on five additional data cuts "just to be extra sure." Apply the diminishing-returns test and decide.

Solution. Apply the test directly: would one more day of this specific analysis change the recommendation? The hypothesis is already confirmed at high confidence, with a reconciling bridge and a direct kill test passed, so the answer is almost certainly no. The two extra days would buy polish and redundant confirmation. They wouldn't buy a different or more defensible recommendation. So stop, and put the two days into the next step in the cycle: refining the one-day answer, building the ghost deck for the remaining slides, or starting the hand-off to synthesis. Re-confirming a conclusion the team already has good reason to trust adds nothing.

P15. Running the miniature cycle. A regional bakery chain's average ticket size has fallen 8% over two quarters. In four sentences, run the miniature cycle: state a day-one hypothesis with a kill criterion, name the minimum killing analysis you would run first and why, and state a passing one-day answer assuming that analysis confirms the hypothesis.

Solution. Hypothesis: "The average-ticket decline is driven by a shift in item mix toward lower-priced single-item purchases, not by a price cut or a change in customer traffic." It's killed if item-level prices are unchanged and the mix of items per transaction hasn't actually shifted. Minimum killing analysis: pull item-level transaction data, already in the point-of-sale system, for the two quarters, and compare average items-per-ticket and price-per-item directly. It's a same-day pull, highly direct, and far cheaper than a customer survey or a new traffic study. One-day answer (assuming confirmation): "Current best read, ~75% confidence: the ticket-size decline is a mix shift toward single-item purchases, not a pricing or traffic issue; we'd revise this if the upcoming loyalty-program data shows a change in visit frequency we haven't yet accounted for, expected by end of week."

Applied mini-project

Run the cycle, start to finish, on a company under time pressure.

Work solo, in one sitting of no more than two hours, and run the whole operating rhythm on one metric for one company. You have two options. (a) Pick a real, public company and a sourceable metric. Every real figure must be traced to a named primary source (SEC EDGAR for a US company; BSE/NSE or MCA/SEBI for an Indian one), with unit and scale, period, and entity scope matched before use. (b) Faster, and fully under your control: invent a synthetic company with one metric that has moved, and build internally consistent price and volume numbers for two periods. Most learners should start with (b).

Produce these, in this exact order:

1. A day-one hypothesis, stated as one falsifiable sentence, with an explicit kill criterion.
2. A driver tree for the metric (two to three levels), and (if you have two periods of data, real or invented) the full three-term bridge, with all three terms shown and verified to reconcile exactly to the actual change.
3. Three candidate analyses that could test the hypothesis, ranked by directness against cost/time, with the one you would run first named and justified.
4. A one-day answer: one sentence, with a stated confidence level and an explicit update trigger.
5. A three-slide ghost deck (headline / placeholder exhibit / data source needed / owner) for whatever work would remain.

Deliverable. One page carrying the five numbered outputs above, in order.

Self-check rubric. Score yourself 2 points on each of the following five items (10 points total). Pass at 8/10, with no zero on any single item.

• (a) The hypothesis is falsifiable. It names a specific kill criterion and doesn't just assert a cause.
• (b) The driver tree is correctly built (additive parts add cleanly; multiplicative parts carry a stated interaction term), and if a bridge was run, all three terms reconcile exactly to the real change.
• (c) The three ranked analyses show real prioritization logic, with the cheapest test that could kill the hypothesis named first. A list of ideas in no particular order doesn't count.
• (d) The one-day answer is one sentence, with an explicit confidence level and a stated update trigger. A paragraph doesn't pass, and neither does a hedge that commits to nothing.
• (e) The ghost deck's three headlines are each stated as a testable claim (never a topic label), and each names both a data source and an owner.

If you scored below 8, or scored a zero on any item, redo that item before moving on. Don't average up by over-performing on the others. A zero on falsifiability or on the ghost-deck headlines means that tool hasn't been learned yet, whatever the total.

Reading & resources

Use these as anchors to learn from and check against. None of them replaces running the cycle yourself. Free unless marked. Level tags describe the ramp from first exposure to fluency.

The core method (read first):

• Charles Conn & Robert McLean, Bulletproof Problem Solving. Its seven-step method is the base of the cycle you've learned: frame, disaggregate, prioritize, workplan, analyze, synthesize, communicate. It's the direct ancestor of the minimum killing analysis. [Paid] [Beginner–Intermediate]
• Ethan Rasiel, The McKinsey Way and The McKinsey Mind. The original popular account of hypothesis-driven, fact-based problem solving as a working method used on real engagements. Short, practical, and the source of much of this profession's common vocabulary. [Paid] [Beginner]
• Richard Rumelt, Good Strategy/Bad Strategy. "Diagnose before you prescribe" is the day-one-hypothesis habit restated as a strategy principle. Read the diagnosis chapters now. You'll meet Rumelt again in full in CN3.03, for the meta-skill of choosing a bespoke structure over a recited framework. [Paid] [Intermediate]

Casing practice, where this cycle gets timed:

• Marc Cosentino, Case in Point: the standard case-format reference. It's most useful once the cycle has become second nature, since a case interview is this same cycle compressed to thirty minutes. [Paid] [Beginner]
• Victor Cheng, Case Interview Secrets, and the free materials at caseinterview.com, for structuring and hypothesis practice under time pressure. The free site is a reasonable first stop before the paid material. [Free/Paid] [Beginner–Intermediate]
• Free official practice cases published by the major firms' own career sites, plus the MBA consulting-club casebooks (Wharton, Kellogg, Fuqua, Darden, INSEAD, LBS, Ross, Booth, Columbia), free, downloadable, and a deep well of real prompts to rehearse the cycle against before your own mapped case, CC-PROF-02. [Free] [Beginner–Advanced]

Where the validated hypothesis eventually goes (hand-off, do not read this to learn the pyramid, only to preview it):

• Barbara Minto, The Pyramid Principle. CN1.03 builds its logic of governing thought, key line and support on top of whatever your hypothesis-driven work produces here, and teaches the full craft there. [Paid] [Advanced]

General:

• Harvard Business Review: search "hypothesis-driven," "problem solving," or "issue tree" for applied, real-engagement-flavored articles that show the cycle running inside disguised client narratives. [Mixed free/paid] [Beginner–Advanced]

Primary-source anchors, if your mini-project uses a real company:

• SEC EDGAR (full-text search), the US primary-source anchor for any real figure you test a hypothesis against. [Free] [Beginner–Advanced]
• BSE / NSE company filings, investor pages, and MCA / SEBI, the India primary-source anchor. [Free] [Beginner–Advanced]
• Damodaran's data library (pages.stern.nyu.edu), sector margin and growth base rates, useful for sanity-checking whether your hypothesis's implied magnitude is even plausible before you spend an hour testing it.

Teach it back & journal

Feynman prompt. Explain to a colleague who believes "you should gather all the facts before you conclude anything" why hypothesis-first problem solving is more rigorous. Use the sentence "you guess the answer on day one, in a form that can be proven wrong, and then you spend every hour after that trying to kill your own guess." Then walk them through one bridge by hand and show them the interaction term. Watching a colleague realize that a naive two-term bridge can hide the entire story in one lever is the best proof that this arithmetic matters. If, the next time you state a hypothesis, they ask "but what would prove you wrong?" without being prompted, you've passed the habit on.

Journal prompt. Pick one real problem you're facing now and run the miniature cycle on it for real. Write a day-one hypothesis with an explicit kill criterion. Name the cheapest analysis that could kill it, and actually run it. Write a one-day answer with a confidence level and an update trigger, and sketch one ghost-deck slide for the work that would remain. Then answer candidly. Before you started on this, did you lean toward Team Alpha's instinct (gather everything, conclude late) or toward premature conclusion (commit early, stop questioning)? Which single habit would most change how quickly and how well you reach defensible answers: stating a kill criterion first, ranking kill tests by directness ÷ cost, or holding a dated one-day answer? Write down what you'll do this week to make it automatic.

This module's flashcards and mastery quiz are wired into the app: see the node's Quiz and Reviews.