Launch week goes well. The embargo holds, the coverage lands, the post does numbers, three newsletters pick it up. Traffic spikes for four days and settles.
Two weeks later somebody on your team asks ChatGPT what the best option in your category is, mostly out of curiosity. You aren’t in the answer. Or you are, described as the thing you were before the launch, with the old positioning and sometimes the old price. All that coverage, and the machine your buyers are asking hasn’t registered that anything happened.
The instinct is to assume something went wrong with distribution. Nothing did. A launch and an AI answer engine want opposite things, and almost every launch plan is built for the wrong one.
A launch is a burst. The engine is reading an accumulation
The modern launch playbook is optimized to concentrate attention into a narrow window. Embargo lifts at the same hour, the announcement goes out to everyone at once, coverage clusters into two or three days on purpose, because a synchronized spike is what ranks on aggregators and what makes a launch feel like an event.
An answer engine isn’t reading for events. It’s assembling a description of what your product is from sources that agree with each other, and it weights corroboration and durability. Ten pieces published on the same morning, all derived from the same press kit, all using your phrasing, aren’t ten sources agreeing. They’re one claim, yours, repeated. That the engine can trace the shape back to a single origin is exactly the property that makes it discount the claim.
So launch day is the moment you have the maximum amount of attention and the minimum amount of the thing AI search actually reads: independent accounts, published at different times, by people who formed their own view.
On top of that sits the timing problem. Retrieval engines and memory engines run on completely different clocks. The retrieval ones can pick up a genuinely new page within a crawl cycle, which is why Perplexity sometimes knows about your launch quickly. The memory-default ones only learn you exist on their own refresh schedule, which is months long and which nobody outside those companies controls. That’s why the answer looks stale in one place and current in another, and why the team’s confidence in the launch depends entirely on which engine they happened to open.
None of this is fixable on launch day. All of it is fixable before and after.
The pre-launch window is the asset nobody spends
Here’s the part that changes what you would actually do differently.
Most launches treat the weeks before as a communications embargo: nothing exists publicly until the moment it does. That’s the right instinct for press and the wrong one for the source layer, because the source layer takes time to accumulate and you have deliberately set its start date to zero.
The teams that come out of a launch visible in AI search almost always did something before it. Design partners who wrote publicly about using the thing. A practitioner who published a real write-up on their own timeline, not yours. A comparison or category page that got updated ahead of the announcement rather than three months after it. None of that requires breaking an embargo on the product news. It requires deciding that the goal is a record that exists before the spike, not only a spike.
Then, on launch day, be honest about which question you can actually win. You aren’t going to take the broad category query in week one. That query is answered from an accumulated consensus you haven’t had time to build, and you can’t out-differentiate your way into it on features alone. What you can win immediately is the narrow, recent, specific question: the one where being new is an advantage rather than a deficit. Somebody asking whether anything solves a particular problem that nothing solved cleanly last year is asking a question where recency is the answer. That’s a real query with real buyers behind it and almost no incumbent advantage.
And publish the launch itself as a fact rather than an announcement. Dated, specific, plainly stated, with the numbers and the constraints in it. A page an engine can lift one accurate sentence from will do more for you over the next year than a page that reads like a celebration, because the argument on your own site is the weakest input the engine has and the verifiable specifics are the strongest part of it.
What I got wrong
I ran a launch as a spike to be maximized, and I would run it differently now.
The client had a genuinely significant release, a real category move, not a feature. We planned it properly by every standard I had: embargo, coordinated coverage, a strong launch post, good syndication. It worked. The coverage was better than we expected and the week looked great in every dashboard.
Then I checked the engines a few weeks out and the client was still being described in the old terms. Not wrong exactly, just superseded. The launch hadn’t entered the description of what the company was.
When I actually looked at what we had produced, the problem was obvious and it was mine. We had generated eleven pieces of coverage in three days, and every one of them traced back to the same press release. Same framing, same phrases, often the same quote. To a machine deciding what is corroborated, that’s one source with eleven copies, and I had spent the entire budget producing it. I had optimized for a number that measured how synchronized we were, when the thing that mattered was how independent we were.
What eventually moved it was small and slow and would have made a terrible launch plan. Two people who had actually used the product wrote about it on their own schedule, weeks apart, in their own words, including things we wouldn’t have said about ourselves. A category page got updated by someone we had a real relationship with. That’s when the engines started describing the new thing, and it happened well after everyone internally had stopped thinking about the launch.
The lesson I kept is that a launch buys you attention, and attention isn’t the input. If you want the launch to change what the engine says, some of the record has to exist before the spike and some of it has to keep arriving after it, from people who aren’t you.
What to do with the launch you have coming
Work backwards from the record you want to exist a month after launch day, not from the launch day itself.
Before: get at least two people outside the company positioned to write something real on their own timeline, and get whatever third-party pages describe your category updated. Those are slow asks, which is precisely why they can’t start in launch week.
During: publish the launch as a dated, liftable, specific page, and aim your query ambitions at the narrow recent question rather than the category head term you have no standing in yet.
After: expect the retrieval engines to move in weeks and the memory-default ones not to move on your schedule at all, and tell everyone that in advance so a normal lag doesn’t get read as a failed launch at the first review. Then keep publishing the accounts that arrive late, because those are the ones doing the work.
If you have a launch coming and you want the record to exist before the spike rather than after it, that’s the work we do and the method we use.