| name | product-launch |
| description | Takes something built and gets it into the market — tiering the launch to match what it actually warrants, sequencing internal readiness before external announcement, preparing sales and support to answer the questions it creates, choosing the date for a reason, and measuring adoption rather than announcement reach. Use this to plan a launch, right-size one that is consuming more than it deserves, work out why a released feature nobody uses was launched loudly, or run the weeks after launch day. |
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.
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.
