Pre-Mortem

The Pre-Mortem Is the Cheapest Insurance in Product Development

Every failed product launch has a moment -- usually about two weeks after ship -- when someone on the team says, "I knew that was going to be a problem." The pre-mortem exists to surface that knowledge before it becomes an expensive lesson.

Developed by psychologist Gary Klein, the pre-mortem inverts the traditional post-mortem. Instead of analyzing what went wrong after failure, it asks: imagine the project has already failed -- what caused it? Research published in the Harvard Business Review found that prospective hindsight -- imagining an event has already occurred -- increases the ability to identify reasons for future outcomes by 30%.

The Problem

Product teams are systematically biased toward optimism. The planning fallacy, documented by Kahneman and Tversky, shows that people underestimate completion time by 25-50% on average, even when they have experience with similar projects. This optimism extends beyond timelines to risk assessment: teams underestimate technical complexity, market resistance, and organizational friction.

The social dynamics of product teams amplify the problem. Raising concerns in a planning meeting feels like pessimism. Nobody wants to be the person who kills momentum. So risks go unspoken, assumptions go untested, and the team marches toward a failure that multiple people saw coming.

According to the Standish Group's CHAOS Report, only 31% of software projects are considered successful in terms of being on time, on budget, and meeting requirements. The majority overrun or get cancelled.

How This Prompt Works

The Pre-Mortem prompt creates a structured risk identification exercise that removes the social stigma of raising concerns. It begins with a vivid scenario: your project has launched and failed spectacularly. Then it systematically explores failure categories.

The prompt walks through technical risks, market risks, organizational risks, and timing risks. For each category, it generates specific failure scenarios calibrated to your project context. Then it asks you to rate each scenario on likelihood and impact, producing a prioritized risk register.

Finally, it generates mitigation strategies for the top risks and identifies early warning indicators you can monitor during execution.

When to Use It

• Before kickoff of any project that will take more than two weeks
• Before a major launch when the stakes are high and reversal is costly
• After scope changes that introduce new risks the team has not processed
• When the team feels overconfident and you need a structured way to stress-test assumptions

Common Pitfalls

Going through the motions. A pre-mortem done as a checkbox exercise produces nothing useful. The team needs to genuinely engage with the failure scenarios.

Focusing only on technical risks. The biggest product failures are rarely technical. Market fit, organizational alignment, competitive timing, and regulatory issues are more common killers.

Not acting on the output. A risk register that sits in a document nobody reads is worse than no risk register. Assign owners and monitoring cadence to the top three risks.

Sources

• Performing a Project Pre-Mortem - Harvard Business Review
• CHAOS Report - Standish Group
• The Planning Fallacy - Daniel Kahneman