STOP! Before You Add That Feature, Do You Know The Real Cost?

You're excited! And, why wouldn't you be? This could be the one. This could be that feature that unlocks the holy grail of viral user acquisition. This could be the one that drives your cancellation rates down to microscopic levels. This could be the one that the tech press writes about. This could then cause random strangers to give you a small, congratulatory smile as they pass you on the street, acknowledging your brilliance.

This could be that company-changing, life-changing feature. Or, it could not.

There are many reasons you might consider adding a new feature to your product. Here are some of the most common ones:

Reasons (and Rationalizations) To Add A New Feature

1) It Just Makes Sense. You're surprised that the product exists at all without this feature. You're not sure which idiot decided to leave it out of the MVP (oh, that might have been you). How could we have not had this from Day 1! It's obvious that our kind of product needs this feature. It's table-stakes. Lets add it immediately.

2) A big/important customer is asking for it. Based on how many customers you have, and how much this customer is paying you (or is promising to pay you), there's a strong push to just do it. You'll come up with many rationalizations: “Hey, if this customer wants it, likely others do too.” And, besides, it's not that hard. I think our dev team can crank it out in a weekend and we can still go out for drinks on Sunday night. And, we're supposed to be listening intently to customers, right? RIGHT?

3) A competitor just added it. So, your sales team starts banging on tables for the feature (or, you're the sales team). And, the feature is ludicrously trivial. They should be embarrassed for issuing a press release about it. And TechCrunch should be embarrassed for writing an article about it. Those dolts! So, you just go do it. Just so you can prove you can and how lame that competitor is for making a big deal out of it.

4) It will drive revenue! Your gut is telling you that more people will buy, more people will stay, or your existing customers will spend more money if you have this feature. There's a clear ROI path! We spend a weekend or two developing the feature, and if only [x] customers buy, we're golden. The feature practically pays for itself!

Now, though I wrote all of those a bit tongue-in-cheek — the reality is that some of your reasons might be completely legitimate. Lets just pick the last one (we'll make more revenue), because it's the simplest to talk about. We're going to assume that your thesis is correct and that adding this feature adds more revenue. Let's stipulate that you are correct.

The problem is being correct on the revenue side of the equation is not enough. What about the costs side of the equation? “Wait, wait,” you say “you silly nilly, this is the software business. Once we spend the money to build the feature, we're done. Software has high gross margins. This is MBA 101 stuff. Dharmesh, didn't you go to some high falutin' business school?”

First off, nobody uses the phrase “silly nilly” anymore. Just sayin'. Oh and yes, I did go to a high falutin' business school (MIT Sloan) — don't hold that against me.

There are some costs that you should consider as you add that new feature.

Costs Of Adding That Awesome New Feature

1. Increase in setup time: It this new feature requires some configuration — or even some training to understand it, your costs go up. They go up because it takes longer to understand your product. They go up because your sales cycle might be impercetibly longer. They go up because customers have to spend more calories getting going (and trust me, eventually you pay the price for this).

2. Support costs: The feature might be a little complicated. Or, might not be as intuitive to your users as you think. Your support call-volume and e-mail volume go up. Last I checked, those things cost money. Real money.

3. Infrastructure costs: The feature is one of those that requires you to do a bunch of “pre-processing” to get the data ready for the user to consume (only a small fraction of whom will need it in any given time period). Example: A slow/expensive daily analytics report that you precompute/build from your Hadoop cluster so that users don't have to wait. Now, you have to consume resources to build this report for all customers (because you don't know which ones will login on any give day). This is just an example, but there are many different cases where features involve more data manipulation, indexing, retrieval of data from the web, etc.

Side note on this kind of cost increase: You incur the cost for pretty much all of your customers, even though almost nobody uses it in the early days. Ideally, you should be looking for features where the costs to support it match the actual usage (i.e. you don't pay for non-usage).

4. Increased maintenance costs: As well as you might do to factor (and refactor) your code to ensure that features are decoupled from each other, so adding feeature [x] does not raise the complexity of feature [y], in practice, for any system of decent size, it's inevitable that you have some “leakage” in your abstractions. Some of these will be deliberate (you want to get code reuse, so you start interconnecting parts of the product together). Regardless, the fact is that every feature you add makes the overall system harder to maintain. Period. End of story. If you're really good, this cost might be nominal, but it's never zero.

And, the most important, overlooked cost of all:

5. The Cost of Complexity: Startups are a constant battle against ever-increasing complexity. When you move to having multiple price options for your product, your complexity goes up. When you add an important feature/app, your complexity goes up. It's one more thing to track adoption of. It's one more thing you have to promote to your customers (so they know it's there). It's one more decision to make (should we include this feature in the free product, or use it to drive upgrades?). It's one more hungry mouth to feed when you're trying to allocate limited product/engineering resources. It's one more row in your pricing/feature matrix. Every one of those things cost money. They just may not show up on your P&L on day one. They're subtle and somewhat hidden, but they're very, very real.

So, STOP! Before you just go add that feature because you know it's going to help you drive more adoption, revenue, etc. Spend a little bit of time thinking through what the actual costs for this feature will be over its lifetime. You don't have to analyze it to death, but it's deserving of some time spent that is proportional to how big the feature is.

What do you think? Any other hidden costs that you've learned about in your experience building and delivering product? Would love to hear your thoughts in the comments.