Launching: pilots, waves and the review after
Shipping code is the easy part. A launch is everything that turns working software into changed behaviour: the right amount of effort for the change, a pilot with go/no-go criteria, waves with gates, messages in each audience's own words, training and support ready before day one, and a dated review that decides what happens next.
By the end you can
- Separate deploy, release and launch, and use feature flags and staged rollouts to control who gets what
- Pick a launch tier and plan the effort that goes with it
- Design a pilot and waves with go/no-go criteria written before you start
- Write positioning and messages for each audience, including internal users
- Get training and support ready, run a go/no-go meeting, and hold a post-launch review that ends in a decision
The everyday picture
A new restaurant rarely opens to the whole city on day one. First comes a soft opening for friends and neighbours, where the kitchen learns which dish takes too long and which waiter forgets the drinks. Then it opens for lunch only. The grand opening comes when the kitchen can keep up. Before any of it, the waiters learn the menu, the owner writes the one line for the sign outside, and everyone knows what to do when the kitchen falls behind.
A month later the owner sits down with the numbers: what sold, what came back to the kitchen, what people said. Then she makes a decision: change the menu, hire another cook, or open a second branch. A product launch is the same sequence, and most failed launches skip one of these steps.
Deploy, release, launch
Three words are often used as if they meant the same thing. Keeping them apart gives you control.
- Deploy: the new code is running in production, or installed on users' phones. Nobody has to see it yet.
- Release: users can use the feature, because a flag was switched on for them or an app version made it visible.
- Launch: the people affected know about it, are trained and supported, and you are measuring the result.
A feature flag is what separates deploy from release. The code ships switched off, and you turn it on for a chosen group, then a bigger one. Pete Hodgson's widely read article on feature toggles (2017) describes four kinds: release toggles that hide unfinished or unlaunched work, experiment toggles for A/B tests, ops toggles that let operators switch off or degrade a feature in trouble (the long-lived ones are called kill switches), and permissioning toggles that give a feature to certain user groups. He also warns that flags are inventory with a carrying cost: release toggles should usually live only a week or two after full rollout, so add a removal task when you create one. The engineering side is in Shipping safely.
Flags matter even more on mobile, because you cannot pull an installed app version back off people's phones. App stores let you spread a new version out gradually. Apple's phased release sends an update to users with automatic updates over seven days (1%, 2%, 5%, 10%, 20%, 50%, then 100%), can be paused for up to 30 days in total, and anyone can still download the update manually. Google Play's staged rollout lets you pick the percentage, raise it yourself when you are ready, and halt it if you find a problem. Company-owned devices, such as store handhelds, usually get updates through a device-management tool that can push to one store or group at a time.
Quick check
Partner app version 4.2, which contains the claims code with its flag off, reached 100% of phones last week. Has claims launched?
Having the code on every phone is deployment. Nobody can use claims until the flag is switched on, and nobody is ready to use it until training and support are in place. That gap is exactly what lets you choose the pilot shops.