It is 11 pm the night before launch. The engineer who built the feature is writing the announcement email, the docs page still says "coming soon", and the pricing page describes a plan that stopped existing this morning. The product is fine. Everything around it was nobody's job.
That is how most small-team launches go wrong, and it is fixable with a calendar. This is the SaaS product launch checklist I work from, timed from six weeks out to thirty days after, written for a team where marketing is somebody's second job.
First, decide how big this launch actually is
Not every release deserves a launch, and treating every release like one is how a team burns out by March. Pick a size before you plan anything:
A changelog entry. A fix or a small improvement. Write it up, ship it, move on.
A feature launch. Something existing customers will change their behaviour for. Docs, a changelog entry, a customer email, maybe a post.
A product launch. Something that changes what you sell or who you sell it to. New pages, pricing changes, sales enablement, the lot.
The checklist below is written for the middle and the top. For a changelog entry, skip to the docs section and stop there.
Six weeks out: the one line everything depends on
Write the positioning line. One sentence: who it is for, what job it does, and what they did before it existed. If the team cannot agree on that sentence, that disagreement is the launch's real problem, and it is much cheaper to find now than in the email draft.
Pick one owner. One person who is allowed to chase everyone else. Not a committee.
Choose the number you will judge it on, and write it down. Existing accounts that turn the feature on, trials started from the launch page, and demo requests that mention it. Pick before launch, so you are not grading your own homework afterwards.
Name it, or decide deliberately not to. A plain descriptive name beats a clever one nobody searches for.
Four weeks out: docs and changelog first
This is the part engineering teams tend to get right and marketing plans tend to skip, so lean into it. Write the docs page before the marketing copy. Docs force you to say exactly what the thing does, in what order, with what limits, and the marketing copy gets sharper when it can borrow that precision.
Draft the docs page with real steps and real limits, including what it does not do.
Draft the changelog entry on a permanent URL rather than a modal that disappears. A changelog is a running record of a product that is alive, and buyers doing diligence read it.
Capture real screenshots or a short screen recording from the product itself, not a mockup. Technical buyers can tell.
Link the three together: changelog to docs, docs to the feature page, feature page back to docs.
Docs and changelog pages are also often the pages that match what someone types when they search for exactly what your feature does, because they describe it literally rather than in benefits language. Treat them as launch assets, not housekeeping.
Three weeks out: the pages that change
Pricing page. If the feature changes which plan someone needs, the pricing page changes on launch day, not the week after. What your pricing page has to do before a demo still applies here: a buyer should be able to work out which plan they are on without booking a call.
Feature or landing page, for a product-sized launch. Lead with the positioning line, show the product, and link to the docs.
Homepage. Read the headline again. Does it still describe what you sell?
One expectation to set early: search will not deliver launch-day traffic. You can ask Google to crawl new pages with the URL Inspection tool or by submitting a sitemap, but crawling can take anywhere from a few days to a few weeks, and requesting it does not guarantee the page is included at all (sourced from Google Search Central). Get the pages live early, submit them, and plan for launch week traffic to come from email, your own channels and the people you tell directly.
Two weeks out: the customer email and CASL
Existing customers are the warmest audience a launch has, so write to them first and write plainly: what changed, who it is for, how to turn it on, and a link to the docs. One email, not a sequence. Segment it if only some accounts can use the feature.
A note on Canada's Anti-Spam Legislation (CASL). A launch announcement is very likely a commercial electronic message, which means it needs consent, clear identification of who is sending it, and a working unsubscribe mechanism. The unsubscribe has to keep working for at least 60 days after you send, requests have to be processed within 10 business days, and if consent is ever questioned, the onus is on you to prove you had it (sourced from the CRTC). Existing customers often fall under implied consent through an existing business relationship, but that consent has time limits set out in the Act, so check your list rather than assuming everyone on it qualifies. If you are not sure how your product email and marketing email should be split, where to start with CRM and lifecycle email walks through it. This is marketing guidance, not legal advice: for anything consequential, talk to counsel.
One week out: sales enablement for a team without a sales team
Whoever answers support tickets and runs demos is your sales team this week. Give them one page:
The positioning line, word for word.
The three questions customers will ask, with the answers.
What it does not do, stated honestly.
Whether it changes anyone's plan or price.
Then update the demo flow and any onboarding email that describes the old behaviour, and draft the founder's own post about it, in the founder's own voice. People follow founders more readily than logos.
Launch week: ship in the right order
Docs and changelog go live first.
Then the pages: feature page, pricing, homepage changes.
Then the customer email, so every link in it resolves.
Then social and community posts, spread over a few days rather than all in one hour.
Keep an eye on the support inbox. The first ten questions tell you exactly what the docs missed, and fixing the docs that afternoon is worth more than another social post.
Thirty days after: check the number
Compare the result against the number you wrote down six weeks ago. Not a new number you picked because it looks better.
Fold the support questions back into the docs.
Redirect or retire any temporary launch page so it does not sit there going stale.
Write five lines for next time: what slipped, what nobody owned, what you would start earlier.
When this gets too big for the team you have
This checklist is maybe two to three days of real work spread over six weeks for a feature launch, more for a product launch. If you are shipping one every quarter and the person running the checklist is also the person writing the code, something gives, and it is usually the docs and the email. That is the point where launch work I take on for founders earns its place: the Embedded retainer includes one end-to-end launch a quarter, so the work around the release has an owner who is not also shipping it.
So: what is the next thing you are shipping, and who owns everything around it?