When Is a Dark Launch the Right Release Strategy?

This is a guest post from Michiel Mulders.

Have you ever considered different launch strategies for product updates? Did you ever experience the launch of a feature that the audience of your application didn’t actually desire? Dark launches are here to save you!

A dark launch is a safe way of releasing a new product to a limited audience. You basically release a product to a subgroup of your users to test if they like the new feature and if it’s useful to them. Based on this feedback, you can either choose to release the product to the full user base or make further improvements to the actual user needs.

Often, dark launches are used in combination with feature flags. A feature flag allows users to self-enable new features and test them out. This way, users are in control and they can decide if they want to select a new feature. However, some tech organizations prefer to control the process of dark launches by selecting a subset of their users themselves and only pushing them the new feature update.

This article will answer the following questions about dark launches:

• Why would you choose a dark launch?

• How do you implement a dark launch?

• How do you manage risks with a dark launch?

• What are the pros and cons of dark launches?

Let’s explore first why a dark launch is useful for your organization.

First of all, a dark launch is an interesting approach to gauge the interest in a new feature. Instead of launching a feature to your full audience, you can try out a new feature among a limited audience to see their responses.

Therefore, it’s considered a safe way to test a new feature in an actual market without fully exposing the feature. Your company’s reputation is important, as is user satisfaction, so it’s better to safely try out your feature with a limited user base. This means your organization can mitigate risks but also create a faster feedback loop for newly developed features. Therefore, time to market can be decreased, and customer acquisition will increase—which is why a dark launch is a clear advantage over your competition over time.

Besides, a dark launch allows your organization to safely try out a new feature in a production environment. You can gather statistics and important metrics about the feature but also analyze your users’ behavior. This data allows you to make a more informed decision about releasing the product to the full user base or refining the feature to better fit users’ needs. In other words, you want to measure if users like the new feature and if it satisfies their needs.

Some organizations even choose to gamify dark launches by only allowing loyal users to try out new features. However, you should be sure that you have a diversified selection of users that represents the general user base for your product. Often, you’ll find tech-savvy users in such dark launches who don’t fully represent the audience of your application. Therefore, it’s a nice option to gamify dark launches, but be mindful about the audience you’re testing a feature with.

Now that we understand why a dark launch might be useful for your organization, let’s learn how to implement a dark launch.

So, let’s answer the question of how to implement a dark launch. The most common approach is to allow the user to decide if they want to toggle on experimental or new features themselves, making use of feature flags.

Alternatively, the organization remains in control by enabling new features via feature flags for a select number of users. This means the organization forces this set of users to use the new features.

Both approaches are interesting ways to test a new feature. It depends on the audience of your application. Some users don’t like to be part of test programs, while others do. Choose which option works best for your user base.

Lastly, you can opt to not make use of feature flags. In this case, you need to find an alternative, likely more complex, solution for pushing updates to a limited number of users. For example, you can push an update of the application to this smaller set of users. 

However, this adds more complexity and you need to design a solution to be able to roll back features. This can quickly become a messy operation. Whereas using a feature flag you can switch a simple boolean to enable or disable a feature.

A great advantage of dark launches is that they help you manage risks. They’re a safe way of releasing features to the production environment without risking your whole company’s credibility. Also, users who try out features released via dark launches know they can expect potential bugs or incorrectnesses. You get a better idea of how the market reacts to the new feature and if it’s worth rolling out to your whole user base.

Dark launches allow you to bundle small feature requests or change requests to release them to your users. This approach accommodates smaller releases of functionality. In addition, you can frequently roll out new features in a safe way instead of bundling them into a higher-risk major release. Therefore, dark launches facilitate a more agile approach.

Now, let’s discuss the benefits and disadvantages of dark launches.

Here’s a list of the most important benefits of dark launches:

• Present lower risk

• Provide a safe way of releasing a new feature

• Gauge the interest of a new feature

• Gather insights quickly on how users interact with a feature

• Use feature flags

In addition, your organization can possibly save money as less time is spent on QA testing. You can just use your user base for testing new features safely and receiving much more valuable feedback!

Next, let’s take a look at the disadvantages of dark launches.

A feature tested via a dark launch can still be met with dislike from your user base. There’s no guarantee that your users will like a feature when dark launch users liked the feature. You might receive subjective feedback and only get feedback from a subset of users. Most users don’t mess with feature flags or don’t intend to try out new features. So, those users might have more valuable feedback, but you won’t always reach them with a feature flag in their settings. For example, some older users are generally not concerned with their settings or trying out new features.

Let’s be clear – a dark launch does not count as user testing. Often, organizations use dark launches in this way, but this shouldn’t be the case. You should do proper testing before launching a feature via a dark launch. Therefore, you should treat a dark launch as a real launch because you’re dealing with your active user base. It’s not a nice experience for your users if they encounter one or multiple bugs.

Lastly, feature flags need to be managed properly so you don’t get a mess of feature flags that enable or disable portions of other functions. Try to keep your code clean and don’t build up technical debt.

Dark launches are a great way of gauging the interest of a new feature. They allow your organization to mitigate risks and create a faster feedback loop between developers and end-users for new features. This allows you to build better products faster without the risk of releasing an unwanted feature or a feature that still contains bugs. To conclude, with the use of feature flags, your organization can quickly develop a safe dark launch system.

Michiel Mulders is a passionate blockchain developer who loves writing technical content. Besides that, he loves learning about marketing, UX psychology, and entrepreneurship. When he’s not writing, he’s probably enjoying a Belgian beer!