Feature Flag Decision Template
A decision template for when and how to use feature flags. Define flag scope, rollout strategy, kill switch criteria, and cleanup schedule before shipping. Free to copy, download, and use. No signup required.
# Feature Flag Decision Template **Feature:** [Feature Name] **Flag Key:** [feature_name_v1] **PM:** [Name] **Engineer:** [Name] **Date:** [Date] **Target Ship Date:** [Date] --- ## 1. Flag Purpose **Why is this feature flag needed?** - [ ] Gradual rollout (% of users) - [ ] A/B test (control vs treatment) - [ ] Kill switch for risky feature - [ ] Beta / allowlist rollout (specific users or accounts) - [ ] Canary deployment (specific servers or regions) - [ ] Operational toggle (off during maintenance) **Is a flag necessary here?** > Ask: Could we ship this to 100% of users immediately with confidence? If yes, skip the flag. [Justify why a flag is needed or not] --- ## 2. Flag Configuration | Setting | Value | |---|---| | Flag Key | `feature_name_v1` | | Flag Type | Boolean / Multivariate | | Default Value (off) | false | | Enabled Value (on) | true | | Platform | Web / Mobile / API | | Targeting Scope | All users / Paid users / Beta group / % rollout | --- ## 3. Rollout Plan | Phase | Target | % Users | Start Date | Success Criteria | |---|---|---|---|---| | 1 — Internal | Employees only | 100% internal | Day 1 | No errors in logs | | 2 — Beta | Beta users (allowlist) | ~5% | Day 3 | Error rate < 0.1%; no P1 bugs | | 3 — Ramp | General users | 10% → 25% → 50% → 100% | Week 2 | Conversion / engagement metric within 5% of baseline | | 4 — Full | All users | 100% | Week 3 | — | **Rollout gates:** Each phase requires the previous phase's success criteria to be met before advancing. --- ## 4. Metrics to Monitor | Metric | Baseline | Target | Alert Threshold | |---|---|---|---| | Error rate | | | > 0.5% → pause rollout | | Page load time (p95) | | | > 500ms above baseline → pause | | [Feature adoption metric] | | | | | [Core product metric] | | | | --- ## 5. Kill Switch Criteria > Define exactly what triggers an immediate rollback. Don't leave this to judgment in an incident. Automatically roll back (set flag to 0%) if: - [ ] Error rate exceeds **[X%]** for > 5 minutes - [ ] P95 latency exceeds baseline by > **[Xms]** - [ ] More than **[X]** user complaints in Slack/support in 1 hour - [ ] Any data integrity issue detected Who can pull the kill switch: **[PM / On-call engineer / Anyone]** How to pull it: [Link to flag in LaunchDarkly / GrowthBook / Unleash] --- ## 6. Flag Lifespan | Date | State | |---|---| | [Ship date] | Flag created, off by default | | [+1 week] | Phase 1 rollout | | [+3 weeks] | 100% rollout (if criteria met) | | **[+6 weeks] → Cleanup deadline** | Flag removed from code and dashboard | **Flag cleanup owner:** [Engineer Name] **Cleanup ticket:** [Link to Jira/Linear ticket] > Flags that aren't cleaned up become permanent feature toggles. Set a cleanup deadline at flag creation time, not after. --- ## 7. Risks | Risk | Probability | Impact | Mitigation | |---|---|---|---| | Flag logic error causes different behavior for flagged vs non-flagged users | Medium | High | Code review + QA both variants | | Flag is never cleaned up | High | Medium | Calendar reminder + ticket created now | | Partial rollout causes inconsistent UX across sessions | Low | Low | Sticky sessions by user_id, not session | --- ## 8. Dependencies | Dependency | Status | Owner | |---|---|---| | Analytics event tracking | ✅ / 🔲 | | | Monitoring dashboard updated | ✅ / 🔲 | | | Support team briefed | ✅ / 🔲 | |
How to use this Feature Flag Decision template
Decide first whether a flag is actually needed
Feature flags have a cost: code complexity, test burden, and cleanup debt. If you can ship at 100% confidence immediately, skip the flag. Use flags for features with real risk (irreversible data changes, significant UX shifts, or load concerns at scale).
Define kill switch criteria before launch, not during an incident
During an incident, you're under pressure and making decisions on incomplete information. Pre-define the exact numbers that trigger a rollback (error rate, latency, complaint volume). This removes judgment from a moment when judgment is least reliable.
Set the cleanup deadline at flag creation
Create the cleanup ticket and assign it to a named engineer the same day you create the flag. Flags without cleanup deadlines become permanent — they accumulate in your codebase and create confusion about what behavior is 'real'. 6 weeks after 100% rollout is a reasonable default.
Gate each rollout phase on explicit success criteria
Don't advance from 10% to 50% automatically after a time delay. Gate it on actual data: error rate below threshold, no P1 bugs, core metrics within normal range. This is the entire point of a gradual rollout.
Want a Feature Flag Decision grounded in your actual customer data?
PMRead ingests your customer interviews, feedback, and Slack threads — and generates PRDs backed by real evidence, not guesses.
Frequently asked questions
What's the best feature flag tool for a small team?
GrowthBook (open source, self-hostable) is ideal for cost-conscious teams. LaunchDarkly is the enterprise standard with excellent SDKs and targeting. Unleash is a solid open-source alternative. For very small teams, a simple database-backed toggle (a Feature table in Postgres) is often sufficient before you need a dedicated platform.
Should flags target users or sessions?
Target by user_id for consistency — a user who sees variant A on their laptop should also see variant A on mobile. Session-based targeting creates a jarring experience where the same person sees different versions across sessions.
How many feature flags is too many?
There's no absolute limit, but flags that live longer than 3 months are a red flag (pun intended). If you have > 50 active flags in a codebase of < 50k lines, you likely have a cleanup backlog problem. Audit flags quarterly and delete anything that's been at 100% for > 6 weeks.
Can feature flags replace blue-green deployments?
No — they're complementary. Blue-green deployments control which version of the code runs on which servers. Feature flags control which code paths execute for which users within a single deployment. Use both: deploy to blue/green, then control user exposure with flags.
Other free templates