Launch
By the time you reach this stage, there should be nothing to figure out.
The release plan was written in Define and 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 — it's where you execute a plan that was already made.
If Launch feels stressful or chaotic, that's a signal about what happened earlier, not about the launch itself.
No Surprises
What's expected: Every stakeholder who needs to know about this release has been informed before it ships — not at the moment it ships, not after.
What good looks like: The client knows what's in the release and what it does. Internal team members know what's shipping and when. Support, if relevant, has been briefed. No one finds out about the release by seeing it live.
How to get there:
Work 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 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.
Tools:
- Eisenhower Matrix — useful for triaging last-minute items that surface before launch. Separate what actually needs to be done now from what can follow the release.
Release Notes
What's expected: Release notes go out before the feature goes live. The draft was written in Define and updated throughout Build. By now it should require only a final review.
What good looks like: Plain language. Describes what changed, for whom, and what it allows them to do now that they couldn't before. No internal jargon. No technical implementation details unless they matter to the user.
Bad: "We've updated the scheduling module."
Good: "Coordinators can now reschedule a patient directly from the appointment card — no cancellation needed. Patient intake data carries over automatically."
How to get there: Read the notes as if you're a client seeing them for the first time. Would you understand what changed and why it matters? If not, rewrite until you would.
After It Ships
Watch it. The first few hours matter.
What's expected: PM is monitoring metrics, error rates, and support tickets on launch day. The instrumentation set up in Define is being checked. If something is wrong, you know it the same day — not at the next morning's standup.
What good looks like: You check the primary metric from Define. You confirm the feature is being used. You confirm error rates haven't spiked. If any of these are off, you investigate immediately.
How to get there: Before launching, write down what you'll check and when. "I'll look at X metric at 2pm and Y support queue at end of day." The plan makes it less likely you forget in the noise of a release day.
Next: Learn