Pre-Mortem Exercise AI Prompts for PMs

Most product launches fail not because of what you did not know, but because of what you did not let yourself see. The planning process is optimistic by design. You identify risks and then convince yourself they will not materialize. The result is project teams that are surprised by problems they should have anticipated.

The pre-mortem is a technique designed to overcome this optimism bias. Instead of asking “what could go right?” you ask “what went wrong?” You imagine the project has failed catastrophically, and then you work backward to identify what must have caused that failure. The technique is powerful. It is also deeply uncomfortable — it asks you to publicly speculate about failure before you have any evidence of it.

AI Unpacker provides prompts designed to help product managers run effective pre-mortems that surface real risks, generate actionable mitigation strategies, and create accountability for addressing identified problems.

TL;DR

• Pre-mortems are more effective than traditional risk identification because they overcome optimism bias.
• The technique requires psychological safety — the team must feel comfortable imagining failure.
• A good pre-mortem generates specific risks, not generic concerns.
• Every identified risk should have an owner and a mitigation plan.
• Pre-mortems are most effective early in the project, but should be revisited as new information emerges.
• Documentation of pre-mortem findings creates accountability for follow-through.

Introduction

Product managers are paid to be optimistic. They champion projects, defend timelines, and sell visions. This optimism is valuable — it motivates teams andaligns stakeholders. But it also blinds PMs to the risks that optimism systematically underweights.

Traditional risk management asks teams to identify what could go wrong. It is a useful exercise, but it operates within the frame of “this project will succeed, but here are some concerns.” The pre-mortem inverts this frame. It assumes the project has already failed. Now tell me why.

The power of the pre-mortem is that it frees people from defending the project plan. The plan is already dead. Now you are diagnosing what killed it. This inversion surfaces risks that polite optimism would suppress.

1. Pre-Mortem Facilitation Framework

Running a pre-mortem requires structure. Without it, teams either spiral into unproductive doom-spiraling or fail to surface the real risks. The framework guides the conversation through distinct phases, each with a specific purpose.

Prompt for Pre-Mortem Session Design

Design a pre-mortem session for this upcoming project.

Project: Launch of a new AI-powered feature for our B2B SaaS platform
Timeline: 16-week development, 4-week beta, general availability
Team: 8 engineers, 2 designers, 1 PM, 1 content writer, 1 QA engineer
Current status: Design complete, development 30% complete
Executive stakes: Featured in upcoming customer advisory board meeting in 8 weeks

Risk identification history:
- Last project similar in scope was late by 6 weeks
- Team has limited experience with AI/ML features
- Infrastructure needs significant scaling for AI workloads
- Beta customer commitments were made before technical review

Session constraints:
- 90-minute team session
- Team is distributed (async-friendly outputs needed)
- Some team members are skeptical of "ceremony" around planning

Pre-mortem structure I have used before:
- Individual brainstorm (15 min)
- Group share-out (30 min)
- Dot voting for prioritization (10 min)
- Mitigation discussion (35 min)

Tasks:
1. Critique my previous structure:
   - What works and what does not based on this project context?
   - What biases might this structure reinforce?
   - How can I improve the facilitation approach?

2. Design a better session structure:
   - What specific framing should I use for the failure scenario?
   - How to handle skeptics who think pre-mortems are theater?
   - What async components would strengthen the synchronous session?

3. Prepare facilitation materials:
   - What framing statement should I give at the start?
   - What ground rules encourage honest risk identification?
   - How to document findings for easy post-session review?

4. Plan follow-up process:
   - How to convert pre-mortem findings into action items?
   - Who should own which risks?
   - How to revisit pre-mortem findings as project progresses?

Generate a complete pre-mortem facilitation guide with timing, materials, and follow-up process.

2. Risk Identification Prompts

The key to a useful pre-mortem is specific risks, not generic concerns. “The project might be late” is not actionable. “The third-party AI API rate limits will cause timeouts during peak usage, leading to customer escalations” is actionable. AI can help teams move from vague concerns to specific risk hypotheses.

Prompt for Risk Hypothesis Generation

Help me generate specific risk hypotheses for this project.

Project: Mobile app redesign (iOS and Android)
Timeline: 12 months total, first release in 6 months (MVP)
Team: 4 engineers, 1 designer, 1 PM (me), external QA partner
Tech stack: React Native (team has limited experience), Firebase backend

Current known risks:
- React Native learning curve is steeper than estimated
- External QA partner has limited mobile testing experience
- Design system from web does not translate directly to mobile
- Stakeholders have expectations for feature parity with web app

What I am looking for:
- Risks we have not considered yet
- Second and third-order consequences of known risks
- External factors beyond our control that could impact delivery

Tasks:
1. Generate risk hypotheses for each project dimension:
   - Technical risks (architecture, integration, performance)
   - Team risks (capacity, skill gaps, turnover)
   - Stakeholder risks (alignment, scope creep, competing priorities)
   - External risks (market, regulatory, vendor)

2. For each risk, develop:
   - Specific hypothesis (what exactly could go wrong?)
   - Indicators (how would we know this is happening?)
   - Impact (what would be the consequence if this occurs?)

3. Identify which risks are most likely:
   - Based on this project type, what typically goes wrong?
   - Which risks have the highest probability of occurring?

4. Identify which risks have the highest impact:
   - If these risks materialize, what is the realistic outcome?
   - Which could cause complete project failure vs. minor delays?

Generate a prioritized risk hypothesis document with specific, testable risks.

3. Mitigation Planning

