How to Tell a Launch From a Release
FOR MANY BUSINESSES, THE LAUNCH PROCESS hasn’t changed as they’ve implemented agile or gone to the cloud. It still looks something like this: Overhead and activity dictate arbitrary milestones and dates that center on delivering content and features, which, of course, the market will embrace and users will adopt. It’s the old, “The product is done; it’s time to launch.” No one asks if the business is ready, the channel is enabled or if the market even cares about the release.
Releases Aren’t Launches
As organizations improve execution and delivery within their engineering and build processes, the sheer volume of features and content delivered increases accordingly. But constant delivery of new stuff doesn’t necessarily mean you’ve created something significant enough to be launched as a “market event.”
Market events need to make your product more competitive, deliver increased satisfaction and improve profitability. A launch needs meaningful, measurable goals that deliver incremental benefit to the key buyer and user stakeholders. If it doesn’t meet this standard for a market event, you have yourself a release, not a launch—plain and simple.
When a Release Becomes a Launch
Teams involved in high-frequency development environments often get stuck in the repetitive and rigid go-to-market activities that they’ve always done. A launch job comes in, they run the playbook and voilà, another successful launch, right? But if no one stops to think whether this will be of value to anyone, or if the right amount of noise is being made for the right release, customers will perceive everything as being of the same value. Whoops.
Too bad that major market event looks just like the security update you released last month. Or worse, your customers stopped listening long ago because they’re sick of your level of engagement.
Here’s the secret: Even though you’ve finished a feature, you don’t need to tell anyone. Put the solutions in production and give yourself the opportunity to observe usage, engage users who organically adopted the feature and interview them to validate messaging. Maybe even recruit some users to aid in creating awareness when you do go to launch. This is sometimes referred to as canary testing. You put a set of production-viable code in place for a subset of your users—or even your whole user base—and wait and observe the results.
Finalizing the Launch Window
As the team works to deploy releases and finalize iteration plans to deliver on the overall promise of the release plan tied to your roadmap, cross-functional engagement and readiness plans should begin.
In other words: If the product has significant capability that the market will embrace, and you have market validation of the message and problems, only then can you set a launch date with stakeholders, both in the market and in the business, with confidence and credibility.
Release vs. Launch
As an organization’s ability to execute on release plans continues to improve and accelerate, it is increasingly important to differentiate between a release and a launch.
A release is a viable set of content and features that the market uses. But a launch—with its full set of activities, organizational impact and market noise—needs to be more. It must be used only when there is a collection of features and capabilities that can increase awareness, strengthen or extend positioning, and create momentum in the channels and market that will help the business achieve its goals.