What is feature flagging? The A-Z complete guide for product teams.

Launching a new feature is a high-stakes moment. A ton of potential issues need to be monitored at once, for example: 

In traditional deployments, product teams need to manage all of these different considerations while also coordinating with the development team responsible for coding the feature. It’s a risky situation, and even small issues can have a ripple effect on product performance. 

Feature flags solve that. By separating feature deployment from feature release, they give product teams more control to safely release features while measuring business impact.   

Let’s talk about what feature flagging is, when you should use it, and how feature flags and analytics can help you control rollouts, run experiments, and more. 

Feature flags are like a light switch for product features. They use conditional logic (“if-then”) to allow you to turn features on or off without deploying new code. 

Unlike traditional deployments, using feature flags separates code deployment from feature release. This makes it easier to roll out features gradually by releasing them to a small subset of users at a time to test functionality, without impacting the broader user experience. If an issue is detected, feature flagging also makes it easier to roll that feature back: You simply toggle the “off” switch. 

Feature flags are the building blocks of product experimentation and feature management. You can use them to conduct A/B tests and experiments, or personalize experiences by turning on features for different user cohorts. For example, you could use a feature flag to show new users your onboarding welcome message and skip it for existing users, or give your internal QA team access to a feature before you launch it. You can also use feature flags to release premium features only to your paid users, for example. 

Feature flags are especially useful for product teams because they provide strategic control over feature deployment. This means you can iterate without risk, test ideas quickly on a smaller scale, and validate ideas before deploying them to your entire user base. 

There are many use cases that product teams can use feature flags for. Here are a few examples. 

Flags for releases: You can use feature flags to gradually roll out features by releasing them to a small subset of users at a time (also called a “canary release”). This limits the risk of feature releases, since you can spot bugs and see how users are impacted by new features before they affect your broader user base. 

Flags for permissioning: Feature flags give you more control over user access. You can segment users and divide them into cohorts based on their behaviors and attributes to give them different levels of access (for example, directing new users to onboarding, or giving paid users access to features that free trial users don’t have). 

Flags for experimentation: Feature flags help you run experiments, including A/B testing different variants to different users, without deploying code or making any permanent changes. Once your experiment is complete, you can use the results to guide your decision-making and toggle your feature flags accordingly. 

Feature flagging is especially valuable for organizations using a product-led growth (PLG) strategy. 

When paired with powerful analytics, feature flags enable data-driven decisions. You can use feature flags to measure the real business impact of releases and see how different features affect engagement, retention, conversion, and activation across different user segments, and by how much. When you use feature flags to test features with specific user segments, you create more personalized experiences and improve user experience. 

Feature flags combined with self-serve analytics also allow non-technical users to manage releases, run experiments, and analyze results, which frees up your devs and analysts and supports cross-functional collaboration for marketing, product, data, and growth teams. 

Self-serve analytics is a powerful way to gain more insights from your data, but it’s important to have a system in place to keep all team members aligned. The OADA loop (Observe, Analyze, Decide, Act) gives teams a structured process to use feature flagging and power experimentation. 

Some PMs have the misconception that feature flagging is painful to implement, but that doesn’t have to be the case. As David Martin, Senior Solution Engineer at Split, shared with us in an interview for the Mixpanel blog, “It can be as modest an undertaking as you’d like. That’s because you can start by putting just one feature under flag,” he says. 

In addition to taking it one step at a time, he recommends adding flags in areas that you’re already updating. 

“My advice is to start with whatever you’re already making code changes to at the time. Put a flag in, test it, and get a feel for the process with that one flag. If it’s a good experience, you’ll work toward a policy of putting every new feature under flag.”

As David recommends, it’s a good idea to start with a single feature flag. Choose an area where you’re already making updates, and choose a feature to put under the flag.  

To use feature flags, developers write code as they normally would and wrap it in a conditional if-then statement, which remains turned off until the feature flag is put to use. 

Creating feature flags and putting them in the “off” position enables trunk-based development, where developers merge features wrapped in flags into the main trunk. This allows for continuous integration and continuous deployment (CI/CD) without releasing features until they’re ready. 

Feature flags give you more control over experiments and releases, and there are lots of valuable insights to be gained. Track key metrics tied to feature flags that will help you determine if your feature rollout or experiment is successful, including:

