Technical debt. Why should a product owner care about it?

In software development, every decision has its trade-offs. So, technical debt is formed when development opts for shortcuts to deliver a feature faster but introduces complexity or maintenance difficulty in the long run. Your team will have to refactor the code at a later time. Often, it will take more time to fix it than it would have taken to build it properly the first time. Therefore, the ‘debt’ concept borrowed from finance indicates that the longer you wait to address the issue, the more expensive it will end up costing. 

Most shortcuts are taken during the MVP development stage. This is when the business is only starting. So budgets are tight, and deadlines are pressuring. The product must get to the market as soon as possible. Speed brings the most business value. So, from this perspective, any product will generate some level of technical debt and it is a norm. After all, it is not only about the speed but you will potentially discard a part of functionality upon getting the feedback. 

On the other hand, a product owner is a team member who is responsible for the maximum value of your software product. An app with high technical debt cannot innovate much, release new features, or provide great UX among other things. This hinders the ability to generate traction and capture the market share. 

In this article, we’ll look into why a person responsible for maximizing the value of an app should care about the app’s technical debt. 

A Product Owner: The Definition

The Product Owner role is formally defined only in the Scrum methodology out of all the Agile ones. Plainly put, this role aims to maximize the product value by focusing on Product Goals and managing Product Backlog. Overall, Scrum methodology implements agile principles by having a strictly set amount of time per each sprint with daily Scrum updates. Therefore, the Product Owner must work with the Product Backlog to prioritize work for the next iteration. 

In contrast, Kanban methodology focuses on the development process as a continuous flow organized on a Kanban board. So there are no fixed sprints, and the Product Manager, the Project Manager, and the development team shares the responsibility of a Product Owner. 

In the lean methodology, the function of minimizing waste and prioritizing features is collaborative work. As such, the team shares responsibility of a Product Owner collectively. 

However, the Scrum methodology offers the most accountability when it comes to the Product Backlog. Having said that, the task of maximizing value, prioritizing work, and aligning with business goals exists in all methodologies. Yet, there might be different roles that fulfill these. 

It is important to note that the Product Owner does not directly identify the technical debt. The Product Owner delegates the technical estimation to the development team. They identify the issues, and then calculate and estimate the technical debt. It is the Product Owner who manages the work to be done on the project.

Interestingly, InsightTD conducted a survey of software developers in 6 countries – Brazil, Chile, Colombia, Costa Rica, Serbia and the USA. According to the survey, 31% of 653 respondents had never heard of the concept of technical debt. And out of the remaining developers who did, only 27% can practically manage it on a project.

Technical Debt: The Concept

Let’s imagine this part of the Product Backlog:

1. Implement user authentication on the backend
2. Implement user authentication on frontend
3. Implement secure routing on the backend
4. Implement secure routing on frontend
5. Update product database schema for scalability
6. Remove deprecated API endpoints
7. Improve state management of UI components 
8. Address cross-browser compatibility issues

Tasks 1 to 4 are new functionalities. Implementing this means you move the needle on the project and things get to be functional on the website. Tasks from 5 to 8 address the technical debt. They tweak or fix the existing functionality and make it work better, be scalable, and extensible. 

The tasks on this list seem manageable, and the Product Owner can gradually phase them into the works. However, sometimes a codebase might be more problematic than that or upgrades are more extensive. For example, optimization might mean that all files must be touched and reworked. This would be a not-easy bit to squeeze into a sprint.

Sometimes, trying to embed a new feature might become impossible due to high coupling of elements in the existing codebase. Decoupling components requires redesigning the relationships within the code. It is also a technical debt task which with time gets to be more and more “expensive”.

So, Technical Debt is a term that describes all the rework that will have to make its way to the Product Backlog and compete with new features and enhancements for developers’ time and the project’s budget.

The Structure of Technical Debt

In more formal ways, technical debt includes quite a few distinct categories. 

In the radial diagram above, you can see quite a few kinds of technical debt. Let’s briefly determine them.

Design Debt

It is when UX principles and best practices are violated or not implemented properly. For instance, proper user research, prototyping, wireframing, and usability testing might take 4-6 weeks. In a rush, this functionality gets 1 or 2 weeks of a project’s time. 

Code Debt

These are the issues with code maintainability or readability. Often, there are no standards for how developers write and organize the codebase. Some developers might do overly complex things, and others might go for hacky one-liners. The Product Owner can introduce code reviews as well as delegate developing the company’s standards or introducing linters and code formatters. 

Defect Debt 

The Product Owner postpones dealing with defects discovered during QA. For instance, a button is slightly misaligned, or label text is overflowing a little on some screen sizes.

Architecture Debt

These are violations of separating logic into layers, keeping things in their respective modules, lack of abstraction when using newer third-party tools, etc. This can occur if you start with one or two developers. They simply might not see a need to spend an extra couple of hours to design proper abstraction as they work closely. 

People Debt

It stems from the lack of specific skills or knowledge, high turnover, and other people-related issues. These can come both from tight budgets and strict deadlines. Sometimes, it is possible to get the qualifications you need, but it takes a long time to source such a developer.  At other times, you might have a budget only for a junior developer who will implement the complexity but it might result in performance issues.

Process Debt

