What Are Feature Flags? Everything You Need to Know
What are feature flags?
Feature flags (also called feature toggles, feature switches, and feature flippers) are if/else logic code snippets that are used to enable or disable features.
They are the foundation of feature management tools, allowing users to test and roll out features with precise delivery rules. This includes:
- Progressive delivery: a new feature is released to a smaller percentage of users to understand the impact of the update before rolling the feature out to 100% of the user base.
- Targeted delivery: features are rolled out only to users who share a common trait (i.e., are in the same segment) such as early access users, internal testers or premium users.
- Feature experimentation: launching different versions of a feature to see which one performs best.
Feature flags are an essential tool in the DevOps toolkit and are used regularly in agile and continuous integration/continuous delivery (CI/CD) organizations. Product managers have also adopted feature flags to have more control over who sees changes in production and when.
How do feature flags work?
Feature flags operate as conditional statements that determine which code will be executed based on a set of rules.
Feature flags allow users to put product changes behind a flag and let users access them in a controlled way. This makes it possible to deploy even incomplete features to production.
Essentially, they separate deployment from release.
Who uses feature flags?
Developers have been the primary user of feature flags for many years. Because flags are implicated in code, they have typically required a developer or engineer to configure them.
Traditionally, developers used Boolean flags, a simple toggle that turned a feature on or off. It stores only true or false values and is basic in its complexity.
Now, thanks to advanced feature management solutions, product managers have gained more control over releases with the ability to update feature flags and even run product experiments. Developers can deploy code whenever they want, but product managers can decide who sees the changes in production and when.
This enables product teams to do more with feature flags.
Below is a summary of how feature flags may be used across R&D and product teams:
- Developers: configure flags for use across the product team.
- Product managers: roll out features incrementally, run feature experiments, and provide feature access to different user populations for feedback and testing.
- Quality Assurance (QA): use feature flags to test features in production, validate them internally first, and then release to a clearly defined production audience. Rolling out using feature flags also enables features to be rolled back if they're problematic.
Because so many different teams can be using feature flags, they’re best managed with the help of a comprehensive and unified management tool.
What are the benefits of using feature flags?
There are many reasons why developer and product teams use feature flags, from mitigating risk to increasing overall control. Here are some of the top benefits of using feature flags.
Releasing features to an entire user base presents many risks. There is the possibility of introducing bugs into production, impacting product performance negatively, and creating a poor user experience for users.
Without any sort of toggle or switch, any error introduced will require a complete rollback. This can be a costly and time-consuming effort.
Feature flags enable teams to release a feature gradually, beginning with a small and trusted user base, and expanding from there. Teams may even choose to test different versions of a feature, to validate product hypotheses and minimize the risk of releasing a feature that users don’t want.
With feature flags, product teams can maximize their chances of having a successful release, while reducing their chances of causing disturbances to their users and the business.
Without feature flags, product teams have little to no control over who sees a feature and when they see it.
Feature flags allow product managers to put product changes behind a flag and let users access them in a controlled way. This makes it possible to push even incomplete features to production.
Product managers can increase control over the release of features by using feature flags to:
- Display or hide features with ease.
- Roll out features incrementally.
- Roll out a feature variation to a subset of users.
- Run experiments on features.
Improves efficiency and agility
Having an agile product team is key to exceptional innovation. With feature flags, teams can separate feature releases from code deployment, thus boosting developer productivity and creating a more agile environment.
When developers are releasing features faster, users are gaining access to more value faster.
This can improve customer retention and customer lifetime value (CLV), while decreasing acquisition cost over time.
Introduces a timely and cost-effective approach to software production
Building the wrong feature or releasing a broken feature into production is an expensive mistake.
Feature flags are a cost-effective approach to releasing code. They can prevent businesses from having to make significant feature rollbacks, or launching a feature that users don’t find useful, and thus won’t adopt.
When features can be validated with a small number of users first, it’s easier to detect an issue and correct it quickly.
Feature flags: use cases
There are many different applications of feature flags, from killswitches to feature experimentation. Here are some of the most common use cases for feature flags.
1. Killswitches (toggling on/off)
When features or capabilities are associated with feature flags, they can be easily changed and toggled on/off, individually, in real time. These changes can happen without affecting the rest of the product.
Turning off a feature can also work as a killswitch, should the activation of a feature cause issues. A killswitch is an on/off flag that users can flip whenever a problem with a feature is detected. It is one of the most common applications of feature flags.
With a killswitch, flags can be turned off, and changes to the app will take place immediately, without needing to change targeting rules or perform redeployments.
Using this capability, product managers are empowered to release individual features to production, and do not need to rely on rollbacks due to failed deployments of individual features.
Migrating data or changing backend infrastructure often takes multiple, tedious steps.
Developers can use feature flags to preload all of their changes ahead of time and leave them dormant behind feature flags. When they’re ready to make the backend switch, they can release flags and turn on the new code in the necessary sequence.
If there’s a problem, they can switch the flag back and revert to known-working configurations.
Feature flags take the complexity out of multistep migrations by allowing DevOps teams to put everything in place for a straightforward switch instead of worrying about multiple overlapping, interconnecting steps.
3. Refactoring code
Dev teams applying CI/CD methodologies can sometimes struggle with refactoring and integrating complex codebases. Feature flags help them isolate stable code from those they’re currently working on.
Instead of doing periodic major merges, DevOps teams can turn on bits and pieces of code using feature flags as soon as they’re found to be stable.
4. Controlled, granular releases
Feature flags are powerful when it comes to product releases. Flags can be configured to release features quietly, beginning with a small subset of users and expanding from there.
Product managers can configure rules for gradually activating features over a period of time to all, or a subset, of users. This is known as progressive delivery.
Progressive delivery allows product managers to:
- Be more agile in pushing traffic to a feature automatically.
- Release a feature in stages.
- Get internal and/or external feedback and incorporate that feedback faster.
- Make decisions faster as to whether to keep iterating on a feature or to scrap it.
By controlling who can access a feature and when, product managers can benefit from a reduced potential negative impact of a release.
Product managers can target a subset of users, or even a smaller percentage of that subset, for whom they want to activate a feature flag. This is called targeted delivery.
It gives product managers the ability to:
- Control which segment of a user base sees a feature.
- Get internal and/or external feedback and incorporate that feedback before general availability.
- Roll out a feature gradually, in multiple stages.
- Ensure a smooth, controlled rollout to general availability.
Canary releases refer to releasing a feature to a small set of users to test the implications of that feature like a canary in a coal mine.
Traditionally, in canary deployment, an updated copy of an app is created and a small percentage of traffic is directed to it. Once the canary test's performance is satisfactory, the updated code is deployed to the production environment where users can access it.
This is all made possible by feature flags.
Canary releases are a subset of targeted delivery. Their goal is specifically to test the impact of updates, as opposed to targeted delivery where the goal is to push different variations of a feature to different segments of a user base.
5. Feature experimentation
Feature experimentation is the exciting next step in the evolution of feature management. Feature flags are what makes feature experimentation possible.
With feature flags, a version of a new feature can be tested and shown to users. Performance is then measured based on goals that users define.
With in-app reports, designed specifically for analyzing the performance of feature experiments, product managers can:
- Test adoption rates to understand which variation of a feature is received better by users.
- See how changes to their product impact performance, usage, and other KPIs defined as custom goals.
Instead of guessing which features an audience would benefit from the most, features can be tested, iterated upon, and changes can be made quickly.
How to implement feature flags
There are a couple of different options when it comes to implementing feature flags.
Using developer resources
Developers can code feature flags directly into the code base. This is how feature flags have been traditionally handled, and for a long time, was the only way to implement a feature flag.
Relying solely on developer time and resources however presents many challenges, and is rarely considered a sustainable path towards growth.
Using a feature management system
Feature flag management systems take the burden off developers for designing, monitoring, and managing feature-flagged code.
With a feature management solution, developers only need to code the feature and add the variables to the code. Product managers can then create as many variants as they want for their experiments, without any additional code required from their developers.
A wide range of solutions exists, from point solution feature management platforms to full stack experimentation solutions that allow users to manage server-side experiments, feature flags, and feature experiments.
Advanced feature flag management tools offer:
- Comprehensive SDK libraries.
- Support for feature variables and variations.
- Support for mobile app testing.
- Deep reporting.
- Real-time monitoring and alert systems.
These capabilities allow product managers and product owners to easily implement flags for experiments or other use cases, without developer resources.
Feature flag best practices
Looking to get started with feature flagging? Here are some best practices to keep in mind.
Implement a standard naming convention
With multiple team members using feature flags for various use cases, management can easily become overwhelming.
The best practice when dealing with feature flags is to implement a
standard naming convention from the get-go. Each flag set could have its own naming conventions, syntax, and organizational structure.
Following a standard naming convention can:
- Minimizes the risk of implementing the incorrect flag.
- Help in feature flag removal and review processes.
- Make their function easier to understand at a glance.
- Streamline product team operations.
- Real-time monitoring and alert systems.
Remove old feature flags
One best practice to implement as soon as possible is removing stale feature flags from code. This minimizes the possibility of accumulating technical debt.
Technical debt is the consequence of cutting corners and making less than optimal decisions to prioritize short-term goals. Too much technical debt can produce poor results and hurt overall productivity over time.
For that reason, it’s best to review all existing flags and remove as many as possible whenever a new flag is introduced.
Track feature flags externally
Tracking a large volume of feature flags manually, such as through comments in code, can be unreliable.
Using a feature management tool instead can automate time-consuming tasks and provide greater insight into where flags are in code and how they operate.
Feature flags and feature experimentation
Feature experimentation is the practice of using feature flags to launch different versions of the same feature to measure how each variation performs against business goals.
Feature experimentation enables teams to take a truly data-driven approach to developing a product and can make way for true product innovation.
Feature experimentation can be used to:
- Validate hypotheses with the scientific method: check that the product aligns with business objectives and is performing as intended.
- Validate product direction and quality: check that the product meets user expectations and is up to standards.
- Assess the impact of a feature on performance: understand how the product is impacting overall performance of the business.
- Identify and focus on the most impactful variation: determine which version of the ones tested are most impactful and will drive the most results for the business.
Feature experimentation makes getting customer feedback easier by providing quantitative data on adoption. It is the foundation of any high-performing product team looking to achieve exponential product-led growth.
For more information, check out our complete guide to feature experimentation.
Using Kameleoon to manage feature flags
Managing and implementing feature flags has never been easier, thanks to Kameleoon’s Full Stack Experimentation solution.
Kameleoon is the only optimization solution with web, full stack, and feature experimentation capabilities in a single unified platform. This means marketing and product teams can work in one platform, in their preferred environment. Working in a unified platform that creates transparency for all team members is especially important today, when various stages of the buyer experience are co-owned by these teams.
If marketing manages customer acquisition and product drives retention and monetization, it’s crucial to have a single view of the end-to-end customer experience. (Not to mention a single source of truth for data.)
Needless to say, a unified platform promotes closer collaboration between the product and engineering teams as well. With Kameleoon’s feature management and feature flag capabilities, product managers no longer have to ask developers to manually code every feature version. Feature flags can be easily managed and configured from an intuitive UI.
Here’s how product managers can simplify feature flag management with Kameleoon:
- Configure a flag, decide how it should be released using our Rollout Planner, and use advanced scheduling options to determine a release plan.
- Set alerts to roll back features based on goal performance.
- View, sort, and filter feature flags with a single dashboard.
Feature flags are more than just a tool for developers. They’re an integral part of any high-performing product team.
Looking for a feature flagging solution for your product team? Request a demo to see the Kameleoon platform in action.