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

Very often, and honestly, it should be a standing agenda item, not a periodic conversation. For mature products, tech debt is rarely invisible. It shows up in: Slower shipping velocity: features that should take days take weeks Fragile releases: every deploy feels riskier than it should Engineer frustration: a signal that's easy to dismiss but costly to ignore My approach is to treat tech debt like any other roadmap item -> prioritize it, size it, and tie it to business impact. "We need to re ...Read More

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: It does what its suppose to do We can maintain it We can evolve it So when I am working on a mature product I ...Read More

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 ...Read More

As often as it needs to be, but understanding why it needs attention is the real answer. Mature products accumulate technical and product debt just from years of decisions, tradeoffs, and "we'll fix it later" moments that never got prioritized. In the past I have worked with my technical lead to identify known technical debt and understand the cost/benefit of fixing it. Some things have real due dates, others can limp along indefinitely as is. A next step is to look for the unknown unknowns—area ...Read More

Tech debt becomes a looming issue in every quarterly planning. It manifests itself in many ways, such as: 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." 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 servi ...Read More

Tech debt should be considered at every stage of a product’s lifecycle, but it becomes materially more important as a product matures. Mature products have accumulated years of iteration, and each iteration leaves new layers of tech debt.  What changes at scale is the cost of failure:  A small infrastructure issue that’s tolerable at MVP can be catastrophic in a mature product as a result of customer volume, nuanced edge cases, operational load, regulatory and reputational impact, and financial ...Read More

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 rel ...Read More

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: Regular technical reviews: I schedule regular technical reviews with my development ...Read More