Technical debt: How to deal with it as a product owner

As a product owner, you are responsible for the successful development of your product. You may have consciously or unconsciously entered into technical debt yourself. But have you also thought about its effects? In this article, you will find out what technical debt actually is, what definitions there are for it and how you can consciously enter into it with your team.

What is technical debt?

Technical debt, also known as technical debt, occurs when you take shortcuts in the development of a product to get it to market faster. These shortcuts can take the form of poor code, lack of testing or inadequate documentation. In the worst case scenario, this makes it more difficult to further develop the product and costs more time and resources to fix problems in the future.

‍

What types of technical debt are there?

‍

Our overview for product owners is based on the "categories of technical debt" according to Martin Fowler, Chief Scientist at Thoughtworks.

The different types of technical debt differ in the severity of their consequences. On the one hand, there are the so-called "considered debts" (right in green), which can be a quick and easy shortcut (top right) or simply arise because you have gathered more information from the market & customers over time (bottom right).

Ward Cunningham coined the 'debt metaphor' to emphasize the importance of refactoring in software development. This metaphor makes it clear that code should always represent the current understanding in order to solve problems through software, and that technical debt is not built up intentionally, but arises involuntarily in the course of development.

On the other hand, there are the "frivolous debts" (left in red). To remedy their consequences, you (often) need more time and resources. These include, for example, shortcuts deliberately taken without a concrete goal (top left), or simply a lack of knowledge in dealing with a new technology (bottom left). Poor code or inadequate architecture is often the result.

If you would like to find out more, Sebastian explains both sides in more detail in the video.

Which technical debts in software development are good - and which are bad?

"Good" debts help to bring the product to market more quickly and thus achieve a potential return on investment (ROI) quickly. You have a goal.

• Example:
• You quickly hack a feature to bring it to market faster and test whether it works for your customers. (P.S. Don't forget to clean up)

"Bad" debts, on the other hand, are based on ignorance or a lack of conscientiousness and do not pursue a specific goal. They hinder the further development of the product and can be very expensive in the long term.

• Example:
• You don't carry out tests during development because you say you don't have time for testing. This can lead to problems with the quality of the product later on.

In order to manage technical debt effectively, it is important to develop and apply suitable strategies.

What effects can technical debt have?

Always be aware that technical debts - even if you enter into them carefully - are still debts. In particular, it can have a negative impact on the further development of the software. It also costs more time and resources to fix problems in software development. Technical debt can significantly affect the quality of the software.

Technical debt can also significantly reduce your team's 'time to market' as there is less time available to work on new features.

Also think about your customers. It is certainly an advantage for everyone if your product is launched quickly. However, a later backlash due to technical debt can negatively affect the quality of the product and customer confidence. The impact of technical debt can be drastic for the company and its customers.

• As a product owner, consciously address the issue of technical debt!
• It can be advantageous if you enter into technical debt in a considered and targeted manner.
• If you do, be aware of the exact impact of technical debt on the evolution of the product and make sure it doesn't lead to long-term problems.

‍

‍