Do you REALLY need a Rollout Strategy?
Do you really need a rollout strategy? Of all the ones out there, how do you know which one suits you best?
If this was the late 90s or the early 2000s, most would have been happy working on something of a feature, testing it with a handful of users that form a subset of the target audience & then releasing it at the end. But, we’re totally past all that & it is certain that such stuff wouldn’t fit in with the current scheme of things.
The question “How frequently do we have to ship features?” has been a subject of discussion for long, with the size of the user base, the size of the org., the stage of the product forming the stubs of the debate.
But here’s the thing. There just no single universal answer that holds good for all situations.
The reason for that happens to be very stubs listed there.
If the user base is very small the rollout could pretty seamlessly include the whole sample space irrespective of the other parameters
If the org. is itself small owing to how it is just in its early stages, it could still depend on the size of the user base, if it small it could be a full-on rollout otherwise it could be stage-wise
If it happens to be an already established product with a sizeable user base generating a solid revenue stream & this happens to be a new feature release, it could be done in stages by earmarking certain user groups sorted on descending order of CLTV
“It is NEVER about the quantity, because even over a race between quantity & quality it is pretty evident that the latter would beat the former hands down”
Over casual exchanges / discussions you may have come across how product managers seem to swear a lot by the cadence of releases quoting how they ship every week, or every fortnight, or thrice a month. As and when an onlooker hears that, they may begin to introspect about their release schedule.
“They’re shipping every week & that perhaps justifies their healthy DAU”
Diving a step deeper into that very metric <shipping every week>, one ought to put some thought into “WHAT are they shipping every week?”. And if that DAU as a metric really stands testimony to the product’s success, all eyes should be on their roadmap & the immersive research they may have subjected their products to so as to come up with meaningful EPICs & how they are able to flesh out winning features that resonate with the targeted user groups regularly over such short cadences.
Also, if anything, quantity is believed to carry a certain positive psychological bearing & is seen to take precedence when catering to a mass audience. But, if one analyzes it deeply, it is always the quality of a product that keeps the audience engaged for a long period of time. You can’t expect the users to keep coming back because you are offering an abundance of something (some (x)) as opposed to your competition. Yes, that would hold ONLY if you are prioritizing quality first & then optimizing the quantity thereof, given a certain price point of course.
So, it is the BENEFIT & the VALUE that collectively counts.
There’s always a motive behind everything because it would then make it easier & put every external & internal stakeholder, team member in the clear, aligning them over the outcome. Your rollout strategy ought to be strongly & deeply connected to how you want to test the solution on the users for overall fitment.
Here are some of the popular & commonly used rollout strategies:
1. HANDPICKED (set of people)
Before the solution gets out to the wider audience, it makes total sense to release it to a highly selective set of people / individuals who could be touted as experts in their own right, so as to test out a few hypotheses, help ascertain a few ideas, establish the cohesiveness between the problem & the solution towards measuring the validity of it all. Although there’s no hard and fast rule about the number, this could be ranging from a few (10s, 20 to under 100).
For ex: A restaurant could handpick a few loyal users & launch a new feature on their App allowing them to “CUSTOMIZE DISHES” before launching it as a feature to the wider audience.
2. SPECIFIC GROUPS (of users)
It is true that users may not be aware of their own pain points. But it is also true that nobody else would be able to understand a given problem better than the end users. So, it makes perfect sense to pick out a certain user group that would resonate with the problem better, launch the feature selectively to them so as to have a fair testing ground. Although largely dependent on the TAM & market segmentation, one could extrapolate this number to go from a few 100s to around but under the 500 mark.
For ex: A dating app could add a link sporting a handsome couple’s photo bearing the title “Got an upcoming date? Why not look like this?” leading them onto a feature called STYLE GUIDE that can suggest outfits based on complexion, face structure, hair style etc.
3. NETWORKS (Close Circles)
The amount of freedom one could have in terms of launching & testing out a feature within a close-knit group of people / a network / a community is often underestimated by most. If you think about it, there could be no better way to gain feedback from a certain specific demographic & yet so diverse a sample space given their multi-ethnic cultural backgrounds. This could be perceived as a number pushing 1,000 if not well above it.
For ex: Facebook launched the app ONLY to Harvard grads before throwing it open to the whole wide world
4. REGIONS (Specific / Hyperlocal Areas)
Proximity could play a major role in the problem, the markets, the target audience & could prove to be a great testing ground. It is possible that the problem & the solution resonate well with the personae who hail from a small pocket of a large city. Testing the whole solution there would then make sense as it could provide a healthy validation, which could then be extrapolated to the other pockets. Again, dependent on the TAM largely, one could perceive this number to fall in the range of a few 1000s.
For ex: Swiggy, a common name in the food delivery segment here in India earmarked a hyperlocal geography for release & tested it out thoroughly before they went for an actual launch with a wider coverage
5. ALL-OUT (full-fledged release)
Although very rarely used, at times when one has all the cards stacked in one’s favor, it could make sense to go for an all-out release to the wider audience. But, at most times this could be thought of as a follow-up to one of the 4 strategies discussed here earlier. As for this, coming up with a range may be tough given how it largely depends on the product itself. But, talking in percentages this could certainly be well above 90% closing in on the 100% mark.
For ex: A mobile-first payments app could think of a city-wide / state-wide / country-wide launch given their problem validation & solution fitment from the markets
“There NEVER could be a [ONE SIZE FITS ALL] when it comes to any strategy & rollouts aren’t any different”
But as you notice various rollout strategies discussed above, you also come to terms with the fact that they can’t be applicable across all situations. The situation could demand that the strategy changes given the control one’d want to enforce over the size of the audience, synthesizing the sample space for the release so as to be able to hit those touchpoints individually, gather ample feedback over all quarters as deemed necessary & factor it all in towards improving the product offering.
So, which strategy do you have to employ & how / when does that have to change?
Here’s a self-explanatory chart on how you ought to choose the rollout strategy.
Going by the chart here, if you’re looking for a rollout strategy over a [medium user base] that isn’t too small nor too large, you ought to be rolling it out to some [SPECIFIC GROUPS of USERS] who you think can resonate with the problem pretty well.
We used to do region based rollouts but that was because we tied subscriptions to the regions.
EU used to have the free tiers so we send it to them first.
It was easier to rollout by regions due to how AWS was setup.