Deployment vs Release vs Launch: How they're different (And Why It Matters)
Most product teams use these words interchangeably. That's a mistake.
It’s important to understand what these terms mean, and how you can use them effectively in your Product Operating Model… but for the TLDR version, here's what they each mean:
Deployment: Code gets pushed to an environment, usually production, where it sits waiting. With feature flags (toggles), you can deploy code that users will never see until you flip the switch.
Release: Features become available to some or all users. This is what most people mean when they say "shipping". Example: rolling out a new checkout flow to 10% of users first, or making a new reporting feature available to enterprise customers only.
Launch: A big release with fanfare and public announcement. This needs serious coordination—press releases, email campaigns, sales enablement, customer success training, maybe even launch events. Example: Slack launching Slack AI, Apple announcing a new iPhone, or your company revealing a major platform overhaul with full media coverage.
The key difference is visibility, frequency and effort. A deployment can happen dozens of times a day with zero user impact. A release means users see something new, so you can do this generally daily depending on the complexity of the change to the user experience. Anything more than weekly means your releases are too big and introducing too much change to the user. A launch means you're putting your reputation behind it publicly, so you need everyone coordinated and ready.
Why People Mix Up These Terms
Historically, deployment and release were the same thing. You wrote code, you shipped it to users, everyone saw it at once.
Then feature flags changed everything. Suddenly you could push code to production without exposing it to anyone. You could deploy on Tuesday and release on Thursday. You could release to 5% of users, then 50%, then everyone.
This decoupling of deployment from release is what enables modern product development. But most teams haven't updated their language, or their processes, to match.
Deployment: Code In Production, Not Necessarily Used
A deployment is simply moving code into a production environment. That's it. The code exists on production servers but might never be seen by users.
This is possible because of feature flags (also called feature toggles). You wrap new code behind a flag that's set to "off". The code is deployed, it's sitting there in production, but no user will ever hit it.
Why would you do this? Because it lets you practice continuous deployment without continuous chaos. Your team can merge to main and deploy multiple times per day without worrying about half-finished features breaking the user experience.
Some people call this a "dark launch". Code is there, in the dark, waiting to be turned on.
From a PM perspective, you barely need to be involved in deployments. Engineering deploys, the feature stays hidden, life continues. No GTM planning, no user communication, no drama.
The risk profile is low. If something breaks you can roll back at a code level. Most users never knew the code existed.
Release: Making Features Available To Users
A release is when you make a feature available to actual users. This is what most people mean when they say "we shipped it".
You might release to everyone at once, or you might use a feature flag to release to a subset. Maybe 5% of users first (a canary release), then 25%, then 50%, then everyone. Maybe just internal users for a week (what I call a Champagne Brunch, an early chance to drink your own champagne). Maybe only premium customers. This is something that the top product led companies do well as a part of their Product Operating Model.
This is where Product Managers need to be heavily involved as you’re responsible for the value and viability of the product. You're putting something in front of users, which means you need some go-to-market (GTM) plan. Not a full GTM, but some. A successful launch is a key component to achieving the outcome.
That might mean updating help docs, briefing support, sending an in-app notification, writing a small blog post. The effort should match the release scope. Releasing to 5% of users needs less GTM than releasing to everyone.
The risk profile is medium. Users will see this. If you need to roll it back you can flip the feature flag off, but you'll need to communicate about it. Some users will have seen the feature and might wonder where it went.
For OKRs and measurement, this is what counts. You measure outcomes from releases, not deployments. A deployment changes nothing for users, so it can't move metrics. A release changes user experience, so it can move metrics.
Launch: Big Release With Big Fanfare
A launch is a special kind of release. It's a release you're making noise about.
You launch when the feature deserves attention. Maybe it's a major new capability, maybe it's tied to a marketing campaign, maybe it unlocks a new market segment. Whatever the reason, you're not just releasing it, you're announcing it.
Big GTM effort required. Press releases, blog posts, email campaigns, maybe even a launch event. Sales needs new materials, customer success needs new scripts, support needs detailed documentation. You might coordinate with partners, line up customer quotes, prep executives for interviews.
This coordination is why launches are expensive. Every launch pulls people away from other work for weeks. Most features don't warrant this effort.
The risk profile is high. Not necessarily technical risk (you've hopefully already validated that with a smaller release), but reputational risk. You've told the world this matters. If it doesn't work, or users don't care, or worse, it breaks publicly, that's a visible failure.
If you need to roll back a launch you're not just flipping a flag off. You're doing damage control. Public communication, probably some apologizing, definitely some scrambling.
Feature Flags: The Enabling Mechanism
None of this deployment/release separation works without feature flags. They're the technical mechanism that makes it possible.
At the simplest level, a feature flag is just an if statement. If flag is on, run new code. If flag is off, run old code. But good feature flag systems let you do more sophisticated things.
Martin Fowler's taxonomy is helpful here. He breaks flags into categories based on how dynamic they are and how long they live.
Release Toggles are temporary flags used to hide incomplete work. You're building a feature over two weeks, but you want to deploy to production every day. You wrap it in a release toggle, deploy it hidden, then remove the flag once the feature is done. These should live for days or weeks, not months.
Experiment Toggles are for A/B testing. Each user gets assigned to a cohort and consistently sees one version or the other. You run the experiment until you have statistical significance, then remove the flag. These typically live for weeks.
Ops Toggles let you turn off expensive features under load. Maybe your recommendations engine is great but slow, and when you're under heavy traffic you want to disable it. Some of these are temporary (for a new feature you're not confident about), some are permanent kill switches.
Permissioning Toggles control access to features for specific user groups. Premium features only for paid users, alpha features only for internal users. These can live for years.
Different toggle types need different management approaches. Release toggles should be aggressively removed. Permissioning toggles need proper admin UIs. Ops toggles need to be changeable instantly, not via redeployment.
But the core concept is the same. Feature flags separate the act of deploying code from the act of exposing it to users. That separation is what makes modern product development possible.
What This Means For Product Teams
If you're treating every deployment like a launch, you're moving too slowly. You're adding coordination overhead to things that don't need it. You're probably deploying less frequently than you should be.
If you're treating every launch like a deployment, you're creating chaos. You're not preparing users, you're not preparing internal teams, and you're probably shipping things that aren't ready.
The right approach depends on what you're doing.
For most work-in-progress code, deploy it behind a flag and forget about it. No ceremony needed.
For most features, release them quietly, maybe to a small group first. Minimal coordination, not much fuss. Measure the impact, iterate, then expand.
For the rare truly important feature, launch it properly. Full coordination, timing aligned with your strategy, the whole thing. But recognize this is expensive and save it for things that matter.
When you're setting OKRs, remember that only releases and launches move metrics. Deployments are invisible to users. Don't celebrate deployments as if they're outcomes. Celebrate when users see value. In the Product Operating Model, empowered teams measure progress based on outcomes users experience, not technical milestones.
When something goes wrong, understand which type of problem you're dealing with. A bad deployment can be rolled back quietly. A bad release needs user communication. A bad launch needs crisis management.
The language matters because it shapes how you think about risk, coordination, and velocity. Teams that understand the difference ship faster and more safely than teams that don't.
