5 Whys Technique: How to Use It (With Examples)

Quick answer

The 5 Whys is a root cause analysis technique in which you state a problem precisely, ask why it happened, then ask why of each answer, until you reach a cause that is both systemic and fixable. Its value comes from discipline, not from the number five: each answer must be verified against evidence, and the final cause must lead to an action that prevents recurrence.

What is the 5 Whys technique?

It is a structured questioning method that walks from a visible failure down to the process or design condition that allowed it. You start with a factual problem statement, ask why, and treat each answer as the new problem.

The technique was developed by Sakichi Toyoda and used within Toyota Industries as part of the evolution of the Toyota Production System. Taiichi Ohno, who architected TPS, described it as the basis of Toyota’s scientific approach: by repeating why five times, the nature of the problem and its solution become clear. Toyota compressed this into a phrase — five whys equal one how.

One detail is often lost: the method was initially developed to understand why a new product feature or manufacturing technique was needed. It was not designed as an accident investigation tool, which is exactly where it is most often applied today.

The mechanics are simple enough to run on a whiteboard: state the problem as an observed fact, ask why, answer with a mechanism rather than a person, verify the answer against logs or direct observation, and repeat. The discipline sits in the verification, the stopping rule, and the countermeasure that follows. Those are the steps most teams skip, and that is why the method has a reputation problem.

How do you run a 5 Whys session without wasting an hour?

Run it with three to five people who touched the work, one facilitator, one evidence source open on screen, and a hard 45-minute time box. The facilitator’s job is to reject unverified answers, not to produce them.

Step 1: Write the problem statement like an incident report

“The release was late” is not a problem statement. “The 14 March release shipped 6 working days after the committed date, and two of the four scope items were dropped” is. It contains a date, a measure, and a boundary.

A good statement answers what happened, how much, when, and compared to what expectation. If the team cannot agree on it, stop: disagreement about the problem is the most common reason a session produces a conclusion nobody implements.

Step 2: Ask why, and write down every plausible answer

At the first level you will usually get three or four candidates: a dependency arrived late, an estimate was wrong, a reviewer was on leave, the scope grew. Write them all down before evaluating any of them.

Then check which one the evidence supports. That step separates a 5 Whys from a brainstorm. If the answer is “the dependency arrived late”, open the ticket system and confirm the date. If it is “the estimate was wrong”, compare estimated and actual effort for the last ten comparable items.

Step 3: Verify every answer before you ask the next why

A “why” built on an unverified answer produces a confident conclusion about the wrong thing. The practical rule: no answer advances to the next level without a citation — a log line, a ticket timestamp, a commit, a recorded decision, or a direct observation.

When the team cannot verify an answer, that is the finding. “We do not know why the review took nine days because we do not record review start and end times” is a legitimate 5 Whys output, and it usually points at a measurement gap worth fixing first.

Step 4: Stop at a cause you can act on

You have reached the right depth when the cause is a condition in the system that you can change: a missing check, an ambiguous rule, an untested dependency, a queue with no owner. If your final answer is “people need to be more careful”, you have not finished. Care is not a control.

Step 5: Attach a countermeasure and a verification date

Every analysis should end with three things: what changes, who owns it, and how you will know it worked. Without the third item, you will be running the same 5 Whys on the same problem in eight weeks.

What does a real 5 Whys analysis look like?

Here is an analysis of a database incident, written the way it should be documented. The evidence column is not decoration; it is the reason the conclusion is credible.

Problem statement: On 12 February, the orders service was unavailable for 3 hours 20 minutes (02:10–05:30 UTC), affecting 4,100 customer sessions.

The fix is not “be careful with reporting jobs”. It is a connection cap, a load test, and a revised review checklist — three changes that survive staff turnover.

Why the same incident keeps returning

The most common failure is stopping at level two or three, where the answer is already technically true. “The reporting job used too many connections” is accurate, and fixing only that guarantees the next parallelisation project repeats the outage.

A second failure is the circular answer. *Why is the queue slow? Because work arrives faster than it is processed. Why does work arrive faster? Because the queue is slow, so requests retry.* When you see why and because chasing each other, stop: you are describing a feedback loop, not a causal chain.

Why is the 5 Whys criticised, and is the criticism fair?

The criticism is fair and worth understanding, because it changes how you should use the tool.

Teruyuki Minoura, a former managing director of global purchasing at Toyota, criticised 5 Whys as too basic to reach the depth needed to ensure a problem is actually fixed. The standard objections: investigators stop at symptoms, they cannot find causes beyond their existing knowledge, results are not repeatable across teams, and the method isolates a single root cause when most failures have several contributing conditions.

Alan J. Card argued in a 2016 *BMJ Quality & Safety* paper that the technique should be abandoned for root cause analysis in healthcare, because the fifth why has no logical claim to being the most useful intervention point and the method forces a single pathway through systemic problems.

A 2024 study in the *International Journal of Six Sigma and Competitive Advantage* found that over half the literature treats 5 Whys as a simplified brainstorming tool, only 16.7% of authors clearly require investigation and empirical methods, and 41.8% of surveyed practitioners use it purely as brainstorming. That is the real diagnosis: the tool is not the problem, the way it is taught is.

