The Product Launch Checklist (Internal and External)
A phased checklist for launching a feature or product: what to line up before launch, what has to happen on the day, and the follow-through that turns a launch into adoption. Includes the assets you need and a copyable list.
A product launch has three phases, and skipping the first or third is where launches go quiet. Pre-launch: nail the positioning, enable the internal teams, produce the assets (a demo, screenshots, docs), and do a dry run. Launch day: publish in a deliberate order — docs first, then changelog, site, email, social, communities — while someone watches for breakage and covers support. Post-launch: measure whether people are actually using the thing, collect feedback, follow up with prospects who were waiting on it, and hold a short retro. The internal launch always precedes the external one, even by a day.
Pre-launch (start 2–4 weeks out for anything significant)
Positioning
- One-line description a non-expert understands.
- One-paragraph description with the user benefit up front.
- The specific user or use case this is for (and who it's not for).
- How it's different from the workaround people use today.
Internal enablement
- Support has docs and knows the common failure modes.
- Sales and success can describe it and demo it.
- A shared FAQ for internal questions.
Assets (start these first — they're the long pole)
- Updated documentation, published but unlinked until launch.
- Changelog entry drafted.
- A visual per key point — screenshot, GIF, or clip.
- An interactive demo or short walkthrough of the new capability.
- Announcement post and email drafted (for a major launch).
Dry run
- Walk the full user flow on production (or a production-like environment) as a new user.
- Test the demo, the links, the email render, the docs navigation.
Launch day
Publish in order — each step assumes the previous is live:
- Documentation linked and discoverable.
- Changelog entry published.
- Site updated (feature page, homepage mention, pricing if relevant).
- In-app "what's new" live.
- Email sent (for major launches).
- Social posts, one per notable point.
- Community posts (relevant forums, communities, and — if it fits — a launch platform).
During the day
- Someone monitoring error rates and support volume.
- Someone answering comments and questions in near-real-time.
- A rollback or feature-flag plan if something breaks.
The interactive demo is the asset that does the most work on launch day: it's the thing you link in the announcement, drop in the email, and paste into community replies. One recording, used everywhere. See how to build a product walkthrough.
Post-launch (the week after)
- Adoption check — how many users have tried the feature? Is it sticking? See feature adoption.
- Feedback sweep — support tickets, community comments, direct outreach to a few users. See how to collect product feedback.
- Prospect follow-up — email the deals that stalled waiting on this, with the demo link.
- Fix the top papercut — there's almost always one small thing that trips people up. Ship it fast.
- Retro — 30 minutes: what worked, what was a scramble, what to templatize for next time.
The reusable version
Turn this into a template your team clones per launch, with owners and dates. The checklist matters less than the habit of running all three phases every time — most launches nail the middle one and drop the bookends.
Related: changelog best practices, how to write release notes people actually read, how to run a beta program.
Frequently asked questions
What should be on a product launch checklist?
Three phases. Pre-launch: positioning, internal enablement, assets (demo, screenshots, docs), and a dry run. Launch day: publish in order (docs, changelog, site, email, social, communities), monitor for issues, and have someone on support. Post-launch: measure adoption, gather feedback, follow up with prospects, and schedule a retro.
How far in advance should you plan a product launch?
For a significant feature, two to four weeks of lead time covers positioning, asset creation, internal enablement, and a dry run without a scramble. Smaller launches need less. The constraint is usually asset production — a demo, a walkthrough video, updated docs — so start those first.
What assets do you need for a product launch?
At minimum: a one-line and one-paragraph description, updated documentation, a changelog entry, a visual (screenshot or GIF) per key point, and an interactive demo or short walkthrough of the new capability. For a major launch add an announcement post, an email, and a landing section or page.
What is the difference between an internal and external launch?
The internal launch makes sure everyone who talks to customers — support, sales, success, marketing — knows what shipped, why, and how to demo it, before customers hear about it. The external launch is the customer-facing announcement. The internal one should always come first, even by a day.