Introducing Feature Debt — the unconventional sibling of Tech Debt

We have all heard of Tech Debt, and we’re probably terrified of building so much debt that our team stops being able to deliver. However, a less commonly discussed, but just as powerful issue also exists — Feature Debt. At best you have more expensive product delivery and, at worst, you run the risk of losing your customers and your team because of Feature Debt. The number of features that can ultimately cause Feature Debt will differ for each organization given different resources, velocity, architecture, etc., but none are immune to building too much. For the purposes of this discussion, I will use the term “feature” to be functionality, both big and small, that is a new and/or separate capability.

What is Feature Debt?

Debt is defined by Merriam-Webster as “a state of being under obligation to pay or repay someone or something in return for something received; a state of owing.” In the financial world, debt often has compounding interest, which is interest on top of interest. Meaning debt gets more expensive to pay back the longer you wait. Technical debt is a concept originally introduced almost 30 years ago by Ward Cunninghamthat reflects the cost of additional work caused by choosing an easy and fast solution now instead of using a better approach that would take longer.

Feature Debt is simply the accrued cost of constantly adding new functionality into your product or system instead of building better, more complete solutions.

Feature Debt is simply the accrued cost of constantly adding new functionality into your product or system instead of building better, more complete solutions. Feature Debt also contributes to all other kinds of debt in software development (e.g., Functional Debt, UI Debt, and Tech Debt).This will not only slow down development and make it more expensive, but also lead to a poor, fractured experience that can make both customers and employees leave you.

How you amass Feature Debt:

• In the early days, it’s often by building too many integrated MVPs. At this stage, when so much is unknown, MVPs are a great way to test many different ideas to quickly and cheaply learn. But when these MVPs are combined and built upon each other, you can create a bulky, complex product that might not yet actually solve your customer’s problem.
• Over time, it’s improper prioritization. You move on to new problems and start building new functionality before that which already exists is working to solve the customer’s original problem.
• Ultimately, it may just come down to poor leadership at all levels. If leadership isn’t clear on the vision of the product, then they likely just keep throwing out ideas and tell the Product and Engineering teams what to build. If you operate in such an output-based, feature factory, then you’re not operating in the outcome-based mindset used by empowered Product teams that Marty Cagan talks about.

The impact of Feature Debt:

• You build the wrong thing (more for earlier stage companies still finding their product-market fit). Maybe you built a SaaS platform and the right solution was a physical hardware product. Because every decision that you make creates interdependencies, and every interdependency “hardens” the platform from which all other solution decisions are based, you could be building a larger version of the wrong thing. And maybe you did build the right thing, but now the architecture is wrong or overly complex because it was built to support a lot of individual wrong things.

Because every decision that you make creates interdependencies, and every interdependency “hardens” the platform from which all other solution decisions are based, you could be building a larger version of the wrong thing.

• No (or almost no) individual feature works well. Every time you launch a new feature you intentionally know that it is incomplete and doesn’t fully fit your overall experience in order to get something out (if not, then you’ve launched too late). The remaining functionality and debt then becomes “nice-to-have” and put at the bottom of your backlog because you don’t have enough capacity for it all (and because you’ve now moved on to building a new features anyway).
• Prioritization becomes more difficult. The more features that you have, the bigger your backlog, filled with missing functionality, future feature enhancements, and bugs for all existing features, as well as more new features. Assuming that your team has generally the same resources and capacity, you will higher costs with increased complexity sorting between it all.
• You spend a lot of money and resources. If you release it, you own it. You now have to pay the debt of ongoing maintenance, more complicated release testing, integration with other features, expanded architecture, training internal and external stakeholders, etc.
• Customer churn. Because no (or almost no) individual feature works well, customers perceive that your product isn’t good and their biggest problems still aren’t solved. So they’ll leave for an alternative that actually works.
• Employee churn. Frustrated with slow development cycles, owning features that are perpetually deprioritized yet sub-optimal, and unhappy customers your Product, UX, and Engineering teams will leave. I’ve seen this happen first-hand.

How to not fall into this trap:

• Focus and say “no.” Focus on your customer’s biggest pain, define outcomes that you hope to achieve, and see features only as a means to achieving those outcomes. Use tradeoffs. Use data. Use all of the techniques Product Managers use to help stay focused. Know that tradeoffs for new feature are a lot harder to define because the value and cost to build and maintain is unclear given that so much is unknown.
• Wait to add new features until existing features are more stable and mature. Features are like children — the more you have, the more you have to manage. Parents can typically manage multiple children because they are in different stages of life. When they get older, they get more self-sufficient and require less day-to-day management. Adding more infants (new features) to the same parents (your existing capacity) becomes impossible to manage (see how it worked out for Jon and Kate).

Features are like children — the more you have, the more you have to manage.

• Consider removing functionality. I’ll ditch the children analogy here, but you should consider getting rid of functionality that isn’t used and only making your product “worse.” When removing functionality you must consider the impact to customer experience, execute it with thought and caution, and consider the long-term impact on trust in your product or company if done frequently.
• Implement new features with the ability to undo them. Think of new features as experiments. Create different processes for reversible and irreversible decisions. Then do whatever you can to make the experiment reversible (create a Wizard of Oz experiment, develop a landing page, etc.), don’t integrate it with your core functionally, or don’t give it to a large population of customers.
• Add resources to pay down Feature Debt. All of the above deal with not building Feature Debt to begin with. But it happens, so invest in paying it down by adding more resources to Engineering, Dev Ops, architecture, customer success, etc. Of course many great technology companies have many great products with many great features, but they are at a scale of resources and infrastructure that can support it.

In our personal and professional lives we knowingly or unknowingly amass debt. Debt is not necessarily a bad thing — we can intentionally go into debt to get short-term gains, with the assumption that we’ll pay it down later. In our personal lives we may do this to jump-start our career. In the technology world we do this to learn fast and preserve options. However, if this debt is amassed too quickly or not repaid in a timely manner, it accumulates “interest,” making it harder to fix in the future.

So if you are getting started be mindful of adding new features before your existing ones are working. And as you grow, be on the lookout for the common pitfalls and impact of Feature Debt.

Give us all your feedback. Let me know your thoughts on Feature Debt. Let me know areas that you’d like explored more. And, if your organization is great at not amassing Feature Debt, let us know how!!