Product decisions · 4 min read · Sep 25, 2026

The rollout is part of the product

A team tests a new feature. The result looks promising. Someone asks, “Can we roll it out?”

It sounds like the analysis is finished and deployment is the next person’s job.

But “roll it out” contains several decisions. To whom? In what order? What counts as receiving the feature? Which outcomes must remain healthy? How long do we wait before expanding? What can we turn off if something goes wrong?

The feature people experience is shaped by those answers. A good change delivered badly can still be a bad experience.

First, separate available from experienced

Imagine a team changes the way a video ad closes. The new behaviour is available in the latest version of its software, but an app developer has to update that software and release a new app version before players can encounter it.

The code may be deployed while almost no players are exposed.

Even among updated apps, some players never reach that ad placement. Others see it several times. Calling all of them “treated” would muddle the result.

I would track four distinct stages:

These are different denominators. If adoption is slow, the problem may be distribution rather than the feature itself. If the outcome changes only among heavily exposed players, that matters more than a reassuring average across everyone with the update.

Choose the first audience deliberately

A small initial release limits the number of people affected while the team observes real use. Google’s SRE guidance on canary releases describes this as evaluating a partial, time-limited deployment before proceeding.

But a small audience is not automatically representative.

The first partners willing to update may have more technical support or different traffic from everyone else. A feature that works on one device, app category or placement may behave differently elsewhere.

So the rollout plan needs two questions, not one:

Is this working for the people who have it?
Are those people similar enough to the next group that we should expand?

A canary can catch a broken release without proving its full business impact. A randomized experiment can estimate an effect under its tested conditions without guaranteeing that every later segment will behave the same way. Those are related tools with different jobs.

Define the stop rule while everyone is optimistic

Suppose the headline metric improves by 2%. That is interesting, but it is not yet a rollout decision.

Before expanding, I would want to know whether the change affects reliability, user experience and the other side of the marketplace. For the video-ad example, the team might examine crashes, completion, player retention, publisher revenue, advertiser outcomes and support reports. The relevant guardrails depend on what the feature could plausibly change.

A rollout plan should say in advance:

• which signals trigger investigation;
• which ones pause expansion;
• which ones require disabling the feature;
• who has authority to make that call.

Without those rules, a team can explain away a warning because it has already become attached to the launch.

There also needs to be enough observation time for the signal to appear. A crash may show up quickly; a retention effect may take longer. “Nothing bad happened in the first hour” only supports the things an hour could reveal.

Know what “off” can and cannot undo

A feature flag can separate shipping code from enabling a feature. It can also target a percentage of users or a particular audience; LaunchDarkly’s documentation shows how percentage rollouts work in one implementation.

That control is useful, but “we can flip the flag off” is not a complete recovery plan.

If the feature has already changed stored data, sent messages or affected completed transactions, disabling it will not reverse those actions. If an app has to ship a new version, some behaviour may remain on devices until the next update.

The team should identify which effects are immediately reversible, which need repair and which cannot be recalled. That distinction changes how cautiously each part should launch.

A launch is not a single moment when a switch moves from off to on. It is a sequence of decisions about who experiences a change and what the team learns before exposing the next person to it.