What Is Technical Debt and Product Debt?
A technical debt is a debt which is caused by writing sub-optimal codes in the beginning in order to release it early. It occurs when the code is written without following the proper scaling and documentations, which are essential for the increase in quality.
It is often seen that people go quick in order to release fast, but end up with a debt in hand. If you don’t reduce the amount of technical debt, it will become difficult to create or change the code in the future.
Whereas a product debt is a debt which is caused when you make short-term product decisions that can lead to expensive long-term consequences. Product debt results from decisions made in rush or hurry.
“Some debts are fun when you are acquiring them, but none are fun when you set about retiring them.” A quote by Ogden Nash.
There may be many causes of debts such as adding too many features, custom features, data/model related hacks, flow related hacks and interface hacks.
How are you incurring Product Debt? OR Reasons for Product Debt.
The reasons are:
Adding too many features: Adding too much information to your release or product is the major reason for product debt. You can simply relate this with an example, that if you try to add too much, then it becomes quite difficult for the product engineer to cope up with the features. It is like you are burdening him with some extra work, which is not possible in the desired time. For adding extra features you are ultimately landing yourself in the unwanted product debt, because at the end you won’t be able to release on time. Thus causing a delay. This is an example of debt created by business pressure. There are also cases where the features are often badly implemented. This leads to confusion.
Data/ Flows/ Interface Hacks: If you are adding features which change the data model of the app, these changes are far more expensive than creating a button that appears inconsistently in “that section of the product”. Creating new inconsistent flows is more expensive than adding a new set of icons.
What should be done to prevent debts?
Listed below are some common preventive measures which you can effectively to prevent any sort of debts. They are:
The Boy Scout Rule: In Boy Scouts, there is a rule which says “always leave the campground cleaner than you found it.” With this it says that when you design a product, you should end up by making it better from the original one. This helps in increasing the life of the product and the product quality suitable for future use.
Strong Leadership Design: A debt is always found where there is even a slight presence of confusion. This confusion can be in the product’s goal or the ultimate vision of the design. If this is changed regularly, the team may lose interest and thus there is a decrease in the quality. In order to reduce this, they need to be provided with enough authority to drive the direction of the design, while still affording a deal of autonomy to the designers that work for them.
How can a debt be eliminated/ managed?
If you are already suffering from the problem of technical or product debt, then the listed below solutions can be followed. They are:
Refactoring: Refactoring or redesigning is being one of the best methods to eliminate a debt. It is the process in which the full integration and reorganization of the new structure takes place. This can be developed experimentally. You can implement new lessons from carrying out experiments. Then can consolidate those design patterns and restore context and consistency.
Small iterations, followed by a large iteration: The refactoring process can also be seen as a large iteration that ties together the changes made by the multiple small iterations that came before it. Small iterations are based on quick learning. While large iterations are based on applying those learning into practical use. This maintains the integrity of the user experience. This can happen semi-regularly, depending of course on how frequently you are running experiments and implementing changes.
Conclusion
Iteration and experiment driven process is one of the best ways to learn about the audience and develop a design that truly works. By using all the measures, the designers can make most of it. But it is important to consider the debt that can be taken on by a design over time, and plan for refactoring as necessary.
Join to get a sneak peek into what's happening
I write about books, experiences, product, UX, EdTech, early stage growth, validation – mostly tech. Subscribe if these topics interest you. Once every 15 days emailer. I promise – No spam. (I am known for it otherwise) 😉
