Back to template

5 Whys Examples

These 5 Whys examples show how different teams apply the technique to real problems — from production incidents to missed sprint goals to customer complaints. Use them as a reference for writing your own analysis.

Use this 5 Whys templateBack to template
5 Whys Examples

Real examples

Production database outage

Who uses it: Engineering team running a post-mortem after a 45-minute outage

Problem: Database unavailable for 45 minutes, affecting all users
Why 1: Primary database ran out of disk space
Why 2: Write-ahead log files accumulated faster than expected
Why 3: A new feature increased write volume 4× without adjusting log retention
Why 4: The feature's write impact was not estimated before deployment
Why 5: No pre-deployment checklist item exists for write volume impact
Root Cause: Deployment process has no capacity impact review step
Action: Add write volume estimation to the pre-deployment checklist

Why this works: Stopping at Why 2 (disk full) would have led to a one-time fix: buy more disk. Continuing to Why 5 revealed a process gap that would have caused the same issue with the next high-volume feature.

Missed sprint goal

Who uses it: Scrum team retrospective after three consecutive missed sprints

Problem: Team delivered 40% of sprint commitment for the third sprint in a row
Why 1: Two large stories were not finished
Why 2: The stories were larger than estimated
Why 3: Estimates were made without breaking stories into tasks first
Why 4: Story refinement sessions are skipped when the backlog is thin
Why 5: Refinement is treated as optional, not a required sprint ceremony
Root Cause: Inconsistent refinement practice leads to systematically poor estimates
Action: Block sprint planning from starting until refinement is complete for all stories

Why this works: The team had previously tried fixing velocity by working longer hours (treating Why 1 as the root cause). The 5 Whys revealed that the real issue was a process gap, not effort.

Recurring customer support ticket

Who uses it: Customer success team analyzing a ticket that appears weekly

Problem: 8–12 customers per week report that exported reports show wrong date ranges
Why 1: Export uses the user's local timezone, not the account timezone
Why 2: Export feature was built by a different team than the core reporting feature
Why 3: There is no shared timezone handling utility across teams
Why 4: Backend services were built independently without a shared standards library
Why 5: No architectural standard for timezone handling was defined at the platform level
Root Cause: Missing platform-level timezone standard causes inconsistent behavior
Action: Define a shared timezone utility and add it to the platform standards guide

Why this works: The support team had been sending the same workaround email for 6 months. The 5 Whys shifted the fix from a reactive workaround to a proactive platform decision.

Failed product launch

Who uses it: Product team reviewing a launch that missed adoption targets by 60%

Problem: New feature reached only 40% of adoption target after 30 days
Why 1: Users were not discovering the feature
Why 2: The feature was accessible only from a settings menu
Why 3: Feature placement was decided late in development without user testing
Why 4: No discovery test was included in the launch checklist
Why 5: Launch checklist focuses on technical readiness, not user discoverability
Root Cause: Launch process does not evaluate discoverability before release
Action: Add a discoverability review (with at least one user test) to the launch checklist

Why this works: The technical team had shipped a working feature. The 5 Whys revealed that the problem was never technical — it was a product process gap that treated development completion as the definition of done.

Sales deal lost to competitor

Who uses it: Sales manager reviewing a pattern of losses in the enterprise segment

Problem: Lost 4 of the last 5 enterprise deals to the same competitor
Why 1: Prospects chose the competitor's security compliance features
Why 2: Our product lacks SOC 2 Type II certification
Why 3: Security certification was deprioritized in favor of feature development
Why 4: No enterprise customer was interviewed before setting the roadmap
Why 5: Roadmap prioritization process does not include systematic enterprise buyer input
Root Cause: Missing enterprise voice in the roadmap process led to a compliance gap
Action: Add enterprise customer advisory board to the quarterly roadmap review

Why this works: The sales team initially attributed the losses to pricing. The 5 Whys traced back to a product process failure — enterprise buyers had been telling the team about compliance requirements, but there was no formal channel to translate that into roadmap priority.

High employee churn in one team

Who uses it: HR and engineering manager reviewing a team with 40% annual turnover

Problem: Engineering team B lost 4 of 10 engineers in the past year
Why 1: Exit interviews cite burnout and lack of growth
Why 2: The team is on a critical product that has been in maintenance mode for 18 months
Why 3: No new projects were assigned to the team despite budget availability
Why 4: Team B's manager did not surface the retention risk to leadership
Why 5: There is no structured forum for managers to discuss retention risks
Root Cause: No systematic channel for managers to escalate retention concerns early
Action: Add retention health check to the quarterly manager-leadership sync agenda

Why this works: Turnover was initially blamed on compensation. The 5 Whys revealed that engineers were leaving due to lack of meaningful work — a problem that could have been addressed much earlier with a simple management process change.

Tips for better study mind maps

  • Stop when the answer points to a process, system, or behavior that can be changed — not when you've counted to five. Some problems resolve in three whys; some need seven.
  • Avoid whys that land on 'human error' as a root cause. Human error is almost always a symptom of a system that makes it easy to make the mistake — keep asking why.
  • Assign a specific owner and deadline to the corrective action before the session ends. A root cause without an owner is just an observation.
  • Run the 5 Whys as a group exercise, not a solo analysis. Others will spot causal jumps or alternative explanations that the problem owner would miss.

Start editing online

Go back to the template, swap in your own topics, and keep the same structure if it fits your class or project.

Use this template: /editor/new?template=five-whys

Use this 5 Whys template