In one line: The 5 Whys is a root cause technique that asks "why" a problem occurred, then asks why again on each answer, typically five times, until the questioning surfaces a fixable root cause rather than a symptom you would otherwise paper over with a quick fix.
Why Most Corrective Actions Don't Correct Anything
A machine stops. Someone replaces a blown fuse. Production restarts within ten minutes. Three weeks later, the same machine stops again.
This is the most common failure pattern in problem-solving: fixing the symptom and calling it the fix. Taiichi Ohno, the architect of the Toyota Production System, used exactly this fuse example to explain why. If you replace the fuse and stop there, you will have solved the problem only superficially, and the machine will fail again in a few months.
The 5 Whys exists to stop that cycle. It is not a statistical tool, not a piece of software, and not something that needs a calculator. It is a disciplined habit of refusing to stop questioning at the first answer.
Where the Technique Actually Comes From
The method predates Six Sigma by decades. It was developed by Sakichi Toyoda in the 1930s and became a core part of the Toyota Production System, later formalised by Taiichi Ohno as a way of teaching engineers to see past obvious causes. Toyota describes the underlying philosophy as the "scientific approach" to problem-solving: observe the problem directly, then repeatedly ask why rather than theorising about it from a desk.
That detail matters more than the number five. Ohno's own worked example runs through exactly five iterations, but the count is a guideline, not a rule. Some root causes surface on the third why. Others need seven or eight. The discipline is asking "why" again after every answer that still describes a symptom rather than a cause — not stopping at a fixed number.
Ohno's Fuse Example, in Full
The example every practitioner eventually learns is worth walking through completely, because it shows exactly where a lazy investigation stops and where a real one continues.
- Why did the machine stop? There was an overload and the fuse blew.
- Why was there an overload? The bearing was not sufficiently lubricated.
- Why was it not lubricated sufficiently? The lubrication pump was not pumping sufficiently.
- Why was it not pumping sufficiently? The shaft of the pump was worn and rattling.
- Why was the shaft worn out? There was no strainer attached, and metal scrap got in.
Stop at why one and you replace a fuse. Stop at why three and you might service a pump that will simply wear out the same way again. Only the fifth why produces an action — fitting a strainer — that actually prevents recurrence. That gap between "the fix that stops the immediate symptom" and "the fix that prevents the failure mode" is the entire value of the tool.
The Failure Mode Nobody Warns You About
The 5 Whys has a well-documented weakness: it is easy to do badly while feeling like you did it well.
Teams under time pressure frequently stop after two or three whys because the third answer sounds plausible and everyone is ready to move on. The technique offers no built-in check against this. There is no statistical test that tells you whether why number three is a real root cause or just a comfortable stopping point.
A second, subtler failure is single-path reasoning. Real failures usually have more than one contributing cause, but the classic 5 Whys format walks a single chain of causes as if only one existed. iSixSigma's reference material on the technique notes it works best on straightforward problems with one dominant cause chain — complex, multi-causal failures usually need a fishbone diagram or a full DMAIC investigation to map every contributing branch before the whys get applied to each one.
The practical guard against both failure modes is the same: insist that every answer is something you can verify with evidence — a broken part you can hold, a log entry you can point to, a measurement you can repeat — not an opinion about what "probably" happened. If an answer can't be verified, that's your actual next why.
Running a 5 Whys Session That Doesn't Fall Apart
A handful of ground rules separate a useful session from a wasted half hour.
Write the problem statement first, and be precise. "Quality is bad" is not a problem statement. "Batch 4471 shipped with 12 units failing the tensile test" is. Vague inputs produce vague root causes.
Get the people who were actually there. Root cause analysis done entirely from a manager's office produces theories, not causes. The operator who was running the line when it stopped knows things a report will never capture.
Answer each why with a fact, not a guess. If nobody in the room can verify an answer, that answer is not why number three — it is a hypothesis that needs checking before you continue.
Keep going until the answer points to a process, a system, or a standard — not a person. "The operator made a mistake" is very rarely a root cause. Ask why the process allowed that mistake to happen, why the training didn't prevent it, or why the equipment made the error possible. Blame ends investigations early; systems thinking keeps them going.
Confirm the fix would have actually prevented the original problem. Before closing the investigation, run the logic forward: if this fix had been in place before the failure, would it have stopped it? If the answer is "maybe," you haven't reached the root cause yet.
Where 5 Whys Fits Alongside Other RCA Tools
The 5 Whys is not a replacement for structured root cause analysis — it is usually the fastest first move inside it. On a straightforward, single-cause problem, five whys and twenty minutes is often all you need.
On a problem with several plausible contributing factors — a machine failure that could stem from maintenance, material, operator technique, or environmental conditions — the better starting point is a fishbone diagram to map every branch of possible causes, then apply the 5 Whys to each branch that survives scrutiny. Used together, the fishbone stops you tunnelling down one plausible-sounding chain while ignoring three others that were just as likely.
Either way, the same principle from Ohno's original example holds: the objective is never to find someone to blame. It is to find the point in the system where a fix actually breaks the failure loop.
The One-Line Test
Before you act on any root cause you've found, ask one more question: would a stranger, reading your five answers in order with no other context, agree that number five explains number one? If there's a logical gap anywhere in the chain, that gap is where the real work still needs to happen. Five whys is not a magic number. It is a commitment to keep asking until the chain actually holds.