Why Product Debt Won't Die
We’ve all heard of technical debt, and many of us have grappled with it first hand: DRYing up that wet code, upgrading libraries and dependencies, removing that pattern the team decided wasn’t such a good idea after all, etc. It’s actually something that we talk about a lot: there are about 1850 posts on Medium dedicated to tech debt in the last year alone. Ultimately, though, tech debt doesn’t affect the user—at least not directly. So why do talk about it so much?
My hypothesis is because it’s annoying. Engineers have to look at and work around and be reminded of technical debt every day. It’s ugly and in-your-face. Getting rid of it might be tedious, but it feels good in the way that cleaning your house feels good: you know that when you’re all done, your home will be a nicer place to live in.
This also explains why we don’t talk about product debt so much: because lots of the time, we’re not the ones actually using our products. Sure, your company may dogfood its software. If you make accounting software, maybe your accounting team uses it. Or if you make an applicant tracking software, your company’s recruiters may do all their business with it. Or if you make a website builder, maybe your homepage is built with it.
But at the end of the day, the majority of people at your company are spending more time building the product than actually using it. So technical debt is obvious, and product debt simmers just below the surface, and individuals don't want to clean it up because that would be like cleaning your neighbor's house. We don’t even talk about it! Remember those 1850 Medium posts about tech debt? For product debt, there are fewer than 50.
There’s another difference, too: in many cases, technical debt is intentional, and product debt is accidental.
More often that not, tech debt is willingly taken on by the team. It’s the result of a ubiquitous tradeoff described by a weird fetishization of “hackers” and a hundred pithy catchphrases: “ship it”, “launch fast, iterate faster”, “get shit done”.
The point is, the industry has reached an equilibrium that usually kind of works, where features get pushed out the door with some t’s uncrossed and some i’s undotted, propelled by the belief that user adoption is a precursor to code quality. Then, we build into the roadmap a few cycles of bug fixing and debt collecting, and everything is okay. Every once in a while, some enterprising engineer takes it upon herself to update some libraries or bump a few dependencies, thereby clearing out the pesky warnings that dirty up each build, and she’s lauded as a minor hero. The debt collector is paid. The house is clean. Everything is okay.
But more often than not, the product debt is never collected.
See, product debt accumulates unintentionally. Nobody says, “we need to get this feature out, but we’ll make a ticket to refactor this thing later” with regard to product debt. Instead, what happens is that somebody adds a tab to a modal (the users need it!), and that’s fine. Then somebody else adds another tab to the same modal (the users need it!), and it’s still fine. Then another tab, and then another tab, and then your modal likes this:
Suddenly, it’s not fine.
But somehow, there’s still always time for another tab (the users need it!), but no time to break down the modal. And didn't The Internet decide that modals were Bad Design sometime last year anyway?
Perhaps you’ve heard the saying that a camel is just a horse, designed by a committee. Well, I argue that a camel is just a horse designed very slowly in response to an ever-changing slew of requirements and endless feature requests, by a startup. And those humps? Product debt at its finest.
One of the big problems is that features are added incrementally. And, because there are PMs and product designers and engineers who are invested in those features—who own those features—they’re iterated on in response to user feedback. This is good: eventually the features start to look really nice, and the team feels pretty good about themselves. But because the actual product is a collection of features, and often time there’s no one person or team responsible for the whole thing, it only ever gets incremented… never iterated. Your product becomes the swiss army knife that can do everything, but doesn't fit in your pocket anymore. Sure, there's nothing else out there with such a robust feature set! But at the same time, there's nothing else out there that's quite so unusable.
It’s true that some product debt is the result of a lack of proper big-picture thinking. Some of it can be avoided with more flexible implementations. Improving inter-team communication and shortening feedback cycles can keep slow down the rate that it appears. But at the end of the day, there’s no beating around the bush: your horse has humps.
Needless to say, this is bad. Unlike tech debt, your users notice product debt. Maybe they don’t complain about it directly, but don’t let the lack of designated tickets in your customer support queue lull you into a false sense of security. Overloaded interfaces, inconsistent components, poor navigations—all of these things cause users to get frustrated with your product. No, they won’t write in, but only because they don’t know what to say. “Your interface is dumb” might be a stupid email, but it’s not an invalid complaint.
Furthermore, product debt is the product equivalent to the Broken Windows Theory. Once one modal has mutated to the point of looking like the cockpit of an F-16 Raptor, what’s to keep your other modals clean and easy to use? Once one non-standard field creeps its way into on form, what’s to keep it out of the rest?
Unfortunately, there aren’t many excellent solutions here—or at least, none that I know of. Having a designer regularly audit the platform is good. Regular user testing is even better. Having a team cross-functional team dedicated to product coherence only (no new features!) may be best of all, though to be perfectly honest, I've never heard of such a thing. But second to that, a periodic process in place for regularly building robust, scalable solutions to address red flags found in these audits may be the only way from keeping your product debt from mounting too high. This is extremely important, because the alternative may be just to bulldoze the whole product every couple of years and start fresh.
Which, now that I think about it, might not always be the worst idea either.
What do you think?