pre-mortem

A pre-mortem uses prospective hindsight (Gary Klein): imagine it is some months from now and the plan has already failed, then work backward to explain why. Naming a failure that has "already happened" surfaces risks that "what could go wrong?" misses, because it removes the optimism of an open future.

When to use

The user has a plan, PRD, strategy, launch, migration, or decision and wants it stress-tested before committing. Not for work already shipped (that is a post-mortem) and not for debugging a specific failure (use a debugging workflow).

Inputs

• PLAN (required): the thing under review. A pasted document, a file path, or a described decision.
• CONTEXT (optional): goals, constraints, budget, timeline, and what "failure" concretely means here (missed deadline, low adoption, blown budget, harm to users). If missing, ask one or two questions before starting, since the lenses are only as good as the definition of failure.
• HORIZON (optional): the point to imagine standing at. Defaults to the plan's own deadline, or "six months after launch" if none is given.

Orchestration map