5 Whys

What is the 5 Whys?

The 5 Whys is a root cause analysis technique that helps teams find the underlying cause of a problem by repeatedly asking “why?”

The method starts with a clear problem statement. The team asks why the problem happened, answers with evidence, and uses that answer as the basis for the next “why?” question.

The goal is not to ask exactly five questions every time. Five is a rule of thumb. Some problems need fewer questions. Others need more.

The 5 Whys is commonly used in:

• Root cause analysis
• Product management
• Engineering
• UX research
• Quality management
• Process improvement
• Incident reviews
• Customer support
• Operations

The technique is useful because it is simple, fast, and easy to use with a team. It helps people look beyond symptoms and focus on the cause of a problem.

5 Whys definition

The 5 Whys is a problem-solving method that identifies the root cause of an issue by asking “why?” several times in sequence.

A simple definition:

The 5 Whys is a root cause analysis method where each answer becomes the basis for the next “why?” question.

For example:

Step	Question	Answer
1	Why did the user fail to complete onboarding?	They did not verify their email.
2	Why did they not verify their email?	They did not see the verification message.
3	Why did they not see the message?	It went to spam.
4	Why did it go to spam?	The email sender was not properly configured.
5	Why was the sender not properly configured?	Email deliverability was not included in the launch checklist.

The final answer points to a cause the team can fix.

5 Whys example

Here is a 5 Whys example for a product team.

Problem: Trial users are not activating.

Step	Question	Answer
1	Why are trial users not activating?	They are not completing the setup flow.
2	Why are they not completing the setup flow?	They stop at the integration step.
3	Why do they stop at the integration step?	They do not know which integration to choose.
4	Why do they not know which integration to choose?	The product shows all integrations without guidance.
5	Why does the product show all integrations without guidance?	The onboarding flow was designed for existing customers, not new trial users.

Possible root cause: The onboarding flow assumes too much prior knowledge.

Possible corrective action: Add guided setup based on the user’s role, use case, or existing tools.

This example shows how the 5 Whys can move a team from a visible symptom, “trial users are not activating,” to a more useful cause, “the onboarding flow assumes too much prior knowledge.”

5 Whys root cause analysis example

The 5 Whys is often used after a defect, incident, customer complaint, or process failure.

Problem: A customer reported that a report showed the wrong numbers.

Step	Question	Answer
1	Why did the report show the wrong numbers?	The report used outdated data.
2	Why did it use outdated data?	The data sync failed overnight.
3	Why did the data sync fail?	The API request timed out.
4	Why did the timeout go unnoticed?	The monitoring alert was not configured for this sync job.
5	Why was there no monitoring alert?	The team did not include background sync jobs in the launch checklist.

Possible root cause: The launch checklist did not include monitoring for background jobs.

Possible corrective action: Update the launch checklist, add monitoring for sync jobs, and create alerts for failed or delayed syncs.

A weak solution would be “rerun the sync.” That fixes the immediate symptom. A stronger solution changes the system so the problem is less likely to happen again.

How the 5 Whys works

The 5 Whys works by turning each answer into the next question.

The structure is simple:

1. State the problem.
2. Ask why it happened.
3. Answer based on evidence.
4. Ask why that answer is true.
5. Repeat until the team finds a useful root cause.
6. Choose a corrective action.
7. Check whether the corrective action worked.

The method is most effective when the team avoids guessing. Each answer should be supported by data, observation, user feedback, logs, customer conversations, or direct evidence.

How to use the 5 Whys

Use the 5 Whys when the team needs to understand why a specific problem happened.

1. Define the problem clearly

Start with a specific problem statement.

Weak problem statement:

• Users hate onboarding.

Better problem statement:

• Only 32% of new trial users complete onboarding within the first 24 hours.

A clear problem statement makes the analysis easier and more useful.

2. Bring the right people together

Include people who understand the problem from different angles.

Depending on the problem, this might include:

• Product managers
• Designers
• Engineers
• QA specialists
• Customer support
• Sales
• Data analysts
• Operations
• Users or customers

The goal is to understand the system, not to assign blame.

3. Ask the first why

