Reactify Solutions
HandbooksLean startup methodFinding root causes

Finding root causes

Five whys turns a technical fault into a human one, and tells you how much to invest in the fix. Plus when a fishbone is the better tool.

Product teams and foundersLast reviewed September 5, 2026
In one minute
  • Ask why five times. Technical problems nearly always end in a human cause: training, process, or an assumption nobody checked.
  • Invest in the fix in proportion to the size of the problem. Small fix for a small symptom.
  • Run it with everyone affected in the room, and blame the system rather than the person.
  • Use a fishbone instead when the problem has several causes at once rather than one chain.

Five whys

Start with the symptom and keep asking why until you reach something that is not technical.

Five whys, from symptom to a human cause
Symptom
Customers could not check out for two hours.
Why did the new release break checkout?
A server config was wrong.
Why was it wrong?
One engineer changed it by hand.
Why by hand?
There is no script for that change.
Why no script?
The person who set it up has left.
Why did nobody else know how?
Nobody was trained on that system.
Root cause
A training gap, not a bad config.
Five technical answers would have produced five patches. The fifth answer is the one that stops it happening again.

The first answer is always a machine. Somewhere around the fifth you reach a person, a process, or a missing piece of training. Stop at the first and you get a patch that holds until next time.

Invest proportionally

The rule that keeps this from becoming bureaucracy: make the size of the fix match the size of the problem.

A small outage gets a small fix at each level, not a six-month programme. Something serious earns more. The compounding effect comes from doing this consistently on small things, not from occasional grand responses to disasters.

Run it well

DoDo not
Get everyone affected in the roomRun it with only the person who made the change
Blame the system, not the personLet it become a search for who to fault
Agree a fix at each of the five levelsFix only the last one
Appoint someone to own the follow-upLet the actions sit in a document nobody opens
The failure mode is blame

The moment it feels like a hunt for the guilty person, people stop giving honest answers and the technique is finished. Ries is direct about this: be tolerant of all mistakes the first time, and never let the same mistake happen twice.

When to use a fishbone instead

Not from the book

Ries covers five whys and no alternative. The fishbone below is a standard quality tool, included because it fills the gap where five whys does not fit.

Ishikawa, the same outage grouped by kind of cause
People
Nobody trained on the system
On-call rotation had a gap
Process
No review step for config
Deploy checklist not followed
Tooling
No script for the change
No alert on checkout errors
Environment
Staging differs from production
Release ran late on a Friday
Effect
Checkout down for two hours
Five whys follows one chain. This spreads the same outage across every kind of cause at once, which is useful when the chain has more than one branch.

Reach for five whys when there is a clear chain from symptom to cause. Reach for a fishbone when several things went wrong together, or when the team cannot agree where to start looking.

Check it worked.

Take the last incident your team fixed. Ask why five times about it now. If the fifth answer is still technical, you stopped too early.

Last reviewed September 5, 2026 · verified against The Lean Startup, Eric Ries, 2011
PreviousEngines of growthNextInside an existing company