Identifying risks is not enough. A pre-mortem that generates a list of concerns without mitigation plans is just anxiety theater. Each significant risk needs a concrete plan for prevention or response.

Prompt for Risk Mitigation Design

Develop mitigation plans for the highest-priority project risks.

Top 5 risks identified in pre-mortem:
1. Third-party AI API latency causes user-facing timeouts during peak usage
2. Key engineer leaves mid-project, creating knowledge gap in React Native
3. Beta customers cannot integrate with new mobile authentication flow
4. Stakeholder scope creep adds 40% more features after development start
5. App store review process rejects app for new privacy disclosure requirements

Context for each risk:
1. AI API risk: We have no control over third-party performance, but we could implement caching and graceful degradation
2. Engineer risk: We have no retention guarantees, and React Native expertise is concentrated in one person
3. Beta customer risk: Three enterprise beta customers require SSO integration that is not in MVP scope
4. Scope creep risk: Executive sponsor has a history of adding features late in projects
5. App store risk: New Apple privacy requirements announced, implementation guidance is unclear

Mitigation planning requirements:
- Each mitigation should have a cost (time, resources, trade-offs)
- Each mitigation should have a trigger condition (when do we implement it?)
- Each mitigation should have an owner (who is responsible?)
- We cannot eliminate all risks; some are acceptable

Tasks:
1. For each risk, develop 2-3 mitigation options:
   - Prevention (reduce probability)
   - Detection (identify early)
   - Response (reduce impact if it occurs)

2. Evaluate trade-offs:
   - What does each mitigation cost?
   - What are the side effects of mitigation?
   - What is the residual risk if we do not fully mitigate?

3. Recommend prioritization:
   - Which mitigations are worth implementing vs. not?
   - What is our risk appetite for this project?

4. Create risk monitoring dashboard:
   - What metrics indicate risk status?
   - How often should we review risk status?

Generate mitigation plans with trade-off analysis and monitoring approach.

4. Pre-Mortem Documentation

A pre-mortem without documentation is a wasted meeting. The insights surface, everyone agrees they are important, and then they are forgotten. Documentation creates accountability and enables future learning.

Prompt for Pre-Mortem Report Creation

Create a pre-mortem report for this project.

Project: Enterprise feature launch (access controls and permissions redesign)
Timeline: 10 months, currently in month 3
Pre-mortem conducted: At project kickoff, before any development started

Risks identified and prioritized:
HIGH PRIORITY:
- Permissions complexity underestimated (15+ permission types, complex inheritance)
- Enterprise customer integration requirements vary significantly (no standard)
- Security review at month 6 could require architectural changes
- Key security engineer available only 50% of time due to other commitments

MEDIUM PRIORITY:
- Stakeholder alignment on edge cases (who owns what decisions)
- Performance requirements unclear (concurrent user loads)
- Localization requirements discovered late (already in development)

LOW PRIORITY:
- UI component library does not cover all permission UI patterns
- Documentation team capacity for end-user guides

Mitigation actions committed:
HIGH PRIORITY:
- [Owner: Tech Lead] Spike on permissions complexity in month 1 (done, confirmed underestimated)
- [Owner: PM] Create integration requirements doc with 3 enterprise customer interviews (in progress)
- [Owner: Security] Schedule security review for month 5, get pre-review guidance
- [Owner: PM + Security] Bi-weekly syncs with security engineer, define 50% availability scope

Report requirements:
1. Executive summary (2-3 sentences on key risks and mitigations)
2. Risk register with status and ownership
3. Mitigation tracker with completion criteria
4. Decision log (what architectural choices were made based on pre-mortem)
5. Signatures/confirmation from team that they reviewed and committed to mitigations

Tasks:
1. Structure the report for the right audiences:
   - What does the executive sponsor need to see?
   - What does the engineering team need to track?
   - What does the PM need to monitor?

2. Define what "resolved" means for each risk:
   - How do we know a risk is no longer a risk?
   - What evidence shows mitigation is working?

3. Create review cadence recommendations:
   - How often should pre-mortem findings be revisited?
   - Who should attend risk review meetings?

Generate a complete pre-mortem report template with guidance for each section.

FAQ

When in the project should a pre-mortem be conducted?

Conduct the first pre-mortem at project kickoff, before any significant development begins. This surfaces risks early when mitigation is cheap. Conduct follow-up pre-mortems at major milestones (design complete, first release, beta launch) to identify new risks as the project context evolves.

How do I get a skeptical team to take pre-mortems seriously?

Start by running a low-investment pre-mortem on a past project and comparing findings to what actually went wrong. The evidence that the technique works is more persuasive than any argument for it. Also, focus on action items, not just identification — teams take pre-mortems seriously when they see that identified risks actually get mitigated.

What if the pre-mortem surfaces risks we cannot address?

Some risks are acceptable. Not every risk needs a mitigation plan — some are low probability, low impact, or too expensive to mitigate. The point of the pre-mortem is awareness, not panic. Document the risks you are choosing to accept, and make sure that decision is explicit rather than implicit.

Conclusion

The pre-mortem is a technique for seeing what you are choosing not to see. Optimism is a valuable trait in product managers, but it must be paired with structured skepticism. The pre-mortem provides that structure.

AI Unpacker gives you prompts to run pre-mortems that surface real risks and generate actionable mitigations. But the willingness to take pre-mortem findings seriously, to allocate resources to prevention rather than reaction — that commitment comes from you.

The goal is not to predict the future. It is to prepare for the futures you can see coming.