Five Whys

Origin & evolution

The technique originated at Toyota. Sakichi Toyoda, the founder of the company that became Toyota Industries, developed the questioning discipline in the 1930s, and it was later formalised as a core tool of the Toyota Production System by Taiichi Ohno, who described it in his writing on lean manufacturing. Ohno framed it as the scientific habit behind Toyota's approach to problems: repeating why five times to push past the obvious answer to the real one.

Ohno's own illustration is the canonical example. A machine stops. Why? A fuse blew from an overload. Why the overload? The bearing was not lubricated enough. Why? The lubrication pump was not pumping enough. Why? The pump shaft was worn. Why? There was no filter, so metal scrap got in. The fix that survives five whys is fitting a filter, not replacing the fuse. Replacing the fuse treats the surface; the filter addresses the cause.

How it works in practice

A team facing a recurring problem writes the symptom plainly, then works the chain together:

• Name the symptom precisely. Vague symptoms produce vague chains. "Deploys fail on Fridays" is workable; "things are flaky" is not.
• Ask why, and answer with evidence🔎EvidenceValidationData supporting or refuting a hypothesisView reference →. Each answer should be a cause you can point to, not a guess. If the answer is speculative, that is a signal to go and look before continuing.
• Make each answer the next subject. The discipline is that the chain stays single-threaded and causal, rather than fanning out into a list of everything that might be wrong.
• Stop at an actionable cause. The terminal answer should be something the team can change. If the last why lands on "human error" or "they were careless", push further: a good root cause🪝Root CauseEngineeringAn identified root cause of an issueView reference → names a process or condition, not a person.

A worked example. A SaaS team finds customer invoices💳InvoiceSales & RevenueAn invoice for billingView reference → are occasionally wrong. Why? Some line items use a stale tax rate. Why? The rate is cached and the cache is not invalidated when rates change. Why? Rate changes are applied directly to the database, bypassing the application that owns the cache. Why? There is no admin path for rate changes, so finance edits the table by hand. Why? The admin tooling was descoped at launch and never revisited. The root cause is a missing internal tool, not a bad cache, and that is a very different ticket from the one the symptom suggested.

When to use it (and when not)

Five Whys fits problems with a single dominant cause and a reasonably linear causal history: a specific defect, an outage, a process breakdown. It is fast, needs🫀NeedUserA user need, pain, desire, or constraintView reference → no tooling, and works well in a blameless conversation where people are willing to keep asking past the comfortable first answer.

It is the wrong tool for problems with many interacting causes, where a single chain oversimplifies and a fishbone diagram or a fuller causal analysis serves better. Its two classic failure modes are stopping too early, landing on a symptom dressed up as a cause, and drifting into blame, where the chain terminates at a person rather than the system that let the error through. The Toyota framing guards against the second: the goal is a process you can change, not a culprit you can name.

In the Unified Product Graph

Five Whys is a reflection framework in the team-process category. Its chain maps cleanly onto graph entities:

• The starting symptom is a need🫀NeedUserA user need, pain, desire, or constraintView reference →: the problem the team still has to solve.
• Each answer along the chain is an insight🔦InsightUser ResearchA synthesised finding from researchView reference →, linked in sequence so the causal path is preserved, not flattened.
• The terminal answer is the root-cause insight🔦InsightUser ResearchA synthesised finding from researchView reference →, the one the team will act on.

Holding the chain in the graph means the root cause is connected to the work that addresses it and to the symptom it explains. A later incident🚨IncidentDevOps & PlatformA production incidentView reference → with the same symptom can find the prior analysis instead of restarting it, and the reasoning survives past the meeting that produced it.