Deployment vs Release for Product Managers

Deployment puts a version of software into an environment, such as production. A release makes a change available to its intended users. The two can happen together, but teams can also deploy code and activate a feature later. This separation lets them check the running system before widening access, provided the architecture supports it.

For a Product Manager, “it is in production” can therefore leave an important question unanswered: who can use it? A checkout improvement might be running on the servers while remaining unavailable to customers. Scheduling a campaign around the deployment date without checking the release plan could send people to a feature they cannot access.

Deployment and release describe different changes

A deployment changes what is running in an environment. It may introduce application code, configuration or infrastructure changes, and the destination may be a test environment rather than production. Deployment checks establish whether that change has been applied and whether the system is behaving as expected.

In this article, release means making a capability available to a defined audience. Teams also use “release” for a packaged version or a named milestone, so the terminology should be agreed locally. The useful distinction for planning is between installing a change and exposing its behaviour to users.

Deployment and feature release in product planning
Question	Deployment	Feature release
What changes?	The version or configuration running in an environment.	Who can use a capability and under what conditions.
What confirms it?	Deployment completion and checks on the running system.	Eligible users can access the intended behaviour.
Can it happen gradually?	Yes, for example by replacing instances in stages.	Yes, for example by enabling a feature for selected accounts.
What can go wrong?	A new version fails to start, slows shared services or breaks compatibility.	The feature misbehaves for eligible users or produces an unexpected business outcome.

A successful deployment gives evidence about the running system, but it cannot establish every business outcome. Health checks may pass while a promotion applies the wrong discount to a particular basket. Conversely, a hidden feature can still cause a production incident if its deployment changes shared code or the database.

A checkout promotion, from deployment to availability

Consider a hypothetical launch at Mercato, a commerce platform. Product wants to introduce a delivery discount for eligible customers. Engineering implements the calculation and places the new behaviour behind a feature flag: a configuration-controlled decision in the code that selects which behaviour runs. The backend enforces eligibility and the discount; hiding a button in the browser would not be sufficient.

The team deploys the new version on Tuesday with the customer-facing flag disabled. Existing customers continue through the previous checkout path. Engineering checks that the version is healthy and uses a controlled internal configuration to exercise the new path. This requires planning both paths; adding a flag does not automatically make the inactive version safe.

On Wednesday, the team enables the promotion for a small, defined group of eligible accounts. This is the first customer release of the feature. A stable account-based selection keeps the experience consistent across repeat visits, while the backend preserves the agreed treatment of a checkout already in progress. The group size is a decision for this example, not a universal percentage for safe releases.

Deploy the new version with customer access disabled and check the existing checkout.
Validate the new path under controlled conditions, including eligibility and the final order total.
Enable access for the initial customer group and observe technical and business signals.
Expand access only when the agreed checks support it; pause or recover if they do not.

The promotion’s public announcement belongs alongside the availability plan. If only the initial group can use it, marketing and support need to know that limitation. The team should also record which version of the offer a customer saw, so a support agent can explain an unexpected delivery charge without guessing.

Gradual exposure needs evidence and an owner

The Mercato team monitors checkout errors and payment failures, but also verifies that discounts reach eligible orders and that margins remain within the agreed limits. An increase in completed orders would be difficult to interpret without checking traffic changes and the customers receiving the offer. A gradual rollout controls exposure; it does not automatically constitute a well-designed A/B experiment.

Before increasing access, the team needs enough observation to include relevant behaviour, such as returning customers and orders completed after a delay. There is no fixed waiting period that suits every product. A high-volume checkout and an enterprise process used once a month provide evidence at different speeds.

The release plan should name the person who can expand or stop access, the signals that trigger a review and who responds outside normal working hours. A flag change can affect production immediately or after a propagation delay, depending on the implementation. That behaviour and the fallback used when flag configuration is unavailable need to be understood before launch.

Turning a feature off and rolling back a deployment

If the promotion produces incorrect discounts, disabling its flag can stop the guarded behaviour for subsequent requests once the configuration takes effect. The deployed version remains in place. The team still needs to address in-progress checkouts, discounts already granted and orders already paid. Changing the flag cannot undo those business events.

A deployment rollback returns the relevant component to an earlier version or configuration. That may be necessary if the new version breaks shared checkout logic, even when the promotion flag is off. It also has limits: restoring application code does not automatically reverse a database migration, cancel queued work or recover data written in a new format. Compatibility determines whether the older version can run safely.

For Mercato, a recovery plan could stop new promotional checkouts, preserve the terms already accepted by customers and investigate affected orders. Engineering might then restore a compatible version or deliver a corrective change. Product and support need to agree on how to handle incorrect charges separately from the technical recovery.

What to agree before announcing a date

A release discussion can use the customer journey as its reference. That makes it easier to distinguish the version running on a server from the behaviour a customer can actually use. These questions help turn the distinction into launch requirements:

Does the date refer to deployment, first customer access or availability for the full intended audience?
Which accounts are eligible, and will the same customer receive a consistent experience?
Which checks must pass before access expands, and who makes that decision?
What continues running when the flag is disabled, including background work and in-progress transactions?
Can the previous version still work with the current data, and what requires a separate recovery action?
Who will remove temporary flags and the unused code path after the rollout is complete?

Mobile applications add another dependency: a deployed backend change does not install a new app version on every device. Store approval, installation and compatibility with older clients can constrain availability. The release plan should describe those limits explicitly when a feature depends on an updated client.

The guide to CI/CD and releases explains the wider pipeline, environments and automated checks. The book CI/CD and Releases for Product Managers develops these delivery decisions in more detail. For the consequences of dependencies between components, see the software architecture guide.