Templates / Product launch checklist
Product launch checklist
Week by week from four weeks out to the week after launch. Every line is a task with an owner, not a category to think about.
Launches do not usually fail on launch day. They fail two weeks earlier, when nobody decided who owns the pricing page, and everyone assumed it was handled.
This checklist is ordered by when the work has to happen, not by department. Work backwards from your date, put a name on every line, and the meetings mostly stop being necessary.
It assumes a small team and a real product going live to real customers. Cut lines that do not apply to you. Do not reorder them, because the order is the useful part.
How to use it
- 01Pick the launch date first and write it at the top. Everything below is relative to it, and a floating date makes the whole list decorative.
- 02Put a named owner on every line before you start. Any line without an owner on day one is the line that goes wrong in week four.
- 03Delete what does not apply. A list with lines nobody intends to do teaches the team to skim the whole thing.
- 04Run a fifteen minute check in at the end of each week, walking the list top to bottom and marking done or not done. Not in progress.
- 05Name one person who can move the launch date, and agree in advance what would make them do it.
- 06Keep the week after section. Most teams stop at launch day, and the week after is where the first real feedback arrives.
The template
Header. Fill this in first.
Five lines that prevent most of the arguments.
Launch date: [DATE AND TIME, WITH TIME ZONE]
What we are launching, in one sentence: [PLAIN DESCRIPTION A CUSTOMER WOULD RECOGNIZE]
Who it is for: [PERSONA OR SEGMENT]
What counts as a good launch: [THE ONE OUTCOME, for example fifty teams complete setup in week one]
Who can move the date: [ONE NAME]
Four weeks out
Decisions week. Everything after this depends on these being settled.
[ ] Lock the launch date and put it in every calendar. Owner: [LAUNCH OWNER]
[ ] Write the one sentence description and get everyone to use those exact words. Owner: [MARKETING]
[ ] Confirm pricing, including what happens to existing customers. Owner: [FOUNDER]
[ ] Decide the launch channels and rank them. One primary, two supporting, nothing else. Owner: [MARKETING]
[ ] Write the messaging one pager: who it is for, the problem, what it does, what it does not do. Owner: [MARKETING]
[ ] Agree what is not in this launch, in writing, so scope stops moving. Owner: [PRODUCT]
[ ] Book any external dependencies now: design help, video, a guest slot, a partner mention. Owner: [MARKETING]
[ ] Identify five friendly customers or testers who will use it before launch. Owner: [CX]
[ ] Draft the pricing page changes. Owner: [MARKETING]
[ ] Confirm legal or compliance review is needed or not, and start it if it is. Owner: [FOUNDER]
Three weeks out
Build the assets. Everything written this week gets reviewed next week.
[ ] Write the landing page copy from the messaging one pager. Owner: [MARKETING]
[ ] Write the launch email to existing customers. Owner: [MARKETING]
[ ] Write the launch email to the waitlist or the wider list. Owner: [MARKETING]
[ ] Draft the in product announcement copy. Owner: [PRODUCT]
[ ] Draft five social posts: announcement, how it works, why we built it, a walkthrough, a customer angle. Owner: [SOCIAL]
[ ] Write or update the help documentation for the new thing. Owner: [CX]
[ ] Record a two minute walkthrough. Screen recording is fine. Owner: [PRODUCT]
[ ] Take the screenshots you will use everywhere, at one consistent size. Owner: [DESIGN]
[ ] Put the friendly testers in front of it and write down every question they ask. Owner: [CX]
[ ] Turn those questions into the FAQ section. Owner: [CX]
[ ] Decide what you will measure and confirm the tracking actually records it. Owner: [ANALYTICS]
Two weeks out
Review and rehearse. This is the week problems are still cheap to fix.
[ ] Review every piece of copy against the messaging one pager. Cut anything that drifted. Owner: [MARKETING]
[ ] Fact check every claim on the landing page. Anything without a source gets removed, not softened. Owner: [MARKETING]
[ ] Build the landing page and test it on a phone. Owner: [WEB]
[ ] Test the full signup or purchase path end to end, with a real payment if money is involved. Owner: [PRODUCT]
[ ] Test the path again as an existing customer, which is a different path and is usually the broken one. Owner: [PRODUCT]
[ ] Load the emails into the sending tool and send tests to five people on different email clients. Owner: [MARKETING]
[ ] Confirm support coverage for launch day and the two days after. Owner: [CX]
[ ] Write the support macros for the three questions you know are coming. Owner: [CX]
[ ] Agree the rollback plan: what breaks, who calls it, what we do. Owner: [ENGINEERING]
[ ] Brief anyone who talks to customers on what to say, including what not to promise. Owner: [FOUNDER]
[ ] Schedule the social posts. Owner: [SOCIAL]
One week out
Freeze and prepare. New ideas this week go on the after launch list.
[ ] Freeze the copy. Changes from here need the launch owner to approve. Owner: [LAUNCH OWNER]
[ ] Final proofread of the landing page, both emails and the in product message, by someone who has not read them yet. Owner: [ANYONE ELSE]
[ ] Check every link in every asset, including the ones in email footers. Owner: [MARKETING]
[ ] Confirm the analytics events fire, by triggering them yourself and finding them in the dashboard. Owner: [ANALYTICS]
[ ] Warm up the audience: one post about the problem, no announcement yet. Owner: [SOCIAL]
[ ] Send the heads up email to your friendliest customers, a few days early. Owner: [CX]
[ ] Write the launch day runbook: what happens at what hour, and who does it. Owner: [LAUNCH OWNER]
[ ] Confirm who is online on launch day and when, including the person watching for errors. Owner: [ENGINEERING]
[ ] Prepare the internal announcement so the whole team knows before customers do. Owner: [FOUNDER]
[ ] Decide the one number you will look at on launch day and where you will look at it. Owner: [ANALYTICS]
Launch day, by the hour
Boring is the goal. Everything on this list was decided already.
[ ] Morning, before anything is public: internal announcement in the team channel. Owner: [FOUNDER]
[ ] Ship it. Confirm it is live from a logged out browser and from a phone. Owner: [ENGINEERING]
[ ] Publish the landing page. Check it renders on a phone, again, live. Owner: [WEB]
[ ] Turn on the in product announcement. Owner: [PRODUCT]
[ ] Send the email to existing customers first. They should not hear it from social. Owner: [MARKETING]
[ ] Send the email to the wider list one hour later. Owner: [MARKETING]
[ ] Post the announcement on your primary channel, then the supporting two. Owner: [SOCIAL]
[ ] Watch error rates and support inbox for the first two hours. Owner: [ENGINEERING] and [CX]
[ ] Reply to every comment and every support message for the first four hours. Owner: [SOCIAL] and [CX]
[ ] End of day: write down what broke, what surprised you and what people kept asking. Owner: [LAUNCH OWNER]
The week after
The section most checklists leave out, and where the useful information arrives.
[ ] Day one after: fix the top support issue before doing anything else. Owner: [ENGINEERING]
[ ] Day two: send a follow up to people who opened but did not act, with the walkthrough video. Owner: [MARKETING]
[ ] Day three: read every support ticket from launch and group them into three themes. Owner: [CX]
[ ] Day three: update the help docs and the FAQ with what people actually asked. Owner: [CX]
[ ] Day five: post the honest follow up, including one thing that did not go to plan. Owner: [SOCIAL]
[ ] Day five: check the number you said you would measure, and write down what it says. Owner: [ANALYTICS]
[ ] Day seven: run a thirty minute retro. What to keep, what to change, what to never do again. Owner: [LAUNCH OWNER]
[ ] Day seven: move the after launch list into the normal roadmap so it does not evaporate. Owner: [PRODUCT]
[ ] Contact the first ten people who used it and ask one question: what nearly stopped you? Owner: [FOUNDER]
The five things that go wrong most
Check these specifically, because they are the ones teams find on launch day.
The existing customer path. Everyone tests the new signup and nobody tests what a logged in customer sees.
Email on a phone with images off. The layout that looked fine on a laptop becomes an unreadable column.
The pricing page saying something different from the launch email. Two people wrote them a week apart.
Analytics recording nothing, discovered on day three, when the launch week data is already gone.
Nobody assigned to replies. The announcement goes out and comments sit unanswered for six hours, which is the whole window.
Where this usually goes wrong
- Starting from the launch date and working forwards. Working backwards from the date is what exposes the week where three things collide.
- Owners listed as a team. Marketing does not write the email, a person does, and a team name is how a task stays unstarted for two weeks.
- Adding scope in the final week. The thing you add unreviewed is the thing that breaks in front of the largest audience you will have.
- Announcing to social before emailing existing customers. Finding out from a public post that the tool they pay for changed is a bad way to learn it.
- Treating launch day as the finish. The first real feedback arrives in the days after, and if the team has moved on there is nobody left to act on it.
Common questions
How long before launch should we start this checklist?
Four weeks works for a feature or a small product with a small team. A bigger launch needs six to eight, but the shape stays the same: decisions first, assets second, review third, freeze last.
What if we have to move the launch date?
Move it once and move it far enough to be true. Two day slips repeated three times cost more than one two week slip, because each slip restarts the coordination.
Who should own the launch?
One person, and preferably not the person building it. The launch owner keeps the list moving and holds the date. That is a full job during the last two weeks.
Do we need a press release?
Usually no. For most launches the customer email, the landing page and the in product announcement do almost all the work, and a press release absorbs time that would be better spent on the support docs.
Related templates