It’s one of the more frustrating parts of being a software Product Manager – you inherit a product that’s been around for awhile, and every time you want to start a new project to change and improve what’s already there, some nasty little issue crops up and takes the spotlight.  Maybe the platform was never really designed to scale, maybe some customer is doing something outside the original intent of the product, or maybe the technology is just old and starting to crumble around the edges.

Regardless of the specifics, inevitably the primary cause of these issues is a mountain of technical debt that’s been built up by the teams working on the product over the course of its lifecycle — the shortcuts taken in the name of getting product shipped, the design corners skimmed because it was seen as an “edge case” three years ago, or even the architectural limits imposed by budget or resource constraints.

Regardless, once you realize what’s causing these issues, you need a plan to attack and mitigate the harm that these limitations are causing you — and that’s where you good old friend, The Clever PM, has a few tricks up his sleeve…

What is Technical Debt?  (And What Isn’t…)

The idea of “technical debt” has its origins (as do a lot of things) with the Agile software movement, and refers to the inevitable and unavoidable consequences of focusing on delivering useable software over analysis paralysis and over-specification.  Essentially, technical debt is comprised of those things that you decide not to do now, that will eventually have impacts on things that you may want to do in the future.  In most Agile environments, technical debt is unavoidable, and that’s not necessarily a bad thing.  Focusing on delivering software now that solves a current market or customer product is the goal; over-architecting, over-analyzing, or over-coding those solutions just delays the launch and feedback loops unnecessarily.

However, many companies fail to understand that (1) technical debt is unavoidable, (2) technical debt stacks up, and (3) technical debt must be repaid.  Decisions not to do something right now should not be viewed as decisions to never do them in the future; as the situation “on the ground” changes, so must our plans and our execution.

On the other side of the spectrum are the things that nobody thought of, no decisions were made on, and which are not technical debt.  If you started your product as an SMB solution that would support X number of customers at a time, then decided to move up into a higher strata of client with a greater number of users, that is not technical debt; it’s a new market segment that you’re targeting, and it needs to be dealt with like new feature requests, not shoehorned in to your allotments for repaying technical debt (see below).  It’s a very common situation for development management or CTOs to try to position these major shifts in product strategy as “a miss” or as technical debt, but don’t let them do this.

When deciding if something truly is technical debt, consider the following:

• Is it related to functionality that was previously designed, developed, and released?
• Were design, development, or release decisions made that align with the claimed technical debt?
• Have new technologies, use cases, or management “caused” the complaint to rear its head?

The first two are indicators that the request probably is technical debt; the last one is an indicator that it might not be.

Making Room for the Constant Shuffle

Now that you know what is and isn’t technical debt, what do you do about it?  Well, the simple answer is that you have to make time for your teams to tackle the known technical debt that the product has incurred in its life, and you need to plan for some percent of the teams’ time addressing these — either as they come up or proactively to prevent issues.  In mature B2B environments, I’ve seen these efforts take up to 25% of a teams’ active development time, which initially seems like a lot, but it’s actually very manageable.

First, you need to track technical debt just like you would any other user story that the team works on — it doesn’t have to have a story associated with it, but it should have a place in your tracking system, should be estimated like your user stories, and should have a “slot” in your planning efforts.  Tracking technical debt work in this way allows you to be entirely open and transparent with your management team about what the teams are actually working on and what’s actually taking up their time.  It positions you to explain that the new feature that everyone wants is delayed not because of a lack of interest, but because the teams are keeping the foundation of the product from falling apart.

Ideally, in addition to tracking these items of technical debt like you do user stories, you should also be researching them in the same vein.  You should know what the incidence rate is of issues associated with the debt, what the best-case and worst-case scenarios are, what the critical path is to resolving them, and any interim, stopgap measures that can be taken to mitigate harm (which incur additional technical debt to deal with later…).

Collaboration = Cooperation

One of the best ways to deal with technical debt is to work it in to your triage meetings with your other stakeholders — you are having regular meetings with your stakeholders to report issues, right?  Just add in development alongside your services, support, and sales teams, and have them represent the technical debt side of the equation, which naturally fights for exposure and prioritization against everything else.  Don’t make the mistake of treating technical debt as some “special” thing that only you and the dev team can understand.  Make it open, make it transparent, and make development’s requests stand up to the same scrutiny that others’ requests must.  While as Product Managers we often work very closely with our development teams, in the day-to-day business of the product, they must be treated as simply another set of stakeholders, and their concerns need to be as open and transparent as anyone else’s.

The other effect that this has is to normalize and demystify development’s needs in front of the whole company — especially when there is a large contingent of non-technical stakeholders, having development managers or team leaders there to explain in plain-business terms what the impacts are of this technical debt gives them a glimpse into how the whole machine works to achieve success.  These glimpses behind the curtain build a sense of camaraderie, and reinforce the fact that everyone really is working toward the same goals, even if they’re doing so through sometimes obscure and arcane means.  Bringing your development team to the table with their technical debt needs is a win-win for everyone involved.