Why does the pre-mortem work?
The premise of the pre-mortem seems almost too good to be true. Can simply asking why a project will fail really reduce the likelihood of its death?
I started using them this year after seeing Shreyas Doshi's advocacy, and for my team the answer has been a resounding yes. The engineers now start asking me weeks in advance when the pre-mortem will be like it's a newly-announced Taylor Swift album. Well, not quite, but it is that rare meeting that is (extremely) valuable yet fun.
The basic idea of the pre-mortem is: Before a project starts, everyone involved writes down what will cause it to fail then discusses how to prevent.
When I run a pre-mortem I use Doshi’s animal threat spectrum and ask everyone to think about potential failure in terms of:
tigers = real threat
paper tigers = overblown concerns
elephants = threats hiding in the room
We discuss and leave the meeting with an action plan for the major dangers.
So why does it work? The pre-mortem does three valuable things:
1. Assassinates cognitive biases
2. Spreads responsibility for risks
3. Opens up everyone's creativity
Not bad for a 1 hour meeting!
Cognitive biases
While we're planning out the details of our brilliant new feature, our brain is busy blinding us to the reasons it could fail. The magic act of flipping the question to "why will we fail?" re-orders the information we already have and reveals the lurking problems.
Every time I am freshly astonished at how I suddenly see significant threats that I had previously overlooked.
This works at the team level too. By changing the focus to risk, the concerns of legal, operations, or engineering take center stage instead of being crushed beneath the weight of the bias towards action.
Alignment on risks and mitigation
After doing a few pre-mortems with the same team, I've been surprised how different the elephants and tigers are for each project even with the same product. Sometimes the biggest threat is whether the page will load fast enough for users, another time the timing of the testing schedule, and on one recent one, geopolitical turmoil!
By involving every relevant team, you get a much richer view of the threats. Without the pre-mortem these concerns tend to stay in a silo. The PM may be vaguely aware, but the tech lead is probably not thinking about the same risks as marketing and vice versa.
Now everyone has a full view of the risks and the relative importance. This is why the elephant prompt is my favorite. It always teases out the risks that would have gone otherwise unacknowledged.
Spreading awareness of the major project risks enables the whole team to collaboratively mitigate. This can spark new creative solutions as well as make later decisions easier since everyone already understands the relative weight of threats.
Creativity
Fun is the real secret to the pre-mortem. The animal lexicon loosens up the discussion and brings the group into a more honest, free-flowing atmosphere which actually makes us better at analyzing problems.
Metaphors are fun and the animal categorization process gives everyone the same toolset for ranking, evaluating, and solving.
Combining the lexicon with a silent writing period also elevates the voices of quieter team members, who in my experience often identify threats others miss.
Areas for exploration
As I've become somewhat of a pre-mortem proselytizer I've started to wonder how else I can harness these structural tricks.
What other framing approaches can invert biases so effectively?
Can we improve our product planning process by doing a pre-mortem on that?
Does the failure question work if I ask only myself or does it require group visibility?
And what other processes can be improved with a fun lexicon?
There's just something so satisfying about announcing to the team "we can downgrade this elephant to a paper tiger now."