The product manager wants to ship with a bug you think is serious. How do you handle it?

First I check that we actually disagree about the risk, not about the words. Often “Major” means something different to me and to the PM.

1. Translate the bug into impact

Not “the sync has a race condition”, but “if a user edits a note on two devices within a few seconds, one edit is lost without warning. Our heaviest users do this every day, and lost data creates support tickets and churn.”

I add what I know about how many users, how often, and whether there’s a workaround, and I’m honest about what I don’t know.

2. Offer options, not just “no”

• Ship with the feature behind a feature flag, off for everyone or on for a small group.
• Staged rollout with a clear rule to halt it.
• Ship but disable the specific path (for example, turn off multi-device editing for now).
• Delay by one or two days for a targeted fix and a focused retest.

3. If the PM still decides to ship, make the risk acceptance explicit

• Record it on the ticket: the risk, who accepted it, and the reason.
• Add it to the known issues for the support team and, if needed, the release notes.
• Agree on monitoring (crash rate, error logs, support tickets for that flow) and a trigger: “If we see more than a handful of reports in 48 hours, we roll back or hotfix.”
• Schedule the fix.

4. Escalate only when it’s justified

For security holes, data loss, legal or payment issues, I escalate to engineering or product leadership, calmly and with evidence, and I tell the PM I’m doing it. For anything less, I accept that the business can take risks I wouldn’t have taken.

Learn more: Severity vs Priority