How technical debt helps product teams get actionable feedback

But technical debt isn't just an engineering issue. The entire product team needs to be aware of technical debt: what it is, what it's not, and how it can actually help your team. And as a product manager, you play a big part in how your product team handles technical debt.

Keep reading to learn:

• What technical debt is

• What it isn’t

• What causes technical debt

• The pros and cons of technical debt

• A product manager’s relationship with technical debt

• How Hotjar can help you manage technical debt

What is technical debt?

Technical debt is a metaphor used to explain the buildup of deficiencies in code quality that make code difficult to modify for new features. The extra effort required to add new features due to these code deficiencies is similar to the interest you pay on financial debt.

Code deficiencies occur for various reasons, including coding shortcuts, unnecessary complexity, and bad coding practices.

Even the most skilled developers have concluded that technical debt is a fact of life. According to members of the Agile Alliance technical debt program, “the question is not whether there is technical debt, but instead, how much there is, and how much impact it has on individuals, the team, and the organization.”

4 types of technical debt

Martin Fowler, an expert in software development and architecture, described four types of technical debt based on whether the debt was introduced deliberately or inadvertently and whether the introduction was reckless or prudent. You can, as you would expect, show the four resulting types in a 2x2 matrix:

1. Inadvertent and reckless: code deficiencies are introduced by a team that may be unaware of good code design principles, and therefore unaware of the mess they're getting themselves into. To pay down this debt, you have to address the deficiencies and train developers in good code design practices.

2. Deliberate and reckless: code deficiencies are introduced by a team that knows good coding practices but writes 'quick and dirty' code to save time. To pay down this debt, the team has to refactor the code to incorporate the good coding practices they chose to skip the first time around.

3. Deliberate and prudent: code deficiencies are incurred when a team follows good coding practices but intentionally takes a faster route to release early and learn from feedback. This represents a form of scrappy product management, where your team acts decisively to prefer speed over completely clean code. You pay down the debt you incur in this situation by refactoring the code if feedback shows the feature is worth keeping.

4. Inadvertent and prudent: code deficiencies are incurred by developers who follow good design practices and learn—through building the product—what the code design should have been. To pay down this debt, the team refactors the code to match the preferred design.

These four types of debt serve as a reminder that you can choose how to incur technical debt. You can take shortcuts to shorten your feedback cycle, just like businesses incur debt to add equipment or people that’ll drive more revenue in the future. The key is to explicitly make a choice and consider the consequences.

What isn’t technical debt?

You may be tempted to apply the 'technical debt' label to anything that slows development, but that can be counterproductive. Some things labeled as technical debt are caused by other issues, and it’s helpful to know the difference so you can use the right approach to address each of them.

Here are some issues that slow down development but are not technical debt:

• Identified defects:

  this is a case where code does not behave as intended due to incorrect coding rather than poor design practices.

• Lack of process or poor process:

  if your team exhibits one or more product workflow red flags, such as relying too much on A/B tests or trying to make too many instant improvements, it could indicate an inefficient process.

• Wrong or delayed features:

  this is a sign that your approach to product backlog prioritization may need some work.

• Inconsistent or poor: user experience this may be a sign of insufficient or non-existent design practices.

Directly address these types of issues if they show up. Don’t falsely label them as technical debt, or you may try to address them with the wrong approach.

What causes technical debt?

When your team understands what causes technical debt, you can minimize the amount of technical debt you incur inadvertently. That way, you're in a position to take on debt deliberately.

The main causes of inadvertent technical debt include:

• Development shortcuts:

  developers solve a particular coding problem using the first approach that comes to mind without considering how easy (or difficult) the code might be to change or extend in the future. The most common shortcut that causes tech debt is to copy/paste without adjusting the code to appropriately fit its new use. Other common shortcuts include only coding to address a specific situation, and failing to ensure code is covered by unit tests.

• Obsolescent technology or approach:

  you continue to build your solution with libraries or a full tech stack that is no longer sufficient for the job you’re trying to accomplish, or that can't scale with your solution or team.

• Lack of coding standards:

  your team hasn't agreed upon coding practices to follow, so practices are inconsistent and differ from developer to developer.

As we said though, there’ll be times when your team explicitly chooses to take some coding shortcuts. This generally happens when there’s an opportunity to release your product quickly so you can get feedback right away.

When you make that choice, plan (in a near-future sprint) to address the technical debt incurred from moving fast. Just like financial debt provides benefits now that you have to pay back later, technical debt allows you to get feedback now, but you have to pay back the debt later.

What are the pros and cons of technical debt?

Understanding the pros and cons of technical debt comes down to knowing when (or if) technical debt is beneficial and when it could be detrimental to your product team. To get a real understanding of the pros and cons of technical debt, we reached out to some product managers to get their perspectives.

When is technical debt beneficial?

