Pre-Mortem Before a Campaign or Product Rollout: A Founder’s Checklist

When a founder of a 40-person SaaS team told me they’d launched three features in a row that no one used, I realized they were skipping the one step that could have saved them: a pre-mortem.

What is a pre-mortem and why run it before a campaign or rollout?

A pre-mortem flips traditional risk planning. Instead of asking what could go wrong, you assume failure has already happened and ask why. This reduces optimism bias and surfaces risks teams often ignore — like unclear ownership, outdated assumptions, or silent dependencies.

Run it late enough in planning to have real details, but early enough to change course — ideally 3–5 days before launch.

How to run a pre-mortem: step-by-step

1. Gather the core team: founder, campaign lead, product owner, and any ops or support leads who will execute.
2. State the launch goal clearly: "We are launching X to achieve Y by Z date."
3. Imagine it’s 30 days after launch and the campaign or rollout has failed — no uptake, missed targets, or broken trust.
4. Each person writes down 3–5 specific reasons why it failed (e.g., "sales team didn’t know the new messaging," "integration broke under load," "customers didn’t see the email").
5. Share and cluster risks into themes: people (skills, bandwidth), process (handoffs, approvals), tooling (tech limits, integrations), dependencies (external teams, vendors).
6. For each risk, assign an owner and a prevention or mitigation action.
7. Update your plan with these actions — this becomes your risk-adjusted launch plan.

Tool tip (AiAdvisoryBoard.me): The best pre-mortems don’t just list risks — they surface the gap between what the team thinks will happen and what could actually derail the effort. Use the Plan → Fact → Gap lens to stress-test assumptions before launch. See how the 7-day diagnostic helps founders surface these gaps early.

What to include in your pre-mortem notes

• One clear failure scenario per bullet (avoid vagueness like "poor execution").
• Specific, observable causes (e.g., "support team not trained on new FAQ" vs "training gap").
• Risks tied to launch timeline (e.g., "dependency on legal review slips past cutoff date").
• At least one risk per functional area involved — don’t let silos hide.

Good vs bad pre-mortem outputs

Good:

• "Email campaign fails because marketing didn’t coordinate with sales on lead handoff timing."
• "New feature rollout stalls because the admin tool lacks bulk upload, forcing manual entry for 200+ records."

Bad:

• "Marketing and sales aren’t aligned."
• "The tool isn’t ready."

Micro-case (what changes after 7–14 days)

A founder running a 60-person logistics software team ran a pre-mortem before launching a new client portal. The team assumed adoption would be smooth — until the exercise revealed that client success managers hadn’t been briefed on the new login flow, and support hadn’t updated their scripts. Two days later, they paused the launch, trained the team, and updated the help center. When they launched, adoption hit 70% in week one — vs the 30% they’d seen on prior releases.

Note on this case: This example is illustrative — based on typical patterns we observe with companies of 30–500 employees, not a single named client. Specific numbers are rounded approximations of common ranges, not guarantees.

FAQ

How long should a pre-mortem take? For a team of 5–10 people, 45–60 minutes is enough to surface meaningful risks without overburdening the schedule.

Who should run it? The founder or the person accountable for the launch outcome — usually the product owner, campaign lead, or COO.

Can we do this asynchronously? Yes — have individuals write their failure reasons in a shared doc, then convene to cluster and assign owners. Synchronous discussion improves buy-in.

What if we find too many risks to fix? Prioritize by impact and likelihood. Address the top 20–30% that could derail the launch; track the rest as post-launch watch items.

Is this different from a retrospective? Yes. A retrospective looks backward at what happened; a pre-mortem looks forward by assuming failure has already occurred.

Conclusion

A pre-mortem isn’t about predicting the future — it’s about stress-testing your plan before you bet on it. By imagining failure, you make your success more likely.

What to do tomorrow: Block 60 minutes with your launch team to run a pre-mortem on your next campaign or product rollout.

If you want to surface the Plan → Fact → Gap automatically — every day, across the company — see how the 7-day diagnostic works.