◀ Stage Select World 4 · Stage 4-03

Root Cause Analysis

Fix the cause, not the symptom

Something broke, or a number fell off a cliff. Root cause analysis is the discipline of finding what actually produced it, instead of patching the nearest visible thing and waiting for it to come back. This guide covers the diagnostic sweep, the techniques, and how to prove a cause rather than agree on one.

Ready?

Step-by-step lessons

Diagnose Before You Prescribe

Four short lessons: symptom versus cause, the ordered sweep for a metric drop, choosing the right technique, and proving the cause before you commit engineering to it.

1

Symptom, Proximate Cause, Root Cause

The symptom is what you noticed. The proximate cause is the last link in the chain, the thing that failed immediately before. The root cause is the condition that, once removed, stops the problem recurring. All three are true at once; only the last one ends the story.

Everyday example, the leaking ceiling

Symptom: water on the floor. Proximate cause: a crack in the ceiling. Root cause: a blocked gutter that's been overflowing into the wall cavity for months. You can mop the floor daily and even patch the ceiling, and the water will keep coming back, because neither action touches the gutter.

Symptom-fixing has a distinctive signature: the fix works, then has to be repeated, then has to be repeated bigger. More support agents for an overflowing queue. A second retry for a flaky call. A discount to hold a churning account. Each one buys time and none of them removes what generates the problem.

RCA also has a cost. Reserve the deep version for problems that recur, are expensive, or carry safety and trust risk. A 1% wobble on a secondary metric deserves a note and a watchlist, not a two-week investigation.

Quick check

A support queue keeps overflowing, so the team adds three agents. Six weeks later it overflows again. What did the team do?

2

The Diagnostic Sweep for a Metric Drop

"Engagement dropped 18% overnight, why?" is the most common RCA a PM will ever run, and the order of the checks matters more than the cleverness of any one of them.

1

Is it real?

Broken event, renamed property, SDK upgrade, failed pipeline job, changed metric definition. Rule out measurement before explaining behavior.

2

What's the shape?

A step means a discrete event on a specific date. A slope means something compounding: mix shift, decay, creeping regression.

3

Internal or external?

Internal: release, incident, pricing, a campaign that stopped. External: competitor launch, OS or app-store change, regulation, seasonality, macro.

4

Which slice?

Platform, app version, geography, channel, new vs existing users, plan tier. Keep slicing until the drop is concentrated somewhere.

5

Which part of the metric?

Decompose it. Users × frequency × conversion. A drop in one factor is a much smaller problem than a drop in all three.

Signatures worth memorizing

A cliff-edge drop with silent support channels is almost always tracking. A drop confined to one country starting on a specific date, with no release, points outward: a competitor, a holiday, a payment provider, a regulator. A drop confined to one app version points straight at that release. A drop that's flat in every segment but visible in the aggregate is a mix shift, not a behavior change.

Segmentation doesn't find the cause. It shrinks the search space until the cause is findable.

Quick check

Weekly active users drop 18% overnight. The team's first move is to brainstorm which product changes could explain it. What should come first?

3

Choosing the Right Technique

The techniques aren't interchangeable. Each one assumes a different shape of problem.

One chain

5 Whys

Ask why repeatedly down a single causal thread. Fast, cheap, and blind to parallel causes. End on a mechanism, never on a person.

Many causes

Fishbone (Ishikawa)

Fan one effect into categories, people, process, product, platform, policy, external, and enumerate contributors in each.

Search space

Issue tree

Break the problem into MECE branches you can test and eliminate. Best when the cause could be almost anywhere.

Prioritize

Pareto

Rank known causes by impact. Six error types out of forty often carry 80% of the failures.

A note on 5 Whys, since it's the one everyone reaches for. It fails in two predictable ways. It collapses multi-factor problems into one thread, so genuine contributors get dropped. And it terminates on people, "the developer didn't have enough time", which feels like an answer and isn't actionable. Push past it: why was the estimate wrong, why wasn't the risk visible, why did scope grow mid-sprint.

Quick check

A problem has plausible contributors across engineering, design, pricing and support, and every 5 Whys attempt collapses into a single thread. Which technique fits better?

4

Proving the Cause, and Preventing the Recurrence

A room agreeing on a cause is not evidence. Two tests separate a real root cause from a confident story.

The prediction test

