Why should product managers involve themselves with prioritizing technical debt?
When it comes to technical debt many product managers do not like to get involved. They see it totally as the domain of the development. Most of the developers also do not want product managers involved in technical debt decisions because they feel that product managers care only about features.
To solve it, many organizations decide to allocate x% of the development resources to technical debt and in that, they feel they avoid the conflict between development and product management at least in one frontier.
While it is definitely a feasible and reasonable solution it is far from perfect and has some disadvantages, as I will try to depict below.
What is technical debt?
I am sure you are all aware of what is technical debt, but let’s make sure we are aligned. Technical debt usually reflects the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer.
Technical debt can relate to scale and performance, maintainability, development efficiency and many other areas that can hold us back.
You can compare it to a monetary debt in which you take a loan and it accumulates interest. The later you pay the more expansive it is to close the debt.
How is technical debt created?
Technical debt is not necessarily a bad thing. Many times, we create technical debt on purpose. The most common case is in startups when the practice is to build things that do not scale (see also Do Things that Don’t Scale by Paul Grahm).
As a startup, you do not always have the money to build a system that will scale properly if you succeed and grow. You build the minimal capabilities to allow you to get into a product-market fit. If you would have built it the right way, you would have wasted expensive resources on engineering problems instead of discovering how to come with a differentiative solution. Once you get to product-market fit and start to grow, this becomes the time to start paying the debt.
This approach is usually good for any feature even in big enterprises. You first want to build the feature and make sure customers will use it. Once you know it is not a feature you will need to throw away you can start improving on scale, performance, and maintainability.
Technical debt can also be created even if you do the best engineering. You design a system with the inputs and technology you have at the time, and after a year you discover some new inputs or there is a new technology.
Prioritizing technical debt
The reason I prefer to prioritize technical debt just like any other feature is that giving x% of resources to it sometimes causes waste of resources because engineers love to re-engineer and other times it is not enough and can hold the product back. Sometimes a technical debt might require the whole team to solve it fast enough. Especially if you start growing and suddenly need to scale fast.
When you insist on prioritizing technical debt you make sure the right questions are asked just as for any other features. The questions should, of course, be around value but in a little different way than regular features.
While for a regular feature you usually ask what value you will gain, for a technical debt you usually ask what value you will lose if you do not handle it.
I usually ask the following questions:
If we do not implement it now, what will be the cost to implement it later compared to the cost now?
Based on business trajectory when do you think the technical debt will start causing real damage if we do not handle it. Real damage can be an inability to scale the system, a hold in development ability to develop fast enough, or something else.
Asking these questions makes sure the development team handles the right technical debt at the right time and that proper resources are given or not given according to a real need and not according to what is sexy to solve.
Some more interesting insight on this subject can be found in Who Owns the Technical Debt.
Summary
A product manager does not need to define every feature. There are many technical features that do not require their involvement in the definition. However, when it comes to prioritization, a product manager needs to be able to lead the discussion. They should care about any feature whether it is technical or not and understand the implications. Otherwise, they might find themselves not in control and out of focus of what needs to be built to serve the business.
Be Reliable