When Do You Announce a Feature That's Only 10% Rolled Out?

Brian Sierakowski - Founder

A Head of Product Operations asked me a question I’ve been thinking about ever since: “Our release cadence and rollout percentages complicate when and how to communicate. When a feature is at 10%… 50%… GA… when do we tell customers?”

She was running release management at an enterprise integration platform. They’d moved from six-week release cycles toward CI/CD with feature flags. The technical benefits were clear. The communication challenges were not.

Traditional release notes assume a binary state: shipped or not shipped. Feature flags break that assumption. And nobody has figured out a clean answer for when to communicate about features that exist for some users but not others.

We Broke the Old Model

In the waterfall era, communication was straightforward:

  1. Build the feature
  2. Ship the release
  3. Announce to everyone

The feature was either available or it wasn’t. The announcement went out after the release. Everyone got the same message because everyone got the same product.

Feature flags changed everything.

Now a feature might be:

  • Merged but not deployed
  • Deployed but behind a flag (0%)
  • Rolled out to internal users only
  • At 10% of production traffic
  • At 50% of production traffic
  • Fully rolled out but not yet announced
  • Announced to some segments but not others

At which of these stages should you tell customers? The answer is “it depends,” which is unsatisfying but accurate.

The Communication Timing Matrix

Here’s how different teams handle this:

Option 1: Wait for GA

The safest approach: don’t announce anything until it’s fully rolled out to everyone.

Pros: No confusion. No “I don’t see this feature” support tickets. No awkward “sorry, you’re in the control group” conversations.

Cons: You lose the window to build anticipation. Early adopters who discover features feel ignored. Competitors might announce similar features first. Internal teams don’t know what’s coming.

Option 2: Announce at First Rollout

The aggressive approach: announce as soon as the feature is available to anyone.

Pros: Most time to build awareness. Shows momentum. Gets feedback earlier.

Cons: Most customers can’t use what you’re announcing. Support gets flooded with “where is it?” questions. You might roll back a feature you’ve already promoted.

Option 3: Staged Communication

The nuanced approach: different messages at different stages to different audiences.

Pros: Each audience gets relevant information. Internal teams can prepare. You can notify customers in the rollout directly. Others aren’t confused.

Cons: Complex to execute. Requires coordination between product, marketing, and engineering. Easy to make mistakes.

What Smart Teams Do

The companies handling this well share common patterns:

They Separate Internal from External

Internal teams (support, sales, marketing) need to know about features before customers do. They need time to prepare documentation, update scripts, and understand the change.

This internal enablement should start at first rollout, not GA. A feature at 10% means support might get questions. They need answers.

External communication waits longer, often until 50% or higher.

They Match Audience to Rollout Stage

If you’re doing a targeted rollout to enterprise customers, announce to enterprise customers. If you’re testing with a geographic region, communicate to that region.

The announcement should reach roughly the same audience as the feature.

They Use Qualifiers Instead of Absolutes

“We’re rolling out a new dashboard” is different from “The new dashboard is now available.”

Smart teams use language that reflects the state:

  • “Starting to roll out…”
  • “Now available to select customers…”
  • “Gradually becoming available…”
  • “Now generally available to all customers…”

This sets accurate expectations without waiting for GA.

They Have Rollback Plans

Before announcing anything, they know what happens if the feature gets pulled. Can you un-send the announcement? Update the changelog? Notify customers who got excited?

Features at 10% rollout get pulled regularly. That’s the point of staged rollouts: finding problems before they affect everyone. Communication should account for this possibility.

The Internal vs. External Timeline

Here’s a rough timeline that works for many teams:

Feature merged (0%):

  • Engineering and product know
  • No external communication

Internal testing (0-5%):

  • QA and dogfooding
  • Still no external communication

Limited rollout (5-20%):

  • Internal enablement begins (support, sales, marketing)
  • Documentation prepared but not published
  • No external announcement yet

Expanding rollout (20-50%):

  • Documentation published (findable but not promoted)
  • Notify customers in rollout directly
  • Consider soft announcement (“rolling out to customers…”)

Approaching GA (50-90%):

  • Public announcement if the feature is stable
  • Full documentation available
  • Marketing can promote

General availability (100%):

  • Final announcement if not done earlier
  • Remove any “rolling out” qualifiers
  • Feature included in standard release notes

This isn’t a universal formula. Adjust based on your product, your customers, and your risk tolerance.

The LaunchDarkly Problem

Many teams using feature flags have another challenge: their flag management system doesn’t talk to their communication system.

LaunchDarkly knows who has access to what. Your changelog doesn’t. Your support team doesn’t. Your marketing team definitely doesn’t.

This creates a gap where engineering knows the true state of the rollout, but everyone else is guessing. The announcement goes out at 80% rollout, but nobody knows it’s 80%.

The fix is integration: your communication tooling should understand rollout state. When you write release notes, you should know which audiences can see which features.

What Customers Actually Want

Here’s the thing: most customers don’t care about your rollout percentage. They care about two questions:

  1. Can I use this?
  2. When can I use it if not now?

Your communication should answer these questions, not explain your deployment architecture.

“We’re rolling out a new reporting dashboard. You’ll see it in your account over the next two weeks” is better than “We’ve deployed the reporting dashboard to 35% of users and will reach GA by end of month.”

The former is customer-centric. The latter is engineering-centric.

The Honest Answer

When should you announce a feature that’s only partially rolled out?

Internally: As early as possible. Your teams need time to prepare.

Externally: When you’re confident enough in the feature to defend the announcement if something goes wrong. For most teams, that’s somewhere between 50% and GA.

To specific customers: When they can use it. If you know a customer is in the rollout, tell them.

The complexity of modern deployment practices doesn’t have to mean complexity in communication. It just means your communication system needs to be as sophisticated as your deployment system.

Most aren’t. That’s the gap.

If your rollout process has outpaced your communication process, let’s chat about how Changebot integrates with feature flags and deployment pipelines to keep your communication in sync with what’s actually shipped.