The engineering work can be finished, tested and ready, and the launch can still go badly. Support doesn't know how the feature works. Sales is promising something it doesn't do. Marketing announces it a day before it's actually available in one region. Nobody is watching the numbers.
I wrote about the release go/no-go checklist, which is about whether the build is ready. This one is about whether everyone else is.
The checklist
| Area | What to have ready | Owner (usually) |
|---|---|---|
| Positioning | Who it's for, the problem it solves, how it's different | Product and marketing |
| Messaging | Short description, key benefits, what it doesn't do | Marketing |
| Pricing and packaging | Which plans include it, any new pricing | Product and commercial |
| Sales readiness | Talking points, demo, answers to likely objections | Product and sales |
| Support readiness | How it works, common issues, escalation path | Product and support |
| Documentation | Help articles, FAQs, release notes | Product and support |
| Internal communication | Everyone in the company knows what's launching and when | Product |
| External communication | Emails, blog post, in-app announcements | Marketing |
| Measurement | Dashboard ready, success metrics defined | Product and analytics |
| Timing | Dates per region and platform, all aligned | Product |
Say what it doesn't do
The most useful line in any launch material, in my experience, is what the feature doesn't do. Sales and support will get asked about it, and if they don't know the limits, they'll guess. Usually optimistically.
This matters even more for AI features, where demos can make the product look more capable than it is in everyday use. Clear limits protect trust with customers. If you cut scope to make the date, the list of what you dropped is a good starting point.
Train support before launch, not after
Support should see the feature before customers do. Give them a walkthrough, the help articles, a list of known issues and a clear way to escalate problems they can't solve.
When support learns about a feature from customers, the first week of tickets is much harder than it needs to be.
Align the timing
For a product on several platforms or in several markets, the feature might not be available everywhere at once. Make sure announcements match actual availability, including in markets where the localised version is still catching up. Announcing something users can't find is worse than announcing it a few days later.
This was a regular coordination challenge for us across web, mobile and Smart TV at Travelxp. A single launch calendar that marketing, support and product all used solved most of it.
Decide what success looks like
Before launch, write down what you'll measure, the targets, and when you'll review. Adoption, usage, impact on the main outcome, and guardrail metrics. I covered how to set these up for AI features in the AI adoption metrics post, and much of it applies to any feature.
Launch day
Someone should be clearly responsible for watching on launch day: metrics, support tickets, social mentions, error rates, and any partner APIs the feature depends on. If something goes wrong, they need to know who to call and what the rollback options are.
The post-launch review
A few weeks after launch, review what happened:
- Did it reach the people it was meant for?
- Did it move the metric we hoped?
- What did support hear?
- What went wrong in the launch process itself?
Write down the lessons and update the checklist. Every team's launch checklist should grow a little with every launch, based on what went wrong last time.
Mine started as about ten lines. Most of what's on it now is there because something went wrong once.