If this is the cause, what else must be true? "If latency drives abandonment, the slowest sessions should abandon most." Check it. A failed prediction kills a theory cheaply.

The recurrence test

Remove the cause and the effect stops. If the failure returns in a new costume two months later, you fixed a proximate cause.

Then make the fix structural. A countermeasure changes the system so the failure can't happen or is caught early: a pre-deploy check, a staged rollout, a guardrail, an alert that fires in minutes. "Be more careful" is not a countermeasure, it relies on vigilance that decays the week after the postmortem and can't be handed to a new joiner.

Blameless, because you need the truth

A postmortem that hunts for who approved the change gets one name and no information. A blameless one assumes everyone acted reasonably given what they knew, and asks what in the system made the failure possible and hard to catch. The point isn't kindness, it's that people only report near-misses honestly in an environment where doing so is safe.

Quick check

Two months after a root cause was "fixed", the same failure recurs in a slightly different form. What's the most likely explanation?

Review the concepts

Root Cause Analysis Flashcards

6 cards covering the essentials. Click a card to flip it.

Click to flip

Tip: say the answer out loud before flipping.

Explanation

In practice

1 / 6
Did you recall it?
Apply what you learned

Practice Scenarios

15 situations that test whether you can separate symptom from cause, run a disciplined diagnostic sweep, and prove a root cause instead of guessing one.

Scenario 1easy

A support queue is overflowing, so a team adds three more support agents. Six weeks later the queue is overflowing again.

What did the team do?

Scenario 2easy

A weekly active users number drops 18% overnight. The team's first move is to open a brainstorm on what product changes could have caused it.

What should come first?

Scenario 3easy

Asked why checkout failed, an engineer answers "because the payment service timed out," and the team stops there.

What kind of cause is that?

Scenario 4easy

A metric declines gradually over four months with no step change on any single day.

What does the shape of the decline suggest?

Scenario 5easy

During a postmortem, most of the discussion focuses on which engineer approved the change that broke production.

What's wrong with this framing?

Scenario 6medium

An app's crash rate spikes. Segmenting shows the spike is entirely on Android 14 devices running app version 5.2.

What has the segmentation accomplished?

Scenario 7medium

A team runs 5 Whys on a delivery delay and lands on "the developer didn't have enough time," then stops.

What's the weakness in this chain?

Scenario 8medium

A problem has many plausible contributing causes across engineering, design, pricing, and support, and 5 Whys keeps collapsing into a single thread.

Which technique fits better?

Scenario 9medium

Analysis shows 6 error types account for 81% of all failed transactions, out of 40 distinct error types logged.

What principle does this illustrate, and what follows from it?

Scenario 10medium

A team believes a slow API is causing checkout abandonment. Before committing engineering time, they want to test the belief.

What's the strongest check?

Scenario 11hard

A revenue drop is traced to a pricing page change, but the same change shipped three months earlier in another market with no effect.

What does this tell the team?

Scenario 12hard

An incident is closed with the corrective action "be more careful during deploys."

Why is this a weak countermeasure?

Scenario 13hard

Two months after a root cause was "fixed," the same failure recurs in a slightly different form.

What's the most likely explanation?

Scenario 14hard

A metric drop is investigated for two weeks with no conclusion, while the team's roadmap stalls. The drop is 1.5% on a secondary metric.

What's the judgement call here?

Scenario 15hard

An engagement drop is confirmed real, isolated to one country, starting on a specific date, with no release that day.

What's the next best line of inquiry?

Lock it in

Guess the Term

Read the clues and name the concept. The fewer clues you need, the more points you score.

Round 1 Score 0
Keep it handy

Root Cause Analysis Quick Reference

The whole topic on one screen.

Three Levels

Symptom

What you noticed.

Proximate cause

The last link before failure.

Root cause

Remove it and recurrence stops.

Sweep for a Metric Drop

1

Is it real?

Tracking, pipeline, definition.

2

Step or slope?

Event versus compounding drift.

3

Internal or external?

Release versus market.

4

Which slice?

Platform, version, geo, channel.

Pick a Technique

5 Whys

One chain, one cause.

Fishbone

Many parallel contributors.

Issue tree

MECE branches to eliminate.

Pareto

Rank causes by impact.

Prove & Prevent

Prediction test

What else must be true?

Recurrence test

Does removal end it?

Countermeasure

Structural, not "be careful".

Blameless review

System, not person.

Notification