Launch Checklist

Missing pieces surface on launch day in the same shape every time. The people who built it treat the moment the code goes out as the launch; the people who sell it and the people who answer the phone hear about it from customers. The feature is live and two engineers are the only people in the company who can explain it.

Pagedeck learned this shipping permission controls. Questions started arriving the afternoon it went live — how do I make this admin-only? — and the person answering them didn't know the feature existed. The help article was empty, and the pricing page said nothing about which plan it started on. The feature itself was built well. What the day produced was 40 apology emails.

The cause isn't laziness. The work is spread across several teams and the list of it isn't written down anywhere, so no one team can see the shape of what is left. Everyone did their own part and nobody held the whole. A checklist pulls the scattered items onto one page and creates a moment, before launch, where missing ones can be found.

Items usually fall into five groups, each answering a different question.

1. How to undo it. Write down how the thing gets turned off before anything else. Does a feature flag switch it off on its own, or does it take a rollback to the previous version, and who makes that call. A feature flag is a switch that turns a capability on and off while the code stays deployed.
2. Everything the user reads. Release notes saying what changed, a help article explaining how to use it, and the wording inside the product itself. The documentation has to be live at the moment of launch. Someone who sees the feature, searches for it, and finds nothing turns straight into a support ticket, which costs more to answer than the article would have cost to write.
3. Price and entitlement. Which plan it starts on, whether the pricing page reflects that, and how existing contracts are treated. When something that was free moves behind a paid tier, advance notice belongs in this group too.
4. Internal readiness. Whether sales and support can explain the feature. Internal enablement owns this item, and a single page of likely questions with answers is the minimum bar.
5. External announcement and the verdict. When the page, the email, and the posts go out is scheduled by the launch plan. Alongside it, write down in advance how this launch will be judged. Something like "20 percent of team accounts turn it on at least once within two weeks" — a number and a deadline — keeps the argument from happening later.

Every item carries a name and a date. Items without a name don't get done, and a date of "before launch" is the same as no date at all. The length of the list is set by the launch tier: the top tier fills all five groups, while a one-line copy change keeps only groups 1 and 2.

The list is owned by one person — the product manager or product marketer responsible for that launch. Owning it isn't the same as filling it. Engineers write the undo path, a writer or PM fills in the help article, support drafts the question-and-answer page. The owner's job is finding the empty cells and asking about them.

The readers are everyone involved in the launch. The moment it actually gets opened is a short review meeting a day or two before go-live. The owner reads the items top to bottom and each owner answers done or not done. When something comes back not done, one of two things gets decided on the spot: move the date, or ship without it and write down who covers the gap and how. Both are acceptable answers. What isn't acceptable is leaving the meeting with the cell blank and no decision attached to it.

Turn it into a document where nothing ships until every box is ticked and it becomes a formality fast. The judgment belongs to the owner, not to the list. Most teams make one exception for the undo path. Other gaps can be filled after launch; a feature that shipped with no way to turn it off leaves nothing to fill the gap with when something breaks.

"The help article and the support Q&A are still blank on the launch checklist."

A notice that two item owners owe an answer before go-live.

"This one's tier 3, so it's release notes only and we skip the rest."

The launch is small, so the list is being used in its short form.

"If the undo path isn't written down, this isn't going out today."

Unlike the other items, this cell can't ship empty.

Pagedeck built its list after the permissions incident. Mia owns it and books a 15-minute review the day before go-live. On a later launch Theo answered that the feature flag was in place but only engineers could flip it, which meant nobody on call could turn it off at night. That surfaced in the meeting and go-live moved by a day.

In the same meeting Sofia pointed out that the feature was top-tier only while the sales deck said it was available on every plan. Ship that and free-plan customers go hunting for something they can't have, and support apologizes for the gap between the deck and the product every time. That's the kind of hole a list catches — invisible in the code, invisible to tests.

The most common mistake is assuming a longer list is a safer one. Something got missed and caused an incident, so the instinct is to add items. But require a 20-item list for a one-line copy change and within two months people open the list, tick everything, and close it. The same reflex then shows up on the launches that matter, and the list stops preventing incidents and starts serving as the record of who ticked what.

Confusing it with quality assurance (QA) is common too. Both happen before shipping, so they look like the same activity. QA asks whether what was built behaves as intended. The checklist asks about everything outside that. A flawless feature still fails as a launch if the pricing page is stale, the documentation is missing, or nobody in support knows about it. Merge the two and "testing is done" becomes a reason to skip the other four groups entirely.