The Post-Mortem No PM Wants to Give

It happened on a Thursday. A payment failure bug had been sitting in the backlog for three weeks, marked P3 by a QA engineer who noted it only happened “sometimes on mobile.” By the time someone connected it to a 14% drop in checkout completions, three sprints had gone by. The post-mortem was scheduled for the following Monday.

Every PM in a room of engineers, a head of product, and a CEO asking one question: “Why didn't we catch this?”

The honest answer — “we trusted the reporter's priority label” — is also the most damaging one you can give.

The Real Cost of a Missed Critical Bug

When a critical bug slips through triage, the immediate cost is visible: revenue lost, users churned, engineering time spent on an emergency fix. But the secondary cost is the one that lingers.

You lose credibility as the person responsible for deciding what gets fixed.

The question at the post-mortem is never really about the bug. It's about whether your process can be trusted — whether the next critical issue will also sit in the backlog for three weeks while the team ships CSS tweaks.

That question doesn't go away after one post-mortem. It follows you into every sprint planning meeting. Every time you deprioritise something, someone in the room is wondering whether you missed another one.

Why Bugs Get Mislabelled in the First Place

The payment bug was filed by a QA engineer who genuinely believed it was intermittent and low-impact. They weren't wrong based on what they saw. They just didn't have the full picture: which user segment was affected, which device share represented “sometimes on mobile,” which flow the bug lived in.

This is the structural problem with reporter-assigned priority. The person filing the bug has the narrowest view of it. They can describe the symptom accurately. They cannot accurately judge the business consequence.

By the time the bug reaches your backlog, its priority label reflects the perspective and incentives of whoever filed it — not the actual risk to your product.

What “Defensible” Triage Actually Means

A defensible prioritisation decision is one where, if someone asks you why you made it, you have a documented answer that doesn't start with “I felt like” or “the reporter said.”

It means being able to say:

That sentence does three things. It shows your reasoning was grounded in product context, not gut feel. It creates a paper trail if the decision is later questioned. And it surfaces the gap: if the bug description was missing the information that would have changed the verdict, that's a process failure in how bugs are filed — not a triage failure.

Defensible triage isn't about being right every time. It's about being able to show your work — so that when something does slip through, the conversation is about improving the system, not about whether you can be trusted.

The Conversation That Changes Everything

There are two versions of the post-mortem conversation.

Version B doesn't require the AI to have been right. It requires the AI to have had a documented reason — one that shows the decision was made on available information, not on someone's intuition.

Building a Triage Process You Can Stand Behind

What You Want to Be Able to Say Next Monday

The post-mortem you want to give is one where the question “why didn't we catch this?” has a complete answer. Not “we didn't know,” but: “the description didn't include the checkout context — here's how we change the filing process to surface that next time.”

That answer is only possible if your triage decisions are documented. Every verdict written down, every rationale saved, every override noted. Not because you're covering yourself — but because that documentation is what lets you improve the system instead of relitigating who was responsible.

The goal isn't a perfect backlog. It's a defensible one.