One thing that’s fairly surprising when you start offering software products is the never-ending stream of feature requests. And the more popular your “thing” gets, the more requests you’ll receive, obviously.

What’s particularly difficult about that is making sure that all requests get addressed, and whoever submitted them gets a response / explanation. With enough requests coming in, you really do need a system in place to make handling them efficient.

Today, let’s welcome Katie Keith of Barn2, who’s going to share how they built a better, more effective “feature request” system for their WordPress plugins, what the result was, and how you can emulate the same principles.

This is a contribution by Katie Keith:

When we started selling plugins 2 years ago, I was amazed at how many feature requests we received. It felt like no one was happy with our plugins, as everyone wanted something that wasn’t possible!

At first, the number and range of feature requests was disheartening and a bit overwhelming. Over time, I’ve learned to view customer feedback and feature requests as an opportunity rather than a threat.


#casestudy Building a better ‘feature request’ system for your #WordPress plugins
Click To Tweet


This is the story of how I created a better feedback system for our WordPress plugins. I’ll share why feature requests are so important, how Barn2 collects them from our customers, and how to manage a feature request list. I’ll give you my top tips on how to communicate with customers about feature requests, turning a “No” into a positive. Finally, I’ll tell you how to use your feedback system to create an effective road map for improving your plugins in a way that maximizes future sales.

Feature requests are a huge opportunity

I believe that every feature request is an opportunity to make your plugin business more successful.

Not everyone would agree with me. Before we switched from designing websites to selling plugins, I lost count of the number of plugin companies who seemed resentful when I sent them a feature request. As part of a web design project, I would often install a plugin for a client and find that it lacked a vital feature. When I contacted the plugin company to request the feature, they would typically reply in a defensive way. They seemed to think that their plugin was already perfect and I was the only person in the world who thought it was missing something.

I think that people with this attitude are missing out on opportunities to improve their plugins.

Why feature requests are a good thing

There are lots of reasons why feature requests should be viewed positively:

  • They’re a way of getting valuable insider knowledge on gaps in the market that you can exploit and profit from.
  • You can measure demand for each feature and prioritize development time to maximize future sales.
  • Even if you say “No” to a feature request, it’s an opportunity to show you’re listening and improve customer loyalty, so they’re more likely to keep renewing their plugin license.
  • You learn more about how people are using your plugins. This can feed into your marketing activities and uncover new use cases.

I’m not saying that you should implement every feature that your customers request. That would result in a bloated plugin that’s a nightmare to maintain. It would also make it impossible for you to prioritize or use your time wisely.

Instead, you should use feature requests as evidence on how to make your plugins more successful.

Collecting feature requests

There are lots of different times when a customer might want to send you a feedback request.

The first challenge is how to prevent customers from requesting features that already exist! I used to find that lots of our plugin customers were sending feature requests for things that were already possible. It was nice to tell them the good news, but would have been even better if they could have discovered it for themselves! That’s why it’s so important to create a good knowledge base and clear lists of your plugin’s features.

How Barn2 collects feature requests

Customers provide feedback at different times and in different ways. Our feature request system allows customers to feed back when the time is right for them:

Plugin Feature Request Form - part of our Feature Request System

  • General support requests – The majority of feature requests are disguised as general support queries. The customer contacts us to ask how to do something with one of our plugins. Unfortunately this isn’t possible, so I have to explain and treat it as a feature request. The key point is that I don’t just reply saying “No”. Instead, their enquiry feeds into our feature request system so that we can monitor these requests and improve our plugins in future. I’ll share exactly how we do this later.
  • Feature request form – Barn2’s plugin knowledge base contains a ‘Feature Request’ button immediately below the ‘Get Support’ button. This provides an easy and dedicated way for people to request new features.
  • Feedback request emails – We use MailChimp to send a quick automated email to every customer 2 days after their purchase. This email asks for feedback, which feeds into our feature request system. We also use the Jilt abandoned cart plugin to request feedback from people who didn’t buy from us.
  • Knowledge base analytics – We use the Heroic Knowledge Base plugin for our knowledge base. It comes with analytics, which we use to evaluate the knowledge base articles. While the main purpose of this data is to improve the documentation, it’s also helpful in identifying missing features. For example, customers sometimes leave negative comments because something wasn’t possible using one of our plugins. The data about failed knowledge base searches is also helpful in identifying gaps.

Managing a feature request list

Our plugin feature request list is a Google spreadsheet, with a separate tab for each plugin. We have further tabs for features that we have already implemented.

Here’s a screenshot of the feature request list for our free WooCommerce Custom Add to Cart Button plugin. (Note: The feature request lists for our premium plugins are much longer!)

Feature Request List

