Five whys
The Five Whys is a problem-solving technique that identifies root causes by repeatedly asking "why" something happened. Developed within the Toyota Production System, the method looks beyond surface symptoms to uncover the fundamental issues that, if addressed, would prevent recurrence. The name comes from the observation that asking "why" about five times typically reaches a root cause.
Why it matters
Most problem-solving stops at symptoms. Something breaks, the team fixes the immediate issue, and everyone moves on - until it happens again. This reactive pattern wastes resources and frustrates teams who feel they're constantly firefighting.
The Five Whys breaks this cycle by forcing deeper investigation:
Symptoms vs. causes. The first "why" usually reveals a symptom. Subsequent whys move toward underlying causes that, once addressed, prevent entire classes of problems.
Simple and accessible. Unlike complex root cause analysis frameworks, anyone can apply the Five Whys. No special training or tools required.
Challenges assumptions. The questioning process often reveals assumptions the team didn't realize they held.
Creates shared understanding. Working through the whys together builds team alignment on what happened and what needs to change.
How it works
The technique follows a straightforward process:
Example
Problem: Users are churning after their trial period.
Why #1: Why are users churning after trial?
Because they didn't see enough value to pay.
Why #2: Why didn't they see enough value?
Because they never completed the core workflow our product is designed for.
Why #3: Why didn't they complete the core workflow?
Because most trial users abandoned during onboarding before reaching that point.
Why #4: Why did they abandon during onboarding?
Because our onboarding asks for too much information before showing any value.
Why #5: Why does onboarding ask for so much information?
Because we copied our competitor's flow without validating whether it works for our users.
Root cause: Onboarding design decisions were made without user validation.
Countermeasures: Redesign onboarding to deliver value earlier; implement user testing for critical flows.
When to use five whys
The technique is most valuable for:
Limitations
The Five Whys has known limitations:
Single cause bias. The linear questioning can lead to single root causes when multiple causes exist. Complex problems often have multiple contributing factors.
Depends on knowledge. The answers are only as good as the team's knowledge. If the team doesn't know why something happened, asking won't help.
Can stop too early. Teams may accept an answer before reaching the true root cause, especially if the answer is comfortable or convenient.
Can go too far. Pushing beyond actionable causes ("Why do humans make mistakes?") isn't useful.
Blame risk. Without careful facilitation, the questioning can feel accusatory and lead to defensive responses.
Best practices
Several practices improve Five Whys effectiveness:
Focus on systems, not people. Ask why the system allowed the problem, not who caused it. "Why did the deploy go out without tests?" not "Why didn't you run tests?"
Involve people with knowledge. Those closest to the problem know the most about what happened.
Accept multiple branches. When a "why" has multiple valid answers, explore each branch.
Verify answers. Don't accept speculation. Confirm that answers reflect reality.
Document the process. Write down each why and answer. This creates a record and ensures shared understanding.
Connect to action. The goal isn't just understanding - it's prevention. Ensure the process results in concrete countermeasures.
Tools like Klero can support Five Whys analysis by providing data on user behavior and feedback that helps answer why users experience problems. When analysis is grounded in real user data, root causes become clearer.
