Product Launch Plan

You make sure a launch lands: the right people hear about it, the site, sales and support are ready on the day, and you know afterwards whether it worked. The size of the effort matches the size of the news. A strong launch plan is a dated checklist with named owners and a single goal, not a mood board.

When to use

• "We're launching [product / feature / plan] on [date]. What do we need?"
• "Plan the release of the new pricing."
• "Is this big enough for a press push?"
• "What goes out on launch day, and in what order?"
• Any change customers will notice: new product, major feature, new market, pricing, rebrand.

What you need

• What is launching, for whom, and the date (or date range). Confirm the product will be ready: ask the product owner with ask_teammate.
• Positioning for the launch: who it is for, the alternative it beats, proof. If there is none, write a short version first (see also positioning-and-messaging).
• The launch goal and one primary metric (signups, trials, revenue, upgrades, waitlist joins), plus the baseline.
• Owned channels and their size: email list, blog, in-app messages, community. Access through connected apps (Mailchimp, HubSpot, Google Analytics) or the owner's signed-in browser.
• Who can do what: design, copy, product demo, sales, support. Their availability across the countdown.
• Any embargo, legal review or partner approvals required.
• If neither connected apps nor the owner's browser give you the numbers, ask the owner with clarify for list sizes and baselines, and mark any estimate as such.

Method

1. Pick the launch tier. Size the effort to the news, judged from the customer's side:
   • Tier 1: new product, new market, major repositioning. Full plan, all channels, press and partner outreach, sales training. Countdown of 6 to 8 weeks.
   • Tier 2: significant feature or plan change existing customers will care about. Owned channels plus selected rented ones, sales and support briefed. Countdown of 2 to 4 weeks.
   • Tier 3: improvements and small features. Changelog, in-app note, a line in the newsletter. A few days. Over-launching small news trains the audience to ignore you; under-launching big news wastes it.
2. Write the one-page launch brief (template in references/launch-kit.md): what it is, who it is for, why now, the problem and proof, the one message, the goal and metric, the date, the owners, what is out of scope.
3. Plan channels as owned, rented and borrowed. Owned (email, site, blog, in-app, community) is where you have direct reach and should get the most care. Rented (social platforms, marketplaces, app stores, paid ads) gives reach you do not control; use it to bring people back to owned channels. Borrowed (partners, newsletters, podcasts, press, creators) gives credibility; line it up weeks ahead. Pick channels by where the best-fit customer pays attention.
4. List the assets per channel: landing page or updated product page, announcement post, email to customers, email to prospects, in-app message, demo video or screenshots, social posts, sales one-pager and talk track, support help article and FAQ, press note if Tier 1, pricing page changes. Each asset gets an owner and a due date.
5. Build the countdown backwards from launch day (T-minus schedule in references/launch-kit.md). Leave a buffer: assets due at least 3 working days before launch for Tier 1 and 2.
6. Set up measurement before launch. UTM-tagged links per channel, conversion events tested in Google Analytics or the product analytics tool, a baseline for the primary metric, and a simple dashboard or sheet. If tracking is broken, results cannot be judged.
7. Run the go/no-go check 2 to 3 days before (checklist in references/launch-kit.md). Product works in production, pages live behind a flag or ready to publish, emails tested, support trained, tracking verified, approvals in. Any red item means you move the date or cut the scope with the owner's agreement, not that you launch anyway.
8. Write the launch-day runbook: a timed sequence (for example 09:00 site live, 09:15 customer email, 09:30 blog and social, 10:00 partner posts), who presses each button, who watches support and social for problems, and the rollback plan if something breaks.
9. Get approval to send. Every external action on the day (emails, posts, press notes, partner messages) needs the owner's explicit go-ahead, given once for the agreed runbook or item by item, as the owner prefers. Then schedule it with the tools the owner uses, and set cronjob reminders for each step.
10. Sustain and measure. Plan the follow-up for weeks 1 to 4: customer stories, a webinar or demo, answers to the top questions, a reminder email to non-openers. At day 7 and day 30, report the primary metric against target and baseline, by channel, plus what you learned.

Output

• Launch brief (one page).
• Asset list: asset, channel, owner, due date, status.
• T-minus timeline from start to day 30.
• Go/no-go checklist with status.
• Launch-day runbook with times and owners.
• Measurement plan: metric, baseline, target, UTM scheme, where to read results.
• Day-7 and day-30 reports when the time comes. Put the countdown and the go/no-go status on a show_card so the owner sees red items at a glance.

Checks before you finish

• The tier matches the customer value of the news, and the effort matches the tier.
• One primary goal and metric with a baseline and target.
• Every asset has an owner and a due date before launch day.
• Tracking links and conversion events have been tested, not just created.
• Support has the FAQ and help article before launch day.
• External sends are marked as waiting for the owner's approval until it is given.
• Claims in launch copy match what actually ships on the day.

Pitfalls

• Announcing what is not live. Launch copy must describe what customers can use on the day. Coordinate dates with the product team, and keep anything "coming soon" clearly labelled.
• One-day thinking. Most of the result comes from preparation and the follow-up weeks. Plan both.
• Forgetting existing customers. They are the most likely to adopt and to tell others. Email them first, with what changes for them.
• No support briefing. A launch that floods support with unanswered questions damages trust. Brief support and publish the help article first.
• Untracked links. Without UTMs and tested events you cannot tell which channel worked. Set them up before the go/no-go.
• Fake urgency. No invented scarcity or countdowns that reset. Use real deadlines and real offers only.
• Sending without a go-ahead. Never send emails, publish posts or contact press and partners without the owner's explicit approval.