A switch that turns a feature on or off without deploying new code, separating shipping code from releasing features.
Why it exists
Shipping a feature and releasing it to users are two different moments, and coupling them makes every launch a risky all-at-once deploy. Feature flags exist to turn features on and off without deploying, so code can ship dark, roll out to a few users first, and be switched off instantly if it misbehaves.
How it actually works
Code for a new feature can be deployed to production but hidden behind a flag, an off switch. Flip the flag on and the feature appears; flip it off and it's gone, instantly, no deploy needed.
This lets you release to a few users first, turn a broken feature off in seconds, or schedule a launch by flipping a switch at the right moment. Deploying and releasing become separate decisions you control independently.
Subtopics
A senior PM walks you through it
A junior PM, stuck
I want to open the new checkout to 10% of users today. The dev said "just edit the flag config" and pasted a JSON file, but there are three features in it and I am scared I will change the wrong number and either launch something to everyone or break a feature that is already live.
This is a safe edit once you can see which field controls what, and it is a small file. Below is the actual feature-flags JSON, the settings the app reads to decide who sees which feature. I will show you the exactly two fields you touch and the one field that is your instant undo, so you can make the change without touching anything that is already live.
Editing enabled or percent on the wrong feature line. Each feature is independent; changing search_suggestions while aiming at new_checkout can pull a live feature out from under users. Confirm the key name before the value.
Setting rollout_percent to 10 but leaving enabled false. Both gates have to open: enabled true turns the feature on, the percent decides how many see it. Off at any percent is still off.
Ramping past 10% before reading the metrics you set the flag to protect. The point of a small percent is to watch first; jumping to 100 throws away the safety the flag exists to give you.
Treating a flag flip as harmless because there is no deploy. No deploy is not no risk; a wrong percent shows real users an unfinished feature. Know the kill_switch is there before you turn anything up.
Tell the dev: "To open new checkout to 10%, I set new_checkout enabled to true and rollout_percent from 0 to 10, nothing else, and kill_switch is there to force it off in one edit if conversion dips. Can you review that one-line change before I merge it?" You read a flag config, found the two fields that control a rollout and the one that undoes it, and made a launch a safe edit instead of a scary one.
Where a PM meets this
Flags hand you the launch button: you decide when a built feature goes live, and to whom, without waiting on a deploy.
"Turn it off" during an incident is a flag; "give it to 10% first" is a flag. This is one of the most PM-relevant tools here.
Hear it in a meeting
"It's behind a flag, we'll open it to 10% and watch conversion."