The five whys technique finds the root cause of a problem by asking "why" repeatedly, using each answer to generate the next question, until the chain reaches a cause that is specific and fixable. It was developed at Toyota as part of its production system and has stayed popular because it needs no software, no training beyond the concept itself, and can be run in a hallway conversation as easily as a formal meeting.
What changed in 2026
- The rigid "exactly five" framing relaxed further. More teams treat five as a typical number rather than a target, stopping when the chain reaches an actionable process cause, which sometimes happens at why three and sometimes takes seven.
- Five whys increasingly gets paired with a written fact-check step. Rather than answering each why from memory or intuition, more teams now require a data point, log entry, or direct observation behind each answer before moving to the next question.
- Async, written five-whys chains became more common. Distributed teams increasingly build the chain in a shared document over a day rather than in a single live meeting, which slows the process but improves the evidence behind each step.
How to run it
- State the problem specifically. "Customer X canceled their subscription the day after a failed payment retry" beats "we are losing customers."
- Ask why it happened, and answer with a fact, not a guess. "The payment retry failed because the stored card had expired."
- Ask why again, using the previous answer as the new question. "The card expiry was not caught earlier because no check runs before the renewal date."
- Keep going until the answer names a process, system, or decision you can actually change. "There is no automated expiry check ahead of renewal."
- Stop there and design a fix for that specific gap — in this example, adding an expiry check ahead of the renewal date, not just telling the support team to be more careful.
A worked example
| Why |
Question |
Answer |
| 1 |
Why did the customer churn |
Their subscription payment failed and was not recovered |
| 2 |
Why was it not recovered |
The retry used an expired card with no fallback prompt |
| 3 |
Why was the card expired |
No expiry check ran before the renewal date |
| 4 |
Why was there no expiry check |
The renewal flow was never built with an upfront check |
| 5 |
Why was it built that way |
The original spec assumed cards would fail rarely enough to handle manually |
The fixable root cause is not "the customer forgot to update their card," it is the missing upfront check, a process gap the team can actually close.
Where five whys goes wrong
The most common failure is a chain that drifts sideways instead of going deeper — each "why" answers a slightly different question rather than building on the previous answer, and the chain arrives at an unrelated observation instead of a cause. The second common failure is stopping at a person rather than a process: "why did the bug ship" answered with "the engineer missed it in review" is rarely a true final answer. The next why, "why did review not catch it," usually leads somewhere more useful and more fixable. When a problem has several plausible, unrelated causes rather than one linear chain, a fishbone diagram usually works better than forcing everything through a single five-whys chain.
FAQ
Does the technique always take exactly five whys?
No. Five is a typical number based on experience, not a hard rule. Stop when the answer is specific and fixable, whether that takes three iterations or eight.
Can five whys be used by one person, or does it need a group?
Either works. A group tends to catch weak or assumed answers faster; a single person can still run a useful chain if they are honest about checking facts rather than guessing.
What is the difference between five whys and a full root cause analysis?
Five whys is one technique used inside a root cause analysis. RCA is the broader process, including defining the problem, gathering facts, choosing a technique, and verifying a fix, that five whys fits inside.
What if two different whys seem equally valid at some step?
That is a sign the problem has more than one contributing cause. Branch into separate chains for each, or switch to a fishbone diagram to capture multiple causes at once.
Where to go next