The Rollout Plan Document

One page, agreed in advance

A rollout plan answers, before launch: what is launching and for whom; success metrics and guardrail metrics with thresholds; launch bars (evaluation, safety, cost, latency); stages of exposure and how long each holds; who decides to advance, pause or roll back, and on what signals; the kill switch and fallback behaviour; communication to users and support; and the owner on call. Writing it first prevents moving goalposts under launch pressure.

A rollout plan skeleton

Fill it in and get sign-off.

feature: AI ticket summary for support agents        owner: support-ai team
success: handle time -10%; summary rated useful >= 80%
guardrails: thumbs-down <= 5%, safety flags <= 1 per 1k, p95 latency <= 5 s, cost <= $0.012/request
launch bars: eval pass >= 85% overall, >= 80% each slice; red-team blockers = 0
stages: dogfood 7d -> beta 14d -> 1% -> 5% -> 25% -> 50% -> 100% (gate checks at each)
kill switch: flag "ai-summary" (support lead + on-call can flip); fallback: last 5 messages
comms: agent training note, in-product "AI-generated" label, feedback button
rollback triggers: see monitoring section; decision makers: owner + on-call

Name the decision makers

Write down who can pause or roll back without a meeting; in an incident there is no time to find out.

Quick check: Why write the rollout plan before launch?

• To agree on metrics, bars and rollback rules before launch pressure builds
• To avoid measuring anything
• Because launches cannot be paused
• To skip user communication