5. Managing Feature Requests

Every store owner would love to pay for one piece of software that does everything they need, and they want our software to do it. This is okay – who wants to pay for a bunch of different things if they can get an all-in-one solution? Who doesn't want things to work exactly as they imagine?

The nature of selling generic software rather than a customized solution is that we have to say "no". We may not add features a merchant wants, and even if we're thinking about adding them, it may not be as part of the existing app or plugin.

We need to manage expectations appropriately so merchants don't think we're making their hopes and dreams come true when we're not. In the case of features, under-promise and over-deliver.

We can encourage the merchant to check the plugin's changelog regularly to keep them informed on development updates.

Here's how to handle new features:

• Does the feature already exist? Merchants may not be aware of everything the software does. Tell them that what they want is already possible (without saying "Actually").

• Is the feature in development? If you're not sure, ask the lead developer for the project. If the feature is already being built, you can tell the merchant something like this:

  I have good news! We're already working on adding this feature :) While we can't give an exact timeline since we're still in the middle of development, my best estimate is that this can be available by the end of summer.

  Whatever time the lead developer says, multiply by 2x. If it looks like a fairly large feature, multiply by 3x.

• Is the development starting soon? If so, you can tell the merchant something like this:

  Thanks so much for your feedback – we really appreciate your help in making our software better :) We don't have this feature in development yet, but we are starting on development soon. Once our development team begins, I can give you a rough estimate of our release date for this.

• Is the feature planned? As in, we're taking votes for it, but nobody has spec'ed it out or started. If we haven't started building, and we don't have a clear spec on what this feature looks like, it's more like a "nice to have" at this point. Don't give the merchant the impression that it's coming soon or we're looking to build it. Something like this is appropriate:

  Thanks so much for your feedback – we really appreciate your help in making our software better :) This feature is on our idea board and planned for a future release, but we haven't looked into details yet as we're still gathering customer feedback for it. If you'd like to stay in the loop, we recommend checking the plugin's changelog on a regular basis. 

• Is the feature on our idea board? As in, we're just gathering votes still and we don't know if we'll actually build it. In this case, we don't give the impression that it's coming and we're honest about where the feature stands.

  Thanks so much for your feedback – we really appreciate your help in making our software better :) We have this feature on our idea board, but I'm not sure yet if it will make it onto our roadmap and into development. I've added your vote for it along with your feedback.  If you'd like to stay in the loop, we recommend checking the plugin's changelog on a regular basis. 

• Is this not a good fit? There are features that don't make sense for our product, and it's okay to tell people that and say no. Don't give the impression that this is something we're going to add, and try to suggest another solution if it comes close.

  Thanks so much for your feedback! While I can definitely see how this would help your shop, I'm afraid that it's not a great fit for our app / plugin. We try to make sure the features we add help the majority of our users so our product doesn't become bloated and untenable, and most of them don't use the app / plugin in this way. {Suggest another solution or point them to a developer that can help}.