How to Reevaluate WordPress Plugins After Launch

You put your heart and soul into creating and perfecting your WordPress plugin.

You slaved over your code. You even made it through the wrenching, drawn-out process of submitting it to the repository. You waited, you responded, you made requested changes, and now, finally, the day is here. It’s been approved. Your plugin – your baby – is online and available for download. Time to celebrate?

Not quite!

Before you pop open the champagne, or move on to the next process, you still have some work to do – especially if you’re serious about your business as a WordPress plugin developer.

Post-launch, you can take action to improve your plugin, foster great relationships with your user base, and increase downloads.

Post on

Mastering the post-launch re-evaluation process can also raise your plugin’s ratings, which will help grow your user base and even set yourself up for greater success with the next plugin you create.

What Happens After You Release Your Plugin?

After you launch your plugin, you’ll start to get feedback, reviews, and support requests. It’s tempting to get a little lost in this “honeymoon” period if everything’s going well — or to wallow a bit if the response isn’t as positive as you’d hoped.

Most probably, within a week or so, support requests will take up increasing amounts of your time each day. And while you can get mired in the day-to-day support of your plugin, it’s important to take the time to step back and reevaluate your plugins after launch with fresh eyes.

First, though, you need to set up a system for processing feedback. You can do this before you release your plugin, ideally, or as soon as possible after launch.

Questions, complaints, reviews, support requests — any type of feedback about your plugin that your users take the time to give you is valuable information.

Any type of feedback about your plugin that your users take the time to give you is valuable information.

Post on

One solution is Freemius’s Insights, which provides an easy, in-Dashboard method for your customers to provide feedback, as well as for you to communicate with them. Insights is a powerful way to get an excellent cross-sectional portrait of how your user base is feeling about your plugin.

Using whatever tools and methods make sense to you, and with which you’re already comfortable (no need to make things more complicated now), create a system for collecting and categorizing all incoming user data. You can use note-taking apps such as Evernote for this, or plain old pen and paper.

You’ll also want to keep a tick-mark tally of the substance of these comments and questions based on categories.

So, for instance, If you get a lot of requests for a specific feature to be added, it’ll be helpful to know how many users asked for it. Extrapolating from your download count will tell you whether this is something a significant portion of your users would likely welcome.

With your system for processing feedback in place, it’s time to take some action.

Your Post-Launch Evaluation/Action Plan

A week or so after launch, sort out your notes, support requests, and user questions into the following groups: bug reports, questions about the plugin itself (download, activation, set up or use), new feature requests, and UI/UX issues.

Next, begin to work your way through them. You may have to work your way through some of these categories more than once, as new feedback comes in. But within a month you should have a fairly good idea of the general comments in each category.

Remember that data is your best friend in the post-launch period. Freemius Insights can offer a lot of important information that’ll help you as a developer evaluate your plugin in light of user feedback via other sources (i.e., support requests and reviews).

For instance, if you integrate Freemius with your plugin on the sites your plugin is installed on – provided those site owners opted in when they activated your plugin – you can gain access to the following types of data:

• Plugin State (active, inactive, uninstalled)
• Plugin Version
• Site URL
• WordPress admin name
• WordPress admin email
• WordPress locale (country + language)
• WordPress version
• PHP version
• MySql version

Debug

First and most crucially, you need to address any reported bugs. Reported bugs are the most critical issues, since they have the biggest potential to do the most harm to users and to your reputation.

Of course, conscientious plugin developers try their best to debug plugins before release. It’s the ethical thing to do but it’s also obviously in your best interests, too. The more consistently your plugin operates, the less work you’ll have to do after release.

But even the most experienced developers have problems to address post-launch. That’s because it’s just not feasible to control and test for every possible permutation of user operating conditions.

Even the most experienced developers have problems to address post-launch. It’s just not feasible to control and test for everything.

Post on

As the author of a leading SEO plugin for WordPress, Joost de Valk has quite a lot of experience with the plugin development process. Discussing his own post-launch plugin experience, he had this to say:

