Technical debt 🏦 is often accumulated and ignored in software projects that are struggling with quality, timelines, and expectations. Instead, teams focus on fixing bugs, adding new features, and building quickly. Ignored tech debt is like a monster 👹 that the business knows exists but that it is afraid to talk about 🫣. This monster only becomes a priority when it becomes a blocker or costs more money. Until then, the business assumes that the team will simply learn to live with it.

In the meantime, the engineering team 🤹 has to work on a superficially stable 😵‍💫 product. They patch up 🩹 and build new features 🏗️ on an already leaky product. The team may say technical debt is stopping them from building features X, Y, and Z. They can only deliver X1 and Y1. Some Product Owners (POs) may find an alternative path to squeeze the feature set into the release. They think they’ve achieved the impossible 🥳. In reality, ignoring team feedback is a 🧨 mistake that lowers morale and trust. Over time, you end up with an unhappy, 😖 less motivated team.

Prioritizing a Collaborative Product Experience

As POs, we prioritize the customer experience. But our responsibility extends beyond users 🧑 and the business. We must include our engineering team 🤹 and other stakeholders. Once you consider everyone, you will notice the rough edges and gaps. We must assess the gaps in our process, discuss, and create a plan 📝. We need to focus on the immediate and larger gaps, and set timelines to address others. The earlier we resolve these problems, the better.

I have come to realize by focusing on the collaborative product experience, including all primary stakeholders, and not just the customer experience, we can create a better outcome 📈 for all. We must set aside time on our roadmap 🌎 to review and address technical debt. Give time between releases for teams to recharge themselves 🏖️, reflect on their work, and come up with ways to improve the collaborative product experience 💡. It’s possible that tech debt is not the monster 👻 we always thought it was. Or, perhaps worse, we’ll find that by ignoring tech debt for so long that it was us who made it into a monster 👹. You will never know until you look.

Understanding Ignored Tech Debt

If you want to know the type of monster you are dealing with, keep reading. Here are some steps I suggest to deal with ignored tech debt.

Allow the development team to conduct a technical audit to identify and compile a list of tech debt items. 

This process can be time-consuming, especially for teams that work on legacy infrastructure, unstable products, or systems where tech has not not been actively managed. Product owners can focus the team’s efforts by providing specific goals for the next few releases or for the year ahead, allowing the development team to review connected pieces and identify potential blockers.

Work together to understand the business impact, development impact, and cost of fixing each item. 

Use a simple scale, such as small, medium, large, and extra large, to categorize the ignored tech debt. Development impact refers to the effect of tech debt on the product from a technical point of view, the development team’s job satisfaction, and the team’s morale. You may also consider other factors relevant to your development team.

Map tech debt items on a chart against business and development impact. 

The size of the circle should correspond to the cost of fixing. This will help you to prioritize which tech debt items to address first.

Address debt with high business and high development impact first. 

For example, this could be a mobile app or site that not only frustrates users and leads to lost revenue, but also slows down development. Everyone should be motivated to eliminate small and medium-size circles within the current development cycle, but larger circles may require a conversation. Collaborate with the business and development teams to understand tech debt impact and if larger circles can be split into smaller ones. Resolve as much tech debt as possible while meeting release goals, and ensure everyone understands the cost of delaying or not fixing tech debt. Develop an action plan and timeline for revisiting remaining debt and make space for these items on the product roadmap.

Prioritize items with low development impact but high business impact based on potential impact on the user experience or business goals. 

An outdated payment processing system is an example of such tech debt. It may not directly affect the development team but can cause users and the business to suffer. These items may surface in the future as feature requests, so it’s crucial to address them sooner when the impact is smaller rather than later. Categorize and prioritize these items based on their impact on the business and development, and create an action plan to address them.

Next, focus on tech debt with high development impact but low business impact. 

While these items may not directly affect the business goals, they can have a significant impact on the development team’s ability to deliver quality products. Examples of such tech debt include code refactoring, code optimization, and writing unit tests. To prioritize these items, work with the development team to understand their impact and estimate the cost of fixing them. Then, identify a use case or scenario that demonstrates the value of addressing the tech debt, and present it to the business stakeholders.

For example, you can show how refactoring a piece of code can improve performance and reduce risk in future releases. It’s important to approach these conversations with empathy and understanding. Your goal is to help the business stakeholders see the long-term benefits of addressing the tech debt. By investing in the development team’s productivity and morale, you can help them deliver better products faster with higher quality and confidence.

Save low development and low business impact debt to address last. 

While these items may seem trivial, they can still add up. For example, the unused code or feature in the product clutters the codebase and might make it difficult to maintain over time. In this category, evaluate each item and consider its long-term impact on the product. Start with those that are strongly connected to the product roadmap and goals for the year. For the remaining items, analyze and understand what happens if these tech debts are not fixed in a year. If the answer is little to no change in size and impact, carry them over to the next year. But if ignoring the debt increases its impact, prioritize and create an action plan.

Long-Term Benefits for All

Remember, it’s important to regularly review and address tech debt during your product development process. This helps maintain the health and stability of your product. It also ensures that the development team can work efficiently and effectively. By prioritizing and addressing previously ignored tech debt, you can create a culture of continuous improvement and quality. As a result, you’ll deliver a better collaborative product experience. Ultimately, a positive and motivated team is essential for the success 🌟 of any project, and it is our responsibility as POs to ensure this. Do the right thing for your people and product.

This post was contributed by Rushi Pol, the Product Owner Craft Steward at Robots & Pencils.