The pre-mortem, but as a tree

A pre-mortem is the inverse of a post-mortem. Instead of analyzing why a project failed after the fact, the team imagines the project has already failed and works backward to identify the failure modes before they happen.

The technique was popularized by Gary Klein in a 2007 Harvard Business Review article and has been adopted widely since, mostly badly. Most pre-mortems are an hour-long meeting where the team brainstorms reasons the project might fail, captures them in a list, and then proceeds to ignore the list during execution. The exercise feels productive in the moment and produces almost no behavioral change.

This is a fixable problem. The pre-mortem isn't the wrong technique. The format is the wrong format. A pre-mortem captured as a list goes the way of every other planning artifact stored as a list: forgotten by week three, irrelevant by week six.

A pre-mortem captured as a graph is different. The risks become structural objects with relationships to the rest of the work. They stay visible. They influence decisions. They earn their place in the project instead of being archived alongside the meeting notes.

This post is about how to run a pre-mortem as a tree.

What goes wrong with list-shaped pre-mortems

The standard pre-mortem produces output that looks something like this.

Reasons the project might fail:

• We picked the wrong API provider
• The data migration is harder than expected
• A key engineer leaves mid-project
• The customer requirements change
• We underestimated the testing time
• The competitor ships first
• The integration with the existing system breaks production
• Stakeholders lose interest

The team writes the list, ranks the items by likelihood and impact, picks two or three to mitigate, and moves on. The list goes into a Notion page or a Google Doc and is never opened again.

This format fails for three reasons.

The risks have no relationships to the work. The list of risks is parallel to the list of tasks. The team has no mechanical way to ask "which tasks does this risk affect?" or "which risks are blockers for this task?" The risks float free of the project structure.

The risks have no relationships to each other. Some risks are causally linked. "Key engineer leaves" makes "data migration is harder than expected" worse, because the engineer was the one with the migration knowledge. The list format doesn't capture this. Each risk reads as independent, which is rarely true.

The risks have no relationship to mitigations. The team picks two or three risks to address, but the mitigation work goes into the project as separate tickets. Three months later, when somebody asks "did we handle the data migration risk," the answer is buried in old tickets and the risk itself has been forgotten.

The list format produces a planning artifact that doesn't survive contact with execution. This is the same failure mode as list-shaped roadmaps and list-shaped scoping. The structure isn't preserved because the format doesn't support structure.

What a tree-shaped pre-mortem looks like

The graph approach treats risks as first-class objects with structural relationships to the rest of the project.

The technique runs in four steps.

Step one: imagine the failure. Same as a standard pre-mortem. The team assumes the project has failed and asks why.

The framing matters. "Why might this project fail?" produces shallow answers. "It's six months from now, the project failed, what do we tell the team?" produces better ones. The second framing forces the team to imagine a specific narrative of failure, which surfaces specific failure modes the abstract framing misses.

Step two: plant the failure modes as branches. Each failure mode becomes a node on the graph. The node is planted as a parallel branch off whatever part of the project it threatens.

If the failure mode is "we picked the wrong API provider," the node attaches to the part of the graph where the API provider decision lives. The risk becomes a sibling branch to the chosen approach, visible alongside it.

If the failure mode is "key engineer leaves," the node attaches to the work that engineer is responsible for. The risk lives in the same neighborhood of the graph as the affected tasks.

If the failure mode is structural ("we underestimated the testing time"), the node attaches to the testing work itself. The risk modifies the existing structure rather than sitting outside it.

The point is that risks aren't a separate list. They're part of the graph, attached to the work they threaten. The structure carries the relationship.

Step three: trace the impact. For each risk node, follow the dependency edges forward to see what would be affected if the risk materialized. The graph already encodes "what depends on what." The same structure tells you "what would break if this fails."

This is where the graph format earns its keep. A risk attached to a node high in the dependency tree affects everything downstream. A risk attached to a node deep in a single branch affects only that branch. The structural position of the risk tells you its blast radius.

The list format can't do this. A list of risks and a list of tasks are parallel, not connected. The team has to manually trace which risks affect which tasks, every time, and the manual work doesn't get done.

Step four: plan the mitigations as nodes. For the risks worth mitigating, plant the mitigation work as new nodes upstream of the risk. The mitigation is itself a piece of work with its own prerequisites and effort cost. Treating it as a node forces the team to scope it instead of waving at it.

If the risk is "data migration is harder than expected," the mitigation might be "write a migration spike to estimate complexity." The spike is a node. It has prerequisites (access to the production data, time from the migration engineer). It has a cost. It either gets done or doesn't, and the graph shows which.

If the risk is "key engineer leaves," the mitigation might be "document the migration knowledge so anyone can execute it." Same logic. The mitigation is a node. The work either happens or it doesn't.

This is the difference between a pre-mortem that influences the project and one that doesn't. The mitigations are work, on the graph, with the same status logic as everything else. They can't be forgotten because they're either done, in progress, or visibly locked.

