How Many CTOs?

What is product debt and how does it differ from technical debt?

Short answer

Product debt refers to the accumulation of outdated or conflicting product features that hinder innovation and maintenance, whereas technical debt involves code-related issues that make future development difficult. Both types of debt can slow down progress, but product debt is more about the features themselves than the underlying code.

Product debt refers to the accumulation of outdated or conflicting product features that hinder innovation and maintenance, whereas technical debt involves code-related issues that make future development difficult. Both types of debt can slow down progress, but product debt is more about the features themselves than the underlying code.

Understanding Product Debt

Product debt is a concept that Brad and Scott discussed extensively in this episode. It arises when a product accumulates features that may no longer be relevant or that conflict with each other, creating a drag on future innovation. Brad explained, "you know, you've kind of added all the different special cases" ▶ 2:41. This kind of debt is particularly insidious because it is not always visible in the code itself but is embedded in the product's functionality and user experience.

Scott shared a concrete example from TaskRabbit, where they had a partner requiring a custom landing page. This led to a situation where updates to the booking experience had to be made in two places, creating product debt. "Okay, we've already got a landing page and we got this one special customer," Scott noted, highlighting how business agreements can lock teams into maintaining outdated or duplicate features ▶ 6:50.

How Product Debt Interacts with Technical Debt

While product debt is about the features and requirements, technical debt is about the code. Brad emphasized that technical debt makes code hard to maintain, whereas product debt involves features that are at odds with each other. "That is a great example of product debt," he said, referring to features that are contradictory yet must coexist within the product ▶ 5:11.

The two types of debt often intersect. For instance, a product decision to create multiple flows for different user types can lead to technical debt if not implemented carefully. Scott illustrated this with a scenario involving multiple date picker components, which could either share a component or exist separately, impacting the technical debt based on the implementation choice.

The Challenges of Addressing Product Debt

Addressing product debt can be challenging because it often involves decisions made long ago that are no longer documented or remembered. Brad recounted how during modernization efforts, forgotten features can become "landmines" that disrupt progress. "Make sure you don't forget about buried old feature X," he warned, underscoring the risk of overlooking these hidden debts during refactoring ▶ 12:06.

Scott and Brad discussed the dilemma of whether to rewrite or refactor systems burdened with debt. Scott argued that rewriting can lead to missing undocumented features entirely, whereas refactoring at least exposes these features to scrutiny, even if the decisions made aren't always perfect. Brad agreed that while refactoring might catch more issues, it's not foolproof, as each small rewrite within a refactor can introduce its own challenges.

Strategies for Managing Product Debt

Managing product debt requires a strategic approach that balances innovation with the realities of maintaining existing features. One strategy is to involve both engineering and product teams in decision-making. As Scott pointed out, "One of the things that you can do what you certainly would need to do if you're going to rewrite it is you would need to say, what do we want this thing to do?" ▶ 26:45. This involves a thorough review of current features to determine which are truly necessary and which can be retired.

Brad and Scott also discussed the importance of being realistic about the volume of requirements and the cost of rationalizing them. Brad noted that while it might seem straightforward to start from scratch, the organic evolution of a product over time means that many features, even those that seem minor, have a reason for existing. This complexity makes it crucial to carefully evaluate the impact of removing or altering features.

Conclusion

Product debt is a significant factor in the lifecycle of any product, influencing how easily a company can innovate and maintain its offerings. Unlike technical debt, which is visible in the code, product debt is embedded in the product's features and often goes unnoticed until it becomes a barrier to progress. By understanding and managing both types of debt, companies can better position themselves to innovate effectively while maintaining the integrity of their existing products.