It has never been easier for engineering teams to build and release new features for your customers. This fits well with our philosophy of shipping value to customers on a regular basis but does your customer experience this in the same way? And who should be in charge of releasing new features?

Releasing fast and often can be very disruptive from a customer perspective when they are used to a certain way of working and that way has now changed for what appears to be no reason. In addition to that, your support team is usually not up to date and thus cannot help your customers. All of this can quickly snowball into creating a customer perception of a company that does not design or release with their customers’ best interests in mind which leads to decreased loyalty and sales.

The other side of the spectrum is preparing a huge product launch and waiting for all the features to be functional before releasing it to the public, a so-called big bang release. This approach comes with its own set of pitfalls. First of all, you miss out on a lot of feedback from your customers meaning that you cannot work iteratively and might have built a solution that does not solve the problem. Secondly, because you spend so much time finishing all the features you increase the cost of your initial launch meaning there is a higher risk of things going wrong (and things will go wrong) and you increase the difficulty of fixing those problems.

Instead of leaving these responsibilities to the engineering team, it should be done by the people that know the customer the best, this could be either the product manager or the marketing/customer success/sales team when available.

A better way to release new features

We have established that launching new features suddenly and without warning is not a good move. Customers get confused and may not like or even use the features because they solve the wrong problem. Let’s have a look at some better ways to release new features.

The segmented roll out

This strategy allows you to control the release process more thoroughly and mitigate risks as they arrive. 

The idea behind a segmented release is that you start by rolling out the features to a small subset of your user base, e.g. 5% or so. Then, after a couple of days, check in on questions and complaints. If necessary, go back to tweak and fix based on their feedback. Keep repeating this with 10% of your users, then 20%. Plan for a period of a month before the feature is available to all of your customers. 

You should define segments such as power users or customers that have expressed interest in beta testing as they are more likely to give useful feedback. You can also segment based on country so you have enough time to translate all the documentation in each language.

In order to make this strategy a success, you will need to work together with different teams. The engineering team will have to adapt their codebase so it leverages the chosen feature management system and you will need to work with the customer-facing teams to help define segments and set up a process for receiving their feedback. We have built ChangeHub to help communicate about the many changes that occur.

It’s still important to communicate with your customers about these changes. A popular strategy by Slack is to announce it upfront and tell your customers they might start seeing the feature in the coming weeks. LinkedIn uses a different approach where they only announce a feature when a subset of their users has already been using it.

The pre-release announcement

Another strategy is to send out an email announcement to your customers before the feature has even been built. This allows you to field-test certain ideas, let customers contribute early on or gauge interest to see if it is worth continuing. Sometimes, cutting losses is as important as maximizing gains. Announcements can help you with both.

You do not have to make an announcement for every feature or bug fix as customers will quickly get annoyed by this and stop paying attention. Use it sporadically and consider targeting only a subset of your customers from which you believe you’ll get the most value.

This is a technique that is successfully implemented by Harvest. We have been using their platform for years, and we remember multiple cases in which they announced a certain change but revised it based on the comments on the announcement post. Sadly enough they removed the option to comment on their blog, but this is a clear case where they indicate they are not making the change because of the feedback they received.

Let the customer decide

The final strategy is similar to a segmented rollout but it puts the customer in control so they can decide which features they want to take for a spin. 

While you might be so sure that a feature will improve the usability and customer experience it is still possible for the customer to disagree. Letting them decide which features they want to try out is a good way to measure interest and see which ones just don’t cut it for them. By giving them a choice it also makes them feel that you respect their involvement and opinion and they become more eager to give feedback. 

You should only consider using this strategy for UX improvements or features that are close to being finished and have gone through earlier rounds of feedback. Avoid using it for features that could result in data loss as this could create distrust with your customers.

GitHub has been applying this technique for some time already. They added a “Feature Preview” section where you can enable certain features and leave feedback. They’ve used this previously to gather feedback about new features such as the notifications experience.

We have highlighted a couple of strategies that your marketing teams can use to release features to customers. We don’t believe that a one-size-fits-all solution exists and we would recommend you to experiment with multiple strategies as each of them have their own strengths and weaknesses.

Join the conversation