skip to content

Search

The Art of the Pre-Mortem

Less than one minute read Updated:

Imagining failure before launch is the most underused tool in product management, and it prevents the expensive surprises that post-mortems document.

# product-management
# strategy
# leadership
# risk
# planning
Not in series

By the time you write a post-mortem, you already paid for the lesson in cash, reputation, and calendar time.

Every team I have worked with calls itself careful. Ask the same team to name the failure mode of the thing they shipped last quarter, and the room goes quiet.

I own the system of record under InMobi’s demand-side platform and ad exchange, processing 200 million-plus devices’ worth of ad events a day. Nothing in that pipeline gets a second chance at a clean number once the month closes. This post is the ritual I run before a launch to buy that second chance while it is still free.

So that’s today’s post.

Today’s Post

The meeting that runs before the launch, while the failure is still imaginary and still preventable, in six sections.

  • Why a pre-mortem is triage and a post-mortem is an autopsy
  • The incentive problem forward planning never fixes
  • Why a narrated disaster beats a risk register
  • The thirty-minute structure, run with discipline
  • The quiet risks that get expensive
  • What has to happen after the meeting, or none of it counts

1. Post-mortems are autopsies. Pre-mortems are triage.

A post-mortem asks what went wrong after the damage is done. Customers already churned. The team already burned nights fixing what should not have shipped.

A pre-mortem asks a different question. Assume you failed. Assume it was loud and expensive. Now explain how you got there.

That is not pessimism. It is timing. You move the most valuable conversation to the one point where the fix is still cheap.

The same lesson, two prices A pre-mortem spends 30 minutes before launch. A post-mortem spends days, after the damage is already billed. Grey monospace text is the time each stage actually costs. PRE-MORTEM, BEFORE LAUNCH POST-MORTEM, AFTER LAUNCH Name the failure the room writes causes alone 30 minutes, one meeting Fix it in the plan before a line of it ships a scope cut, a monitor, free Launch clean nobody outside the room ever meets the failure Ship the failure customers meet it first day zero, in production Diagnose under fire nights burned reconstructing what the room could have named multi-day, on-call rotation Pay in cash and trust reputation, churn, and calendar time, all spent cheap, while the failure is still imaginary expensive, because the failure is now real
The same lesson, learned at two different prices. Only the timing changes what it costs. PNG ↓

At InMobi, the close on that 200-million-device pipeline runs every month whether anyone asks for it or not. A pre-mortem borrows that same trick on purpose, on a schedule you set, before the number exists yet to argue about.

2. Forward planning rewards optimism, and punishes doubt

Normal planning meetings carry a hidden bias toward momentum. The roadmap slide is green. Raising a real concern can sound like a lack of conviction, so people smooth the edges and save the doubt for a private chat that never reaches the room that needs it.

A pre-mortem flips the incentive. The most valuable contribution in the meeting becomes the darkest scenario, not the most confident one.

I saw this decision play out directly on Prism, the AI co-pilot I built at Pixis. One-click campaign changes were the whole magic of the product, and also the whole risk. The team’s answer was structural, not a warning nobody acted on: the AI proposes and explains, the human commits. That line exists in the product today because someone was allowed to say the loud version of “what if it’s wrong” out loud, before a customer found out first.

3. A narrated disaster beats a risk register

Human brains explain outcomes better than they generate probabilities. Ask a team for risks in the abstract and you get a shallow list: performance, security, bugs. Ask the same team to narrate a specific failure and you get a trigger, a screenshot, a customer quote.

That specificity is where prevention lives. A vague risk is a category. A storied failure is a causal chain, and a causal chain has a link you can interrupt.

A category versus a chain you can interrupt A risk register produces a line item nobody reads. A pre-mortem produces a trigger, an owner, and a mitigation. Grey monospace text is the one line each format actually leaves behind. RISK REGISTER NARRATED FAILURE Performance risk: medium a category, checked once and filed no trigger, no owner, no next step A checkbox in a spreadsheet that stops meaning anything the moment the meeting ends. outcome: nobody owns the load test Trigger: a caching assumption fails under a named load Owner: the engineer who flagged the cache Mitigation: a load test before rollout One sentence, but it names the moment it breaks, so there is a link to interrupt. outcome: a load test, owned, before ship creates a checkbox creates an owner
A register says 'performance risk, medium.' A pre-mortem names the trigger, the owner, and the fix. One creates a checkbox, the other an owner. PNG ↓

A register says “performance risk, medium.” A pre-mortem says a caching assumption failed under a named load and nobody owned the load test. One of those sentences creates an owner. The other creates a checkbox.

4. The thirty-minute structure

A pre-mortem needs a tight structure and a leader who protects the frame, not a facilitator certification.

