Product Managers are Responsible for Managing Technical Debt

Product Managers are responsible for managing Technical Debt. Or at least should be. When I make this statement, I often get threatened by an angry mob, chanting that I should be banished from this plane of existence. At other times… I get highly skeptical looks and a question "Why?"
Why, you ask? Because questions around Technical Debt are business questions that are ultimately tied to the future of the product. Managing Technical Debt is more than typical risk management. If left untacked, technical debt could devastate your competitive advantage over a few years, by decreasing your development velocity. The consequences of technical debt can ruin your brand reputation. If you are a B2B company, technical debt can end up in lawsuits from your customers. Mismanaging technical debt can even result in your most talented employees leaving.
No Go Zone
By now, most companies figured out that Product Managers without a technical background can make a tremendous business impact. I feel a need to note that I was a Software Engineer before I transitioned into Product Management, so this is not a defensive statement by any means.
But for some silly reason, if a business decision is even slightly technical, it gets pulled out from Product Managers' area of responsibility. Responsibility for managing technical debt is the prime example of that. Typical excuses are that Product Managers don't have the skills or enough insights to do it properly. But I beg to differ - it's not the matter of technical skills. It's a matter of soft skills, process and business acumen.
I firmly believe that there are two key factors when it comes to this topic: understanding technical debt and prioritizing technical debt.
Better Communication is Crucical
I noticed that most Product Managers struggle to understand technical debt because they have communication issues with Software Engineers. Technical debt problems are often complex, and non-senior engineers often struggle with explaining the problem itself. In general, people tend to ignore the problems they don't understand, until those problems hit them in the face. The same goes for Product Managers.
Another common communication problem lies in the discrepancy between skills and expectations. Most Software Engineers I have meet in my life care about their craft, which typically doesn't include sales skills. In return, they end up pitching technical debt problems that don't sound so important for the business. Often about developer productivity and delivery velocity. On the other hand, Product Managers are often swarmed with backlogs of things that sound important for the business, as business-oriented stakeholders are more persuasive than Software Engineers. Therefore, Product Managers don't take these pitches from Software Engineers as seriously as they should.
Prioritizing the Technical Debt is a Business Decision
I'm a strong advocate of prioritizing backlogs in alignment with the company goals. I won't dive into explaining how OKRs should be set up, because it's a topic unto itself, and there's plenty of quality material available on the internet. There is no reason why the same approach shouldn't be used for technical debt.
Often, it feels like there is a disconnect between the company OKRs and technical debt. But OKRs are usually connected to technical debt, unless the horizon of your company's strategy is shorter than one year. The problem is in finding the connection.
A typical place to start is to look into 'technical' KRs, such as '0 SLA1-level problems' or' 99.95% uptime'. If you start considering the implication of technical debt and have enough data, you will likely find the connection to the business KRs. A prime example of such KRs is reducing user churn, because bugs and downtime often end up abandoning your application. I can't emphasize enough that you need enough data. If you can't find any link between these issues, the first technical debt improvement you might want to resolve is improving your applications' monitoring stack.
Technical debt can even be correlated to the HR KRs. I know of some companies that could acquire interesting insights if they asked questions about managing technical debt on exit interviews with their Software Engineers.
But why should Product Managers manage the Technical Debt?
As I explained above, managing technical debt is more than the typical risk management. But why should Product Managers be the ones to do it? The short answer is: because no one else can do it well. Prioritizing something in the backlog requires a holistic view of all the business priorities. And having that view is the Product Manager's job.
The worst approach, and unfortunately, the most common approach, is to agree on the "fixed time" for technical debt. For example, two days of every Sprint, developers can work on any technical debt they feel like working on. The problem with this approach is that it's not evaluating technical debt against the current business needs. Sometimes, what business needs is developers entirely focusing on delivering an important feature set for the next few Sprints. Sometimes, what business needs is to focus the whole Sprint on the refactoring legacy part of the architecture, because the potential outcomes of leaving that piece of technical debt untackled is frightening.
Technical Debt Management Strategies
Here are a few strategies that might help Product Managers with managing technical debt:
• Do correlation mapping sessions - Correlating technical debt to OKRs is a team sport. At least include your technical counterpart in the process, if not the whole team. And don't forget that you might need to re-assess the correlation from time to time.
• Create templates - Understanding all the intricacies of technical debt problems is time-consuming. And time is usually the resource that Product Managers lack. What helped me with this is creating a template for technical debt problems. The technical debt problem template can include a summary and details like KR it impacts, worst-case outcomes, and timelines for those outcomes. The next step is having your Software Engineers populate that template each time they pitch a technical debt problem. It will make communication faster, but it will also help coach your Software Engineers about the business impact.
• Raise transparency through data - Periodically send out a summary of technical debt problems that were resolved, including the potential worst-case outcomes prevented. It will help relevant stakeholders understand the complexity of your team's work and raise your teams' morale.
None of these strategies mean that you have less responsibility for the prioritization decisions you make in the end. Same as for anything you prioritize in the backlog.
In case you are a Product Manager, and you still believe that you should not manage the technical debt, I would dare say that you don't understand the importance of technical debt. If so, please feel free to challenge me on Twitter.