Premortem for product managers
A premortem is a short exercise I use before a product plan, launch, or major decision is committed. I ask the team to imagine that the effort has already failed and then work backward to explain why. The point is not to predict the future or make the room cynical. It is to make plausible failure modes discussable while the team can still change the plan.
I find a premortem especially useful when a group is excited about an idea, working under time pressure, or relying on assumptions that have not been tested. It does not replace discovery, risk review, or a launch plan. It gives those activities better questions.
Start with a clear decision
I define the object of the exercise before inviting people into the room. “The project failed” is too broad. I state the decision, customer, time horizon, and outcome I am evaluating: “We launched this workflow for this customer group, and it did not produce the intended result.” If the team is reviewing a roadmap bet, I describe what success was supposed to look like without inventing a target that was never agreed.
I also make the counterfactual time-bound. A launch can fail because adoption is weak, because reliability is poor, because the economics do not work, or because the team cannot operate it. The relevant causes depend on when and how I judge the result.
Create the failure story
I explain that the exercise begins after the outcome is known. Each participant writes possible reasons for failure independently before discussion. I prefer specific statements over vague concerns. “Customers did not understand the value” is a starting point; “the first-use experience required customers to configure data they did not have” gives us something to investigate.
I ask people to consider different kinds of failure:
- Customer problem or segment misunderstanding.
- Weak evidence behind the product decision.
- Usability, accessibility, or trust friction.
- Technical reliability, performance, or security risk.
- Operational, support, or go-to-market constraints.
- Pricing, packaging, or unit-economics problems.
- Dependencies, ownership gaps, or decision delays.
These categories are prompts, not a checklist to complete for its own sake. I want the team to notice what it might otherwise leave implicit.
Make it safe and concrete
The quality of a premortem depends on psychological safety. I frame the work around the plan, not the competence of the people who created it. I invite dissent from engineers, designers, researchers, support, sales, operations, and other colleagues who see different parts of the customer experience. If the meeting feels like a defense of the roadmap, the exercise will produce polite approval instead of useful risk.
I separate a concern from a conclusion. A participant can say, “I am worried that the workflow will fail for customers with multiple roles,” without having to prove that failure is certain. I capture the context, the affected group, and the mechanism that could create the problem.
I also keep anonymous input available when hierarchy or team history might suppress disagreement. An anonymous note is not automatically correct, but it can reveal a question worth investigating.
Cluster and test the risks
After the independent writing, I group similar failure stories and clarify their differences. Several notes about onboarding may describe one underlying issue, or they may point to separate problems for separate segments. I ask:
- What would have to be true for this failure to occur?
- What evidence do we already have?
- Which customer or system is exposed?
- How soon could we detect the problem?
- What would make the risk more or less likely?
I avoid pretending that a precise score makes uncertainty disappear. I can use a simple view of impact, plausibility, and detectability to choose where to look first, but I record the reasoning behind the assessment. A low-probability failure with severe consequences may deserve attention even when it is not the most likely scenario.
Then I classify each risk as something to prevent, test, monitor, accept, or escalate. A risk that can be answered with a customer interview belongs in a discovery plan. A reliability concern may need an engineering spike or load test. An unclear owner is a planning problem, not a research question.
Turn concerns into decisions
A premortem has little value if it ends with a list of worries. For the most important risks, I write a response with an owner and a point in the plan where the response will happen. The response might be a smaller first release, a guardrail, a usability test, a fallback process, a support script, a technical constraint, or a decision checkpoint.
I distinguish a mitigation from evidence. Adding a warning message may reduce confusion, but it does not prove that the underlying workflow is useful. A manual fallback may protect customers during a rollout, but it does not make a weak business case strong. I state what each action changes and what it will teach us.
I also record triggers. If a risk becomes visible through failed tasks, support themes, latency, opt-outs, or another agreed signal, the team should know who responds and what decision follows. Monitoring without a response plan is observation, not risk management.
Revisit the premortem
I revisit the highest-value risks at the next decision point and after meaningful new evidence. I remove risks that have been disproven, update those whose conditions changed, and add new ones created by scope or implementation choices. I do not treat the original document as a prediction scorecard.
The review also helps me notice whether the team is learning. If the same concern appears repeatedly without an owner, the obstacle may be prioritization or decision-making rather than uncertainty itself. If every risk is marked accepted, I ask whether the group is making an intentional tradeoff or simply avoiding a hard conversation.
Common mistakes
The first mistake is running a premortem as a disguised approval meeting. If leaders answer every concern immediately, the team stops exploring. The second is asking for generic worst cases with no customer or decision context. That produces dramatic possibilities rather than actionable risks.
I also avoid using the exercise to assign blame for old launches. A retrospective asks what happened; a premortem asks what could happen and what we can do now. Finally, I do not let a risk list become a substitute for judgment. The goal is not to eliminate uncertainty. It is to choose which uncertainty deserves a test, a safeguard, or an explicit acceptance.
A practical starting exercise
Before the next important product decision, I write one sentence describing the intended outcome and invite a small cross-functional group to complete: “It is six months later, and this effort failed because…” Each person supplies several specific reasons. We cluster them, select the risks with the most consequential unknowns, and assign one next action to each.
I then add the results to the decision brief, including what would change the plan. A good premortem makes the plan more resilient without pretending that the team can see the future. That is why I use it: it gives reasonable doubts a productive place before customers have to discover them for us.
Next step
Build stronger product strategy, discovery, and decision-making skills in the Product Manager Certification. Subscribe to the Product HQ newsletter for practical frameworks and career-ready product lessons.
