How to convince your product stakeholders to pay down technical debt

Your product has accrued some technical debt and there are early signs that it may soon rise to bite you in the ass. Your developers have raised the issue multiple times and as the product owner, it’s on you to make the case for fixing it to the rest of the stakeholders.

But you’re worried it will be a tough sell. This isn’t a quick fix and the Marketing and Sales Managers want to ship a large new feature ahead of a campaign launch deadline and they won’t be happy with engineers being pulled away from this onto non user-facing or revenue-earning tasks. What happens if they don’t see the return on investment and just say no? Then you’re left with the painful task of delivering the bad news to the development team and asking them to just live with it.

But with a little bit of preparation, you can avoid disappointing your devs and ensure your pitch gets a “yes” from the other stakeholders.

Understand the risks of not addressing the debt

Technical debt can come about for many reasons and can be either as a result of a deliberate past decision (e.g. taken to accelerate time to market), or accidentally, as an unforeseen side effect of a process or architectural design decision. It does not necessarily need to be a fault with an existing component of the product, it could simply be the lack of an important non user-facing operational component or process (e.g. an automated build script or server monitoring).

Irrespective of how it came about, in order to make your case for fixing it to the stakeholders, you need to quantify its impact on the product and your business overall. To do this, you need to first talk to the developers closest to the issue to get a deep understanding of the scope of the issue, and then translate the technical aspects into something everyone else can understand.

The development team should be able to help you categorise the impact into one or more of the following areas:

• Reduced velocity of development — affects speed to market for new features
• Higher probability of bugs or downtime — affects user happiness and churn rate
• Performance degradation — affects user happiness and churn rate
• Security vulnerability — affects user trust and churn rate
• Compliance penalties — risks of legal action

Try to put concrete numbers around the risk areas to give credibility to your pitch, even if they are estimates. For example:

“On average this is costing us 8hrs per sprint doing manual testing or workarounds.”

“Average load time for search results has increased to 4 seconds, up from 0.75 seconds 2 months ago.”

Provide multiple options for fixing it

Once you’ve defined the problem, aim to come up with 2 or 3 different costed implementation options to present to stakeholders. Depending on the nature of the technical issue, providing multiple options may not be possible (e.g. upgrading database to a new major version), but by giving them a choice, you’re decreasing the probability of an outright “no”.

Here are some different angles to approach it from:

• Implement a stop gap fix which mitigates a portion of the risk with less effort.
• Incrementally implement the full fix over time (e.g. apply fix to just one page/component and then roll it out to others in future sprints).

Set expectations in advance

You can pre-empt these difficult discussions with stakeholders by making sure technical debt items are on their radar well ahead of when they need to be fixed. You can do this by using a Technical Debt Register. This is simply a document (or a wiki page) with a list of all known technical debt items in the product today which left unresolved could have a significant business impact.

Each register entry should contain:

• A description of the impact and what users/components could be affected (in non-technical terms)
• Reason why the debt was incurred
• Estimate for when it may need to be resolved (either a calendar date or upon a specific event trigger)
• High-level solution options, with ballpark estimates

An added benefit of creating the register is that when compiling it with your dev team, you may uncover new risks which were in the heads of some developers but hadn’t been communicated to you.

Note: This register isn’t a substitute for your product backlog, and you should still maintain items for all technical debt tasks on your product backlog.

Recap

• Talk with your developers to identify the scale and scope of the risk, if left unaddressed.
• Phrase the problem in a way that non-technical stakeholders can easily understand.
• Aim to provide 2 or 3 options for resolution in order to increase your chances of getting approval.
• Provide concrete figures around both the impact of doing nothing and benefits of each fix option.
• Maintain a Technical Debt Register to pre-empt awkward future pitches by keeping all stakeholders aware of all known technical debt and when it may need repaid.

That last point is something you can get started on today.