What Is Technical Debt in Product Management?

When you’re just getting started in Product Management, there’s a mind-boggling amount of new terms and theories to come to grips with, especially if you’ve never worked in the tech industry before.

If you’ve come from an engineering background, you’re already very familiar with today’s topic: technical debt. But if you’ve come from any of the other myriad backgrounds Product Managers can come from, you might be scratching your head.

That’s what we’re here for! To break it down and make it easy, today we’re lifting the lid on technical debt.

The Basics: What Does ‘Technical Debt’ Mean?

Technical debt (known colloquially as tech debt, code debt, or design debt) describes a situation when code quality is sacrificed in exchange for a speedier delivery. Development teams will take steps to push out a new feature because it’s more important to deliver it quickly than perfectly. The expectation is that there will be time to fix the code or release an update later.

The tech debt metaphor is essentially shorthand for “release now, fix later.”

To the uninitiated, this looks like a terrible idea. Why on Earth would you ever want to compromise software quality for a speedier release?! Doesn’t that sound like a recipe for disaster? But it’s a strategic decision when time is of the essence. It doesn’t mean ‘always ship bad code in the interest of speed.’ It's just a reality of the real world—sometimes done is better than perfect.

The debt metaphor was first coined by Ward Cunningham, one of the authors of the Agile Manifesto. In 1992 Ward said;

““Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with refactoring. The danger occurs when the debt is not repaid. Every minute spent on code that is not quite right for the programming task of the moment counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unfactored implementation, object-oriented or otherwise.””

He later went on to say;

““When taking short cuts and delivering code that is not quite right for the programming task of the moment, a development team incurs Technical Debt. This debt decreases productivity. This loss of productivity is the interest of the Technical Debt.””

Ward has explained his debt metaphor in a few different ways over the years, the best of which you can see right here.

Technical debt doesn’t just refer to deliberate tech debt but also to accidental and bit rot tech debt, which we’ll go into in more detail. These types of debt aren’t planned, but they are often part and parcel of product development and something which Product Managers need to take into account.

Different Types of Technical Debt

There are three main types of tech debt that you’ll likely encounter in your Product Management career.

Deliberate tech debt

Dag Liodden, CTO of Tapad, described deliberate tech debt perfectly in his talk for FirstMark. He says that engineers know the right way to do things and the quick way to do things. “We sometimes deliberately incur tech debt to reduce time to market.”

Accidental tech/design debt

Tech debt isn’t always a deliberate decision. It can be a by-product of evolving technology and changes in requirements.

Business goals may shift, a competitor may innovate in the same space as you, or new data may challenge your assumptions. There are a number of scenarios that could render a feature you’ve been working on as redundant.

Accidental tech debt often occurs from situations that are out of your control. What matters more is how you respond to them.

Bit rot tech debt

Bit rot tech debt is the one you should try to avoid the most. According to Wired it happens when “a component or system slowly devolves into unnecessary complexity through lots of incremental changes, often exacerbated when worked upon by several people who might not fully understand the original design.”

This is what happens when you have ‘too many cooks in the kitchen.’ When individual developers work on the product without coming together to look at the big picture, sometimes the individual contributions don’t quite fit together.

Technical Debt for Product Managers

Managing technical debt is a key part of a Product Manager’s job, and there are a few things that great PMs do to properly manage tech debt, no matter which of the above categories it fits into.

Realize that it’s normal. Sometimes it feels like it’s following you around like a bad smell. The key is not to run from it but to realize that it’s all just part of building products!

It doesn’t do any good for the morale of you or your team if you walk around feeling like the team has failed because you’ve got a backlog of tech debt. As long as it’s not excessive, and you’ve got a plan to properly manage it, there’s nothing wrong or abnormal with tech debt.

Set benchmarks and keep track. The key to properly managing tech debt is to make sure you’re keeping a proper eye on it. That means setting soft deadlines on what needs to be caught up on and when. This also involves planning ahead and understanding that you’ll need to allow your developers some time to go back over completed work and clean up bad code or make updates in line with evolving tech/requirements.

This is why having a collaborative and adaptable roadmap early on in development is so important.

By making sure you keep your deliberate tech debt properly tracked whilst simultaneously understanding that accidental tech debt is inevitable and will need to be addressed, you keep your development team accountable and

Keep communication open and useful. It’s easy to label what you’re up to as ‘working through the tech debt’, but that doesn’t accurately convey what you and your teams are working on. Also, the word ‘debt’ has negative connotations and won’t make sense to your less-technical stakeholders.

Try to communicate what problem your teams are working on, how they’re fixing it, and why it’ll make the end product better.