Feature Flags for Product Managers: Give Yourself Options for Handling Risk

As a product person, have you ever witnessed large, complex releases result in outages or rollbacks?

Have you wanted to make configuration changes in production without a release?

Have you released new features to your customers only to find out that they don’t solve the problem they were intended to solve, or don’t solve that problem as well as you expected?

If so, read on.

What is a feature flag?

A feature flag is a technical design pattern (re: a way to build your product) which allows your product to behave differently when enabled or disabled. We’ll go over some use cases and examples below.

How can feature flags benefit your customers?

For this article, I want to make some assumptions about all users of software products. As a product person, I always try to be very careful when making assumptions about customers, but I believe the following assumptions are reasonably accepted across the industry.

We can assume that all customers want a reliable product, free from defects. We can also assume that if a defect is found, customers want that defect fixed in a timely manner.

Building on this assumption, we can assume that customers who opt-into using beta features are willing to experience some defects at the price of being the first users of new features.

How do feature flags provide more options to handle risk?

Let’s discuss three possible use cases;

1. Change configuration without a production release: For example, your product has a form which allows you to collect some user data. This form contains a drop-down with four possible options, and you want to add an additional fifth option.
2. Mitigate risk during release: For example, Your team works in a highly controlled environment where production releases carry a lot of risk, and complications during a release must be kept to a minimum.
3. Testing new features with early adopters (beta testing): Your team wants to test certain features with customers ahead of time, to ensure those features are truly solving the problems they are designed to solve for your customers.

How does changing configuration without a production release help mitigate risk?

Making changes to a product environment always carries risk. Typically, the larger the change, the larger the amount of risk that something will go wrong. Typically configuration changes are very small changes.

Often times when developing new features, you will be able to predict small tweaks and changes that may need to occur in the future. If you can reasonably predict these changes, they can give you the flexibility of implementing them in a production environment with minimal risk.

For example, if you have an application which makes external API calls, and you know the API you currently call will soon be replaced by a new version, you can use them to switch between calling the old API and the new API. You can then toggle this functionality at your leisure, potentially in a production environment without a release.

I’m not saying that you shouldn’t first test integrations like this in a lower environment. Releasing disabled functionally doesn’t mean you can skip testing that functionality. Doing so just lets you enable this functionality in a production environment that you’ve hopefully already tested properly in a lower environment.

How do feature flags allow me to mitigate the risk of defects during a release?

Feature flags allow you to control the risk of a failed release by allowing your delivery team to slowly release new chunks of testable code into production, without the overall feature going live.

Imagine you are the product manager for a ride sharing product that is in the process of developing a scooter rental feature.

In this example your delivery team can write all the code necessary to build the scooter rental feature over the course of multiple release cycles, and send smaller chunks of code to production when they are ready. Because the feature is turned off, your customers will not experience partially built functionality. All they experience is the same ride sharing product they know and love, until all the code is deployed and you are ready to flip the switch and enable that scooter rental capability.

This prevents your delivery team from having to write all the code for our scooter rental feature and add it to your release in one big chunk. Adding a very large amount of code to a release increases the complexity of that specific release and therefore increases the risk that something could go severely wrong, causing an unexpected outage. Unexpected outages are typically a situation which requires your team to fix the issue on the spot, or roll back the release entirely.

They also give you the option of “turning off” misbehaving functionality during a release. For example, if the scooter rental feature breaks our car requesting functionality when we flip it on, we can simply flip it off.

This is an especially powerful option if you are developing software in an environment where outages must be kept to an absolute minimum.

Keeping release complications to a minimum is always good practice though, and your customers will thank you for it. Unexpected outages can reduce customer confidence in your product and drive them to switch to another product. Depending on your product, unexpected outages can also result in Service Level Agreement (SLA) violations with real financial implications for your company.

How can feature flags let me use beta testing to reduce risk?

In additional to allowing you to control the risk of complications during a release, they also give you options when dealing with the risk of defects.

They can be used to identify some features as “beta” features - sometimes referred to as “beta flags”, which allows you to flag specific features to be part of your products set of features which are available to beta testers.

This allows you to expose these beta features to your customers who have explicitly agreed to trade product reliability for the ability to use your latest features, typically by explicitly opting-in to see beta features.

Beta testing is a great way to get feedback about new features that are in development before they are released for general availability. This allows you to get important feedback from your customers about how they like the feature in question, which will enable you to make changes before the feature is available to your entire user base.

Allowing customers to help you build better functionality via a “beta flag” means that your product will be more successful in solving whatever problems it’s meant to solve for your customer.

What are some considerations when using feature flags?

There are some things to watch out for - testing being perhaps the most important. I have personally witnessed much higher success rates when they are used on products which have high levels of test coverage.

Having a high level of test coverage is critical since you need to ensure none of the smaller chunks of code you are releasing in a disabled state introduce new bugs. Often times you won’t be able to test the new feature in its entirety until all the chunks of code are released.

Conclusion

As a product manager, feature flags provide you with options that you can use to mitigate risk. Specifically, they allow you to mitigate the risk of defects, and the risk of complications during a release.

They can be especially helpful in high-risk environments where release windows are tightly controlled and the cost of release complications is high.

When using, it’s important to have good automated testing coverage as you may not be able to manually test new functionality in its entirety until it is enabled.

Any opinions expressed in this article are my own and not those of any current or previous employer.