Ok, so to fall in love with your technical debt is probably a step too far. How can you love the aspects of your product that are probably causing you a lot of pain?! However, in product management you should aim to have your team, and stakeholders, love what you could achieve if you addressed it.
What is technical debt?
Technical debt is a necessary evil in the production of great product. The reality is, there are always trade-offs to be made, and sometimes it is not worth the investment to take the software to that higher level of quality. You may still be proving product market fit, or may not have many users. You might need to meet a deadline, or need to launch before a competitor does. Whatever the reason, technical debt comes from the result of a finite amount of time and resources plus the reality of market conditions outside your control. As your product, market, and customers evolve, so will your technical debt. Ideally, you want to be actively managing it throughout.
So, how do you do this?
First, stop thinking of it as technical debt.
Product Managers succeed where previous set ups to deliver IT projects failed because they look at the value. So, answer the question: how can addressing this technical debt help your product? Think about the strategic objectives that become easier to reach, or the impact fixing it could have on your KPIs.
In reality, what you might find is the impact they will make on these key measures would be small and not as significant as other initiatives. So, how might they impact your other measures of quality for your product? You might have these defined as your non-functional requirements.
Measures of quality
Usually, non-functional requirements are left to technical teams to get on with. However, they can be crucial in the success of the product. Response times, up times, load times all directly impact the user experience. Choices made about infrastructure provisioning impact your costs and potential margin on your product. It is sometimes these little details that frustrate teams. Imagine, your site is really slow. You find it painful just checking over features; you can’t imagine how a real customer might feel You speak with your team but they explain all the ways it might not be like that for a customer - even if you are using it live. You can’t get to the bottom of what the speed is, or what good could look like, and everyone is busy trying to deliver the other initiatives you have set out.
However, if the team had a target page load time, they would need to measure that. Measuring the page load times would provide analytics and real world data on the experience for customers. That next comment about speed from a customer could be linked with quantifiable data.
So, by defining your quality metrics, your non-functional requirements, you have quality measures that matter to the customer, and the business, monitored by the team. It is most likely that addressing technical debt will impact these measures and so give you a direct link to the impact you could have.
The P word…
Now you know the impact you can make with this change you need to look at how it stacks up with the rest of what you want to achieve with the product. You need to prioritise. The realities that led you to have this technical debt in the first place are still there - you have limited time and resources. You have a market and industry context to adapt to. You need to prioritise what the team spends their time working on. However, it is far easier to compare one initiative with another when you know what each intends to achieve.
The classic conversation on technical debt usually starts with one of the development team explaining that you need to address something about the database, or a way an API is structured. They then explain the technical and engineering issues behind the problem and the impact on the team. It sounds complicated. However, you can see the passion from your team members and you are wary of what this issue is doing to motivation in the team. However, you then think about the new feature you want to add and the potential new usage and revenue that would drive. It seems like a no-brainer to do the new feature.
The new conversation, however, can be very different. Now you have aligned the technical debt to value you can talk about the potential outcomes of both initiatives. Maybe, addressing the technical debt could increase satisfaction and reduce the drop off rate as the site would be more performant? You can question whether your new feature would have the impact you desire without addressing the technical debt?
Having the value linked to the work you intended to do makes for more meaningful conversations on the priority of your work. In fact, by having these aspects of quality defined it may even drive the identification of this work before it becomes such a pain point that it threatens the morale of your team. I believe this is far more effective than simply allocating a certain amount of team capacity to addressing technical debt.
Telling the story
Now you have the value you intend to gain, and the relative priority of this work against other initiatives, you can engage your stakeholders with the story. No longer are you trying to explain the technical implications, or the engineering conundrums. No longer do you need to explain why you got here, or pretend that this fix will be it for technical debt forever! You can paint the picture of the future world with this piece addressed. You can speak about how you will measure success, just like any other initiative, and why it is worth doing it before other initiatives.
Falling in love…sort of
Technical debt is an inevitable consequence of building product. We always have a finite amount of time and resources, and we are always operating in a context that changes over time. All too often technical debt conversations focus on the problem and not the impact of solving it. However, without linking what solving technical debt will do to your product you will struggle to get buy-in from stakeholders to address it.
Sound familiar? I help Product teams with challenges like this, and many more. Get in touch if you'd like to work together.