Three calendars decide whether a launch plan holds together

Most launch plans are one calendar with tasks on it. That shape hides the only question worth asking: whether the day you picked is a day on which anything can be learned.

Split the plan into three calendars instead. They run at different speeds, they have different owners, and when they disagree, the disagreement is the finding. A launch planning guide sets out the six short documents these three calendars need and the order they get written in.

What to take away

Calendar one: what must be true

Write conditions, in the past tense, as if the day has arrived and someone is checking.

A condition reads like this: the price is set and written down, and a person outside the team has completed the purchase path start to finish. The refund and delivery terms exist in one place a buyer can read, and the business is registered under the name on the page.

That last one has a lead time nobody plans for. The registration steps differ by state and by structure, which is why it belongs on a calendar rather than a task list.

The price condition is the one most often marked done while still soft. A number that has never been said aloud to a stranger is a draft, and pricing validation is the work that turns it into a condition you can check.

Two rules keep this calendar honest.

Each condition gets one owner, a person and not a team. And each condition gets a date by which it must be true, set backwards from the launch, not forwards from today. Backwards dating is what surfaces the item that needed six weeks and has four.

A condition that cannot be written as a checkable sentence is not a condition. It is an intention, and it belongs on the ask calendar or nowhere. The smallest set of conditions that still constitutes a real product is worked out in minimum viable offers; this calendar assumes that argument is already settled.

Calendar two: what you ask of other people

Everything that depends on somebody else's attention goes here, with the lead time that person needs rather than the lead time you would like them to need.

The supplier row is the one that turns into a legal problem rather than an embarrassment. If you take money for goods before they exist, the shipping window you state becomes an obligation.

The federal rule on order and shipment timing requires you to notify the buyer and offer a refund when you cannot meet it. Put that window on the truth calendar as a condition, not on the marketing page as a hope.

The point of separating this calendar is that you control none of it. Every item is a promise from a person who has other work. Ordering the asks by lead time, longest first, is the whole discipline, and it usually moves the launch date before anything else does.

Keep a column for what you have actually heard back. An ask you sent and have not had answered is not scheduled. It is hoped for.

Calendar three: what you will be able to see

This is the calendar people skip, and it is the one that decides whether the launch was a test.

For each day of the first two weeks, write what evidence will exist by day's end and where it will come from.

Track visits and their source, starts of the purchase path, completions, refunds, and questions arriving by email. Any of those can be zero, and a zero is readable. A day with no instrument pointed at anything is not readable.

Then check the lag on each. A signup you can see the same hour. A refund window that has not elapsed tells you nothing yet. A repeat purchase cannot exist for a cycle.

Writing the lag beside each item stops the day-three meeting where someone says the launch failed, when the only thing that has happened is that time has not passed. Designing a reading that can come back negative is the same work as designing an offer test, one step later.

If the observation calendar is empty for the first week, either the launch is a publicity event rather than a test, which is a legitimate thing to want, or you have not built the instrument. Say which. The pillar on launch planning works through what a launch is for before you pick a date at all.

Where the three calendars disagree

The disagreements are the useful part, and there are three common ones.

A condition is late and an ask has already been sent. Now you either move the date or launch into a promise you cannot keep. Decide which before the ask goes out, not after.

An ask has a lead time longer than the gap to the launch date. The date is already wrong; nobody has said so yet.

The observation calendar starts producing before a condition is met. This is the good failure: you can see something, and what you can see is that the thing being seen is not finished.

Running the review

Once a week, one sitting, in this order: conditions not met and their owners, asks outstanding and how long they have been outstanding, then what the observation calendar will show next.

Do not review tasks. Tasks are how conditions get met and they belong to their owners. A launch review that becomes a status meeting has stopped being a launch review.

The last review before the date has one question: is every condition met. If not, the choice is to move the date or launch knowingly short, and both are acceptable. What is not acceptable is discovering it on the day. The readiness questions are the same species of check applied to the person rather than the plan.

Common questions

How far ahead should the three calendars start?

They start when the longest ask starts, which is usually a supplier or an approval rather than anything you build. Work back from that, not from a round number of weeks.

Can a condition depend on another condition?

Yes, and when it does, write both dates. Chained conditions are where compression hides: two items each described as taking a week are a fortnight, and the plan usually has them on the same line.

What if we have no asks at all?

Then you are launching to people who already know you, which is a real launch with a small ceiling. Say so in the plan, and set the expectation for the observation calendar accordingly. A quiet result from a warm list is not evidence about a cold one.

Should the launch date be public?

Only after every ask with a long lead time has been answered. A public date converts your asks into obligations for other people, and they will remember which way that went.

Does this replace a project plan?

No. It sits above one. The project plan says who does what; these three say whether the date holds, and they are the only part worth reviewing weekly.