You shipped a feature three weeks ago. The PM closed the Linear ticket, engineering merged the PR, and someone posted in the internal Slack channel. But when you talked to three customers at your last QBR, none of them knew the feature existed.

This is not a writing problem. It is a throughput problem, and it is the most common silent revenue leak in B2B SaaS companies between 20 and 500 people.

The bottleneck nobody talks about

In most SaaS companies, one person owns release communication. Sometimes it is a Product Manager or Head of Product. Sometimes it is a Product Marketing Manager or a Customer Success Lead. Occasionally it is whoever is least busy that week.

That person is sitting between five PMs who are each shipping independently, a support queue that keeps moving, and a backlog of drafts that never quite make it to send. When something major ships, the comms get written. When something minor ships, it goes into a Notion doc that nobody reads. When three things ship in the same week, priorities get made on instinct.

The result is inconsistent coverage. Major features get buried in the same generic all-user blast as minor bug fixes. Minor fixes get ignored entirely. And users who would have upgraded if they had seen the right message at the right time never get that message.

This is not a problem you solve by hiring another writer. The bottleneck is structural. Adding a second person just moves the wall.

Why the manual process breaks specifically at this company size

Enterprise companies have dedicated release comms teams. Very early-stage startups ship infrequently enough that one person can handle it manually. The 20-to-500-person window is where the math stops working.

At this size, product teams are shipping fast, CS teams are stretched thin covering renewals and onboarding, and there is rarely a dedicated PMM who owns only release communication. Whoever owns release comms, whether that is a Senior Product Manager, Director of Product Management, VP of Product, PMM, or CS Lead, is also running roadmap reviews, QBRs, onboarding sequences, health scores, and escalations.

Each release requires several things to happen: someone has to understand what shipped and why it matters, decide which users need to hear about it and how loudly, write different versions of the announcement for email versus in-product versus Slack, get it reviewed, and then actually send it through the right tools. That sequence takes hours per release, and it requires the same person to be available at the right time every single time.

When priorities shift, which they always do, the release comms fall. Not because nobody cares, but because there are only so many hours.

The specific gap between "shipped" and "noticed"

There is a secondary problem that does not get talked about enough: even when the comms go out, they often go to the wrong audience with the wrong message.

A generic all-user blast for every release trains your users to tune you out. If every email looks the same regardless of whether it contains a major workflow change or a minor visual tweak, your users stop reading. Open rates drop. When you actually have something important to say, nobody is listening.

The fix is not just more communication. It is tiered communication. A T1 major feature that changes how a core workflow functions deserves a dedicated email, an in-product announcement walking users through what changed, and a Slack message to relevant account teams. A T4 silent patch needs none of that. The problem is that deciding which release gets which treatment, and then executing the right level of response, requires judgment and time that most product and CS teams do not have in reserve.

What automated feature release communication actually looks like

The right approach to this problem starts with structure, not more tools.

When a feature ships, someone should be able to paste the PR description, changelog entry, or Jira ticket text into a system that reads what shipped and generates a plain-language summary. That system should then classify the release into a tier based on rules the team has already defined: how significant is it, which user segments does it affect, what channels should be used for this category of release.

Once the tier is set, the system should draft channel-appropriate copy automatically. Not the same block of text sent everywhere, but a short tooltip for in-product use, a longer email for the segment that needs context, a Slack message for the account team. The responsible person reviews it, edits what needs editing, and approves. Nothing goes out without that approval.

After launch, the system should measure whether users actually adopted the feature, because adoption data is where the next part of the revenue loop lives. Accounts that start using a feature heavily after it launches are often ready for a plan conversation. If you are not tracking feature adoption at the account level, you are leaving that conversation to chance.

This is what Across is built to do. It ingests release context, runs it through a customizable tiering rubric, drafts per-channel launch plans for review, delivers through the tools you already use including Pendo, Intercom, and Customer.io, and then pulls adoption data from your connected analytics stack to surface which accounts are using the feature above their plan tier. The expansion signal comes automatically. The upgrade suggestion gets drafted. The PM, PMM, or CS Lead reviews and sends.

The integration question

One reason teams do not adopt release comms tooling is the re-instrumentation fear. Nobody wants to set up a parallel tracking system when they already have Mixpanel running and Pendo configured and three years of Intercom data.

The answer to this is not to rebuild your stack. It is to connect what you already have. If your release communication tool connects directly to Mixpanel, Amplitude, Pendo, Intercom, and Customer.io, it can pull usage data to inform tier decisions and measure adoption without asking your engineering team for a new event or touching your existing setup.

That is the difference between a tool that adds work and a system that removes it.

Where to start

If you are a Product Manager, Head of Product, VP of Product, PMM, or CS Lead at a B2B SaaS company and you are currently the person manually writing and sending release comms, the first step is not to find a better writing tool. It is to acknowledge that the problem is structural and that the fix requires structure: a defined tiering rubric, a review workflow, channel-specific templates, and post-launch measurement.

You can build that manually in Notion and Zapier and it will be better than nothing. Or you can look at Across and see whether the system does the structural work for you.

The throughput problem is solvable. The feature you shipped three weeks ago that your customers do not know about yet is the evidence that the current approach is not working.

Frequently asked questions

What is feature release communication automation? It is the practice of using a system to handle the classification, drafting, approval, and delivery of feature announcements across multiple channels, rather than having one person manually write and send each announcement.

Why do product and CS teams struggle with release communication? In most growing SaaS companies, release comms land on a Product Manager, Head of Product, PMM, or CS Lead in addition to their core responsibilities. When multiple features ship simultaneously and priorities shift, release comms get deprioritized. The throughput problem compounds as product teams ship faster.

What is a release communication tiering system? A tiering system classifies each release by its significance and assigns a default communication strategy. A T1 major release gets in-product announcements, a dedicated email, and a Slack message. A T4 minor fix might get no outbound comms at all. The system ensures the right level of attention for each type of release.

How does feature adoption tracking connect to expansion revenue? When you track which accounts start using a new feature after launch, you can identify accounts whose usage exceeds their current plan tier. These accounts are expansion candidates. Flagging them automatically and drafting the upgrade suggestion converts feature adoption data into a revenue signal.