Launch Premortem Risk Register
Identify plausible launch failures before release, then assign prevention, observable warning signals and bounded response actions to named owners.
Read this resource as Markdown
When to use this template
Use this before a planned software launch when the team can still change a dependency, clarify an offer or prepare a response. Discuss plausible failure paths without pretending they are predictions.
Choose another approach when: You need an active-incident procedure, want to score invented probabilities as measured risk, or plan to treat a completed workshop as proof the launch is safe.
Gather these inputs
- The actual release scope, acquisition routes and first user journey.
- Known dependencies, prior failures and relevant team observations.
- Owners with authority to review prevention and response actions within the approved scope.
Copy and adapt the template
Edit the text below and copy it into your own document. Edits stay in this browser field and are not submitted or saved by this page.
Worked example
Illustrative example, not a Crany customer result. Replace every example detail with facts you can verify.
Fictional example: a founder imagines that launch visitors request access but the invitation journey fails. The concern is grounded in an earlier expired-link defect, not an invented probability. A fresh approved-account journey becomes the preventive check, with an owner and a deadline before announcements. If that check fails, the response is to hold further acquisition messages and investigate; it is not to delete waiting applicants or weaken sign-in protection. The register also records that an external service may still fail after the check. Passing a rehearsal reduces one uncertainty and informs the separate release decision. It does not guarantee uninterrupted launch access.
How to use it
- Describe several concrete ways the promised launch experience could fail.
- Connect each scenario to evidence, a warning signal and a bounded preventive action.
- Assign response ownership and revisit unresolved risks before the separate release decision.
Check before using it
- Scenarios are labeled possibilities rather than reported incidents or measured forecasts.
- Actions have owners, review points and evidence of completion.
- A fallback does not assume permission to remove data, alter access or bypass security.
What to measure
Track actions actually completed, signals observed and scenarios that need revision. Compare the register with later launch experience to improve planning. A short premortem cannot quantify every risk or certify reliability.
Research and sources
Atlassian’s premortem play connects potential risks to assigned actions and later review. This launch-specific register is original, with no claim that its scenarios or scoring have been statistically validated.
- Atlassian Team Playbook: Pre-mortem — checked 2026-10-24. Potential project risks, assigned mitigation actions and later review. No numeric risk-reduction claim adopted.
About Crany
Crany is an AI marketing co-founder in development for software founders and vibe coders, designed to strategize, execute approved marketing and improve based on results. This free resource is usable independently of the product. Join the public waitlist.