What a postmortem is for
A postmortem is a structured look back at a project, done after release or after you decide to stop. Its purpose is not to judge anyone. It is to collect what you learned while it is still fresh, so the next project starts from knowledge instead of vague impressions.
Memory is unreliable here. After a long project, people tend to remember the last few weeks vividly and the early months poorly, and success or failure colors how the whole thing is recalled. Writing the review down, and doing it soon, protects against that.
When to do it
A good moment is a few weeks after release, once the launch rush has settled but before details fade. Some teams also hold small reviews at the end of each milestone, which makes the final one easier because much of the material already exists. A cancelled project deserves a postmortem too. Often, those reviews teach more than a smooth launch does.
If the project was a solo effort, you can still do this. Set aside a couple of hours, and treat your past self as a colleague whose decisions you are trying to understand, not to scold.
Gather material first
Before opinions, collect facts.
- The original plan and the final result: what you intended to build and what you actually shipped.
- Rough dates for major events, such as when the prototype worked, when the content was complete and when the release happened. Your own task lists, messages and version history are good sources.
- Any feedback you received from testers and players.
- Whatever numbers you have access to, such as store page visits, wishlists or crash reports, treated carefully. Small numbers are noisy, and a single week may say little.
Do not invent precision. If your production schedule was never tracked closely, or you did not record what the development budget went to, say “roughly” and move on. An honest estimate is more useful than a made-up figure.
Questions that produce useful answers
Start with open questions and let people answer in their own words.
- What went well, and why? Be specific about the cause, not just the result.
- What went poorly, and why?
- What took much longer than expected? What took less?
- Which decisions would you change, knowing what you know now?
- What did you cut, and was it the right thing to cut?
- What surprised you about players, the tools or yourselves?
- What would you do the same way next time?
The second half of that list matters. Teams often review only problems, which risks discarding practices that worked. Recording the habits worth keeping is just as valuable.
Separate decisions from outcomes
The hardest part of a postmortem is distinguishing a good decision from a good result. A choice can be sensible and still turn out badly because of factors nobody controlled, and a careless choice can work out by luck. If you judge decisions only by outcomes, you learn the wrong lessons.
A useful test is to ask: given what we knew at the time, was this a reasonable choice? If yes, the lesson may be about gathering better information rather than blaming the decision. This is especially important when discussing sales or reception. A game’s reception depends on timing, visibility and the wider market, and a single title tells you very little about cause.
Be equally careful about explaining a result with one neat story. Most outcomes have several contributing factors, and it is fine to write “we are not sure why” when that is the truth.
Keep it blame-free
In a team, the tone decides whether people tell the truth. Focus on processes and situations rather than individuals. “Our build broke often because we had no shared routine for merging work” opens the door to a fix. “Someone kept breaking the build” closes it.
Give everyone a chance to contribute, including quieter members. Writing answers privately first, then discussing them, often surfaces points that would otherwise go unsaid.
Turn findings into actions
A list of observations is not enough. For each important finding, write one concrete change you will try next time, and who or what will carry it. For example, if estimates were consistently too optimistic, the action might be to add a buffer or to track actual time on tasks. If testing happened too late, the action could be to schedule the first outside playtest earlier.
Limit yourself to a few actions. Three changes that happen beat twenty that are forgotten.
A simple format to write up
A short document is more likely to be read again. Many people use a layout like this:
- Summary: what the project was and how it ended, in a paragraph.
- What went well: a handful of items with causes.
- What did not: a handful of items with causes.
- Lessons and actions: the changes you will try.
- Open questions: things you still do not understand.
Date it, store it with the project, and reread it when you begin your next one. Some developers choose to publish their reviews, which can help others, but publishing is optional. If you do, stick to what you know firsthand and avoid presenting your single experience as a rule that applies to everyone.