Why are so many shipped features going completely unused?
The short answer: your go-to-market motion was built for a world where features took quarters to ship. Now they take days, and the communication infrastructure never caught up. Features are going live without positioning, without sales enablement, and without any feedback loop telling you whether anyone noticed.
Last quarter I was on a call with a PMM lead at a mid-sized SaaS company. She was describing her week, and the phrase she used stuck with me: "drinking from a water hose." Her engineering org had tripled its output since they adopted AI coding tools, and her team of three was supposed to cover all of it. They weren't writing launch plans anymore. They were just trying to document what already shipped.
This isn't a rare situation. I've heard versions of it from enough operators now that I think it's one of the more consequential structural problems in B2B SaaS right now.
What did PMM teams actually believe before AI changed the equation?
For most of the last decade, product marketing operated on a reasonable assumption: feature development was the bottleneck. If you could ship something, it was probably important enough to warrant a real launch. PMMs planned campaigns around roadmap milestones. Sales got enablement materials before GA. There was enough lead time to write the positioning, prep the deck, and brief the CS team.
That assumption is gone. Even I can ship code now, and engineers with real skill sets can ship at a rate that no traditional PMM process was designed to absorb. The bottleneck moved from build to communicate, and most teams haven't reorganized around that.
The flawed assumption was that shipping and launching were the same activity. They never were, but the gap between them was small enough that conflating them didn't cause much damage. Now the gap is enormous and the damage is real.
How does this show up as a business problem, not just an operational one?
When features ship without proper communication, you get a cascade of downstream problems that are easy to misdiagnose.
First, adoption craters. A ton of companies are shipping a ton of features that aren't getting used at all. That's not a user engagement mystery. It's a direct result of users never hearing about the feature clearly enough to try it. Low adoption feeds into renewal conversations that go badly, because customers feel like the product isn't moving fast enough even when it's moving faster than ever.
Second, sales cycles get longer and messier. When reps don't have current enablement material, they either skip newer features entirely or improvise positioning that's inconsistent with what marketing is saying. Deal friction goes up. The features that should be differentiating you in competitive deals aren't getting mentioned at the right moment.
Third, PMM teams burn out and start making triage decisions that nobody explicitly signed off on. The horse is out of the barn, so teams figure out how to adjust, but that adjustment usually means some features get decent launches and many get none. Nobody tracks which ones. Nobody measures the difference in adoption or revenue between a supported launch and an unsupported one. So the decision stays invisible and the problem compounds.
I've seen this described as PMM becoming reactive. One operator put it plainly: the job has become marketing what is already out rather than planning launches. That's not a PMM failure. That's an organizational design that hasn't caught up with build velocity.
Why do smart teams let this gap grow without addressing it?
Partly because the consequences are diffuse. No one deal fails because a feature launched without proper enablement. The damage shows up in aggregate: slightly lower adoption rates, slightly longer sales cycles, slightly higher churn. Each individual signal is explainable by something else.
Partly because the solution feels like adding headcount. The obvious response to "PMM can't keep up" is "hire more PMMs." But as one person in my network asked pointedly: "I'm doubting you all got more resources." That's right. The headcount math doesn't work. You can't linearly scale a human process to match AI-assisted engineering output.
And partly because nobody has made the measurement clear. If you can't connect a specific feature launch to sales mentions, to pipeline movement, to expansion revenue, then the argument for investing in launch infrastructure stays abstract. Leadership hears "PMM is overwhelmed" and thinks it's a capacity complaint rather than a revenue leak.
What actually needs to change in how teams handle feature launches?
The shift that matters most isn't adding people. It's changing where the communication work sits and how it gets triggered.
Right now, most teams treat launch communication as something PMM does after engineering finishes. That sequencing made sense when build cycles were long. Now it means communication is always behind, always catching up, always reactive.
The teams handling this better are building the communication scaffold into the development workflow itself. Not a separate process that runs in parallel. Not a handoff that requires someone to go find a PMM. The release notes, the positioning, the sales alert, the customer-facing changelog entry: these get drafted as part of the feature being built, the same way a unit test does.
That sounds like a workflow change, and it is. But it's also a data change. When you build communication into the release process, you start to get a record of what launched, when, with what messaging, and to whom. That record is what lets you eventually close the loop to adoption data and sales mentions. Without it, you're always guessing.
The PMMs I've talked to who feel less overwhelmed aren't the ones at companies that slowed down shipping. They're the ones at companies where the communication trigger became automatic rather than manual, where they're reviewing and refining output rather than producing everything from scratch under deadline.
That's the practical shift: move from PMM as the source of launch communication to PMM as the quality layer on top of a process that runs whether they're in the room or not.
FAQ
Why can't PMM teams just hire more people to keep up with AI feature velocity?
AI-assisted engineering output scales faster than headcount can. A team that doubled in size would still face the same structural lag because the bottleneck is the sequential handoff between build and communication, not raw PMM capacity. The fix requires changing the process, not only adding people to the existing one.
What is the revenue impact of features that launch without PMM support?
Unsupported launches typically result in lower feature adoption, weaker competitive positioning in sales cycles, and reduced expansion revenue from existing customers. Because the damage is distributed across many deals rather than concentrated in one, it tends to stay invisible until adoption metrics or NRR numbers surface the pattern.
How should B2B SaaS teams change their launch process when shipping velocity increases?
Rather than treating launch communication as a downstream PMM task, high-velocity teams are embedding communication scaffolding into the development workflow itself. Release notes, sales alerts, and positioning drafts get created as part of the build rather than after it, which keeps communication close to the feature and gives PMM a review role rather than a production role.
What does feature adoption have to do with sales cycle length?
When reps lack current enablement material, they either omit newer features from their pitches or improvise inconsistent positioning. Both outcomes reduce the chance that a differentiating feature gets mentioned at the right moment in a deal, which can extend the sales cycle or lose a competitive comparison.