A template for a product launch post-mortem analysis should document the timeline of key decisions, what went well and what failed with root causes, quantified impact of any issues, and action items with owners and due dates — completed within 2 weeks of launch while memory is fresh and before the team moves on to the next initiative.
Most product launch post-mortems are either skipped entirely or done so long after launch that the institutional memory of what actually happened has faded. The post-mortem's value is proportional to how quickly it's completed and how honest it is. A post-mortem completed 3 months post-launch surfaces fewer learnings than one completed in week 2.
When to Run a Product Launch Post-Mortem
Run a post-mortem after:
- Any launch that missed its success metric targets by more than 20%
- Any launch that experienced a production incident within the first 30 days
- Any launch where the team felt significant launch-day friction
- Any major launch regardless of outcome (the learnings from successful launches are as valuable as from failures)
Timing: Start the post-mortem within 2 weeks of launch. Block 2 hours for the team session and 1 hour for the PM to prepare materials beforehand.
Product Launch Post-Mortem Template
Section 1: Launch Summary
Product / Feature: [Name] Launch Date: [Date] Post-Mortem Date: [Date — should be within 2 weeks of launch] Facilitator: [PM Name] Participants: [Names and roles]
What we launched: [2–3 sentences describing what shipped]
What we expected: [Quantified — specific metrics targets set before launch]
What actually happened: [Quantified — actual metrics vs. targets, production incidents, support ticket volume, any other measurable outcomes]
Section 2: Timeline of Key Decisions
List every significant decision made during the launch process, when it was made, and who made it.
| Date | Decision | Made by | Context | |------|---------|---------|---------| | [Date] | Scope cut: removed X feature to hit launch date | PM + Eng Lead | Engineering capacity constraint | | [Date] | Delayed launch by 1 week for QA fix | PM | Critical bug found in staging | | [Date] | Proceeded with launch despite known Y issue | PM + CPO | Risk accepted, fix planned for week 2 |
This timeline serves two purposes: it creates a factual record for the post-mortem, and it often surfaces that good-faith decisions made under time pressure led to suboptimal outcomes — without blame.
Section 3: What Went Well
Format: Specific, observable statements. Not "communication was good" but "the launch brief was distributed 5 days before launch and CS confirmed they felt prepared."
- [Specific thing that worked, with evidence]
- [Specific thing that worked, with evidence]
- [Specific thing that worked, with evidence]
Section 4: What Failed or Underperformed
Format: Each failure item should have: what happened, when it was first detected, root cause, and impact.
| Issue | When detected | Root cause | Impact | |-------|-------------|-----------|--------| | [Issue description] | Day 1 post-launch | [Specific root cause] | [Quantified: N support tickets, X% metric miss, Y production errors] | | [Issue description] | Week 2 | [Specific root cause] | [Quantified] |
Root cause depth requirement: Do not stop at the first cause. Use the 5 Whys:
- Why did X happen? Because of Y.
- Why did Y happen? Because of Z.
- Continue until you reach a systemic cause (process gap, missing checklist item, unclear ownership) rather than a one-time mistake.
According to Shreyas Doshi on Lenny's Podcast, the most common post-mortem failure is stopping at surface-level causes — "we didn't test that scenario" is not a root cause; the root cause is whatever process should have caught it and didn't.
Section 5: Quantified Impact Assessment
| Impact area | Planned | Actual | Delta | Significance | |-------------|---------|--------|-------|-------------| | Primary metric (D30) | [Target] | [Actual] | [+/-] | [Significant / Within noise] | | Support ticket volume | <10/week baseline | [Actual] | [+/-] | [Significant / Within noise] | | Production error rate | <0.1% | [Actual] | [+/-] | [Significant / Within noise] | | Customer satisfaction | NPS >40 | [Actual] | [+/-] | [Significant / Within noise] |
Section 6: Action Items
Each action item must have: what will change, who owns it, and when it will be done. Post-mortem action items without owners and due dates are aspirations, not commitments.
| Action | Category | Owner | Due date | Status | |--------|---------|-------|---------|--------| | Add [test type] to launch checklist | Process | PM | [Date] | Open | | Implement [monitoring alert] for future launches | Technical | Eng Lead | [Date] | Open | | Update rollout playbook with [specific step] | Process | TPM | [Date] | Open |
Action categories:
- Process: Changes to how launches are planned or executed
- Technical: Changes to tooling, monitoring, or infrastructure
- Communication: Changes to how launches are communicated internally or externally
- Ownership: Changes to who is responsible for specific launch activities
Section 7: Decisions for Future Launches
Based on this launch, what should we do differently for all future launches?
List 2–3 specific changes to the launch process:
- [Specific change]: Previously we [did X]. In future launches we will [do Y instead] because [this launch showed that X caused Z].
- [Specific change]
- [Specific change]
Running an Effective Post-Mortem Session
According to Lenny Rachitsky on his podcast discussing launch retrospectives, the most effective post-mortems are blameless — the goal is to improve the system, not evaluate individuals. Starting with "what did the system fail to catch?" rather than "who made the mistake?" produces more honest and actionable outcomes.
Facilitation guidelines:
- Send the timeline of key decisions document before the session so attendees can review factual history
- Open with what went well before what failed (psychological safety before critique)
- For each failure item: ask "what would have had to be true for this not to happen?" rather than "who should have caught this?"
- Close with explicit confirmation of action item owners — no action item leaves the room without an owner
FAQ
Q: What should a product launch post-mortem analysis template include? A: Launch summary with quantified planned vs. actual metrics, timeline of key decisions, what went well with evidence, what failed with root causes, quantified impact assessment, action items with owners and due dates, and decisions for future launches.
Q: When should you run a product launch post-mortem? A: Within 2 weeks of launch, for any launch that missed targets by more than 20%, experienced a production incident, or involved significant launch friction. Run it for successful launches too — the learnings are equally valuable.
Q: How do you conduct a blameless post-mortem? A: Ask "what would have had to be true for this not to happen?" rather than "who made the mistake?" Document the timeline of decisions factually before the session so discussion focuses on system gaps rather than individual errors.
Q: How do you turn post-mortem learnings into process improvements? A: Each action item must have an owner, a due date, and a specific change to process, tooling, communication, or ownership — not vague intentions. Review action item completion at the start of the next launch planning cycle.
Q: What is the 5 Whys technique in a product launch post-mortem? A: A root cause analysis method that asks "why" five times for each failure to find the systemic cause rather than stopping at the surface-level symptom — for example, "we didn't test that scenario" is not a root cause; the underlying process gap that allowed it is.
HowTo: Run a Product Launch Post-Mortem Analysis
- Schedule the post-mortem within 2 weeks of launch and prepare the timeline of key decisions document before the session so attendees start with shared factual history
- Document what went well with specific, observable evidence before covering failures to establish psychological safety for honest retrospective discussion
- For each failure or underperformance, identify the root cause using 5 Whys rather than stopping at surface-level explanations like we did not test that scenario
- Quantify the impact of each issue in measurable terms — support ticket count, metric miss percentage, production error rate — so severity can be assessed objectively
- Create action items with specific process changes, named owners, and due dates for every systemic gap identified — no action item leaves the session without an owner
- Review post-mortem action item completion at the start of the next major launch planning cycle to close the organizational learning loop