five-whys

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.