The hidden costs of adding features

“This is awesome Jesung, but can you just add…”. I had built out an automated dashboard of campaign performance and was getting buy-in from our marketing partners to use it to track their campaign results. The marketers were excited to have access to this data next-day since the previous process involved manual work and took longer. However, they would often bring up one campaign metric that is currently reported to the senior leaders of the company but not currently in the report.

I diligently added new metrics and tabs over the following weeks and months. However, I began to run into issues such as the data pull crashing or slow response times on the dashboard. I had not accounted for the both the rows and columns of data to balloon and was paying the price. What should I have looked at before jumping into building new features?

An obvious comparison to make is other things that could be done in that time. There are other features to be added or new products to be built. For bigger projects, the finance team can help to calculate a return on investment (ROI) value and see if it exceeds the internal rate of return (IRR). This will help the company allocate capital by comparing ROI across multiple possible projects.

At smaller scales, it is possible to plot a value vs. effort grid to see where the various options land. The higher the value at the same or lower effort, the most attractive a project/feature is. Instead of adding 60- or 90-day churn metrics from the existing 30, I could have added revenue lift or worked on a different dashboard. If it is difficult to put a financial value to a feature, you could look at the number of clients asking for it and how they would prioritize.

A cost that is not immediately obvious is the ongoing support and maintenance costs. For my dashboard, adding more data points required more processing on the database side. Adding more tabs to a visualization increased the load on your visualization server. Adding more features also meant having more features that can potentially break. A small change in the source tables could mean days of trying to debug numerous lines of SQL code. Keep in mind that support/maintenance is not optional in many cases – you cannot let your product stay broken. As the support time continues to jump, you will have less time to develop your product. Before you know it, the heat will add up and you will realize that you are the frog, not the chef.

A particular support cost for products is technical debt. Technical debt is defined as the implied cost when making decisions to expedite delivery rather than build robust solutions, requiring refactoring down the line. Ward Cunningham – one of the authors of the agile manifesto – coined the term and likened it to borrowing money and paying interest on it¹. You can accelerate delivery through borrowing but eventually you will just be paying interest rather than making any useful progress on the principal.

It seems like technical debt is the plague and everyone should avoid it. However, it can be used strategically to meet deadlines or verify assumptions. Every feature or project should account for the technical debt that will be accrued as a consequence of implementing it. Whether you choose to pay it off now or later should be a conscious decision, not a surprise credit card bill you find years later.

Focusing on high ROI opportunities and accounting for technical debt without strategy is like sailing a speedboat efficiently without a map. You could be headed in a totally wrong direction and would not know it. Good strategy will focus on a few efforts that have been narrowed down from a long list of good ideas. That is easier said than done – with so many directions to go, it is easy to be led astray.

One temptation for a product team is to be a market follower – implement the features that your top competitors have or the features that your customers ask for the most. This could be driven by the fear of missing out or lack of clarity in your vision. The problem with a homogenous market is that it is difficult for your product to stand out in a sea of similar commodities (you can only compete on price or service) and that the market will be ripe for disruption. If the market does not address a wide range of needs, it provides room for start-ups to take up unaddressed niches. The key, then, is differentiation.

A useful tool when deciding on product strategy is the Blue Ocean strategy canvas, introduced in the book Blue Ocean Strategy². You start off by listing off various industry factors and the baseline score of your main competitors. Then you distort the factors and plot out the canvas of the baseline score vs. your product’s score. The important takeaway here is understanding not only what your product will be good at, but also understanding what you choose to be bad at.

There are many hidden dangers of adding features. I have certainly lost time and effort by not accounting for them. However, that does not mean you should never add new features. Much like taking on debt to buy a house, you can take calculated risks and pay back the debt later. You also need a strategy to tell you which type of house to buy in which area. Plan for increasing infrastructure capacity and support hours accordingly. Plan to address technical debt. Plan what the product will be good at and bad at. Ignoring these dangers can lead you to a shock bill years later or the realization that you are on the wrong planet.

¹Ward Cunningham. (Feb 14, 2009). Debt Metaphor [Video]. YouTube. http://www.youtube.com/watch?v=pqeJFYwnkjE
²Kim, W. C., & Mauborgne, R. (2005). Blue ocean strategy: How to create uncontested market space and make the competition irrelevant. Boston, Mass: Harvard Business School Press.