As a plugin developer, if you release a product (no matter how popular), its a given that over time you’ll receive an influx of feature requests; some user somewhere thinks your plugin should do X to better suit their own personal needs.

Feature requests shouldn’t be dismissed as they can give valuable insight into your user base’s needs and some requests could be perfectly valid oversights on your part. But before coding, consider the impact of adding the feature, work out if it’s actually relevant, and ensure its not just bloat.

Feature bloat is defined as being defined as:

the tendency of a vendor continually to add unnecessary features to a product that are not of any value to most users, use more system resources than necessary, and often unnecessarily add to the cost of the product

Obviously you don’t want to add something for a single user that’s decremental to the majority, so think it through carefully. Striking the right balance is the key to success.

5 reasons to avoid feature bloat

• more code means a greater chance of conflict and malfunction
• more features can make your product harder to test and support
• if you code something niche, users may demand more niche features on top. When do you draw the line?
• too many features can make a plugin appear too complex for new users — usability can be severely compromised
• a simpler plugin may come along in the future and make your plugin appear too clunky to use

So should I build it?

When evaluating a feature request ask yourself these questions:

1. Is the feature niche, or does it benefit all users? – Check demand! If the idea crops up frequently, consider adding it.
2. How difficult is this feature to code – if it’s a quick win, it might be worth adding.
3. Does it impact other parts of the plugin negatively? – if a feature is so big or complex that it affects usability or performance you should consider leaving it out.
4. Is the feature within the plugins original scope? – Don’t add something totally irrelevant – focus on your plugin’s core purpose.
5. Do competitor plugins do it? – This is the least important point in my opinion (do what’s best for your users, rather than what others do), however it should still factor into your decision as some users could see a missing feature as a barrier to entry.

If the feature turns out to be out of scope or too niche, don’t add it to your core plugin. Suggest a customisation or consider building a separate extension (or snippet) for those whom need it.

Take a real world example; a user wanted WooCommerce (an eCommerce plugin) to show extra personalisation options for a product. Do all users need this? No. Is it a simple addition? No. Does it impact other parts of the plugin? Yes, it needs lots more admin fields. Therefore it was built as an extension. The feature is now available (user happy), the admin panel in core has not been made more complicated than it needs to be (majority happy), and its a paid addon (dev happy). Happiness all round.

Reaping the benefits

By avoiding feature bloat you’ll end up with a more focused, easier to use, higher quality product which does what it’s supposed to do, rather than a product which spreads itself too thin in a futile attempt to please everyone.

And of course, if you decide to pursue out of scope, overly complex, or niche feature, you’ll have a way to monetise your product through extensions whilst still keeping your user base happy. Makes perfect sense!