Root Cause Analysis Template for Product Managers

A post-mortem is a broader review of an event (what happened, what went well, what went poorly). An RCA is specifically focused on finding the root cause of a problem and preventing recurrence. Post-mortems often include an RCA section, but they also cover communication, timeline, and process. Use this template for the RCA portion of a post-mortem.

Stop when you reach a cause that is (a) within your control to fix, (b) specific enough to act on, and (c) systemic rather than situational. If your answer is "because humans make mistakes," you have gone too far. Back up one level and fix the process that allowed the mistake.

Yes. The goal is to improve processes and systems, not to find someone to punish. Frame every finding as a system failure, not a person failure. Instead of "PM did not run usability testing," write "the launch process did not require usability testing for Tier 3 features." This shifts the corrective action from training one person to fixing the process for everyone.

Use 5 Whys when the problem has a single, clear chain of causation (A caused B caused C). Use the fishbone when multiple independent factors contributed to the problem. A production outage caused by one bad deployment is a 5 Whys problem. Low feature adoption caused by poor discovery, missing documentation, and bad timing is a fishbone problem.

Only run formal RCAs for significant problems: missed targets by over 30%, customer-facing incidents, or recurring issues. For minor problems, a 15-minute "quick 5 Whys" in the [retrospective](/glossary/retrospective-retro) is sufficient. If you run an RCA every week, the team will treat them as busywork. ---