The feature request tab contains the following columns:

  1. Feature – A brief description of the feature
  2. Demand (1-3) – A score showing the number of people who have requested the feature. 1 is low, 3 is high. This score is based on the number of votes in column 6.
  3. Impact (1-3) – A score showing how important the feature is to future sales. For example, a minor enhancement that will please existing customers would score 1; whereas a feature that would open up the plugin to a new market and significantly increase sales would score 3.
  4. Effort (1-3) – A score indicating the difficulty in adding the feature. Unlike the other columns, 1 is high and 3 is low. A simple feature will get a score of 3, whereas one that would take weeks of development time would score 1.
  5. Score – This column is calculated automatically based on the scores in columns 2, 3 and 4. The formula used for this is: =SUM(B2:D2) – this is for row 2, and you would need to change the number for each row.
  6. # Votes – We use this column to manually record the actual number of requests for each feature.
  7. Notify – This is where we add details of the customers who have made the feature request. We use it to notify them when the feature becomes available.

I’ll tell you how to prioritize new features based on this data in a minute.

Responding to feature requests

When you receive a feature request for something that isn’t possible in your plugin, your response should depend on which of the following categories it falls into.

Items already on the feature request list

You’ll often be asked for new features that are already on your feature request list. This happens to me at least once a day! When this happens, you can send a helpful and honest reply. Your response will depend on how likely you are to add the feature in future:

  • Popular features already on your plugin road map. I typically reply with something like this: “Unfortunately what you’re asking for isn’t currently possible. However, quite a few people have requested this and we’re likely to develop it in the near future. I will add your details to our feature request list so that we can let you know when it becomes available.” If you have a timescale for this feature, then that’s great – tell them. If not, don’t make any false promises. In my experience, customers are usually happy with this response and don’t demand an exact timeframe.
  • Non-priority features already on the feature request list. I normally tell the customer something like this: “Unfortunately this isn’t currently possible. You’re the 5th person who has requested this, and I will add you as another vote on our feature request list. We will add this feature if enough people ask in future. Realistically, I can’t tell you how likely this is because there are currently 139 items on our feature request list and we need to prioritize the ones that more people want. I will keep your details so that we can notify you if we add this feature in future.” I find that although this is bad news, customers appreciate and respect the honesty. Every customer thinks that the feature they want will be useful to everyone else, and can’t imagine why we haven’t added it already. Providing facts and figures puts their feature request into perspective, and they understand why we are prioritizing other tasks.

Either way, respond in a positive way that shows the customer that you are listening to them.

Items not on the feature request list

Every few days, I also receive a request for a feature that no one else has asked for yet. If I feel that it would improve the plugin, then I add it as a new row on the feature request spreadsheet.

Respond to the customer with something like this: “Thanks for the suggestion! Unfortunately this isn’t possible at the moment, and you’re the first person to request this. I will add it to our feature request list and we may add it in the future if enough people ask. I’ll keep your details so that we can notify you if this ever happens.”

Feature requests outside the scope of the plugin

You’ll receive lots of feature requests that aren’t really applicable to your plugin. For example, we have two WordPress table plugins – WooCommerce Product Table and Posts Table Pro – which create instant tables listing WooCommerce products or other types of WordPress content. Lots of customers request an import facility to automatically add their products/documents/posts/etc. in bulk.

The scope of these plugins is to display content from the WordPress database in a table layout. They don’t affect how the content is added or stored. Instead of viewing these queries as feature requests, I tell the customer about the built-in importer that comes with WordPress/WooCommerce. If those aren’t suitable then I recommend a suitable import plugin. Once the customer understands that they can use these tools to import their content and then display it using our table plugins, they no longer feel that our plugins are missing anything.

Other customers request features that are incredibly specific and not repeatable. When this happens, gently explain that their requirement is very specific and they will need to ask a developer to build it for them (ideally on top of your plugin!).

It may be that some feature requests are a great idea for a new plugin. For example, when we first released Posts Table Pro, lots of users started requesting WooCommerce-specific features such as add to cart buttons. Since Posts Table Pro was a generic plugin to list any type of WordPress content in a table, it didn’t feel appropriate to add WooCommerce-specific features to it. Instead, we launched WooCommerce Product Table and it is now our bestselling plugin!

Bonus tip: get paid for your recommendations

If you’re recommending a specific plugin regularly, sign up as an affiliate and you can even earn some commission! For example, we recommend a lot of official WooCommerce extensions to use alongside our WooCommerce plugins, and receive over $300/month commission as a result.

We’re also Codeable affiliates and when a customer would need to pay a developer to achieve their requirement, we recommend that they post a job on Codeable to find someone suitable. This helps the customer, while also rewarding us for the recommendation.

Suggest workarounds

