How to Run a Product Launch Pre-Mortem

Picture the launch review after a consequential product change. Customers received little value, a dependent group was harmed, support found the problem before telemetry did, or the team could not reverse the release cleanly. The expensive question is: what could have been surfaced before broad exposure?

A product launch pre-mortem is a structured exercise run before launch. The team assumes the launch failed, silently lists plausible causes, then turns material risks into evidence checks, owners, warning signals, mitigations, and advance, pause, stop, or rollback rules. It surfaces possibilities; it does not predict failure or replace research, testing, or monitoring.

The useful output is not a wall of imagined disasters. It is a launch-risk record that states what the team knows, what remains hypothetical, what evidence comes next, and who acts on it.

Source and SERP snapshot reviewed July 26, 2026.

What a product launch pre-mortem is—and is not

The prospective-hindsight exercise

A pre-mortem asks the team to assume that a future launch has already failed and work backward to generate plausible explanations. This is prospective hindsight: moving mentally into a future outcome, then explaining it as if it had happened. Mitchell, Russo, and Pennington’s original 1989 paper defined the frame and reported nuanced effects from temporal perspective and outcome certainty.

Gary Klein later adapted the approach for project planning, arguing that the assumed failure gives knowledgeable dissenters a legitimate reason to voice reservations. For a product launch, that matters when plan authors, senior stakeholders, or delivery momentum make ordinary criticism harder.

The exercise still does not forecast the launch. It does not estimate the probability or prevalence of a risk, prove that the team found every failure path, or validate the product decision. In particular, the 1989 paper does not establish that a product pre-mortem improves launch outcomes, and it should not be used to support a fixed efficacy percentage.

Pre-mortem vs risk register, launch checklist, and post-mortem

The pre-mortem feeds the other artifacts; it does not replace them. A material hypothesis may become a maintained risk, a mitigation may become a checklist item, and a later incident may become factual post-mortem evidence.

When to run it and who should participate

Run it when the plan is concrete enough to challenge and change is still possible

Run the exercise when the team can describe the change, affected users, launch scope, dependencies, intended value, and recovery path—but before the decision is locked. It is especially useful before consequential launches, broad exposure, pricing or access changes, feature removals, trust-sensitive flows, or a material expansion of rollout.

Revisit the record after a material change to scope, audience, dependency, evidence, mitigation, or rollout. There is no universal meeting duration, attendee count, calendar offset, or review cadence. The right shape depends on the decision, consequences, and team governance.

Bring the knowledge needed to expose different failure paths

Include the accountable PM, a facilitator, engineering or QA, design or research, data, product marketing or GTM, and support or operations. Add privacy, security, legal, accessibility, safety, finance, or domain specialists only when the launch requires their judgment.

Include people close to affected users and operational consequences, not only the authors of the plan. The facilitator protects dissent, prevents senior voices from anchoring the first answers, keeps imagined causes separate from evidence, and ensures that required reviews are routed rather than simulated.

Prepare a copyable one-page brief

Complete this brief before the workshop so participants challenge the same launch decision.

## Product Launch Pre-Mortem Brief

- Product change and launch decision:
- Intended user value:
- Affected and excluded users:
- Launch scope and rollout path:
- Known dependencies and constraints:
- Existing research, analytics, support, and quality evidence:
- Material unknowns:
- Reversibility and recovery path:
- Accountable decision owner:
- Evidence checkpoint after this workshop:

How to run the product launch pre-mortem

Create a shared board or document with space for independent causes, clusters, evidence labels, dissent, and controls. The facilitator then runs the following sequence.

1. Frame one concrete failure state

Choose a future review point that is relevant to this launch; do not borrow a standard time horizon. State a material failure across one or more dimensions: users did not receive the intended value, a cohort experienced unacceptable consequences, the product could not operate safely or reliably, the business outcome failed, or the team learned too little to make the next decision.

Say explicitly: “This scenario is fictional. It helps us generate possibilities; it does not establish that failure is likely.” Keep the scenario specific enough to work backward from, but do not load it with an invented cause.

2. Generate failure causes silently before discussion

Ask each participant to write independently before anyone shares. Use anonymous input when hierarchy or interpersonal risk could suppress a concern. A practical sentence form is:

Because [condition/cause], [failure event] occurred, leading to [consequence for whom].

Silent writing reduces early conversational anchoring and gives each person space to contribute. A brainwriting pre-mortem study used silent written idea generation in a healthcare implementation context, while Atlassian’s practical pre-mortem play also starts with silent writing before grouping and assigning actions. These sources support the process choice, not a claim that it improves product-launch outcomes.

