the release · the moment
The release moment
The gate is passed. The Product Owner enables the flag. The feature is live. This is not the end of the work — it is the beginning of a different kind of attention.
In the first hour after enablement, the team watches three things: the SLO dashboards (is the system healthy?), the analytics events (are the right events firing?), and the support channel (are users confused by something expected or surprised by something unexpected?). The runbook is open. The on-call is alert. This is not a vigil — it is a structured watch with clear signals for action.
The release brief
The client receives a release brief before the flag is enabled — not at the moment it goes live, not after. Short, in the client's language, covering exactly three things:
- What changed and for whom — person-first. "Gal can now see all student scores immediately when an exam closes, without manual calculation."
- What to expect — the experience, any intentionally unfamiliar behaviour.
- What is not yet available — the honest list of deferred items, so absences aren't interpreted as bugs.
The release brief also names the prediction to the client: "We expect grading time to drop below 15 minutes. We will check with you in 30 days." That sentence sets the expectation and creates the natural follow-up.
The CS handoff
Customer support receives a more detailed, operational handoff: what the feature does (happy path in plain language), known limitations, the three to five most likely support questions with answers, and the escalation path — what qualifies as a bug vs a feature request vs working-as-intended, and who gets notified for each.
Resolution gate — Release to After We Build
Enough to close the chain honestly with the people who depend on it.
The flag is enabled. The release brief landed before the feature did. The prediction is named to the client with a check date. CS is briefed. The first hour is clean.