I think The Featuritis Curve is one of the most critical things for a good Product Manager to really internalize. People tend to look at this curve and nod their heads, smile, say they “get it”, perhaps even look at me like “of course, why are you even bringing this up”, then they go right back to the business of jamming as many features into their product as they can fit.
Does this story sound familiar to you? Product Management and Engineering are fighting again. Engineering is coming back to Product Management to tell them they have to start dropping some previously agreed upon features if they want the release to come out on time. Product Management is saying that they are all critical features, and we won’t make our revenue targets if we drop them. PM blames engineering for under-delivering again, and there’s lots of tension between the teams. If it does sound familiar, it’s likely that your Product Managers suffer from the deadly condition known as “FEATURITIS”…
The Featuritis Curve is actually providing a similar message to The Innovators Dilemma, which essentially says disruptive innovation comes from by building products that are less functional and significantly cheaper than the market leaders. In doing this, you can capture the needs of customers who were not previously willing to buy the market leaders due to their price and/or complexity. So it is probably even more critical for startups to really have this message sink in if they want to disrupt existing businesses.
Of course, there are several companies who abide by this, and they tend to be the most successful companies, so by definition, those are therefore likely the ones you HAVE heard of. But think about all the other startups (especially enterprise software startups) who fail that you don’t know about, and take a look at their products. A lot of them seem to do be doing their best to get straight onto the right hand side of the curve. Why does this continue to happen over and over?
I will offer up one overarching reason: poor Product Management (or in the case of many startups, no dedicated product management at all). It takes A LOT of disciple not to slide down the curve. In fact, it is the natural evolution of a product to move from left to right along the curve as everybody you talk to will have feature requests for your backlog for you. It’s your job as a Product Manager to fight for your users though. When you dont understand your users and know what they REALLY want, or you don’t have a clear vision for your product, or you add a feature just because a competitor has it (the topic of my next post), you will end up over that side of the curve. Poor Product Management equates more features with a more viable product (Kathy Sierra called this “fear” – fear that your product is inferior with less features).
Aside from poor Product Management though, perhaps the best argument against The Featuritis Curve I have seen was laid out by Joel Spolsky. I will paraphrase his key argument as: even though it might be true that feature usage follows the Pareto principle (80% of customers use 20% of the features), each customer uses a different 20% of the features – there is no magical 20% set of features that appeals to everyone. Therefore, more features = more ability to attract new customers. I would add that his argument is particularly true if you are designing products are inherently complex (e.g. an ERP suite vs an iPod). However, there are few things missing in this argument:
- Customer Satisfaction and Churn – you might be signing on new customers, but are all your extra features making your software more complex, and therefore reducing user happiness? What’s most troubling about this is that the numbers won’t show this to you until it’s too late – customer’s won’t churn on you instantly (especially in Enterprise Software). It will likely take some time, at which point you are far down the right side of The Featuritis Curve. And once you are down there, you can almost never travel back up towards the top – it’s a one way street.
- Technical Debt – Ceteris Paribus (all things being equal), the more features you are adding to your product, the more likely it is that you are accumulating Technical Debt. The big problem with Technical Debt is that it then becomes even more difficult for you to add more features to your product. So now you’re on the far right side of the curve, unable to move back up the hill AND unable to add any new features without breaking something else. If you ever look at product from a big company, and think that the product looks almost identical to what it did 5 years ago despite lots of new releases coming out, you now know the reason for it.
- Crossing The Chasm – A false dichotomy in Spolsky’s argument is that people are buying your software only because of your features. In reality, there are so many other reasons why people buy (especially in the world of Enterprise Software). For just one example, consider Crossing The Chasm – the Late Majority and Laggards are buying because everybody else is buying. They might rationalize it (to themselves even) as now you have the features they want, but it’s much more likely to be that they just needed the social proof of others having bought you before them.
Despite saying all this, I will grant that Spolsky is somewhat correct – you will always be enhancing your product in new releases, and at least some of those enhancements will be new features, therefore your feature count will always go up over time. You don’t hit the top of the curve, then fire all your PM and Dev teams, and expect the revenue to come rolling in since you’re now at the perfect peak. The Featuritis Curve is overly simplistic to make a point, and it doing so it conflates a few different concepts like design and usability into the “features” axis.
So rather than saying you shouldn’t add features, it’s that you should be extremely diligent about adding them, and make sure that the features you do add are focusing on maximizing your user happiness. Unfortunately, most Product Managers do suffer from Featuritis. I believe this is the true test for good Product Management – knowing what features to NOT add to your product. This means fighting to keep things out, not fighting to jam more in.