The completed graph

After the four steps, the project graph has three kinds of nodes.

Work nodes: the actual project tasks. These were already there from scoping.

Risk nodes: the failure modes from the pre-mortem. They're attached to the work they threaten. They have no execution status (you don't "complete" a risk), but they're visible alongside the work.

Mitigation nodes: the work to reduce the risks. These are first-class tasks with their own status logic. They live upstream of the risks they address.

The team can now look at the graph and see the project structure with its risks and mitigations woven in. The risks aren't a list in a separate doc. They're part of the same artifact the team uses to plan and execute.

This produces three behavioral changes.

The team makes different decisions during execution. When a risk node is sitting next to a work node, the team thinks about it. When the risk is on a separate page in a forgotten Notion doc, they don't.

The team executes the mitigations. Mitigation work that's a node in the project graph gets the same treatment as any other work. It's prioritized, assigned, completed, and tracked. Mitigation work that's a bullet point in an old document doesn't.

The team revisits the risks naturally. As the project graph updates, the risks update with it. New work added to the graph might affect existing risks. Completed mitigations close their associated risks. The pre-mortem stays alive in a way the list format never does.

A worked example

Consider a project to migrate a customer-facing application from one cloud provider to another.

The work nodes from scoping include: migrate the database, migrate the application servers, migrate the file storage, update the DNS configuration, validate the new environment, switch traffic over, decommission the old environment.

The team runs a pre-mortem. The failure modes that surface include:

The new provider's database has subtle behavioral differences from the old one. Attached to the database migration node.

The file storage migration is much larger than estimated and runs over the planned window. Attached to the file storage migration node.

DNS propagation issues cause downtime during the cutover. Attached to the DNS configuration node.

The validation pass misses an important regression that's only caught after switching traffic. Attached to the validation node.

A team member on vacation during the cutover means there isn't enough coverage for incident response. Not attached to a specific work node; this is a temporal risk attached to the cutover cluster.

After step three, the impact tracing produces useful structural information. The database behavioral differences are upstream of every other migration step, so this risk has the largest blast radius. The DNS issue is contained to the cutover window but would be high-impact if it happens. The team-coverage risk is structural to the cutover cluster but doesn't propagate further.

After step four, the mitigations are planted as nodes. A "behavioral compatibility test suite" node is added upstream of the database migration. A "file storage size audit" node is added upstream of the file storage migration. A "DNS rehearsal" node is added upstream of the DNS configuration. A "validation checklist with regression cases" node is added upstream of the validation. A "cutover staffing schedule with backup coverage" node is added upstream of the cutover.

The graph now shows the migration project with its risks and mitigations integrated. Each mitigation has its own status. As mitigations complete, the team can see the risk surface shrinking. As new work surfaces during execution, the team can ask whether it introduces new risks the pre-mortem didn't catch.

This is a different artifact from a list. It evolves with the project. It influences daily decisions. It earns its place in the team's workflow.

What this isn't

Tree-shaped pre-mortems aren't a substitute for project management discipline.

The technique works because the graph keeps risks visible. It doesn't work if the team ignores the graph. A team that runs a beautiful pre-mortem and then doesn't open the project tool until launch day will fail the same way they would have without the pre-mortem.

The technique also isn't a way to identify all possible risks. Pre-mortems are good at surfacing risks the team can imagine. They're bad at risks the team can't imagine. The unknown unknowns are still unknown after the pre-mortem. The technique reduces the surface area of preventable failure, not the surface area of all failure.

And the technique isn't a process gate. Some teams treat pre-mortems as a mandatory step that has to happen before work can start. This is the wrong frame. The pre-mortem is a tool that's useful when the team needs it, which is most projects but not all of them. A two-day bug fix doesn't need a pre-mortem. A six-month migration does.

The right rule is: if the project is large enough that failure would be costly, do a pre-mortem. If it's small enough that failure is cheap, skip it. The graph format makes pre-mortems cheap enough that the threshold is lower than most teams currently use, but there's still a threshold.

Why this works in a graph tool specifically

The technique technically works on a whiteboard. You can draw nodes and edges and risks and mitigations on any surface. The whiteboard version captures the structure for an afternoon and loses it by next week.

The technique works in a graph tool because the graph persists. The risks stay attached to the work they threaten. The mitigations stay tracked. The structural relationships survive the transition from planning to execution.

This is the same argument as graph-first scoping and graph-first roadmaps. The format that captures the structure has to be the format that supports the work, or the structure gets lost in the translation between formats.

Tree was built for this. The pre-mortem produces nodes, edges, risks, and mitigations on the same graph the team will use during execution. There's no separate "pre-mortem document" that gets archived. The pre-mortem is the project, with risks woven in.

If you want to run a pre-mortem on a graph instead of a list, join the waitlist.