The 5 Whys: Find the Root Cause of Any Problem (With Examples)

What are the 5 Whys?

The 5 Whys is a way to get past the symptom of a problem to its root cause. You state what went wrong, ask why, and keep asking why of each answer until you reach a cause you can actually fix so the problem does not return.

The number five is a rule of thumb, not a law. The real rule is: do not stop at the first answer. The first answer is usually the symptom (“the server crashed”). The useful answer is usually a few levels down (“we have no alert when the disk fills up, because nobody owns monitoring”).

It is popular because it needs no software, no training and no statistics. A team and a whiteboard are enough.

Where it comes from

The 5 Whys is credited to Sakichi Toyoda, the inventor and industrialist whose company, Toyoda Automatic Loom Works, gave rise to the Toyota Motor Corporation. It became a standard practice inside the Toyota Production System, the manufacturing approach developed largely by engineer Taiichi Ohno.

In his book Toyota Production System: Beyond Large-Scale Production (published in Japanese in 1978 and in English in 1988), Ohno describes repeating why five times as the basis of Toyota’s scientific approach. His example is a machine that stopped working:

1. Why did the machine stop? There was an overload and the fuse blew.
2. Why was there an overload? The bearing was not sufficiently lubricated.
3. Why was it not lubricated? The lubrication pump was not pumping enough.
4. Why was it not pumping enough? The pump shaft was worn and rattling.
5. Why was the shaft worn? There was no strainer attached, and metal scrap got in.

Replacing the fuse would have fixed the symptom. Attaching a strainer fixed the cause. The method later spread well beyond manufacturing, into lean management, Six Sigma, software incident reviews and healthcare.

How to use the 5 Whys

1. Write a specific problem statement. “Order #4512 shipped three days late,” not “shipping is bad.” Specific problems produce specific answers.
2. Ask why and write the answer. Base each answer on evidence: logs, data, what people saw. If you are guessing, mark it and go check.
3. Ask why of that answer. Keep going. If an answer has two causes, split the chain and follow both.
4. Stop at a process you can change. A good root cause is something in your control that, if fixed, would have prevented the problem. “Human error” is never a stopping point: ask why the process allowed the error.
5. Fix it and check. Assign the fix to someone with a date, then confirm later that the problem has not come back. If it has, your chain missed something.

When you suspect several interacting causes, combine the method with feedback loops thinking: some root causes are loops, not chains.

3 real-world examples

Business

Say an online store receives a wave of complaints about wrong items. Why? Pickers grabbed the wrong product. Why? Two products with similar names sit next to each other. Why? Shelf locations are assigned by arrival date, not by similarity. Why? Nobody owns the warehouse layout; it grew over time. The fix is not “tell pickers to be careful” but a layout rule and an owner. (A hypothetical example.)

Personal life

You keep missing your morning workouts. Why? You are too tired at 6 a.m. Why? You go to bed after midnight. Why? You watch videos in bed. Why? Your phone charges on the nightstand. Moving the charger to the kitchen is a small, concrete fix at the level of the system, rather than a promise to “have more discipline.” Three or four whys are often enough for personal problems.

Tech

Software teams use the 5 Whys in blameless postmortems. Why did the site go down? A database ran out of connections. Why? A new feature opened a connection per request. Why? The code review did not catch it. Why? There is no automated check for connection usage. Why? Performance testing is not part of the release process. The final fix (add a performance check to the release pipeline) protects against a whole class of future bugs, not just this one.

Common mistakes

• Stopping at a person. “Because Sam forgot” is where most bad 5 Whys sessions end. It feels like an answer but changes nothing. Blaming individuals over situations is the fundamental attribution error; ask why the system let Sam forget.
• Following one chain when there are several. Complex failures often have multiple contributing causes. Branch the chain when answers split.
• Guessing instead of checking. Each answer should rest on evidence. A chain of plausible guesses can lead confidently to the wrong root cause.
• Going too far. “Why? Because the universe tends toward entropy” is true and useless. Stop at the deepest cause you can act on.
• Never closing the loop. A root cause without an owner and a follow-up check is just a story.

5 Whys vs fishbone diagram

Many teams use both: a fishbone diagram to list candidate causes, then the 5 Whys to dig into the most likely ones.

The Mentarium take

The 5 Whys is the best example we know of a simple tool that is usually run badly. The question is easy. The discipline is in where you stop. Our rule: you are not done until the answer is a process, a design or an incentive, never a person and never a vague trait like “communication.” If the root cause has no owner, ask one more why.

It also works on decisions, not just failures. At the Review step of the Mentarium Decision Loop, when an outcome differs from your prediction, run three to five whys on the gap. Was it bad luck, a wrong assumption, missing information or a bias? Combined with first-principles thinking and the theory of constraints, it gives you a repeatable way to find what is really holding a system back.

Two practical tips for running a session with a team. First, write the chain where everyone can see it, so each answer can be challenged before the next why is asked. Second, invite at least one person who was close to the work, not only managers. Root causes often live in details that only the people doing the job know, like a workaround everyone uses or a tool that quietly fails. A session without them tends to produce a tidy chain that points at the wrong cause. Finally, keep the tone blameless. If people expect the chain to end with their name, they will stop offering the honest answers the method depends on, and every session will quietly end one why too early.