Technical debt in product terms
No matter your role, if you have worked with software engineers, you would have heard these two words “technical debt.”
Understanding technical debt is burdensome and one of the most challenging things to explain to no-code people. Trying to describe it is difficult, but it is worth doing strategically; this is part of your job as a product manager.
In the early stages, product managers have tons of expectations about building the most outstanding product, the best feature. Thus they want to invest all the effort and time of their team in disruptive ideas, move metrics and try things before the competitors.
It is the most fantastic attitude to start with; never lose it. However, it is also essential to pay attention to the technical debt that your product is regularly generating. Sometimes it will be complex to find value in investing your team’s time in technical debts, although it can be worth it soon.
What is “technical debt”?
Technical work needs to be completed but is not necessarily a priority. When prioritizing speedy delivery over perfect code, you are generating debt.
The more technical the work is, the harder it is to communicate and justify for the product manager. So transmitting its benefit and value to the stakeholders is tough. That is because we need to translate the technical task into business language.
Reducing technical debt is necessary for your product to scale, so start by understanding it and use your team’s focus strategically to hack technical debt.
What are the key aspects of working with technical debt and being compromised?
As the product manager, you have three significant challenges related to technical debt.
The First act, understand it.
Do you remember when you came up with this fantastic idea, and your team made a “quick win hack” to launch it fastest than ever? Unfortunately, that quick win hack generated a percentage of your current technical debt.
Your responsibility is to know your product, and technical debt is part of it. It is advantageous to know the following aspects:
- Which technical task we deprioritize to speed our delivery.
- Which technical debt blocks our product to scale.
- Which part of the product is a headache for your team.
Get together with the development team and try to thoroughly understand this technical debt checklist to have a diagnosis of what your product currently has.
Here are a couple of questions to answer with the engineering team about your current list of code debt:
- What do we think will enhance our customers’ experience?
- What do we believe will improve our team’s expertise?
- What do we think will help us to scale our product faster?
We need to know and understand the technical debts of our product to prioritize at the right time and increase the quality of our product.
The second act, tell the story.
As product managers, we must tell the story and show the impact of tackling technical debt. This story has to be accompanied by the company’s growth strategy; the product’s quality and infrastructure must grow in line with the company’s approach to achieve an orderly and sustainable scale.
Organizing these high-demand periods is essential from two key points of view. First, from a customer-centric perspective, to give them the product they deserve, and from an employee-centric optic, to reduce unexpected problems by fixing a product that does not scale as the business expected (as much as possible).
Technical debt strategic tackling must follow the company life cycle and work across it. The product manager’s skill in detecting oportunities and anticipating possible problems according to the company’s stage will help tell the story to stakeholders.
How do the company’s stages influence our technical debt decision?
In start-ups, speed delivery is prioritized to get ideas to arrive first in the market or validate business ideas. As a result, working here is agile and dynamic, with lots of uncertainty. Teams are more vulnerable to adding technical debt to the new products because it is more important to validate the concept than to robust the solution.
In the growth phase, the transition from start-up to growth phase can be turbulent bugs, issues, processes undefined, and technical debt not correctly documented starting to play in the game.
This stage typically finds the product with low quality; unfortunately, these problems make your product go down, or some part doesn’t respond correctly.
After suffering a bit or a lot of unplanned work after hours, services turn down, and customer problems, it is time to “refactor” and prepare your product to scale if you couldn’t be planned before.
In the maturity stage, the company has frequent customers, and the quality pillar becomes more relevant. Therefore, technical debt needs to be part of the roadmap by adding value to the product, the team, or the company. Therefore, managers and PMs must be more selective in deciding which technical debt carries on to the backlog and which is needed to do it right from the beginning.
The risk of having your product not working or with some issues is higher and represents a high cost that translates into money or brand image.
Creating a story that contemplates the company’s growth strategy, current product stage and connects the technical debt with the impact of solving it in business terms will help any product manager convince stakeholders.
How do you build that story? With great synergy on your team ( engineer + product + uxers)
Third act. It’s always about balance
.Technical debt is a trending topic in every technological company. Working in a multidisciplinary team challenged the product manager to speak about technical debt so that everyone could properly understand it.
Building a clear vision of technical debt’s value is as important as buying some of it and putting it into the backlog when we need to be first in the market.
The team must compromise with both aspects of the technical debt and feel comfortable working on both sides, with quick idea testing and high-quality products.
It is always about balance, speed delivery and robust solution, time to market, and perfect solutions.
Thank you to read it. If you found this article useful and it can be useful to others, share it :)
