Post-mortems as a habit, not a ceremony

Most teams reach for a post-mortem only when something has broken. A release failed. A launch missed the date. A customer escalated. The meeting gets called, the slide deck gets built, and the team spends an hour walking through what went wrong before going back to the work.

That version of the post-mortem is a ceremony. It signals failure. It produces a small set of lessons-learned bullets that may or may not change anything. And it teaches the team to associate the meeting with discomfort, which makes the next post-mortem harder to convene than the last.

The most effective version is different. It's a habit, not a ceremony. It happens regularly, not exceptionally. And it happens after wins as often as after losses.

Why the wins matter more

Annie Duke names a thinking error she calls resulting: judging the quality of a decision by the quality of its outcome. A bad decision can lead to a good result by sheer luck. A good decision can lead to a bad result the same way. If you only review the outcomes you didn't like, you systematically miss the good outcomes that came from bad reasoning. And bad reasoning, unexamined, repeats.

This is why the wins are where leverage hides. A successful launch can mask the fact that three teams duplicated effort, that the timeline only worked because someone burned out, or that the launch caught a tailwind unrelated to the team's choices. None of that surfaces in the celebration. All of it shapes the next launch.

A post-mortem after a win asks: what worked, and why? Then the harder version: would we make the same choices again with what we now know?

Four traditions worth borrowing from

The principle isn't new. It has been worked out independently in several high-stakes fields, each of which arrived in roughly the same place.

In software, Norm Kerth formalised the project retrospective in 2001 and named what he called the Prime Directive: the assumption, going into the meeting, that everyone involved did the best work they could with what they had at the time. That assumption is what makes honest discussion possible.

In site reliability engineering, Google's SRE practice popularised the blameless post-mortem: write it to understand the system, not to assign individual fault. The aim is to make the system more reliable by understanding how the failure became possible, not to find the person whose mistake it was.

In medicine, the surgical Morbidity and Mortality conference has existed for over a century. At its best, it's the cultural backbone of safer surgery. At its worst, the unspoken curriculum has been described as abuse, berate, and chastise. The modern version learned to focus on systems and patterns instead, in part thanks to writers like Atul Gawande, who documented the older culture in Complications.

In decision theory, Duke's Thinking in Bets makes the case that separating decisions from outcomes is not just a learning practice. It's a discipline of thought.

What a good post-mortem actually looks like

There is no single template. The shape varies by team, cadence, and context. But the strong versions share a few features.

• They happen on a schedule, not on demand. A regular cadence after each delivery cycle is more useful than an annual ceremony triggered by the big failure. The regularity is what makes the conversation routine instead of charged.
• They cover wins and losses with equal weight. The team that only meets when something has broken is teaching itself that the meeting is a punishment.
• They focus on the system, not the people. The question is never who did this? It's how did this become possible? That shift unlocks honest contribution.
• They produce actions, not just observations. Every recurring observation without a follow-up action erodes the team's confidence that the post-mortem is real.
• They are documented for the next person. The decision log lives here. Pattern recognition happens over time, across many post-mortems, not in any single one.

Because the artefacts do the remembering, a steady cadence quietly becomes one of the governance surfaces a PM holds — see the PM as governance system. And the cadence reads differently depending on the kind of work: a migration's post-mortem asks did we deliver as planned?, while an exploratory workstream's asks what did we learn, and was the bet sound? (more in running two workstreams as one PM).

The product manager's role

You are not the one with the solutions. That's not the PM's job in a post-mortem.

Your job is to frame the problem clearly, bring the right people into the room, and protect the discussion from defensiveness so the actual reasoning surfaces. The team supplies the diagnosis and the fix. You hold the space in which both can happen. When the follow-up actions cross team boundaries, the ownership matrix decides who actually carries each one — see multi-team coordination.

This is also why post-mortems are an underused PM lever. They are one of the cheapest ways to build a learning culture, and one of the most reliable ways to make a team's improvement compound over time.