8 Feature Flag Best Practices You Should Know
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 toolbox. So read on!
In this article I will discuss some best practices for feature management, followed by a case study from my own work for Guardian Soulmates, The Guardian’s dating platform.
1. Use A Consistent System For Feature Flag Management
It doesn’t matter if you use a feature flag management tool (like for example LaunchDarkly), a config file, or a database table. 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: facilitate rollout of production code before a feature is ready for public feature release.
- Experiment flags: to create an A/B test, the flag controls which group of users gets which experience.
- Permission flags: allow you control access to certain features for different customers
- Kill flags: 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 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 full release of a new feature controlled by a flag or the completion of an experiment, plan in some time 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 specific purpose which is independent of any other flag. For permission 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 users’ experiences.
7. Use Feature Switch To Avoid Code Branches
When discussing the implementation of a bigger feature in 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. Instead, the code for the new feature can be continuously merged and released without being exposed to users in a CI/CD (continuous integration / continuous delivery) or in an agile sprint code deployment. This improves the integrity of your codebase as you have no big and 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, monitor the effects, and roll 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.
When your new functionality is ready, turn it on in the production environment to expose it to internal testers only, then to a small percentage of customers (called a canary release), then to the whole customer base.
In each step, you monitor your key metrics. If something goes wrong at any point, you can easily flick the flag back off and investigate the issue without the stress of a complicated rollback.
The following case study shows an example of de-risking a major redesign of a product.
Case Study - Feature Flags In The Redesign of Guardian Soulmates
When I worked as a product manager for Guardian Soulmates (the Guardian’s subscription dating platform at the time), we faced two challenges: a sub-standard mobile site and a tired branding. We decided to tackle the transition to a rebranded responsive site in two steps.
Let’s face it: customers generally hate change, especially paying customers. A rebrand is a major undertaking that can bring a lot of disruption.
We discussed how to best achieve our goals to replace the mobile site and implement a new branding without too much disruption for our subscribers. The chosen solution was a two step process involving two feature flags:
- Flag for responsive layout: this flag was used to allow us to show any individual page either in responsive or in existing desktop layout (the separate mobile site remained untouched until we were ready to launch the new mobile site fully).
- Flag for new branding: This flag allowed us to show the whole site in old or new branding.
Flag For Responsive Site
After creating a responsive framework, we migrated over pages one by one to the new responsive layout. For each migrated page the responsive feature flag was turned on for a small group of users first with an option to give feedback. Then after a few days, the responsive page would go live for all users. This was repeated until the whole site was responsive.
Then the mobile site was switched over to the new responsive site. The disruption for desktop users was minimal as we had transitioned the pages in an incremental fashion.
The disruption to mobile users was small as we didn’t have very many mobile users at the time (as the old mobile site was not very good!).
Flag For Rebranding The Responsive Site
After the rollout of the responsive site, the feature flag for the new branding allowed us to toggle the whole site between old and new branding. Developers implemented a button on the site to switch the branding on a per-user basis, which allowed designers, QA, and also me as a product manager to see the progress. Redesigned pages were released continuously, but in the live environment this flag remained off so that no user saw any pages in the new branding.
When all pages were ready, we put a button on the site for users to opt into a public preview of the new branding. This button flicked the switch to the new branding for a user. The users were able to give us feedback and after a week we enabled the branding for everybody.
The whole process was completely painless both for the development team and for our customers. It was an excellent example of using feature flags to de-risk a major site redesign.
If you are interested in understanding in greater detail what we did, you can find an article about the Soulmates redesign project on the Guardian’s Engineering Blog.
Conclusion
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 clever ways how 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 subscribe to our newsletter.
Get the help of another Product Manager on your team with this helpful guide: How To Create An Effective Agile Product Manager Job Description (+Example)
Also Worth Checking Out: