75% of Teams Ship Faster. 7% Can Launch at That Speed. Retire the Launch Tier.

Kristen Bryant Smith at Appcues published a survey of 60 marketers, run with Navattic, on October 27. Two numbers in it describe the next five years of this job. 75% say their product is shipping faster than last year. Only 7% say their launch process is keeping up.

The other 7% in the survey is the one I'd frame. That's the share who call alignment across product, sales, customer success, and marketing strong.

Her read on what AI has done for launches so far is blunt. It mostly helps teams write announcements nobody sees.

So the build sped up and the story didn't. The fix isn't a faster launch process. It's a different unit of work. When the product ships every day, the launch tier stops being useful, and what replaces it is a question you ask about every change: what does this do to the claim?

This is part 3 of The Product Marketing Transition. Part 2 put the positioning file in the repo next to the spec, with the PM and the PMM as its two owners. This part is about what happens to that file when the product changes daily.

The short version

• Appcues found 75% of marketers say their product ships faster than last year and only 7% say their launch process keeps up.
• The launch tier ranks a change by the size of the feature, which is the wrong axis when changes arrive daily. The right axis is what the change does to the claim. Most changes do nothing to it and should flow from the pull request to the changelog and docs with no meeting.
• Some change the proof, so docs, comparison pages, and the discovery file move the same day. A few change the claim itself, and those get reviewed like a spec change.
• The PMM owns that rule and the claim, the campaign stays in marketing, and the number to watch is story lag, the days between a change shipping and the assistants describing it correctly.
• Because the sorting happens at merge time, it lives in the product pipeline, under the CPO.

The tier ranks the wrong thing

One respondent in the Appcues survey describes the next step without quite taking it. Every tier 3 launch at their company is fully automated, through a GTM plugin the PMM built.

That's the right instinct, a PMM building the system instead of running the event. But it's still sorting changes by size. Tier 1 for the big feature, tier 3 for the small one. The buyer doesn't sort that way, and neither does the assistant answering the buyer's question. They care whether the change alters what you're for, what you can prove, or neither.

Look at the volume. Vercel's changelog posted eight entries across November 2 and 3: a security review in public beta, CI without a linked project, a vercel doctor command, faster sandbox startup, and more. Salesforce's Agentforce Coworker announcement on November 4 reads as a rolling schedule. Available now, generally available in November, expected in December, sorted by channel and feature. Salesforce reports more than 185,000 users and usage up 21x in three months, its own figures.

Nobody tiers eight entries in two days. And a release that's really a schedule doesn't have a launch day.

One question at merge time

Here's the rule I'd put in place instead. Every change gets one question when it merges: does it change the claim, the proof, or neither?

Neither is most of them. A faster startup, a new CLI flag, a fixed edge case. These flow from the pull request to the changelog to the docs without a meeting. An agent drafts the entry from the diff, which is a solved problem. The launch comms agent blueprint on this site writes six channels on every release. Generation was never the hard part.

Some changes move the proof. A new integration, a benchmark, a capability a competitor lacks. The claim stays, but the evidence for it changed, so the docs, the comparison pages, the pricing page, and the agent-facing discovery file from part 1 move the same day. If they move next week, the assistants spend a week telling buyers the old story.

And rarely, a change moves the claim. A new buyer, a new alternative you now beat, a new reason to switch. That's a positioning change. It gets reviewed like a spec change, by the two owners of the file, before it merges.

The PMM owns the rule and the claim. Not the calendar.

Emily Kramer said it in her analysis of 1,100+ marketing job posts last month: launches are just campaigns. I agree, and I'd split it cleanly. The campaign, the event, the quarterly story moment, those are marketing's and they matter. The claim, and every change that touches it, is product's.

Story lag is the number

If the launch isn't the unit, launch-day reach isn't the metric. The one I'd track is story lag: days between a change shipping and the AI assistants describing it correctly.

It matters because the assistant's picture of you is redrawn constantly. Rich Holmes reported Ahrefs data on about 37,500 AI citations: at least half were gone by day two, and about 75% of those came back later. That's a surface that gets re-read and re-written every day, whether or not you shipped anything.

7%

So story lag is measurable, and it's mostly a function of how fast the proof surfaces move after a change. A claim change with a two-week lag is two weeks of buyers hearing the old positioning from a machine they trust.

Why the sorting belongs under the CPO

This part's piece of the larger case is about where the question gets asked. Claim, proof, or neither is decided at merge time, in the pull request, by people looking at the diff. That's the product pipeline. The PMM review on a claim-changing change is a check in that pipeline, like a security review.

A check owned by a different org turns into a ticket queue. The change merges on Tuesday. The ticket gets read on Thursday. The assistants have been answering with the old story since Wednesday.

Put the PMM inside the product org and the check runs on the build's calendar. That's why the CPO Transition keeps arriving at one function owning the whole outcome, and why the new PM Transition frames the PM as one seat in the same loop. The loop runs customer, spec, build, story, adoption. Story can't sit on a separate calendar from build when build ships daily.

The decision for a CPO this quarter: retire the launch tier matrix. Replace it with the three-way question at merge, name the PMM as a required reviewer on claim changes, and put story lag on the same dashboard as adoption. Keep the campaign calendar, and give it to marketing.

What I expect

These are my predictions, not facts.

By the end of 2027, the launch calendar is gone at AI-native software companies. Story lag sits on the CPO's dashboard next to adoption.

Within 18 months, most changelog entries at AI-native companies are drafted by an agent from the pull request, and a human edits only the ones that touch the claim or the proof.

By 2028, the PMM's review of claim-changing changes is a required check in the release pipeline, as routine as a security review. Appcues' 7% who say their launch process keeps up will be the companies that made that change first.

One thing to try this week

Pull the last 30 days of merged changes, or the changelog if that's easier. Sort every entry into one of three piles: changed the claim, changed the proof, changed neither.

Then take the top two from the first two piles and ask ChatGPT, Claude, Gemini, and Perplexity about them. Count the days since each one shipped and note whether the assistants have it right yet. That gap is your story lag, and the pile sizes tell you how much of your launch process was spent on changes that didn't need one.

Sources: Kristen Bryant Smith, "The State of Product Launches," Appcues, October 27, 2026, survey of 60 marketers with Navattic. Vercel, "Changelog," entries of November 2 and 3, 2026. Salesforce, "Salesforce's Agentforce Coworker Usage Soars 21x in Three Months," Salesforce Newsroom, November 4, 2026, company figures. Emily Kramer, "I analyzed 1,100+ marketing job posts. They're stuck in 2023.," MKT1 Newsletter, October 19, 2026. Rich Holmes, "Reddit's CEO warns Google's 'AI Mode does not drive traffic'," Department of Product, November 1, 2026, for the Ahrefs citation figures as he reports them.

Part of the running argument on Product Leadership: the product org chart was calibrated to a build cost that collapsed, and when the product ships daily, the launch stops being the unit of product marketing and the claim review moves into the product pipeline under the CPO.

Related answer: What replaces launch tiers when product ships daily?