Somewhere in your next planning meeting, someone already knows how the project is going to fail. They noticed it weeks ago: the vendor who goes quiet every Friday, the dependency nobody quite owns, the launch date that only works if nothing goes wrong. They won't say it. That isn't cowardice. In a room full of momentum, a doubt sounds like disloyalty, and nobody wants to be the one who didn't believe.

Six months later, at the postmortem, it comes out. “Honestly, I kind of saw this coming.” Everyone nods, because so did they.

That gap matters. The knowledge was in the room the whole time. What was missing was a moment when saying it out loud was allowed.

The meeting that happens too late

Most teams already hold a meeting built for honesty about failure. It's called a postmortem, and it comes at the one point where honesty no longer costs anything and no longer helps. The money is spent, the deadline is gone, and the warning that could have changed things is now just a story.

It's tempting to treat this as a problem of information, as if better forecasting, more data or a sharper risk register would have caught it. Usually the information was there. Somebody held it, privately and with some unease, and kept quiet because the meeting was set up to build commitment, not to test it.

To fix that, you don't need smarter people. You need to change the question they're asked.

Prospective hindsight: why “it failed” beats “could it fail?”

The research psychologist Gary Klein spent his career studying how experienced people make decisions under real pressure: firefighters, military commanders, intensive-care nurses. In a 2007 Harvard Business Review piece he described a simple exercise he called the premortem. Before a project is locked in, the team imagines it is some time in the future and the project has failed, completely. Then everyone writes down why.

The idea draws on a phenomenon researchers call prospective hindsight. In a 1989 study, Deborah Mitchell, J. Edward Russo and Nancy Pennington found that when people imagined an event had already happened, they came up with more specific reasons for it than when they only considered whether it might happen. Treating the outcome as settled changed what their minds did.

Here's why that works. Ask “Could this project fail?” and you've invited an evaluation, which a committed team will answer with a defense. Smart, invested people are very good at defending. Say “It failed. What happened?” and you've asked for an explanation, and people are compulsive storytellers. Give someone an ending and they will start building the plot that leads to it, reaching for details they would otherwise have filtered out as too pessimistic, too awkward or too small to mention.

The same brain that was guarding the plan a moment ago starts digging through it instead.

What a premortem does to the room

The cognitive trick is only half of it. The other half is social, and it's arguably the bigger one.

In an ordinary planning meeting, raising a risk carries a cost. You look negative. You slow things down. You seem to be doubting the person who championed the plan, who may well sign your performance review. So people do the arithmetic and stay quiet, or soften the concern until it's useless: “Might be worth keeping an eye on the vendor timeline.”

A premortem reverses that arithmetic. Naming a way the project could die is no longer a breach of loyalty. It is the task. The person who spots the most plausible failure isn't the pessimist anymore. They're the one who did the exercise well. Klein presented the technique partly as an answer to the overconfidence that builds up as a team commits to a plan, and Daniel Kahneman later praised it in Thinking, Fast and Slow as one of the few practical tools for loosening a group's grip on its own optimism.

There's also a quieter benefit that rarely gets mentioned: relief. Plenty of people carry private doubts about their work, and they carry them alone, half-convinced the doubt says something bad about their commitment or ability. A premortem tells them their unease was information, not a character flaw. Some of the most valuable people on your team are the ones who see trouble coming. For years, many of them have been quietly taught that seeing it makes them difficult.

How to run a pre-mortem meeting that actually works

The premortem only works if you protect what makes it work. A few details make the difference.

Timing. Run it after the plan is mostly shaped but before final commitment. Too early and there's nothing concrete to break. Too late and people will hold back, because the decision is already made and objecting feels pointless.

Set the scene in the past tense, and mean it. Don't say “let's think about risks.” Say something like: “It's six months from now. This project failed, and it failed badly. Take a few minutes and write down every reason it happened.” The certainty is what does the work. Hedge it and you lose the effect.

Write silently before anyone speaks. If the most senior or most talkative person goes first, their story becomes the anchor and everyone else drifts toward it. Give people a few quiet minutes with paper or a private doc so each person's failure story is their own.

Share one reason at a time, round-robin, leader last. Go around the room, one item per person per turn, until the lists run dry. The person who owns the plan speaks last and mostly listens. They should not respond, rebut or explain. The moment the owner starts defending, everyone else goes back to doing the arithmetic.

Change the plan before you leave. This is where most premortems quietly fail. A list of risks that nobody acts on is just a more elaborate way of feeling worried. Pick the few failure stories that are both plausible and serious, and for each one decide what in the plan changes, who owns that change, and by when.

Keep it about the plan, not the people. “Engineering missed the deadline” goes nowhere. “We had no buffer for the API migration and no one was tracking it” gives you something to fix.

The quiet part

Underneath all of this is a tension most of us feel and rarely name: the pull between belonging and telling the truth. We want to be on the team, behind the plan, one of the people who believed. Often the most caring thing you can do for a group is say the uncomfortable thing while it's still useful. A premortem doesn't remove that tension. It gives the group a set time, with clear rules, when telling the truth is how you belong.

Your next moves

  • Pick one project launching in the next 30 days and put a 30-minute premortem on the calendar this week, scheduled before final sign-off.
  • Write your opening line word for word now: “It's [specific date]. This project has failed. Spend four minutes writing every reason why.” Read it exactly as written. Don't soften it on the day.
  • Run silent writing for at least three minutes before anyone speaks, then go round-robin with one reason per person per turn, and the plan's owner speaks last.
  • Leave with no more than three risks, each with a named owner and one concrete change to the plan, written into the project doc before the end of the day.
  • Tonight, run a solo premortem on one personal decision you're about to make, such as a job move, a hard conversation or a big purchase. Imagine it went wrong and write down why. Notice which reason you were avoiding.

Looking back so you can look ahead

A premortem and a postmortem are two halves of the same habit: being honest about how things go wrong. You can't run a good one without getting better at the other. MeetingMortem is built for the looking-back half. It helps you reflect on how your meetings actually went, what got decided, what got glossed over, and where the real doubts only came out after everyone had left. Over time those patterns show you exactly where your team needs a premortem most. If you'd like to start noticing them, you can explore it at meetingmortem.lumenlabs.works.