Post-mortem: definition
A post-mortem is the structured analysis of a failure, incident or finished project, run after the fact to understand its causes and extract lessons. The term comes from forensic medicine and was popularized in business by engineering teams, who run one after every production incident. Its central principle: analyze causes without assigning blame, so the team learns instead of defending itself.
Why post-mortems matter
An unexamined failure costs twice: once when it happens, once when it repeats. Without a post-mortem, each team member walks away with their own version of the causes, often contradicting everyone else's, and the company learns nothing collectively. The article Why startups forget their decisions describes how this kind of knowledge evaporates when it is not captured.
A post-mortem turns the failure into an asset: identified causes become lessons, lessons become decisions, and the same mistake does not replay six months later under a different name.
What a post-mortem is not
- It is not a trial. The blameless rule is not politeness: a post-mortem where people feel judged produces defensive narratives and disguised causes. You analyze the conditions that made the error possible, not the person who made it.
- It is not a sprint retrospective. A retrospective is a regular continuous-improvement ritual; a post-mortem is triggered by a specific event, a failure or an incident.
- It is not just for engineering. A failed launch, an abandoned acquisition channel or a hiring miss deserve the same exercise.
A post-mortem is a specific format of lessons learned, focused on one event where the broader practice can cover any project.
How to run one in practice
A good post-mortem follows a stable structure:
- The factual timeline: what happened, in order, without interpretation. This shared baseline keeps the analysis from starting with impressions.
- The impact: what the failure cost, in concrete and honest terms.
- The causes: digging past the immediate cause, for example with the five-whys method, down to the structural conditions.
- Lessons and actions: phrased so they are actionable, each with an owner and a deadline.
The startup post-mortem template provides this structure ready to copy. Decisions that come out of it belong in a decision record, so the chain from failure to lesson to decision stays traceable.
The classic trap: a well-run post-mortem filed in a folder nobody reopens. The lessons need to join the team's memory and resurface when a similar project is being planned. That is what a living memory like Verbasil does, linking the failure, its causes and its lessons to future decisions.
FAQ
When should a team run a post-mortem?
After any failure or incident the team wants to avoid repeating: a production incident, a disappointing launch, a halted experiment, an abandoned project. The right moment is close to the event, while the facts are fresh, but after things have calmed down so analysis outweighs emotion.
Why must a post-mortem be blameless?
Because the goal is information, not punishment. If participants fear judgment, they deliver defensive accounts and the real causes stay hidden. By analyzing the conditions that made the error possible rather than the person, you get usable facts and fixes that hold.