How often is tech debt considered when working on a mature product?

The thing to keep in mind with mature products is work does not stop. If you are doing a good job as a Product Manager you will continue to find new customer problems, enhancements to your existing product and ways to create more differentiation. In order to do this work you have to make sure your technology stack is in a good spot. I always say there are three aspects of good software:

1. It does what its suppose to do

2. We can maintain it

3. We can evolve it

So when I am working on a mature product I am constantly asking my engineering team where is our tech debt building, what are the implications of that, what benefits do we get if we solve it. I always want to make sure I can maintain and evolve the technology that powers our products.

The unsatisfying, but honest, answer is “it depends.” As a general principle, addressing tech debt should be a continuous consideration. Without it, you put your product’s long term security, reliability, and scalability (both in terms of handling new users but also in terms of being able to quickly implement changes and updates) at risk. 

That said, how often you’ll need to spend development calories on addressing tech debt is contingent on a variety of factors: 

• Overall technical architecture of your product

• Past decisions (did former teams cut corners? How often, and how much?)

• Your company’s overall willingness to prioritize maintenance and tech debt vs. new feature development

Tech debt is an ongoing input into the product roadmap process, especially for mature products that may have a higher probability of tech debt in the code base.

I usually have the following inputs to my roadmap process:

• business goals and strategic product priorities

• user friction (eg: adoption blockers etc.)

• market and sales priorities (eg: is delivery of a feature important to win against a competitor in this cycle)

• internal priorities (eg: technical debt, infrastructure upgrades etc.)

The relative priority of tech debt depends on how severe it is vs. new feature development, and how much it is hindering user workflows.

For example, if tech debt is making it increasing challenging to maintain the product, or it is affecting reliability, availability or security of the product, or it is making it hard for devops to run production services, those merit adding tech debt removal at a higher priority in the product roadmap.

There have been times when, as a team, we have decided to completely halt new feature development for a quarter, to get the tech debt and related issues under control.

Tech debt becomes a looming issue in every quarterly planning. It manifests itself in many ways, such as:

1. Rising customer escalations due to new code causing regression issues. This happens when there isn't enough unit or integration test coverage to test all the "legacy code."

2. Launch-driven product development causes teams to "cut corners" and leverage technology that needs to be reversed, as it may not scale or work for all deployment types. A simple example would be using a cloud-native service that needs to be reversed if the product needs to be available on multiple cloud platforms.

A product development team must prioritize tech debt as a percentage of new feature development, as waiting too long can cause catastrophic product failures. For example, regression bugs caused by new features can sometimes prevent user access to the product, resulting in millions of dollars in losses for the customer and the business.

It's essential to regularly evaluate and address tech debt as it can significantly impact a mature product's overall health and sustainability. If left unaddressed, it can build up and require a massive focus from the team that can disrupt existing customers or prevent you from adding new customers to the product until addressed (this is something I've run into before, and it's no fun!).

Here's how I approach it:

1. Regular technical reviews: I schedule regular technical reviews with my development team to identify any technical debt that has accumulated and determine the best way to address it. We typically have a staff-level engineer or dedicated architect who can provide regular guidance and reviews as we build to ensure we consider the larger technical vision and the scale we need to deliver.
2. Budget for tech debt: I allocate a budget specifically for addressing tech debt and ensure that it is included in our development plan. I use three buckets at the team level to align what percentage of our overall capacity to devote to each: Innovation (new features, new products), Iteration (incremental enhancements), and Operation (tech debt, bug fixes, etc.).
3. Incorporate tech debt into prioritization: Once you have the target capacity allocation across the big three buckets, you can incorporate tech debt into the product backlog and prioritize it alongside new features and enhancements. This helps ensure that you take a proactive approach to reduce tech debt and improve the product's codebase.

In conclusion, considering tech debt is an ongoing process when working on a mature product. By regularly evaluating and addressing it, you can ensure that your product remains healthy, scalable, and sustainable over time.