We want to coordinate product, QA, and engineering on staged releases. How should we structure feature flag usage?

A good way to structure feature flags for staged releases is to treat them as release controls, not permanent product logic. That keeps Product, QA, and Engineering aligned on what’s shipping, who sees it, and when it can be removed.

Recommended structure

1) Use one flag per releasable feature

Create a flag for each user-facing capability you want to stage.

Examples:

• new_checkout_flow
• bulk_edit_projects
• mobile_search_v2

Avoid:

• one flag controlling many unrelated changes
• deeply nested flags for every small code path

This makes it clear to Product what’s being released and to QA what to test.

---

2) Standardize flag states

Use a common set of states or targeting modes:

• Off: feature hidden/disabled for everyone
• Internal only: visible to employees/testers
• QA / staging cohort: visible to designated testers
• Pilot / beta customers: visible to a small real-user group
• Gradual rollout: percentage-based rollout
• On: enabled for all users

This gives everyone a shared rollout language.

---

3) Separate release flags from long-term product flags

Use feature flags in two categories:

Release flags

Temporary, used to stage a launch.

• Turned on/off during rollout
• Removed after full release and stabilization

Product flags

Longer-lived, used for entitlement, experiments, or tiering.

• Example: paid plan access, A/B tests, region-specific availability

This distinction prevents “flag debt.”

---

4) Define ownership

Assign clear ownership per flag:

• Product: decides rollout timing, audience, and success criteria
• Engineering: implements the flag and safe fallback behavior
• QA: validates behavior across target states and edge cases
• Release manager / TPM: coordinates timing, approvals, and communication

If no one owns the flag, it tends to linger indefinitely.

---

5) Make flags visible in a release checklist

For each release flag, document:

• Flag name
• Purpose
• Owner
• Default state
• Target cohorts
• Rollout plan
• Monitoring metrics
• Rollback plan
• Removal date or expiry review

This can live in a release doc, ticket, or launch checklist.

---

6) QA should test by flag state, not by environment only

QA should verify behavior in the same states Product will use in rollout:

• Flag off
• Flag on for internal accounts
• Flag on for QA cohort
• Flag on for pilot users
• Flag on for 100%

Where possible, test both:

• the feature path
• the fallback/disabled path

This reduces surprises during staged enablement.

---

7) Use percentage rollouts after targeted validation

A common pattern:

1. Dev and QA test with flag on in non-prod
2. Internal dogfood with flag on
3. Small pilot group in production
4. 5% / 25% / 50% / 100% rollout
5. Remove flag after stable launch

Product should define the rollout thresholds and pause conditions.

---

8) Build safety into the implementation

Flags should support:

• fast rollback
• no broken states when off
• backward-compatible data changes if needed
• logging/telemetry by flag state

A flag should not require a redeploy to disable the feature.

---

9) Keep a cleanup policy

Every flag should have an expiration review date, for example:

• 2 weeks after full rollout
• 30 days after launch for cleanup
• review in monthly flag debt grooming

Dead flags confuse QA and increase technical complexity.

---

A practical operating model

For Product

• defines audience and rollout criteria
• approves movement between stages
• monitors success metrics

For QA

• creates a test matrix by flag state
• validates off/on/fallback behavior
• confirms rollout readiness before each step

For Engineering

• implements the flag safely
• ensures observability and rollback
• removes flag after launch completion

---

Simple naming and documentation convention

Use a consistent naming scheme:

• Prefix by area: checkout_, search_, billing_
• Use clear intent: checkout_new_flow
• Document in one source of truth

Example record:

• Flag: checkout_new_flow
• Type: release flag
• Owner: Product + Eng
• Default: off
• Rollout: internal → QA → 10% → 50% → 100%
• Removal date: 2026-03-01

---

Best practice summary

If you want a clean staged-release process, use feature flags to:

• gate each releasable feature separately
• support explicit rollout stages
• assign ownership
• require QA verification by flag state
• remove release flags quickly after launch

If you want, I can also give you a sample feature flag policy, a RACI chart, or a release checklist template for Product/QA/Engineering.