We're in the midst of a tech-wide effort at BuzzFeed to "aggressively pay down technical debt," so as a product manager I've been thinking about what that means for non-engineers, and how everyone who works on a product has the ability to influence tech debt for better or worse. It's tempting to think that tech debt is primarily a concern for engineering, with product taking a backseat. That temptation is a trap.
What is tech debt?
Not all debt is equal. Some debts, like mortgages or loans to start a new business, are good kinds of debt. You still want to pay them off, and having too much of this kind of debt or tying it to unwise investments can get you in trouble, but when used properly good debt lets you do things that you wouldn't otherwise be able to do. On the other end of the spectrum there's bad debt like a payday loan, the kind of debt that is never a good idea to hold on to for even a short period of time if you can avoid it.
The same is true of technical debt. Sometimes you'll "take out a mortgage" to build something you wouldn't otherwise be able to afford all at once. One category of tech debt that's often worthwhile is building something that won't scale, for example, building an API that can't handle millions of requests when for the foreseeable future you only need it to handle thousands. (This is especially true when scaling that product later can be done primarily by building on top of what's already been done rather than through a massive refactor.)
There are other kinds of "bad" tech debt — loan shark tech debt — that ideally wouldn't be taken out in the first place, like kludgy quick fixes and deviations from coding standards. This is the kind of stuff you know is debt the moment you create it, which is a sign you should stop right there. You're making future work for yourself and others without much upside.
Why tech debt is product debt
Product managers and other product-minded people have significant influence on ensuring both that "good" debt is used responsibly and that "bad" debt is avoided. Good debt is used responsibly when it has clearly defined parameters and you stick to a repayment plan. Bad debt is created through poorly thought out one-off product decisions, and through failing to adequately communicate with and empower your team.
At a high level, the most important thing a product manager can do to minimize bad debt is make sure there's a clear short and longterm vision for the product, and that everyone working on the product fully understands it. You know you've done a bad job at this when you propose a new feature to your engineering team and they say "oh, if we knew that was coming we would have built everything totally differently" and then disappear into a refactor sanctum for a month. Or if product designers have to completely reimagine an interface because what you thought would be a small addition can't be accommodated properly without changes to the tool's information architecture.
The next most important thing a product manager can do to minimize debt is make liberal use of two syllables: "no" and "why." Saying "no" is important because it is the only way to manage scope and maintain focus, but it's hard because we want to make people happy and achieve quick wins. Asking "why" is important because it can get at root problems and reveal better, higher value solutions, but it's hard because determining root problems and ideal solutions takes a lot more work than implementing the idea that's already on the table.
I can think of many examples of where I've failed at this. "Could we just add a button that sends me an email notification?" Sure! "Can you hide the dropdown for anyone who came through this referral path?" You got it! "Can the logo be 5px wider on Tuesdays?" Yeah it can! And now you've got a hopelessly complex codebase that no one fully understands and is prone to breaking in unpredictable ways. That messy, unclear code is very often a direct result of messy, unclear product direction.
Even product decisions that may have been a great idea at the time don't always remain a great idea over time. In these situations the existence of product bloat that contributes to debt doesn't necessarily mean that the earlier features were ill-conceived, just that they haven't been revisited and reevaluated as other factors have changed.
Once you've gotten yourself into this position, revisit past decisions with a bias towards reducing complexity and removing features. Since unnecessarily complex products also tend to be buggy projects, bug reports are one great indicator of which product areas might need to be reconsidered. "Oh, that feature is broken? Remove it entirely. Now it'll never be broken again!"
Keeping a good credit score
So, keeping "bad" technical debt low happens upfront with the decision to not build something, or by making sure the team has enough information and time to build it well. It's important to do this at the outset of "good" technical debt projects too, but an even more common pitfall with those kinds of projects is failure to repay the debt when it comes due.
When you decide to take on good technical debt, the team should define its equivalent of "mortgage terms." Why do you think taking on this debt is worthwhile? How will you know when it's time to pay it down? How much work is going to be involved in retiring this debt, and are you going to hate Past You when you have to do it? Then, once those repayment conditions you defined are met ("user needs are no longer being addressed," "the system is at 70% capacity," etc.) you need to set aside time to make good on your commitments.
Bottom line, the phrase "technical debt" is dangerous because it tempts product managers and designers into thinking that tech debt is an engineering problem they can safely ignore. Reframing tech debt as product debt forces everyone working on the product to think about how they inevitably participate either in paying debt down or racking it up.