Value Over Vanity: Reframing Tech Debt to Get It Prioritised
Product managers face a constant tension: technical debt competes with feature development for finite engineering time. The choice often feels binary—fix crumbling foundations or stall visible progress.
There’s a better way to think about this.
Where Tech Debt Comes From
Technical debt accumulates from two primary sources:
- Outdated implementation decisions — Made for speed or cost at the time, now showing their age
- Technology requiring upgrades — Dependencies, frameworks, and infrastructure that need updating
Both stem from earlier trade-off decisions. They were probably the right call at the time.
The Reframe
Stop framing this as “tech debt versus product value.” Instead, think “value versus value.”
This levels the playing field. Technical work delivers value too—you just need to quantify it.
Practical Examples
Instead of: “We need to remove hardcoded values”
Try: “Adding dynamic configuration increases development speed, saving 2+ hours per ticket. That’s potentially 100 hours annually per developer.”
This highlights developer experience improvements that affect team retention and business outcomes.
Instead of: “We need to upgrade this service”
Try: “Upgrading this service prevents exposure to known vulnerabilities and protects customer data, reducing reputational and financial risk.”
Link improvements to risk mitigation in terms stakeholders understand.
Make It Concrete
Document technical improvements as user stories with explicit value statements:
“As a developer, I want dynamically updated configuration values so we don’t manually update them during releases.”
This makes the benefit tangible and comparable to feature work.
One Backlog
Abandon separate feature and technical debt backlogs. Maintain a single backlog where all work competes based on demonstrable value.
When technical work is framed as value delivery—not maintenance overhead—it gets prioritised alongside everything else.