A launch is a process, not an event. The day code ships is deployment; launch is when customers discover, adopt, and advocate. The gap between the two is where most product value is lost.
▸ Try the interactive toolA launch is a process, not an event. The moment a feature flag flips is deployment — the day code reaches production. Launch is when customers discover, adopt, and advocate for what was built. The gap between deployment and launch is where most product value quietly leaks away — great features shipped to silence because nobody planned the adoption.
The framework structures the weeks of work that turn a shipped feature into a customer outcome: the pre-launch preparation (messaging, enablement, beta), the launch moment itself, and the post-launch follow-through (adoption tracking, iteration). The core discipline is treating launch as a cross-functional plan with phases, not a single announcement — because adoption is earned over weeks, not triggered by a press release.
Pre-launch — messaging, internal enablement, beta, readiness (the bulk of the work)
Launch — the coordinated moment of announcement and availability
Post-launch — adoption tracking, iteration, advocacy (where value is actually realised)
Teams pour months into building, then treat launch as flipping a switch — and watch a strong feature go unnoticed and unadopted.
| The shortcut | What it costs | What it gives you instead |
|---|---|---|
| Deploy = launch confusion | Shipping the code is treated as the finish line; adoption never gets planned. | Separating deployment from launch forces a real adoption plan. |
| No pre-launch prep | Messaging, enablement, and beta are skipped; the launch lands flat. | Pre-launch work — the bulk — makes the moment actually land. |
| No post-launch follow-through | Nobody tracks whether anyone adopted it; issues fester. | Post-launch tracking turns a release into realised value. |
| Uncoordinated functions | Sales, support, and marketing aren't ready when customers arrive. | A cross-functional plan gets every function ready together. |
Not every release needs a full launch. Decide the tier — a quiet update, a standard launch, or a major moment — and what success looks like (adoption, not just availability).
Craft the customer-facing message (rooted in positioning), and enable internal teams — sales, support, success — so they're ready before customers arrive. This is the bulk of the work.
Run a beta to catch issues and gather proof points. Confirm the product, docs, and support are genuinely ready — a launch that exposes a half-ready feature damages trust.
Announce and make available in a coordinated way across channels, sized to the launch tier. Everyone who touches customers should be ready the same day.
Measure whether customers actually discover and adopt the feature, gather feedback, fix friction, and amplify early advocates. This phase is where the value is finally realised — don't skip it.
A team shipped a genuinely strong feature — flipped the flag, posted a changelog note, and moved on to the next thing. Months later, usage was negligible: most customers never knew it existed, sales never mentioned it, and support couldn't answer questions about it.
Re-run as a real launch, the same feature got a pre-launch phase (clear messaging, sales and support enabled, a beta with proof points), a coordinated launch moment, and post-launch adoption tracking that caught and fixed the friction stopping people from trying it. Adoption climbed because the work didn't stop at deployment.
The deliverable is a phased, cross-functional plan — tiered to the launch's size — covering pre-launch prep, the moment, and post-launch follow-through.
| Phase | Key work | Owned with |
|---|---|---|
| Pre-launch | Messaging, enablement, beta, readiness | Marketing, sales, support |
| Launch | Coordinated announcement & availability | All customer-facing teams |
| Post-launch | Adoption tracking, iteration, advocacy | Product, success, data |
Deployment is when the code is live; launch is when the customer's life changes. The distance between them is measured in adoption — and it's bridged by planning, not by an announcement.
The counterintuitive truth is that most launch work happens before and after the launch moment, not at it. The announcement is the visible tip; the adoption that justifies the whole build comes from pre-launch enablement (so everyone's ready) and post-launch tracking (so friction gets fixed and advocates get amplified). Teams that equate launch with the announcement pour months into building and then forfeit the adoption by treating the finish line as the moment the code goes live — when that's really the moment the launch begins.
Flipping the flag isn't launching. Plan discovery, adoption, and advocacy.
If sales and support aren't ready, customers hit a wall. Enable internal teams first.
Without adoption data, you can't tell if the launch worked or fix what's blocking it.
Not every release needs a major launch. Tier the effort to the impact.
The motion (Tool 22) determines how a launch reaches customers — PLG launches in-product, SLG launches through sales.
Launch messaging is positioning (Tool 15) made customer-facing.
Post-launch tracking uses the activation and adoption metrics from Module 5.
Who you launch to first — early adopters vs. mainstream — is an adoption-lifecycle question (Tool 24).
Take a feature (yours or a product's you use). Sketch the three phases: what pre-launch prep would it need, what's the launch moment, and how would you track adoption afterward?
Estimate the split: how much of the total effort is the announcement itself versus the pre- and post-launch work?
If the announcement is a small fraction of the real work, you've understood the framework — the launch that gets adopted is mostly made of the parts nobody sees.