Post-Launch Retrospective Template
72-hour post-launch retro agenda covering what shipped, what broke, what to change, and the written artifact format.
What this template covers
Post-launch retros slip because the team is tired and the next launch is already starting. This template enforces a 72-hour window, uses a Start/Stop/Continue format with a twist (two columns for 'what surprised us' and 'what the data said'), and produces a written artifact with three named follow-ups and owners. Product ops facilitates; engineering lead owns the written doc.
The template
# Post-Launch Retrospective **Launch:** ___________ **Launch date:** YYYY-MM-DD **Retro date:** YYYY-MM-DD (must be within 72h of launch) **Facilitator:** Product Operations **Scribe:** PM **Attendees:** PM, Eng Lead, Design Lead, Marketing, Support, CSM, Data --- ## Ground rules (read aloud at the start) - Blameless. We're examining the system, not individuals. - Every voice in the room speaks at least once. - We are looking for **patterns**, not stories. - We will produce a written artifact and three named follow-ups before we leave. --- ## Agenda (60 minutes) | Time | Block | Format | | --- | --- | --- | | 0:00-0:05 | Recap what shipped and the original success criteria | PM presents | | 0:05-0:15 | "What worked" — silent write, then round-robin | Sticky notes or doc | | 0:15-0:30 | "What broke" — silent write, then round-robin | Sticky notes or doc | | 0:30-0:40 | "What surprised us" — open discussion | Group | | 0:40-0:50 | "What the data said" — Data lead presents | 24-72h post-launch metrics | | 0:50-0:60 | Three follow-ups, with named owners and due dates | PO drives | --- ## Artifact (publish within 5 business days) ### Section 1 — What shipped A two-paragraph summary: what went out, who it's for, the headline change. ### Section 2 — Original success criteria vs. actuals | Metric | Target (T+30) | Actual (T+7) | Trend | | --- | --- | --- | --- | | | | | | | | | | | | | | | | ### Section 3 — What worked Three bullets max. Be specific. "The launch playbook was clear" is too vague. "The launch playbook caught the missing legal review on day -10, before it could slip the date" is right. - - - ### Section 4 — What broke Three bullets max. Each gets a one-sentence root-cause hypothesis. - - - ### Section 5 — What surprised us Anything you predicted incorrectly. These are the most valuable bullets in the document. - - ### Section 6 — What the data said Two paragraphs from the data lead: how is the launch performing, what we still need to learn. ### Section 7 — Follow-ups | # | Action | Owner | Due | Status | | --- | --- | --- | --- | --- | | 1 | | | | | | 2 | | | | | | 3 | | | | | ### Section 8 — T+30 review Schedule the T+30 follow-up review **before leaving the retro.** This is the meeting where you check whether the launch actually delivered what you predicted at T+7. - T+30 review date: YYYY-MM-DD - Attendees: same as retro - Facilitator: PO --- ## Anti-patterns to watch for - Skipping the retro because "the launch went well" - Letting the retro slip past 72 hours because the next launch is starting - Producing slides instead of a doc - Closing the meeting without three named follow-ups and dates - Treating the T+30 review as optional
When to use it
- Retro for a major launch
- Post-incident review
- Debrief after a failed launch
- Template for every launch, standardized
How to adapt it
Copy the template above into Google Docs, Sheets, Notion, Airtable, or Confluence. Keep the section order intact, later sections often reference data entered earlier. Replace the example values with your own, then review quarterly and re-circulate to stakeholders.
Related templates
Templates are drafted from public Product Operations research and reviewed by practicing PO leaders. Free to copy and modify for internal company use.
Frequently Asked Questions
Post-launch retros slip because the team is tired and the next launch is already starting. This template enforces a 72-hour window, uses a Start/Stop/Continue format with a twist (two columns for 'what surprised us' and 'what the data said'), and produces a written artifact with three named follow-ups and owners. Product ops facilitates; engineering lead owns the written doc.
This template is written for Product Operations teams at software companies sized 50-500 employees. Common use cases include: Retro for a major launch; Post-incident review; Debrief after a failed launch.
The template is designed as a Google Doc. Copy the structure directly into your own Google Docs, Sheets, Notion, or Airtable workspace. No attribution is required for internal company use.
Start with the section structure exactly as published, then modify field names to match your organization's vocabulary. Most teams complete a first pass in 30 minutes and a polished version within one working week.