4 Ways To Reduce Technical Debt In Product Management

As a Product Manager, you shouldn't just offload the issue of "technical debt" to the engineering team to figure out.

Unless Product Managers attempt to understand it, the debt will return - often, with a vengeance.

‍

What's technical debt?

Imagine you receive an IKEA dinner table an hour before your guests show up.

Instead of screwing it up as per the manual, you choose to take a hasty shortcut and set the table up with a combination of tape, glue and hammered nails.

The table stands upright but it's rickety. It can't support the full advertised weight due to the sub-optimal assembly. You can't place add-on accessories either because the table has an unstable base & slants at an angle. It does the job but that's about it.

To fix this for future parties with larger turnouts, you'll have to rip out the adhesives, strip down a few parts and re-assemble a lot of the sub-components.

This pending rework = technical debt.

And that starts to bite when your friends start to wonder why you aren't inviting them for your famous dinner parties.

How should Product Managers approach it?

Unpack it

The worst thing you can do is to turn away from it because you think you're unlikely to understand it. Some PMs think awarding the devs some sprint bandwidth will make the issue go away. That's a poor approach.

Get in there. Put a label on it.

Ex: Is it a database structure issue? Do we have an unwieldy search framework? Did we hardcode aspects that needed to be parameterized? Help in prioritization.

Size the debt footprint

How closely is the problem hooked to other modules? Are we even working on that module in the future weeks?

Ex: A poor implementation of global notifications might affect a lot of areas.

Ask why are we fixing it now? What happens if we don't fix it? What's the opportunity cost?

If "debt" resides in a feature that's lies cleanly outside your near-term strategic focus, you may not need to prioritize it.

Super important: What's causing the debt to crop up?

Based on historical evidence, what approach could you take to avoid debt in the first place? Sure, we're taking shortcuts, but how much incremental effort was the "right way"? Could we have just bought that extra time to get ahead?

Ex: If we had made a report's timeframe controls configurable (as opposed to hardcoded), how much additional effort was that really? 2 days? 1 more sprint?

Was debt a conscious decision or accidental?

Was this issue created because devs consciously chose the shortcut to save time OR the requirements weren't clear? Was it because you as a PM didn't clarify how a feature was going to evolve over time and the architecture was prematurely designed?

Ex: if you didn't mention that prices on your e-commerce marketplace will support currency conversion in the future, then architects might lean towards a short-sighted solution. In this case, the debt is attributable to you as a PM.