Launches deserve a process, not a spreadsheet

A launch is not an engineering event. Before something reaches customers it usually needs a design review, a privacy review, a security look, somebody in support to write the help article, somebody in marketing to decide whether to say anything, and now and then a lawyer. None of those people work on the launch. Any of them can stop it.

That is what makes launches hard. The engineering work has a home: a tracker, a board, a sprint. The approvals do not. They happen in chat threads and corridors, and the launcher learns what was required by being told, often late. The classic version is the privacy review discovered in the week the feature was meant to go out.

The usual fixes each solve part of it.

• The checklist doc. Somebody writes down the steps and every launch copies them. Within a quarter there are a dozen copies, each a little different, and none of them matches what the reviewers now want.
• The launch manager. One person who knows the process and chases everybody. It works until they are on holiday, or until the company ships more than one person can hold in their head.
• The tracker. A ticket per review. Now the reviews sit in an engineering backlog that reviewers never open, next to work they do not own.
• The weekly launch meeting. Good for decisions, expensive as a status report. Most of the hour goes on finding out where things stand.

What these share is that the process lives with the launcher, who knows it least. We think it belongs with the reviewers, who know it best.

The people who review a launch know what they need to see. So they should write it down, once, and own it.

In LaunchCal, every function that reviews launches is a functional team: design, engineering, privacy, support, whatever your company has. Each owns the steps it asks for, and each step says four things:

• Who reviews it: the functional team it belongs to.
• When it applies: Every time, Recommended or Optional. Keep the first list short; everything on it can hold up a launch.
• How long it takes: a typical duration, in days.
• Why it exists: a line of reasoning the launcher reads.

The last one matters more than it looks. A step with no reason reads as a tax. A step that says "PII and GDPR review" tells the launcher what the reviewer is protecting, and usually what to bring. Reviewers get better material, and launchers stop treating review as an obstacle to route around.

Running launches this way, through reviews owned by each function and a calendar anyone can read, is a practice we used at Google. LaunchCal is our version of it, for companies that do not have a launch team to keep the spreadsheet alive.

A launch has one fixed point: the day it is meant to go out. Everything else should be arranged around it.

When a launcher adds a launch with a planned date, LaunchCal copies the process's steps onto it and dates each one back from that day. Every review is due a week before the planned launch date, and starts as many days earlier as its typical duration. A privacy review that takes five days starts twelve days out. A user study that takes two weeks starts three weeks out.

Two things follow. The launcher does not need to know the process to follow it, because the checklist arrives already scheduled. And reviewers see dated work rather than a stream of requests. A step past its due date and still undecided shows its date in red, to everybody, which is a better prompt than another message in chat.

The week of margin is deliberate. A review that lands on launch day is a review nobody can act on. A denial a week out is an inconvenience. A denial on the morning is a missed date.

Once a launch has its steps, each one sits with its functional team and its reviewer. Reviewers work from a list of what is waiting on them, soonest due first, rather than from whoever messaged them last. From the queue they start a review, approve it, grant an exception or mark it not applicable; a denial is made on the launch's own page, next to everything the launcher wrote.

The launch's owners and stakeholders hear about every decision. Email goes out only for a denial or an exception, because those are the decisions that need a person to do something. The rest arrive in the app, where the launcher can watch the whole launch move without chasing anyone. When a review is stuck, the launcher nudges the reviewer from the step itself, so the reminder arrives with its context attached.

Exceptions deserve a word. Not every step fits every launch, and a process that cannot bend gets quietly ignored. The answer is not to let steps lapse by silence. An exception, or a step marked not applicable, is a decision somebody made, recorded on the launch where the next person to ask can find it.

Most launch arguments are arguments about the word ready. Engineering says it is done. Privacy says it has not seen it. Marketing is waiting for a date. Without a shared definition, ready means whatever the most senior person in the room says it means.

We define it in two places.

% to launch is the share of a launch's steps that have been settled: approved, given an exception or marked not applicable. A denial does not count. It is a decision, but it is not progress, and counting it would flatter the launch. A step still in review does not count either.

Press to launch! is the button that marks a launch as launched. While any step marked Every time is undecided or denied, it says how many are still in the way. You can launch anyway: a process should serve the launch rather than hold it hostage. But that takes a second, deliberate choice by a person, not a skipped line in a spreadsheet. When it does go, its owners, its stakeholders and every reviewer hear that it shipped, which is the least the people who reviewed it are owed.

Most people in a company never review a launch. They want to know what is going out and when: sales, support, the executive who will be asked about it on a call. For them the process can stay invisible, as long as its result does not.

LaunchCal keeps a calendar of launches and a timeline of every step, drawn from the same records the launchers and reviewers work from, so it is current without anyone maintaining it. Each launch also carries three artifacts: a press release written before launch, a dashboard during it, and the learnings after, so the story stays with the launch. Insights, a sentence each, gather across launches, so the next team inherits the lesson instead of rediscovering it.

If you change nothing else, try this, with or without software:

1. Ask each reviewing function what it needs from a launch, and write that down as steps, each with a reason.
2. Mark which steps are required, and keep that list short.
3. Give each step a typical duration, and date it back from the launch with a week to spare.
4. Make "this does not apply" a recorded decision, never a silence.
5. Agree that ready means every required review has an answer that lets the launch through.
6. Put the dates where everyone can see them, and keep the learnings with the launch.

None of that needs a tool. It needs a home that is not one person's memory. LaunchCal is ours, and the help article walks through setting up your process.