How do you handle a disagreement with a PM about scope vs quality?

#Don't Fight About Values, Fight About Definitions

Most scope-versus-quality arguments are actually definition arguments wearing a disagreement's clothing. A PM often means "quality" as polish — a nicer animation, a rare edge case, an empty state that could look better. An engineer often means "quality" as reliability — crash-free sessions, data correctness, nothing silently failing. The first move, before anyone digs in, is getting explicit about which flavor of quality is actually under discussion, because the two blend together in conversation and almost never in reality.

#Sort Into Non-Negotiable and Negotiable, Out Loud

I keep a short, genuinely short list of things that don't move regardless of the date: crash-free sessions, data loss or corruption, security, accessibility compliance where there's legal exposure, and correctness in anything touching money. Everything else — visual polish, uncommon edge cases, a nice-to-have empty state — is negotiable and can ship as a fast follow. Naming this list out loud to a PM, instead of treating every quality concern as equally sacred, is itself the credibility move: it tells them you're not going to fight them on everything, which makes the things you do hold firm on land harder.

#Bring Data, Not Adjectives

"This doesn't feel done" loses every negotiation. "This hits three percent of transactions in the market we're expanding into next quarter" wins most of them. A PM once wanted to ship a payment retry flow without handling a specific network-timeout edge case because it was "rare" — pulling analytics from the beta showed that exact timeout condition affecting roughly three percent of transactions in a market with spotty connectivity that the company was actively expanding into. That single number turned "rare" into a revenue line, and turned the conversation from a feelings disagreement into a shared read of the same spreadsheet.

#Offer Options, Never Just a Veto

Never show up with only "no." Come with two or three real options, each with its scope, quality, and date tradeoffs made explicit: ship the full scope late, ship a reduced scope on the original date with the risky edge case gated behind a flag, or ship on date accepting a named, bounded risk with a fast-follow patch already scheduled and on someone's calendar. That turns you into someone solving the PM's problem alongside them instead of someone standing in front of their date.

#Escalate the Tradeoff, Not the Person

When agreement genuinely doesn't happen, escalate the decision itself — with your recommendation attached — to whoever owns the release call, rather than escalating a complaint about the PM. The framing that works: "here are the three options, here's the risk of each, here's what I'd choose, I want this decision made on the record by whoever owns it." That keeps the relationship with the PM intact for the next disagreement, which there will be one.

#Know Where Your Own Line Actually Is

Sometimes the decision sits inside your own authority as the engineer accountable for the system, and a crash in a payment path isn't something to negotiate away. Be ready to say plainly, "I won't sign off on this shipping in this state," and explain the specific risk in one sentence — while still acknowledging that the deadline pressure is a real constraint you're not dismissing, just one that doesn't override this particular line.