Gary Klein describes the method as imagining a plan has failed and generating potential threats together. The worksheet below is our startup adaptation; its timing and prioritization rules are suggestions, not a validated scoring system. See Klein's description of the premortem.
Choose a plan that is concrete enough to examine
Name the launch, the people it serves and the commitment you are about to make. “Our startup fails” is too broad to guide a useful check. “Our limited launch does not produce enough evidence to decide whether to expand” gives the exercise a boundary.
Write what success would mean for this particular step. Separate a successful test from a successful business: completing interviews, demonstrating a workflow or observing initial use does not by itself establish demand or repeat use.
Run the exercise before a commitment that remains changeable. If the plan is already under way, use the next decision point. Include people who understand delivery, customer contact and support, where available. A solo founder can complete the worksheet alone and identify which perspectives remain missing.
A suggested 25-minute session
- Frame the plan, five minutes. State the current scope, intended audience, success condition and constraints. Give everyone the same starting point.
- Write independently, five minutes. Imagine the agreed failure at a named future checkpoint. Each person records plausible causes before group discussion.
- Compare causes, five minutes. Share the notes and group genuinely similar causes. Preserve disagreement and distinguish an observation from a possibility.
- Choose responses, seven minutes. Identify the causes that could change your next commitment and that you can usefully investigate or address now.
- Confirm ownership, three minutes. Give each chosen response an owner, due date and review trigger. Name unresolved risks explicitly.
The agenda is a starting point. Use more time if the decision needs it. A vote can reveal which concerns people prioritize, but agreement is not evidence that a cause is likely. Avoid assigning precise probabilities without a defensible basis.
Copy this premortem analysis template
Plan and next commitment:
Intended audience and launch boundary:
Success condition for this step:
Future checkpoint and imagined failure:
Participants; important perspectives missing:
For each plausible cause:
- Cause stated as a specific event or condition:
- Why it could affect this launch:
- Existing evidence, source and date:
- What is assumed or unknown:
- What would make this concern less plausible:
- Response: change / test / monitor / accept:
- Next permitted action and decision it informs:
- Owner and due date:
- Observable review trigger:
- Remaining exposure if the response succeeds:
At the checkpoint:
What actually happened, with evidence:
Which concern changed; what remains unknown:
Keep, revise, pause or close the plan; reason:Keep the cause separate from the response. “We need more marketing” is a proposal. “Our intended users never encounter the invitation” is a condition you can investigate. “The product is confusing” needs a task and audience before it becomes a useful observation.
A worked example: a limited founder-tool launch
Fictional example: a team plans to invite a small group of consenting founders to try a decision-history workflow. At its future checkpoint, it imagines having too little usable evidence to decide whether to expand. None of the rows below describes Feedsion customers or measured product performance.
| Plausible cause | Evidence or unknown | Response before the next commitment | Owner and review trigger |
|---|---|---|---|
| Invitees cannot tell which task to try | No participant observation yet | Ask consenting invitees to explain the invitation in their own words; record misunderstandings | Lee; review before sending the wider invitation |
| Participants avoid using their private notes | Willingness and permissions unknown | Offer a clearly labelled fictional example; record when it changes what the session can establish | Sam; review whenever a participant declines real material |
| Support effort exceeds the team's capacity | No comparable workload observation | Keep the first cohort small and record actual support work; agree a pause trigger before expansion | Maya; review after the first sessions |
The privacy response may make a session possible, but a fictional task cannot establish behavior with someone's real records. The support response may bound the team's exposure, but a small cohort cannot establish operating cost at scale. Record these limits beside the action rather than treating a mitigation as proof that the underlying concern is solved.
Turn the exercise into a decision
Choose a small number of responses that matter for the next step. Investigate an uncertain belief with an assumption test brief when it needs an observable question and an interpretation rule. Change the plan when the risk is already clear enough to act on. Monitor a condition when you have a meaningful signal and someone responsible for watching it.
An accepted risk still needs a reason and an owner with authority to accept it. Write the chosen scope and unresolved exposure in a decision journal, then revisit the triggers in your weekly decision review. The exercise does not grant permission to use private data or contact customers.
Avoid treating the worksheet as a forecast
A detailed scenario can be convincing without being likely. A premortem helps generate questions; it does not estimate market demand, prove a launch will fail or guarantee that you have found every important risk. Keep new evidence separate from the imagined story and update the plan when the facts change.
How is this different from a postmortem? A premortem examines an imagined failure before the relevant outcome. A postmortem examines what actually happened. Do not present the imagined causes as observed findings.
How often should we repeat it? Consider another session when the launch scope, dependencies or commitment materially change. Between sessions, review the agreed signals and actions instead of recreating the entire list each week.
What should a solo founder do first? Write one concrete future failure and three plausible causes. For each, identify what you know, what is missing and one permitted next action. Start with the cause most capable of changing your next commitment, rather than the one with the most dramatic story.