By now, you’ll have spotted that it’s important to respond to all feature requests in a positive way. This doesn’t mean that you need to change your plugin for every (or indeed any!) customer who asks. What it means is that you should signpost the customer to solutions that will help them.

If your plugin can’t quite do what the customer needs, think creatively about some workarounds that might help them. It only takes a few minutes of your time, or less if you save it as a canned response to re-use for other customers. And it keeps customers happy and offers a way for them to keep using your plugin.

Some examples

This is a real plugin support email that I sent while writing this article:

Plugin Support Email

To help you think about the types of workaround you can suggest, here are some examples from our own plugin feature requests:

  • Someone using WooCommerce Product Table reported that one of the options on the settings page in our plugin didn’t work. This particular option could also be controlled directly in the product table shortcode, so we advised them to use it until we released a new version with the fix.
  • Another WooCommerce Product Table customer wanted to use our plugin with a third party product options plugin, instead of the official Product Add-Ons plugin that we have integrated with. We advised them to either switch to the official plugin, or let customers click through from the product table to the single product page where they could choose product options from the other plugin.
  • Users of our WooCommerce Private Store plugin sometimes get confused because they’ve set up the plugin to unlock the hidden shop for logged in users, but the plugin hides the WooCommerce Account page containing the login form! Hiding the Account page is intended behavior because our plugin hides all WooCommerce-related pages. Instead of viewing this as a feature request, we tell customers about other ways to create a front end login page that is not hidden by our plugin.

You know your plugins better than anyone. Learn about how people are using them to achieve different requirements, and use this knowledge to advise your customers more effectively.

How to prioritize new features

When you’re planning new features, you need an evidence-based way to decide which ones to prioritize. Fortunately, the feature request list I described earlier will give you exactly this!

Sort your feature request spreadsheet by column 5 (Score), in descending order. At the top of the list, you’ll discover which features are most in demand, realistic to develop and will make a difference to your sales.

Of course it’s not an exact science. Read through the top few features manually, and ignore any that don’t fit with your current direction. For example, the item at the top of the feature request list for our WooCommerce Product Table plugin would take many months to develop. Even though this item has a poor score for ‘Effort’, it has big demand which has pushed it to the top of the list. If we’re looking for simpler features to develop quickly then we will skip this item and focus on other tasks which are easier to develop, but still have plenty of demand.

But overall, sorting your feature request by score is an excellent start. Look through the most popular features and use this to plan a plugin road map for the short and medium term.

Implementing new features

When you launch new features, there are a few ways to promote them:

  • Email individual customers whose names are on the feature request list against that feature. They’ll appreciate the personal touch and will be more likely to renew their plugin license next year!
  • Email your existing plugin users to tell them about the new feature.
  • For major new features that will attract new customers, publish a blog post and publicize it.

The proof

When we first launched WooCommerce Product Table in October 2016, a huge number of people asked to display product variations in the table. (We hadn’t included this in our initial minimum viable product because it was a lot of work. We wanted to see if the plugin would sell first.)

It soon became evident that the plugin would be successful and was worth investing more time in. Support for variable products shot straight to the top of the feature request list.

Variations

In the 2 months before adding this feature, we received 24 sales. In the 2 months afterwards, we had 104 sales. Obviously it was a new plugin and was gathering momentum, so sales would have grown anyway. However, a huge proportion of our customers display variations in the product table, and this is essential to popular use cases such as creating a one-page WooCommerce order form and restaurant ordering system. I’m convinced that the plugin wouldn’t be nearly as successful if we hadn’t listened to our customers and added support for variations.

How to build a “Feature Request” system: wrapping up

I hope I’ve convinced you that customer feedback and feature requests are a huge opportunity for any plugin business.

They allow you to plan the future development of your plugins more effectively, adding new features that will directly increase your success. Even where you have to say “No” to the customer, they’re an opportunity to show you’re listening, build customer loyalty, earn affiliate commission by recommending other plugins and developers, and even to get new plugin ideas!

How does your own feedback request system work? I’d love to know how it differs to the one I’ve described above. Are there are any important fields I’ve missed from the feedback request spreadsheet? Can you suggest any improvements to my formula for prioritizing feedback requests? Please let me know in the comments below.

#casestudy Building a better ‘feature request’ system for your #WordPress plugins
Click To Tweet


About the author: Operations Director at Barn2 Media, Katie Keith is a WordPress web designer who specializes in helping companies to build their online presence. She’ll help you get the most out of WordPress and the web.

Don’t forget to join our crash course on speeding up your WordPress site. With some simple fixes, you can reduce your loading time by even 50-80%:

The post [Case Study] Building a Better “Feature Request” System for Your WordPress Plugins appeared first on CodeinWP Blog.

Categories: CodeinWP

Leave a Reply

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