The 90 day pre-launch runbook, week by week

The order matters more than the list

A launch checklist that lists forty tasks in no particular order hides the one property of the work that decides the outcome: several of these tasks compound, and doing them out of sequence throws away the ones you already paid for. The tasks below are not unusual. The sequence is the part most teams get wrong, and it costs them weeks they do not notice losing.

Five dependencies run through the whole ninety days. Evidence comes before positioning, because positioning written without buyer language is a guess you then print onto every surface you own. Positioning comes before copy, since copy is positioning expressed in sentences, and reopening the positioning after the copy is written means rewriting the site, the emails, the deck, the onboarding and the sales script. Copy comes before build, because a site designed around placeholder text has to be redesigned the moment a real headline turns out to be nineteen words long. Surfaces come before seeding: there is no value in being named in a comparison roundup that links to a page which does not exist yet. And seeding comes well before launch, because third-party mentions need weeks to be crawled, indexed and absorbed into the sources that search engines and answer engines actually pull from. Seeding started in launch week is seeding wasted.

This runbook counts down. Week 13 is the first week of work, week 1 is the week before you go live, then launch week, then the first thirty days. It sits alongside the rest of the launch guides, and it assumes you have already read the launch readiness framework or can at least name the eight things a launch is judged on.

The whole runbook in one table

Each phase closes with one artefact and one decision. If the artefact does not exist, the phase is not finished, whatever the calendar says.

Weeks 13 to 10: evidence, and permission to continue

This phase exists to give you the right to spend the next ten weeks. It ends with a written decision, and that decision is allowed to be no.

• Twelve to eighteen buyer conversations with people who fit the target and owe you nothing. Ask what they did the last time they hit this problem, what they used and what it cost them. Do not describe your product until the last five minutes.
• Name the trigger event. Something happens in a buyer's month that makes them start looking: an audit fails, a contract renews, a person leaves. Write down what it is and how often it occurs, because that frequency is your realistic demand ceiling for the quarter.
• Find demand signals that do not contain your product name. Search volume for the problem and the category term, branded volume for the incumbents, recurring threads in the communities your buyers use, and what they spend on the alternative today, including the spreadsheet and the person maintaining it.
• Ask for pre-commitment. A waitlist of four hundred emails that has never been asked for money is weaker evidence than six paid deposits or three design partners with a signed scope. Ask early enough that a no still leaves you time to change course.

Write the decision on one page: what you learned, what you now believe, what would have to be true for this to fail, and whether you are continuing. Date it and send it round. When week 4 arrives and somebody proposes a pivot in a meeting, this page is what you argue against.

Weeks 9 to 8: positioning and the offer

Two weeks, and the output is a paragraph and a price. If that sounds thin, consider that every word written from week 7 onwards is downstream of it.

• Choose the category using the words buyers used unprompted in the conversations, even where their term is duller than the one you invented. Inventing a category is a multi-year exercise with a budget behind it.
• Write the headline so it says what the thing is, who it is for and what it replaces. Test it by reading it aloud to somebody who has no context and asking them to describe what you sell.
• Write the anti-profile. A specific, named list of who this is not for, detailed enough that it will cost you a deal. Sales teams that cannot say no in the first call spend the first quarter drowning in the wrong pipeline.
• Pick the pricing model and evidence it. What does the buyer spend today, what unit do they think in, and what did real people say when you named a number. The mechanics of this are in the guide on launch pricing, and the positioning work has its own guide on how to position a launch.

The gate is uncomfortable and worth enforcing: five people outside the company, given the positioning statement once, repeat it back correctly a day later. If four of them produce four different descriptions, you have not finished, and building the site now just means building it twice.

Weeks 7 to 5: build the surfaces with search foundations already in

The site gets built in these three weeks, and the search and measurement foundations go in during the build rather than in a remediation project six months later. Retrofitting indexability and schema onto a finished marketing site costs roughly three times what including them costs.

• Indexability. Staging behind authentication, production not carrying a leftover noindex or a disallow-all robots file. Check it the day the site goes live, then again on launch morning, because this is the most expensive one-line mistake in launch history.
• One canonical host with everything else redirecting to it permanently, and self-referencing canonical tags on every template.
• Core Web Vitals on the templates before the content lands, tested on a throttled mobile connection rather than your laptop.
• Structured data with a stable identifier. Organization and product nodes that reuse the same identifier everywhere, so the systems reading you build one entity rather than three partial ones, for reasons covered in answer engine optimisation for product launches.
• The category page that targets the term buyers use rather than your brand name, because nobody searches for a product they have never heard of.
• Comparison pages against the two or three alternatives named repeatedly in buyer conversations, written fairly enough that a reader trusts them. These pages get cited disproportionately by search results and assistants alike.
• The pricing page with actual numbers on it.
• Analytics and the activation event. Define the one event meaning a user reached value, instrument it, and watch it fire in production while there is still no traffic to hide a broken tag.

Run the launch readiness check at the end of week 5 rather than at the end of week 1. A weak score in week 5 is a work item; the same score in week 1 is something you have to live with.

Weeks 6 to 3: seed visibility while the build finishes

