Run a 5-whys root cause analysis on a user complaint

Five Whys Is the Cheapest Root Cause Tool

Teams that patch symptoms accumulate brittle fixes; teams that trace structural causes reduce complaint rates. The 5-whys method — originating in manufacturing and widely adopted in software — is a near-zero-cost root cause tool. Google re:Work's guidance on problem solving and Atlassian's post-incident practice both document its reliability when each level is backed by evidence, not speculation.

How the Run a 5-whys root cause analysis on a user complaint Prompt Works

The prompt forces evidence at every level so the chain does not descend into speculation, classifies the root cause into five structural categories, and names the early warning metric that would have caught the issue earlier. The structural-vs-symptom tradeoff matrix legitimizes the pragmatic short-term patch when the structural fix takes a quarter.

When to Use It

• A single customer complaint is loud and pattern-likely.
• A post-incident review needs structural cause, not incident-specific fix.
• A category of bugs keeps recurring and nobody has traced the pattern.
• A new PM wants to shift the team from symptom-patching to root-cause fixing.
• A CEO or board is asking "how did this happen."

Common Pitfalls

• Speculating without evidence. Every "why" answer needs backing data. Without it, the chain produces confident fiction.
• Stopping at "people error". Individual mistakes are usually a symptom. Keep asking why.
• No warning metric. A root cause without a monitorable leading indicator is a lesson you can't repeat.

Sources

• Google re:Work — Google
• Agile Metrics — Atlassian
• Begin with Trust — Harvard Business Review
• Sprint Retrospectives — Atlassian