An incident takes the service down, and the minutes record: “someone forgot to run the migration”. Everyone agrees to pay more attention, and the matter closes. Two months later, the problem comes back with someone else.
The first explanation is usually true and insufficient. It describes what happened, but not why the system allowed it to happen. Asking “why?” a few times in a row is a simple way out of that surface, as long as each answer gets verified.
What the 5 Whys are
The technique investigates a problem through linked questions: each answer becomes the subject of the next question, until you reach a mechanism that can be fixed and tested.
The method is tied to the Toyota Production System. Taiichi Ohno described it as the basis of Toyota’s scientific approach, in which repeating why five times makes both the problem and its solution clear (Ohno, 1988). Sources disagree on its exact origin, and some attribute it to Sakichi Toyoda.
When to use it and when to avoid it
When to use it
- Incidents and operational failures with a defined scope
- Recurring quality problems and rework
- To go deeper into a hypothesis already backed by data
- In postmortems, as part of the analysis
When to avoid it
- On problems with many interlinked causes, when used alone
- When there is no data, logs or reports to back the answers
- In a blame-seeking environment, where people defend themselves
- To widen the field of hypotheses: the fishbone works better
How to apply it
- Describe the observable problem. Include the metric, period and impact, without embedding a cause.
- Ask why and answer with facts. Record the evidence for each answer. If there is none, mark it as a hypothesis and go verify it.
- Test the link from the bottom up. Read the chain in reverse using “therefore”. If the sentence doesn’t make sense, the link is weak.
- Open parallel chains. When there is more than one plausible answer, follow each separately.
- Stop at something fixable. A process, requirement or tool under the team’s control. Define the action and how to detect recurrence.
Example: accounts connect data but don’t generate results
After an AI assistant launched, a SaaS platform’s activation fell from 40% to 30%. Breaking down the funnel showed the loss is in accounts that connect data but don’t generate a first result. The fishbone diagram pointed to two main hypotheses, and each one became a chain.
Chain A: slow first generation
| Why? | Answer | Evidence |
|---|---|---|
| Why don’t accounts generate a result? | They abandon the first generation before it ends | Start events with no end |
| Why do they abandon it? | The first generation is much slower than later ones | Latency logs |
| Why is it slower? | The data index is built on the first request | Code and tracing |
| Why is it built at that moment? | Indexing on connection was cut to meet the deadline | Planning record |
| Why didn’t the effect show up earlier? | Tests used small accounts, and there is no latency requirement | Test plan |
Chain B: empty screen
| Why? | Answer | Evidence |
|---|---|---|
| Why do some accounts never start a generation? | The assistant opens empty, with no suggestions | Session recordings |
| Why does it open empty? | The examples were dropped in the new onboarding | Change history |
| Why were they dropped with no alert? | Onboarding reviews don’t track activation | Review minutes |
The second chain stopped at three whys because it had already reached a fixable process. Forcing two more levels would only produce invented answers.
Reverse-reading test on chain A: “There was no latency requirement, therefore indexing later seemed acceptable, therefore the first generation became slow, therefore accounts abandon it”. The sentence holds up.
The two chains produce these actions:
- Index data in the background, right after the connection.
- Create a latency requirement for the first generation and test with large accounts.
- Make activation a mandatory criterion when reviewing onboarding changes.
- Create an alert to detect the slowness coming back.
The causes are still well-supported hypotheses. A hypothesis test will show whether the fixes recover activation.
Avoid looking for culprits
When a chain ends in “the person made a mistake”, it has usually stopped too early. The useful question is what made that mistake possible and easy to make. Google’s postmortem culture follows this line: the analysis looks for the causes that contributed to the incident without accusing people or teams, and it assumes everyone acted in good faith with the information they had (Google SRE).
Besides being fairer, this improves the analysis, because people who fear punishment hide information.
The technique’s limits
The 5 Whys have serious critics. Card (2017), writing about patient safety, argues that a single chain offers a narrow view of a complex causal pathway, that the fifth why is an arbitrary stopping point and that the technique’s popularity doesn’t come from evidence of effectiveness. His conclusion is that it shouldn’t be used for root cause analysis in healthcare, a highly complex setting. It’s also common for different people to reach different causes for the same problem.
These criticisms don’t cancel the technique, but they bound its use: it works well for contained problems and for disciplining the conversation, especially with parallel chains, evidence at each link and the support of a wider map. In critical systems, it doesn’t replace a full technical investigation.
How to use an LLM
An LLM helps organize an incident report, suggest questions, point out logical leaps and open alternative chains. It doesn’t know what happened in your system, so it tends to complete the chain with plausible answers. Demand evidence at every link.
Help me investigate the root cause of [observable problem].Metric, period and magnitude: [describe].Data, logs, interviews and recent changes: [describe].
Run a 5 Whys analysis, but don't force exactly five steps if theevidence calls for more or fewer. If there are parallel causes,create separate chains.
For each causal link, state the evidence, the doubts and how we couldverify the hypothesis. If there is no evidence, write "unverifiedhypothesis" instead of completing the chain.
End with corrective actions for systems or processes, owners andmeasures to detect recurrence. Don't turn the analysis into blame.Expected output: verifiable causal chains, with corrective actions and recurrence signals.
Before trusting the answer:
- Check every link. Confirm that the cited evidence exists and really supports the answer.
- Ask for an alternative chain. Ask what other explanation would fit the same data.
- Do the reverse reading. Read the chain from the bottom up using “therefore”.
- Sanitize the context. Remove names, customer data and secrets from logs before pasting.
Combine it with other frameworks
- Fishbone diagram: maps hypotheses in breadth before going deep on each chain.
- Hypothesis testing: checks whether the fix really solves the problem.
- Pre-mortem analysis: anticipates plausible failures before execution, while the 5 Whys investigate observed problems.
- Decision matrix: compares corrective actions when there is more than one candidate.
References
- Ohno, T. (1988). Toyota Production System: Beyond Large-Scale Production. Portland, OR: Productivity Press.
- Card, A. J. (2017). The problem with ‘5 whys’. BMJ Quality & Safety, 26(8), 671–677. DOI
- Google. Site Reliability Engineering, chapter “Postmortem Culture”. O’Reilly Media. Link
- Wikipedia. Five whys. Link