Every team has to deal with tech debt, and they take a variety of approaches to how they address it within their team, and how involved product management is in those decisions. How should you allocate time for working on tech debt? Should it be represented on your roadmap? How should you prioritize tech debt vs new features?
On Wednesday, April 2, 2025, Scaling Tech Podcast host, Arin Sime, welcomed product management expert, Kent J. McDonald, and tech debt author and engineering expert, Lou Franco, for a live discussion on the relationship between product management and tech debt.
Listen to the full episode on Spotify
Listen to the full episode on Apple Podcasts
Watch the video:
Key Insights are below
About Our Guests:
Name: Lou Franco
What he does: He’s an Independent Software Engineer and the author of an upcoming book on tech debt.
Company: Greenwave Solution
Where to find Lou: LinkedIn | Website
Name: Kent McDonald
What he does: He’s a Freelance Product Manager, Writer, and Former Agile Coach.
Company: KBPMedia
Where to find Kent: LinkedIn | Website | Newsletter
Key Insights
⚡Tech debt is not always about bad code or taking shortcuts. Lou breaks it down simply: it’s an internal friction in your system that slows developers down and gets in the way of delivering value. As he puts it, “ I think of tech debt as something about the code, an internal thing about the code base or systems, something very visible to the developers you’re working on the code, that is affecting the developer productivity in doing the things that the product manager or the business needs you to do. So you’re trying to go in a direction and you’re getting resistance from the code base to go into that direction.”
⚡How to tackle debt wisely? When it comes to tech debt, don’t fix what isn’t broken, unless there’s a real value in doing so. As Lou puts it, “One of the things I talk about is factors that make you think you should pay debt and factors that make you think you shouldn’t. And one of the factors for not is the problem of regressions. So you got a situation where a lot of people highly depend on a piece of code that is working for them. It is working to whatever extent it works; it works. But there’s something you want to do in there to pay some tech debt or whatever. To me, it’s only worth it if you can offset it with some benefits, ’cause that’s a benefit of doing nothing. So now what are the benefits of doing something?”
⚡How to get tech debt on a roadmap? To effectively integrate tech debt on your roadmap, it’s essential to align it with your business’s key priorities and its impact on users and customers. As Kent explains, “ I have a roadmap, and we will occasionally have items in there that inherently are impacting technical debt, fixing it, not creating more, but it’s not labeled as technical debt. I try to label it as in some way of expressing what impact it’s bringing to our users and customers.”
Episode Highlights
Who owns tech debt?
Tech debt isn’t just one person’s responsibility. It’s a shared challenge across product and engineering. Lou explains, “ I want engineers when they’re dealing with their tech debt backlog or whatever they’re doing to put on a product manager kind of hat with it. So to approach it in the way they would, but rather than the customer being the business’s customer, one of the most important customers of the fixing of tech debt is the developers themselves. So they are the ones that are going to benefit from the tech debt, debt being paid off in developer productivity. So they should also think about things that a product manager thinks about.”
Lack of clarity can contribute to tech debt
Tech debt isn’t always about bad code. Sometimes it’s a symptom of unclear goals and poor communication. As Kent puts it, “ I think that difference in those two things and who’s actually interacting with teams can contribute to tech debt for the reason I mentioned before, which is maybe there isn’t a lack of clarity or there is unrealistic or unsupported time pressures involved that drive the team to do things in a way that they maybe wouldn’t do if they had a bit more time to figure it out, or if they didn’t really have a good understanding of what the ultimate goal is which can also happen if you, especially if you have product managers who are kind of laying out, here’s the problem we’re going to solve, but that message doesn’t get fully translated to the product owner and hence the team that’s building stuff.”
Tech debt is still tech debt, even with AI.
While AI can speed up development, it doesn’t justify cutting corners or embracing short-term fixes that compromise long-term sustainability. As Kent puts it, “If you’re using AI to roll out features faster, hopefully you’re not doing it in a move fast break things approach ’cause I think we all know that doesn’t necessarily work as much as it used to, unless you’re just prototyping things but then it’s back to the same thing that you’re choosing to take tech debt even when you were having people code it by hand to get it out there faster so you’re just using a different tool to do it. If you’ve got people saying, ‘Oh, well, it’s okay to do tech debt, we’re using AI,’ I think you’re missing the point.”