The Pre-Mortem Process
Predict failure before it happens by imagining the project has already failed
The Pre-Mortem Process is conducted before a project launches, not after. The team imagines the project has already failed and works backward to identify what went wrong. This simple inversion is profoundly effective because it gives people psychological permission to voice concerns that they would suppress in a normal planning meeting. In a standard planning session, raising concerns feels like being negative or unsupportive. In a pre-mortem, raising concerns is the explicit purpose of the exercise. Shreyas Doshi used this process extensively at Stripe, where it fundamentally changed the culture around risk identification. Teams became more comfortable surfacing problems early, which prevented costly late-stage failures. The process works by gathering the team before the project begins, having each person independently write down potential failure modes, sharing and discussing all failure modes as a group, prioritizing the most likely and most damaging failures, and creating specific mitigation plans for the top risks.
- In a pre-mortem, raising concerns is the purpose, not a distraction
- The most expensive failures are usually predictable by someone on the team
- People suppress concerns in planning meetings because voicing them feels negative
- Written independent responses prevent groupthink and anchoring bias
- Gather the team and frame the exerciseBefore the project begins, assemble all relevant stakeholders including engineering, design, operations, and product. Frame the exercise clearly: Imagine it is six months from now and this project has completely failed. What went wrong? Emphasize that the goal is to identify as many potential failure modes as possible and that there are no wrong answers.Pro tipInclude people from adjacent teams who interact with the project. They often see risks that the core team is blind to.
- Collect failure modes independently before group discussionGive each person five to ten minutes to independently write down every way the project could fail. This independent writing phase is critical because it prevents the first speaker from anchoring the entire group's thinking. Once collected, share all failure modes with the group and discuss. Cluster similar ones and add new ones that emerge from discussion.Pro tipUse anonymous submission if the team has significant power dynamics. Junior members are more likely to share genuine concerns when not identified.WarningDo not allow the project leader to speak first during the discussion phase. Their opinion will anchor the group.
- Prioritize and create mitigation plans for the top risksRank all identified failure modes by probability and severity. Focus mitigation efforts on the top five to seven risks, distinguishing between risks you can actively mitigate and risks you must accept but monitor. Create a specific mitigation plan for each top risk with a clear owner and timeline. Revisit the pre-mortem findings at key project milestones.Pro tipSchedule pre-mortem review checkpoints at each major project milestone. New risks emerge as projects evolve.
When Shreyas Doshi introduced pre-mortem meetings at Stripe, teams initially resisted the exercise as unnecessary overhead. However, after the first few pre-mortems successfully predicted and prevented costly late-stage failures, the practice became embedded in Stripe's project culture. Teams began requesting pre-mortems for any significant initiative.
Shreyas Doshi refined this process during his tenure at Stripe, where he joined as the fourth product manager and later became Stripe's first PM manager. He observed that the most expensive project failures were always predictable in retrospect because someone on the team had seen the problem coming but did not feel empowered to raise it. The pre-mortem created a structured container where voicing concerns was not just acceptable but required.