Ask why the problem happened.

The first answer should describe a direct cause.

Example:

Problem: Users are dropping off during checkout.

Why? Because many users see a payment error.

4. Use evidence for each answer

Do not rely only on opinion or memory.

Useful evidence might include:

• Product analytics
• Error logs
• Support tickets
• User interviews
• Session recordings
• Usability tests
• Customer complaints
• Incident reports
• Process documentation

The 5 Whys becomes weak when the answers are guesses.

5. Continue until you find a useful cause

Keep asking why until the team reaches a cause it can act on.

You do not need to stop at exactly five questions. Stop when the cause is specific, evidence-based, and useful.

6. Choose a corrective action

A root cause analysis is only useful if it leads to action.

A good corrective action should:

• Address the cause, not only the symptom.
• Have a clear owner.
• Be specific.
• Be realistic.
• Be tracked after implementation.

7. Check whether the fix worked

After the corrective action is implemented, review the result.

Ask:

• Did the problem happen again?
• Did the metric improve?
• Did the fix create new problems?
• Do we need another action?

The 5 Whys should lead to learning, not just a meeting.

For a facilitated version of this method, see the Five Whys workshop exercise.

5 Whys template

Use this 5 Whys template for a simple root cause analysis.

Field	Notes
Problem statement	What happened? Be specific.
Impact	Who or what was affected?
Evidence	What data, logs, observations, or feedback do we have?
Why 1	Why did the problem happen?
Why 2	Why did that happen?
Why 3	Why did that happen?
Why 4	Why did that happen?
Why 5	Why did that happen?
Root cause	What underlying cause can we address?
Corrective action	What will we change?
Owner	Who is responsible for the action?
Follow-up date	When will we check whether the fix worked?

5 Whys worksheet

Use this worksheet during a meeting or workshop.

Problem:

Write the problem in one sentence.

Evidence:

List the data, observations, logs, feedback, or examples that show the problem is real.

• Why 1: Because…
• Why 2: Because…
• Why 3: Because…
• Why 4: Because…
• Why 5: Because…

Root cause:

The underlying cause appears to be…

Corrective action:

We will…

Owner:

The owner is…

Review date:

We will check again on…

What are the 5 Whys questions?

The 5 Whys questions are not five fixed questions. They are a sequence of “why?” questions based on the previous answer.

A typical format is:

1. Why did the problem happen?
2. Why did that cause happen?
3. Why did that condition exist?
4. Why was it not prevented or detected?
5. Why does the system allow this to happen?

For product and UX teams, useful 5 Whys questions might include:

• Why did users fail to complete the task?
• Why did they not understand the next step?
• Why did the interface not make the action clear?
• Why did the team not detect the issue earlier?
• Why was this assumption not tested before launch?

For engineering or operations teams, useful questions might include:

• Why did the incident happen?
• Why did the system behave that way?
• Why was the failure not caught?
• Why did monitoring not alert the team?
• Why was the process missing that check?

The best questions focus on causes, evidence, and systems.

When the 5 Whys helps

The 5 Whys is most useful when a team needs a quick, structured way to understand why a specific problem happened.

It helps in situations where the problem is clear, but the cause is not.

Customer complaints

The 5 Whys can help teams move from the complaint itself to the underlying cause.

Example:

A customer says the product is confusing. The real cause may be unclear onboarding, missing feedback, a poor empty state, or a workflow that does not match how the customer expects to work.

Product and UX issues

Product teams can use the 5 Whys to understand problems in onboarding, activation, retention, conversion, feature adoption, support volume, and customer satisfaction.

Good use cases include:

• Users abandon onboarding.
• A feature has low adoption.
• Trial users do not convert.
• Customers churn after the first month.
• A product experiment fails.
• Customers misunderstand pricing.
• A key workflow takes too long.

Engineering incidents

Engineering teams can use the 5 Whys for bugs, outages, regressions, deployment failures, monitoring gaps, and quality problems.

The method is especially useful when the team wants to understand why the system allowed the issue to reach users.

Process breakdowns

The 5 Whys can help teams understand why a process failed.

Examples:

