Technical Debt and Product Success
Similar to a company experiencing financial debt, products can incur “technical debt”: This happens when wrong or suboptimal architecture, technology, and coding decisions are taken. Consequently, the architecture may not be as loosely coupled as it should be, and the code may be messy rather than clean. This article explains why product people should care about technical debt and it offers strategies for addressing it.
Why Technical Debt Matters for Product People
As the person in charge of the product, you may not be terribly concerned about how clean and well-structured the code is. But the quality of your product matters: It directly impacts your ability to achieve strategic product goals and make your products successful: Technical debt makes it hard to experiment with new ideas, release new features, and quickly respond to user feedback. [1]
The messier the code and the less modular the architecture is, the longer it takes and the more expensive it is to change your product. In the worst case, you have to go through a rewriting exercise where some parts or even the entire product are being redeveloped. This is similar to financial debt: When the debt is not paid back, the interest payments can multiply and eventually cripple the business.
Technical Debt and Your Product
To understand if and to what extent your product is affected by technical debt, talk to the development team, for example, in the next sprint retrospective. I find that development team members usually have a good understanding where issues in the architecture and code are.
Additionally, consider asking the team to collect data that shows how much technical debt there is, where it is located, and how bad it is, for example, by using code complexity, dependencies, duplication, and test coverage as indicators. There are a number of code analysis tools available that collect the appropriate data and show how adaptable the architecture and how clean the code is. [2]
Once you understand the amount and severity of tech debt in your product, analyse its impact on meeting the product goals and achieving product success together with the development team. Take into account the cost of delay, the cost of not addressing the technical debt now but delaying it to a future point in time. Should you, for example, continue adding new features to the product for the next six months and plan in bigger technical improvement work afterwards? Or would it be better to address the worst debt now?
Furthermore, consider the life cycle stage of your product. Technical debt is particularly bad for new and young products: If your product has a closely-coupled architecture with lots of dependencies, if it lacks (automated) tests and documentation, or if it is full of spaghetti code, then experimenting with new ideas and adapting the product to user feedback and new trends will be difficult and time-consuming. Similarly, if you want to extend its product life cycle, you may have to first remove (some of) the technical debt before you can make the necessary changes and add new features or create a variant.
Having said that, it is a valid strategy to launch a minimum viable product (MVP) whose architecture, technology, and code has been intentionally compromised in order to reduce time to market — as long as the quality is good enough to adapt the product to feedback from the early market. But apply this strategy with caution: You will have to spend time addressing the technical debt incurred and putting your product on solid technical foundations. This should be done before reaching product-market fit, as you will otherwise struggle to scale up and keep your product growing.
If, however, your product is in maturity — or even decline — and you do not intend to extend its life cycle but focus on maximising the business benefits it generates, you probably want to do as little debt removal work as possible.
Read On …
To read the rest of this article and access the remaining tips, please head over to my website: https://www.romanpichler.com/blog/technical-debt-and-product-success/
Learn More
To learn more about technical debt, attend my Product Owner Masterclass and read my book Strategize.
Notes
[1]Technical debt is a concept originally suggested by Ward Cunningham and nicely explained by Martin Fowler. Thanks to Yves Hanoullefor encouraging me to write about it.
[2] I recommend that you add software quality to your KPIsand routinely track it. Quality is leading indicator: If it is decreasing, then you know that changing the product will become more and more difficult unless you do something about it. Knowing if and how much technical debt is building up helps you be proactive and avoid nasty surprises.
Source: https://www.romanpichler.com/blog/technical-debt-and-product-success/
