Product launch

Product launch

A launch is two separable things: the rollout (engineering risk management) and the announcement (attention harvesting). Decouple them: ship dark, ramp safely, announce when it is boringly stable.

Method

1. Tier the launch, size the ceremony. Tier 3: quiet improvement, changelog only (see changelog-writing). Tier 2: notable feature, in-product announcement + docs + support briefing. Tier 1: strategic bet, full coordinated moment (PR, campaigns, sales enablement). Most launches are tier 2-3; treating everything as tier 1 exhausts every team and trains users to ignore you.
2. Roll out behind flags, ramped, before any announcement. Dark launch, internal dogfood (see dogfooding-program), beta cohort, percentage ramp with halt criteria (see canary-analysis, feature-flags-hygiene): the announcement date is after the ramp proves stable, never the day the code first meets production. Announcing a launch you then roll back converts a bug into a news story.
3. Run the readiness checklist across functions. Engineering: load tested at announcement-spike traffic (see load-testing), dashboards and alerts live (see product-metrics instrumentation), rollback rehearsed (see rollback-strategy). Support: briefed, macros ready, known limitations documented. Docs and pricing updated; legal/ compliance cleared where applicable (see launch-review for the formal gate). One owner runs the list; unowned checklists are decoration.
4. Write the announcement from the user's problem. Lead with the outcome ("stop rebuilding reports by hand"), show it working, state availability and price plainly (see landing-page-strategy's message hierarchy); match channel to tier (in-product beats email for adoption of tier 2; see user-activation for converting attention to usage). Internal comms land before external: support discovering the launch from tickets is a process failure (see status-updates' no-surprises rule).
5. Staff launch day like a mini-incident. A war-room channel, the dashboard on screen (traffic, errors, activation funnel, support volume), owners named for decisions (ramp further, hold, roll back), and an end-of-day status note (see war-room-protocol scaled down; incident-commander-role if it goes sideways).
6. Review at day 30 against the launch's own goals. Adoption and activation vs targets (see product-metrics), support-ticket themes, what the ramp caught, what the checklist missed: fold into the next launch's checklist (see incident-postmortem's blameless mechanics applied to a happy event). Then decide the follow-through: iterate, expand, or admit the feature is done and move on (see feature-sunsetting when the numbers say so).

Boundaries

• Marketing-driven date commitments invert the decoupling at real risk; when a date is immovable, scope becomes the variable (see mobile-release-strategy's train discipline) and the ramp starts earlier, not never.
• Platform launches (APIs, SDKs) add deprecation posture, versioning promises, and developer docs as first-class deliverables (see api-versioning, api-reference-docs).
• A launch cannot rescue a product discovery failure; attention on something users do not want just accelerates the learning you skipped (see mvp-scoping).