Startup post-mortem template
A post-mortem has exactly one goal: turning a failure (or an incident, or a botched launch) into a learning the company will not forget. Most post-mortems fail at the second part: the document gets written, filed, and never read again.
This template is deliberately short. A one-page post-mortem the team actually fills in beats a ten-section ritual abandoned by the second incident.
The template
Copy the block below into your tool (the duplicable Notion / Google Docs version is available at the bottom of this page).
Header
| Field | Content |
|---|---|
| Title | A clear name: "Launch of X", "March 12 incident"… |
| Event date | When it happened |
| Post-mortem date | Ideally less than a week later |
| Participants | Who was involved, who writes |
| Severity | Minor · Significant · Critical |
1. What was supposed to happen
Two or three sentences: the initial plan, the expectation, the starting hypothesis. Without this baseline, the gap cannot be measured.
2. What actually happened
The facts, in order, with dates. No interpretation yet: a timeline. This is the part you will wish you had when rereading six months later.
3. Why (causes, not culprits)
The golden rule: blameless. You are looking for structural causes, not guilty parties. Simple technique: ask "why?" several times until you reach a cause you can actually act on.
4. What we knew and ignored
The most uncomfortable and most profitable question in the template. In almost every failure, signals existed beforehand: a customer comment, a doubt someone voiced, an odd number. Listing them in black and white teaches the team to listen next time.
5. The learnings
Two or three at most, phrased as reusable rules: not "the launch failed", but "never launch again without testing the signup flow on mobile." A learning that changes no future behavior is not a learning.
6. The actions
| Action | Owner | Due date |
|---|---|---|
| ... | ... | ... |
Three actions maximum. Beyond that, nothing gets done.
The part everyone misses: the reread
Once the post-mortem is filled in, the real problem remains: bringing those learnings back at the moment they matter. A doc filed in a "Post-mortems" folder will not warn anyone, six months later, that the team is about to make the exact same mistake.
Two practices that change everything:
- Reread the learnings from past post-mortems before any decision of the same type (before a launch, reread the launch post-mortems).
- Keep the learnings in a shared memory, not in separate documents — which is precisely the job of a business memory like Verbasil: the learning stays linked to the original decision and its evidence, and resurfaces when the topic comes back.
FAQ
When should you run a post-mortem?
Within the week following the event, while the facts and feelings are fresh. Beyond that, the timeline gets reconstructed from memory and loses reliability. A post-mortem is worth running for any failure or incident the company wants to learn from durably, not just major crises.
Should a post-mortem name who is responsible?
No. The blameless rule is not decorative kindness: if participants fear being singled out, they hide the information the analysis needs. You are after structural causes (process, ignored signals, wrong assumptions), which are the only ones you can act on.
How do you keep post-mortem learnings alive?
By getting them out of the document. Phrase each learning as an actionable rule, add it to the team's shared memory, and reread the relevant learnings before any decision of the same type. A post-mortem sleeping in a folder only served as catharsis.