None of this makes 5 Whys useless. It makes it a first-pass tool with a specific job: cheap, fast, transparent, and good at exposing a process gap a small team can fix this sprint. For a safety-critical failure with several contributing conditions, it is the wrong instrument.

When should you use 5 Whys, and when should you use something else?

Use 5 Whys for problems with a single dominant causal path, a team that knows the work, and a fix you can ship within weeks. Use a broader method when the failure has several interacting causes, crosses organisational boundaries, or carries safety or regulatory weight.

A pragmatic pattern for most teams: run a 5 Whys to get a fast, cheap hypothesis, then use a fishbone to check whether you missed parallel causes, then verify with data. The 5 Whys gives you direction; the fishbone gives you coverage.

How do you keep the method from becoming a blame exercise?

Separate the person from the mechanism, and write the rule into the session. “Who” questions produce defensiveness; “what allowed this” questions produce fixes.

Three habits work:

• Ban names in the causal chain. Record roles and mechanisms. If a name appears, ask what condition made the person’s action reasonable at the time.
• Assume good intent explicitly. Most people follow the process they were given. If following the process produced a failure, the process is the finding.
• Publish the analysis, not the culprit. A shared document with evidence and countermeasures improves the system. A memo about who missed what improves nothing.

The same rule blocks the classic trap: an answer like “we need to raise awareness” or “the operator must pay more attention”. Those are requests for compliance, not causes, and they fail at the first busy week.

How much does a missed root cause actually cost?

The business case for doing the analysis properly is easiest to see in a repeat-failure calculation. This is a composite example built from realistic assumptions, not a study result.

Scenario: A checkout service fails four times in a year. Each outage lasts an average of 3.5 hours during business hours and blocks an estimated $9,000 of revenue per hour. Support and engineering response costs roughly $4,000 per incident.

• Revenue loss: 4 × 3.5 h × $9,000 = $126,000
• Response cost: 4 × $4,000 = $16,000
• Total: $142,000

A proper analysis and fix — a connection cap, a load test, and a review checklist — might cost $12,000 in engineering time. That is a 12:1 return before you count the customer trust you did not lose.

A second example: the support queue

A support team handles 1,150 tickets a month. Seventeen percent are password resets: 195 tickets at about 11 minutes each, or roughly 36 agent-hours monthly. A 5 Whys on “why do customers email us to reset passwords” reaches the self-service flow: the reset link expires in 10 minutes, and 40% of requests come from mobile users who leave the app to find the email. Extending the link to 60 minutes and adding a resend button is small and testable; a drop from 195 tickets to under 60 over eight weeks justifies the change.

How do you verify that the fix worked?

Define the measure before you ship the countermeasure, and give it a baseline and a review date. “Fewer incidents” is not a measure; “connection-limit errors per week, from 12 to under 1 by 30 April” is.

A verification plan has four parts: the leading indicator (did the change ship and get used), the lagging indicator (did the failure rate fall, measured the same way as the problem), side effects (did the fix move the problem elsewhere), and a review date 30 and 90 days out. Without the date, the analysis is a document rather than a change.

In the database example, the verification is concrete: connection-limit errors per week (12 before, target under 1), nightly job peak connections (400 before, 40 after), and the percentage of change reviews that include the resource-impact checkbox (0% before, target 90%).

What mistakes should you avoid?

• Solving the symptom because it is visible. A rollback that restores service is recovery, not analysis. Do both, in that order.
• Asking why in a group without evidence. Group dynamics reward the most confident answer, not the correct one.
• Treating five as mandatory. If the third why reaches a fixable systemic cause, stop. If the seventh is still revealing, continue.
• Ignoring parallel causes. Most outages have a trigger and a latent condition. Fix both.
• Ending without an owner. An action without a name and a date is a wish.

How do you turn the analysis into tracked work?

The gap between a good 5 Whys and a fixed problem is usually tracking. The analysis lives in a document, the countermeasures live in someone’s memory, and the verification date never arrives.

Write each countermeasure as a task with an owner, a due date, and a definition of done that includes the verification, and link it back to the incident so the next person can see why the control exists. Review open countermeasures in the weekly ops meeting until they close.

That is the workflow Doitify is built for: incidents become projects, countermeasures become tasks with owners and due dates, and verification shows up in a progress report instead of a forgotten document. Doitify is our product, so read that as a description of the workflow rather than an independent endorsement.

Conclusion

The 5 Whys is a disciplined question, repeated. Its power is not in the number five but in the refusal to accept the first plausible answer. Write the problem as a fact, verify every answer against evidence, stop when you reach something you can change, and attach a countermeasure with an owner and a date.

Know its limits too. It follows one path, it depends on what the team already knows, and it can produce a confident answer to the wrong question. Use it first, check coverage with a fishbone when the failure is complex, and measure whether the fix held.

If this post on 5 whys was helpful, you might also enjoy Project Management Software for Engineering Teams in 2026 and How to Create a Work Breakdown Structure (8 Steps).