Almost as soon as I released the plugin, people who updated were telling me that it worked wonderfully, and others were telling me that it didn’t work for them. Turns out I hadn’t tested the plugin with a Google Analytics account that has only one website registered; I expected the websites to be an array. Fixing this bug was easy, but determining that this was the problem took a while.

No matter how much effort you put into testing and debugging pre-launch, it’s entirely possible you’ll have more issues to address.

So think of your users as your best debugging and testing team. They can dig far deeper than you possibly can on your own.

Revise Built-In Support Documents

Next, take a look at the questions you’re getting asked and the requests for support. Working from that list, begin to compile a list of the most frequently asked questions and problems.

Remember, a great plugin with shoddy or no documentation is less valuable to many users than a satisfactory plugin with excellent documentation.

So if your users are asking variations on the same question, or are running into the same problem, then consider adding more information to or otherwise revising your plugin’s built-in support documents.

For instance, let’s say you get several requests for support based on a configuration-based user error. It’s not a bug – just something the users aren’t quite sure about. This is a great example of a situation where revising your help documentation can help both your users and you.

You could add a new section to your support documents and including visual aids such as screenshots of each major menu would help your users feel more confident in the plugin, and would help you by cutting down on repeat support requests.

If you need some tips on writing better documentation, check out an excellent post from Siobhan McKeown for Smashing Magazine titled “Writing Effective Documentation for WordPress End Users.”

Address UI/UX Issues

WordPress users are becoming savvier and more sophisticated every day. More of them are taking a hard look at plugins before they install and activate them on their sites. A growing number of them go through a stringent preview analysis before downloading.

But users have a hard time evaluating user interface and user experience (UI/UX) before actually activating and playing around with your plugin.

So unless you were able to test out your plugin pre-release with a varied group of WordPress users, you might find yourself confronted by comments about your plugin’s UI/UX that are surprising to you.

It might be tempting to dismiss comments about the user experience or interface as “just opinions.”

That’s a mistake. If your users encounter non-intuitive interface settings or menus, they may grow frustrated and simply move on to a competitor’s plugin instead.

It might be tempting to dismiss comments about the user experience or interface as “just opinions.” That’s a mistake.

Post on

Take UI/UX issues seriously, especially if you receive the same comment from more than a few users.

Add New Features

After you’ve addressed existing issues, it’s time to think about adding new features that have been requested or that your target audience needs.

Whether it’s appropriate to add a new feature will depend on your plugin, your available resources, and your business model. One option to consider, if you’d only planned a free release for this plugin, is to add a premium version with enhanced functionality.

Before you decide to go this route, however, make sure that you have enough user interest to support the investment of additional time, resources, and energy you’ll need to make a freemium/premium structure successful.

Also, think carefully about the financial and legal ramifications of expanding your plugin this way. Once you begin accepting money for your work, you’re officially in business for yourself. You’ll have to report income and pay tax on it. In addition, you’ll have to set up a secure system for accepting and processing payments. If the latter is not something you’d like to spend too much time on, there are services that offer an automated solution for that.

Conclusion

Don’t get discouraged if your list of “things to fix” seems to keep getting larger and larger, or if the feedback is less positive than you’d hoped for. As Manuel Vicedo wrote:

Be persistent and consistent

Of course, not every response was good.

In these three months, we have had our ups and downs. Some agencies were already using existing page builders, while others resisted change a lot. This may get disheartening at times, especially since you are just getting your newborn plugin out into the world. It will be rejected many.many times.

This can be very disheartening at times. Who wouldn’t feel frustrated after all their invested time and hard work was met with rejection?

After trying to get in touch with over a hundred potential customers, I realized it’s just a matter of being persistent. It’s very unlikely that you will succeed on your first try, so you just need to keep pressing on. If things don’t move forward, refine your idea and try a different angle.

Finally, thoroughly debrief your own experience as a plugin developer. Think back over your post-launch period and process any lessons learned.

Then get back to work and create a new plugin.

What would you add to our list of post-launch evaluation tasks? Share your thoughts in the comments below.