One of the things with which I’ve just started experimenting is soft launches of product updates. That is, I’m providing updates to users of certain plugins through automatic updates in order to garner feedback – if any – prior to announcing it and launching it to everyone else.

For those involved in the software world, this is nothing new, but for those who are just getting into building products for others or who are looking for ways to test the proverbial waters of their projects without a public announcement for every single release, then this isn’t a bad idea.

Wikipedia defines a soft launch:

A soft launch is the release of a website, hotel, or other product or service to a limited audience. Soft-launching is a method for gathering data on a product’s usage and acceptance in the marketplace, before making it generally available as a hard launch or grand opening.

I think the idea of soft launches, open source, and the general WordPress economy is a really broad topic about which there’s a lot to discuss, but I thought I’d share some quick ideas based on my experience for those who are looking for a process on how to perform soft launches of their work with their existing customer base.

Soft Launching in WordPress

If only software launches were this amazing.

If only software launches were this amazing.

Before getting into the actual process, there’s a few things that are worth mentioning – perhaps even disclaiming – as it relates to soft launching in WordPress.

  • For those who have plugins in the WordPress Plugin Repository, it’s likely that you already have a sizable base of users. It’s difficult to soft launch to this audience because whenever you provide an update to the plugin, it’s made available to everyone.
  • If you’re working with themes, then you’re likely selling it through your own channels, and/or selling it through a marketplace. If you’re selling it through a marketplace, then making it available to a small segment of the audience is tough because, like plugins, when you provide an update then it’s sent out to all customers.

Because of the points above, this assumes that you have a more control over the product for which you’re trying to soft launch and that’s part of the point of this post. This may even be the initial pre-requisite or initial step.

Step 1: Control

If you’re someone who’s looking to begin experimenting with performing soft launches, then having control of how your work is distributed is key.

That is, you need to be able to have access to a segment of your customers and be able to give them the option of upgrading their product. To do this, you need to have your work in other places than just a public repository that pushes out automatic updates.

This means that you need to be able to access your customers through some other channel that the one through which your work is primarily sold and distributed. Case in point: If you’re looking to soft launch a plugin that resides in the WordPress Plugin Repository, then you need a way to access your customers – the repository gives you access to 100% of your customers.

Thus, by definition, you can’t perform a soft launch by releasing your work to everyone – you need to be able to have access only to a certain segment of your user base.

Step 2: Tools

How you end up segmenting your customers can vary between something as simple as maintaining an email list for those who have subscribed to updates, to being able to distribute your work to those who are paying customers, who have license keys, or who are using a version of the plugin from a specific branch.

When it comes to maintaining these segments, there’s a variety of tools that are available:

  • For the WordPress Plugin Boilerplate, I’ve simply used a MailChimp newsletter. This allows people to opt-in and opt-out of receiving information as they please. Those who are more technically inclined can follow the work directly via GitHub.
  • Andy Fragen’s GitHub Updater is a utility that I really like (and have talked about here) that makes it possible to host your plugin on GitHub and provide automatic updates for your users for those who have downloaded the code from that channel.
  • Easy Digital Downloads by Pippin Williamson is part of the toolset that I use to power The Pressware Shop and it also makes it easy to provide updates to those who currently have a version of your product installed.

Regardless of what you opt to use, this gives the ability to access a segment of your customers (or potential customers) and distribute an update to them. Permitting that you have the proper support channels setup, this is a great way to gather feedback prior to announcing an update.

Step 3: Feedback

How you garner feedback often depends on how the project is distributed. For example, if you’re primarily distributing updates via announcements and links in a mailing list, then you’re likely going to receive feedback via email.

No brainer, right?

Similarly, if you have a support forum that’s hooked up to your shop or accessible via your software, then users are likely going to contact you via that channel since it’s the one with which they are most familiar (and that’s arguably most prominent).

Personally, I only use email though The Pressware Shop uses Help Scout as a middleman for email.

Regardless of what method you choose – even if it’s something like Twitter (though I’m not really a fan of using social media channels like that for support, but that’s another post) – you need to have a way to organize all of the information that you receive.

This may mean labeling emails, this may mean people open issues on GitHub or your ticketing system, or it may mean you star the input to read later. Whatever the case may be, the important thing is to keep the feedback organized.

What you do with it is out of scope of this particular post, but it ultimately should contribute something back into the project.

Step 4: Release

Knowing when the do a public release can be tricky . Generally speaking, it may take a few iterations on updating the project, garnering feedback, updating the project, garnering feedback, and so on. I know – this sounds almost like a mini-development cycle. And that may very well be the case (though it shouldn’t be the norm).

What I’ve found is that when people go radio silent, it usually means that things are working well. People are really good at letting you know when something isn’t working or something isn’t performing well, but they aren’t so good at simply saying “Everything’s all good – carry on.”

No news is good news.

So in whatever way you’ve opted to get feedback from your users, know how to read the signals that the product is ready for a hard launch or a public launch when there’s little left being discussed.

Each Project Is Different

Ultimately, each project is different. What I’ve outlined here is largely based on personal experience. I know that there are other ways to go about doing this, but I thought it was worth sharing if for no other reason than a few people have contacted me asking for my process on this.

Over time, this may change, but this is what I’ve found to work right now.

Finally, for those who are curious as to how soft launching a product is different than running a beta of a product boils down to the fact that the soft launch should be in the post-beta stage. Generally, the software that’s being shipped is already at the latest stable version. Yes, there may be small fixes you make here and there, but the bulk of the work and the testing has been done.

You can have your own goals for a soft launch, but I generally use it to get feedback from people who I consider to be customers (and loyal ones, at that) so that they’ll contact me through the usual support channels before I announce something is like and available for sale.

You and your customers should have some type of relationship such that having conversations through support about updates yields significant returns. When you hard launch something, you’re basically opening the flood gates for practically everyone to access your work – and that may yield criticism (or it may not) over things that could have been caught sooner.