Technical Debt and Product Development — A Balancing Act
This article was co-authored with Maxim Essipovitch.
In product management, we always hear about product vision, iteration, agility and delivering software. One thing that is rarely talked about is technical debt, more specifically how to balance it while still achieving goals and hitting all the targets. It doesn’t come easy but as is typically the case, a balanced approach is best.
What Is Technical Debt?
Technical debt can mean different things to different people. This is true of many aspects in tech, and as we know, the words we choose are important as they help bring alignment across teams.
Technical debt (also known as tech debt or code debt) describes what results when development teams take actions to expedite the delivery of a piece of functionality or a project, which later needs to be refactored. In other words, it’s the result of prioritizing speedy delivery over perfect code. — Product Plan
Technical debt can be summarized as “any action taken to expedite a release”. Those actions can be big or small but either way their goal is clear. They aim to cut the time to get to the finish line and, as is the case with all shortcuts, there is a price to pay or repay. Sprints are part of a race and releases are the actual race: if you decide to take a shortcut to release faster, there will be consequences that can trickle across different areas.
Why Is Technical Debt Important in Product Development?
The direct consequence of technical debt is most acutely felt by the Product Development team as it reduces its velocity, and each subsequent release will carry that debt forward. The technical debt will continue to accumulate, resulting in longer timelines for the team to release new features. It can also impact the team’s engagement and morale when it accumulates.
We’ve seen this before, a team will voice that a certain feature is going to be nearly impossible to deliver and we will need to refactor a lot for the release. It can definitely be discouraging for everyone involved and this is why it’s important to keep the technical debt manageable.
Technical debt can also hurt the product in the long run. You want to ensure your product is optimal in terms of performance, stability, and scalability, and that the cost of releasing new features is manageable.
One of the most common analogies for technical debt is that of an iceberg; what is visible is just the tip, with much more hidden beneath the surface. The technical debt that is apparent to others, and even to the team at times, is just the tip of the iceberg. There is more to it than meets the eye. This is why it’s important to measure the technical debt so that everyone, not just the team, can see the full extent of it.
Technical debt also impacts innovation. You might be thinking “what does technical debt have to do with innovation?” The answer is simple: if you are too busy worrying about making it through a release, it becomes difficult to focus on long-term innovation for your product. In this sense, technical debt can hinder the innovation and scalability of your product.
How Is Technical Debt Introduced?
To explore how technical debt is introduced, let’s focus on products that release new functionalities often. Say you have prioritized a new functionality such as continuous improvement or an existing initiative in your roadmap. As product managers, we know we are always focused on delivering value and impact quickly, which can come at the expense of introducing technical debt.
Introducing technical debt when you first launch a feature is completely normal. In fact, if you are not slightly embarrassed by your launches, you are likely doing something wrong. Having a perfect launch implies that your code is squeaky clean and that you are addressing every single possible use case, with the trade-off being that you took more time to release.
There are two paths that you can follow:
- You can refactor as you continue to enhance your delivered solution, which in turn allows you to continue delivering increased value to your users.
- You can choose to limit the refactoring of your solution and continue to code in a space that will eventually create limitations on performance or prevent you from unlocking additional features for your users.
It may be tempting to avoid refactoring in order to maintain momentum in delivering new functionalities, but this approach will quickly come back to haunt you. The technical debt you introduced becomes a tax on the effort it takes for every subsequent enhancement you develop in that space. If you don’t address this tax as you continue to enhance, not only will you start to face limitations in terms of enhancements, but the time it takes for the team to release future enhancements will increase significantly.
Tackling the Technical Debt
To tackle technical debt it comes down to your product and what is important to prioritize. Is having a high-performing application important for your end-users? Is minimizing support requests a strategic objective for your product? Is monitoring all critical flows of your application taking precedence over other technical improvements?
To answer these questions, it’s important to be clear on your product vision, mission, guiding principles, objectives, UX and tech objectives. This will help you make a more informed decision when discussing prioritization.
With this in mind, when we have prioritization discussions with our stakeholders or team, we should always refer back to our UX and tech objectives. Ultimately, the conversation ends with what tech improvement or enhancement will bring the biggest user impact.
What’s the best way to prioritize your technical debt? Tie it to a measurable user impact.
The Power of a Clear Plan and Clear Communication
As we know, shortcuts will be taken when delivering complex projects, especially those with hard deadlines. So what happens next? Once a project is delivered, there is always some sort of cooldown period during which we can take a step back and rethink any flaws or gaps that may exist. Let’s look at an example to see how this process can take place.
In this example, we notice the following issues:
- The architecture doesn’t scale horizontally: if the number of products displayed is increased, the number of calls will increase.
- Product data is needed in the back-end of the application to be able to calculate data for the UI.
- The application is slow and very coupled with the product service.
Once we determine that major architecture changes need to be made, the challenging part begins. How will the team convince the product manager to prioritize this work?
Of course, the answer is clear communication, but first, we need a plan and a viable solution. The solution is simple: let’s make sure to have the data before we even need it.
If this solution is brought to the product manager, it might be a hard sell. Although it brings value and even product improvements, this needs to be properly highlighted. In this case, the plan is solid, but one area where a lot of technical people fail is clearly communicating and outlining the value it brings for the product manager and the stakeholders. In other words: what’s in it for them?
We often hear arguments such as:
“I feel we should undertake this plan; it’s very critical to make the architecture and code cleaner. We can get this done in a few months.”
“If we don’t do this, it will cause issues down the road and slow us down.”
On the surface, these arguments are okay but they don’t use clear and persuasive communication. These statements are rather vague and don’t highlight the other party’s needs.
When entering any debate or negotiation, you want to put yourself in the other person’s shoes. Why would a product manager, who is looking to deliver value, prioritize this technical debt? Our advice for a situation like this is to focus on the value this provides rather than just the technical value.
Try this approach instead:
“Since the launch of the project, we noticed some performance drop-offs. The page load is 30% slower and this issue is worsening due to the increased number of products being loaded on each page. We foresee this becoming even more of an issue in the coming months and ignoring it will result in poor performance and a negative user experience. We have developed a plan to remediate this issue, while also ensuring scalability for future features.”
In this example, the key message is delivered by identifying the issue and its impact on the product, which resonates more with the product manager. When a clear plan is communicated on how to resolve the issue, it also gives the product manager confidence that the team is in control. Also, the more data you can include to support your case, the better.
Clear communication is always essential, and not all situations will require the same approach, but attaching value to a technical debt will always help prioritize it and ultimately result in a better product.
Technical Debt Is a Tax that Must Be Paid
Last year, while working on a key project at SSENSE, the team worked hard to get it over the finish line. However, the code presented clear limitations in terms of readability, reusability and maintainability as a consequence of shortcuts we took. The timeline for us to launch all the required features left us with no choice but to create technical debt to deliver. We carried and addressed the technical debt across the application and we also suffered in terms of user experience.
In this case, the value provided by refactoring the code was evaluated in productivity gains for the team. It was harder to prioritize as it didn’t bring direct value to the end user. So, our goal was to attach it to something that does.
When we looked into refactoring the application, our main focus was improving the user experience while minimizing the time spent searching for items. We took the opportunity to completely redefine the way we wanted to search across the application. Although this meant we took longer to deliver these enhancements due to the cost of the technical debt, it also meant we were unlocking new features and getting closer to the vision we had for the application.
A stakeholder will never ask a product manager to prioritize technical debt. Their focus is on pain points, and they will naturally want enhancements made as quickly as possible. That’s why, as product managers, it is our responsibility to prioritize technical debt. And if we want our product to continue to scale, we have to find creative ways to get it prioritized.
The Balancing Act
Technical debt has negative repercussions when left untouched, which can be compared to loan interest. If left unpaid, it will grow exponentially. This is also true for technical debt. As such, you want to consistently repay and manage it so it doesn’t overwhelm the product and hinder its capacity to iterate fast.
There are different ways to manage technical debt. It can be prioritized as an initiative that focuses on the user impact or it can be added as a tax to features in development. These two approaches are efficient when it comes to larger chunks of technical debt, while smaller tasks can be completed as part of ongoing maintenance work in a sprint.
Ultimately, always ask yourself: “What will happen to the product if we don’t address this issue?” Knowing the answer to this question will help you clearly assess the impact of not addressing the technical debt and how to prioritize tackling this debt.
Editorial reviews by Catherine Heim, Luba Mikhnovsky & Mario Bittencourt.
Want to work with us? Click here to see all open positions at SSENSE!
