How to Run a Pre-Mortem on a Product Before You Commit Budget

Most products don't fail at launch. They fail much earlier, in the weeks before anyone writes a line of code, when the team is too excited to ask the hard questions. The budget gets approved, the roadmap gets built, and everyone moves fast. Then, six months later, something goes wrong that someone in that early room probably sensed but never said out loud.

A pre-mortem is a way of saying those things before they become expensive. The idea is simple: before you commit, you imagine the product has already failed, and you work backwards to understand why. It's a discipline borrowed from psychology and used well in product strategy, and it works because it gives people permission to be honest at the moment when honesty is hardest to come by.

At We Are Affective, we think about this a lot. So much of what goes wrong in product development is predictable, not because teams are careless, but because the social dynamics of a kickoff meeting make it genuinely difficult to voice doubt. A pre-mortem creates a structured space for that doubt. And doing it before budget is committed, rather than after, is what makes it worth doing at all.

A pre-mortem gives people permission to be honest at the moment when honesty is hardest to come by.

This article walks through how to run one properly, what to look for, and how to turn what you find into a real decision rather than a politely ignored document.

Why Teams Skip the Hard Questions Before Build

The pattern is familiar. A team arrives at the pre-build phase with energy and conviction. The idea has already survived several internal conversations, it's been refined, it's been presented upward, and it's been approved in principle. Asking hard questions at this point feels like moving backwards. It can feel, socially, almost like a betrayal of the shared momentum.

There's also a comfort that comes from the kind of work that doesn't risk contradiction. Mapping competitor features, building slide decks, writing job specs for the engineering team: these activities feel productive and generate no uncomfortable findings. Speaking to real users, or stress-testing the core assumptions of the product, risks surfacing something nobody wants to hear. So teams often skip it, or replace it with something that looks like rigour but isn't.

Underneath this is something psychological. When a team has invested time and identity in an idea, the prospect of research or critical analysis feels threatening rather than useful. The pre-mortem reframes that. It treats the search for failure as a team exercise rather than a personal critique, which makes it much easier for people to participate honestly. The goal is to surface what's already there in people's heads but hasn't yet been said in the room.

The Psychology Behind Pre-Mortem Thinking

The pre-mortem technique was developed by psychologist Gary Klein as a way of countering a well-documented bias called planning fallacy. Planning fallacy describes the human tendency to underestimate how long things will take, how much they will cost, and how many things will go wrong, while overestimating how smoothly a plan will unfold. Teams are particularly vulnerable to this because optimism tends to be socially rewarded in group settings.

What Klein noticed was that asking people to imagine a project has succeeded produces very little new information, because people are already imagining success. But asking them to imagine it has failed, and to explain why, opens up a completely different kind of thinking. It bypasses the social pressure to be positive and activates a more analytical mode where people surface concerns they'd been carrying quietly.

This matters in product development because the risks that sink products are rarely technical. They tend to be human: a user behaviour that the team assumed but never validated, an organisational constraint that nobody wanted to raise, a competitor move that everyone privately feared but collectively dismissed. Pre-mortem thinking gives those risks a legitimate place in the conversation before the product is built, rather than a painful place in the post-launch debrief.

Setting Up Your Pre-Mortem Session

The setup matters as much as the method. A pre-mortem run in the wrong conditions produces polite, sanitised responses that don't surface anything useful. The right conditions are a mix of the right people, the right framing, and the right rules for the room.

On people, you want a cross-functional group that includes someone from design, someone from product, someone from engineering, and ideally someone with a commercial or customer-facing role. The most valuable voices are often from people who sit closest to the end user or to the business reality, not necessarily the most senior people in the room. If the session is dominated by those with the most invested in the idea proceeding, the findings will reflect that.

The most valuable voices are often from people closest to the end user, not the most senior in the room.

On framing, you open by asking the group to set aside two years. The product has launched, the team worked hard, and it has failed. Users didn't adopt it, the business didn't grow, the investment didn't return. Now: why? Each person writes their reasons privately before anyone speaks aloud. This private writing step is not optional. It's what prevents the first voice in the room from shaping every response that follows.

Give participants five minutes of silent individual writing before any group discussion begins. Written responses produced privately are consistently more honest than verbal ones shaped by the room's mood.

On time, ninety minutes is usually enough. Shorter than that and you rush the most uncomfortable parts. Longer and the energy drops before you reach decisions.

Surfacing Hidden Assumptions

The problem beneath the product