It refers to misaligned or outdated team organization practices or processes within the business. For instance, a lack of retrospectives might cause issues or inefficiencies to go undetected.

Test Debt

This includes poor test coverage or not running scheduled tests. In some development methodologies, the Product Owner authorizes only basic tests and it is on purpose. The MVP app, for instance, is simply seeking to gain traction for basic functionalities. So, the management defers doing comprehensive testing until the growth stage. 

Requirements Debt

This is a mismatch between project requirements and the implemented functionality. Sometimes this can occur because the requirements evolve during the project. In other cases, it can be due to the scope creep when new functionalities are added on the go. 

Documentation Debt

This type of debt ranges from missing and insufficient documentation to outdated, inconsistent, or confusing one. During fast-moving development cycles when developers do last-minute code submissions or tweaks, documentation is never a priority. They delay dealing with it when the backlog frees up. 

Infrastructure Debt

This refers to the company’s internal issues that create hurdles for developers. For instance, they get stuck with using outdated tools in their work. It can be a lack of investment in tools or people’s training. It can also happen if the senior developers are just set in their ways and prefer using their custom tools rather than new out-of-the-box solutions.   

Other Debt

There are other less frequently occurring types of debt. They can be connected to the build, automated testing, services, versioning, or usability.

The Causes of Technical Debt

In short, the number 1 reason is time pressure. The development team just needs to complete all the work on time, so there is no room for tinkering, organizing, testing, documenting, and whatnot. The developer takes a convenient shortcut. Then this bit of code starts causing trouble as your app grows and changes. 

Below, you can see the top 10 causes of technical debt by frequency of occurrence and impact on technical debt. 

Why should the Product Owner care about Technical Debt on a project?

Let’s imagine a Scrum environment where a team of developers led by a Scrum Master and a Product Owner set out to develop a custom iOS app -an e-commerce app. Let’s imagine a particularly common feature in the Product Backlog – a wishlist. Something like Amazon has (the screenshot below).

This piece of functionality permeates every screen of the app, has a dedicated screen, and includes other functionalities. So, it means:

• building the WishList component with adding, deleting, sorting, and filtering., 
• enabling adding to WishList from the product catalog, promotions, top products and whatnot with pop-up notifications; 
• Displaying the WishList Icon across the app with a number of items displayed.

This functionality always includes additions to the database and linking users to their respective wishlists. Let’s imagine a Product Owner has only one weekly sprint allocated for this feature. 

Having not enough time, developers take shortcuts:

• The WishList functionality is written into each component.
• They quickly draft queries to the database which are not necessarily optimized.
• The error handling includes generic error messages.  

The Worst Case Scenario of Poorly Managed Technical Debt

The Product Owner decides to pressure the team into completing the entire full-scope functionality. So, everything must be done with adding, deleting, sorting, and filtering. Every separate component must include the add/remove to wishlist functionality. Every action must be followed up with a pop-up. 

Result:

• Things are highly coupled – every component appearance on the page triggers a wishlist with its own network requests to the database. Every update or reload repeats all the requests.
• Since there was not much time to optimize network requests and the size of requests, the data transfer size is large. 
• Error handling is rudimentary leaving unclear messages.
• Page load times spike to a few seconds.
• Data transfer costs jump 10x. 
•  Frequent errors make users abandon the page. 

Those seem like heavy mistakes, but they are not. This is a development environment. The Product Owner can gradually address this debt. So, in our worst-case scenario, the Product Owner can make things much worse by not including in the Product Backlog these four items:

• Code refactoring for modularizing WishList functionality;
• Optimizing database querying;
• Optimizing data storage and the number of network requests;
• Graceful error handling.

As such, when in two to three weeks comes the time to introduce personalized recommendations based on the wishlist, the project is on the verge of collapse. Introducing workarounds to include personalized recommendations takes 3x more time than was allocated. The chances that the project will result in a smooth user experience are nearing zero. 

The Best Case Scenario of Skillfully Managed Technical Debt

The Product Owner realizes with the team that this functionality is critical and the time is tight. The Product Owner makes a decision to implement the basic version of this functionality prioritizing modularization from the get-go. It is common when you Develop Custom iOS app to prioritize smooth and fast UX. As such, the WishList does not have any filtering or sorting for now. There are also no pop-ups at present (but planned in the future). But, we do an indicator of the number of items in the wishlist. So, the Product Owner adds the following items to the Product Backlog: 

1. Completing advanced functionality with filtering/adding/pop-ups;
2. Optimizing database querying;
3. Optimizing data storage and the number of network requests;
4. Graceful error handling.

It might be a higher priority to complete numbers 2 and 3 first – to address some technical debt. So, over the next sprint, the team ensures lower data transfer costs. Plus, the impact of wishlist functionality on load times gets down to 200-300 milliseconds. 

Then, when the time comes to include personalized recommendations, the task takes less than a week compared to the worst-case scenario of 3 weeks. In addition, overall the user experience is fast and smooth with quick loading and smooth transitions, and the business owner enjoys lower costs on bandwidth. 

If you are going to develop Custom Android app, similar things apply to managing technical debt. You generally want to have cleaner functionality working smoothly.

All in all, it often pays off to have fewer features of great quality or have a simpler implementation of them than a lot of poorly functioning ones. 

FAQ: Technical Debt and Product Owners