Tech Debt from the Product Manager’s POV

Three strategies for more productive outcomes when collaborating with engineering.

As product managers, we often find ourselves caught in the middle when addressing technical debt and refactoring. 

At some point, engineers or architects will come to you and say, “Hey, we need to start investing in our tech stack; we have major issues slowing us down.” It’s not an if. It’s a when. 

They’ll ask for time, which equals money, to fix issues related to scalability, maintainability, performance… and the list goes on.

To you? These might seem like invisible things. They’re probably not on your roadmap. Often, your customers, where you’re focused, aren’t asking you to invest in these areas.

On the one hand, our engineering teams are fighting to invest time and effort into our product’s underlying architecture and stability. On the other hand, we face pressure from sales, leadership, and the market to deliver new features and capabilities that drive revenue growth.

That’s a tough tension to navigate.

What if the three-month investment turns into a year-long effort? How will my stakeholders react to a pause in feature or capability flow? If we break the engine apart to rebuild it, isn’t that too risky?  

When I’m faced with this, I rely on three key strategies I've learned from my experience as a product manager to navigate this tricky balance:

1. Don't call it "tech debt.” Reframe it as customer value.

2. Don't write blank checks. Collaborate with engineering on iterative experiments.

3. Do the technical improvements while you’re developing features.

By applying these approaches, you can effectively advocate for your product's technical health while delivering the new features and enhancements your business demands.

1. Reframe tech debt in terms of customer value.

As product managers, we know that addressing technical debt is critical for the long-term viability of our products. However, when we bring these needs to the executive team, they often struggle to see the direct ROI. That's why it's important to reframe the conversation away from vague terms like "tech debt" and "refactoring" and instead focus on the tangible customer value these investments will unlock.

If you’re an engineer or engineering leader reading this, this imprecise language cuts off communication and understanding, obfuscating the real need and value with talk of magic beans. Instead, help your PM understand and frame the customer and business value gained from technical investment! This PM you’re selling “technical debt” to will need to sell this up in the organization, maybe even up to the boardroom. Technical vagaries don’t help your cause. In plain language – what’s in it for your stakeholders, customers included. 

I remember working in a company many years ago on a security software product. We needed some architectural changes, but the reasons the architects brought to me weren’t reasons I could sell.

After many back-and-forths with the architects, we finally got to the point. We stood to gain significant performance enhancements in one of our software’s core workflows. That was something I could sell!

I could take this performance argument into the boardroom and sell this investment as beneficial in two ways. First, by doing this, we keep our existing customers happy. Second, we can use this to differentiate our superior performance in the marketplace.

We didn’t put “tech debt” or “refactoring” or “architecture change” on the roadmap. We put “significant performance enhancement for our number one workflow” on the roadmap. 

See the difference?

We got that project approved, and we did it. We paid back the debt and changed our architecture. More importantly, we got performance enhancements. We got an outcome our customers and stakeholders recognized as desirable and valuable—an outcome that became the number one bullet point on our release notes.

Try to attach real value to your technical investments. Sometimes, like in the story I shared, it’s really obvious. You might just be able to tease it out of your engineering partners through a conversation or two. 

Other times, it isn’t obvious at all. You might have to look into product health or resiliency. You might have to look at competitors and see where they lag in non-feature qualities like performance. Product discovery activities don’t just tell you what features are needed. Discovery can also illuminate opportunities that justify technical investment. You just have to take the feature blinders off.

2. Collaborate with engineering on iterative experiments.

Do not write blank checks. I’ve seen so many product managers say, “Alright, we’ll take this quarter.” Don’t do it. 

If your engineers break things apart, it’s easy for one quarter to become two, two to become three… you see where this is going.

There’s no reason you can’t do architectural or under-the-cover type work in well-formed, iterative experiments.

I’m working for a client right now, a SaaS company that is trying to improve performance. It would’ve been easy for product management to write that blank check and say, “Here, go away for two months and make it so.” 

But this PM team didn’t do that. They worked with the engineers, and together, they collaborated on about a half dozen experiments to figure out the problem's source and some ways to address it directly or maneuver around it. Interestingly, almost every attempt failed in the first week of conducting these experiments. But that told us not to go there. It helped us find dead ends and narrow our focus.

We all—product and engineering—learned cheaply and quickly. After a couple of iterations, they isolated the root cause of their performance problem. One set of queries was the main culprit. Instead of shotgun surgery, they found a clear diagnosis with a more precise prescription.

Product management didn’t write a blank check. They leaned into collaboration, bringing to the party the tools they know best: iteration, experimentation, and a focus on value. 

3. Tackle technical work while you're already in that area of the codebase.

Finally, product managers should always look for opportunities to address technical debt and refactoring while their teams are already working on a particular product area. This allows you to maximize efficiency and minimize the overall investment required.

Don't call it tech debt or refactoring. It's just work; it’s a part of the whole. We need to balance improving the system with adding new features and capabilities. When one steals focus, the other suffers. One of the reasons you have debt typically comes from over-indexing on delivery.

It helps your engineers reinforce the message of “do it right.” You’re not giving permission. It’s more about setting an expectation that while working on feature XYZ, you’ll tidy up the campground. Again, not permission. More advocacy and encouragement. 

Pay down the technical debt that’s in our way while we cut a new customer journey through our software. This acknowledges the agency you want your engineers to have, but it also creates a challenge to clean up the system while creating new functionality. 

This messaging encourages balance at the most atomic level and slows the compounding interest effect of technical debt.

Navigate the tension between quality and delivery continuously.

By taking the continuous, iterative approach, you can steadily improve your product’s health without dedicating large blocks of time and effort.

As a product manager, addressing technical debt and refactoring requires an appreciation of balance and good negotiating skills. 

By reframing the conversation around customer value, collaborating closely with engineering, and seizing opportunities to do the work incrementally, you can ensure your product remains healthy and competitive in the long run. 

It's challenging, but applying these strategies will improve outcomes for your engineering partners and customers. It will also fortify the social bonds and trust between product and engineering, yielding a more transparent and collaborative team.