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 that they allow engineering teams to distinguish between code deployment and a feature rollout.
Feature flags (also called feature toggles or feature switches) can seem like a pretty technical topic for a product manager.
Why would you want to know about this?
Isn’t this better left to development teams?
Well, feature flags can be an extremely useful tool to ensure an efficient and low-risk release cycle and enable easy customization and testing of your product.
With feature flags, the behavior of your product can be changed at runtime without code changes or a rollout. It can be a very good tool in your product manager’s toolbox.
So read on!
Top 8 Feature Flag Practices
In this blog, we will discuss the best Feature Flag practices followed in Product Management-
1. Use A Consistent System For Feature Flag Management
Whatever you use, the system should be easy to understand, including good naming conventions so that every software engineer understands what a flag does.
Spend a little bit of time when first introducing feature flags to discuss what is the best solution for you, as you want to stick with this system for the long term.
2. Set Naming Conventions For Different Types Of Feature Flags
You can implement feature flags to achieve many different things:
- Release flags: It facilitates the rollout of production code before a feature is ready for a public feature release.
- Experiment flags: It is used to create an A/B test, the flag controls which group of users gets which experience.
- Permission flags: They allow you to control access to certain features for different customers
- Kill flags: They allow you to degrade your product gracefully in case of any performance or overload issues.
Clear naming conventions for each type of flag mean that everybody knows what each flag does, even years later.
3. Make It Easy To Switch A Flag On/Off
The beauty of feature flags is that they can be turned on and off easily. Ideally, you should have a way to set a flag without any code change or intervention by a developer. As flags can be so widely used, multiple teams may want to manipulate them, For example:
- QA to troubleshoot or replicate a particular customer situation.
- Customer service to enable or disable a feature for a customer.
- DevOps team to shut down (parts of) your product gracefully in case of overload or other problems.
If you have an online screen to set the flags, all this can be done without work from your engineering team.
4. Make Feature Flag Settings Visible
It should be easily visible what combination of feature flag settings are set for a specific user. This should be stored with a user’s profile both in your user database as well as in your analytics system.
This can be very useful for customer service to troubleshoot any reported problems. It can also be very valuable to analyze the different behaviors of users with different settings. It is essential when analyzing the results of an A/B test.
5. Clean Up Obsolete Flags
Release flags and experiment flags are, by definition, only needed temporarily. After the full release of a new feature controlled by a flag or the completion of an experiment, plan to remove the flag as the last step.
In this way, you don’t accumulate technical debt in the code, and your feature flag management remains uncluttered and easy to understand.
6. Avoid Dependencies Between Flags
Each flag should have its own specific purpose that is independent of any other flag. For permissions flags, this means that the code needs to be so modular that different features can be turned on in any combination.
If multiple flags are needed to enable a particular use case or potentially conflict with other flags, the setting of the flags can become confusing, and sooner or later problems will happen with the users’ experiences.
7. Use Feature Switch To Avoid Code Branches
When discussing the implementation of a bigger feature with the product team, you will discuss how to break down the software development into smaller pieces. At this point, you should discuss the use of a feature flag as well.
When you implement a flag and keep it turned off, you avoid the creation of long-lived feature branches. This improves the integrity of your codebase, as you have no big, complicated merge processes, and any conflicts are quickly identified.
It also decouples the release of code from showing the changes to end users, as explained in point 8.
8. Use Feature Flags for Small Test Releases
Big new feature releases tend to be stressful and risky, but you can address this by exposing your feature to a small audience first, monitoring the effects, and rolling back if necessary.
If you have used a feature flag to constantly merge and release your code before exposing it to the world as recommended under point 7, you already have the tool to achieve this.
Get the initial framework right and you will find that using feature flags can greatly increase flexibility and efficiency in your product. You should also consider using feature flags for bigger initiatives to minimize risk and ensure a smooth rollout. The only limit to the use of feature flags is your imagination!
Tell us about any more ways you have used feature flags in your product in the comments.
If you would like more tips and tricks to improve your Product Management skills, please check out our blog page.
