Three weeks after launch, someone on your team says "we should never do a tutorial that late again." Everyone nods. Nobody writes it down. Eighteen months later you are building a tutorial in the last six weeks of the project, again, and the same person says the same sentence.
That is what a missing post-mortem costs: not a document, but a repeated mistake with a two-year payback period. A good post-mortem is neither a therapy session nor a victory lap. It is a structured attempt to turn one project's scar tissue into a small number of decisions that bind the next one.
Run it twice, not once
The classic post-mortem happens after shipping. By then the early decisions are fuzzy and the people who made them have rewritten their memory of them. Do the end-of-project one anyway, but add a shorter version after every milestone: vertical slice, each content milestone, demo, beta, launch, and each major patch.
A milestone retrospective costs 60–90 minutes and catches process problems while you can still act on them. You cannot un-ship a launch, but you can change how you schedule the next six months of content.
| Type | When | Length | Output |
|---|---|---|---|
| Milestone retro | Within 5 days of a milestone | 60–90 min | 3–5 process changes for the next milestone |
| Launch post-mortem | 3–6 weeks after launch | 3 hours, split in two sessions | Written doc + decisions carried into the next project |
| Public post-mortem | After the internal one | Blog/talk | Edited subset, no blame, no NDA material |
Three to six weeks after launch is the sweet spot for the big one: late enough that the panic patches are done and the sales data has a shape, early enough that people still remember the crunch.
Gather evidence before the meeting, not during it
The failure mode of every post-mortem is that it becomes a conversation about feelings in the last month of development, because that is the only part anyone remembers clearly. Fix that by walking into the room with a reconstructed timeline.
One person — ideally not the lead, so the lead can be a participant rather than a defender — spends two or three hours assembling:
- A build timeline. Dates and version numbers of every significant build, from first playable to launch, pulled from your build tracking records. Annotate what changed in each.
- Task and sprint history. Which sprints slipped, by how much, and what moved to the next one. The pattern you are looking for is the task that got rescheduled five times — that is a design problem wearing a scheduling costume.
- The decision log. Every call you recorded, with its date and the reason given at the time. This is the single most valuable artifact, because it lets you compare the reasoning you used then to the outcome you got. Tools built for this — GameDesignerX keeps decision, issue and risk logs alongside the design docs they refer to — mostly earn their keep in this one meeting.
- Playtest results. What testers said at each round, and how long it took you to act on it. A finding that appeared in three consecutive playtests and shipped unchanged is a process failure, not a design one.
- The original risk log, if you wrote one. Which risks fired, which never materialised, and which real problems were nowhere on the list.
- Hard numbers. Planned versus actual duration per milestone, bug count per milestone, wishlists at announce and demo and launch, refund rate — whatever you actually measured.
Circulate that packet two days ahead with one instruction: come with three things that went well and three that did not, written down before the meeting. Written-first beats spoken-first, because the first person to speak in an unstructured retro sets the agenda for everyone else.
A three-hour agenda that does not drift
Split it across two sessions a day or two apart. People think of their real answers overnight.
Session one — what happened (90 minutes)
- Timeline walk (25 min). Read the build timeline out loud, milestone by milestone. No analysis yet. The goal is shared memory.
- Silent writing (10 min). Everyone adds items to three columns: kept us alive, cost us time, nearly killed us.
- Clustering (20 min). Group the items. Clusters with four independent mentions are your real topics; a single mention is one person's bad week.
- Pick five (15 min). Vote. Five topics, ranked. Everything else goes in the document as an appendix and is not discussed.
- Wins pass (20 min). Go through what worked, properly. If you only analyse failures you will quietly delete the practices that saved you, because nobody ever defended them out loud.
Session two — why, and what changes (90 minutes)
For each of the five topics, 15 minutes: trace the cause, then write one concrete change. Then 15 minutes at the end to cut the list down to what you will actually do.
Use a cause chain, not a culprit. "The tutorial shipped unfinished" → it started in month 20 of 24 → because the first playable had no onboarding and nobody noticed → because onboarding was not in any milestone definition → because those definitions listed content, not player experience. The change is not "start the tutorial earlier." It is "every milestone definition names the player-facing experience it must prove, not just the assets it must contain." That is a rule you can apply next week.
The rule of five changes
Every post-mortem produces a list of twenty improvements and your next project adopts zero of them. Cap it at five, and make each one pass every test below:
- It is a behaviour, not an aspiration. "Better communication" fails. "The design lead writes a one-page spec before any feature enters a sprint" passes.
- It has an owner by name. Not a role, a person.
- It has a trigger. What event makes this change fire? "At project kickoff," "when any feature is estimated over two weeks," "before every playtest round."
- You can tell whether it happened. Three months in, someone can check yes or no.
- It costs something you have. A change that needs a hire or a tool you cannot afford is not a change, it is a wish.
Write those five into the place where your next project actually starts — the design decision log of the new project, the kickoff checklist, the milestone template. A post-mortem document in a folder nobody opens is just a nicely formatted regret.
Keeping it blameless without making it useless
"Blameless" does not mean "causeless." You still have to say that the combat system was rebuilt three times. The discipline is in how you attribute it: to a decision, a process gap, or an information deficit, never to a character flaw. In practice that means a facilitator who interrupts twice:
- When a sentence names a person as the cause, ask what information that person was missing at the time.
- When the room agrees too fast, ask who disagrees — and if nobody does, ask what evidence would change the conclusion.
One more guardrail: the person who made the call that went wrong should state the reasoning they had at the time, from the decision log, before anyone evaluates it. Most "bad decisions" turn out to be reasonable decisions made with the information available, which means the fix belongs to your information flow, not to someone's judgment.
The public version
Publishing a post-mortem is good for your studio and for everyone behind you, but it is a different document. Cut anything under NDA, anything that identifies an individual's mistake, and anything about publisher or platform relationships you still need. Keep the numbers you are willing to stand behind, and keep the decisions — the useful part of any public post-mortem is not "we sold X copies," it is "here is the call we made in month four and here is what it cost us."
Then do the thing almost nobody does: schedule a review of your own five changes three months out. Did they fire? Did they help? That loop is the entire point. A post-mortem you never check is a story you told yourselves; a post-mortem you audit is a process that improves.