What it is
5 Whys is a root-cause analysis technique: start with a problem, ask "why did this happen?", answer it, then ask "why?" of the answer, and repeat — usually about five times — until you reach something that explains the surface symptom. The technique was developed at Toyota in the 1930s by Sakichi Toyoda, founder of what would become Toyota Industries, and was central to the Toyota Production System.
The number five is a rule of thumb, not a law. The point is to push past the first plausible-sounding answer, which is almost always a symptom, and keep going until you hit something you can actually change.
When to use it
5 Whys works best for problems where the chain of causation is mostly linear and you want a fast diagnosis. Reach for it when:
- A production incident has just been resolved and you need a post-mortem
- A customer-facing metric drops unexpectedly
- A team keeps missing the same kind of deadline
- A defect appears in QA that should have been caught earlier
- A recurring complaint surfaces in customer support
It's less suited to problems with many interacting causes (a churn spike driven by pricing, onboarding, and a competitor launch). For those, use a Fishbone diagram instead.
How to run it
- Write the problem statement in one sentence, with a metric or observable behavior. "Checkout error rate jumped from 0.4% to 2.1% on Tuesday," not "checkout is broken."
- Ask "why?" and answer with a single, factual cause — something you could observe or measure.
- Ask "why?" of that answer. Push past "human error," "we didn't communicate," and similar dead-end phrasings.
- Keep going. Stop when the next "why?" leaves the domain you can act on, or when you've reached a system or policy that can be changed.
- Test the chain: if you remove the root cause, would the symptom go away? If not, you stopped too early or wandered down the wrong branch.
- Identify the smallest change that addresses the root cause, and assign an owner and date.
- Schedule a check-in to confirm the symptom doesn't return.
Common pitfalls
The biggest trap is stopping at "human error." If your root cause is "Alex forgot to run the migration," you've identified a person, not a cause. The real question is why was it possible for Alex to forget? Was there no checklist, no automation, no review? The Toyota tradition insists that root causes live in systems, not people — if the same role were held by someone else, would the failure still be possible? If yes, you haven't reached the root.
Second pitfall: confirmation bias. The person running the 5 Whys often has a theory before they start, and the questions get steered toward it. Have someone other than the suspected owner facilitate.
Third: treating it as a single linear chain when the actual failure had multiple contributing causes. If a "why?" has two real answers, branch — don't pick the more convenient one.
Variations
The Fishbone diagram (Ishikawa) is the natural complement. Where 5 Whys traces one chain deep, Ishikawa maps causes wide, sorted into categories like People, Process, Equipment, Materials, Environment, and Management. Use Ishikawa first when the problem feels multi-causal, then 5 Whys on the most promising branch. A more rigorous variant is Fault Tree Analysis, used in safety-critical industries, which formalizes the branching with logical operators (AND, OR) — overkill for most product or ops work, but the right tool when consequences are catastrophic.