Launch
By the time you reach this stage, there should be nothing to figure out.
Launch is discipline and follow-through. 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.
The other side of launch is adoption: making sure the impact reaches the people it was built for. Shipping is not the finish line. The feature needs to land: used, understood, and doing what you said it would do. That’s what you’re watching for.
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 like “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: The Before/After draft was written in Define and updated throughout Build. By now it needs a final review, a screenshot or demo video attached, and a leadership sign-off before it goes out.
What good looks like: Plain language. No internal jargon. A client reading it cold understands what changed and why it matters.
Bad: “We’ve improved the checkout experience.”
Good: Before: Cart emptied when you left and came back. You had to start over. After: Cart saves automatically for 30 days, across any device.
How to get there: Attach a screenshot at minimum. For anything complex, record a short demo. Send to leadership first for a quick review, then post to the full team and relevant stakeholders within one hour of going live.
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.
Driving Adoption
Shipping is not the finish line. The feature needs to reach the people it was built for. Reach means used, not just available.
What’s expected: PM has a plan for adoption before launch day. Not “we’ll see how it goes,” but a specific set of actions to make sure the feature lands.
What good looks like: The right users know the feature exists, know how to use it, and have a reason to try it. Adoption is tracked against the success metric defined in Define. If adoption is below target after two weeks, there’s a specific next action, not a vague plan to “promote it more.”
How to get there:
Think through who needs to take action for the metric to move. For each group:
- Do they know it exists? Release notes reach users who are already engaged. Users who aren’t will miss it. A direct message, an in-app prompt, or a client briefing may be needed.
- Do they know how to use it? A feature that’s hard to discover or understand doesn’t get used. A short walkthrough, tooltip, or onboarding moment can make the difference.
- Do they have a reason to try it now? Timing and framing matter. “We just launched X” is less compelling than “you no longer have to do Y the hard way.”
Adoption is part of the release plan. Write it in Define alongside the milestones, not as an afterthought on launch day.
Next: Learn