Product Post-Mortem Template

A [sprint retrospective](/templates/sprint-retrospective-template) reviews a recurring time period (usually two weeks) and focuses on team process. A post-mortem reviews a specific event or project and focuses on outcomes and root causes. Run both. Retros every sprint, post-mortems after launches, failed bets, or significant incidents. They serve different purposes.

60 to 90 minutes for most projects. Budget 15 minutes for timeline, 20 minutes for root cause discussion, 15 minutes for impact review, and 15-20 minutes for follow-up actions. If your post-mortem runs over 90 minutes, you are either discussing too many issues (pick the top 3-5) or the facilitator is not managing time.

Redirect to systems. Instead of "Who made this mistake?" ask "What process allowed this mistake to happen?" If an engineer deployed broken code, the root cause is not the engineer. The root cause might be missing automated tests, inadequate code review, or time pressure that discouraged thorough QA. Frame every finding as a process improvement opportunity using the root cause categories in the template.

Run one combined post-mortem, not separate ones per team. Cross-team issues only surface when everyone is in the room. Use the timeline section to map each team's contributions and handoff points. Often the root cause lives in the gaps between teams, not within any single team. Keep the group to 6-8 people by sending one representative per function.

Yes. Post-mortems lose value when they stay locked in a team folder. Share them with adjacent teams and leadership. Transparency builds trust and prevents other teams from making the same mistakes. Redact sensitive details if needed, but default to open. Use a shared wiki or your [decision log](/templates/decision-log-template) to make post-mortems searchable.