Stop Five Whys at structural preventability, not at question five — actionability determines the stopping point

Why This Is a Rule

The "five" in Five Whys is a heuristic, not a rule. Taiichi Ohno (who developed the technique at Toyota) used five as a rough guide for the depth typically needed to reach a root cause. But some problems reach structural root causes in two "whys," while others require eight. Stopping rigidly at five — either prematurely or unnecessarily — produces suboptimal analysis.

The actual stopping criterion is structural preventability: have you reached a cause that you can structurally prevent (not just mitigate through effort)? This aligns with A true root cause, eliminated, makes the error impossible — if it only reduces frequency, keep digging's elimination test: if removing this cause would make the error impossible, and you have a viable structural intervention, you've reached the actionable root.

Two common errors from rigid counting: Stopping too early (at why #5 when you've only reached a contributing factor): you implement a band-aid that reduces frequency but doesn't eliminate the error. Stopping too late (continuing past the actionable root into philosophical territory): "Why do humans make errors?" is philosophically interesting but not structurally preventable. The analysis has gone past the actionable layer into the unfixable layer.

When This Fires

• During any Five Whys or root cause analysis session
• When you've reached "why #5" but the cause isn't structurally preventable — keep going
• When you've reached a structural prevention point at "why #2" — stop, don't force three more
• When analysis is drifting into unfixable abstractions — you've gone too deep

Common Failure Mode

Mechanical application: asking exactly five "whys" regardless of where the analysis leads. At why #3 you've found a clear structural cause → but you ask two more "whys" because "you're supposed to ask five." The extra questions push past the actionable root into deeper systemic factors you can't change, producing a root cause that's accurate but unfixable. The structural cause at #3 was the right stopping point.

The Protocol

(1) Begin the analysis: "Why did [error] occur?" (2) At each answer, apply two checks: Preventability: can I structurally prevent this cause? (Not just mitigate — prevent.) Elimination: would preventing this cause make the error impossible? (A true root cause, eliminated, makes the error impossible — if it only reduces frequency, keep digging) (3) If both checks pass → stop. You've found the actionable root cause. Design the structural fix. (4) If the cause isn't preventable or elimination fails → ask "why" again. Continue deeper. (5) If you reach a cause that's true but unfixable ("human nature," "market conditions," "physics") → you've gone too deep. Back up one level to the last structurally preventable cause. That's your actionable root. (6) The number of "whys" is irrelevant. Some problems root at 2; some at 8. Let the analysis determine depth.