Tool/Mental Model/No. 0388
Five Whys
Five Whys is a root cause analysis technique that uses repeated why questions to explore a problem’s causes. Documented by Taiichi Ohno in the Toyota production system, it prompts deeper inquiry rather than exactly five questions; each answer needs evidence, and causes may branch.
Also called 5 Whys · Five Why Analysis
- Evidence
- Useful, modest evidence
- Read
- 7 min
- Links
- 6 connections
01You've seen this when…
- in life
You pay another late fee despite putting the bill on your calendar. The reminder arrives while you’re commuting, and nothing brings it back when you get home.
- at work
The weekly report contains the same error again. Someone corrects the spreadsheet, but the team never checks why the export keeps putting the wrong number there.
- out in the world
A neighborhood pool closes for the third time because treatment supplies run out. The council approves an emergency purchase each time, without examining how routine ordering works.
02The idea
Fixing today’s problem can leave the conditions for tomorrow’s problem unchanged. Refilling the printer can leave the causes of recurrence in place, just as correcting the spreadsheet or paying the fee can leave the underlying problem untouched.
Five Whys is a way to keep an investigation moving past the first explanation. Start with a specific event and ask why it happened. Use each answer to ask why that condition arose, continuing until you reach a contributing cause you can investigate or change.
The number five reminds you to look deeper; the stopping point depends on what you find. Three questions may be enough. Seven may still leave important causes unexplored. Answers can branch: one event can have several causes, each worth following.
Five Whys has a narrower scope than root cause analysis: it helps generate possible explanations. A full investigation also gathers evidence, compares alternatives, examines interacting conditions and checks whether corrective action works.
Its useful shift is from naming the last thing that went wrong to explaining how the situation allowed it. Even a smooth chain of answers needs evidence for each link.
03How to use it
- Define the event. Describe what happened and specify its time and place. The report contained three incorrect totals is more useful than the reporting process is broken. Keep blame out of the starting statement.
- Establish the sequence. Gather records and talk to people close to the work. Write down the full sequence of events, from the lead-up through the aftermath. Otherwise, your questions may build on a mistaken account.
- Ask for a cause, then check it. For each answer, record what supports it: a log, an observation, a document or a test. Mark unverified answers as possibilities. Ask whether changing that condition would plausibly have prevented or reduced the problem.
- Follow more than one branch. If a deadline slipped because a supplier was late and nobody noticed the delay, investigate both. Trace each contributing condition separately. For complicated failures, a fault tree may offer a better structure.
- Stop at a useful depth. You have gone far enough for this exercise when you have a supported explanation and a practical next step. Stop and gather evidence if the next answer would be guesswork. Even after five answers or a broad label like poor management, you still need that supported explanation and practical next step.
- Test a change. Choose an action, give it an owner and decide what result would count as improvement. Check whether the problem returns. A convincing explanation still needs to yield a useful prediction. Revisit it if that prediction is missing.
When examining a person’s mistake, ask what information they had and what made the action reasonable or possible. That local rationality perspective can reveal how pressures and constraints shaped their choice.
04A worked example
In this illustrative example, a subscription company discovers that fourteen customers received duplicate renewal invoices after its overnight billing job stalled.
What it looks like A temporary technical glitch. The team could cancel the extra invoices and increase the job’s timeout.
What’s actually going on The team follows one possible causal chain and checks it against job logs, billing records and tests:
- The job processes the same renewals twice. After an interruption, it repeats work it has already completed.
- The retry repeats the whole batch. The billing service times out, so the job cannot tell which invoices were created before the interruption.
- Repeated work can create another invoice. There is no enforced rule that each renewal can produce only one invoice.
- The design treats invoice creation and confirmation as one event. It assumes that an invoice exists only if the job receives confirmation, overlooking the possibility that creation succeeds but confirmation fails.
- The tests leave that possibility out. They cover successful billing and failures before invoice creation, but not an interruption between creation and confirmation.
A separate branch investigates the timeout. Fixing that alone would leave the duplicate-invoice risk whenever another interruption occurs. The fifth answer leaves open whether testing is the ultimate cause; the team could investigate why that case was missed if doing so would help.
What made it work The team reproduces the interruption in a test, then changes billing so a repeated renewal cannot generate another invoice. Replaying the failure produces one invoice rather than two. The questions lead to an explanation the team can test and use to make a targeted change.
05When to reach for it
Use it when a small, reasonably bounded problem keeps returning after quick fixes: missed appointments, stock shortages, incorrect reports or a recurring equipment fault.
It is especially useful when the first explanation stops at naming a person and leaves the conditions unexplored. Repeated questioning can counter the fundamental attribution error: treating someone’s behavior as a character defect while overlooking the situation.
It can also expose a rule that needs changing, taking the investigation beyond improving a task. That opens the door to double-loop learning. For serious accidents or complex system failures, use it only as one part of a broader investigation.
06When it misleads
- The first answer chooses the destination. Begin with insufficient training and every later question may stay inside a training story. Compare that explanation with workload, equipment, instructions and incentives before committing to it.
- A chain hides interacting causes. A failure may require several conditions together. Removing any one might prevent it, yet none deserves to be called the sole root cause. The Swiss Cheese Model helps explain how several defenses can fail together.
- Depth gets mistaken for evidence. Judge the fifth answer by its supporting evidence, just as you would any earlier answer. A confident facilitator can guide a group toward almost any preferred conclusion if nobody checks the links.
- The exercise becomes an interrogation. Repeated why questions directed at one employee can sound accusatory and encourage defensive answers. Keep attention on the event and examine the constraints around people’s choices with those who understand the work. This preserves individual responsibility while making the explanation more complete.
- The final answer is too broad to use. An investigation that ends with a label like human error can explain as little as one that ends with culture or leadership. Translate broad labels into observable conditions: which instruction, decision, missing resource or unchecked assumption contributed?
- The investigation outruns the stakes. A low-cost annoyance may need only a small experiment, keeping the search for an ultimate explanation proportionate to the stakes. Conversely, a serious safety event deserves more evidence and expertise than a quick discussion can provide.
07Roots
Taiichi Ohno helped develop Toyota’s postwar production system, where a stopped machine could interrupt the work that followed it. Replacing a blown fuse got production moving again. It did not necessarily explain why the fuse would blow next time.
In his account of the Toyota Production System, Ohno demonstrated repeated questioning with a stopped machine. The explanation moved from an overload to inadequate lubrication, then through a failing pump to metal debris entering because a strainer was missing. It was a teaching example of the difference between restoring operation and preventing recurrence: replace the fuse, and the hidden equipment problem remains.
The technique’s exact beginning is harder to pin down. Later accounts often credit Sakichi Toyoda, the loom inventor associated with the origins of the Toyota group. Ohno’s published explanation provides a firmer reference point than claims about a single inventor or founding date.
As Toyota’s methods spread, Five Whys traveled into management, software and healthcare. Its simplicity helped it travel, but also made it easy to detach from observation and testing. Critiques, including Alan Card’s examination of its use in healthcare improvement, warn that an arbitrary stopping rule and a single causal chain can produce misleading certainty.
08How solid is this?
Five Whys is a long-standing improvement practice. Strong comparative evidence that five questions reliably identify causes or prevent recurrence is limited. Treat it as a prompt for investigation, not a validated causal test.
09Connections
- Helps counter Fundamental Attribution Error
- Part ofRoot Cause Analysis
- See alsoFault Tree Analysis, Local Rationality, Double-Loop Learning, Swiss Cheese Model
10Origin and sources
Toyota production-system tradition, documented by Taiichi Ohno in Toyota Production System (Japanese edition 1978; English edition 1988). Often attributed to Sakichi Toyoda, though the original inventor and date are not firmly established.
- [1]Ohno, T. (1988). Toyota Production System: Beyond Large-Scale Production. Productivity Press.
- [2]Card, A. J. (2017). The problem with '5 whys'. BMJ Quality & Safety, 26(8), 671–677.
Suggest an edit· Updated 2026-10-02