AI Knowledge Hub

How should Product and Engineering decide which technical debt to address?

Quick answer

Choose technical debt work by making its effect on delivery, reliability, risk or operating cost visible, then comparing the cost of leaving it with the cost and timing of change. Engineering diagnoses the mechanism and options; Product weighs the customer and investment consequence. Address urgent safety or service risks promptly, and sequence other items where they unblock valuable work or reduce repeated friction.

What to remember

Key takeaways

Describe a specific constraint instead of using debt as a catch-all label.
Use observed rework, incidents or change delay where available.
Compare bounded remediation options with doing nothing for now.
Revisit the decision as product direction and system evidence change.

A backlog labelled technical debt can become a collection of old complaints. Meanwhile, real design constraints quietly slow each Feature or increase service risk. Product needs to understand the consequence; Engineering needs space to explain the mechanism and remedy. A shared decision makes technical investment visible without reducing it to a fixed percentage of time.

Identify the debt and its effect

Technical debt is a useful metaphor when a design or implementation choice raises the cost or risk of future work. It is not a label for every defect or disliked technology. Martin Fowler's discussion describes how internal quality problems can slow later change; his quadrant shows that the origins of such problems vary. Engineering should name the affected component, the mechanism and the work it impedes. Product should ask which outcomes or commitments are exposed.

Use current evidence to understand the cost

Look at repeated change effort, defects, incidents, build failures, dependency delay, support work and specialist bottlenecks. A single bad week may mislead; gather enough context to see whether the cost recurs. Some debt is a deliberate temporary trade-off with a known repayment trigger; other debt emerges as requirements and technology change. Do not invent a monetary value where data cannot support one. State the uncertainty and compare it with the likely cost of delaying action.

Choose a proportionate intervention

Engineering can propose several routes: contain a risky interface, add tests around a fragile area, refactor while changing a Feature, replace a component or defer with a monitoring trigger. Product considers which route best supports current priorities and which customer value is delayed. Security and reliability risks may require immediate escalation outside normal ranking. A large rewrite needs stronger evidence than a small fix. GOV.UK prioritisation guidance supports using performance evidence and user insight rather than ordering work by assertion.

Keep the decision visible after the change

Record the choice, owner, expected effect, cost and review date. If work is deferred, name what would trigger reconsideration. After remediation, inspect whether change effort or service risk actually improved. Avoid claiming productivity from a cleaner codebase alone. AI can help map dependencies or suggest refactors, but Engineering must validate the analysis and the changed system. Generated code can itself add maintenance burden if accepted without review.

Example

Hypothetically, a retail product team finds that every pricing change requires manual regression across three services. Engineering traces the coupling and proposes a small contract boundary with focused tests. Product compares that work with a seasonal promotion and agrees to make the boundary change before the next pricing Feature. The team later checks whether regression effort and failures have changed.

FAQs

Should teams reserve a fixed share of capacity for debt?

A standing allowance can help planning, but its size should reflect observed demand and material risk rather than a universal rule.
Is an old technology automatically technical debt?

No. The relevant question is whether it causes meaningful cost, risk or difficulty in current or foreseeable work.
Who decides when debt is urgent?

Engineering identifies technical consequence; Product weighs investment effects, with relevant risk owners involved for material security or service exposure.