Release ≠ Launch
Hey I’m Ant and welcome to my newsletter where you will find actionable posts on topics related to product, business and leadership.
You might have missed these recent posts::
- Building Effecive Product Roadmaps
- Long Backlogs and Unmeasurable Work
- Break Outcomes Down, Not Initiatives
My day job is helping companies shift to a Product Operating Model.
My evening job is helping product people master their craft with Product Pathways.
If video is more your thing, check my Youtube channel out!
There’s an untapped opportunity I see in many companies.
They deploy, release, and launch all at the same time.
(If that’s you, keep reading!)
Now you may be thinking - what’s the problem?
Let me pull out the woodfire + armchair and explain through a tall tale.
The onboarding product team have been working frantically this sprint, trying to get their next release out on time.
Today, they’re going through their release checklist, making sure they dot their I’s and cross their T’s.
But they notice that key production configurations are missing—there’s no way they can deploy without them.
It’s T-minus 24 hours from go-live, and the release is looking doubtful.
The Product Manager breaks the bad news to the stakeholders.
The Product Marketing Manager (PMM) couldn’t believe what she was hearing.
Her go-to-market (GTM) team had also been working tirelessly to get all their launch activities in order. Their scheduled videos and social posts were the least of their concerns. They had lined up a live launch event with their current customers, which there was no way they were going to postpone.
The GTM team express their frustration and reiterated the they had ensured the teams were aligned for the last several weeks.
Of course, this highlights one of the many issues with dates.
But, were dates the root issue here?
Or was it perhaps, that we had too many things dependent on each other?
I lean towards the latter in most cases.
Because I’ve seen companies try to solve this by avoiding giving release dates ahead of time, which I’m all for!
But things still blow up in the end.
Frustration brews as the uncertainty makes it hard for dependent teams to plan ahead.
When the call finally comes, those dependent teams kick up a fuss about being notified at the last minute and having little lead time.
GTM teams are often the ones shouting that they have insufficient time to truly plan an effective launch.
The cost is less than the ideal outcomes.
Of course, we could also hold out until every party is ready, but then we end up in this long water-fall chain where one team waits for the other to finish before they can start.
In these cases, lead times blow out.
Whichever way you cut it, it’s not an ideal situation.
Now, in almost all complex systems, there are multiple root causes to any given problem.
But the key contributor is bundling deploying, releasing, and launching together.
Let’s first clear these terms up because a few different definitions are floating around:
Deploy = is the process of making software available on a target environment. This could be a production environment, but it also might not be.
Release = is still a technical activity, but it’s where you make the newly deployed changes available to your users.
Launch = is a strategic (non-technical) activity where you inform the market about specific features and changes.
Why you should decouple them
Hopefully, by now, the need to decouple each of these is obvious, but let’s explore why a bit deeper.
Deploy:
Deploying is purely a technical activity.
Depending on your engineering practices, deploying can be done at any time, to any environment. Including production.
Ideally, we should deploy early and often.
With good CI/CD practices, deploying can be automated and happen anytime Pull Requests are approved.
This helps us reduce risk as we only ever introduce small changes at a time.
The key difference here however is that just because we deployed something doesn’t necessarily mean that it’s visible or accesible to users.
This is where releasing comes into it.
Release:
Releasing is still a technical activity; however, it is the act of making a new change available to your users.
This can be done at the same time as deploying - but the key is that it doesn’t need to.
It should be a choice.
If it’s not a choice then you’re carrying risk as you have to do both at the same time.
Meaning more change + more complexity = more risk of something going wrong.
Practices like feature flagging, versioning and others help us decouple the two. Allowing us to hide functionality from our users until we decide to make them availible.
In doing so we can also leverage practices like gradually rolling new functionality out to your users.
Deploying would be moving the new code into production.
Releasing would then be gradually rolling the new functionality out to your users.
This is a common practice that many companies leverage.
Ideally, we want to avoid big-bang releases.
By gradually rolling out new functionality to our users (e.g., 5%, then 10%, then 25%, then 50%, etc.…), we again reduce risk in two ways.
If something goes wrong, it’s only going to affect a small number of users rather than everyone.
We also reduce desirability and usability risks as we can test and improve features before rolling them out to everyone.
Decoupling these two allow you to deploy to production in small batches (even parts of new features) and then release it to your users when it makes sense to do so.
Which brings me to launching 🚀
Launch:
Launching is a strategic activity.
It is where you actively communicate and market something new to the market and your users.
It’s easy to confuse launching with communicating a release with your users however, launching is a different beast entirely.
Many well-known companies run big launch events every year:
Apple’s famous yearly launch events (WWDC for developers earlier in the year and the common iPhone et al launch in September)
Shopify host two major launch events a year, one in winter and another in summer.
Pendo run a conference/launch event called Pendomonium each year.
Canva also run an annual launch event known as Canva Create.
Credit: Canva Create 2023Now while it’s hard for Apple to release their iPhones before the launch event. Software businesses like Shopify, Pendo and Canva can release new functionality as often as they want before the launch event.
Of course, you may want to keep some of your cards close to your chest and hold them for the launch event, but decoupling these activities makes that easier to do.
Imagine deploying all the new features months in advance before the launch. And on the day all you have to do is simply turn them on?
So much less stress!
Decoupling the two also means that we can release whenever we want and launch at strategic times where it will have maximum impact.
For example, Apple host their iPhone launch in September deliberately.
Think about it - it’s right before the shopping season with Christmas and Black Friday sales.
It would be far less impactful to launch the new iPhone in February, only weeks after people just bought the outgoing edition as a Christmas present.
Most businesses have logical peaks and troughs throughout the year. They know when it’s busy in their industry and when it’s quiet.
Effective launches capitalize on these peaks.
This is fundamentally different from releasing because you can release something without communicating it to your users.
You may choose to do so if the release was only minor, like UI improvements and/or bug fixes.
Alternatively, there may be times when you want to release something ‘silently’, also known as a ‘stealth launch’.
There are a number of reasons why you might want to do this - which I won’t get into here (a topic for another day, perhaps).
There are also times when the release is too small to really warrant a launch.
Instead, you may communicate with your users either through product tours or email comms.
Practitioner Insights
Decoupling deploying, releasing and launching can be a huge unlock for your company.
Major launch events, like Canva Create and Pendo’s Pendomonium, are only possible when these things are decoupled.
It can also help alleviate challenges of deadlines and alignment and enable activities that help you reduce risk.
The product person in me views this in a very similar light to tackling product problems.
We’re simply breaking the problem down.
Let’s get deploying sorted first.
Q: How good are we at putting new code into environments?
Once that’s ticked, then we can look to turn things on for our users when it makes sense.
Because while we want to deliver fast and frequent changes to our users, we also don’t want to bombard them - not least with half-baked features!
Not to mention, scenarios where the feature might be developed but you might need another day or two to finish compiling supporting materials like guides, videos and comms.
This is common in B2B sales companies as there’s often additional work to train and educate sales and support staff before releasing.
When these activities are decoupled, you remove the dependency.
We can deploy when the development is done.
Release when we’re ready to do so.
And launch at strategic times to maximize impact.
Need help with scaling your product or business? I can help in 4 ways::
Level up your craft with self-paced deep dive courses, FREE events and videos on YouTube, templates, and guides on Product Pathways.
1:1 Coaching/Mentoring: I help product people and founders overcome challenges through 1-hour virtual sessions.
Consulting and Advisory: I help companies drive better results by building effective product practices.
Private Workshops and Training: I run practical workshops and training courses for product teams globally.
Top Posts
Your OKRs don’t live in a vacuum.
Yet this is exactly how I see many organizations treat their OKRs.
They jump on the bandwagon and create OKRs void of any context.
Here’s what I see all the time…