One-sentence positioning: Ask "why" 3-7 times about a problem (not strictly 5 times), digging from the symptom down to a changeable process/system/design — do not patch at the symptom level.
When to Use (TRIGGER)
- Incident / bug postmortem
- The same type of problem recurs (not a first-time one-off)
- Surface-level fixes are clearly not enough (every time it's "won't happen again" but it recurs)
- Process problem diagnosis
- Users report "why do we always X?" — a signal that root-cause analysis is needed
When Not to Use (ANTI-PATTERN)
- Single one-off, no pattern to follow — may be noise, observe first
- Complex system problems (Cynefin Complex domain) — 5 Whys assumes linear causality, while complex systems are multi-causal + emergent
- The team atmosphere is "find the guilty party" — 5 Whys easily turns into a blame chain of "Why didn't X do it well → because Y is unreliable"
- Truly unknowable things (e.g., why an ML model produced a certain output) — use statistical methods, not 5 Whys
Steps (STEPS)
1. State the problem accurately
Must include:metric + time + scope. Don't say vaguely "there's a problem with login", say "2026-05-25 14:00-15:00 us-east-1 login failure rate 32%"
2. Ask Why #1, get answer A1
A1 must be a fact, not an evaluation. Wrong: "because the team wasn't careful" Right: "auth-service 14:05 deploy introduced a null check bug"
3. Treat A1 as the problem, ask Why #2
Ask again about A1: "why did A1 happen?" to get A2
4. Repeat until reaching a root cause that is "a changeable process / changeable system / changeable design"
Usually 3-7 levels.5 is an average, not a rule. Termination criterion: the root cause is at the level of "can be prevented from the process level next time" rather than "which specific person was negligent this time"
5. Verify the causal chain
Forward reasoning from the root cause—can it explain the original problem? If not → the chain is broken, redo it
6. Propose actions targeting the root cause
Not temporary patches targeting symptoms. "Add a lint rule" "change the oncall process" "redesign the permission model" — all are process/system-level actions
Decision Checklist
- The problem statement includes metric + time + scope
- The answer to each Why is a fact, not an evaluation
- There are no names in the answers (Why is followed by mechanism, not person)
- The root cause is at the level of "can be prevented from the process level next time" (not "be more careful next time")
- From the root cause you can reason forward back to the original problem (bidirectional verification)
- Actions target the root cause, not the symptom
Real Cases
Case 1: Toyota classic (Taiichi Ohno's original example)
- Problem: The machine stopped
- Why #1: The fuse blew → Why?
- Why #2: The bearing wasn't lubricated → Why?
- Why #3: The oil pump wasn't working → Why?
- Why #4: The pump shaft was worn → Why?
- Why #5: No filter was installed (metal shavings entered the shaft) → root cause
- Action: Add a filter + regular checks (process level)
- If you only ask 1 layer (the fuse blew) → the solution is "replace the fuse" → it will break again a week later
Case 2: Engineer — Login Failure 5 Whys
- Problem: 14:00-15:00 us-east-1 login failure rate 32%
- Why #1: Server 500 → because the DB connection pool was full
- Why #2: Why was the connection pool full? → because a batch job held a long transaction for 12 minutes
- Why #3: Why didn't the batch job release it? → because no timeout was set
- Why #4: Why was no timeout set? → because code review missed it
- Why #5: Why did review miss it? → because there is no lint rule enforcing SQL transaction timeout
- Root cause: Missing lint rule (process level)
- Action: Add a lint rule enforcing that all transactions must have a timeout (system-level prevention)
Case 3: Product — New Feature DAU Is Only 1%
- Problem: One week after launch, the new feature's DAU is only 1%
- Why #1: Users cannot find the entry point
- Why #2: Why can't they find it? → the entry point is buried in a third-level menu
- Why #3: Why a third-level menu? → the PRD did not require first-level exposure
- Why #4: Why didn't the PM require it? → worried that the first-level menu would be too crowded
- Why #5: Why was there no space budget? → there is no RFC process for "first-level menu space allocation"
- Root cause: Missing a decision process for first-level menu space allocation
- Action: Establish an RFC process for the first-level menu (process level) + remediate this feature by moving it up to the first level
Relationship with Other Frameworks
- Pre-Mortem is ex ante 5 Whys: "If it failed, it might be because of why's why..."
- Works with the Orient step of the OODA Loop: 5 Whys is a tool for the quality of Orient
- Second-Order Thinking is "chasing into the future"; 5 Whys is "chasing into the past" — complementary in time direction
Common Pitfalls
- Stopping when you count to 5(5 is an average, not the endpoint) — countermeasure: the criterion is "reaching the process/system/design layer," not "asking 5 times"
- Looking for someone to blame(Why followed by a person's name) — countermeasure: strictly require that what follows Why must be an event/mechanism
- Not validating the causal chain(the root cause cannot be traced back to the original symptom) — countermeasure: a bidirectional causal chain must be able to explain it
- Single-tree-ism(only following one why chain, ignoring parallel multiple causes) — countermeasure: when necessary, draw a fishbone diagram (Ishikawa), with multiple branches
- Jumping to solutions too early(starting to act after asking 1-2 times) — countermeasure: force completion of 3-5 layers before discussing actions
References
- Taiichi Ohno, 《Toyota Production System》 (1978)
- Eric Ries, 《The Lean Startup》 (2011) — extended to software startups
- Toyota Production System: "ask 'why?' five times about every matter"
- Derivative: Fishbone Diagram (Ishikawa Diagram) = multi-branch 5 Whys