What Is Feature Flagging and Why Every PM Needs to Know It
Feature flagging is one of those engineering concepts that product managers often half-understand. They know it exists, they know their team uses it, but they’ve never fully internalized what it enables or how to use it strategically. That’s a gap worth closing, because understanding feature flagging properly changes how you think about shipping, experimentation, and risk management fundamentally.
This guide explains what feature flagging is, how it works in practice, and, most importantly, why product managers should care about it deeply.
What Is Feature Flagging?
Feature flagging (also called feature toggling or feature switching) is a software development technique that allows teams to enable or disable specific features in a live application without deploying new code. Martin Fowler’s widely cited definition frames it simply: a feature flag is a conditional switch in the code. If the flag is ON, the user sees the feature; if it’s OFF, they don’t.
From the outside, it sounds simple. In practice, it’s one of the most powerful tools a product team has, because it decouples deployment from release. Engineers can ship code to production continuously, but product controls who sees what and when. That separation changes everything about how a team manages risk, runs experiments, and responds to problems.
How Feature Flags Work in Practice
When an engineer implements a feature flag, they wrap the new feature code in a conditional block that checks whether the flag is enabled. The flag state is managed through a configuration system, often a dedicated feature flag management tool like LaunchDarkly, Flagsmith, or Unleash.
At the most basic level, a feature flag is a binary toggle: the feature is on or off for all users. But modern feature flagging systems are much more sophisticated. You can enable a feature for:
- A specific percentage of users (5% rollout to test performance and stability)
- A specific user segment (beta users, enterprise accounts, users in a specific country)
- A specific internal group (your own team, for internal testing before any external exposure)
- Users who meet specific criteria (account age, plan type, behavior trigger)
The flag state can be changed in real time from a dashboard, no code deployment required. Turn a feature on for 10% of users today. Check the data. If everything looks good, expand to 50%. If something breaks, turn it off immediately for everyone without a rollback deployment.
Take a realistic case: a 35-person fintech startup rolls out a redesigned transfer confirmation screen to 5% of users on a Friday afternoon. By Monday morning, the error-rate dashboard shows a subtle increase in failed transfers on older Android devices, something that hadn’t surfaced in QA. Because the feature is behind a flag, someone can turn it off in about ninety seconds from the dashboard. No engineer needed, no rollback deployment, no weekend incident call. Without the flag, that fix would have meant an emergency deploy on a Saturday.
Why Product Managers Need to Understand Feature Flagging
Here’s the honest reason: feature flagging gives product managers control that they wouldn’t otherwise have. Without feature flags, the relationship between shipping code and releasing features is binary: engineers deploy, and the feature is live for everyone. With feature flags, you get granular control over the release process, which enables a completely different way of managing product risk.
Controlled rollouts. Instead of releasing to all users at once and hoping nothing breaks, you release to 1%, then 5%, then 25%, monitoring metrics at each stage before expanding. If you’re measuring product success through conversion rates, engagement metrics, or error rates, a gradual rollout lets you detect problems before they affect most of your users.
Kill switches. If a feature causes unexpected problems in production, such as performance degradation, a bug that affects a critical workflow, or negative user behavior, you can turn it off instantly without a new deployment. This dramatically reduces the blast radius of production issues.
A/B testing. Feature flags are the infrastructure layer under most A/B tests. You show version A to 50% of users and version B to the other 50%, you measure the difference in outcomes, and you roll out the winner. Without feature flags, running A/B tests at scale requires significant engineering complexity. With them, it’s a configuration change.
Beta programs. Feature flags make it trivial to run a beta program. You enable a new feature only for users who’ve signed up to be early testers. They give feedback, you iterate, and then you roll out more broadly when it’s ready. No separate beta environment, no complex access management.
Types of Feature Flags and When to Use Each
Not all feature flags are the same. Understanding the types helps you and your engineering team use them appropriately.
Release flags — The most common type. Used to separate deployment from release. A feature is built and deployed to production behind a flag, then the flag is turned on when the team is ready to release. These flags are meant to be temporary; once a feature is fully rolled out, the flag should be removed from the code.
Experiment flags — Used to run A/B or multivariate tests. The flag randomly assigns users to different variants and tracks the outcome differences. Experiment flags are tied to a specific test and are removed once the test concludes and the winner is deployed.
Ops flags — Used to control operational behavior, such as enabling a maintenance mode, switching to a backup data source, or degrading gracefully under high load. These flags are often permanent and are used by engineers and operations teams to manage system behavior.
Permission flags — Used to gate features by user segment, plan, or role. Enterprise features that aren’t available on the free plan. Admin-only settings. Beta features available only to users who’ve opted in. These flags may be long-lived or permanent.
Feature Flagging and A/B Testing: What’s the Difference?
This is a common point of confusion. Feature flagging is the infrastructure; A/B testing is a use case built on top of that infrastructure.
A feature flag is a mechanism for controlling who sees what. An A/B test uses a feature flag (or similar mechanism) to divide your user population and measure the difference in outcomes between variants. You can run an A/B test without sophisticated feature flag infrastructure, but it’s much harder and much less flexible.
Think of it this way: feature flags give you the ability to show different things to different users. A/B testing is the discipline of using that ability systematically to learn which version drives better outcomes.
When you’re running a product discovery sprint, feature flags let you put real prototypes in front of real users in a controlled way, not just paper prototypes or mockups. That’s a qualitatively different kind of evidence.
How to Work With Engineers on Feature Flag Strategy
As a PM, you don’t need to implement feature flags. But you should have opinions about how your team uses them.
Decide which features warrant a gradual rollout. Not everything needs a 1% → 5% → 100% rollout. A minor UI change to a low-traffic page probably doesn’t. A change to the payment flow or the core onboarding experience almost certainly does. Build a shared team heuristic for when gradual rollouts are worth the extra coordination.
Define the metrics you’ll watch during rollout. Before you start a rollout, agree with your team on what “good” looks like. What metrics will you check? What threshold would trigger a pause or rollback? Having this defined in advance avoids the messy conversation of “is this metric change bad enough to roll back?” in the middle of a rollout.
Plan for flag cleanup. Feature flags that aren’t cleaned up become technical debt. After a feature is fully rolled out and the flag is no longer needed, it should be removed from the code. Build the cleanup step into your feature delivery process; add it to your definition of done or your post-launch checklist.
Worth pushing back on one common assumption here: more feature flags aren’t automatically safer. A codebase with over 200 stale flags, most of them fully rolled out months earlier and never removed, can take an engineer the better part of two weeks to untangle before anyone can touch the surrounding code with any confidence. A flag nobody cleans up isn’t a safety net anymore. It’s just an if-statement nobody remembers the reason for, quietly making every future change riskier.
Use flags to support progressive delivery. Progressive delivery is the practice of deploying software gradually to detect issues early and limit blast radius. Feature flags are the primary mechanism. If your team isn’t already thinking about progressive delivery, this is a high-leverage conversation to have with your engineering lead.
Where Feature Flag Strategy Breaks Down
Flags as a substitute for QA. Some teams start treating “we can just turn it off” as permission to skip real testing before launch. A kill switch limits damage after something breaks; it doesn’t prevent the break, and users hit by even a 1% rollout still had a bad experience. Fix: keep your pre-launch testing bar the same regardless of whether a flag exists. The flag is insurance, not a substitute for the work.
Nobody owns the removal. Rollout plans almost always specify who turns a flag on. They rarely specify who’s responsible for turning it into permanent code and deleting the flag once it’s fully live. That ambiguity is exactly how a codebase ends up with hundreds of dead flags nobody wants to touch.
Support and sales get blindsided. If 15% of users see a new experience and the rest don’t, and nobody told your support team, you’ll get confused tickets about a feature “not working” for users who were never supposed to see it. Fix: a one-line heads-up to support and sales before any customer-facing rollout starts, even a small one. It costs nothing and prevents a genuinely confusing week for them.
Combinatorial complexity nobody accounted for. Five active flags on the same page means up to 32 possible states a user could be in, and most teams have only manually tested two or three of them. Fix: keep a running count of active flags touching the same surface area, and treat that count, not just each flag individually, as something to actively manage down.
Feature Flagging Best Practices for Product Managers
Always define the rollout plan before launch. What percentage starts? What metrics gate the next expansion? What triggers a rollback? Document this in your feature spec so everyone knows the plan before the flag goes live.
Keep business stakeholders informed during rollouts. When you’re doing a gradual rollout of an important feature, your stakeholders should know. “We’re rolling this out to 10% of users this week, expanding to 100% by the end of next week” is a sentence that prevents a lot of unnecessary questions.
Use internal flags for dogfooding. Before you expose any new feature to users, run it internally. Make your own team use the feature for a few days. You’ll catch obvious issues that wouldn’t have surfaced in testing, and you’ll build more genuine empathy for the user experience.
Tie your rollout metrics to your product metrics guide. Your rollout monitoring shouldn’t be ad-hoc. The metrics you watch during a feature rollout should be your standard product health metrics, the same ones you track every week, not a one-off dashboard that you build for this one release.
Feature Flagging Tools PMs Should Know
The right tool depends less on feature checklists and more on team size, budget, and whether you need experimentation bundled in. Here’s how the major options stack up:
| Tool | Best For | Self-Hosted Option | Notable Strength |
|---|---|---|---|
| LaunchDarkly | Enterprise teams, complex targeting needs | No | Deepest analytics and targeting rules |
| Flagsmith | Budget-conscious teams wanting control | Yes | Open-source, self-hostable |
| Unleash | Teams wanting an active open-source community | Yes | Strong self-hosted feature set |
| Statsig | Teams wanting flags + experimentation in one tool | No | Combines flagging and A/B testing natively |
| Split.io | Teams running sophisticated experimentation programs | No | Strong data science integrations |
LaunchDarkly — The most widely adopted enterprise feature flag management platform. Strong analytics, complex targeting rules, and excellent integration with most development workflows. Priced for enterprise; not cheap for small teams.
Flagsmith — An open-source alternative to LaunchDarkly. Can be self-hosted or used as a cloud service. Good option for teams that want control over their flag infrastructure or have budget constraints.
Unleash — Another open-source feature flag platform, popular in the European engineering community. Self-hostable, strong feature set, active open-source community.
Statsig — A newer platform that combines feature flagging with experimentation in a single tool. Good option for teams that want A/B testing and flags in one place without stitching together multiple tools.
Split.io — Strong feature flagging and experimentation platform with good data science integrations. Popular with teams that run sophisticated experimentation programs.
For product teams that aren’t ready for a dedicated tool, many teams start with simple boolean flags stored in a configuration file or environment variable, then graduate to a proper platform as their needs grow.
Feature flagging won’t be the most glamorous topic you discuss in your next roadmap review. But it’s the kind of practice that separates teams that ship confidently from teams that treat every release as a high-stakes event. When you understand it well, you’ll find yourself reaching for it constantly, as a minimum viable product testing mechanism, as a safety net during risky migrations, as the infrastructure for every experiment you want to run.
If your team doesn’t currently have a clear, shared answer to “who’s responsible for deleting a flag once it’s fully rolled out,” that’s the smallest useful place to start. Pick an owner this week, not a whole platform migration.
References:
- Martin Fowler — “Feature Toggles (aka Feature Flags)” — martinfowler.com
- LaunchDarkly — “What are Feature Flags?” — launchdarkly.com
- Pete Hodgson — “Feature Toggles” — featureflags.io
