Product launch
A launch is not an announcement. The announcement is the cheapest part and the part most likely to be mistaken for the whole thing, which is how features get press coverage and no adoption.
Tier the launch before planning it
Not everything deserves the same treatment, and treating everything as major is how a team burns its own attention and its audience's.
- Tier one — changes the story you tell about the product, or opens a new segment. Full motion: positioning work, press, sales enablement, customer communication, campaign.
- Tier two — meaningful to existing customers, not a new story. In-product announcement, documentation, a note to affected accounts, sales briefing.
- Tier three — improvement. Release notes and nothing else.
Agree the tier before work starts, and expect the pull toward tier one from whoever built it. Effort spent above the tier is taken from somewhere else, usually from the next launch.
Sequence internal readiness ahead of the announcement
The order matters and gets reversed constantly. Support and sales find out from the announcement, then spend launch week answering questions they were never briefed on, badly.
Before anything external: documentation exists, support can answer the top questions, sales knows who it is for and who it is not for, pricing and packaging are decided and configured, and the thing works for the accounts that will try it first.
Have someone outside the team use it from scratch. The team cannot see the first-run experience any more, and the first-run experience is what everyone else gets.
Decide who it is for, and say who it is not for
A launch aimed at everyone lands on no one. Name the segment, the problem it solves, and what changes for them — and say explicitly who should not use it yet. Sales will otherwise sell it to whoever asks, and the earliest customers will be the worst-fit ones.
Pick a date for a reason, and defend the criteria over the date
Launch dates get set by an event, a quarter, or a promise. Whatever fixes it, write down the criteria that must hold to launch on it — quality bar, documentation, support readiness — and treat those as the real gate.
Launching before support readiness is the most expensive way to save a week. The cost lands as a bad first impression on exactly the customers most interested in the thing.
Plan the days after, not just the day
Most launch plans end on launch day, which is where the work starts. Schedule the follow-through: a second wave for people who missed the first, in-product prompts for users who have not tried it, outreach to accounts that fit, and a check on the questions arriving in support.
Watch the first support tickets closely. They are the fastest signal about what the launch got wrong, and they arrive before any dashboard moves.
Measure adoption, not announcement
Reach, impressions and press mentions measure the announcement. What matters is whether the intended people are using the thing and whether it did what the roadmap claimed.
Decide the number before launch — how many of which accounts, doing what, by when. A launch evaluated on engagement metrics chosen afterward is always a success and teaches you nothing.
Sources
references/sources.md in this skill lists the outside authorities that settle the questions
here — what each one is authoritative for, and what you may do with it. Check them before
answering on anything they cover, and cite what you used. Most are free to read and not free
to reproduce; the use note on each is binding.
Never
- Announce externally before support and sales can answer the obvious questions.
- Run a tier-one motion for a tier-three change because the team is proud of it.
- Launch to everyone because narrowing the audience feels like reducing the impact.
- Report launch success in reach when the goal was adoption.
