Product Manager’s Guide to Using Feature Flags in Release Management

Application development is always an iterative process: you start with a minimum viable product (MVP), add features, and wait for user feedback before deciding what to change and what new enhancements to add.

But with feature release management, your product team can iterate on the fly, enabling you to test and validate different versions of a feature in a highly segmented and controlled process. Using staged releases, A/B testing, personalization, and operation toggles, you’ll be able to build a process to help your team innovate more quickly. You can then optimize features in line with what your target users need and external factors that might impact app performance or roll-out schedules.

In this guide, we’ll share best practices on how to leverage feature flags (also known as feature toggles or feature switches) to implement a more agile, more controlled, and less risky method of managing your product development pipeline.

Note: This guide focuses on consumer digital products such as mobile apps, web apps, and websites. Corporate and enterprise products may have to satisfy compliance and contract requirements that mandate a different release management process.

Defining Feature Release Management

What is release management?

Release management is the process that makes sure releases are ready for production and use in the real world. It’s about ensuring that the deployed product meets the stakeholders’ expectations—internal stakeholders as well as the end users. But release management is more than just a check on the quality of the application before going live.

The release management process guides the product’s transition from development to test, and from test to production. Done effectively, this gives you quality releases, plus communication and productivity improvements that let you deploy more frequently without increasing risk. Using a flexible release management process based on feature flags lets you shorten your time to market and make your product more competitive.

What are feature flags?

Feature flags are also called config flags, feature toggles, flippers, and switchers. Essentially, they have one goal: allow you to turn code on or off without having to modify the code base. The flags can be used across the entire range of platforms, from mobile apps and web clients to server side code.

With these flags, you can select exactly which features get included in a product build. This makes it easy to support A/B testing or create basic and deluxe versions of a product. It also enables an iterative, experimental development process that reduces risk: instead of rolling out a novel feature to millions of users all at once, you can turn it on for just a sample group, test it in a controlled way, and then make a deliberate decision about releasing it to a broader user base.

Why use feature flags?

For developers, using feature flags allows them to work in a continuous delivery process, one that produces a steady stream of releases and delivers functionality fast. They can code without worrying about whether some new function they think is ready should be checked in to the release branch, a development branch, the main branch, an experimental branch, or a personal branch in their source code control system. They can just do the work, focusing on building code and segmenting it in an itemized way so that each element can be tested and released when ready.

Benefits of this model include:

1. Control over the timing of new releases

Typically, when preparing for a new release, developers spend huge amounts of time on internal QA to ensure that their code doesn’t contain errors that will crash the app or negatively impact the customer experience upon deployment. Errors in mobile apps may take weeks to correct because it takes a while for the App Store and Play Store to approve changes.

By using feature flags, your dev team can isolate a “work-in-progress” code and ensure an unfinished feature won’t be seen in production. After the team is ready to enable the feature, they can simply switch on the feature flag. Since the feature flag is deployed separately from the overall code base, it can be enabled or disabled quickly without resubmitting the mobile app to the App Store or Play Store.

This tight control of timing also enables the dev team to coordinate feature roll-outs with other teams, such as marketing. With feature flags, new features can be set to go live in phased rollouts to coincide with marketing activities, such as public announcements or events.

2. Reduced risk in the deployment process

With agile feature release management, if something goes wrong, you don’t have to struggle through a risky rollback process that probably isn’t that well-tested. You can simply disable the problematic feature and make sure it doesn’t impact users. The development team, meanwhile, can take the time they need to repair it properly. While internal QA is still important, this approach enables your team to quickly test out new features and gather feedback early in the development process. Product managers and their teams can also use feature flags to turn off non-critical features that may disrupt the user experience due to heavy use or integration problems.

3. Personalized experiences for multiple user segments

With feature flags, you can develop distinct experiences for different user segments. You don’t have to clutter the interface of your app or website with a one-size-fits-all feature. Instead, you can develop features to target only specific types of users, such as displaying a re-order button only to frequent users of retail or food delivery apps. Feature flags make it simple to develop highly customized versions of features to improve the user experience.

A phased approach to releasing new features

So how does feature release management impact an agile software development workflow when introducing a new feature? We’ve mapped out a typical process to illustrate how feature flagging can be used to create a phased roll-out that enables optimization at every stage:

Step 0: Design, Develop, and Internal QA

All agile software teams incorporate a process that incorporates software design, development, and internal QA within each release cycle. This work is the foundation of any strong deployment, but in many cases, newer features are delayed or left off the product roadmap entirely because the dev team hasn’t had sufficient time to identify potential errors in code. At this stage, the team will launch a beta release that includes only the features that have been through an in-depth QA process. They’ll take the time to ensure that the feature is pressure-tested—but this has the negative result of slowing down innovation. It also means they may spend a lot of time developing a feature that your users won’t adopt the way that you’d hoped.

Feature release management takes the risk out of the innovation process, enabling you to roll out a phased release with multiple codepaths within a single deployable unit.

Step 1: Canary or Pilot Release

Consider this the “friends and family” stage. In a canary release, your team can roll out a new feature to early adopters who’ve been warned to anticipate bugs. The goal here is to collect their honest feedback and understand how they engage with the feature, so that your team can optimize it for the next cycle.

Step 2: Beta Release

Next, your team can release a new feature to a broader, though still small, set of segmented users who’ve signed up for a beta release or private preview, often in response to a newsletter or forum announcement. These users will have the expectation that they’ve been selected to test out experimental features, and may encounter bugs along the way. The goal is to begin collecting data that assesses the UX experience among a broader pool of users.

Step 3: Phased Roll-out

