Phased Rollouts – What 7 Product Leaders Want You To Know

A phased rollout is a launch plan broken down into parts, so that you can develop and launch significant things like a feature set or architectural change in sequential phases. It gives you time to iterate your team’s work for a better final product, but it also gives your customers enough time to lose interest in your big investment.

“Ship early, ship often” is the kind of mantra that that makes launching new products seem almost intuitive. Launch first, iterate later; move fast and break things.

But if what you’re taking on is big and cumbersome – updating from older technology to a new codebase, for example –  that kind of advice has never really cut it.

When we surveyed a handful of experienced product managers, we found that when the stakes are high, they’re busy answering bigger questions:

• “Is the cost of taking significantly longer to roll this out worth the time we lose in market?”
• “Are customers willing to sacrifice having an incomplete solution when there is a promise of more to come?”
• “Are there any potential downsides to not shipping the whole feature at once?”

And when an important new feature is too big to fit neatly into one complete release, they start planning a phased rollout.

So should you do it? Here are 7 product managers on how they approach the juggling act of a phased rollout.

1. Robert Anderson – VP Product Management at IDERA

Q: In an agile world, when is the right time to put a phased rollout on your product roadmap?

I look at a phased approach when the total work required is large and I am looking to deliver quicker incremental value to my customers.

For example, a phased approach is ideal with an enterprise product when I’m making significant performance and stability improvements to the product. However, I’m also not promising users that we will deliver perfect product performance in one release. This allows me to measure the impact of Phase 1 so I can be smarter in planning Phase 2.

I can also show my customers that the roadmap item is more than just a talking point because they can see I am putting my money where my mouth is.

Q: How does the length of product development cycles factor into a Phase 1/Phase 2 approach?

You should consider this when you want to avoid long development cycles. Long development cycles lead to disinterested customers and give you only a limited window to correct mistakes. You should also consider phased delivery when you want to gather feedback on a specific feature in order to refine and improve later phases.

Finally, you should consider phased delivery when you’re working on architectural changes, in order to limit the number of disruptive changes to your product. Users typically digest change better in chunks than one big change.

Keep in mind that unless you’re working with a SaaS product, your users may never upgrade from Phase 1 to Phase 2. So never deliver a product with phase 1 features that couldn’t work independently of Phase 2.

Q: What are your best practices for communicating a phased approach to users?

I think that it is important to make sure you can articulate a clear (and simple) story to your customers about the outcome of your plan. Of course, the reality of what you deliver needs to match that story.

Be open with your users about why you are not releasing everything at once and be clear that their feedback will influence what you deliver in the next phase if it helps improve your understanding of the problem.

2. Nadia Barbot – Product Manager at About.me

Q: How feasible are Phase 1/Phase 2 approaches in 2017?

In a world of competing priorities, Phase 1/Phase 2 timelines are pretty common and often necessary. It can be tricky because stakeholders internally may want the feature to be finished in one swoop, but managing through multiple phases can be done successfully for everyone.

Q: What’s the perfect opportunity to launch something new in phases? Are there any risks?

The phased approach is useful when you launch brand new features or integrations that didn’t exist before. These often require a few phases to become a complete solution, but you can set milestones to help the team see progress, celebrate wins, and keep up their momentum through the next phase.

Major UI changes or site relaunches are not ideal for phasing. Customers need to continue to be able to use your solution or solve their problem while you are launching your features, so phasing can be dangerous here.

Q: What are your best practices for planning and delivering a Phase 1/Phase 2 approach?

Since developers so often work in agile-like cycles these days, my team has even separated the dev launch from the marketing launch. This allows us to quietly coordinate multiple dev launches while planning one big marketing launch for that entire phased rollout.

1. If you are launching something new that impacts user experience, you likely will have to grandfather your Phase 1 users into Phase 2 (might need to give them the Phase 2 enhancements for free, etc).
2. Build a measurement plan for each phase, not just the final phase; this is key to keeping momentum because you can show your teams and the company that you are hitting goals along the way.
3. Collect feedback on Phase 1 as soon as it is out, and include time in your Phase 2 plan (alongside the new features you put in this phase) to make changes based on users’ feedback.
4. Communicate a ton. How will Phase 1 get us to our goals & long term vision? How will Phase 2 build on this?

3. Larkin Plaeger-McCollum – Product Consultant

Q: What are some ways to stay agile during phased development?

A phased rollout plan can give you a false sense of certainty of your plans after the initial launch.

