Five Whys
The Five Whys is a root-cause analysis technique in which a team asks "why?" repeatedly about a problem, using each answer as the basis for the next question, until it reaches the underlying cause instead of a surface symptom. Associated with Taiichi Ohno and the Toyota Production System, it is widely used by product teams to diagnose problems and incidents.
How the Five Whys Works
The method is simple:
- State the problem clearly and specifically.
- Ask why it happened, and answer from facts, not guesses.
- Take that answer and ask why again.
- Continue until the answer points to a cause that, if removed, would stop the problem from recurring.
- Agree on a countermeasure for that root cause.
The number five is a rule of thumb, not a requirement. The Lean Enterprise Institute stresses that the point is to keep asking until the real root cause is found. Some problems need three whys, others more than five.
Ohno's own illustration was a machine that stopped working. The questions led from a blown fuse, to a bearing without enough lubrication, to a pump that was not supplying enough oil, to a worn pump shaft, and finally to metal scrap getting into the pump because there was no strainer. Replacing the fuse would have fixed the symptom. Adding a strainer fixed the cause.
Why the Five Whys Matters
Product teams often react to symptoms: a drop in sign-ups, a spike in support tickets, a missed release. Fixing a symptom brings short-term relief, but the problem returns. The Five Whys pushes the team toward a cause it can actually change.
It is useful in discovery too. When a customer asks for a feature, asking why a few times often uncovers the underlying job to be done or pain, which may point to a simpler solution. It pairs well with writing a clear problem statement and is a common part of blameless incident reviews and retrospectives.
The technique has limits. It follows a single chain of cause and effect, while many problems have several contributing causes. Answers can also drift toward blaming a person rather than a process. Teams get better results when each answer is backed by evidence, when they explore more than one branch if needed, and when they treat "someone made a mistake" as a reason to ask why the system allowed it.
Five Whys Example
A SaaS team notices that many trial users never connect a data source, the step that makes the product useful.
- Why don't trial users connect their data? Most of them stop at the connection screen.
- Why do they stop there? The screen asks for an API key they do not have.
- Why don't they have one? In most companies, only an administrator can create API keys.
- Why does that block them? The product offers no way to invite the administrator or keep exploring without connecting.
- Why not? Onboarding was designed on the assumption that the person signing up is the administrator.
The root cause is a design assumption, not low motivation. The team adds an "invite your admin" step and lets users explore sample data while they wait, then checks whether more trials reach a connected data source.