This phase deliberately overlaps the build, and the overlap is the point. The moment a real URL exists, seeding can start, and it needs every week it can get because the lead time is external and you cannot compress it.

• Get named in third-party sources. Roundups, comparison articles, newsletters read by your buyers, one or two podcasts, a guest piece where you have genuine expertise. Aim for mentions that describe the product in the same words your positioning uses.
• Claim the profiles. Review sites and marketplaces relevant to your category, a company page, the code host if you are developer-facing, and any industry directory your buyers browse. Fill them in properly; half-complete profiles rank and get read anyway.
• Establish the entity consistently. One legal name, one product name, one description sentence used verbatim across every profile, one canonical URL. Variation here is what produces three weak entities where you wanted one.
• Build community presence before you need it. Spend six weeks answering other people's questions in the two or three places your buyers gather, so that on launch day you post as a participant rather than as a stranger arriving with a link.

Take the lead time seriously. A mention published in week 4 has time to be crawled, indexed and picked up in the datasets and retrieval indexes that assistants draw on. The same mention published on launch day exists, but for your launch quarter it may as well not. Teams who discover this after the fact usually describe it as the most avoidable mistake of the whole cycle, and it is one of the patterns behind why product launches fail.

Weeks 2 to 1: assets and rehearsal

Nothing new gets started in these two weeks. The work is finishing, testing and rehearsing what already exists.

• Finish the day zero asset list three days early. Launch post, email to the list, a demo video under three minutes, screenshots at the sizes each channel wants, a one page summary for anyone who might write about you, an FAQ page, the in-app announcement and the changelog entry.
• Run a full dry run on a real mid-range Android phone on mobile data. Not a simulator, not your flagship on office wifi. Go from advert or link, through the site, through signup, through payment, to the activation event. Time it and write down every place you hesitated.
• Load test to five times expected peak, including the signup path, any payment webhook and whatever background job runs on account creation. Peak traffic on launch day is usually a two hour window, not a day.
• Write support macros for the ten questions you already know are coming, and decide who is answering, in which channel, at what hours.
• Write and schedule the trial-end sequence now, because in three weeks you will be busy and the first cohort will hit day fourteen regardless.

Feature work stops at the end of week 2. Anything proposed after that goes on a list for the first sprint after launch, and the list is genuinely honoured, which is what makes the freeze survivable for the engineers agreeing to it.

Launch week: publish in order, then stop touching things

Launch week has one job: execute the plan you already made without improvising. Every hour spent deciding something during launch week is an hour not spent replying to a real prospect.

• Monday. Re-check indexability, validate the structured data, smoke test analytics and the activation event end to end, confirm payments in live mode. Publish nothing.
• Tuesday. Brief everyone. Who answers what, in which channel, and what the escalation path is when something breaks at nine in the evening.
• Wednesday, launch day. Publish in a fixed order: your own site and blog first so every link points at a live canonical page, then the email list, then the communities where you have been present for six weeks, then the outreach you seeded in weeks 6 to 3.
• Nothing changes on launch day. No copy edits, no pricing changes, no deploys except reverts. Keep a running list of everything you want to change and ship the batch on Thursday, when you can watch what it does.
• Thursday and Friday. Reply to everything, and log every question verbatim in one document. That document is the highest quality research you will get all year, and it decays within a fortnight if nobody writes it down.

Days 1 to 30: measure, then ship the second act

The measurement plan was written before launch, which is what makes the first month readable. Deciding what counts as success after seeing the numbers is how teams talk themselves into comfortable conclusions.

• Report against the plan. Traffic by source, signup rate, activation rate, time to first value, qualified conversations, and paid conversions where the cycle is short enough to show any.
• Ship the second act around day 10 to 14. A customer story, a data piece, an integration, a substantial feature held back deliberately. The goal is a traffic graph that steps up and holds rather than spiking and returning to where it started.
• Keep seeding. The mentions you secure in week +2 pay off in month three, in the same way the ones from week 6 paid off this month.
• Hold the 30 day review, already in the calendar, with the people who can actually change positioning, price or roadmap in the room. A review attended only by people without authority produces a document and nothing else.

What to cut if you have 30 days rather than 90

Plenty of launches get thirty days, usually because the date was set by a conference, a funding milestone or a competitor. The compression works, but only if you cut whole phases rather than shaving every phase to a third of its length.

What survives: five buyer conversations compressed into the first week; the positioning statement and the five-outsider test, which costs a day; indexability, canonical host, analytics and the activation event, which are cheap now and expensive later; one category page and one comparison page against the alternative buyers name most; the day zero assets; the dry run on a real phone; and the 30 day review.

What goes: the pre-commitment stage, the full comparison page set, the load test at five times peak, which becomes twice peak, and most of the seeding programme. Be clear-eyed about that last one, because you cannot buy back crawl and index lead time. A thirty day launch will be close to invisible to answer engines during its first quarter, so start the seeding on day one after launch and accept that its benefit arrives in month three or four.

The one phase that cannot be cut is the evidence phase, even in its compressed form. Skip it and the remaining twenty-nine days are spent building surfaces, assets and a price around an assumption nobody has tested, which is a more expensive way of finding out the same thing you could have learned in week one for the cost of five phone calls.