The Debt You Can’t See

The most natural force in product development is to deliver additional user value in the form of new features. This is generally good. By not riding on a previous wave, you're proactively looking past the status quo and making something that's more likely to withstand disruption.

By saying yes to more features though, you are accepting the tradeoff in additional product complexity - both for usability and maintenance. In the short term, adding new details and surfaces into the product feel obviously useful and worth it. Your most loyal users thank you for listening. Your organization’s leaders celebrate you for realizing incremental gains that are harder to come by for a mature product. Maybe they even praise your outsized impact relative to investment. In the long-term though, you’ve inadvertently said yes to hundreds of small new local improvements and new surfaces. Very quickly your simple and approachable product becomes highly complex and oriented towards power users who have built up their understanding over long-term usage. New users can only ever use your product if they are motivated enough to overcome the learning curve to become power users. This puts a bottleneck on growth, with some short-term relief provided by investments in user education and onboarding flows. The upside here is limited, because you haven't tackled the real problem of product complexity.

This is a debt most teams know they are accruing but are rarely conscious about. They know this debt exists but they can't see it. The cost to tackle it proactively isn't one they're willing to fund since it is harder to measure their impact on the more immediate KPIs. Once it has accrued to the point it hurts, a fix usually comes in the form of a major refactor or redesign, that takes far longer to launch than you can anticipate, because existing revenue streams are sensitive to them and they are funding your efforts after all. For a host of products, it's often too late to navigate this change when it is in reaction to growth plateaus or dips in usage, which are often trailing indicators of complacency. Usually by this time, you'll already have a few disruptors in the market that you're actively combating. Your competitors offer something compelling while far less sophisticated -- simplicity and a low barrier to entry makes them as approachable as your product once used to be. In response, you're unable to remove features from your existing product, because your existing users depend on it. You're unable to add competitive features before your major redesign, because it increases your debt further and might end up alienating even your existing users. The situation feels impossible and you wish you'd responded sooner.

The System Solution

Having personally witnessed this in more than one situation across multiple companies, I've made sure my teams are chipping away at product debt proactively. The simplest solution I've found is to sign up only a proportion of bandwidth we have available as a team to support upcoming product work. We intentionally maintain slack on the team (10% bandwidth might be a safe lower bound) to tackle product complexity we cannot see yet. We usually spend at least half this time playtesting. This allows us a chance to retroactively identify the issues of people who are more dependent on our products, many that don't look anything like us. The other half of the time is spent simplifying complexity or fixing issues we've found as a part of this process.

Further, as a part of any new product work, I've found it helpful to bake this into our process proactively. To ground ourselves, we first ask: What are the core jobs that our new products/features will be hired to do?

Then, we ask a few more questions to isolate the real issues:

• Are we accidentally signing up to do more than these core jobs? We usually are, and it's easy to make cuts here once we can see.
• Are there other features/parts of the product which do jobs similar to the ones we're just building? Again, we usually do find features that become good candidates for consolidation/deprecation.

If we're intellectually honest, both of these are excellent at reducing debt on your team. When there are competing incentives, it's sometimes important to ask the extreme questions:

• Are we making our products complex because it serves a lot of people, or we doing it because we haven't set the right goals? This is usually a simpler fix and goal reset can start to pivot the team in the right direction.
• Are we adding more features just to warrant this team existing? In many companies, this is true more often than we care to admit. The solve here is to move your pool of talent to a more meaningful part of the business.