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. However, technical debt is like a monster 👹 that the business knows exists but that it is afraid to talk about 🫣 or treats as an urban myth. Technical debt 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.
The engineering team 🤹, in the meantime, works on a superficially stable 😵💫 product, patching up 🩹 and building new features 🏗️ on an already leaky product. The team may say they cannot build features X, Y, and Z due to technical debt and can only deliver X1 and Y1. Product Owners (POs), who feel the pressure or act for personal reasons, may find an alternative path to squeeze the set of features into the release, thinking they achieved the impossible 🥳. However, this is a 🧨 mistake as it ignores feedback from the team. Ignoring technical debt not only lowers a team’s morale and trust but also leads to an unhappy 😖 and less motivated team.
As POs, we prioritize the customer experience, but our responsibility extends beyond users 🧑 and the business to our engineering team 🤹 and other stakeholders. Once you put everyone in the frame, you will notice the rough edges and gaps. We must assess the gaps 🎢 in our process, discuss and create a plan 📝 to address 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.
If you want to know the type of monster you are dealing with, please continue reading. Here are some steps I suggest.
Begin by allowing 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, products with stability concerns, or those that have not been actively managing tech debt. Product owners can help to 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.
Once the team has identified tech debt items, work together to understand and categorize their business impact, development impact, and cost of fixing. Use a simple scale, such as small, medium, large, and extra large, to categorize the 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 the 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.
Prioritize addressing tech debt with high business and high development impact first. For example, this could be an app or site that not only frustrates users and leads to lost revenue, but also slows down the development team. 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 the impact of tech debt and determine 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 tech debt and make space for these items on the product roadmap.
Prioritize tech debt items with low development impact but high business impact based on their potential impact on the user experience or business goals. An outdated payment processing system is an example of such tech debt, which may not directly affect the development team but can cause users and the business to suffer. These tech debt 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 the 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 particular piece of code can improve performance and reduce the risk of defects in future releases. It’s important to approach these conversations with empathy and understanding and 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.
Lastly, you have low development and low business impact tech debt to address. While these items may seem trivial, they can still add up and create technical debt. For example, the unused code or feature in the product clutters the codebase and might make it difficult to maintain over time. For this category, evaluate each item and consider its long-term impact on the product. For those that are strongly connected to the product roadmap and goals for the year, knock them off. 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, then carry them over to the next year. But if ignoring the debt increases its impact, prioritize and create an action plan.
Remember, it’s important to regularly review and address tech debt as part of your product development process. This helps maintain the health and stability of your product and ensures that the development team can work efficiently and effectively. By prioritizing and addressing tech debt, you can create a culture of continuous improvement and quality, and ultimately 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.
