How Do You Run a Postmortem on a Launch That Missed?

How do you run a postmortem on a launch that underperformed?

Borrow the engineering version. Define in advance what counts as underperformance, write a document rather than hold a meeting, focus on contributing causes instead of people, and end with owned follow up actions. Marketing teams rarely do any of this, which is why the same launch failures repeat.

The best writing on postmortems comes from reliability engineering, not marketing. That discipline has been doing this rigorously for years because the cost of not learning was measured in outages.

The practice transfers almost unchanged. A launch that missed is an incident with a longer timeline.

Why do launch retros usually fail?

Because they are meetings rather than documents, and because they happen weeks too late. By six weeks after a launch, everyone involved has built a private explanation of what went wrong, and the meeting becomes a negotiation between those competing explanations rather than an honest investigation of the evidence.

They also fail because nobody agreed what success was. If the target was never written down, the retro turns into an argument about whether the launch actually underperformed, and that argument consumes the whole session.

The third reason is more human. A retro where someone might be blamed produces careful, defensive, useless contributions. People will not say the pricing page was confusing if the person who wrote it is in the room waiting to be judged.

What does a blameless postmortem actually mean?

Something more specific than being nice. Google's Site Reliability Engineering material defines it clearly, saying that "For a postmortem to be truly blameless, it must focus on identifying the contributing causes of the incident without indicting any individual or team for bad or inappropriate behavior."

The second half of that definition is the operative part. It states that "A blamelessly written postmortem assumes that everyone involved in an incident had good intentions and did the right thing with the information they had."

Applied to a launch, that assumption changes every question. Instead of asking why did marketing not know the release date slipped, you ask what would have had to be true for marketing to know. The first question finds a person. The second finds a missing process.

When should you trigger one?

On criteria you set before the launch, so nobody has to argue about whether this one qualifies. The SRE guidance is that you establish the criteria beforehand so "everyone knows when a postmortem is necessary," and that principle matters more in marketing than in engineering because the signals are fuzzier.

Write the triggers into the launch plan. Signups below a stated number in the first month. Pipeline below a figure. A press push that generated no coverage. A feature launch where adoption stayed under a percentage of eligible accounts.

Keep the escape hatch that engineering uses. The SRE material notes that beyond objective triggers, "any stakeholder may request a postmortem for an event." Somebody who felt the launch went badly should be able to ask for one without having to prove it first.

What goes in the document?

The same structure the engineering version uses, with marketing substituted for the incident. Google's definition is that a postmortem is "a written record of an incident, its impact, the actions taken to mitigate or resolve it, the root cause(s), and the follow-up actions to prevent the incident from recurring."

Section	What it holds for a launch
Target	The number agreed before launch, and where it came from
Actual	What happened, by channel, over a stated period
Timeline	Dates of every decision and change, including slips
Contributing causes	Everything that made the outcome more likely
What we tried	Mid flight changes and whether they helped
Actions	Owned, dated changes to the process
What went well	The parts to keep, named explicitly

The timeline is the section people skip and the one that does the work. Most launch failures are visible in the dates, usually as a compression at the end where three weeks of preparation became four days.

How do you find a cause rather than a culprit?

Keep asking what made that possible until the answers stop being about people. The launch email went out late is not a cause. Nobody owned the email is closer. The launch plan had no single owner for outbound comms is a cause you can fix.

Expect several. Launches rarely fail for one reason, and the phrase contributing causes is deliberately plural. A weak positioning statement, a slipped release date and a competitor announcement in the same week compound into something none of them would have caused alone.

Watch for the cause that is really a target problem. Quite often the launch performed normally and the forecast was invented, in which case the fix belongs in how you set targets rather than how you execute. Our notes on sizing launches into tiers cover that calibration.

How do you know the launch actually underperformed?

By comparing the result against a number registered before launch, rather than against how it felt. This is where marketing postmortems are structurally weaker than engineering ones, because an outage is unambiguous and measurable while a launch that landed softly is neither of those things.

Attribution makes it harder still. A launch that produced pipeline three months later looks like a failure at week four, so the measurement window has to be set in advance and honoured. Judging a launch early is its own kind of error.

Be willing to conclude that it went fine. A postmortem that finds no significant problem is a valid outcome and worth recording, because it stops the team relitigating the launch for the next year. Our notes on B2B attribution cover the measurement traps.

What makes the follow up actions stick?

An owner, a date and a place they live where work actually happens. Actions that sit in the postmortem document get read once. Actions that land in the same tracker as everything else, whether that is Linear, Jira or a Notion board, get done.

Limit them. Three actions with owners beat eleven aspirations, and a postmortem that generates a dozen items has usually not finished thinking about which cause mattered most.

Make at least one of them a change to a template or checklist rather than a behaviour. Behaviours decay when people move roles. A launch checklist that now includes the missing step survives them. That is why we keep one, as described in our launch checklist for websites.

Who should be in the room?

Everyone who made a decision, and nobody who is only there to watch. In practice that means product marketing, the person who owned the release date, whoever ran demand generation for the launch, and at least one person from sales who actually spoke to buyers during the launch window.

Sales presence is the one most often missing and most valuable. They heard the actual objections in real time, which is information no dashboard holds.

Keep the most senior person quiet for the first half. A blameless postmortem stops being blameless the moment the person who approves budgets starts asking pointed questions, however reasonably meant.

How do you make this a habit rather than a punishment?

Run them after good launches too, and make writing them visibly valued. The SRE guidance is explicit on this, advising teams to "Make sure that writing effective postmortems is a rewarded and celebrated practice, both publicly through the social methods mentioned earlier, and through individual and team performance management."

That is the part most companies get wrong. If a postmortem only ever happens after a failure, the document itself becomes evidence of failure, and people will quietly avoid triggering one.

Publish them internally where other teams can read them. The compounding value is not in fixing one launch, it is in the fourth launch going better because someone read what happened on the second.

If you want help setting the triggers and targets before your next launch so a postmortem is actually possible afterwards, we are happy to think it through with you. You can find us at phoenix.studio.