Dean Peters PREMORTEM
What Is It
Frame and explore your problem by imagining a future scenario in which the proposed activity fails to achieve its objective.
Why Use It
Clarify what success looks like. Uncover hidden assumptions about activities, outcomes, success, and failure. Mitigate risks by identifying potential causes of failure. Give your team insight into priorities and success criteria
When to Use It
When the definition of success is being determined or assessed.
How to Do It
- Assemble the project team, and give each member a copy of the Premortem Canvas. Invite everyone to imagine it is two years in the future. Your current project, activity, or initiative has utterly failed. Spend a few minutes writing down answers to the questions in the canvas, then discuss answers with the larger group. Describe the failure. Using vivid detail, describe what it would look like if your project failed completely. Focus on outcomes and attributes, not behaviors or causes. Don’t hold back or self-edit. Use extreme language and explore the worst-case scenarios. It is important for the facilitator to adopt a curious, open posture and create a “high-trust” environment where each participant is free to share and contribute.
- List the causes. Assemble a list of potential causes for the failure. Consider a wide range, including action, inaction, assumptions, priorities, distractions, people, organizations, and processes. Include anything that might be a contributing factor.
- Update goals and risks. Compare the failure description with the team’s current definition of success (goals, objectives, etc.) and the team’s current action plans. Discuss whether accomplishing the team’s goals and activities would prevent the future failure scenarios. Adjust goal statements as needed.
- Examine the list of causes and identify the most likely failure drivers. Discuss which causes are avoidable and whether the team is taking appropriate steps to mitigate or prevent them from occurring.
Key Concepts
Prospective Hindsight — The cognitive technique of imagining an outcome has already occurred and reasoning backward to explain it. Research shows this framing increases the team's ability to identify reasons for a future outcome by roughly 30% versus standard forecasting.
Psychological Safety — A high-trust environment where participants can voice doubts and worst-case scenarios without fear of being seen as disloyal. Without it, the premortem collapses into polite, low-signal answers that miss the real risks.
Failure Imagination — Deliberately describing vivid, extreme failure outcomes rather than hedged 'risks.' The emotional concreteness bypasses optimism bias and groupthink that normally suppress dissent in roadmap and planning sessions.
Outcomes vs. Causes — Separating the description of what failure looks like (outcomes, attributes) from why it happened (causes, drivers). Conflating the two too early narrows the search and lets the team skip past uncomfortable root causes.
Failure Drivers — The subset of identified causes that are both likely and impactful, distinguished from the long list of all possible contributors. Prioritizing these turns the exercise into actionable mitigations rather than an anxiety dump.
Assumption Surfacing — Exposing the hidden beliefs about market, users, dependencies, and capacity that underpin the plan. These map directly to the riskiest-assumption tests in discovery and Lean Startup validation.
PM Applications
- Run a premortem at epic kickoff or quarterly planning to pressure-test OKRs and convert vague success language into measurable, defensible key results.
- Use it before finalizing a PRD to populate the risks, assumptions, and non-goals sections with concrete failure scenarios rather than boilerplate.
- Facilitate a premortem ahead of a major launch or migration to build a prioritized risk register and assign mitigation owners before code freeze.
- Apply it in discovery to identify the riskiest assumptions, then design discovery-sprint experiments to validate or kill them before committing build capacity.
- Convert identified failure drivers into backlog items, dependency tickets, and spikes during backlog refinement so mitigation work is actually scheduled.
- Use the failure narrative as the spine of a stakeholder or executive briefing to align conflicting parties on shared risks and secure resourcing for mitigations.
Benefits
- Often produces profound insights & unexpected moments of honesty.
Common Pitfalls
- Treating it as a generic risk-brainstorm instead of imagining a concrete completed failure — the prospective-hindsight effect disappears and you get the same shallow risks every team already knows.
- Including the sponsor or a dominant senior voice without managing the room, which suppresses honest doubt and produces a sanitized list that confirms the existing plan.
- Stopping at the cathartic failure description and never completing steps 3 and 4 — the team feels relieved but no goals get adjusted and no mitigations get owned or scheduled.
- Jumping straight to causes before vividly describing outcomes, which anchors the group on familiar, comfortable explanations and skips the uncomfortable systemic drivers.
- Generating a huge undifferentiated cause list without ranking by likelihood and impact, leaving the team overwhelmed and unable to act on the few drivers that actually matter.
- Running it too late, after scope and timelines are locked, so surfaced risks can't change the plan and the exercise becomes documentation theater rather than decision input.
Combine With
Problem Framing Mission & Vision Canvas Stakeholder tools ( Stakeholder Map & Matrix , Stakeholder Identification Canvas ) to go deeper into motives (who thought we’d fail? Etc)
Assets
- PDF: Download
- Markdown Template: template.md
Metadata
| Field | Value |
|---|---|
| ITK Phase | DEFINE |
| Difficulty | Intermediate |
| Group Size | 6+ people |
| Time Required | 60+ minutes |
| Source | itk.mitre.org |