Amey-Thakur 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
- 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.
- 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.
- 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.
- 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).
- 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).
- 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).