Product Debt
Product debt is like technical debt: today’s time saver becomes tomorrow’s burden and eventually dead weight. Unfortunately, product debt tends to turn into technical debt, so developers pay the interest on bad product decisions, too.
Technical debt is when developers take shortcuts in the code or architecture to deliver functionality faster at the cost of increased future maintenance. It is often a calculated risk or trade-off to, say, beat the competition to the market or land a big deal on time. Product debt is when product managers make decisions on capabilities without sufficient knowledge. It typically happens when trying to solve imagined future problems rather than existing ones.
Product debt comes from certainty creep, in which uncertainty around the need for a feature morphs into misguided confidence because of the passing of time or the pressure of a deadline, without any or sufficient data or customer research. When such an idea transforms into a requirement and afterwards becomes code, the product debt has turned into technical debt, not because the developers took a shortcut, but because the product manager did.
Product debt is insidious because a proposed feature does not come across as dead weight. As long as it has not been implemented, what is the real problem? There are two reasons why product debt is a serious concern: people tend to ignore the removal of functionality as a viable option and the anchoring effect.
Subtraction
Research has shown that when people solve problems, they tend to add rather than subtract features. This tendency implies that solutions grow in scope, which can lead to feature bloat and tech debt. What is more, once people are committed to such features, it is hard to argue for removal later, because of sunk-cost bias. People spent time on these features, which turned out to be superfluous or not as successful as they ought to have been, so removal feels worse than keeping the features around indefinitely.
In product development, the marginal costs and benefits for addition and subtraction of features are not always equal, which means that you may not end up with the same economics for the product before a feature is added and after you have removed it again. This is known in science as hysteresis, in which the state of a system depends on its history or the path taken.
The marginal value and cost for feature inclusion can be different from those for feature removal. For instance, it can be easier to add something but much harder to remove later due to dependencies and other tech debt that has piled up since.
Likewise, the marginal value of addition can be higher than the marginal value of removal because of incomplete information: you considered a feature to be more valuable than it turned out to be.
Another reason can be that a few customers abuse a feature for a workaround, so deprecation is not desirable from their perspective.
Once you do convince people that subtraction of such features is the best choice, they are out of sight, out of mind. But overcoming that hurdle may be easier said than done due to the anchoring effect.
Anchoring
The anchoring effect is a cognitive bias, in which people tend to stick with any initial idea because it is there, not because it is pertinent. Such an idea becomes a reference point or anchor: once the cat is out of the bag, it is very hard to shove it back in.
Because people are biased to add rather than subtract, they anchor on what is available, and their attachment to effort already spent, product debt is a serious risk for any product team. My advice is to add only if you absolutely must, because you rarely subtract once you have committed to a solution, even if only on the drawing board.
How can you avoid accumulating product debt?
The pope of nope
Be the pope of nope and only add functionality when you are as sure as you can reasonably be that it solves a specific customer problem, not an imagined future problem. Be certain that what is on the roadmap is needed and not a series of just-because features. A roadmap is not a wish list.
How can you be sure? Do not assume anything about what customers need. Permit yourself to be surprised. And manage both feature ideas and tech debt sensibly.
If you are not certain about a particular requirement, do not add it to the roadmap. It can be very difficult to remove once it exists, even if only in the minds of the product team or leadership. The advantage of shipping products without features of questionable value is that the product is easier to build, you gain customer feedback sooner, and you avoid product debt. Feedback now beats feedback later. Always.