5 whys

Origin

Taiichi Ohno (popularised); often attributed to Sakichi Toyoda, 1988 (English edition of Ohno's book)

Level

201 · Tool

Fits

Startup, Small and mid-size, Scale-up, Enterprise

Time to apply

45 to 60 minutes for one problem

What you need

one problem stated in a sentence, with a date and a place · the people who work in the process, not only their manager · a facilitator who stays neutral and writes the answers down

The 5 whys is a way to trace a problem back to a cause you can fix: you state the problem, ask why it happened, then ask why about the answer, and keep going. The Lean Enterprise Institute describes it as asking “why” repeatedly to get past obvious symptoms. It needs no software and no statistics, only people who know the process and about an hour. Its weakness is just as plain, and most of this page is about where it stops being reliable.

Where does the 5 whys come from?

It comes from Toyota, but the exact inventor is unclear. Taiichi Ohno, who built much of the Toyota Production System, wrote about asking why five times in his 1988 English-language book. Eric Ries says he learned the technique from that book before adapting it for startups.

Many guides credit Sakichi Toyoda, the loom inventor behind Toyota’s founding family. The Improvement Cymru guide, for one, says he developed it. Toyota’s own production system page links Toyoda to the automatic loom that stops itself when something goes wrong, which is the root of jidoka. We found no primary Toyota source that shows him asking why five times, so treat that attribution as a convention and not a documented fact.

Toyota’s use of the idea is wider than one technique. In a Harvard Business School interview, Steven Spear describes workers who learn to trace symptoms to underlying conditions with “sophisticated root-cause analysis” and then change the work itself. The interview does not name the 5 whys. The method is one visible tool in a habit of problem solving.

How does the 5 whys work?

You write the problem down and ask why, then ask why about each answer until you reach a cause you can act on. Ohno’s own example is a machine that stopped. The fuse blew from an overload. The bearing was not lubricated enough. The pump was not delivering enough. Its shaft was worn. Scrap got in because no strainer was fitted.

Stopping at the fuse means replacing it and waiting for the next failure. The Lean Enterprise Institute makes this point about the example: the repair that lasts is at the end of the chain. The method also pushes the question away from “who did this” and toward “what in the process allowed it”, which is why NHS England asks facilitators to stay neutral and to hold the session in a safe space.

Why five, and not three or seven?

Five is a rule of thumb. The Lean Enterprise Institute says the number is not the point, and the Institute for Healthcare Improvement calls it a guideline. NHS guidance says a team may need fewer or more.

Mark Graban has shown that Ohno’s own example does not follow its label. The first and last answers each bundle two causes, so unpacked the chain has seven links. He also argues the strainer is not the end: why could the machine run without one? That question leads to standard work and checks, which is where a lasting fix usually lives.

What does the 5 whys miss?

It can miss causes, because it follows a single path. Improvement Cymru warns that asking why can lead down one causal pathway, while problems in complex systems rarely have one cause. Its guide says the tool suits easier or moderate problems.

The sharpest critique comes from health care. Alan Card argued in BMJ Quality & Safety that the method is valuable for teaching but can oversimplify complex problems and limit understanding of how processes fail. A related paper by Peerally and colleagues names an over-focus on a single cause as one of the weaknesses of root cause analysis in general.

Nancy Leveson of MIT makes a structural point about chains of events. The search backward works until it finds something easy to prevent, so the stopping point is often arbitrary, and the cause chosen is often a human operator. James Reason’s work says the same from the other side: blaming individuals hides the conditions that keep producing the same error. The RCA2 guidance turns this into rules, including that a human error must have a preceding cause.

NHS guidance suggests pairing the two lightweight tools: use a fishbone to explore the possible causes, then use the 5 whys to drill into the ones that matter.

How do you turn the answer into a fix?

Fix each level, and size the effort to the cost of the problem. Eric Ries calls this proportional investment. In his outage example the chain produced five fixes, from restoring the site to training the developer, and he asks for a minimum and a maximum, so that small problems get small fixes. Google’s SRE book adds the cultural condition: a blameless review identifies contributing causes without indicting a person or a team, because people stop reporting problems if they expect punishment.

If the chain wanders because nobody agrees how the work really runs, draw the process first. A SIPOC shows the inputs, outputs and handoffs around the step that failed, and a BPMN map shows the decisions and exceptions in it. A Growth Lab plan starts from a map like that, so each “why” has a real step to point at: see Growth Lab.

How to apply 5 whys, step by step

1. Write the problem as a fact. State what happened, where and when, in one sentence. 'Payouts to merchants arrived after the cut-off on Tuesday' works. 'Operations is slow' does not. Result: a problem statement the whole group accepts.
2. Ask why and answer from evidence. Each answer should be something someone saw or can check in a log, a ticket or a record. NHS England's guide asks that answers be factual and witnessed by the person giving them. Result: a first cause backed by evidence, not opinion.
3. Ask why about the answer. Take the answer you just wrote and ask why again. Write each answer on its own line so the chain stays visible. Result: a written chain, one cause per link.
4. Stop at a cause you can act on. Stop when the answer is something your team can change and that, if changed, would have prevented the problem. That may be the third why or the seventh. Result: a cause with an owner.
5. Test the chain backwards. Read it from the bottom: if this cause is true, does it lead to the next one, all the way to the problem? Check for side branches you skipped. Result: a chain that holds, and a list of other branches to look at.
6. Fix each level and check later. Eric Ries, who taught the method to startups, asks for a fix at every level of the chain, sized to the cost of the problem. Set a date to check that the problem has not come back. Result: actions, owners and a review date.

Examples

A payments company: late merchant payouts

Illustrative. Why were payouts late? The review queue had a backlog. Why? The risk rule flagged too many payouts for manual review. Why? Its threshold was set at launch and never revisited. Why? Nobody owned the rule after the first release. Why? The launch checklist ended at go-live. Fix: name an owner, review the threshold quarterly, extend the checklist to a 30-day review. The first answer, a backlog, would have led to hiring another reviewer.

A hospital: a delayed cancer diagnosis

A documented case from the Improvement Cymru guide to the method. The diagnosis was delayed because the surgeon never saw the biopsy report. The report had been filed in a new section of the notes. The surgeon did not look there because nobody told the surgeons about the change. The root cause was that the doctors had not been consulted on the process change. The fix: copies of all biopsy reports now go straight to the responsible consultant.

A software startup: a site outage

A documented case from Eric Ries. The site went down because of an infinite loop in new code. The code shipped because it had no unit test. The developer wrote none because he was new and untrained in test-driven development. Ries's answer was five fixes, from restoring the site to adding the training to new-hire orientation.

When to use it

Use it for a recurring or costly problem with a short causal chain: a missed deadline, a defect, a failed release, a process step that keeps breaking. It suits a first pass, when you want to move from symptom to a fixable cause in an hour and the process is understood by the people in the room.

When not to use it

Do not rely on it alone for incidents in complex systems, such as patient harm or a payments outage with several interacting failures. NHS guidance describes it as a fairly superficial review of a simple problem, and critics argue it reduces complexity to one chain. Use a wider investigation, and do not use it to find who is to blame.

Common mistakes

• Stopping at a person. 'The analyst made a mistake' is a starting point. The RCA2 guidance says a human error must have a preceding cause, and a violated procedure is not a root cause either.
• Following one branch and calling it the cause. Improvement Cymru warns that asking why can lead down a single path while complex problems rarely have one cause. Ask who sees the problem differently.
• Answering from opinion. Each link needs evidence. Without it the chain reflects the loudest person's theory.
• Counting to five. Ohno's own chain bundles two causes in some answers, so it has seven links when unpacked. Stop when you can act, not when you reach five.
• Ending with a document. Without owners, dates and a check, the analysis changes nothing.

FAQ

What is the 5 whys method?

The 5 whys is a questioning technique: state a problem, ask why it happened, then ask why about that answer, and repeat until you reach a cause your team can fix. The Lean Enterprise Institute describes it as asking why to get past symptoms. Taiichi Ohno of Toyota is the person most associated with it.

Do you have to ask exactly five whys?

No. Five is a guide. The Lean Enterprise Institute says the number is not the point, and NHS guidance says it may take fewer or more. Stop when the answer is a cause you can act on and that would have prevented the problem.

Who invented the 5 whys?

Sources disagree. Many guides credit Sakichi Toyoda, the loom inventor and father of Toyota's founder. Others credit Taiichi Ohno, who described it in his 1988 English-language book on the Toyota Production System. Toyota's own production system page ties Toyoda to the loom behind jidoka, but we found no primary Toyota source describing him asking why five times.

What is an example of the 5 whys?

Ohno's example: a machine stopped. Why? A fuse blew from overload. Why? The bearing lacked lubrication. Why? The pump was not delivering enough. Why? Its shaft was worn. Why? Metal scrap got in because no strainer was fitted. Fitting a strainer fixes the cause, where replacing the fuse would not.

Why do critics say the 5 whys is flawed?

Alan Card, in a BMJ Quality & Safety paper, argued it can oversimplify complex problems and limit understanding of how processes fail, though it is useful for teaching. Nancy Leveson of MIT notes that the stopping point of a causal chain is often arbitrary, and the cause chosen is often a human operator.

Sources

1. Lean Enterprise Institute, 5 Whys (Lean Lexicon)
2. Mark Graban, Even Ohno's Classic 5 Whys Example Deserves Another Why, LeanBlog, 2026
3. Taiichi Ohno, Toyota Production System: Beyond Large-Scale Production, Productivity Press, 1988 (Internet Archive record)
4. Toyota Motor Corporation, Toyota Production System
5. Toyota Motor Corporation, 75 Years of Toyota: Kiichiro Toyoda invents the automatic loom
6. Institute for Healthcare Improvement, 5 Whys: Finding the Root Cause
7. Olivier Serrat, The Five Whys Technique, Asian Development Bank Knowledge Solutions, 2009
8. NHS England, Learning handbook: Five whys
9. Improvement Cymru Academy, The 5 Whys: a tool for root cause analysis, toolkit guide
10. Alan J. Card, The problem with '5 whys', BMJ Quality & Safety 26(8), 2017
11. AHRQ Patient Safety Network, The problem with 5 whys (commentary on Card, 2017)
12. Mohammad Farhad Peerally, Susan Carr, Justin Waring, Mary Dixon-Woods, The problem with root cause analysis, BMJ Quality & Safety 26(5), 2017
13. AHRQ Patient Safety Network, The problem with root cause analysis (commentary on Peerally et al., 2017)
14. Nancy Leveson, Safety III: A Systems Approach to Safety and Resilience, MIT Engineering Systems Laboratory, 2020
15. James Reason, Human error: models and management, BMJ 320(7237), 2000
16. National Patient Safety Foundation, RCA2: Improving Root Cause Analyses and Actions to Prevent Harm, 2015 (hosted by IHI)
17. Eric Ries, The Five Whys, guest post on Venture Hacks, 2008
18. Eric Ries, The Five Whys, Stanford Entrepreneurial Thought Leaders seminar, 2009
19. Steven J. Spear, H. Kent Bowen, Decoding the DNA of the Toyota Production System, Harvard Business Review, September 1999
20. Harvard Business School Working Knowledge, How Toyota turns workers into problem solvers (Steven Spear interview)
21. Google, Site Reliability Engineering, chapter 15: Postmortem culture

Last updated Oct 9, 2026

Ilia PushinFounder, PUSHERS & COO Fintech ServiceIlia builds operating systems for growing companies in fintech and healthcare. Since 2021 he has run cross-border payments at ARBI Exchange, a licensed currency exchange in Thailand, including KYC and AML and the move into new jurisdictions.About the authorLinkedIn