5 Whys

What it is

5 Whys originated at Toyota. Sakichi Toyoda — Toyota’s founding patriarch — is usually credited with the shop-floor form sometime in the 1930s, though primary documentation of that era is sparse. What’s better documented is that Taiichi Ohno built the Toyota Production System around the technique through the 1950s and then wrote about it in Toyota Production System: Beyond Large-Scale Production (Productivity Press, 1988), where his framing is pithier than most textbook descriptions: observe the workplace without preconceptions, and repeat “why?” five times to every matter.

The technique is deceptively simple. You state a problem and ask why it happened. You write the answer. You ask why that happened. You keep going. The point isn’t to get to exactly five layers — it’s to get past the first answer (which is usually a symptom or the nearest cause) and reach something systemic enough that fixing it would actually prevent the problem from recurring.

A typical 5 Whys runs like this:

That’s six whys, not five. Nobody cares. What matters is that the last answer — “no one owns SSO test fixtures” — is something you can do something about. Assign an owner. Budget the setup. That’s a real action. Contrast that with the first answer, “we had to redo the auth flow,” which would produce an action like “test the auth flow more carefully next time,” which is worthless.

When to use it

Use 5 Whys when:

• The causal chain from symptom to root cause is relatively linear. One thing led to the next led to the next.
• You have 5–10 minutes and need a fast, structured way to push past the first answer.
• The people in the room actually know the technical details. 5 Whys without domain knowledge just produces fantasy fiction.

Don’t use 5 Whys when:

• Multiple independent factors contributed to the failure. 5 Whys will tunnel-vision onto one branch and miss the rest. Use a fishbone diagram instead.
• The problem is poorly understood. 5 Whys assumes the symptom is well-characterized; if the team is still arguing about what happened, start with observation (Gemba walk, journey mapping) before asking why.
• The answers are going to be speculative. “Why did the customer abandon the checkout?” is not a 5 Whys question unless you’ve actually talked to the customer or have behavioral data.

The rework workshop uses 5 Whys as one of its two default root-cause techniques for rework cases where the story is relatively simple. When a case has multiple contributing factors, the guide recommends fishbone instead.

How to run it

Total time: 5–10 minutes per problem. Ten if you’re thorough and taking notes.

State the problem (30 seconds). One sentence. Specific. With measured impact. “The team missed the sprint goal this week” is fine. “We suck at sprints” is not — there’s nothing to ask why of.

Ask why (30 seconds). It doesn’t have to be a literal “Why?” Wait for an answer. Write it down verbatim. Don’t paraphrase — the exact phrasing often contains the thread to the next layer.

Ask why again (30 seconds × 4 or 5). Keep going. Write each answer.

Pause at each step and check: Does this answer feel like it’s a symptom or a cause? Symptoms are typically nouns that describe events (“the test failed,” “the PR wasn’t reviewed”). Causes are typically conditions or absences (“we don’t have a review-rotation schedule,” “there’s no owner for the test suite”). When you reach a condition or absence, you’ve probably reached a root.

Stop when you reach a cause you can act on. The test for this is: can you draft an action item from this? If yes, stop. If not, ask why once more. The cause should be specific enough to assign to a person and measurable enough to know whether the action worked.

Capture the chain. Write it as a linear sequence (an arrow-chain format works well). This matters because the chain itself is an artifact — if you come back to this problem in three sprints and the actions didn’t stick, you can re-examine the chain to see where your thinking was wrong.

Worked example

The rework workshop’s worked example produces this chain when the team investigates the root cause of its checkout-flow rework:

The action this produces: Add a mid-sprint customer-facing review (30 min, Wednesday of week 2). Owner: the PO. Expected recovery: ~8 hours per sprint.

Why this chain works. The final answer is a systemic condition — “no ritual exists” — that a concrete action can address. Contrast with stopping at the second why (“monthly demos are our only touchpoint”): the action there would be “have more demos,” which is vague and probably wouldn’t land. The chain had to go five layers deep to surface something actionable.

Common failure modes

• Stopping too early. The first why usually produces a symptom, not a cause. Teams that stop after one or two whys end up with action items like “try harder” or “pay more attention.” Keep going.
• Going too far. At some point the chain reaches “because that’s how our industry works” or “because humans are imperfect” — causes so systemic they’re not actionable. Stop one layer above that.
• Following the wrong branch. At any layer, there might be two or three valid “why” answers. 5 Whys picks one and follows it; it doesn’t exhaustively explore. If the team has an active debate about which branch to follow, that’s a signal: you should probably switch to a fishbone, which is built to track multiple branches simultaneously.
• Treating the chain as the answer. The chain isn’t the output. The action generated from the root cause is the output. If the chain produces a root cause nobody wants to own, nothing useful has been produced yet.
• Speculation masquerading as causation. “Why did the user abandon the form?” “Because the form is confusing.” “Why?” “Because UX didn’t test it.” These might all be true, but they might all also be stories the team is telling itself without evidence. If you don’t know why, say “we don’t know” and add “find out” as the action.

References

In the playbook

• Rework workshop — uses 5 Whys as one of two default root-cause techniques (fishbone is the other).
• Planning workshop — runs 5 Whys on the top three planning-waste sources.
• My formula for running a successful workshop — the meta-framework every workshop follows.

External references

• Taiichi Ohno, Toyota Production System: Beyond Large-Scale Production (Productivity Press, 1988) — the canonical treatment by Ohno himself.
• Sakichi Toyoda, attributed as the original formulator of 5 Whys in the 1930s. No single primary source exists; the technique is preserved through the Toyota Production System literature.
• Taiichi Ohno with Setsuo Mito, Just-In-Time for Today and Tomorrow (Productivity Press, 1988) — an earlier and often-overlooked English-language treatment.
• Lean Enterprise Institute, 5 Whys — the modern reference with case studies.
• American Society for Quality, 5 Whys root cause analysis — practical facilitator guidance.