3. Cover the product-launch failure lenses

Use every lens once to challenge coverage. This matrix is an editorial aid, not a validated or exhaustive taxonomy. For deeper treatment of habits, perceived loss, messaging, and customer response, use the guide to avoid user backlash from product changes.

For accessibility risks, involve people with relevant access needs and combine user evaluation with standards-based conformance work; W3C warns that either route alone is insufficient.

4. Cluster without turning votes into evidence

Merge true duplicates, but retain differences in cause, affected cohort, consequence, and recovery path. Keep a dissent log for severe, unfamiliar, or minority risks that could disappear during clustering.

If the team votes, use the result only to choose discussion order. A vote does not show probability, prevalence, confidence, customer demand, or evidence quality. Repeated model outputs do not show those things either.

Prioritize discussion qualitatively by consequence, reversibility, blast radius, detectability, current evidence, and ability to respond. Do not turn those prompts into an invented risk score.

5. Label what the team knows

Apply one evidence-status label to every material input:

Keep the labels separate. Do not combine them into one confidence or risk score. A unanimously imagined concern remains a risk hypothesis; an unpopular observed harm remains evidence. Record the source, population, date, and limitation of observed evidence wherever those details affect the claim.

6. Route each material risk to the right evidence

Turn each hypothesis or unknown into a question, then choose the method that can answer it. GOV.UK’s research-planning guidance recommends converting unfounded assumptions into research questions and selecting activities that fit what the team needs to learn; NN/g likewise distinguishes methods by the evidence they produce.

• Interviews or research: motivation, lived context, perceived loss, trust, and language.
• Usability or accessibility evaluation: comprehension, task performance, and barriers with representative affected users.
• Analytics, support, or quality evidence: current dependence, baselines, incidents, and affected cohorts.
• Customer-response simulation: extra objections or competing hypotheses only. NN/g recommends treating synthetic-user output as hypotheses, not final decisions. Label every output directional · model-generated · unvalidated; see when to use synthetic users for the full boundary.
• Controlled experiment: a causal live-behavior question only when the exposure and design are responsible. Use the dedicated A/B testing risks audit rather than treating “run a test” as sufficient.
• Staged rollout or canary: bounded real exposure, release-safety telemetry, and guardrail monitoring. Google SRE defines canarying as a partial, time-limited deployment evaluated against the rest of the service; not every staged product rollout creates a causal comparison.
• Specialist review: legal, privacy, security, accessibility, safety, or domain assurance when required. Generated output cannot stand in for approval.

7. Convert selected risks into owned launch controls

For each material risk, separate prevention, detection, mitigation, contingency, and rollback. Assign one accountable owner, the next evidence step and owner, an observable early-warning signal, a preventive mitigation, and a review checkpoint.

Then define the rule that changes the decision: what supports advance or wider exposure; what causes a pause or stop; and what triggers rollback or contingency. The accountable team must derive thresholds, exposure stages, and monitoring windows from its baselines, consequences, and governance. There is no universal value to copy.

This operational shape is consistent with HM Treasury’s broader risk-management guidance, which connects accountable owners, treatment, early-warning indicators, monitoring, and contingency planning. It does not validate this product-launch template. A mitigation can reduce exposure or consequence; it cannot erase an evidence gap.

Copyable product launch risk and decision record

This record is an editorial template, not a validated scoring model. Create one record for each material risk, or use a table containing the same fields. Complete it during the workshop, then update it when evidence, scope, or controls change.

## Product Launch Pre-Mortem Record

### Launch decision

- Change and intended user value:
- Affected users and high-consequence cohorts:
- Scope, reversibility, and recovery path:
- Accountable launch owner:

### Risk

- Failure lens:
- Because [cause], [event] may occur, leading to [consequence for whom]:
- Source:
- Evidence label:
- Evidence supporting or contradicting it:
- What this evidence cannot establish:
- Next evidence method and owner:
- Preventive mitigation and owner:
- Early-warning signal and monitoring owner:
- Advance or widen rule:
- Pause or stop rule:
- Rollback or contingency rule:
- Review checkpoint:
- Dissent or unresolved uncertainty:

### Decision

- Advance to evidence / revise / stage / pause / stop or escalate:
- Rationale and evidence still required:
- Approver under the team’s existing governance:

