Launch
By the time you reach this stage, there should be nothing to figure out.
The release plan was written in Define. It has been kept current throughout Build. The release notes have been drafted and updated. Everyone knows what's going out, when, and who needs to know. Launch is not where you coordinate. Launch is where you execute a plan that was already made.
If Launch feels stressful or chaotic, that's a signal about what happened in Build, not about the launch itself.
No Surprises
The most important principle at launch: no one finds out about it at launch.
Internal team members know what's shipping and when. The client knows what's in the release and what it does. Support, if relevant, has been briefed. Stakeholders who need to approve have approved. None of these happen the day something ships. They happen in the days or week before, as part of the release plan you've been maintaining.
If someone is surprised by a release, the process failed somewhere earlier.
Release Notes
Release notes go out before the feature goes live. Not after. Not simultaneously. Before.
The release notes draft was written in Define. It should be updated as the feature evolved during Build. By the time you're publishing, it should require minimal editing — just a final review for accuracy and tone.
Good release notes: describe what changed, for whom, and what it allows them to do now that they couldn't do before. Written in plain language. No internal terminology. No technical implementation details unless they matter to the user.
Bad release notes: "Bug fixes and performance improvements." "We've updated the scheduling module." Anything that requires the reader to already know what the feature is.
Who to Tell and When
Think through the stakeholder list. For each person or group:
- Do they need to know before it ships? (Clients, support, account managers)
- Do they need to know at the moment it ships? (Internal team)
- Do they need to find out through the release notes? (End users)
Most stakeholders should hear from you before the release, not from the notification when it hits their screen. A quick message — "this goes out tomorrow, here's what it does, let me know if you have questions" — is almost always worth sending.
After It Ships
Watch it. First few hours matter. If something is wrong — errors spiking, unexpected behavior, users confused — you want to know immediately, not at the next morning's standup.
Check the metrics you defined in Define. Not to make conclusions yet — too early — but to confirm the instrumentation is working and the feature is being used. If it's not showing up in the data, that's a problem to investigate before you declare it done.
Stay available. Users notice new things. Questions come in. Something will behave in a way you didn't anticipate. Be present for the first day.
Next: Learn