How to Run a Project Postmortem

A postmortem—honestly examining a finished project's successes and failures to extract lessons—is one of the most valuable things you can do to improve as a developer, turning each project into learning for the next. Running one well means being honest about what went wrong, identifying actionable lessons, and actually applying them, because a postmortem only matters if it changes what you do.

Honestly examine what went well and what went wrong

A postmortem's value comes from honesty: examining a finished project to identify what went well (so you can repeat it) and what went wrong (so you can avoid it), with genuine honesty about both. The hard part is honesty about failures—it's uncomfortable to confront what went wrong, the mistakes made, the things that failed, and there's a temptation to gloss over them or rationalize, but the failures are where much of the learning lies, so honest examination of what went wrong is essential to a valuable postmortem. Equally, identifying what went well matters, so you can recognize and repeat your successes. A postmortem that honestly examines both the successes and the failures of a project—what worked and should be repeated, what didn't and should be avoided—extracts the full learning from the project, while one that avoids honest confrontation of the failures misses much of the value. Being honest, especially about failures, in examining what went well and what went wrong is the foundation of a postmortem that genuinely captures the lessons a project offers, because the honest examination is what reveals the lessons, particularly the uncomfortable ones about failures that are often the most valuable.

Identifying actionable lessons and applying them is what makes a postmortem valuable rather than just reflective. Honest examination is only useful if it produces actionable lessons that you apply, which is what turns reflection into improvement. Identifying actionable lessons means extracting from the examination specific, actionable takeaways—not just 'this went wrong' but 'here's what to do differently next time'—so the postmortem produces concrete lessons you can act on rather than vague reflections. The lessons should be actionable: specific changes to your process, your approach, your decisions that will improve future projects, derived from what the examination revealed about what worked and what didn't. Applying them is the crucial final step that makes the whole postmortem worthwhile: a postmortem that identifies lessons but doesn't change what you do next is wasted, while one whose lessons you actually apply—changing how you work on future projects based on what you learned—turns the project's experience into genuine improvement. This is the point of a postmortem: not just to reflect, but to improve, which only happens if the lessons are applied. Combining honest examination of what went well and what went wrong (especially honesty about failures) with identifying actionable lessons (specific takeaways for improvement) and applying them (changing what you do next) is what makes a postmortem the valuable improvement tool it is—turning each finished project into honest learning that you act on to improve future work. A postmortem done this way—honest, actionable, and applied—is one of the best ways to grow as a developer, because it systematically extracts and applies the lessons each project offers, making you better with each project rather than repeating the same mistakes. Running a postmortem on each finished project, with honesty about successes and failures, actionable lessons, and actual application, is what compounds your improvement over time, turning your accumulated project experience into the lessons that make you a better developer. The postmortem only matters if it changes what you do, so the honesty, the actionable lessons, and the application are what make it worthwhile.

Measure before you optimise

Intuition about what's slow, what's confusing, or what's driving players away is usually wrong, and acting on it wastes effort on problems that don't matter while the real ones persist. The developers who improve their games efficiently are the ones who measure first — profiling performance, watching real sessions, capturing actual errors — and let the data set their priorities.

It's slower than trusting your gut, but it's the only approach that reliably improves the game instead of just changing it. Find the biggest real problem, fix that, and measure again, rather than optimising guesses.

The first impression is most of the battle

More players leave in the opening minutes than at any other point, which makes the first few minutes the highest-leverage stretch of the whole game — and also the part the developer can least see clearly, having played it a thousand times. What feels obvious to you is often confusing to someone seeing it fresh, and that gap quietly costs you players before they ever reach the good part.

Get the player into the interesting part fast, let them feel competent quickly, and watch first-time players go through the opening without helping them. Nobody quits a game they're enjoying, so making the early minutes land is most of the battle for retention.

Small and finished beats big and abandoned

A folder of impressive unfinished projects teaches far less than a single small finished one, because finishing is where the hardest and most valuable lessons live — the unglamorous final stretch of bug-fixing, polishing, and shipping that ambitious abandoned projects never reach. Each completed game, however modest, builds the finishing muscle and the confidence that make the next one achievable.

So resist the pull of the dream project until you've shipped a few small ones. Scope to what you can actually complete, finish it, and let the experience of shipping make your bigger ambitions realistic.

Trust behaviour over opinions

People are unreliable narrators of their own experience — they're polite, they rationalise, they suggest fixes that miss the real problem. What they do tells the truth that what they say obscures: where they hesitate, where they get stuck, what they ignore, where they quit. The most valuable feedback is usually the behaviour you observe, not the opinion you're offered.

This is why watching beats asking, and why real data about what players actually do beats any amount of speculation. When several people stumble at the same spot, that's a problem worth fixing, regardless of whether any of them mentioned it.

Ship it, then learn from it

No amount of internal deliberation substitutes for the information you get the moment real players touch your game. The assumptions that felt certain turn out wrong, the feature you doubted becomes the favourite, and the problem you never imagined is the one everyone hits. That feedback only exists on the other side of shipping.

So bias toward getting something real in front of real people sooner rather than later. A rough thing that's out in the world teaches you more in a week than another month of private refinement, and every release makes the next decision better informed.

A postmortem honestly examines what went well and what went wrong on a finished project, identifies actionable lessons, and applies them. Be honest especially about failures—a postmortem only matters if it changes what you do next.