5 Whys
5 Whys: Ask "Why did this happen?" five times in succession to drill from symptom to root cause. The first answer is usually a symptom; the fifth is usually an actionable cause you can actually fix. Used in manufacturing, software post-mortems, and management retrospectives to prevent recurrence rather than merely react to symptoms.
What Is the 5 Whys?β
The 5 Whys was developed by Sakichi Toyoda, founder of Toyota Industries, and became a cornerstone of the Toyota Production System (TPS) in the 1970s. Taiichi Ohno, the architect of TPS, described it as the foundation of Toyota's scientific approach: "By repeating why five times, the nature of the problem as well as its solution becomes clear."
The technique is deceptively simple: when a problem occurs, ask "Why?" and record the answer. Then ask "Why?" about that answer. Repeat until you reach a cause that can actually be fixed β typically around the fifth iteration. The goal is not exactly five questions (sometimes three suffice, sometimes seven are needed) but to keep asking until you reach an actionable root cause rather than stopping at a symptomatic answer.
The power of the method lies in resisting the pull of the obvious. Our cognitive systems are wired to act on proximate causes β the immediately visible trigger of a problem. A machine stops working; we restart it. A customer complains; we apologise. A deadline is missed; we add more hours. These responses address symptoms. The 5 Whys forces past the symptom to the structural or systemic cause that, if addressed, prevents the problem from recurring.
How It Worksβ
Step 1: Define the problem precisely
β Write a clear, specific problem statement
β "Production line stopped" rather than "something went wrong"
Step 2: Ask "Why did this happen?"
β Record the first causal answer
β Keep it factual, not interpretive
Step 3: Ask "Why?" again about the previous answer
β Drill into the cause, not the symptom
Step 4: Repeat until you reach root cause
β Root cause: an addressable systemic failure
β Signs you've gone deep enough: the answer is a process/system failure
Step 5: Verify the chain
β Read upward: "Because X β which caused Y β which caused Z β ..."
β The chain should read logically
Step 6: Design countermeasures at the root cause level
β Don't just fix the symptom; address the root
Three Real-World Examplesβ
Toyota Production Line Stopβ
The canonical Toyota example: a production robot stopped unexpectedly.
- Why did the machine stop? β Overload; fuse blew
- Why was there an overload? β Insufficient lubrication on bearings
- Why were the bearings insufficiently lubricated? β Lubrication pump wasn't circulating oil properly
- Why wasn't the pump working? β Pump intake was clogged with metal shavings
- Why was the pump intake clogged? β No filter was installed; none specified in maintenance procedure
The fix is not "replace the fuse." It's "install a filter and update the maintenance procedure." A fuse replacement addresses the symptom; the countermeasure addresses the root cause. Without the 5 Whys, the same failure would recur within weeks.
Software Deployment Failureβ
A critical API service went down in production at 2am.
- Why did the service go down? β Out-of-memory error on the primary server
- Why did it run out of memory? β A new feature shipped that day had a memory leak
- Why did a memory leak reach production? β It wasn't caught in code review or testing
- Why wasn't it caught in testing? β The staging environment doesn't simulate sustained production load
- Why doesn't staging simulate production load? β We never defined a policy requiring load testing before deployment
Fix: implement a load-testing policy for all memory-intensive features before production deployment. Not: blame the engineer.
Startup Missed Sales Targetβ
A B2B SaaS company missed its Q3 revenue target by 40%.
- Why did we miss the revenue target? β Pipeline conversion rate dropped from 22% to 11%
- Why did conversion drop? β A competitor launched a cheaper alternative in July
- Why did we lose deals to the cheaper alternative? β We couldn't articulate clear differentiation in bottom-of-funnel calls
- Why couldn't sales articulate differentiation? β We had no competitive battle card; reps were improvising
- Why was there no battle card? β Product marketing was allocated to a major conference, not competitive intelligence
Fix: create a competitive battle card process and resource allocation policy. Not: fire the sales team.
When to Use Itβ
β 5 Whys works well for:
- Post-mortems after operational failures (outages, defects, delivery failures)
- Repeating problems β "why does this keep happening?"
- Team retrospectives in agile development
- Any problem where "fixing the obvious thing" hasn't worked
β Be cautious when:
- The problem has multiple contributing causes (use Fishbone Diagram instead)
- You need to restore service before diagnosing (fix first, analyse after)
- The cause is genuinely random or external
| Pairs well with | Why |
|---|---|
| Fishbone Diagram | Fishbone maps multiple causal threads; 5 Whys drills one thread deep |
| Root Cause Analysis | 5 Whys is the simplest implementation of root cause methodology |
| Pre-mortem | Pre-mortem anticipates 5-Whys-type chains before problems occur |
| Scientific Method | 5 Whys generates hypotheses; scientific method validates them |
Common Misuses and Limitationsβ
Stopping at the first "good enough" answer. The most common failure: identifying a plausible cause and stopping. "The server ran out of memory" is a cause; it is not the root cause. Push past comfort to the systemic failure.
Treating people as root causes. "Because John didn't check the server logs" is not a root cause. John is a node in a system β ask why the system failed to support John. Was there no policy? No alerting? Was he overloaded? Humans are often proximate causes; systems are usually root causes.
Creating a single chain for multi-cause problems. 5 Whys produces a linear chain; many problems have branching causes. If multiple second-level causes seem equally relevant, use Fishbone Diagram instead.
Confirmation bias in the chain. Two different analysts can construct very different chains for the same problem. The chain reflects assumptions brought to the investigation. Validate by reading the chain backwards and checking each causal link.
Related Modelsβ
| Model | Relationship |
|---|---|
| Root Cause Analysis | 5 Whys is a specific technique within the broader RCA framework |
| Fishbone Diagram | Fishbone explores multiple causal branches; 5 Whys goes deep on one |
| Issue Tree | Issue Trees structure complex problems; 5 Whys diagnoses specific failures |
| Black Box Thinking | Black Box Thinking motivates the cultural practice of 5-Whys analysis |
Frequently Asked Questionsβ
Does it always have to be exactly five "whys"?
No. The "5" is a heuristic, not a rule. Some problems resolve in three; complex ones may require seven. The stopping criterion is reaching a cause that: (a) can be addressed by a specific countermeasure, and (b) if fixed, would prevent the problem from recurring. When you've reached that level, stop β whether at three or eight.
What's the difference between proximate cause and root cause?
A proximate cause is the immediate trigger: "the server crashed because of a memory overflow." A root cause is the deepest addressable systemic cause: "the server crashed because we have no load-testing policy." Proximate causes describe what happened; root causes explain why the system allowed it. Root causes are typically process, policy, or design failures β things that can be changed to prevent recurrence.
How do you prevent the 5 Whys from becoming a blame exercise?
Frame the inquiry as a systems audit, not a performance review. Use language like "what in our process allowed X to happen?" rather than "why did person Y do X?" When a person appears in the chain, ask what the system should have provided to prevent a reasonable person from making that mistake. Toyota's practice was to assume system failure before individual failure.
Further Readingβ
- Ohno, T. (1988). Toyota Production System: Beyond Large-Scale Production β the original source
- Liker, J.K. (2004). The Toyota Way β comprehensive treatment of TPS including 5 Whys
- Dekker, S. (2006). The Field Guide to Understanding 'Human Error' β systems thinking approach to fault analysis
Apply with AIβ
π Run a 5 Whys analysis on your problem with MindMax β
This page is part of the MindMax Mental Models Knowledge Base.