It creates the temptation to not plan your product as thoughtfully as possible, because it’s easy to add features to Phase 2 that aren’t truly critical because the next phase feels distant. Conversely in Phase 2, it’s tempting to rely on your initial plans rather than reevaluating with fresh eyes based on your most recent data and observations.

When a feature set really does require a multi-step rollout, you need extra discipline to stay agile. You also need to keep reevaluating your plans throughout the product development process in light of what you learn from the initial launch.

When considering a phased rollout, define what features are essential to your product regardless of rollout strategy. If you and your engineering team still agree that multiple phases are necessary, make sure to stay alert during each phase to new information that can improve your plan.

Q: What are the drawbacks of a phased approach? How do you avoid them?

When possible, I prefer to think of a development process as a single launch of a product followed by ongoing improvements, rather than discrete phases. This may be a minor semantic difference but it helps keep your mindset agile and focused on learning at each stage of its development.

Another danger of a phased rollout is that you lose sight of your core goal, which is to solve a certain problem for your user.

To be successful, make sure you keep that core goal well defined and that you return to it at each stage of the project to confirm that you’re still geared toward solving that user problem.

Q: How should a product manager plan a phased rollout with their development team?

Close coordination with developers is essential. Sometimes your initial product-based take on logical phases is challenging from a dev perspective or would actually increase overall project scope. It’s also important for the dev team to have a view of the long-term feature plan to architect Phase 1 in a way that makes future additions easy.

4. Michael Hopkin – Product Consultant at Lead On Purpose

Q: Phased rollout – when is it a good time?

The phased approach works well when the initial phase offers enough value that people will use it. It’s much more common these days with the increased emphasis on creating MVPs.

If the product is complex or if customers will not use the product until both phases are complete, I wouldn’t recommend the phased approach.

Q: What would you tell a colleague considering a phased approach?

I’d tell them to take a hard look at your market, talk to people/companies and find out how they will use your product. If they’re willing to get started with limited functionality, it’s likely a good candidate for a phased approach.

5. Virgilia Pruthi – Product and Strategy Leader at Amazon Business

Q: What’s the best way to communicate a phased rollout to users?

Roadmaps are super tricky, especially for SaaS companies. From my experience, indicating what problem you will be solving or a theme is a way to ensure you don’t end up getting caught up in the solution early on.

As we all know, these things can change. Focus on the experimentation and less on the roadmap language.

Q: Should you specifically mention a phased rollout on the product roadmap?

I’m personally not a fan of anything other than a themed approach to features and architectural changes. Focus on what problem you’re looking to solve, and articulate to clients/customers what they can expect and why.

6. Dave Mathias – Associate at TigerRisk

Q: What would you say justifies a taking a phased approach to product features or architectural changes?

It is all about the customer. A phased approach is best when:

1. A major segment of your customers would prefer features or architectural changes to be phased
2. Each phase is geared at uniquely different customer segment and working on them in phases allows you to focus on one segment at a time.

View a phased approach from the shoes of your current and future customers and you won’t go wrong.

Q: In what scenarios do you recommend considering a phased rollout?

Generally I have used a Phase 1/Phase 2 timeline on a roadmap when balancing different customer priorities against limited resources. The key is to just make sure you break down each phased deliverable into a complete use case for a feature.

If a product is not attractive to your customers or future customers until a feature or architectural change is complete, then a phased approach is not the right option.

7. Michael Smart – Managing Principal, Egress Solutions

Q: When is the time right for a phased rollout?

If you have a complicated feature that can be broken into story points that stand on their own, you have a good candidate for a phased rollout. If the feature has dependencies, but partial functionality will gain market acceptance, you can still consider moving forward with it.

However, I would not recommend a phased approach for any feature that if delayed, might jeopardize the expected market acceptance or the expected market share growth.

Q: Do product teams ever scrap Phase 2?

Very often, phased rollouts aren’t completed. There are other times when the additional story points just get dropped. If this is in response to a conscious pivot or new market insight, that’s great! 

The Takeaway

There are always pitfalls to launching a new feature, but hopefully the experiences of these product leaders gives you a sense of what really needs your attention when you’re planning a phased rollout.  Got well-defined goals? Development themes? Have you set up proper expectations your customers?

Then you’re already on the right track.

---

This is a guest post by Matt Anderson, a product manager for a suite of mobile apps in Salt Lake City, UT and Alicia Dixon is Senior Mobile Product Manager at Hilton Worldwide.