Postmortem template
A postmortem is a structured review of what happened and why — filled in by your agent in under a minute, then shared as a link where the team comments on the exact line. Action items don't get lost.
Most postmortems fail at the same point: the action items get assigned to "the team" with no due date, the doc goes into a shared drive nobody opens, and the next project starts with the same unresolved patterns. The template isn't the problem. The missing piece is a single shareable version where comments land on the exact line they're about — and every action item is one click away from the next planning doc.
Generate it with your agent
Paste this into Claude, Cursor, or any agent — it drafts the postmortem and publishes it as a Drafty link your team can annotate directly:
See it on a real one
What goes in a postmortem
Six sections. The order matters — summary first so anyone can read the first paragraph and decide whether they need the rest.
- Summary — the project, the outcome, and a plain verdict. "Shipped two weeks late; core feature worked but onboarding was unfinished at launch." One paragraph.
- What went well — specific wins to repeat. "We used a shared Figma file for the first time and design-dev handoff was half as slow" is useful. "Good teamwork" is not.
- What failed — the honest account, named at the system level. "We had no owner for the API integration decision for three weeks" rather than naming the person who didn't decide. Blame cultures produce postmortems people don't tell the truth in.
- Root cause — for the biggest failure, trace it one level deeper than the surface symptom. If the launch was late because of a last-minute security review, the root cause is that security wasn't in the launch checklist — not that the review took long.
- Action items — the section most postmortems get wrong (more below).
- Lessons — what the team would do differently from day one. Three or four. A list of twelve is a list nobody reads.
The section most postmortems get wrong
Action items. They are consistently the most poorly executed section in postmortem templates — not because teams don't know what to fix, but because the items aren't written to survive the week after the meeting.
Two rules that make the difference:
- One name per item, not "the team." When an action item belongs to everyone, it belongs to no one. If the right owner isn't obvious, the item needs to be broken into smaller pieces until it is.
- A done-condition, not a direction. "Improve the handoff process" will never be done. "Add a handoff checklist to the sprint planning template by {date}" will. Write the done-condition before you leave the meeting.
Cap at five items. A postmortem that produces ten action items will complete zero of them — the list becomes noise by the next standup. Pick the five that would have prevented the most pain.
Postmortem vs retrospective — which one to run
They're often used interchangeably, but they're different in scope and timing.
A retrospective (or retro) is a recurring team ritual — typically at the end of each sprint — covering the process and dynamics of the last two weeks. Short, frequent, forward-looking.
A postmortem is written after a significant event: a product launch, a major incident, a cancelled project, a feature that shipped with serious bugs. It's longer, less frequent, and goes deeper into root cause. It often includes impact numbers — revenue affected, users impacted, SLA breach duration — that a sprint retro wouldn't track.
If your sprint just had a rough week, run a retro. If a launch went sideways or production went down for four hours, run a postmortem.
Who should write it and when
The person closest to the event owns the first draft — the project lead or incident commander. Not a committee. A committee-written postmortem is one with no clear conclusions.
First draft within 48 hours. Memory accuracy drops sharply after 72 hours, and the team starts constructing narratives that make the outcome seem more inevitable (or more random) than it was. Fast drafts are messier but more honest.
Share the draft as a link rather than a file in a shared drive. The goal is reactions anchored to specific lines — "the root cause here is wrong, it was actually X" should land on that sentence, not arrive as a reply-all email.
FAQ
What's the difference between a postmortem and a root cause analysis (RCA)? An RCA is a subset of the postmortem — the specific investigation into why a failure occurred, usually using a structured technique like the 5 Whys or fishbone diagram. A postmortem is the full document that includes the RCA plus the impact, what went well, and the action items. Some teams use the terms interchangeably for technical incidents; either way, the goal is the same.
How long should a postmortem be? One to three pages for most projects. An executive summary at the top handles anyone who needs the headline without the detail. More than five pages usually means you're capturing everything rather than the important things.
Should postmortems be blameless? Yes — and this is misunderstood. Blameless doesn't mean accountability-free. It means the postmortem focuses on systems and processes, not on individual fault. People make better decisions in the context of bad systems, unclear ownership, and missing information. Naming the system failure ("there was no deployment checklist") is more useful than naming the person who skipped the step.
How many action items should a postmortem produce? Three to five, maximum. Each one needs a single owner and a specific done-condition. If you leave the postmortem meeting with ten action items, schedule a 20-minute follow-up to cut the list in half — the items you wouldn't fight to keep are the ones that won't get done anyway.
When is it too late to run a postmortem? Never — but it gets less useful fast. After two weeks, people's accounts are reconstructed rather than recalled. Run it within a week if you can. If you missed the window, a 45-minute conversation with a drafted doc is more useful than skipping it.