Postmortems as Product Input

PMs surface product issues. Use them.

Identify product issues

Postmortems regularly surface product issues, not just engineering ones. Confusing UI driving wrong actions, missing features driving manual workarounds, performance issues with legitimate use cases. Each looks like an engineering finding on the surface but really points at the product.

• Confusing UI led to wrong action. Often labelled "user error" but really UI ambiguity. Product fix, not engineering blame.
• Missing feature drove manual workarounds. Gap-in-product signal. Customers improvising drives risky paths and surface area engineering does not control.
• Performance issue with valid use case. Legitimate-but-slow scenario. Implies an unrecognised product requirement, not just an optimisation.
• Product-impact tag per postmortem. Explicit "has product implications" flag. Catches missed product feedback before it disappears into the engineering archive.

File product tickets

The PM-derived ticket is the bridge to product work. Filed during the postmortem so context is fresh; reviewed at product cadence so it competes for prioritisation alongside everything else product is weighing.

• One ticket per implication. Each implication gets its own ticket. Trackable independently rather than buried under "follow up on incident X."
• Weekly product-side triage. Tickets reviewed alongside other product work. Drives real prioritisation, not a separate "incident-derived" backlog that nobody reads.
• Postmortem link per ticket. Source-incident reference on every ticket. Supports product-side context six months later.
• Customer-impact summary per ticket. Documented incident pain in product terms. Supports prioritisation conversations with non-engineers.

Close the loop

Closing the loop is what makes the discipline pay back. Product ships fixes; future incidents in the same shape get rarer; the closed-loop report makes the case for keeping the practice. Six-month follow-up audit catches the fixes that did not actually resolve the underlying issue.

• Product ships fixes. Quarterly count of shipped product changes from postmortems. Reduces future incidents in the same shape.
• Compounds over time. Cumulative reduction year over year. Product gets better as incidents get rarer.
• Quarterly closed-loop report. Postmortem-to-product shipped tally. Supports the business case for keeping the discipline.
• Six-month follow-up audit. Per-postmortem check on whether the issue recurred. Catches incomplete fixes before they recur in production.