Do not prefill the record with a fabricated case, assign a synthetic probability, or collapse evidence labels into a score. “Owner” means a named, accountable person in the team’s operating system—not a department with no decision right. “Approver” refers only to existing governance; the workshop cannot invent approval authority or imply specialist sign-off.

The decision field records the next responsible move, not a declaration that the launch is safe. A risk can advance to research while the launch remains paused. A mitigation can be implemented while a required review remains open. Preserve those states separately so delivery progress is not mistaken for evidence.

At each evidence checkpoint, update three things separately: the source and evidence label, the status of the controls, and the current decision. Record contradictory evidence rather than deleting the original hypothesis. If the launch scope or affected population changes, revise the corresponding fields and route any newly material risk through the same loop. This preserves the basis for the decision without pretending that the first workshop captured a final truth.

From workshop output to a controlled launch decision

The workshop is complete only when its material outputs enter an evidence and control loop:

flowchart TD
    A[Imagine a material launch failure] --> B[Generate causes independently]
    B --> C[Cluster causes and preserve dissent]
    C --> D[Label constraint, evidence, hypothesis, unknown, or required review]
    D --> E{Can evidence support the next decision?}
    E -->|No| F[Research, test, generate hypotheses, or seek specialist review]
    E -->|Yes| G[Assign owner, signal, mitigation, and rules]
    F --> G
    G --> H{Responsible exposure now?}
    H -->|No| I[Revise, pause, stop, or escalate]
    H -->|Yes| J[Stage or run a suitable controlled test]
    J --> K[Monitor by affected cohort]
    K --> L[Advance, hold, mitigate, or roll back]

Text equivalent: Imagine failure, generate causes independently, preserve distinct risks, and label each input. If evidence is insufficient, route the risk to appropriate research, testing, hypothesis generation, or specialist review. Only then assign controls and decide whether exposure is responsible. During exposure, monitor affected cohorts and follow predefined advance, hold, mitigation, or rollback rules.

The exercise may create risks, questions, mitigations, evidence tasks, and reasons to investigate, revise, narrow, pause, stop, or escalate. It cannot establish customer response, prevalence, usability, accessibility, causal impact, release safety, or launch approval.

Staging limits exposure and can reveal production signals; it does not guarantee safety or create causality by name. Monitoring must remain cohort-aware because an acceptable aggregate can hide a serious consequence for an affected group. The absence of imagined risks is not evidence of safety.

Before exposure, confirm that each material rule can be executed: any recovery mechanism it relies on exists, the monitoring owner can see the warning signal, operational teams know the escalation route, and the decision owner can act. A written rollback rule without the capability or authority to follow it remains an unresolved control.

Decision authority stays with the people and governance responsible for the launch, the affected domain, and the evidence method. The record makes that authority visible; it does not replace it.

Common questions about product launch pre-mortems

Does a pre-mortem predict why a launch will fail?

No. It generates plausible explanations, warning signals, and questions by assuming failure for the exercise. It does not estimate which cause will occur, how likely it is, how many users it may affect, or whether the launch will fail at all. Treat every imagined cause as a hypothesis until evidence changes its status.

Is it a replacement for user research or testing?

No. A pre-mortem helps expose assumptions and route them. Interviews can address lived context and motivation; usability evaluation can observe task performance; analytics can establish current behavior; controlled experiments can answer bounded causal questions; staged exposure can reveal release signals. The workshop itself provides none of that evidence.

How should teams prioritize without fake precision?

Use consequence, reversibility, blast radius, detectability, evidence status, and ability to respond as qualitative discussion prompts. Preserve severe or unfamiliar dissent even when few people raise it. Votes can determine which risk the group discusses first, but they cannot establish probability, prevalence, confidence, or importance to customers.

When should it be revisited?

Revisit the record after a material change to launch scope, audience, dependencies, evidence, mitigation, or rollout. Also revisit it when monitoring reveals a new affected cohort or invalidates an assumption. Do not apply a universal cadence; choose review checkpoints that match the team’s decision process and the risk’s response time.

Conclusion — a pre-mortem earns questions, not certainty

A product launch pre-mortem is useful when it turns an imagined failure into a traceable loop: risk hypothesis, evidence status, evidence route, owner, signal, mitigation, and decision rule. It does not earn confidence merely because the team completed the workshop. Use the broader guide to test product changes before launch when choosing the evidence method.

For an optional hypothesis-generation input labeled directional · model-generated · unvalidated, join the genjury waitlist. It does not predict failure, supply customer evidence, validate a launch, guarantee safety, or replace discovery, user research, testing, specialist review, staged exposure, monitoring, and human accountability.