What is a Feature Flag?
A feature flag refers to a team’s ability to turn a feature or functionality “on” or “off” at their discretion. They are used for many reasons, the main one being they allow engineering teams to distinguish between code deployment and a feature rollout. They also enable teams to toggle “on” or “off” premium features based on an account’s plan level.
Who Uses Feature Flags?
Feature flags are used by various parts of the organization for a number of different reasons:
- Product development/engineering add the flag capability to the codebase. Engineering’s primary usage revolves around keeping things turned “off” until they’re ready for prime time. Even though some or all of the code may be shipping to stage and production environments prior to that go live date.
- QA/testing use feature flags as part of their test plans. Toggling things on and off simulate real-world conditions and configurations.
- Operations use feature flags to test the impact of particular features and capabilities on operational infrastructure and system performance.
- UI/UX staff use feature flags to experiment with different user interaction models and designs.
- Account management/sales leverage feature flags to provide different sets of functionality to different customers/users and upgrade users for additional revenue.
- Product marketing uses feature flags to test messaging and highlight product capabilities. Feature flags also make it easier to time a feature release with a specific event or announcement.
- Product management uses feature flags for all the reasons above, and for conducting other fact-finding experiments. These experiments gauge user response to new capabilities and refine the product roadmap.
Why Use Feature Flags?
Feature flags are a simple way to toggle specific functionality for some or all of the user population. This toggling often occurs from an administrative UI that doesn’t require active involvement from product development. As a result, this gives other members of the product team the option to experiment, phase in a rollout, or change a user’s level of access independently.
Feature flags enable businesses to offer tiered levels of functionality, charge for upgrades and add-ons, gradually expand access to certain features, conduct A/B tests, and have more flexibility for the user experience. They could also be used for localization purposes, compliance requirements, and account configuration options.
Adding in feature flags also allow developers to ship code without turning a new capability “on”. This simplifies code management and is particularly relevant in Agile and Continuous Development environments. Those environments often have lots of interim code releases that may not go through an end-to-end QA cycle. 
Another critical use case for feature flags is the ability to roll changes back. This might be because it doesn’t work properly or is causing performance issues. However, it could just as easily be used to remove a feature that didn’t catch on with users or achieve its expected goals and outcomes.
Regardless of the underlying motivation, feature flags are all about flexibility. Whether it’s determining when something becomes available to the public or trialing new pricing, packaging, and business models. By making it easy to restrict/grant access, businesses can more nimbly react to situations with limited involvement from technical teams.
What Are the Four Categories?
The ability to toggle or throttle any aspect of the product is almost always a good thing. It provides customer success teams with additional tools, developers with more flexibility, and product managers with more learning opportunities.
Since feature flags don’t require a software release or code changes to switch, it also decreases the need for the business side of the house to bother engineers to make these changes on their behalf. This enables more dynamic control and faster response time to problems or opportunities.
There are lots of options for feature flags, but they generally fall into one of these four categories:
1. Experimenting
Many product teams prefer introducing new functionality to a subset of the user population. A/B testing makes the given feature or change available to only a subset of users, while the rest serve as a control. The team can then definitively measure the impact of a potential change in a limited test without unleashing it to everyone. It also potentially limits the chances of having to pull back due to poor performance or a lackluster reception.
Similarly, an A/B test might offer one version of a feature or change to one set of users and an alternative option to others. This could be as simple as testing out the effectiveness of a button’s color or some text—but it may also encompass more significant forks in the road for the product.
The goal of these experiments is often to judge user response and its impact on KPIs. A “beta tag” may very well accompany the new capabilities during one of these experiments.
2. Operational readiness
Major changes to a product not only have to pass quality assurance testing. In many cases it’s essential to test their impact on the product’s underlying infrastructure and environment.
By only allowing a limited set of users access to a new capability, the team can monitor the product’s overall performance and the individual subsystems, including bandwidth consumption, responsiveness, and data storage.
While these metrics are ideally tested in a stage environment, there’s no replacement for the actual production environment. Unleashing a new feature that might dramatically ramp up data transfers and requests, server loads, or storage capacity on the entire user base could lead to a massive outage and hit to the product’s reputation.
By only granting a smaller group of users access this new functionality, the business gets a look at how things behave in the real world while still limiting the overall impact if things go awry.
3. Release readiness and flexibility
This type of feature flag allows code for a still-in-progress, new, or updated feature to ship and be released into production environments without making it available to users. This primarily lets developers work in a shared branch or trunk of the code tree without exposing the new feature to anyone before it’s complete.
This tactic is especially useful in a continuous delivery environment where code is being regularly pushed into production. Holding up a release until one feature is finished can delay delivering other valuable benefits to customers. A flag allows some ongoing development without requiring lots of branches and code merges, which can complicate the management and testing of the product.
Read how roadmaps fit into continuous delivery →
4. Tiered user accounts
This flag is used to enable, disable, or limit access to specific features and functionality depending on the user. This tends to be used in two different-but-related ways.
The first situation is when the product has different productized packages or an a la carte payment scheme. For example, a product may have Free, Basic, and Pro versions of the product; each version with their own set of allowed functionality. Alternatively, users may be able to pay extra to access a specific feature or increase the number of seats, storage capacity, etc. Flags are used to denote which tier has access to a particular feature or capability.
The second case is where permissions are set on a case-by-case basis. For B2B or enterprise software this may be a configuration made based on that customer’s specific requirements or preferences. Alternatively, in a consumer model these are set for the individual user based on their choices or subscription plan.
Sometimes these flags can only be toggled on and off for an account by customer service or account managers. In other cases it’s a self-service model. Either way, it may result in different users having significantly different user experiences. This would manifest in terms of what capabilities are available or how things are presented in the user interface.
How Are Feature Flags Deployed?
When new features are being developed, engineers include “gates” that allow/block access to the new functionality. Those gates are then controlled by switches that typically reside outside of the codebase. The business rules for whether the gate should be open or closed for one, some, or all users is then controlled through a dashboard, a settings interface, or by making changes in a database.
Building these gating feature flags into the product isn’t difficult in most cases when the requirement for a feature flag was clearly stated upfront. Attempting to retroactively apply one can be much more difficult, if not impossible, without significant code alterations.
It’s a good best practice to make feature flags part of the organization’s “standard operating procedures” or a checklist item on any requirement, theme, user story, etc. That way things can be turned on, turned off, or access otherwise limited.
Since no one can predict the future, feature flags are a good safety net regardless of the confidence one has in a new feature. The landscape can change quickly, business needs can shift, and new customers and target markets can dash previous assumptions, placing flexibility and responsiveness at a premium.