5 Whys: reaching the root cause by asking why, 5 times

In one line

5 Whys is a problem-solving technique that consists of asking "why?" in a chain — each answer becomes the basis of the next question — until you reach a cause you can actually act on, instead of stopping at the surface symptom.

What it is

The technique was developed by Sakichi Toyoda for Toyota Industries Corporation, and was later built into the Toyota Production System (TPS) as a basic practice, driven by Taiichi Ohno. The underlying idea is simple: when a problem shows up, the natural temptation is to blame someone else, an outside factor or bad luck — but the real cause is almost always closer than it seems, inside the process itself.

Asking "why" five times is not a magic formula or a rigid rule: the source itself makes clear that five is only a practical guide for peeling away the layers of symptoms that cover the cause — in some cases fewer questions are needed, in others, more.

For the technique to work, three basic conditions are needed:

• A precise and complete problem statement (not something vague like "the machine fails a lot")
• Total honesty when answering each question, without trying to look good or cover for anyone
• A real decision to get to the bottom of it and not settle for the first comfortable answer

5 Whys is a generic root cause analysis (RCA) tool: when it is not enough to see clearly where the problem comes from, it can be combined with other tools from this same pillar, such as the Ishikawa diagram, or with more structured techniques such as barrier analysis or the causal factor tree.

What it is for

It is useful for any specific, well-bounded problem where you suspect that the visible cause is really a symptom of something deeper: an equipment failure that keeps recurring, a safety incident, a quality complaint, a shift changeover that did not go as planned. It is not the right tool for problems with many interrelated variables acting at the same time — in that case an Ishikawa or a more formal analysis is a better fit before chaining questions.

How it is applied

The process described by the source has five steps, designed to be done as a team (it works better with several people directly involved in the problem, not a single person speculating alone):

1. Gather the team and agree together on the exact problem statement.
2. Ask the first "why": three or four reasonable answers will probably come up — write them all down (whiteboard, cards, spreadsheet).
3. Repeat "why" for each of those answers, four more times — without discarding any plausible branch. If with fewer than five questions no new information comes out, that is the root cause; if needed, keep going past the fifth.
4. Among all the answers to the last question, look for systemic causes (not individual ones) and agree as a team on which one is the most likely.
5. Define the corrective action that removes that root cause from the system — not an action that fixes the symptom on top.

Real example

In 2004, during a walk through an Amazon.com distribution center (Fulfillment Center), Jeff Bezos learned about a safety incident: an operator had hurt his thumb. Instead of asking for a written report, he stood in front of a whiteboard and chained the questions right there:

1. Why did he hurt his thumb? → Because it got caught in the conveyor belt.
2. Why did his thumb get caught in the belt? → Because he was chasing his bag, which was riding on top of the moving belt.
3. Why was he chasing the bag? → Because he had left it resting on the belt, and the belt started up without his expecting it.
4. Why had he left the bag on the belt? → Because he was using it as if it were a table.

With that fourth answer the root cause was already visible: there was no surface near the workstation to leave personal items on, so the operator improvised by using the conveyor belt as a table. The corrective action was not "ask him to be more careful" — it was to install tables at the workstations that needed them, update the safety training, and review the standardized preventive maintenance work for the line.

The source itself adds a clarification worth noting: the "5" is a guide, not a fixed rule. In this real case the root cause came to light at the fourth question, not the fifth — and that is fine: what matters is to keep asking until the next answer no longer adds any new information, whether that happens before or after the fifth round.

How to put it together

To fill it in on screen (what you enter is saved in your browser), use the interactive tool.

Copy this sequence and complete it with your team, one answer at a time, before moving on to the next question:

1. Problem to analyze: (a concrete, well-bounded description of the problem)
2. Why did the problem occur?
3. Why did that happen?
4. Why did that happen?
5. Why did that happen?
6. Why did that happen? (the answer to this question is your root cause candidate)
7. Root cause identified:
8. Corrective action:

Benefits

• It needs no statistical tools or special training: any team can apply it with a whiteboard and half an hour
• It is fast: it is resolved in a single working session, unlike more formal analyses that take days
• Because it is done as a team, it pushes the conversation toward causes in the system and the process, instead of staying at "whose fault was it"
• It combines well with other tools in this pillar: it can be used to dig deeper into any "bone" of an Ishikawa diagram, or into any hypothetical cause of a broader RCA

Limitations to keep in mind

The same source warns that the technique is criticized for being too basic to guarantee that it reaches a real root cause and not just another, deeper symptom. The most common reasons:

• The team tends to stop at the first convincing symptom, without going one level further down
• The answers depend on the knowledge and experience of the people asking — if nobody in the room knows enough, the chain breaks off too early
• Lack of facilitation: without someone pushing to keep asking, it is easy to settle
• Low repeatability: two different teams analyzing the same problem can arrive at different root causes

The way to mitigate this is to verify each answer against reality (not answering by deduction or intuition) before moving on to the next question, and not closing the analysis until you confirm that the cause found explains the whole problem.

Apply it to your problem

In summary

5 Whys is the starting tool of root cause analysis: it was born at Toyota with Sakichi Toyoda and became standard TPS practice because it is simple, fast and needs no prior training. Asking "why" in a chain — with honesty and verifying each answer before moving on — shifts the focus from "whose fault was it" to "what part of the system allowed this to happen". It is a good first step for almost any specific problem; when the problem has too many possible causes acting at the same time, it is worth relying also on an Ishikawa or a more structured RCA.