Launch Plan

Some launches turn the feature on and nothing happens. The code shipped on schedule, it works, and the only people who know about it are the team that built it, so usage stops at 30 people in week one. Months of work go quiet.

The opposite failure is just as common. The announcement email goes out three hours before the feature is enabled, so everyone who clicks the link lands on an empty screen. Sales tells a customer it ships next week, and it's already live that morning. When every team carries only its own dates, this repeats every quarter.

Both failures have the same cause: a release is not one team's work, and nothing collected its moments onto a single page. Engineering held the deploy date, marketing held the content calendar, sales held the customer meetings. A launch plan lays those scattered moments on one timeline and decides in advance what goes first and what follows.

It's a single page of items, each with a date and a name attached. Six groups make up the standard shape.

1. The reference moment. Pin the go-live date and time in one line. Every other date is set relative to it, so if this one moves loosely the whole document stops meaning anything.
2. What to say. Decide the sentences this release is announced with. The one-line summary and the three main claims come down from the messaging document, which is where a team keeps the core phrasing for the product. The rule is to reuse it rather than write new lines here.
3. What goes out, and when. The blog post, the announcement email, the landing page, the in-product notice, the press release, the webinar — each with its own date. Order matters. The email goes after the feature is live, and the page has to be up before the email.
4. Who hears early. The accounts you contact before the public announcement: beta users, large customers, partners, journalists. Letting a major account learn about a change from a mass email puts their account manager in a bad position.
5. Internal readiness. Sales enablement, which hands sales the materials, and internal enablement, which gets support up to speed, both have to finish a few days before go-live.
6. The verdict. Write down in advance what counts as success — 30 percent of paid teams turning it on at least once in the first two weeks, 5,000 visits to the landing page — as a number with a deadline.

Whether the preparation is finished is a separate question, owned by the launch checklist. The checklist asks done or not done. The launch plan decides when, and by whom, things go out. Merge the two documents and the preparation items crowd out the dates.

The author is the product marketer, or on teams without that role, the product manager or growth lead. They don't fill every line themselves. Content writes the blog post, engineering handles the in-product notice, sales fills in the customer meetings. The owner's job is checking that the dates interlock, and moving everything downstream when one of them slips.

The readers are marketing, sales, support, and engineering, and the document works best when each of them can read only their own rows. The common format counts days out from go-live as day zero: confirm the early-access list at day minus 14, hand over sales materials at minus seven, enable the feature on the morning of day zero and send the email that afternoon, check the numbers at day plus seven.

This isn't a document you write once and close. Open it weekly until launch and move the rows that slipped. When the reference moment shifts by a week, fifteen other rows have to shift with it — and if nobody does that adjustment, the email alone still goes out on its original date.

"The webinar date is still blank on the launch plan. Who owns that?"

Looking for the person who should fill an empty row.

"Go-live moved a week, so please push the whole launch plan back."

The reference moment changed, so every dependent date needs adjusting.

"For this one I put twelve enterprise accounts on the early-notice list."

Confirming which customers get contacted before the public announcement.

When Pagedeck shipped document history, Ravi owned the plan. Go-live was set for Tuesday at 10 a.m. Two weeks out he confirmed the early-notice list: 30 teams from the beta plus 12 large accounts. One week out he handed Sofia the sales materials and the pricing explanation. On the day, the in-product notice went up first and the announcement email went at 2 p.m.

Holding the email until the afternoon was deliberate. It gave the team two hours after go-live to watch for problems and hold the send if anything looked wrong. The previous quarter that gap caught a bug and the email moved by a day. The same document carried a customer story scheduled for three weeks after launch.

The most common reading is that this is the document where the launch date gets decided. The first line is a date, so it looks that way. But the date is only the peg the other fifteen rows hang from, and the substance is what hangs there in what order. Set the date, leave the rest blank, and you reproduce exactly the situation where customers write in on launch day and support has never heard of the feature.

Treating it as a plan that ends at go-live is the other mistake. The word launch points at a single moment, so the assumption is natural. But people take time to notice a new capability, and one announcement on day one means most of them never register it. So the plan covers the two to four weeks after go-live as well: follow-up content at week two, a customer story at week three, a numbers review at week four. Leave that stretch empty and the spike from launch day is gone by the third week.