• A handoff was missed.
• A release was delayed.
• A support issue escalated too late.
• A decision was made without the right input.
• A requirement was misunderstood.

Retrospectives and continuous improvement

The 5 Whys can be used in retrospectives when a team wants to understand why a problem keeps happening.

It helps the team move from “this went badly” to “what in our system made this likely?”

5 Whys in product management

Product teams can use the 5 Whys to understand why users behave in a certain way or why a product outcome changed.

Examples of product questions:

• Why are users not activating?
• Why is feature adoption low?
• Why did conversion drop?
• Why are customers churning?
• Why did a product experiment fail?
• Why are users contacting support?
• Why are customers not upgrading?

Product teams should avoid using the 5 Whys only in internal discussions. Many product problems require customer evidence. Use analytics, user interviews, session recordings, support tickets, and usability testing to support the answers.

5 Whys in UX research

In UX research, the 5 Whys can help researchers and designers understand why users behave in a certain way.

For example:

Problem: Users do not use the saved filters feature.

Step	Question	Answer
1	Why do users not use saved filters?	They do not notice the feature.
2	Why do they not notice it?	The control is hidden in an overflow menu.
3	Why is it hidden there?	The team wanted to reduce visual clutter.
4	Why was reducing clutter prioritized over discoverability?	The design review focused on visual simplicity, not task success.
5	Why was task success not part of the review?	The team did not define success criteria for the workflow.

Possible root cause: The team reviewed the interface visually but did not evaluate whether users could complete the task.

Possible corrective action: Add task success criteria to design reviews and test discoverability before release.

5 Whys in engineering

Engineering teams can use the 5 Whys for bugs, incidents, outages, regressions, and quality problems.

For example:

Problem: A release introduced a bug in the billing flow.

Step	Question	Answer
1	Why did the billing bug reach production?	The bug was not caught before release.
2	Why was it not caught?	The billing flow was not covered by automated tests.
3	Why was it not covered?	The team had not added tests for the new discount logic.
4	Why were tests not added?	The acceptance criteria did not mention discount edge cases.
5	Why were edge cases missing from the acceptance criteria?	Product, engineering, and QA did not review pricing logic together before implementation.

Possible root cause: Pricing edge cases were not reviewed cross-functionally before development.

Possible corrective action: Add a pricing review step for billing-related changes and include discount scenarios in acceptance criteria.

When not to use the 5 Whys

The 5 Whys is not the right tool for every problem.

Avoid using the 5 Whys by itself when:

• The problem is highly complex.
• There are many interacting causes.
• The issue is safety-critical or compliance-critical.
• The team does not have evidence.
• The discussion is likely to become political or blame-focused.
• The problem requires statistical analysis.
• The team needs to compare many possible causes.
• The problem is vague or not yet confirmed.

In these cases, use a more structured root cause analysis method or combine the 5 Whys with another tool, such as a fishbone diagram.

Limitations of the 5 Whys

The 5 Whys is useful, but it has limits.

It can oversimplify complex problems

Some problems have several causes. A single chain of “why” questions may miss important contributing factors.

It can follow the wrong path

If the first answer is wrong, the rest of the analysis may lead to the wrong conclusion.

It can become opinion-based

Teams may answer from memory or assumption instead of evidence.

It can lead to blame

A poor 5 Whys session can end with “someone made a mistake.” A better analysis asks why the system allowed the mistake to happen.

It may stop too early

Teams sometimes stop when they find a convenient answer, not the real cause.

Use the 5 Whys as a thinking tool, not as proof. For complex problems, combine it with other methods.

5 Whys best practices

Use these practices to make the 5 Whys more effective.

Start with a specific problem

The problem should be observable and clear.

Better:

• Checkout conversion dropped from 48% to 36% after the release.

Weaker:

• Checkout is broken.

Use evidence

Support each answer with data, logs, user feedback, observations, or examples.

Focus on systems, not blame

Avoid stopping at “the person forgot.” Ask why the process, design, system, or environment allowed the failure.

Do not force exactly five whys

Five is a guide. Stop when you find a useful cause, or continue if the cause is still unclear.

Look for more than one cause

