The Report You Write Before You Write a Single Line of Code

We’ve all been in that meeting. The one six weeks after launch where the dashboard is stubbornly red. A senior leader leans back in her chair, looks you in the eye, and asks, “Did we ever consider that our main competitor might launch a similar feature a week before us?”

You did. Of course, you did. You mentioned it in a planning meeting. It’s buried in a Slack thread somewhere. But you never wrote it down with the gravity it deserved. You never forced the hard conversation. So you nod, feeling the heat rise in your face, and say, “It was a known risk.”

The problem wasn’t a lack of foresight. The problem was a lack of the right artifact. We spend weeks on Product Requirement Documents that describe a happy path to success. We need to spend a few hours on a document that maps out the most likely paths to failure.

Before your team writes a line of code, you need to write the Pre-Mortem Brief.

This Isn’t a PRD, It’s a Premonition

A PRD sells the vision. It details the user stories, the acceptance criteria, and the beautiful future state. It’s optimistic by nature.

A Pre-Mortem Brief is a dose of strategic pessimism. It’s a one-page document that imagines the project has already failed spectacularly and asks: “What went wrong?” It’s not about killing ideas; it’s about pressure-testing them so they don’t die from predictable causes later.

This brief forces you and your team to confront uncomfortable truths when the stakes are low—just words on a page, not thousands of lines of committed code.

The Four Questions Your Pre-Mortem Brief Must Answer

Make this document simple. Forcing clarity is the entire point. It should directly answer these four questions.

1. If this project fails, what is the single most likely reason? Don’t list ten things. Pick one. Force yourself to name the monster under the bed. Is it a technical dependency on a flaky API? Is it a user behavior assumption that feels more like a prayer? Is it that the sales team has no real incentive to sell it? Write it down. This singular focus elevates your primary risk from a bullet point on a slide to the team’s shared obsession.

2. Which stakeholder’s silence worries you the most? Every project has a Quiet Stakeholder. It might be the head of legal, the lead for data science, or a key engineer on a dependent team. They attend the meetings, nod along, but offer no strong opinions. Their silence is not agreement. It’s often a sign of unvoiced concerns or a lack of buy-in. Naming this person in your brief is a forcing function to go have a direct, one-on-one conversation and turn their silence into explicit support or constructive criticism.

3. What market event would instantly kill this project? Get out of your own building. What could a competitor do? What new technology could emerge? What privacy regulation could pass that would render your entire approach obsolete? This question pushes you beyond internal execution risk. If your project is so fragile that a single press release from your rival can destroy it, you need to know that now, not after you’ve launched.

4. What is our "off-ramp" criteria? Success metrics are easy. What are the failure metrics? Define the clear, quantifiable signals that would tell you to stop. For example: "If we can't get the core algorithm's error rate below 5% in the first two sprints, we will pause and re-evaluate." Or, "If user testing with three separate prototypes shows a task completion rate under 60%, we will kill the project." This