Feature Flag Rollout Plan
By jieunUX · Published · Updated
Maps the stages, audiences, metrics and kill switch for releasing a feature behind a flag, so a bad rollout is spotted fast and reversed in minutes.
Prompt template
## Feature Flag Rollout Plan Plan the staged rollout of a feature behind a flag. - Feature: [textarea: What it does and who it affects] - Flag system: [text: LaunchDarkly or Firebase Remote Config or homegrown] - Risk if it goes wrong: [dropdown: Cosmetic, Lost conversions, Data corruption, Outage] - User base size: [text: About 20000 weekly users] - Success metric: [text: The number that proves the feature works] - Guardrail metrics: [textarea: Numbers that must not get worse] - Who can roll back: [text: Role or team on call] Design the rollout in stages, each with an audience, a size, a minimum soak time and the exit rule to advance. A typical path is internal staff, a small percentage of low-risk users, a larger slice, then everyone, but fit it to the risk and the user count so each stage yields enough data to read. For every stage, state the metric thresholds that mean go, hold or stop, using the success metric and guardrails given. Define the kill switch precisely: who flips it, how long it takes to take effect, and what happens to users and data already touched, including any migration that does not reverse. Add a monitoring checklist for the first hour of each stage. Finish with a flag cleanup date, because stale flags become permanent code paths.