Find the real problem: symptoms lie, roots don't

• The discipline: for every fact about what the problem IS (what, where, when, extent), write its twin - what it plausibly COULD have hit but did not. "Single-module clients churn" means little until you add "multi-module clients do not." The contrast IS the clue.
• Why rooms skip it: is-not data feels like non-news, so nobody collects it. But causes must explain BOTH columns - a "bad product" theory dies instantly against "direct-onboarded clients are fine."
• The THEREFORE column is where specification becomes direction: each row's contrast points somewhere. Four rows in, Himalaya's grid is pointing hard at one thing - the partner onboarding path.

Ford's 8D (eight disciplines) adds the step every elegant root-cause method forgets: containment first. Form the team, describe the problem (D1-D2), then D3 - stop the bleeding with an interim fix BEFORE hunting the root cause (D4-D7), and close by preventing recurrence (D8).

The Himalaya translation: while today's session digs for the root, Tom should already be calling every single-module client up for renewal in the next 60 days. Containment is not the fix - it buys the time to find the fix without losing another cohort. When something is actively costing customers, contain first, diagnose second, and never confuse the two.

• Stop at a cause you can act on. Five is a slogan, not a rule - Himalaya hit an actionable root in five, but four or six is fine. Drill past "actionable" and you end up at "capitalism" - true, useless.
• Whys can branch. "Why did clients never activate a second module?" has two honest answers at Himalaya (no playbook AND the second module is hard to discover in-product). Draw two chains when they branch; do not force one story.
• "Human error" is never a root. If a why lands on "someone forgot / someone made a mistake," ask why the system LET them - the next why down is always a missing checklist, handoff, or incentive. Roots live in process, not people.
• Test every link: "if we fixed this, would the spike vanish?" A why that fails the test is a passenger, not a cause.

Born at Bell Labs in 1962 for missile safety, fault tree analysis is the engineer's upgrade to 5 Whys: start from the failure at the top, decompose downward through logic gates - this fails if A OR B happens; that fails only if C AND D happen together.

The gates matter because they change where you spend: an OR gate means every child is a full path to failure (harden all of them); an AND gate means killing ONE child kills the branch (harden the cheapest). Himalaya's churn was an AND: no playbook AND no in-product discovery of the second module - which is genuinely good news, because fixing either one breaks the failure path. Overkill for most business problems; exactly right when the failure is rare, expensive, and multi-causal.

• Fishbone = breadth. Generate candidate causes across every family (pick bones that fit YOUR problem - Himalaya's are People, Process, Product, Partner, Pricing, Competition). Its job is to stop the room from anchoring on the first plausible story.
• Is/is-not = the filter. Hold each candidate against the grid: does it explain BOTH columns? "Rivals are cheaper" fails - direct-onboarded clients face the same rivals and are not churning. The facts eliminated four of six bones in minutes.
• 5 Whys = depth. Drill the surviving bone to an actionable root. For messy problems, run them in exactly that order - swarm, filter, drill.
• Himalaya's verdict, proven: churned clients were single-module, onboarded by a partner reseller with no activation playbook, never built a usage habit, churned at renewal. Session 2's activation fix was aimed at the right root - now the room KNOWS instead of hopes.

Joseph Juran's "vital few, trivial many": before drilling any single cause, tally how often each candidate actually shows up in the data. Pull Himalaya's last 40 churned accounts and count - how many were partner-onboarded and single-module? If it is 31 of 40, the fishbone's hot bones are confirmed in an afternoon. If it is 12, your neat story just met an inconvenient distribution.

The move is embarrassingly simple - a tally chart sorted tallest-first - which is why it gets skipped in rooms that prefer narrative to counting. Session 1's 80/20 instinct, now pointed at causes: drill where the count is, not where the loudest anecdote lives.

Today's kit suits EVENTS - a spike, an outage, a cohort gone wrong. When the problem is a process that slowly drifts (onboarding time creeping up, quality sliding a percent a quarter), Six Sigma's DMAIC is the wrapper: Define the defect in metric terms, Measure the baseline honestly, Analyze root causes (today's three tools slot in here), Improve with tested changes, Control so the fix sticks with monitoring and owners.

That last letter is the one Himalaya will need in Session 7: an activation playbook that ships without a control plan - a metric, a dashboard, an owner - quietly rots back to baseline within a year. Fixes decay; Control is what stops them.