What This Template Is For
A post-mortem is how product teams turn outcomes into future advantage. Unlike a sprint retrospective, which reviews a two-week cycle, a post-mortem examines a specific product event: a launch that underperformed, a bet that failed, a migration that went sideways, or a release that succeeded in surprising ways.
Most post-mortems fail because they become either blame sessions or feel-good recaps. This template forces your team through a structured sequence: timeline reconstruction, root cause analysis, quantified impact, and concrete follow-ups with owners. The goal is not to assign fault. The goal is to make the next launch, migration, or product bet measurably better.
Use this alongside your decision log to build an institutional memory that compounds over quarters.
When to Use This Template
- After a product launch: Whether it hit targets or missed them, a post-mortem captures what you would repeat or change.
- After a missed metric target: When quarterly OKRs come in below expectations, a post-mortem identifies whether the issue was strategy, execution, or measurement.
- After a failed experiment: When a feature bet does not pay off, capture why the hypothesis was wrong rather than just archiving the work.
- After a customer escalation or outage: When the product caused real user pain, structure the review around prevention and detection.
- After a major pivot or scope change: When you killed or significantly changed direction mid-cycle, document the decision context for future reference.
Step-by-Step Instructions
Step 1: Schedule Within 5 Business Days
Run the post-mortem while context is fresh. Invite everyone who was directly involved in the work, including engineering, design, marketing, and support. Keep the group to 4-8 people. Larger groups produce shallow discussion.
- ☐ Post-mortem scheduled within 5 business days of the event
- ☐ All key contributors invited
- ☐ Pre-work sent: ask attendees to write 2-3 observations before the meeting
Step 2: Reconstruct the Timeline
Before analyzing what went wrong or right, align the team on what actually happened. Build a shared timeline of key decisions, milestones, and turning points. This prevents revisionist history.
- ☐ Key dates and decisions listed chronologically
- ☐ Decision-makers identified for each turning point
- ☐ External factors noted (market changes, competitor moves, platform updates)
Step 3: Analyze Root Causes
For each significant outcome (positive or negative), ask "why" at least three times. Surface the systemic cause, not just the proximate one. A missed deadline is not a root cause. An unrealistic scope estimate based on incomplete technical discovery is.
- ☐ 3-5 root causes identified
- ☐ Each root cause traced back to a process, information, or structural gap
- ☐ Contributing factors separated from root causes
Step 4: Quantify Impact
Attach numbers to outcomes wherever possible. "The launch underperformed" is not useful. "Day-30 retention was 18% vs. the 25% target, with 40% of churned users citing onboarding friction in exit surveys" is useful. Use your KPI dashboard data.
- ☐ Actual metrics vs. targets documented
- ☐ User and revenue impact quantified
- ☐ Effort spent (engineering weeks, design hours) captured
Step 5: Define Follow-Up Actions
Every post-mortem must produce 3-5 specific, assigned follow-ups. Not lessons learned. Actions. Each needs an owner, a due date, and a definition of done. Add them to your backlog.
- ☐ 3-5 follow-up actions defined
- ☐ Each action has an owner and due date
- ☐ Actions added to team backlog or project tracker
- ☐ Review date set (4 weeks out) to check completion
The Post-Mortem Template
Header
Post-Mortem Title: [Project/Feature/Launch Name]
Date of Event: [When the event occurred]
Post-Mortem Date: [When this review happened]
Facilitator: [Name]
Attendees: [Names and roles]
Severity/Scope: [High/Medium/Low impact]
Section 1: Summary
What happened (2-3 sentences):
[Brief, factual description of the event and its outcome]
Expected outcome:
[What was the target or hypothesis?]
Actual outcome:
[What actually happened?]
Gap:
[Quantified difference between expected and actual]
Section 2: Timeline
| Date | Event | Decision/Action | Who |
|---|---|---|---|
| [Date] | [What happened] | [What was decided] | [Name] |
| [Date] | [What happened] | [What was decided] | [Name] |
| [Date] | [What happened] | [What was decided] | [Name] |
| [Date] | [What happened] | [What was decided] | [Name] |
| [Date] | [What happened] | [What was decided] | [Name] |
Section 3: What Went Well
- ☐ [Positive outcome 1: specific detail]
- ☐ [Positive outcome 2: specific detail]
- ☐ [Positive outcome 3: specific detail]
Why these worked:
[Brief analysis of contributing factors]
Section 4: What Went Wrong
- ☐ [Issue 1: specific detail with quantified impact]
- ☐ [Issue 2: specific detail with quantified impact]
- ☐ [Issue 3: specific detail with quantified impact]
Section 5: Root Cause Analysis
Issue 1: [Name]
- What happened: [Description]
- Why (1): [Proximate cause]
- Why (2): [Deeper cause]
- Why (3): [Root cause]
- Root cause category: [Process / Information / Tooling / Communication / Scope / Staffing]
Issue 2: [Name]
- What happened: [Description]
- Why (1): [Proximate cause]
- Why (2): [Deeper cause]
- Why (3): [Root cause]
- Root cause category: [Process / Information / Tooling / Communication / Scope / Staffing]
Issue 3: [Name]
- What happened: [Description]
- Why (1): [Proximate cause]
- Why (2): [Deeper cause]
- Why (3): [Root cause]
- Root cause category: [Process / Information / Tooling / Communication / Scope / Staffing]
Section 6: Impact Assessment
| Metric | Target | Actual | Delta |
|---|---|---|---|
| [Primary KPI] | [Target] | [Actual] | [+/- %] |
| [Secondary KPI] | [Target] | [Actual] | [+/- %] |
| [User metric] | [Target] | [Actual] | [+/- %] |
| [Revenue metric] | [Target] | [Actual] | [+/- %] |
Engineering effort spent: [X engineer-weeks]
Opportunity cost: [What else could have been built]
Section 7: Follow-Up Actions
| # | Action | Owner | Due Date | Definition of Done | Status |
|---|---|---|---|---|---|
| 1 | [Specific action] | [Name] | [Date] | [What "done" looks like] | Not started |
| 2 | [Specific action] | [Name] | [Date] | [What "done" looks like] | Not started |
| 3 | [Specific action] | [Name] | [Date] | [What "done" looks like] | Not started |
| 4 | [Specific action] | [Name] | [Date] | [What "done" looks like] | Not started |
| 5 | [Specific action] | [Name] | [Date] | [What "done" looks like] | Not started |
Follow-up review date: [4 weeks from post-mortem date]
Section 8: Lessons for the Team
What we would do the same way again:
- [Lesson]
- [Lesson]
What we would do differently:
- [Lesson]
- [Lesson]
Process changes to implement:
- [Change]
- [Change]
Example: Post-Mortem in Action
Scenario: A B2B SaaS team launched a new reporting dashboard. The target was 60% adoption among existing enterprise accounts within 90 days. At day 90, adoption was 34%.
How to apply:
- Timeline reconstruction revealed the team skipped beta testing with enterprise users because of a board-mandated launch date. Two critical workflows (custom date ranges and export-to-PDF) were not included in v1.
- Root cause analysis surfaced three issues: (a) the launch date was set before scoping was complete, (b) the PM assumed enterprise users would accept a phased rollout, and (c) user research was conducted only with SMB accounts.
- Impact assessment showed 34% adoption vs. 60% target, with 71% of enterprise support tickets mentioning missing export functionality. Engineering spent 14 weeks on the build.
- Follow-up actions included: ship export-to-PDF within 30 days (owner: engineering lead), run 5 enterprise user interviews before scoping v2 (owner: PM), and institute a policy requiring customer segment validation before setting launch dates (owner: VP Product).
The team hit 58% adoption within 60 days of shipping the export feature. The post-mortem's root cause analysis prevented the same mistake on their next enterprise feature.
Tips
- Assign a facilitator who was not the project lead. The PM or engineering lead often feels defensive (naturally). A neutral facilitator keeps discussion focused on systems, not individuals.
- Send pre-work 48 hours before. Ask each attendee to write 2-3 observations about what happened and why. This prevents the loudest voice from setting the narrative and gives quieter team members equal input.
- Time-cap the timeline section at 15 minutes. Teams can spend the entire meeting debating what happened on which date. Set a timer. The timeline is context, not the main event.
- Categorize root causes. Tagging each root cause as Process, Information, Tooling, Communication, Scope, or Staffing reveals patterns across post-mortems. If 80% of your root causes are "Scope," that points to a product discovery or estimation problem.
- Review follow-up actions 4 weeks later. The most common post-mortem failure mode is producing good actions that nobody tracks. Put the review on the calendar during the post-mortem itself.
Common Mistakes
- Skipping the timeline. Without a shared timeline, team members argue from different mental models of what happened. Spend the first 15 minutes aligning on facts before analyzing.
- Stopping at the proximate cause. "We missed the deadline because QA found bugs late" is a proximate cause. Ask why QA found bugs late. Ask why that testing gap existed. The root cause is usually 2-3 layers deeper.
- Writing lessons instead of actions. "We should communicate earlier" is a lesson. "PM will share draft specs with engineering leads 5 business days before sprint planning, starting next cycle" is an action. Only actions change behavior.
- Running post-mortems only for failures. Successful launches deserve post-mortems too. Understanding why something worked lets you repeat it. Luck does not scale.
- Making the post-mortem optional. If post-mortems only happen after disasters, the team associates them with punishment. Make them a standard part of every significant release cycle.