Menu
Specifically in B2B, when some customers are reluctant to change, it is important to be able to stage features when distributing updates to your product. This is particularly true for incremental changes to an existing product.
Being able to work in an agile manner and continuously deliver product updates to an integrated environment, is as much state-of-the-art today as it is a prerequisite for successful deployment of product updates across large customer bases. If not done well, half-finished features will sit untested for too long and tech dependencies will pile up.
To deal with that situation, it is often helpful to refrain from continuous deployment (that is, frequent updates of the product being shipped to customers) and have explicit release cycles implemented during the Distribution phase.
On the one hand, that includes scheduled releases, on specific dates that have been announced earlier, with dedicated release notes, webinars, Q&A sessions, and related activities by the Product Management, Marketing, and Customer Success teams. During these events, new functionality can be announced to a wide audience.
On the other hand, however, it is essential to ship innovation features earlier. Not only for technical reasons, to avoid technical dependencies piling up (see above) but also in order to collect feedback from early adopter customers. The best way to combine both, stable products for the vast majority as well as quick feedback on innovation, is by gradually distributing the new functionality with feature stages.
Technically speaking, these are feature toggles inside the product which control which features are accessible/visible to which customers. Based on that, a model like the following has worked well for us in various environments:
A new feature or functionality is currently being implemented by the Engineering team. It is not accessible anywhere yet but only “lives” inside the product developer’s environment.
An early version of the feature can be demonstrated in an integrated environment, typically to internal teams only so that they can give feedback as early as possible.
As soon as the feature is stable enough, it can be offered to customers as part of an early access program. They might get access to dedicated test environments where they can test without risking any production data to be affected. Likewise, customers might have the ability to self-configure the relevant functionality so that they can effectively opt-in or opt-out at their convenience. Regardless of the details, it is mission-critical that Product Management and Customer Success teams closely follow these early adopter customers, support them in their endeavors, and listen to any feedback.
When the new product or feature is ready for prime time, it can be made accessible to all customers. While there could still be configuration toggles to (de-)activate that feature, we have to ensure that customers can now act without further surveillance and guidance.