Pre-Mortem Template for User Research

After the project plan is defined but before execution begins. The team needs enough context to generate specific failure modes (which requires knowing the plan) but enough time to act on the mitigations (which requires running before building starts). For a 10-week project, running the pre-mortem in week 1 is ideal.

A risk register is a living document maintained by the PM throughout the project. A pre-mortem is a one-time team exercise that populates the initial risk register. The pre-mortem is better at surfacing risks because the "imagine it has already failed" framing activates different cognitive patterns than "list what could go wrong." Use the pre-mortem to generate the initial list, then maintain it as a risk register.

Push harder with the prompts. Ask: "What if your biggest technical assumption is wrong?" and "What if the competitor launches the same feature next month?" If the team genuinely cannot imagine failure, that is itself a risk signal. Overconfidence at the start of a project is strongly correlated with scope creep and missed deadlines.

Include stakeholders who will be affected by the project outcome. They often see failure modes the delivery team misses (e.g., "customers will expect X, but we are building Y"). However, if [stakeholder](/glossary/stakeholder-management) presence will cause the team to self-censor ("I cannot say the VP's pet feature might fail"), run the pre-mortem without stakeholders and share the sanitized results afterward.

A healthy pre-mortem with 6-8 participants produces 30-50 failure modes. After clustering, these typically reduce to 10-15 distinct risks. The team then prioritizes and mitigates the top 5. Do not try to mitigate all 15. Focus on the highest-likelihood, highest-impact failures. The rest go into a "watch list" that the PM reviews at mid-project and pre-launch checkpoints. ---