It’s also a good idea to set up alerts so you get notified when metrics change unexpectedly.

Feature flags are part of your broader experiment strategy. Is the purpose of this flag experimentation (like A/B testing) or is it part of a controlled feature rollout that will eventually be released to all of your users? 

Feature flags help you manage releases and enable controlled rollouts, so that only a small subsection of users gets access to the feature at the same time. 

There are several gradual rollout strategies you can use. For example, a percentage-based rollout involves releasing the feature to a small group of users, increasing the overall percentage as the release progresses. Another option is segment-based rollout, where you release a feature to specific user segments to monitor how different audiences receive it. 

It’s important to keep communication open across teams during feature rollouts so that all teams can monitor the impact on their respective areas and spot potential correlations. 

Once you’ve identified your first flag, integrated it with your analytics platform, and planned your strategy, you’re ready to put your first feature under flag. Use your analytics platform to monitor progress: For a controlled release, look out for signs of technical issues or UX concerns. For A/B testing or features released to different user segments, compare the performance of features under flag with their variants. Use this information to inform your strategy and decide next steps. 

Using feature flags helps teams gain more insights into their users and get more data from their experiments. It’s important to set yourself up for success: 

Use descriptive naming: In your flagging or analytics platform, make the flag’s purpose obvious to all team members.

Enable self-serve access: One of the advantages of feature flags is that they decouple feature deployment from release. Let product managers who will ultimately be accountable for results control releases.

Monitor business metrics: Use feature flags to track user behavior and conversion impact.

Document experiments and decisions: Track why flags were created and what their purpose is, why they are turned on and off, and outcomes of different experiments and rollouts. 

Plan for flag cleanup: As time passes, unmanaged feature flags can accumulate in your code base without clear ownership or documentation. Regularly schedule time to review and remove obsolete flags to avoid technical debt. 

Combining feature flags with analytics helps you track whether feature rollouts and experiments are successful. Analytics solutions will help you spot issues and opportunities quickly and help you monitor the performance of your feature flags. 

You can also use cohort analysis to compare cohorts with and without features over time, to gain a deeper understanding of the impact of your feature flags. 

Analytics platforms like Mixpanel can help you connect feature usage to important revenue and growth KPIs. Without analytics in place, seeing those connections is much trickier. 

Feature flagging has several advantages over traditional deployment methods, which require a full code release for any change. Here’s a breakdown of the main differences:

There are a few common challenges to keep in mind when you get started with feature flags. 

Adding segmentation and user targeting to feature flags gives you more strategic control. You can segment users based on their behavior, or based on attributes like geography, demographics, or subscription tier. But making your targeting logic too complex makes it harder to gain useful insights. 

Keep segmentation simple and maintainable, especially to start. As you get more comfortable with feature flagging, you can progressively make your targeting more complex as needed. 

Feature flags help you connect feature usage to meaningful KPIs. Turning a feature flag on or off will give you insights into the impact that the feature has on business metrics like revenue or growth.

But to get those insights, you need to have a robust analytics solution in place that can help you understand what’s happening and why it’s happening. Without it, you won’t get the complete picture. 

Running experiments requires cross-team coordination. Otherwise, you can easily end up with one team pulling on one lever and another team pushing it back up, not realizing that they’re working at cross purposes. A well-executed feature flag strategy with clearly established workflows and responsibilities can actually improve collaboration. It takes the pressure off of engineering teams by decoupling feature deployment and release, and it empowers PM teams to own the feature launch strategy. 

Outdated feature flags that are no longer used can quickly build up and create technical debt. It’s important to set up cleanup strategies and regularly schedule time to review feature flags and remove those that are no longer needed. 

Mixpanel’s new feature flagging gives you a unified solution for both analytics and feature management. There’s no need to use different solutions: Everything is connected in a single platform.

Product managers can analyze feature impact independently and use Mixpanel’s self-serve interface to access the insights they need to make decisions. You can see the impact of feature releases in real time as features roll out, and use those insights to make decisions quickly. Feature flagging in Mixpanel is the missing link that ties product decisions to business outcomes. 

Getting started isn’t complicated, but it does require a little bit of planning and having the right tools in place. 

To summarize, here’s a step-by-step guide to feature flagging:

Mixpanel’s feature flagging and analytics capabilities combined simplify the process.

Get started with feature flagging. Contact us for an experimentation demo today.