As a non-technical product manager, you may feel like an imposter when it comes to technical conversations simply because you don’t know how much you are expected to know! Technical debt is one of those intimidating topics, but this post should help you tackle it better.

What is technical debt?

First things first, technical debt is the cost of maintaining and improving software that could be cleaner or more organised. It can come from various sources such as shortcuts taken during development, not properly refactoring code, or using tools and libraries that aren’t well-suited for the task at hand. It’s like financial debt, where you borrow money now and pay for it later. In software development, technical debt is when a team takes shortcuts or makes decisions that may save time or money in the short term but will cost more to fix or maintain in the long term.

Now, don’t get me wrong, technical debt isn’t always a bad thing! It can be used as a strategic tool to balance short-term needs with long-term goals. The key is to make sure it’s managed and controlled, so it doesn’t become a burden on the organisation.

How to handle technical debt as a non-tech product manager?

As a non-technical product manager, when it comes to prioritising technical debt items, don’t stress! You don’t need to know every technical aspect, just use the same prioritisation framework you use for planning product features. And if you’re unsure of the importance of a technical debt item, just ask the engineering team to explain it to you. 

In my experience, engineers are really passionate about the tech debt items that might have impacted there work recently and might be biased to get rid of these items first. However, you need to guide an objective discussion when arriving at the importance and priority of the different technical debt items. One powerful, yet simple question that helps me here is:

“What happens if we don’t do it?”

Here are some common tech debt items, categorised by business criticality to help get you started:

Technical Debt Items categorised by business impact

Highest Business Impact

• Performance Issues: This can be a result of one or many reasons like inefficient algorithms, poor data structures, lack of concurrency support, memory leaks, lack of caching, etc.
• Security Vulnerabilities: I would recommend giving a quick read on the OWASP Top 10. OWASP top 10 is a standard awareness document for developers and web application security. It represents a broad consensus about the most critical security risks to web applications.
• Usability issues: Some features might not work properly for some or all of the users because of technical debt. e.g. Use of an old library might result in issues for customers on a browser that no longer supports the protocols used in the older library.

Moderate Business Impact

• Code Refactoring: Think of your codebase like a house. When you first start, it’s empty and you can furnish it however you want. It’s organized, with just the things you need and it looks great! But as time goes on, more people move in, your tastes change, and you add more things. Before you know it, it’s cluttered and disorganized. That’s where code refactoring comes in – just like how you need to continuously do housekeeping to keep your house in order, you also need to refactor your code to keep it usable and efficient.
• Documentation Updates: Without proper documentation, it takes a long time for new or even existing developers to understand the existing code sections when they want to build on top of it.
• Test Coverage: A healthy test coverage allows faster delivery of error and bug free features. If the test coverage is not kept in check, then it might grow to such an extent that it might become impossible to fully test a new piece of code resulting in bugs frequently making their way into production systems

Low Business Impact

• Code Cleanup
• Naming Conventions
• Comments
• Etc

Closing Note

I will end this post with 2 key takeaways for you:

• Don’t be too hard on yourself, technical debt is a topic that even experienced engineers need time and research to figure out
• Don’t be afraid to ask the question: “What happens if we don’t do it?”