How to Launch Products in a World of Continuous Delivery/Deployment
Delivery is an internal activity, Launch is about making an initial impact in your market
I was asked a question recently about how companies should execute product/release launches in the context of a continuous delivery environment.
i.e. how can we “wow” the market with a product launch when there is a continuous trickle of new features and functionality coming out of Engineering?
To answer this question, let’s dig into these concepts.
What is Continuous Delivery?
Continuous Delivery (CD) — often spoken about in the same context as Continuous Integration (CI) and usually written as CI/CD — is a software development approach that focuses on working on small “chunks” of software, testing them and ensuring they can be deployed to production when needed.
I’ve emphasized the word deployed, because there is a distinction between delivery and deployment. Delivery is an internal process output. i.e. the engineering team works in a way that they are regularly delivering new product capabilities or updates that can be deployed to Production when needed. This kind of working process often falls under the name DevOps.
What is Continuous Deployment
Deployment is the process of moving working code into production. i.e. for a software product, making it available to your customers and users.
Continuous Deployment (CDp) is the automated and ongoing process of moving delivered code into production.
Deployment should be a business decision based on what is best for the product, the business, customers and the market.
I’ll get into this a bit more further in this post, but this distinction of delivery (internal readiness) and deployment (external availability) is important to understand.
Just because your engineering team is working in a Continuous Delivery model, that doesn’t mean your software has to be deployed in a Continuous Deployment model.
I like the above diagram because it separates and distinguishes delivery vs. deployment and that is important. One could have Continuous Delivery but have a manual or non-Continuous Deployment* process.
*NOTE: Without getting too specific, a company could have a Continuous Deployment process for all software, but use Feature Flags (or Feature Toggles) to hide certain features from public access until the appropriate time. The point being that the decision to expose users to specific capabilities is independent of the software development model and is a business decision. i.e. when and how users/customers can access deployed capabilities.
Why wouldn’t you…..?
Now, I’ve had debates with a few people on the following point; most often Engineers or possibly DevOps advocates.
Why wouldn’t you deploy the software if it has been delivered? It only has value once it is accessible to and in use by customers. Every day it sits undeployed is waste. Etc. Etc.
While on the surface this sounds true, it is in fact not.
And this is where the crux of the problem lies. It’s a philosophical disagreement or misalignment on the value of when to deploy. Here’s the example I use to make the point clear.
When does the market need the software?
Imagine a software company whose product is only needed during a certain time of year. Two examples that come to mind are tax software and seasonal sports management software (e.g ski schools in winter or summer sports leagues etc.)
Let’s use the tax software example. Now imagine a company like Intuit that makes TurboTax. We all know when tax season is. In the US and Canada it in the first few months of the year, with tax filing deadlines in April (for most people). In other nations it may be at a different time of year. But regardless of country, there is a SPECIFIC TIME of YEAR when we do our taxes.
The current tax year version of TurboTax MUST be ready and available for tax season. As a modern software company, let’s assume Intuit uses a CI/CD method of software development. Does that automatically mean they DEPLOY TurboTax in a continuous manner throughout the previous year?
NO! Of course not.
They wait to deploy it when it makes business sense and that is to deploy it just before tax season. And if it’s true for TurboTax, it can also be true for your company.
Engineering can continuously deliver, but you deploy when you’re good and ready!
What are we Deploying?
When it comes to deployment, there are lots of ways to define what to deploy. In Continuous deployment, any bug fix, patch, incremental enhancement, minor feature or major feature could get deployed as soon as it’s delivered, or may be bundled up if warranted.
To keep things simple, let’s consider 3 types of releases that could be deployed.
A Bug Fix (patch) or maintenance release would likely be deployed as soon as it was available to address bugs, close security holes or immediately fix whatever issues it was developed for.
A Minor release could be a single “feature” or a small set of functionality. Often small features can be deployed when delivered with some small announcement or other notification to customers. There may be reasons to hold a small feature from being immediately deployed. e.g. internal rules about when deployments happen, sensitive time periods etc.
A Major release is a broad or significant set of functionality that provides significant value to customers and the market. To maximize the benefit to the company of a major release, a launch needs to be defined, planned, coordinated and executed effectively.
When is the best time to start Launch Planning?
I ask this question in a launch workshop that I give. I’m always curious to hear the answers people give. Often it’s something like:
- one month before launch
- two months before launch
- etc.
The audience is usually comprised of Product Managers and Marketing team members. The reality is that, regardless of the type functionality (Maintenance, Minor, Major etc.) the deployment AND launch decision should be made when the functionality is planned.
In fact, there should be some very well understood policies in place for Maintenance and Minor releases to decide if they are automatically Deployed or not, or when the will be deployed if not upon availability.
With respect to Major releases, I’ve never seen a Major release that didn’t include some form of Launch activities. And Launch planning, even at a macro level should start during product planning.
Why?
Because major functionality represents significant investment by the company and demands a maximum return for the company. Launch should NOT be an afterthought but a coordinated effort aligning the product with market needs and demands.
But we’re Agile….
When explaining this in the workshop, I sometimes get comments like:
That diagram looks very linear and Waterfall. We’re Agile and we don’t work that way.
If I had a dollar for every time I’ve heard the “We’re Agile…” line, well, lets’ just say I’d have a lot of dollars.
It’s a diagram. It’s explaining a point. The point is that Launch is a key business activity and investment. It is key activity to coordinate teams, define and communicate positioning, messaging, benefits, to make the market (customers, partners, press, analysts etc.) aware of the product or new capabilities and other initiatives the company is performing.
Launch doesn’t care whether you are Agile or not. Launch cares about doing what’s best for the company and product. And if you work on the product you should understand that basic fact.
Marketing (including Product Marketing) and Product Management should work together during the planning of any major new product capabilities to ensure the two teams are aligned on objectives, the capabilities and the potential value to the company and the market. This gives Marketing the time and runway to build and execute effective launch plans.
But we’ve already deployed some features
Another comment I hear is about the fact that some “features” defined in the Launch have been deployed already.
Launch isn’t about “features”. We often see launches ahead of feature availability, so why is it a problem if Launch comes after some “features” have been released?
In fact, the more you talk about “features” the less you understand about Launch.
Launch is about:
- aligning your company (product, marketing, sales, services etc.) to maximize the impact of the product in the market
- communicating to the market, the customers, the users and the buyers
- capturing market mindshare and attention
Planning a Launch
As described above, for a major release, Launch planning should start with Release Planning. To help coordinate this, when I work clients, I use the following two Canvases to collect the important information up front.
These two Canvases don’t contain the entirety of the information needed for a Release or Launch, but they cover key information to get clarity and alignment up front.
The middle rows in each Canvas
- Release Planning — Personas, Product Capabilities
- Launch — Key Messages, Key Marketing Programs
should be aligned. You may not know all of this up front, but WHO you’re building for (and marketing to), WHAT your building, WHAT benefits you’re providing and HOW you’ll convey and enable that are all related.
And regardless of exactly when your Engineering team delivers or when you decide to deploy, the alignment of between Engineering, Product Management, Product Marketing and Marketing should be paramount.
NOTE: Contact me if you’d like PDF copies of these Canvases.
In Summary
How your company develops, deploys and delivers software only matters to your company. The frequency and substance of what you deliver is what the market cares about.
Deliver software to the market in a meaningful and methodical way and educate the market via a coordinated Launch to maximize the impact that investment makes.
A little feedback please
If you’ve read this far, thank you. I’d like some feedback on the article to make it better. It should take just 1 minute, but will really be valuable to me. Thanks in advance.
===> Click Here <===
