Pre-Mortem with Tigers, Paper Tigers, and Elephants
Surface launch risks before failure makes them expensive
- Difficulty
- Easy
- Time to result
- ~days to results
- Steps
- 6
- Confidence
- 99%
A pre-mortem reverses the usual post-mortem by asking a team to assume an important initiative has already failed and work backward to explain why. The counterfactual failure prompt gives people permission to voice concerns that ordinary optimistic planning suppresses. Shreyas Doshi adds three memorable risk labels: a tiger is a threat that could kill the project, a paper tiger looks threatening but is not truly concerning, and an elephant is an uncomfortable reality nobody is discussing. Participants write independently, share their risks, and vote for the scariest tiger raised by someone else. The leader then prioritizes the output and converts selected risks into a mitigation plan. The result is earlier risk discovery, a lighter emotional burden for the team, and durable vocabulary for raising concerns in later meetings.
Origin
Doshi learned the pre-mortem concept from a Harvard Business Review article by Gary Klein, then developed and repeatedly used this version at Stripe. He added the tiger, paper tiger, and elephant vocabulary, a structured silent-writing phase, peer voting, and a post-session action plan.
Core principles
- 01Imagining failure makes hidden risks easier to discuss
- 02Psychological safety improves the quality of risk discovery
- 03Shared vocabulary lets teams keep raising concerns after the meeting
- 04Not every identified risk deserves mitigation
- 05The leader owns prioritization and follow-through
How to run it
- 1
Bring every relevant function into the room
Include people from every function involved in the initiative. For a large launch, split product and engineering risks from go-to-market risks; for a smaller launch, keep everyone in one session.
Pro tip Include every engineer for the technical pre-mortem because risks often sit with individual contributors.
Watch out A leadership-only session can miss the concerns already visible to the people doing the work.
- 2
Declare the hypothetical failure
Open with a specific counterfactual: imagine the project or launch has failed miserably six months from now. Ask the team to work backward and explain what contributed to that outcome.
Pro tip Use definite language about failure rather than the softer question, 'What could go wrong?'
Watch out Do not weaken the prompt with reassurance before people have surfaced their concerns.
- 3
Write risks in private
Alternate discussion with five to ten minutes of quiet writing. Have each participant privately record tigers, paper tigers, and elephants before seeing other people's answers.
Pro tip Use a shared document configured so entries remain hidden during the writing period.
Watch out Starting with open discussion can anchor the group on the first senior person's concerns.
- 4
Share and clarify the risks
Go around the room and let participants explain their entries. Keep the discussion focused on understanding the threats, not immediately defending the current plan.
Pro tip Treat elephants as valuable signals even when they are not fatal threats.
Watch out Do not let optimism turn the session into an argument against every concern.
- 5
Vote across perspectives
Ask each participant to select the scariest tiger mentioned by someone else. This creates a simple cross-team signal about which threats deserve the leader's closest attention.
Pro tip Prevent self-voting so participants must seriously evaluate another person's risk.
Watch out Voting identifies concern, not certainty; it does not replace judgment.
- 6
Turn selected risks into action
Prioritize the output rather than trying to solve everything. Create a post-pre-mortem plan, assign mitigation work, share it with the team, and hold yourself accountable for progress.
Pro tip Explicitly record risks you accept as well as risks you mitigate.
Watch out A cathartic meeting without follow-through does not reduce project risk.
In the wild
Doshi describes the common pattern where a company launches a change, receives massive backlash, performs damage control, and may reverse the decision. He argues that team members often already saw the issue but lacked the safety and vocabulary to raise it objectively. A pre-mortem would surface that elephant or tiger while the team still had time to choose whether and how to address it.
→ The team can mitigate, redesign, or consciously accept the risk before public reaction forces an expensive response.
Before releasing a billing migration, engineering lists data integrity tigers, support identifies a staffing elephant, and sales marks a feared customer objection as a paper tiger. The group votes the migration rollback gap as the most serious tiger, so the leader funds a rollback rehearsal and publishes an owner for support readiness.
→ A small planning investment focuses mitigation on the risks most likely to create an ugly post-mortem.
Common mistakes
Asking only what could go wrong
A generic risk question does not create the same psychological permission. The method depends on treating failure as an imagined fact and then reasoning backward.
Inviting only senior stakeholders
People closest to the work may already see the failure modes. Excluding them removes exactly the information the session is designed to surface.
Trying to solve every concern
The output is a risk inventory, not an obligation to eliminate uncertainty. The leader must prioritize, accept some risks, and act on the few that matter most.
Is it for you?
Best for
Cross-functional teams preparing an important product launch, operational change, or high-stakes initiative.
Not ideal for
Routine, reversible work where the coordination cost of a formal risk session exceeds the downside of failure.
From the episode
Shreyas Doshi on pre-mortems, the LNO framework, the three levels of product work, why most execution problems are strategy problems, and ROI vs. opportunity cost thinking