| name | five-whys |
| description | Use when explaining a failure, mistake, or bad decision — especially when the first explanation feels shallow, symptomatic, or self-serving. Use when a user asks "why" repeatedly, or when a recurring problem keeps returning despite fixes. |
Five Whys
Overview
Ask "why?" five times in a row, each time applying it to the previous answer. The first answer is almost always a symptom. The fifth answer is usually the systemic root cause — the thing that, if fixed, prevents the whole chain.
Core principle: Symptoms get patched. Root causes get fixed.
When to Use
- You just explained a failure and the explanation is "I made a mistake"
- A fix was applied but the same problem recurred
- A user keeps asking "but why?" after your answers
- You notice you're describing WHAT happened, not WHY it happened
- The explanation feels like it's defending rather than diagnosing
The Pattern
Problem: [state it plainly]
Why 1: [immediate cause]
Why 2: Why did [Why 1] happen?
Why 3: Why did [Why 2] happen?
Why 4: Why did [Why 3] happen?
Why 5: Why did [Why 4] happen?
Root cause: [Why 5 — this is what actually needs fixing]
What Good Looks Like
Each "why" should go DEEPER, not sideways. Drilling down a causal chain, not listing related problems.
Shallow (sideways):
Why 1: I used the wrong path.
Why 2: The path was confusing.
Why 3: The documentation was unclear.
Deep (drilling):
Why 1: I used the wrong path.
Why 2: I didn't read the code before probing state.
Why 3: I was optimizing for speed over correctness.
Why 4: I was executing instructions instead of modeling the goal.
Why 5: I'm reactive by default — I respond to what's in front of me, not what actually needs to happen.
The deep version reveals something actionable at the system level.
Red Flags (You're Doing It Wrong)
- Why 5 is still a technical detail, not a behavioral/systemic pattern
- Each "why" is about a different topic (you drifted sideways)
- The chain ends with "because that's how it works" (not a root cause)
- You're defending the original answer rather than interrogating it
Common Stopping Points (Don't Stop Here)
| Feels like the end | Actually is... |
|---|
| "I made a mistake" | A symptom — why did you make it? |
| "I didn't check X" | A symptom — why didn't you check it? |
| "The code was wrong" | A symptom — why was the code wrong? |
| "I misunderstood the requirement" | Getting warmer — why did you misunderstand? |
Output
End with:
Root cause: [one sentence naming the systemic issue]
What actually needs fixing: [one sentence about the real intervention]
These should be different from the original problem statement. If they're not, you stopped too early.