Once your team has had time to collect and assess early data around feature usability, and dedicated additional time to the QA process, it’s time to begin a phased roll-out. Begin with a small subset of random users (typically 5%, though it can be as little as 0.1% depending on the size of total user base), and expand the group over time. Along the way, if you experience negative user feedback or discover bugs in the feature, you can pause the roll-out at any phase, or opt to turn off the feature for all users until your dev team can analyze and run additional QA on the code for the next release cycle.

Step 4: General Availability

When your team conducts a phased roll-out, if overall metrics are trending positive and you’re not seeing errors that are impacting large groups of users, your team can roll out the new feature to 100% of users. At this point, the feature has been optimized, analyzed, and battle-tested, and should be ready for mass adoption. You can leave the feature conditional for a set amount of time in case errors do occur with a larger user base, and add it to the permanent code base once confidence is high.

Different types of feature flags

Phased roll-outs are a significant use case for feature flags, but by no means the only situation where feature release management can prove valuable to the agile development experience.

Use cases for feature flagging fall along two axes, as illustrated in Martin Fowler’s framework: dynamism, representing the delta between changes that happen at runtime that reconfigure the app and changes that happen on a per-user basis; and longevity, referring to how long the feature flag will be maintained (over a period of hours, days, weeks, even years). Our four primary use cases each fall at different axis points along that spectrum.

Phased roll-outs

As discussed in depth above, phased roll-outs include gradual staging of a new feature to validate functionality and user behavior, integrating a larger random sampling of your user base into each phase of the roll-out. In this scenario, the conditional coding may be removed once the feature has been validated with 100% of users, and the feature code will be included in the permanent code base from that point onward.

A/B testing

In A/B testing or multivariate testing, you can test hypotheses for how to improve certain metrics within your app or website. Using feature flagging, random segments of your user base are presented with different experiences, enabling your team to analyze their behavior to assess which variants are more effective. For instance, will a “recommended content” module increase site engagement and virality? In this type of experiment, dynamic variables can be used to present each type of experience until you’ve accumulated enough data points to validate the results, and the experiments can be modified or improved at any time as you continue to assess and optimize your results.

Personalization

In personalization, your users are not receiving different experiences on a random basis—they’ve been intentionally segmented based on their unique behavior or demographics data. Here, you can present tailored experiences to specific users, such as providing additional “premium” features to paying customers, or giving users specific “roles” that provide them with different levels of permissions within the app (i.e., manager v. individual contributor, for apps used within a company).

Operation toggles

All features can be coded with a simple on/on switch, enabling your team to deactivate a feature for the entire user base. This can be useful to maintain indefinitely for non-critical functions, allowing you to disable specific features that are slowing down loading times while you’re experiencing heavy demand. This gives you the opportunity to streamline the product to its core functionality as needed, and restore additional features based on conditional parameters.

Managing the feature release lifecycle

As shown in our framework, your team will likely incorporate a mix of short-term flags (phased roll-outs and A/B tests), and long-term flags (personalization and operation toggles) during the course of any product release cycle. It will be important to build a structured process for managing your feature toggles over the course of the product roll-out.

Retiring short-term flags

Your team should build a regimented process for when to deploy the feature flag over the course of a phased roll-out or an A/B testing experiment, and when to retire it.

With a phased roll-out, you will plan a staged deployment over a period of days or weeks, allowing opportunity to roll back the feature to its previous user segment, or to turn it off entirely, in the event of unforeseen errors or poor user adoption. Once the feature has been rolled out to 100% of users and has been validated among your entire user base, the feature can be integrated into the permanent code base.

In an A/B test, the goal of the feature flag is to enable you to collect data to validate or disprove a particular hypothesis regarding metrics such as conversion rate, engagement, or other user behavior. Set a target for the number of users who’ll be shown each version of the feature, and once you’ve reached that limit, you’ll have adequate data to decide which version of the feature to add to your permanent code base, and can remove the conditional coding.

Managing long-term flags

Personalized feature permissioning and ops toggles are long-term additions to your code base, and provide opportunities for your team to provide a more granular level of control over the user experience during any engagement with your product.

• These types of long-term flags need to be carefully configured, based on criteria such as:
  User characteristics, tied to unique characteristics of a set user or user segment (i.e., role, location, purchase history)
• Environment variables, tied to values that impact the behavior of computer systems or OS environments (i.e. server load)In these cases, the toggle configurations are included as query string parameters that must be passed in order for the feature to be activated in a specific condition.

The process of managing and configuring both short- and long-term conditional code can be simplified by using an optimization platform such as Apptimize, which provides a centralized dashboard with clear visibility into the status of all of your conditional features, and makes it easy to build customized experiences for segmented user groups and track the resulting data.

The importance of an agile process

By incorporating an agile feature release process into your development cycle, not only do you get releases out faster, but you can customize them in production to ensure that your users get the best possible experience and your business gets the best possible results. Those results include:

• Faster innovation. You’ll understand what works and what doesn’t before you invest time perfecting features that aren’t adding value for the users (or the business).

• More conversions. Because agile feature release management lets you continually test and validate new features, you learn what works quickly and can optimize conversions and growth.

• Improved customer loyalty. Use agile feature release management to create a custom experience for each user segment, giving all users a great experience and increasing their loyalty and preference for your product rather than your competitors’ products.

• Reduced risk. With agile feature release management, non-vital functionality can always be deactivated during high-demand times to ensure a smooth user experience. New functionality can also be added to production earlier in the QA cycle, with the option to roll back the function in the event that it introduces errors.

Perhaps most importantly, agile feature release management gives you a direct route to an improved development culture. Bringing agility to the feature release process lets developers focus on writing quality code, while letting product managers focus on the customer experience. The tech team and product team can collaboratively work towards the future state of the app. You get faster development, reduced costs, and an innovative culture that keeps you moving forward, building out the features you need to attract and retain customers.