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.
Sumeet Chawla 3:19 PM on February 07, 2013
Also, it helps following the Minimum Viable Product model to actually know what the product users want. With proper analytics tracking and monitoring, the requirement or the importance of a feature can be determined...
Mili 10:43 PM on February 07, 2013
very insightful post... i completely agree with the intangible costs of over-engineering/complicating a system. also agree with the implication that many companies suffer from feature-itis... more is not always better!! not saying that sometimes we haven't found ourselves walking down that path, but we do really try to focus and simplify, (on the user and the engineering side). this of course, coming from the MBA on the team... wonder if my tech team would agree :)
EA 11:54 PM on February 07, 2013
Dude, before you start giving advices try to make your logo link work properly.
Raj 11:55 PM on February 07, 2013
One definitely have to consider the incurring charges for adding up a new feature and the real benefits in serve for the community you are serving and then only move on with the new feature or else adding a feature just for name sake will not add any value to the business
Erica Grigg 12:05 AM on February 08, 2013
This is something we're thinking very critically about. As a couples-focused, sex positive startup, we have little cash and big dreams. On the flip side, our co-founders (me being one of them) are highly technology-driven. So I completely agree on the need for analytics & definition. But after several weeks of launching officially, I've kept my ear to the ground in terms of our customers and I can say they don't know *what* they need. Why? This is a relatively new site model (i.e. content-driven, hybrid media company). I've interviewed startup entrepreneurs around this particular issue and it seems to be the stickiest. So--over the next 4 weeks, we're going to be releasing features to get picked up by the press (shockingly), our users and big bloggers, we hope. But ultimately, I hope to report back soon on how this analysis has improved my thought process. Kudos to you, Dharmesh. Making startups possible.
Erica Grigg 12:06 AM on February 08, 2013
This is something we're thinking very critically about. As a couples-focused, sex positive startup, we have little cash and big dreams. On the flip side, our co-founders (me being one of them) are highly technology-driven. So I completely agree on the need for analytics & definition. But after several weeks of launching officially, I've kept my ear to the ground in terms of our customers and I can say they don't know *what* they need. Why? This is a relatively new site model (i.e. content-driven, hybrid media company). I've interviewed startup entrepreneurs around this particular issue and it seems to be the stickiest. So--over the next 4 weeks, we're going to be releasing features to get picked up by the press (shockingly), our users and big bloggers, we hope. But ultimately, I hope to report back soon on how this analysis has improved my thought process. Kudos to you, Dharmesh. Making startups possible.
Saravana Kumar 5:38 AM on February 08, 2013
I would also like to add one more point, keep in mind once the feature is added, it's hard to remove it (may be you can't) without upsetting few people who use that feature. Having said that, you should NOT just stop adding new features to the product, at end of the day we have seen people (both existing customers and new prospects) get more excited every time we announce a bunch of new feature. If you are in doubt the best thing to do is ask people, your customers, community, influential people in your niche etc. If a feature is complex and we know it's something that will take considerable amount of engineering work we normally go back to the community. Here is one example http://www.linkedin.com/groupItem?view=&gid=53234&type=member&item=178641951&qid=4c37858e-dc3a-432a-b722-f5d5aa481c4f&trk=group_items_see_more-0-b-ttl At end of the day, your product should mature day by day, the only way to do it is by adding sensible new value added features. Of course there will be a cost, but you need to measure your cost vs benefit.
chicken coop man 12:47 PM on February 08, 2013
Rather than brainstorming new features I try to incorporate feedback from users and improve on the existing design. My customers have given me lots of ideas that I was too close to the product to see. They became the new, improved overall design of the product
Judy Tyrer 1:59 PM on February 08, 2013
In all of your scenarios you have people making decisions FOR your technical people. That is the first major flaw of any business. If you don't get good estimates from your technicians for what is involved in adding any feature, you have failed.
Judy Tyrer 4:23 PM on February 08, 2013
In all of your scenarios you have people making decisions FOR your technical people. That is the first major flaw of any business. If you don't get good estimates from your technicians for what is involved in adding any feature, you have failed.
rahul dev 5:11 AM on February 09, 2013
I like my work
Sandeep Todi 2:15 AM on February 10, 2013
We've realized time and again that cowboy coding of new features breaks things that are overlooked due to overdose of enthusiasm. If that feature is really hot, write down what you gain by doing it and what you lose by not doing it. Let it simmer for 3 days then revisit your document and see if you still agree with the earlier assumptions. We've found several times that a new enthusiastic idea comes along and the old ones stop looking so attractive. It's a constant battle and while you don't want to slow down the thought enzymes, you do want to take those decisions that *really* impact your topline. Several times we've told users we will do it but in 3-6 months timeframe and they've been ok with it... even respected us for it.
Varun 2:27 AM on February 12, 2013
Hi, Nice post. I would rather like the idea of plug-in features ( though in major scenarios it may not be possible.) but if we look some major product players in market, we can see like gmail, facebook; they always introduce new features with possibility (in most cases) to have the ability to use or not use that feature. Based on static analysis as suggested above like spending more time before implementing is definitely a very good idea and it would add on if feature once introduced can be used by users' will. Based on the user response/analytic and tracking, it can be finally integrated in product.
Varun 2:27 AM on February 12, 2013
Hi, Nice post. I would rather like the idea of plug-in features ( though in major scenarios it may not be possible.) but if we look some major product players in market, we can see like gmail, facebook; they always introduce new features with possibility (in most cases) to have the ability to use or not use that feature. Based on static analysis as suggested above like spending more time before implementing is definitely a very good idea and it would add on if feature once introduced can be used by users' will. Based on the user response/analytic and tracking, it can be finally integrated in product.
Sandeep Todi 9:54 PM on February 12, 2013
Good point Varun. Google mail does this quite elegantly. Will be great to hear from other readers if they know the strategies / tools used to execute sandboxed releases and allow users to switch on/off a new functionality within an existing feature.
Pippa Callanan 2:10 PM on March 26, 2013
Smart article! Many of your ideas resonate with Gerry McGovern's thoughts. Perhaps the greatest parallel is that he believes that adding adds complexity, which has associated costs. I think something he adds to the conversation, which you hinted at in your last paragraph, is that complexity causes confusion, and users don't have the patience to be confused when there are numerous other sites that will help them achieve their goals more easily. This goes for content as well as features too. Great post!
Pippa Callanan 2:32 PM on March 26, 2013
Smart article! Many of your ideas resonate with Gerry McGovern's thoughts. Perhaps the greatest parallel is that he believes that adding adds complexity, which has associated costs. I think something he adds to the conversation, which you hinted at in your last paragraph, is that complexity causes confusion, and users don't have the patience to be confused when there are numerous other sites that will help them achieve their goals more easily. This goes for content as well as features too. Great post!