Technical debt is beneficial when it allows your team to quickly deliver a product or feature and get insight into whether it fulfills your customers' needs.

Jon Harcey, a product manager with experience in agribusiness and financial services, says, “The only time debt is beneficial is when it allows your team to move quicker to get a feature delivered for experimental purposes. Beyond an experiment, you run the risk of that becoming permanent debt. Experiments should be quick and dirty so you can decide if you want to actually build the feature for full scale.”

Gautam Banerjee, managing director at Velocity Labs, adds that incurring technical debt has been beneficial “when time-to-value is the key driver, or time-to-learning is minimized significantly (e.g. doing an experiment).”

In other words, you benefit from technical debt when your team intentionally decides to incur it to learn something about your product.

When is technical debt detrimental?

Technical debt is detrimental when it slows down your team. If you build up a lot of technical debt and don’t address it, you have to account for that in a cost of delay analysis.

Jon explains that this detrimental impact shows up “when there is so much debt that no other features can be built because all of your teams are so busy trying to catch up frameworks.”

And Gautam says technical debt “creates a drag (a tax!) on new feature work measured in increased time/effort and frustration from the dev team.”

What is a product manager’s relationship with technical debt?

Product managers have a very complicated relationship with technical debt: technical debt slows down their team’s development efforts—but at the same time, PMs often ask the engineers on their team to code something 'fast and dirty', even though that’s what causes technical debt in the first place.

Let’s look at why product teams should care, and what they can do to reduce the impact of technical debt.

Why should product managers care about technical debt?

Jon suggests that product managers should care about technical debt because when it builds up too much, it limits your team’s options for modifying your product:

“Large amounts of tech debt—and I'm talking about letting frameworks (Angular JS, .Net, vendor tools, and so on) get so far out of date that the old framework will no longer be supported—leave an almost insurmountable amount of work, that some teams will decide it's easier to completely rewrite the application.

This takes a considerable amount of effort that could have been avoided by keeping things up to date. It's often easy to upgrade one version at a time with minimal interruption, but let that fester too long, you have a year or more worth of work on your hands.

Not using the most current technologies limits the team's ability to innovate. Frameworks are updated for a reason, because there are new and exciting opportunities that can enable innovation.”

Michelle James, a Scrum Master at Wells Fargo, believes that product managers, and product teams in general, should care about technical debt because it forces decisions between introducing new features and maintaining existing features.

Michelle states that product teams “should care enough to know whether or not [technical debt is] really needed. If it can be sprinkled in among customer needs and if the product is future state. It is definitely a challenge to balance but if you work in collaboration with a tech manager both needs can be met.”

Gautam adds that product managers should care about technical debt because of the financial impact it has: “you can often articulate ROI in terms of reduced maintenance costs or reduced effort for features in the roadmap.”

6 tips to help product managers address technical debt

Even though technical debt is primarily an engineering matter, product managers should play a part in addressing it: set aside time for your team to address tech debt regularly, and ask for a business case when your team wants to incur debt intentionally.

Jon shares six tips to help product managers address technical debt:

1. Understand what technical debt is. (Start at the top!👆)

2. Introduce flags and toggles when you build a new feature to segment which users have access to it. This helps you perform isolated tests to get precise, actionable feedback.

3. Don’t let frameworks get too far out of date.

4. Keep track of how much debt your team has accumulated.

5. Encourage and empower your engineering team to speak up when debt becomes unmanageable.

6. Leave time for your teams to recuperate from building features. If you're constantly pushing your engineering team to deliver feature after feature (especially without considering the value they bring) you’ll start to accumulate a lot of debt that becomes harder to pay off.

How can Hotjar help you manage technical debt?

Hotjar's Incoming Feedback widget helps you take advantage of intentionally incurring technical debt by collecting real-time user feedback, and sending that feedback to your team so you can act fast.

For example, if you decide to incur technical debt so you can quickly get a new feature into the hands of customers, you can use the Incoming Feedback widget to get your customers' impressions of the feature when they start using it.

If the feedback you get indicates your customers are happy with the feature, you can refactor your code to make sure it scales.

If the feedback you get indicates your customers don’t care for the new feature or the feature contains bugs you weren’t aware of, you can remove it, saving the extra work you would have put in otherwise.

Hotjar's Session Recordings help you manage tech debt by revealing the impact of technical debt on your users.

For example, you can watch recordings to see how customers are using a new feature to help you decide which aspects of your code should be refactored to address technical debt and which areas you can live with for the time being.

If you see that a particular feature is used a lot but is causing a poor user experience—users seem to get stuck using the feature because of incurred technical debt—you can prioritize refactoring that feature.

On the other hand, if you notice that the technical debt in a feature does not impact the user experience, you can choose to hold off refactoring it, freeing your team to focus on the areas that need immediate attention.