Shipping and specialties
Measuring launches
Write success metrics and guardrails before launch day, then double down, iterate or sunset.
Define success before launch day, in writing, with a time window. Vague goals ("buzz," "adoption") cannot fail, so they never inform the next bet. The first 30 days after GA are still part of the launch.
Concept
A success card names adoption, activation quality, an outcome, and guardrails you must not break. Write it before the flag goes on.
A useful success card
Example for "scheduled reports":
| Metric type | Example |
|---|---|
| Adoption | 20% of weekly-active teams create ≥1 schedule within 30 days |
| Activation quality | Median time-to-first-schedule ≤ 10 minutes |
| Outcome | Support tickets about "manual CSV export" down 30% in 60 days |
| Guardrails | p99 report-job latency < 2 min; error rate < 1%; no Sev-1 |
Compare against a baseline or a holdout if you can (A/B testing). For many T2 launches a simple before/after with cohort cuts is enough: teams that saw the announcement email versus organic discovery.
Walking through a funnel leak
Launch week: 12,000 unique visitors to the blog, 800 clicks to the feature, 90 teams activate. Vanity says "great traffic." The pre-written goal was 400 activated teams in 30 days. At day 14 you are at 140.
Diagnosis: onboarding drop at permission scopes. You ship a permission wizard in week 3; day-30 activations hit 380. Without the pre-defined metric, the team would have celebrated the blog and missed the funnel leak.
Also watch leading indicators on day 0–3: signup spikes, error budgets, support volume by tag, sales questions. Lagging revenue metrics often take a full quarter. Do not wait that long to decide if the launch mechanics worked.
Iterate, double down, or sunset
Schedule a post-launch review around T+14 days: what moved, what broke, what feedback themes dominate, what ships next versus what is won't-do. Feed that into iteration and feedback.
Trade-off
Double down when activation is healthy but awareness is low (a distribution problem). Iterate the product when awareness is fine but activation or retention is weak. Kill when neither awareness nor value shows up after a fair window — continuing is opportunity cost against the next bet (prioritization).
Some launches reveal the feature should not grow. Usage stuck under a few percent of actives, support cost high, strategic fit gone — that is a sunset candidate, not a moral failure. Sunset with the same seriousness as launch: notice period (often 60–90 days for paid B2B), migration path, stop selling immediately, firm end date. Ambiguous "we are phasing it out someday" guarantees nobody migrates.
Common mistakes
- "We'll see how it goes." If success cannot fail, you will not learn.
- Celebrating blog traffic. Measure the funnel to first value.
- Soft-launch forever, or a sunset with no date. Calendar the decision.
Check yourself
12,000 blog visitors, 90 activations, goal 400 in 30 days. Did the launch work? Not yet. Traffic is vanity. Diagnose the funnel (here, permission scopes) against the pre-written goal.
Activation is healthy but almost nobody heard about the feature. Double down, iterate, or kill? Double down on distribution. The product path works; awareness does not.
Key takeaways
- Write adoption, activation quality, outcome and guardrails before launch day.
- Measure the funnel, not just the blog. Watch day 0–3 leading indicators.
- T+14 review: double down, iterate, or sunset with a date and a migration path.
Further learning
ProdPad's GTM webinar walks release → beta → launch metrics with concrete cross-functional ownership.
Back to the map: launching.
Related
Launching products and features
Launch tiers, betas, checklists and measuring whether a launch worked.
A/B testing and experimentation
Designing randomized experiments, sizing samples with real arithmetic, reading lift and confidence intervals, and shipping only what the data actually supports.
Iteration and feedback loops
Turning feedback, support tickets and data into continuous improvement and kill decisions.