Product debt

We could’ve done better

From 2014 to 2019, I worked at Stitch Labs, an ecommerce startup that was later acquired by Square. It was one of those “right place, right time” jobs that I hope every startup employee experiences at least once. While we didn’t have the dream exit we wanted, it was a great place to learn and grow, and the company was acquired by one of the more recognizable names in tech. It was a startup journey and outcome far better than most—and a great company to be from. But years later, I still can’t shake the feeling that we could’ve done better.

Before and since, I haven’t found another team that was so skilled and worked so hard, for so long, while fighting for every single inch of progress. There were a lot of factors at play, many of them outside our control: market timing, the size of the underlying business opportunity, etc. But looking at the factors within our control, I often felt saddled by the very thing that was supposed to propel us forward: our product.

Much has been written about how technical debt slows engineering teams down, and there are at least a few good reads on how design debt impacts user experience and customer value, but our product slowed us down in ways that had little to do with engineering or design.

These self-imposed headwinds were the result of what I call product debt, which can be even more taxing than its technical and design equivalents. Product debt cuts to the core of what software products fundamentally are and what product management should be. And as near as I can tell, it’s not talked about at all.

Understanding product debt

To understand product debt, we have to understand products. Within the context of a software startup, a product should not only reflect the startup’s evolving understanding of the market but also help the business move closer to market fit. In other words, a good product embodies and advances the startup journey, which is primarily a function of learning. Product debt is any element of a product that compromises the learning loop and/or impedes progress toward market fit. Here are a few examples and their potential consequences:

• Low-value features that dilute the product’s perceived value, attract the wrong customers, and/or complicate customer/employee onboarding
• Insufficient product documentation, limiting the market’s ability to self-serve and, in extreme cases, misrepresenting the product’s capabilities and value
• Inadequate internal measurement of product/feature usage, limiting insight into how (or even whether) the market is using what you’ve built

Like technical debt and design debt, product debt is essentially borrowed time: you defer a particular outlay so that you can put your limited resources to better use in the present and reach a desired outcome faster. The hope is that the deferred investment will be easier to pay back later, if it needs to be paid back at all.

For a venture-backed startup, debt of all kinds is expected and prudent; it would be irresponsible if a startup didn’t have any. Here are some instances where a team might reasonably punt on product debt:

• You’ve concluded that a particular feature isn’t meaningfully contributing to the business, but sunsetting it would require significant cross-functional investment. Instead, you limit access to legacy customers (hiding it from new ones) so that you don’t have to devote resources to a full sunset.
• Your new feature lacks sufficient documentation, but you defer investment because the feature is still undergoing refinement and the user group is small enough to handle without self-serve content.
• You’re testing a new feature with a small beta group, but haven’t made the corresponding investment in data instrumentation. You hold off for now because you’ll get adequate insight from direct, qualitative feedback.

As with all forms of debt, the tradeoff is interest: a recurring obligation that can ultimately cost way more than what was originally gained/saved. Whereas tech debt primarily affects engineers and design debt primarily affects users, product debt can slow down the entire organization. Here are a few classic examples:

• You have an unfocused feature set that attracts an unfocused customer base with widely differing needs, hurting metrics at every stage of the customer journey: close rate, sales cycle length, employee ramp time, customer implementation time, etc.
• Your documentation is so inadequate that no one on your customer support team knows even the basics about a particular feature. Basic “what does it do” questions get directed to engineers (to literally look at the code) or product managers (who may not know, either).
• Your product analytics are so lacking that you can’t answer simple questions about how/whether customers are using your product, much less correlate product adoption with business outcomes.

Worse still, product debt can be self-reinforcing. When a product is saddled by debt, it sends very confusing signals about who it’s for, what it does, and why it’s valuable. These poor signals don’t just confuse the market—they also confuse employees, making it harder for a diverse group of professionals to be on the same page about their target market and why that target market should choose their product. This creates a dangerous loop: misaligned employees attract a jumbled customer base, which gives jumbled feedback to the business, which creates further internal misalignment. In this scenario, the debt compounds in ways that are very hard to see, much less undo.

If it gets out of hand, product debt leaves people working for the product rather than the product working for them. This limits what a startup can accomplish with its runway: fewer opportunities for the sort of discovery, experimentation, and investments that help the startup reach its next milestone.

Why we need this term

Like any abstract concept, product debt can’t be directly measured or concretely observed. This isn’t a knock on its usefulness (see other useful concepts like love, diversity, etc), but it does present a challenge to software teams. Its presence within a product and whether to do anything about it deserve to be discussed and debated, but it’s hard to discuss something that you don’t have a name for. Search the web for “technical debt” and you get millions of results. Searching for “product debt” yields fewer than 30,000 results, which is as good a sign as any that it’s not in the product person’s vocabulary, much less anyone else’s.

Given the role that software products play within software startups (i.e., as the core enabler for revenue, margin, and multiples)—as well as the privileged and strategic role that product people play within them—we need a term for elements of the product that work against their core purpose. Software development is inherently messy; product people need a term for their part of the mess.

Maybe there’s an existing term that I don’t know about, or a better way of framing it (if there is, please tell me). What we call it isn’t all that important; what’s important is product people having the necessary concepts, vocabulary, and mental models to assume responsibility for their work, including the failed experiments/features, blind spots in customer/user/market understanding, and parts of the product that haven’t kept up with the market.

Would this have helped Stitch?

Would recognizing and tending to product debt have led to a different outcome at Stitch? Yes and no. I don’t think there’s anything we could’ve done to achieve a billion-dollar exit, but a more calibrated product would’ve undoubtedly delivered better everyday outcomes for users, customers, and employees—and it’s hard to know what breakthroughs that might’ve unlocked.

I share this not to disparage the hard work of my coworkers, especially those who made the insane push to get acquired in the first months of the pandemic. I share this to highlight an area where I, as a member of the product team, could’ve done better by the business. I suspect that many software product teams could do better in this regard. Vocabulary and conceptual clarity won’t deliver better outcomes on their own, but I think they would undoubtedly be a useful part of the product person’s toolkit.