The introduction of new features, products, and services is a crucial component of any company’s lifeblood — and a key driver for growth. A recent article by McKinsey & Company noted that, across all industries, more than 25% of total revenue and profit stems from new product launches. Furthermore, organizations that concentrate on developing new products and services while maintaining their core business models grow much more rapidly than their peers.
And yet, developing new offerings on a regular basis is not for the faint of heart. As even the biggest brands in the world can attest, the process can be fraught with disruption for external customers as well as internal teams. So, how does a savvy product management team strike a balance between delivering constant innovation and ensuring a healthy customer experience?
After spending more than 15 years in the product management arena, I believe the key lies in this philosophy from Marty Cagan of Silicon Valley Product Group: “Good teams celebrate when they achieve a significant impact to the business (outcome). Bad teams celebrate when they finally release something (output).” In other words, merely tossing a new feature or product into the marketplace is not a milestone if it fails to deliver the intended value while wreaking havoc on your user experience and team morale.
For that reason, my team at WebPT, a cloud-based clinical documentation and business platform for physical, occupational and speech therapists, developed a launch technique we’ve dubbed the “10/10/10 strategy.” This method allows us to continuously roll out new products and features to our user base of more than 100,000 customers while also maintaining organizational readiness, increasing user adoption, and easing the impact of new releases on pricing and packaging. Read on to learn how and why this technique works.
Rapid development + user-wide launches = internal challenges
Before I dig into the “what” of WebPT’s 10/10/10 rollout technique, let’s first discuss the “why.” Before we created a better way to do things, the rapid production and delivery of new features to our entire client base caused a bevy of challenges across multiple internal teams. For example:
1. It saddled our member support team.
When you release a new feature to almost 100,000 users at once, you’re bound to unearth user issues like slowness or disrupted workflows. These unhappy clients then pick up the phone and call customer support. Our customer-facing teams were frustrated for two reasons. First, they were inundated by help requests. Second, they didn’t really have a solid understanding of those new features prior to their release due to the rapid launch cycle.
2. It pained our product management team.
When your goal is to introduce a feature in the shortest cycle time possible, you put a lot of focus on delivering a minimally viable product (MVP). Unfortunately, the pressure to deliver faster often results in products that are more minimal than viable. At WebPT, our user base runs the gamut from small, single-user organizations to large enterprise groups. These customer segments use the product differently. Also, they have different levels of risk tolerance if a new release doesn’t meet their needs. Before we adopted the 10/10/10 plan, the product management team struggled to balance the needs of our bleeding-edge customers with those of our bigger clients. It was a no-win situation.
3. It troubled our training and education team.
Let’s face it: it’s pretty difficult to create support materials and customer messaging before you’ve completed—and live-tested—a new product. Back when we rapidly delivered new features to our entire client base at once, our member education team was constantly playing catch-up, sprinting to craft communications in real-time as customer issues and feedback came in.
4. It threw our engineering team for a loop.
The bottom line is that, no matter how well you design a product or feature, you never really know how it’s going to be embraced until it goes out into the wild. Ideally, you want to get an MVP to market quickly, but then allow a small group of customers to test it. That way, you can and iterate on it to ensure viability for a full release. Skipping this crucial step caused a lot of disruption for both our clients and our teams.
The 10/10/10 rollout strategy
Prior to implementing our new rollout strategy, WebPT rapidly developed features and then introduced them to our entire user base at once. I’ve already explained how this philosophy impacted our team. Equally important, though, is the way it affected our customers. For example, a few years ago we rolled out a new driver for our medical document scanning software. This update worked perfectly for the customers who were complaining about the old driver. But for the rest of our customers, it didn’t work at all. So basically, we were creating problems for some users. And there was no way for us to know that these issues would occur until we actually released the update. However, if we had gradually introduced it and then quickly iterated as we received feedback, we wouldn’t have caused so much disruption.
Now, we didn’t just wake up one morning and decide to burn all of our ships. Rather, as we constantly sought to improve our rollout process, we dialed into a staged release method that we now call the 10/10/10 strategy. Here’s how it works:
Stage 1: 10 customers (early access)
Once a feature is built and ready for use, we release it to about ten customers. Typically, these clients were involved in the product development process. There is no “average” user at this stage. However, we don’t want to include clients whose requirements are either too specific or too generic. What we do want from these initial testers is transparent, real-world feedback on how the product is fitting into their environments and workflows. We establish product champions, identify specific fit failures, and address design gaps.
Stage 2: 10% of our user base (limited release)
Next, we roll out the product or feature to 10% of our client base. Typically, we try to choose a diverse cross-section of customers. At this stage, our operations and product marketing teams are engaged and building out support and enablement tools. We monitor support tickets and begin assessing product stability and scalability. At this point, we also collect feedback about edge cases that we might have missed in the early access stage. Additionally, we may elect to rework a high-usage product or feature if it’s causing performance issues.
Stage 3: 10x (full release)
Finally, we release the product or feature to all of our customers (10×10%, or 100%). At this stage, we feel comfortable with the feature. We now begin monitoring KPIs associated with user adoption and expected value. The full handoff to our product marketing and operations teams occurs. It becomes less about the product performing correctly and more about educating our clients. We pay careful attention to features that require our clients to do something differently, like toggle a switch. We use a variety of tools to communicate these changes with customers, including Pendo for in-app messages and usage feedback.
The result: improved KPIs and customer experience
Since introducing the 10/10/10 approach at WebPT, we’ve achieved a number of positive outcomes, both internally and externally. They include:
Increased user adoption
Before we began using this technique, we had a limited window of time to fix problematic feature workflows. And if a client has a bad experience with a feature the first go-round, it’s 10 times harder to get that client to try it again once you fix the problem. Now, we segment our launch to a smaller group of testers before we go to the masses. This ensures that the vast majority of users have positive first-time experiences with new functionality.
Improved organizational readiness
Introducing new features in a staged manner gives our team members time to learn more about the offerings and build a library of training and educational materials. Psychologically, it’s just easier for them. They feel more ready because they’re used to the feature and are able to change their processes between the early and full releases.
Decreased impact on product pricing and packaging
One issue with the frequent deployment of features and functionality is that users constantly see small incremental changes. And over time, they come to expect those changes. This can cause friction when you update your pricing and product packaging. Customers don’t want to pay extra for features that you’ve been slowly fixing and refixing. Even if the end product is the same, they don’t experience the immediate value-add that comes with a single launch. But the 10/10/10 approach allows us to go through the iterative phase with only a small set of users. Then, we can package up the feature and market it as something brand-new to the majority of our client base.
Frequently and rapidly launching new features and products is a whirlwind process for even the most highly regarded product teams. Yet, for companies that have any hope of scaling, it’s an imperative organizational mission. At WebPT, we’ve capitalized on an extremely cohesive partnership between our product and engineering teams to mature a technique that brings our clients and internal staff the most gain for the least pain. And we’re not done yet. We’ll continue to scale our 10/10/10 technique to produce even better business outcomes for everyone involved.
