Surviving the Featuritis Plague

One of the most common reasons for loss of productivity due to office software is a syndrome called Featuritis (i.e. overload of features). Most software applications used within an enterprise seem bloated because of unnecessary features.

The image shown below provides a pictorial explanation of how user happiness is linked to the number of features associated with a product. Any user feels comfortable with an application as long as the application makes him feel like an expert. This is the feature threshold value for that user. If the features are less than the user’s feature threshold, then he feels that the application is incomplete. If the numbers of features are more than the threshold value then users start to get confused by them, and eventually conclude that they suck at using the product. No person likes to use a product that makes him feel this way.

The two primary reasons for featuritis are:

• Feature Arms Race with Competitors
• Ad-hoc User Requests

Features Arms Race happens when product companies start adding features just because their competitors have them. This happens because:

1) They are afraid of falling behind competition.

2) Feeling that whatever a competitor adds is something that users want

3) Assuming that potential users will buy off a checklist, and having maximum features will get their product selected

4) Compulsive need to add, since the idea of an upgrade that subtracts features seems counterintuitive.

5) New features are easier to promote than better/working versions of existing ones.

The solution of winning the feature arms race is to avoid participating in it. Devote all of your attention to users and your own ability to innovate. This will ensure you will spend more time on understanding your users rather than building unnecessary features.

There are situations when users do shop off a checklist. This typically happens when they lack a deeper understanding of what is important and what they really need from the product. Buying off the checklist makes them feel that they are getting better value for their money (the whole ROI concept). You need to educate such users so that they make more prudent decisions.

The second cause for featuritis requires more careful analysis. This happens when users make ad-hoc requests for features. Such requests are made because the feature threshold value for every user is different from other users. If the product company says no to such a request then they may lose a genuine user. However, if they start saying yes to every user request and keep adding features to their product, they are sure to end up with a product that is mammoth and bloated.

The open source community has provided a solution to this problem. Expose as many API’s of your product as possible to your user community. This will give them the flexibility to add or develop new features to the base product. Firefox, for example, has a robust community of developers who write extensions and themes that people can use to enhance Firefox with a flexible set of additional features. By providing these separately, Firefox avoids becoming too bloated and also keeps user needs satisfied.