One of the most productive questions a pre-mortem can ask is: what does this product assume is true? Every product rests on a set of assumptions about user behaviour, market conditions, and organisational capability. Most of these assumptions are never written down. The pre-mortem is a way of making them visible so they can be tested rather than taken for granted.

A useful structure is to ask the group to list their assumptions across three areas. The first is user behaviour: what are we assuming people will do, feel, or want? The second is market conditions: what are we assuming about the competitive environment, timing, or demand? The third is internal capability: what are we assuming our team, budget, or organisation can actually deliver?

Sorting what you find

Once the assumptions are listed, the group sorts them by two dimensions: how confident are we in this assumption, and how much does the product depend on it being true? Assumptions that score low on confidence and high on dependency are your highest-priority risks. These are the things worth investigating before budget is committed, not after.

• High confidence, low dependency: monitor but don't block on these
• High confidence, high dependency: validate anyway, the stakes are high enough
• Low confidence, low dependency: useful to know but not blocking
• Low confidence, high dependency: investigate before committing budget

Write each assumption on a separate card or sticky note before sorting. Physical separation of ideas tends to produce more honest prioritisation than a shared list where everything competes for attention at once.

The goal is to leave the session with a short list of things that must be true for this product to work, with a clear plan for how to test each one before the full build begins.

Mapping Emotional and Organisational Risk

Technical risk gets plenty of attention in pre-launch planning. Emotional and organisational risk tends to get almost none, and these are often what actually derail a product. A pre-mortem that only looks at feature feasibility misses half the picture.

Emotional risk sits on both sides of the user relationship. On the user side, the question is what emotional state the product is asking users to be in, and whether the design actually supports that state. A product built for anxious users that uses dense information design and no progress indicators will deepen anxiety rather than relieve it. A product built for habitual users that requires too much effort to re-engage will be abandoned. These are not hypothetical failures. They follow directly from misaligned emotional design.

Organisational risk is often political

On the organisational side, the risks are often political. There's frequently a stakeholder who has already decided what the product should be, and who will resist any finding that contradicts that position. This isn't always a senior leader. It's sometimes a product owner, a founder, or someone whose credibility is tied to the current direction. Pre-mortems don't solve this problem automatically, but they create a record of concerns that were raised before build, which changes the dynamic considerably when those concerns prove accurate later.

Ask the group directly: who in this organisation might resist evidence that this product needs to change? What would they need to see to update their view? These questions feel awkward but they surface real risk that polite planning conversations never will.

Turning Findings Into Go or No-Go Decisions

The pre-mortem is only useful if it produces a decision. A session that surfaces real risks and then produces a list of things to monitor is not a pre-mortem, it's a worry log. The findings need to connect directly to what happens next with the budget.

A useful frame here is to separate findings into three categories. The first is proceed: the risks identified are manageable, the key assumptions are testable within the current plan, and the team has a shared view of what success looks like. The second is proceed with conditions: there are one or two high-priority assumptions that need validation before full build begins, and the budget plan should reflect that with a dedicated discovery or prototyping phase. The third is pause: the risks identified are too fundamental to proceed without more information, and committing the full budget now would be premature.

Document the pre-mortem findings and the decision made in the same place your product roadmap lives. If the product later encounters one of the risks that was surfaced, the team needs to be able to see that it was anticipated and understand what the original decision was based on.

The pause category is the hardest to recommend, because teams at this stage have already spent time and energy on the idea. But pausing to gather information is a different decision from stopping. It's choosing to spend a smaller amount now to reduce the risk of spending a much larger amount later on something that doesn't work. Research conducted before development begins always costs less than the same findings surfaced after launch.

Conclusion

The pre-mortem is not a pessimistic exercise. It's what serious teams do when they care enough about a product to test it before they build it. The goal is a clearer decision, made with better information, by a team that has had an honest conversation rather than a politely optimistic one.

What makes it worth doing is the timing. Once budget is committed and the build has begun, the social and financial cost of changing course rises sharply. People have booked time, hired contractors, told stakeholders what's coming. Raising a fundamental concern at that point takes a different kind of courage. Raising it before the commitment is made is just good practice.

The questions that surface in a well-run pre-mortem (the hidden assumptions, the emotional risks, the organisational tensions) are questions the team was already carrying. The pre-mortem just gives them a time and a place to be said out loud, in a room where saying them is the job rather than an interruption to it.

If you're preparing to commit budget to a product and want to stress-test your thinking before you do, we'd be glad to help you work through it. Let's talk about your product strategy and make sure the hard questions are asked while they're still cheap to answer.