If the problem is complex, run multiple 5 Whys paths or use a fishbone diagram.

Turn the root cause into action

End with a corrective action, owner, and follow-up.

5 Whys vs. fishbone diagram

The 5 Whys and fishbone diagram are both root cause analysis tools, but they work differently.

Tool	Best for	How it works
5 Whys	Simple or moderately clear problems	Follows one chain of cause and effect by asking “why?”
Fishbone diagram	Complex problems with many possible causes	Maps possible causes across categories such as people, process, tools, environment, and materials

Use the 5 Whys when the problem has a likely cause path.

Use a fishbone diagram when the problem is complex, cross-functional, or has many possible causes.

5 Whys vs. root cause analysis

The 5 Whys is one form of root cause analysis.

Root cause analysis is the broader practice of identifying why a problem happened. The 5 Whys is one simple technique within that practice.

Other root cause analysis methods include:

• Fishbone diagrams
• Fault tree analysis
• Process mapping
• Incident reviews
• Failure mode and effects analysis
• Pareto analysis

Use the 5 Whys when you need a lightweight method. Use a more structured root cause analysis method when the problem is complex or high-risk.

Common 5 Whys mistakes

Starting with a vague problem

A vague problem leads to vague answers.

Guessing instead of checking evidence

The method becomes weak when answers are based only on opinion.

Stopping at human error

“Someone forgot” is rarely a useful root cause. Ask why the system relied on memory.

Treating five as a fixed rule

The method may require fewer or more than five questions.

Choosing a fix before finding the cause

Teams often jump to solutions too early. Finish the analysis first.

Ignoring contributing causes

Some problems have more than one cause. A single chain may not be enough.

Frequently asked questions about the 5 Whys

What is the 5 Whys technique?

The 5 Whys is a root cause analysis technique that asks “why?” repeatedly to identify the underlying cause of a problem.

What are the 5 Whys?

The 5 Whys are not five fixed questions. The method means asking why a problem happened, then asking why each answer is true until the team finds a useful root cause.

What is a 5 Whys example?

A simple example is: users are not completing onboarding. Why? They stop at setup. Why? They do not know which integration to choose. Why? The product shows too many options without guidance. The root cause may be that onboarding assumes too much prior knowledge.

How do you write a 5 Whys analysis?

Write a clear problem statement, then list each “why?” question and answer in order. Finish with the root cause, corrective action, owner, and follow-up date.

What is the purpose of the 5 Whys?

The purpose of the 5 Whys is to help teams find the root cause of a problem so they can fix the underlying issue, not just the symptom.

Does it have to be exactly five whys?

No. Five is a rule of thumb. Some problems need fewer questions, while others need more.

Who invented the 5 Whys?

The 5 Whys is commonly associated with Toyota and the Toyota Production System. It is often linked to Sakichi Toyoda and later Toyota problem-solving practices.

What is the difference between 5 Whys and root cause analysis?

Root cause analysis is the broader practice of finding the underlying cause of a problem. The 5 Whys is one simple root cause analysis technique.

What is the difference between 5 Whys and fishbone diagram?

The 5 Whys follows one chain of cause and effect. A fishbone diagram maps many possible causes across categories, making it better for complex problems.

What are the advantages of the 5 Whys?

The main advantages are simplicity, speed, shared understanding, and a stronger focus on causes instead of symptoms.

What are the limitations of the 5 Whys?

The 5 Whys can oversimplify complex problems, follow the wrong causal path, rely on opinion instead of evidence, or lead to blame if it is not facilitated well.

When should you use the 5 Whys?

Use the 5 Whys for specific problems where the team needs a quick, evidence-based way to understand why the issue happened.

Summary

The 5 Whys is a simple root cause analysis technique that helps teams understand why a problem happened.

The method starts with a clear problem statement and asks “why?” repeatedly until the team finds a useful cause. It is commonly used in product management, engineering, UX, quality management, and process improvement.

The 5 Whys works best for specific problems with a clear cause path. It is less effective for complex problems with many interacting causes. To use it well, focus on evidence, avoid blame, and turn the root cause into a clear corrective action.