Product launch
checklist.

A product launch checklist is the cross-functional plan that lists every task product, marketing, sales, and support must finish to ship — sequenced across three phases: pre-launch, launch day, and post-launch. Each workstream gets one directly responsible individual (a DRI), and the whole thing runs from one shared board instead of a stack of status meetings.

Launches fail in cross-functional ways. The build is ready but the docs are not. Marketing ships the announcement before sales has the deck. Support gets the first ticket about a feature they have never seen. None of those are hard problems — they are coordination problems, and a checklist with named owners solves them. This playbook is that checklist: the workstreams, who owns each one, the three phases task by task, and how to run all of it from a single b/launch board.

What goes on a product launch checklist?

A launch is never one team’s job. The checklist spans five workstreams, and the fastest way to drop a launch is to track one of them in a tool the others cannot see. Before you write a single task, confirm each of these has an owner and a deadline:

• Product & engineering. The build itself, the release toggle or feature flag, QA sign-off, rollback plan, and the metrics you will watch on launch day.
• Marketing. Positioning and messaging, the announcement (blog, email, social), the landing page, screenshots and demo video, and the press or community plan.
• Sales. The pitch deck, pricing and packaging, the one-pager, objection handling, and a heads-up to anyone with deals in flight that touch the new thing.
• Support & success. Help-center docs, canned responses, an escalation path to engineering, and a known-issues list so the first tickets do not turn into fire drills.
• Ops & legal. Pricing changes in billing, updated terms, any compliance or security review, and analytics or tracking wired up before launch, not after.

Who owns what? A DRI per workstream

“The team is launching” means no one is launching. Every workstream needs one directly responsible individual — a single name who is accountable for that lane, even when five people do the work. The DRI is not the person who does everything; they are the person who answers “is this lane ready?” at the go/no-go. A workable default split:

One person — the launch lead — owns the date and the go/no-go decision. Everyone else owns a lane. Put those five names at the top of the board so anyone can see, in five seconds, who to ping when their workstream is the one holding up the date.

Pre-launch: the weeks-before checklist

Pre-launch is where launches are won or lost. Most of this list runs in the two to four weeks before the date, in parallel across the workstreams. Copy it, assign each line to a DRI, and set a due date relative to launch day:

• Lock the launch date and the scope — what is shipping and, just as important, what is not.
• Write the positioning: the one-sentence value, the audience, and the three points the announcement and the deck both repeat.
• Build the announcement assets: blog post, launch email, social copy, screenshots, demo video.
• Ship the landing page and wire up analytics, UTMs, and conversion tracking.
• Finish QA and put the feature behind a flag so launch is a config change, not a deploy under pressure.
• Write the rollback plan: the exact step to turn it off and who is allowed to make that call.
• Enable sales: deck, pricing, one-pager, objection handling, and a dry run with one rep.
• Write the support docs and canned responses, and brief the support team on the known issues.
• Confirm legal, billing, and security sign-off — the slow approvals that quietly slip dates.
• Reserve the launch slug and build the board now — b/launch — so every asset above lands in one place as it is finished.
• Hold a go/no-go meeting 24-48 hours out: each DRI says ready or not, with a reason.

Launch day: the go-live checklist

Launch day should be boring if pre-launch was thorough. The work is flipping the switch in the right order and watching the right numbers — not finishing anything. Keep the team on one board and one channel, and run this in sequence:

• Final go/no-go confirmation from the launch lead — a clear go, in writing, in one place.
• Flip the feature flag or deploy, and verify the feature works in production from a clean account.
• Publish the announcement: blog, email, social — in the planned order, not all at once by accident.
• Flip the landing page and double-check every link, the pricing, and the signup flow.
• Tell the internal teams it is live: sales, support, and leadership, in the launch channel.
• Watch the launch-day metrics live — signups, errors, latency, support volume — on the board so everyone sees the same numbers.
• Triage incoming feedback and tickets against the known-issues list; escalate real bugs fast.
• Keep the rollback plan one click away and name who is watching for the abort signal.

Post-launch: the days-after checklist

The launch is not done when the announcement goes out. The week after is where you turn a spike into something durable and capture what to do differently next time. Do not skip the retro — it is the only part that makes the next launch cheaper:

• Monitor the metrics against the goal for the first few days, not just launch day.
• Triage and prioritise the feedback and bugs that came in; fold the real ones into the backlog.
• Follow up the announcement: a second email, a deeper post, replies to community threads.
• Update sales and support with what is actually landing and the questions that keep recurring.
• Close the loop with anyone who asked for the feature — they are your best early proof.
• Run a launch retro: what shipped late, which lane was the bottleneck, what to template for next time. Keep the notes on the same board.

How do you run the whole launch from one board?

A launch tracked across a spreadsheet, three Slack threads, and a slide deck is a launch with no single source of truth — which is how the docs end up unwritten and the deck ends up stale. The pattern that holds up is to put the entire launch behind one memorable shortcut. In BookSlash that is a board — a multi-tool canvas — sitting behind a single slug, b/launch.

The slug is a go link: a short, team-owned name that resolves from the address bar, Raycast, or Spotlight in around 40-50ms, so nobody has to hunt for “the launch doc” again. The board behind it holds the live pieces a flat spreadsheet cannot: a kanban column per workstream, the demo video embedded, the launch-day metrics charting in real time, the rollback runbook, and the go/no-go notes — all on one canvas the whole cross-functional team edits at once. One URL, everything attached:

• b/launch → the board itself, the one link in every launch invite and channel topic.
• b/launch-brief, b/launch-assets, b/launch-deck → the workstream destinations, pinned on the board.
• b/launch-metrics → the live dashboard everyone watches on launch day.
• b/launch-retro → the post-mortem, captured while it is still fresh.

Build one launch board and duplicate it per release — keep the five workstream columns, swap the assets. Because slugs are workspace-owned, b/launch always points at the current launch, the audit log records who marked each lane ready, and nothing vanishes when the PM who built it moves teams. The full pattern, with the board layout, lives on the launches use case.

Common launch-checklist mistakes

A handful of failure modes show up on launch after launch. Each is cheap to avoid once you have been burned by it:

• No single owner per lane. Shared ownership means the docs and the deck both assume the other team has it. Name a DRI for every workstream.
• Treating it as product-only. The build being ready is a third of a launch. Sales, support, and marketing need the same deadline, not a heads-up the day before.
• No go/no-go. Launching by assuming everyone is ready is how you ship with a broken signup flow. Make readiness an explicit, owned decision.
• No rollback plan. “We will figure it out” is not a plan. Write the off switch and name who pulls it before you flip anything on.
• Skipping the retro. Without a post-launch review, every launch re-learns the same lessons. The retro is what makes the next one faster.

Start small: write the five workstream lists above, name a DRI for each, and put them behind one slug your whole team opens. If the shortcut idea is new, the go links guide covers how slugs resolve, and the launches use case shows the finished board. One b/launch beats a stack of status meetings every time.