5 Whys

Trace a problem beyond its first explanation—but treat every “why” as a hypothesis to verify.

In one minute

5 Whys starts with a specific problem and repeatedly asks why it occurred. Each answer becomes the subject of the next question.

“Five” is a prompt, not a required count. Stop when the team reaches a cause that:

• is supported by evidence;
• explains the observed pattern;
• can be acted on at the right system level;
• would reduce recurrence if changed.

The method is fast and useful for a focused causal chain. It is weak when the problem has several interacting causes or when the team guesses instead of investigating.

Best for: a bounded, recurring issue with a short causal path.
Avoid when: safety, legal or technical complexity requires a formal investigation.

The problem it addresses

Teams often stop at the first visible cause: “the file was wrong,” “the employee forgot,” or “the customer entered bad data.” 5 Whys encourages another level of explanation and can reveal process design, information or control issues.

The intended outcome is a testable causal chain and a next action—not certainty produced by repetition.

When to use it

• during an early Root Cause Analysis;
• when a problem is clearly defined and evidence is accessible;
• when the likely chain is relatively linear;
• when a team needs to move beyond a symptom quickly;
• to deepen one branch of an Ishikawa diagram;
• to identify where further data collection is needed.

When not to use it

Do not rely on 5 Whys:

• for a major incident as the only investigation method;
• when several branches interact;
• when participants lack knowledge of the work;
• when answers are opinions without evidence;
• when the questioning turns into “why did you fail?”;
• when a preferred solution is already driving the chain.

Inputs required

• a neutral, observable problem statement;
• people who know the process;
• relevant records, logs or direct observation;
• a facilitator or note-taker;
• permission to branch when more than one cause is plausible.

Step-by-step process

1. State the problem

Include what, where, when and extent. Do not include an assumed cause.

2. Ask the first why

Ask why the specific event or condition occurred. Record more than one answer if evidence supports branches.

3. Demand a mechanism

For each answer, ask how it produced the previous event. “Poor communication” is not enough; identify what information was missing, where and when.

4. Check evidence

Mark each link:

• verified;
• plausible but unverified;
• contradicted;
• unknown.

Pause to collect data instead of building a confident chain from assumptions.

5. Continue to an actionable system cause

Ask why again until the chain reaches a controllable condition at an appropriate level. More or fewer than five questions may be necessary.

6. Test alternatives

Ask what else could explain the pattern. If causes branch significantly, move to an Ishikawa diagram or broader RCA.

7. Link action to cause

Choose an action that changes the verified condition and define an outcome measure.

Visual model

Text alternative: repeated why questions move from an observed problem through deeper conditions. Evidence must support every link before action is selected.

Interactive example

Scenario

Problem: 126 appointment reminders were sent with an old appointment time after rescheduling.

Worked chain

1. Why was the old time sent?
   The reminder job read the original booking record.
2. Why did it read the original record?
   The reschedule flow updated a new schedule table but did not update the reminder read model.
3. Why was the read model not updated?
   The new event handler omitted the reminder projection.
4. Why was the omission released?
   The integration test covered new bookings but not rescheduled bookings.
5. Why was that path absent?
   The release checklist did not map downstream consumers for changed scheduling events.

Possible actions:

• fix and backfill the projection;
• add reschedule integration coverage;
• add a downstream-consumer check to event-change reviews;
• monitor time mismatches before reminders are sent.

The fifth answer is not “the root cause” by magic. The team must verify the test and review-process evidence and may find additional branches.

Facilitation notes

• Use “what made this possible?” if repeated “why?” sounds accusatory.
• Keep the problem statement visible.
• Ask for records or observations at every link.
• Let the chain branch; forcing one line can hide interacting causes.
• Stop if the discussion leaves the team’s evidence or scope.

Expected output

• a defined problem;
• one or more causal chains;
• evidence status for each link;
• open questions and alternative causes;
• a verified actionable cause or a decision to use broader analysis;
• corrective action and outcome measure.

Common mistakes

1. Stopping after exactly five questions regardless of evidence.
2. Following one linear story for a multi-causal problem.
3. Accepting labels such as “carelessness” or “poor process.”
4. Asking why in a blaming tone.
5. Building the chain from memory alone.
6. Ending at a cause outside any useful control.
7. Choosing an action before verifying the chain.

Quality checklist

• The starting problem is observable and scoped.
• Every answer explains the previous link through a mechanism.
• Evidence status is recorded.
• Alternatives and branches were considered.
• The chain did not stop at human error.
• The selected action changes a verified condition.
• An outcome measure tests whether recurrence falls.

Template

Knowledge check

When should a 5 Whys chain stop?

A. After the fifth question.
B. When the team reaches the first person involved.
C. When a verified, actionable system cause explains the pattern—or when a broader method is needed.
D. When the facilitator proposes a solution.

Answer: C. The number five is a heuristic, and evidence determines whether the chain is useful.

Related tools

• Supports: Root Cause Analysis
• Often combined with: Ishikawa Diagram
• Followed by: PDCA or corrective-action verification
• Not to be confused with: a complete investigation for complex events

References

1. Ohno, T. Toyota Production System: Beyond Large-Scale Production. Productivity Press, English edition 1988. ISBN 978-0-915299-14-0. Primary practitioner account of Toyota’s problem-solving approach.
2. American Society for Quality. “Five Whys and Five Hows.” ASQ guide (opens in a new tab). Authoritative professional procedure and usage guidance.
3. Toyota Motor Corporation. “Basic concept of the Toyota Production System.” Toyota history (opens in a new tab). Primary organisational context for Toyota Production System development.

Sources reviewed 27 July 2026.