What is Tech Debt and How Do you Handle it a Product Manager?
Mar 30, 2023
Q: My dev team and I disagree on the choice of third-party video editor to adopt for a new feature we’re building. The [video platform] I prefer clearly has better features, but the dev team is adamantly against it because the technical implementation required would “incur future tech debt”. I’ve heard tech debt over and over again as a reason not to do something and I’m wondering if you have tips on the right way to think about it as a non-technical founder/acting PM? — Asked by CEO (Acting PM) @ Seed startup
Hey CEO @ Seed startup,
I get why it’s hard to wrap your head around technical debt and how it affects product decisions and timelines. But as you correctly concluded, tech debt isn’t something to take lightly as it could really sink your product in the long term hence the pushback from your dev team. This is why as a PM and CEO, it’s an important part of your technical education to know how to think about tech debt as an important consideration for product decisions.
Technical debt in a nutshell
Technical debt (or tech debt for short) refers to an accumulation of work that builds up when software quality is sacrificed in exchange for quicker delivery of a feature or product. This means implementing the quicker short-term solution instead of the more optimal solution because it’s more complex and/or labor-intensive.
I’ll give you a quick example: It’s best practice to write a unit test for every line of business logic code. However, writing unit tests for every line of code can add weeks onto the release cycle. In order to prioritize a faster release time, developers release code without proper testing. Bugs are released alongside the feature since business logic was not tested properly. These bugs then cause other unforeseen issues.
The expectation is there will be time and resources later to go back and build things the right way. But as you can see from the above example, tech debt often accumulates to the point that it becomes difficult to keep up with and inevitably completely prevents or slows down the ability to build new features.
A good analogy for tech debt is trying to build new walls and windows into a house with a sinking foundation and a precarious structure. Even if it’s possible to add in new windows and walls, it’s probably not a good idea and will only lead to issues in the future.
Here’s a funny meme that captures this analogy pretty well:
Preventing, Managing, and Fixing Technical Debt as a Product Manager
Technical debt is one of those pesky things that just comes with the territory of building software. No matter how much you try, some degree of tech debt will sneak its way into software. Ultimately it’s up to your development team to fix most tech debt but as a product manager you can also take some control over ensuring technical debt doesn’t bog down your product and team.
Managing technical debt ultimately comes down to 3 things:
- Preventing it
- Managing it
- Fixing it
As a product manager you have a role in all three and here’s how:
[Prevent] Factor in technical debt when making product decisions
The best way to manage tech debt is to be proactive about preventing it from happening in the first place. This means being mindful about the technical implications of product decisions by including engineering early on and throughout the product lifecycle.
During my time as a dev at Amazon working with product managers, my PM would set up 1:1 meetings as soon as she start ideating on possible solutions to a problem or a new feature. She’d come prepared with a document with the problem we’re trying to solve and possible solution(s)/features she’s considering. We’d then discuss the technical implications of each solution and we’d each bring our different perspectives to come up with alternative solutions that are easier and faster to implement and contribute to less technical debt.
These 1:1 meetings throughout the product cycle was awesome and works really well for a few reasons:
- Your dev team feels more involved in the success of the product since they’re included in the process so early on
- It keeps an open line of communication between product and engineering
- You develop a sense of what goes into building software and understanding how technical considerations impact product decisions
The more you have these sorts of open-ended discussions with developer teams, the better you’ll be in sensing different strategies for technical implementation that prevents technical debt.
[Manage] Support tackling tech debt as a part of every sprint
Some amount of tech debt will always exist no matter how airtight the measures put in place for preventing them are.
Managing tech debt means tracking it properly and setting time aside for the tech team to work on it. Each tech debt task should have its own ticket on the project management board and include details like:
- When the deadline for fixing it is
- What the repercussions are if not fixed
- What steps need to be taken to resolve the ticket
Tech debt needs to be proactively worked on at all times. You can support this by factoring in time for working on timeline on the product roadmap while encouraging allocating time and resources to working on tech debt tickets on every sprint. For example, if there are 20 velocity points in a 2 week sprint, allocate a portion of that (say 5 points) just for working on tech debt items.
When there are moments of downtime, allocate a larger portion of sprint velocity to working on tech debt. Q4 is a great time to do this since most of the year is over and new features are not typically launched during the holiday season.
[Fix] Identify and work on tech debt you can take on yourself
Different forms of tech debt can occur throughout the software development lifecycle. Technical debt is a catch-all term that can be broken down into more specific forms of debt. For example: Architecture Debt, Code Logic Debt, Documentation Debt, Infrastructure Debt, Process Debt, Test Automation Debt, Test Debt, etc.
While most forms of tech debt require a developer to work on, there are some that you can take on as the product manager. The most obvious example is process debt.
Process is important because it ensures quality while bringing order to chaos. But it can also be a time consuming task to come up with proper processes. This is where you can take ownership. An example would be setting up a process for how customers create bug tickets for the development team. This could include creating a form customer’s fill out to accurately capture bug details and a FAQ page for answers and quick fixes to common issues.
Final takeaways
Takeaway #1: Prevent tech debt by including engineering early on in the product process. The earlier you include engineering in product decisions, the more likely you are to prevent technical debt from happening in the first place.
Takeaway #2: Properly manage tech so that it doesn’t accrue to the point where it seriously hinders new feature development. Do this by allocating time each sprint to work on tech debt items.
Takeaway #3: Identify tech debt that you can work on as a product manager. Work with your development team to identify forms of debt that you can work on and play an active role in the software development lifecycle.
Positive feedback is feedback too!
We often think of feedback as “critical feedback”, but positive feedback is just as important! Team cohesive and effective teamwork ultimately comes from a place of positivity and a sense of forward/upward momentum. It’s difficult to have these when just focusing on critical feedback. You want to know what you’re doing right along with ways you can improve. So as much as possible, ask for positive feedback like “What did you like about [x] that you’d like to see me continue doing?” and “What was your favorite part about [x]?”
If you want to level up your technical skills and your ability to communicate and collaborate with engineers, enroll in the Skiplevel program. The Skiplevel program is a comprehensive, on-demand course + community that helps you become more technical without learning how to code.
Become more technical without learning to code with the Skiplevel program.
The Skiplevel program is specially designed for the non-engineering professional to give you the strong technical foundation you need to feel more confident in your technical abilities in your day-to-day role and during interviews.
Fullstack software engineer and tech mentor to product managers. Follow Irene on Medium!