State the launch and the definition of success in plain language everyone agrees on. Announce the premise: it is weeks from now, and the project failed, loudly and expensively. Give the room two minutes to write causes alone, so the loudest voice does not anchor everyone else. Collect themes and cluster duplicates until each one is a sentence a stranger could understand. Mark what is already owned against what is not, because teams routinely discover they were worried about a risk nobody owned. Then pick the smallest set of actions that move the top scenarios: a monitor, a scope cut, a rollback trigger, a slower rollout.

Thirty minutes, five stages, in order A leader protects this frame. Skip a stage and the meeting turns into open debate. Grey monospace text is the discipline that stage enforces. Scroll slowly, this plays once. State the premise it is weeks from now, and the project failed, loudly everyone agrees on success Write causes alone two minutes, silent, no talking yet the loudest voice can't anchor Cluster into themes merge duplicates until a stranger understands each theme, one sentence Mark owned versus unowned the real discovery step nobody owned the load test Pick the smallest actions a monitor, a scope cut, a rollback trigger, a slower rollout assigned to a name before the room empties frame the failure generate and organise, in silence first the judgement call: owned or not
Five stages, in order. Skip one and the meeting turns into open debate instead of a pre-mortem. (animates as you scroll to it) PNG ↓

If you walk out with no action assigned to a name, you ran a performance instead of a pre-mortem.

5. The quiet risks are the expensive ones

Post-mortems tend to document failures everyone half-expected. The scalability cliff, the ambiguous metric, the partner dependency that was “probably fine.” Those risks were visible in advance. They were just expensive to say out loud in a normal planning meeting.

A pre-mortem changes who gets to speak first. The engineer who noticed the brittle integration gets to name it without sounding like they are blocking the launch. That is the same shift behind the reliability work I ran at Pixis: making data freshness a number the team was accountable to, instead of a worry nobody wanted to own out loud, cut availability delays on that platform from four hours to under fifteen minutes for 400-plus enterprise customers.

Speed without a pre-mortem is often risk compression. You are not moving faster. You are moving the same risk closer to the customer.

6. A pre-mortem that changes nothing is worse than no ritual

If the team names the same three disasters every launch and leadership always picks speed anyway, people stop bringing their best scenarios. They perform the exercise instead of running it.

The fix is not a longer meeting. The fix is a written decision. My own rule from how I run specs applies here without edits: unwritten means undecided. If a top scenario has no owner, assign one before the room empties. If the mitigation is too expensive, say so and record the accepted risk. If the risk is unacceptable, change the scope or change the date.

A pre-mortem that produces no decision log is a moral license to launch, not a safeguard. Treat it as a fork in the road, not a ritual you check off.

Takeaways

Learn the lesson while it is still imaginary Six sections on running a pre-mortem that actually changes what ships Hoshank Ailani · hoshank.vercel.app 1. Triage, not autopsy POST-MORTEM PRE-MORTEM asks after the damage is done assumes you failed, in advance customers already churned nobody outside the room knows yet documents the fix is late the fix is still cheap the same lesson, at two different prices InMobi DSP and exchange: 200M+ devices' worth of ad events a day, no second chance 2. The incentive flip Roadmap slides reward momentum Doubt gets smoothed into a private chat A pre-mortem rewards the darkest scenario The loud "what if it's wrong" gets heard first Prism at Pixis: AI proposes, human commits, a structural answer, not a warning nobody acted on 3. Narrative, not a register × "Performance risk: medium" is a category ✓ A caching assumption fails under a named load and nobody owned the load test a category creates a checkbox a causal chain creates a link you can interrupt 4. Thirty minutes, five stages 1. State the premise 2. Write causes alone 3. Cluster into themes 4. Mark owned versus unowned 5. Pick the smallest actions skip a stage and it turns into open debate 5. The quiet risks get expensive Half-expected risks stay unsaid in normal meetings A pre-mortem changes who speaks first Speed without one is often risk compression Pixis reliability: data freshness made a number, availability delay cut 4h → under 15min, 400+ enterprise customers 6. The decision log makes it count Assign an owner before the room empties Too expensive: record the accepted risk Unacceptable: change the scope or the date Unwritten means undecided no decision log is a moral licence to launch, not a safeguard The lesson is the same either way, only the price changes with when you learn it. Steal thirty minutes before your next launch and ask the room what the headline would say if it failed. Full post: hoshank.vercel.app/posts/the-art-of-the-pre-mortem Takeaways
The whole post on one card. Save it, share it, argue with it. PNG ↓

Six panels, one per section. The thesis on the callout: the lesson is the same either way, only the price changes with when you learn it.

Final Words

Most teams will keep treating the post-mortem as proof of maturity, and keep documenting the same class of failure quarter after quarter. Pick your next launch, steal thirty minutes before it ships, and ask the room what the headline would say if it failed loudly. Then write down who owns the answer.

Reply and tell me what your team named. I am collecting the scenarios that actually got an owner.

Cheers, Hoshank