Tech Debt Negotiation

Why Product Doesn't Care (And How to Change That)

Product managers are measured on shipping features. When you say "we need to refactor the payment service," what they hear is "engineers want to spend two weeks on something with zero user impact." You have to change how you frame the conversation.

Speaking the Business Language of Tech Debt

Instead of "the codebase has high coupling," try: "Changing the pricing logic means touching 14 files across 3 services, which is why the simple pricing tier change took 3 sprints instead of 1." Instead of "we need to upgrade the framework," say: "We're on a version with known security vulnerabilities, and our next compliance audit is going to flag this as a critical finding."

Every piece of tech debt should map to one of these business metrics: velocity impact (how much slower are we), risk exposure (what's the blast radius when something fails), cost (how much are we spending on workarounds), or opportunity cost (what could we be building instead if this wasn't in the way).

The 20% Rule

Don't try to negotiate large blocks of time for tech debt. Instead, get a standing agreement: 20% of sprint capacity goes to engineering-prioritized work. This isn't a radical idea. Google's 20% time is well known, and most healthy engineering orgs operate this way. The important part is that engineering decides what goes into that 20%, not product. It saves you from having to justify every single cleanup task.

The Debt Register

Keep a shared spreadsheet or Jira board with every significant piece of tech debt you know about. For each item, track: a plain-English description, the business impact, estimated effort to fix, risk level (low/medium/high/critical), and an owner. Review this register monthly with product leadership. When an incident happens because of known tech debt, update the register right away. Nothing builds urgency like a trail of outages that could have been prevented.

Showing Results

After every debt paydown effort, publish a short before-and-after summary. "We spent 8 engineering days refactoring the notification pipeline. Deploy time dropped from 45 minutes to 12 minutes. That saves roughly 6 engineer-hours per week, which means the investment pays for itself in 3 weeks." Those receipts are what earn you credibility for the next time you ask.