Skip to content
ProductOS ProductOS ProductOS

Release Phases

A feature doesn’t go from “built” to “everyone” in one step. It moves through named release phases, each with a defined audience, flag state, and entry / exit criteria. Every feature ships behind a flag, so every phase is reversible: if something breaks, turn the flag off.

This is tracker-agnostic: the phase names are what matter, not the tool. Release phase is how widely it’s on. That’s a separate thing from the work’s stakes / path, which drive how much GTM investment, approval depth, and gate rigour the release gets. The gates themselves, with their checklists and approvers, live in Gates and Approvals; this page owns the phases.

Audience + flag state, at a glance

Section titled “Audience + flag state, at a glance”
PhaseLifecycle statusFlag stateWho can accessPurpose
Behind the flagBuildingOFF (internal override)Dev team onlyBuild + test in production
Private PreviewIn PreviewON for specific accounts5–10 trusted customersFeedback from friendly users, low blast radius
Public PreviewGTM Launch PlanningON for a % / opted-inPreview cohortTest at scale before GA
GALaunchedON for all (or gradual %)All customersFull rollout, still disable-able

The phases

Section titled “The phases”

0. Behind the flag (internal)

Section titled “0. Behind the flag (internal)”
  • Audience: the dev team only (internal override).
  • Flag: OFF.
  • Purpose: build and test in a production environment without exposing anything. Wire up instrumentation here (events, dashboards, guardrail metrics) before anyone outside the team sees it.
  • Exit: the outcome UAT passes (the user’s job is validated end-to-end, job × surface, independent of unit tests) and production-readiness is met to the stakes. See Agentic Delivery.

1. Private Preview

Section titled “1. Private Preview”
  • Audience: 5–10 trusted customer accounts (hand-picked, friendly).
  • Flag: ON for those specific accounts.
  • Purpose: real feedback from real users on the real path, with low blast radius. Fix critical bugs, watch production stability, and confirm the outcome holds outside the building.
  • Exit: private-preview feedback summarised, critical tickets resolved, stability holding, then the Launch Readiness Check.

2. Public Preview

Section titled “2. Public Preview”
  • Audience: a percentage of customers, or opted-in / self-selected ones.
  • Flag: ON for the preview cohort.
  • Purpose: test at scale before committing to everyone: load, edge cases, adoption signal, support volume. This is where you learn whether it works for a broad base, not just the friendly accounts.
  • Exit: adoption and stability thresholds met, no critical issues, then GA sign-off.

3. General Availability (GA)

Section titled “3. General Availability (GA)”
  • Audience: all customers (often via a gradual % ramp).
  • Flag: ON for all (still disable-able).
  • Purpose: full rollout, announced. The feature is now the default.
  • After GA: maintain the flag for a stabilisation window; run the post-launch reviews at 2 weeks / 30 days / 60–90 days and make the explicit call (accelerate / iterate / pivot / investigate / stop).

Widening the audience

Section titled “Widening the audience”

Moving past Private Preview is a real checkpoint, not a flag flip: the Launch Readiness Check. Its checklist and approver are on one page, Gates and Approvals. Don’t widen until it’s closed. Moving past Public Preview has its own, lighter check, GA sign-off.

The per-initiative version of this table, with this release’s audiences, exit criteria, and rollback, is the Rollout section of the RFC. Feature-flag on/off is one release shape, not the only one; see Writing an RFC → Rollout for staged, shadow, and champion-challenger shapes.

Rollback

Section titled “Rollback”

Every phase is behind a flag, so the rollback is always the same: turn the flag off. A phase transition must never leave data in a broken state. Prefer changes that are reversible within the phase.

Section titled “Related”