Be bold, ship gradually
• 4 min read
After weeks of researching, designing, and building, it’s tempting to just get your product in the hands of users as quickly as possible. Just ship it. But the way something rolls out can mean the difference between a successful launch and one that backfires.
Shipping boldly
This approach is optimized for speed. Changes roll out to all users at once, usually over hours or days.
Facebook is famous for “move fast and break things” — and it got them where they are, even if they’ve toned it down. As a user, you’ve probably experienced this: logging in and seeing something different each time.
At my previous startup, a B2B SaaS application, we shipped boldly. We had a few hundred paying customers solving a niche problem. Like many startups, our users were early adopters — forgiving of changes and willing to provide feedback. We didn’t have the tools or time for gradual rollouts. If something went wrong, we fixed it quickly. Most startups probably ship boldly.
Shipping gradually
This approach is optimized for learning while minimizing negative impact. Changes roll out to a subset of users, get monitored for feedback, then expand. This might happen over weeks or months.
The new Gmail launched in 2018, but it didn’t happen overnight. It was announced in April as an opt-in experience. Users could try it and go back if they didn’t like it. Gmail collected feedback from users who stayed opted in and those who opted out. After 3 months, they removed the opt-out and migrated everyone.
At Shopify, even small changes get noticed and can disrupt users. I worked on a project redesigning one of our most trafficked pages where qualitative feedback was a success metric. I chose a gradual rollout: release to a small set of users, iterate based on feedback, then expand.
This ended up being smart. We learned things from real users that didn’t surface in testing — things you only discover with the product in the wild. For example, certain users printed this page out, and some of our changes made that experience worse. We caught it early and fixed it before rolling out to everyone.
Picking an approach
Each approach has tradeoffs. Ask yourself:
- What could go wrong? What are the biggest risks?
- How confident are you? Are you looking for feedback? Willing to iterate?
- What’s your timeline? Can you afford additional engineering time to set things up?
Ship boldly when:
- Changes are small and unlikely to disrupt users
- You’ve done extensive user research and are confident in what you’ve built
- You’re making the changes regardless of feedback
- You’re under a tight deadline or don’t have resources for a sophisticated rollout
Ship gradually when:
- Changes are major and likely to surprise or confuse users
- You want to see how real users actually use the product
- You want to iterate based on real feedback
- You have the tools and engineering resources to target specific users
How to ship gradually
The easiest way is using a feature flag — code that toggles a feature on or off. For turning it “on,” you have options:
- By percentage — 0% to 100% of users
- Manually — turn it on for select users
- User opt-in — users can opt in or out themselves
If you’re just getting started, use the percentage method. My personal favorite is user opt-in. Users who opt in are more forgiving early adopters, and it’s less disruptive to everyone else.
The takeaway
Don’t confuse shipping gradually with being slow or lacking confidence. It actually lets you get your product in users’ hands faster — just to a smaller group first. It also lets you ship bolder changes to a subset of users, evolving your product faster overall.
So be bold, and ship gradually.
This was originally written for ProductBoard’s Product Excellence ebook, featuring insights from product leaders like Hiten Shah, Alex Osterwalder, and John Cutler.