Ahhh Version 1. Back when the code was simpler, there were less features and less complexity, and everything was focused around a single, simple idea.

Every WordPress Plugin developer will eventually be faced with customer support and customer questions that lead them away from the original goal of their plugin. The question is, do you implement feature requests just because the customer asked? Or do you say “no” and stay true to your original vision?

Saying “no” can help prevent scope-creep from twisting your plugin into a monster pile of bloated code. On the other hand, saying “no” could also mean you lose a paying customer.

More paying customers does not mean more profit.

Imagine 2 different WordPress plugins. Plugin A makes 5 million dollars per year, while Plugin B makes only $10,000 per year. Which plugin would you rather own?

What if I then told you that Plugin B is more profitable than Plugin A? The problem with Plugin A is that it has a huge amount of customer support from confused customers, resulting in the need to hire a lot of people to do support. So many, that it cost $4,999,999 per year. That means it actually only made $1.

This scenario is actually true for quite a few of the large WordPress plugins. And it’s what can happen if you start saying “yes” to feature requests that don’t fit with your original vision, just so you can gain a new paying customer.

New features always have unexpected results. 

I have seen it time and time again, where adding a new, simple feature seems to be simple and straightforward. But once it is out “in the wild” and being used by customers, they use it in combination with some other setting you’d never considered, and it causes things to break. This means you have to patch the code, and more “fix” code needs to exist in your codebase. Every time “fix” code is added, that code also has the ability to cause problems, resulting in the need for more “fix” code. And before you know it, your plugin has more “fix” code than it does “original” code and “feature” code combined.

The best WordPress Plugins are focused, and solve a single problem.

While it might seem like a great idea to add all kinds of features to your plugin, it’s important to consider the complexity it adds for your users/customers. Every new feature will require set-up time by your customer. Every new feature will require education and reading docs by your users/customers. And every new feature will slow them down, which causes confusion and frustration. This concept is something WordPress calls “Decisions not Options”.

Another philosophy WordPress has is to “Design for the Majority”. If you’re designing features that only a few people will use, you’re adding complexity that isn’t helpful for most people.

If you find yourself always getting requests for new features that only help a small group of people, you may have actually stumbled upon a new niche market. A true niche-market is typically best served by a niche-specific plugin. This is an opportunity to build a brand new plugin specifically for that niche. But it is not a good idea to say “Yes” to adding features to a plugin that was not built for that niche.

Keep to your vision

It’s way to easy to let yourself be taken off track from your original vision for your WordPress plugin. But your original vision was focused and clear. Following the whims of customers leads to a complicated, frustrating product that is difficult to use. 

If you feel like the vision is changing, perhaps it is actually a new vision. Perhaps its time to take what you’ve learned and start a brand new, more niche-focused plugin. 

Either way, keeping to the original vision for your product will help to keep it simple, straightforward, and working well. And more often than not, the right answer to feature requests is “no”.

Leave a comment

Your email address will not be published. Required fields are marked *