The Framework That Asks You to Imagine Failure (Before It Happens)
In 2026, we’re still obsessed with success frameworks.
OKRs. Prioritization matrices. North Star metrics. Everything designed to drive you toward victory.
And yet, most projects still die. Most features launch and nobody uses them. Most strategic decisions that seemed solid become the mea culpa of the next all-hands meeting.
What nobody tells you is that the problem isn’t that you lack a success framework.
It’s that you’ve never had a failure framework.
The inverted logic that changes everything
Look, we’ve spent weeks on this blog discussing mental models. Howard Marks and second-level thinking. Naval and types of leverage. Munger and incentive systems.
They all share something: they force you to think differently before acting.
The Pre-Mortem does exactly that—with a twist that feels uncomfortable at first.
The mechanics are simple:
Instead of asking «how do we make this work?», you ask «assuming this has already failed, what killed it?»
This isn’t pessimism. It’s the opposite: it’s strategic honesty before pride and confirmation bias contaminate your analysis.
Research consistently shows that when teams run a Pre-Mortem before launching a project, they identify a significantly higher percentage of potential failure causes than with any other planning methodology. Some studies point to up to 30% more.
Thirty percent more visible problems—before they become real problems.
That’s brutal.
Why the human brain needs this
The problem isn’t that you’re bad at planning.
The problem is that when you’re inside a project—especially one that excites you—your brain activates all its optimism-protection mechanisms.
It’s called the planning fallacy: the systematic tendency to underestimate a task’s time, costs, and risks while overestimating its benefits.
This bias doesn’t disappear with experience. Veteran builders have it just as much as juniors. What changes is whether you have a system to combat it.
The Pre-Mortem is that system.
When you’re asked to imagine failure as an established fact—«the project died, what happened?»—your brain switches modes. It exits defense mode and enters diagnostic mode. It’s much easier to identify risks from there.
How to apply it in practice (without it becoming a two-hour meeting)
Here’s how I use it before launching something new.
Step 1: Define the time horizon
Don’t just say «the project failed.» Be specific: «Six months have passed since launch and the project is dead. Nobody uses it. We’re shutting it down."
Specificity forces concreteness. Concreteness produces real insights.
Step 2: List the causes of death
Write down everything that could have caused that death. No filters. No hierarchy yet. Just a long, honest list:
- We didn’t find product-market fit
- The main distribution channel didn’t work
- The technical integration was more complex than expected
- The team lacked the specific skill needed
- We were late to market
- We underestimated acquisition cost
- The problem we solved didn’t hurt enough
Do this exercise alone first. Then with the team. You’ll see different things.
Step 3: Prioritize by probability and impact
From that list, select the three or four risks that combine high probability with high impact if they materialize.
Those are your real blind spots.
Step 4: Design countermeasures before you start
Here’s the most ignored part: once critical risks are identified, you design specific responses to each before the project begins.
Not «we’ll manage this if it comes up.» But: «if this happens, we will do this specific thing."
That difference separates teams that react from teams that respond.
Where it fits with the other frameworks
If you’ve been following this blog, you’ll recognize the connections.
Eisenhower knew that the urgent is rarely the important. The Pre-Mortem helps you identify what’s truly important before you start—not when you’re already racing against the clock.
First Principles—the framework Elon Musk popularized for breaking problems down to their fundamental truths—works best when you already know where the false assumptions lie. The Pre-Mortem reveals them.
And John Boyd’s OODA Loop—Observe, Orient, Decide, Act—starts with observation. The Pre-Mortem is anticipatory observation. You give your decision loop information that would normally only be available after the disaster.
These aren’t competing frameworks. They’re layers.
The discomfort that proves it’s working
I learned this the hard way: the first time I did a serious Pre-Mortem on a project I was genuinely excited about, the risk list hit me hard.
Not because the project was bad. But because until that moment, I hadn’t wanted to see those things.
That discomfort is exactly the signal that the exercise is working.
If you do a Pre-Mortem and feel nothing, or the list is short and reassuring, start over. You haven’t been honest yet.
Start this week
You have a project underway or one you want to launch. Right now.
Spend 30 minutes writing this:
«It’s [date six months from now]. The project is dead. What killed it?»
Write without stopping for 15 minutes. Don’t edit. Don’t filter.
Then read what you wrote with the same cold eye you’d use reading someone else’s post-mortem.
What you find there is more valuable than any optimistic roadmap.
And it costs you 30 minutes before you start—not six months after you’ve invested everything.
In the next entries of this series, we continue with more decision-making frameworks. If this format is proving useful, share it with someone who’s about to launch something.
