Technical debt is a term popularized in software development that refers to the implied cost of additional rework caused by choosing an easy fix in the present instead of using a better approach which may take more resources (time and money). Things are never ideal because organizations do not sit on an infinite supply of time and money. Just like in our lives, having debt is not a sin in itself. Not being aware of the debt and allowing that debt to spread beyond sustainable limits is!
The intention of this article is not to talk about tech debt or ways of managing tech debt. I am writing this article because I have felt the need for a term like ‘product debt’. Maybe, it exists and I just do not know. In my experience too, I have seen just technology debt and not product debt in the product roadmaps. One organization that I worked also had a dedicated team for managing technology debt. I believe that debt should never reach an extent that you need a dedicated team to handle it.
I always like to see technology as a means to an end and not an end in itself. Again, means is an important as an end and in some cases like machine learning algorithms that spit out ‘Movies that we think you may like’, means i.e. the algorithm at play has an important role to play towards the end i.e. the recommendation. Debt that accumulates for a product can extend beyond technology. There can be design debt. Again, Wikipedia uses design debt as a synonym for technology debt. I do not think that is right. Are design and technology synonymous? Maybe, yes, for people who feel that the world is full of Java, Javascript, Python, APIs, etc.
During the design thinking phase or the design sprint phase, the team could have chosen a sub optimal solution for want of time, money or for some other reason. And, when I say solution, I just do not mean the technology. In fact, design phases do not go deep into the technology aspects of how the problem will be solved. Choosing a sub optimal solution today must also mean that there is scope for improvement. This is where the concept of product debt comes in. Such solutions or features can be tagged in the product backlog as product debt. They can be taken up as part of the product roadmap conditionally based on certain conditions being met like those of revenue or profit goals. When you start earning more, you just do not party all that money or go to Las Vegas! You also try to repay some of our debt. There can other forms of debt associated with a product. Missing documentation or quality of product documentation is also a concern. Brand consistency may be lacking. Even that is a debt. So, it is important to note that product debt is more than technology debt and one must keep track of such debt and dispose off such debt if the product and the organization are to sustain in the market.
In fact, I believe that if product debt is managed, then a product can be ‘immortal’. There will probably be no need for ‘sunsetting’ a product.
As a side note, I also like to relate this debt business to my daily life when I am cooking something. I like to keep my kitchen table clean when I am cooking and I do not wait until all the cooking is over. I use breaks in between cooking steps to do dishes, keep cleaning what is being dirtied, etc. So, if we think of our product as a kitchen table that we want to keep clean, just be determined to use your time and other resources judiciously to clean that debt whenever you can! The product will stay clean.
Sudhir Gupta's Blog 