How would you make the case for a two-sprint refactor to a product manager under delivery pressure?

What is being tested

Whether you can argue technical debt in terms of delivery outcomes rather than in terms of code quality, which is the argument that loses.

What not to say

"The code is messy." "It is not well designed." "We have technical debt." All are true, all are unfalsifiable from the product manager's position, and all lose to a feature with a customer waiting.

The argument that works

1. Attach it to observed delivery data.

"The last four changes in this area took an average of nine days. Comparable changes elsewhere take two. The difference is roughly three weeks of engineering time per quarter, and it is growing."

That is evidence, it is in the currency the product manager cares about, and it is checkable.

2. Attach it to incidents.

"Three of our last five production incidents originated in this component. Each cost roughly a day of engineering plus the customer impact."

3. Express the outcome as capability, not tidiness.

Not "we will refactor the payment module" but "afterwards, adding a payment method takes a day instead of three weeks." That is a roadmap item the product manager can evaluate against their own plans — and it is frequently something they have already wanted.

4. Show the trajectory.

"If we do nothing, this area gets slower. Here is what has happened to change lead time in it over six months." A trend line is far more persuasive than a snapshot.

5. Offer options with costs.

Not a single take-it-or-leave-it proposal. "Two sprints gets us X. One sprint gets us the highest-value half. Doing nothing costs approximately Y per quarter and rising." Product managers make trade-offs for a living; give them one to make.

Two tactics that often work better than a dedicated block

Incremental refactoring inside feature work. Improve the area you are already touching, absorbed into feature estimates. Slower, requires no negotiation, and avoids the argument entirely.

Tie it to an upcoming feature. "The next three roadmap items all touch this component. Doing the refactor first makes them faster in aggregate than doing them without it." This converts the refactor from a cost into a schedule optimisation.

What to concede honestly

Sometimes the answer is no, and correctly so. If the product is unvalidated, if there is a genuine market window, or if the component may be replaced entirely, deferring is right.

The important thing then is to record the decision and its cost, so it is a deliberate, revisitable choice rather than an invisible drift — and so the next conversation starts from evidence rather than from scratch.

What a strong answer adds

Naming the categories where you would refuse to defer: foundations — data models, security boundaries, tenancy, identity — where shortcuts compound and become extremely expensive to change; and debt whose interest is paid in incidents rather than in effort, such as a missing idempotency guarantee, because that cost is unbounded and arrives without warning.