Audits a launch plan for the two ordering errors that sink most of them: long-lead items started too late, and one-shot moves spent before they can convert.
We have not measured this one. It is published untested, and the number it would need to beat is whatever a strong model produces when you paste a launch plan in and ask what is wrong with it. That baseline is not weak. Generic launch advice is one of the things a good model does well unprompted.
What the file carries that generic advice does not is a dependency order with lead times attached. It says that relationship outreach has a first-contact date roughly six to eight weeks before the ask, and that outreach beginning in launch week is structurally a cold ask no matter how good the email is. It says that anything with a third party in the loop is scheduled backwards from that third party's queue rather than forwards from when you want it live, and it gives the list of things that usually have such a queue. It carries an inventory of one-shot moves, the announcement email, the community post, the first-look exclusive, the personal network ask, with a precondition attached to each: measurement live, page converting, product stable. It turns goal setting into arithmetic, one number and a date decomposed backwards into per-channel inputs with the assumed conversion rates written down so they can be wrong out loud. And it carries a scope-cut decision rule with an explicit branch for when you cannot tell whether something is ready, which resolves toward moving the date rather than shipping.
Who it is not for. If you are launching to an audience of under a hundred people you already speak to weekly, twelve weeks of sequencing is theatre. Send the email. If your launch is one blog post and a tweet, this is overkill and will make the work feel larger than it is. It earns its place when there are several channels, at least one third party with a queue, and a date somebody outside the team has been told.
Measuring one skill honestly costs about twenty model sessions: five runs with it, five without, on real material, each output graded alone by a session that is not told the other arm exists, against a rubric written by somebody who never saw the skill. We have not spent that on this one yet, so it ships labelled rather than ships silently.
How it would be measured. Three invented but realistic twelve-week launch plans, each carrying a fixed set of planted sequencing defects: outreach beginning in launch week, an app store submission scheduled inside its own review window, a whole-list email sent before tracking exists, and a goal stated with no decomposition. Graded against a rubric written from the plans alone by an author who has not seen the skill. Objective spine is whether each planted defect is named and correctly attributed to ordering, so Tier A.
The hard part is building material an objective rubric can grade. A launch plan is a document with no single correct answer, so a fair test needs plans with defects planted deliberately: outreach starting in launch week, a store submission booked inside its own review window, a whole-list email scheduled before analytics exist, a goal with no decomposition. That is buildable, and it is Tier A, but it takes three plans written to feel real rather than obviously broken, which is slower than it sounds.
The honest risk is the control. Asked what is wrong with a launch plan, a strong model already flags thin timelines and missing metrics. The specific claim here is narrower: that it finds *ordering* defects, and correctly says which item blocks which. That is what the rubric would have to isolate.
The rule that decides pass or fail was written down before any run was executed and it does not move afterwards. It is in the method note on the hub, along with the full results table including every skill that was tested and cut.
Stated plainly, because a skill that claims everything is useful for nothing.
name and description in the file's frontmatter, so you can also invoke it by name.A competent person who has run three launches will beat this in an hour, because they carry the lead times in their head and they know which of your suppliers is slow. If you have that person, use them and skip this.
A dependency-aware project tool is better at the ongoing job. Enter the plan, mark the dependencies, and let it tell you what slips when something moves. What a project tool will not do is tell you that an item is in the wrong place to begin with, because it only knows the dependencies you typed in, and the ones people forget to type in are exactly the ones this audit is looking for.
The model with no skill at all is a real alternative here and may be most of the way there. Paste the plan, ask what is out of order, ask what has a queue in front of it, and ask what you only get to do once. If those three questions get you what you need, you do not need the file.
--- name: launch-plan-audit description: Audits a launch plan for sequencing defects rather than missing activities. Rebuilds the plan backwards from the date by lead time, finds long-lead items started too late and one-shot moves spent before their preconditions are true, checks that the goal decomposes into per-channel inputs with stated conversion rates, tests for single-channel dependency, runs a structured pre-mortem, and checks for a freeze point and a day-after plan. This skill should be used whenever a launch plan, GTM timeline or release runway exists as a document and a date has been set. --- # Launch plan audit ## The claim this skill is built on A launch plan is usually written as a list of things to do, ordered by how important each one feels. It should be written as a dependency graph, ordered by lead time. Launches that underperform mostly fail for one of two reasons, and both are ordering errors rather than effort errors. **The first: work with a long lead time was started too late.** A review queue, an approval, a translator, a printer, a security questionnaire, a writer's editorial calendar. None of these move faster because you are enthusiastic, and none of them can be compressed by working a weekend. **The second: moves that only work once were spent too early.** The announcement email to your whole list. The post to the community you actually belong to. The first-look offer to a publication. The founder's personal network ask. Each can be used once per launch. Spent at a moment when the page did not convert, the product was not stable, or the tracking was not live, it is gone, and it does not come back because you fixed the page afterwards. So the audit does not ask whether the plan contains the right activities. It nearly always does. It asks whether each activity starts at a time set by its own lead time, and whether each one-shot move fires after the things it depends on are true. ## The order to run the audit in Run these in order. Steps 1 and 2 change what the rest of the audit is even about, so running them late wastes the pass. 1. **Goal arithmetic.** Does the goal decompose into inputs? 2. **Lead-time sort.** Rebuild the plan backwards from the date. 3. **One-shot inventory.** What can only be spent once, and does it fire after its preconditions? 4. **Channel concentration.** What share of the goal rides on the single largest channel? 5. **Pre-mortem.** Assume it failed. Does the plan address any of the three most likely causes? 6. **Freeze point.** Is there one, is it dated, and is "new" defined? 7. **The day after.** Does the plan continue past launch day at all? ## Step 1. Goal arithmetic, not aspiration A goal that does not decompose is a wish. Ask for one number and one date, then work backwards through every conversion step until you reach a quantity of raw inputs somebody has to actually produce. Take a goal of 500 paying customers within 90 days of launch, at a price of £20 per month. - 500 paying customers, at an assumed trial-to-paid rate of 25%, requires **2,000 trials**. - 2,000 trials, at an assumed visitor-to-trial rate of 3%, requires **around 67,000 visits**. - 67,000 visits in 90 days is **roughly 740 visits per day, every day, including the eighty-nine days that are not launch day**. The point of writing it out is not the final number. It is that every assumed rate is now on the page where it can be challenged. If nobody in the room can say where 25% came from, that is the finding. If the site has never seen 740 visits in a day, the plan needs either a channel that produces that or a smaller number. Then decompose the 67,000 by channel, and sanity-check each line against something already known: - Search: how many pages ranking, for what, at what current click volume? A site with no rankings does not produce 20,000 search visits in 90 days. - Email: list size times an assumed click rate. If the list is 800 people, it produces hundreds of visits, not tens of thousands, however good the email is. - Community and social: reach times an assumed click rate, and reach is a number you can look up rather than hope for. - Paid: budget divided by cost per click. This one is honest arithmetic and it is usually the line that reveals the goal needs money nobody has allocated. - Partners and press: this line is nearly always the fictional one. If it carries 30% of the goal and no partner has yet agreed to anything, the goal is not decomposed, it is decorated. **Write the assumed rates into the plan document.** A rate that lives only in somebody's head cannot be found to be wrong later, which means the post-launch analysis will blame execution. ## Step 2. Rebuild the plan backwards by lead time Take every item and ask: what determines its start date? For anything with a third party in the loop, the answer is the third party's queue, not your preference. Items that usually have a queue, with the question to ask about each: - **App store or marketplace review.** What is the current published review time, and what is your own worst case from last time? Submit with a buffer that assumes at least one rejection and one resubmission. - **Legal, security or compliance review.** Take the stated internal turnaround and treat it as a floor. Whatever the process is, it has a person in it who has other work. - **Customer case studies and quotes.** The long pole is the customer's own legal or communications approval, and it is out of your control entirely. - **Anything printed or physical.** Production plus shipping plus a reprint if the first proof is wrong. - **Translation and localisation.** Including the second pass after the copy changes, which it will. - **A new sending domain or a large increase in send volume.** Sending reputation is built over weeks of increasing volume, not switched on. A cold domain used for a large launch send is a launch send in the spam folder. - **Directory, marketplace and integration listings** with human review. - **Writers and editors.** Publications with any planning at all are working weeks ahead. A pitch in launch week is a news pitch and needs actual news to survive. The rule: **schedule by lead time, not by desire.** If an item takes six weeks and you want it live at T-2, it starts at T-8, and if T-8 has already passed, that item is not in this launch. Say so now rather than discovering it in week ten. ## Step 3. The twelve-week runway A twelve-week shape, with what each item depends on and what it blocks. Adjust the absolute weeks to your runway, but do not reorder them. ### T-12 to T-10: measurement, positioning and arithmetic - **Analytics and event tracking installed, then verified with a real test conversion end to end.** Depends on: nothing. Blocks: every paid campaign, every landing page test, and every claim you will later make about which channel worked. This is first for one reason: a campaign that ran before tracking existed produces a number nobody can act on, and you cannot retrofit it. You will be left arguing about attribution for a quarter over a week of spend. - **The goal decomposed, from step 1.** Depends on: nothing. Blocks: budget allocation and channel selection, because you cannot choose channels before you know how much each must carry. - **Positioning and the one-sentence claim settled.** Depends on: nothing. Blocks: every asset, every pitch and every landing page, all of which have to say the same thing. - **The list, started now.** Depends on: a page that can collect an address. Blocks: the launch email. Build the list before there is anything to announce to it, because a list assembled in launch week is a list of strangers with no relationship and poor deliverability behind it. ### T-9 to T-7: long-lead submissions and the first contact - **Everything with a queue enters its queue.** Depends on: a build or an asset that is good enough to submit. Blocks: launch day itself for anything user-facing. - **The relationship list is built: name twenty to thirty writers, community moderators, and potential partners who plausibly care.** Depends on: positioning. Blocks: all outreach. - **First contact, with no ask in it.** Depends on: the list. Blocks: the ask at T-2. This is the single most commonly inverted item in the whole plan. Outreach that begins in launch week is a cold ask from a stranger. Outreach that began seven weeks earlier is a note between two people who have spoken before. The mechanism is not politeness, it is that the second one gets read. - **Content that needs to accumulate starts publishing.** Depends on: positioning. Blocks: any search traffic in the goal decomposition, because indexing and ranking are not launch-week activities. ### T-6 to T-4: assets, and the honest version of the stability problem - **Second contact with the relationship list: send something useful with no ask.** Depends on: first contact. Blocks: the ask. - **Demo video, screenshots, and documentation.** Depends on: a product stable enough that the recording will not be obsolete. This is the dependency that gets fudged. **The branch for when the product is not stable at T-4:** do not record the full demo. Record only the parts that are frozen, and script the rest so it can be captured in a single afternoon later. Then set a hard decision date at T-2: if the unstable parts are still moving at T-2, the launch asset ships showing only what is frozen, and the plan drops any claim that depends on the rest. Re-recording a full demo in the final week is the classic way to lose the final week. - **Landing page built and, if you have any traffic at all, tested.** Depends on: measurement, positioning. Blocks: every one-shot move. - **Pricing and checkout tested with a real transaction, including a refund.** Depends on: nothing but the build. Blocks: everything, quietly. ### T-3 to T-1: cashing in, and the freeze - **The ask.** Now the outreach converts into commitments: a review, a mention, a co-marketing slot, a moderator's blessing to post. Depends on: two prior contacts. Blocks: launch-day coverage. - **Embargoed briefings, if any.** Depends on: the ask, and a product that will actually be live. - **Warm-up sends to the list.** Two or three emails before the announcement, so the announcement is not the first thing they have heard from you in three months. Depends on: the list existing since T-10. - **The freeze point, at T-1.** After this date nothing new enters the launch: no new feature, no new page, no new channel, no new asset. Define "new" explicitly, because everyone will argue: new means anything not already written down in the plan on the freeze date. Fixes to things already in the plan are allowed. Additions are not. Without a stated freeze, the final week is spent on the thing somebody thought of on Tuesday, and the things that were planned go out unrehearsed. ### Launch week - **Order the one-shot moves so the highest-value one fires when the page is known to work.** If the plan sends the whole-list email at 9am on day one and the checkout breaks at 9:20, that move is spent. Where you can, fire a smaller move first, watch the funnel for an hour, then fire the big one. - **Somebody is on support, not on the launch.** A launch-day support queue that goes unanswered converts an interested visitor into a cancelled trial. ### T+1 to T+4: the part almost every plan omits Most plans end at launch day. This is where most of the remaining value is, because a launch produces a one-off spike that decays within days, and the whole question is what is left after it. - **The follow-up sequence to everyone who arrived and did not convert.** They are the largest and most qualified group you will have all quarter, and after two weeks they are strangers again. - **The retargeting audience that only now exists.** Before launch you had nobody to retarget. Now you do. If this was not set up before launch, the audience is not being collected during the spike, which is when it is cheapest to build. - **The second wave.** Everyone who said "send me something when it is live" gets that, in the week after, and this converts better than launch-day noise because it is not competing with launch-day noise. - **A retrospective against the arithmetic from step 1**, comparing the assumed conversion rates to the observed ones. This is the only moment those assumptions can be corrected while anyone still remembers them. - **The baseline comparison, which is the real result.** Not the launch-day number. Compare the week before launch to week four after launch. If they are the same, the launch produced a spike and no channel. That is a normal outcome and it is worth knowing rather than celebrating. ## Step 4. The single-channel rule For each channel, compute the share of the goal it carries, from the step 1 decomposition. If one channel carries more than roughly half the target, it is a single point of failure. The arithmetic that makes this a rule rather than a feeling: if a channel carrying 70% of the goal underdelivers by half, you miss the total by 35%, and no other channel has the headroom to absorb that in the launch window because the others were sized for their own share. If the largest channel carries 30%, the same underdelivery costs 15%, which is recoverable. The channels most often over-weighted are the ones you least control: a single launch-day aggregator, one publication, one large partner's audience, one platform's algorithm. Ask of each: what happens if this simply does not happen? If the answer is "the launch does not happen", the plan has one channel and a lot of decoration. ## Step 5. The pre-mortem Do this as a written exercise, not a discussion, because the first person to speak sets the answer for everyone else. 1. State the premise: it is four weeks after launch and the result is 20% of the goal. 2. Everyone writes down, **independently and before any discussion**, the three most likely reasons. 3. Collect them. Cluster. Take the three most frequently named. 4. Go through the plan line by line and identify which line addresses each of the three. 5. For any cause with no line addressing it, either add one or write down explicitly that you are accepting the risk and why. Step 5 is the whole exercise. A pre-mortem that produces a list of fears and no changes to the plan has cost an hour and bought a feeling. ## Step 6. The decision rule for cutting scope when the date is fixed Sort every remaining item into three tiers: - **Tier 1, makes the promise true.** Without it, the sentence you are going to say on launch day is false. - **Tier 2, makes the promise credible.** The claim survives without it, but a sceptical visitor has no reason to believe you. - **Tier 3, makes it pleasant.** Polish. Then apply the rule: - **The item is tier 3.** Cut it. Do not discuss it further. - **The item is tier 2.** Cut it, and write down what the launch now cannot prove, so that the post-launch conversion rate is read with that in mind. - **The item is tier 1.** Do not cut it. **Move the date.** Cutting a tier 1 item ships a launch whose central claim is not true, which costs more than a delay, and costs it in the one place you cannot buy back, which is the first impression of the people who cared most. - **You cannot tell which tier it is.** Apply the announcement test: write the launch sentence out, with the item removed, and ask whether it is still true. If it is, the item is tier 2 or 3. If you still cannot tell after that, **treat it as tier 1 and move the date**, because the cost of being wrong in that direction is a delay, and the cost of being wrong in the other direction is a false claim in public. ## Worked example, compressed A plan for a small business invoicing tool, twelve weeks out, goal stated as "a strong launch and good early traction". **Step 1, goal arithmetic. Fail.** "Strong" is not a number and there is no date beyond launch day. Forced into arithmetic, the team lands on 300 paying customers in 90 days at £15 per month. That decomposes to 1,200 trials at an assumed 25% trial-to-paid, and 40,000 visits at an assumed 3% visitor-to-trial. Neither rate has ever been measured, which is now written into the plan as an assumption rather than left as an alibi. **Step 2 and 3, lead-time sort. Three failures.** - Analytics is scheduled for week nine, after a paid test in week seven. The paid test will therefore produce a spend figure and no conversion data. Move analytics to week one. This is the item that blocks the most. - The marketplace listing is scheduled to be submitted in launch week, and its published review time is longer than the week itself. It cannot be live on launch day. Either submit at T-4 or remove it from the plan and stop counting its traffic in the goal. - Press and community outreach is a single line item in launch week reading "reach out to writers and communities". This is the inverted item. Move to a named list at T-9, a first contact with no ask at T-8, a useful second contact at T-5, and the ask at T-2. **Step 3, list. Fail.** The mailing list is scheduled to start collecting in week ten, two weeks before launch, and the launch email is expected to carry 8,000 visits. A list built in two weeks does not produce that. Start collecting at T-10, and re-do the email line of the decomposition with the list size you will realistically have. **Step 3, assets. Conditional fail.** The demo video is booked for T-2, and the two features it is meant to show are still being rewritten. Apply the branch: record the frozen parts now, script the rest, and set the T-2 decision point. **Step 4, channel concentration. Fail.** The launch-day aggregator post carries 60% of the projected traffic. One surface, one day, one algorithm, no control. Either build a second channel to size or restate the goal at a level the remaining channels can support. **Step 5, pre-mortem.** The three causes written independently: nobody knows who it is for, the free tier is too generous to convert, and the launch-day post does not get traction. The plan has a line addressing none of them. Positioning work is added at T-11, a pricing review at T-6, and a second acquisition channel at T-8. **Step 6, freeze.** No freeze point exists. One is set at T-1 with "new" defined. **Step 7, the day after.** The plan ends on launch day. Added: a follow-up sequence to non-converters, retargeting collection switched on before launch rather than after, a second wave to the people who asked to be told, and the week-minus-one against week-four baseline comparison as the actual measure of success. **Verdict: hold the date.** The marketplace review window and the outreach schedule are both immovable, and the plan currently assumes both are free. Either move the launch by three weeks so the queues fit, or drop the marketplace listing and the press line from the goal and restate the number the remaining plan can support. Fixing the analytics ordering is the single cheapest change here and should happen today regardless of which option is taken. ## Failure modes **The wishlist goal.** "A strong launch." It cannot be decomposed, so it cannot be planned against, and it cannot be missed, which is the actual attraction. **Outreach as a launch-week task.** A single line reading "contact press and communities" scheduled in the final week. It converts near zero, and the failure is invisible because nobody counted what it would have converted at if it had started at T-8. **Lead time measured forwards from desire.** "We want it live in week ten, so we will start it in week nine." The correct question is what date the item must start given how long it takes, and for anything with a queue, the queue owner sets it. **Spending a one-shot before its preconditions are true.** The whole-list email on the morning of a day when checkout has not been tested with a real transaction. You do not get to send it again. **Measurement installed after the first spend.** Producing a launch retrospective that is a debate about attribution rather than a set of numbers. **The unfrozen final week.** Something new enters the plan on the Tuesday of launch week, and the things that were planned go out unrehearsed while everyone works on the new thing. **The single-channel launch.** Every projection depends on one surface nobody controls, and there is no line in the plan for what happens if it does not fire. **The plan that ends on launch day.** The spike arrives, decays over roughly a week, nobody follows up with the largest pool of interested non-buyers you will have all quarter, and the baseline four weeks later is exactly where it was before. **Optimism in the asset schedule.** Booking the demo recording against a product that is still moving, then losing the final week to a re-record. ## What this skill does not do - It does not evaluate the product, the positioning or the price. It will tell you that a plan is well ordered. It cannot tell you that the thing being launched is wanted. - It does not know your real lead times. Review queues, legal turnaround, print and translation vary by organisation and by country, so it will ask, and where you cannot answer it will audit against a stated default and label it as such. - It does not check the arithmetic against reality. It checks that the arithmetic exists and that the assumed rates are written down. Whether 3% is the right rate for your site is a question for your analytics. - It does not manage the plan. It is one read of a document. Once the plan is live, a dependency-aware tool that recalculates when a date moves is the correct home for it. - It cannot see capacity, holidays or competing priorities, which is the most common reason a correctly ordered plan still slips. - It does not write the assets, the emails or the pitches. It tells you when each has to exist and what it depends on.
These skills all ask your assistant to check things against your actual codebase, your actual schema, your actual design system. Locul keeps that context current on its own, from the files you already have, on your machine. Mac and Windows, free to start.