Sami Surakka

I've spent years in product and design on B2B and high-stakes SaaS. In that work, a confused CSM on a customer call is not a soft-skills problem. It is a process failure. A pattern I keep seeing: a user hits something new in the product, asks their CSM what it is, and the CSM has never heard of it, even though the change was “announced” on an internal channel. The customer ends up briefing the product expert on what the product can do. Often that means a release process never happened.

The root confusion is treating deployment to production as releasing a feature. They are related, but they are not the same event. When teams treat them as one thing, product and engineering lose track of what users can actually see. Users and the people who support them then face a product surface that keeps moving without a clear story.

This piece is for product and engineering leaders. Continuous delivery is still the right default. Skipping release as a central part of the product experience is where things go wrong.

Deploy, live, release, launch

Clear language helps. Here is a ladder I use:

• Deploy: an event. Code is in production. It may be dark: behind a flag, not yet visible.
• Live: a state. Who currently sees the change (nobody, a beta cohort, 5% of orgs, everyone). Always say who. “It’s live” without an audience is as fuzzy as “we released”.
• Release: an event. An intentional product event: deliberate exposure, a named owner, and the people who represent the product can explain it. A beta or 5% ship is still a release, just a scoped one.
• Rollout: a plan. How exposure moves while the change is live: cohorts, percentages, a kill switch.
• Launch: an event. A release plus go-to-market for something big enough to need marketing and sales enablement. Not every feature needs a launch. If everything is a launch, nothing is.

Feature flags are a common tool, not the definition of release. You can release on a weekly train without flags. You can also flip a flag and only make the change live: no owner, no awareness, no notes. That is how continuous delivery turns into continuous surprise. Surprise is what we want to avoid on our own product surface. Treat it like another risk: bugs, unintended behaviour, and features nobody knew shipped are all surprises, and all of them create business risk.

PostHog’s Why you should decouple deployment from release makes the same core split: deploy puts code on production infrastructure; release makes it available to users. By default those become one step, so teams hold deploys until they feel safe to release. Flags and dark launches let you deploy often, test in production, hand the release to a PM, and roll out in stages. That is the right engineering move. Their handbook also separates release from launch much the way I do above.

PostHog solves the engineering half of this. The half I want to add is what happens after the flag is on. Making a change live for users without the people who represent the product being able to explain it is still only half a release. Separating deploy from release fixes the eng problem. It does not automatically fix the product one: ownership, acknowledgement, and a clear story for the org and the customer.

What the failure looks like

I have seen this in consulting and in product roles. On a legacy path that can only ship maybe once a week, stakeholders stay in the loop almost by accident. The weekly train is a ceremony that bundles “code goes out”, “someone is accountable”, and “the right people find out”. On a modern path, code deploys behind flags (good), then a developer might toggle the flag when they feel like it (uh-oh). There is little rollout control when nobody encoded it and made it explicit. Larger launches still typically get coordinated, because the risk is easier to see. The long tail of continuous delivery does not, and that is where PMs, QA, and CSMs lose track of the product they are supposed to own.

When a flag or feature has no clear owner, the surprise often lands inside the product org first. Someone stumbles on a long-awaited thing in production and is briefly delighted. Surprise can feel positive and still be unprofessional. When the surprise is not positive, that risk has already landed. Users are allowed to be delighted. The company should not be surprised by its own product.

When there is an owner but release still means “we posted in Slack”, the surprise lands on the CSM. Digital channels are full of noise. Writing something into a busy stream does not mean anyone received it. Announcement without acknowledgement is theatre.

This shows up most sharply in B2B, where a named CSM is supposed to be the expert on a call. In B2C the same deploy≠release confusion exists. It shows up more as tickets, reviews, and silent churn than as one embarrassing conversation. The argument is general, but I am looking at this mostly through a B2B lens, since that is where I have made my career.

Product maturity matters for how hard you can move the surface. Early products with a thin audience and habits still forming can shift more radically. Users expect change, and the cost of a wrong bet is often lower than the cost of learning slowly. Established products with a core audience are different. People have workflows, muscle memory, training, and tickets built around what you already shipped. Big shifts without a deliberate release burn trust faster than they buy speed.

A minimum bar for a small change

Before I would call a small, user-visible change released, the bar should match who is live and how mature the product is. A quiet internal beta on a new product does not need the same enablement as a change every CSM’s customers can hit on a surface they use daily. Continuous delivery stays. This is not a release train in disguise. Launch stays rare.

For something invisible, or a pure bug fix that restores expected behaviour: a named owner and a short note in the release notes is enough. No promotion, no CSM tour.

For something user-visible and customer-facing, I want more:

1. The people working on it know it is out: PM, engineering, design, and CSM when the change is customer-facing. The test is not “was on the PR” or “we posted in Slack”. It is: could they answer what changed and who gets it? without asking whoever flipped the flag. That is what I mean by acknowledgement, not an emoji on a thread.
2. There is a named release owner for that ship or toggle.
3. It is documented as release notes in a place people actually look when a user asks, not only in a channel that scrolls away.
4. If it is small but high value, the product surface promotes it. If it is a bug fix, no promotion. The fix is the experience.
5. When users will notice in B2B: the CSM (or equivalent) can be the expert on the call. An in-product cue helps users. It does not save the CSM who is hearing about the feature from the customer.

Not every change needs a broadcast. Every user-visible change needs a record and an owner. Sending a message without that kind of acknowledgement is just adding to the noise.

Bigger releases still need planning, coordination, and real communication. Launches need GTM on top. Release is part of the product experience, and that experience includes the people who stand between the product and the customer.

Pushbacks worth taking seriously

If this lands in a PD or eng leadership thread, these are the objections I expect, and how I would answer them.

• “This recreates waterfall / release trains”. No. Continuous delivery stays the default. Launch stays rare. The bar scales with who is live and how visible the change is. Friction without evidence is bad. Shipping without a loop is also bad.
• “That’s CS enablement, not product”. If the customer is teaching the CSM what the product can do, the product org lost control of its own surface. That is outcome ownership, not ticket routing.
• “We already have release notes / Slack”. Sending is not receiving. Worse, sending more messages potentially cripples the receiver. The test is whether the people who represent the product can answer without asking whoever flipped the flag.
• “Facebook / consumer products train users by shipping”. Sometimes true for low-stakes UI. The lens here is mostly B2B: workflows, training, tickets, and a named expert on the call. Not all SaaS is that shape, but a lot of it is.
• “Flags are the release process”. Flags are a tool for separating deploy from live. Without who, when, ownership, and awareness, you have only made the change live.
• “CSM ack on every small change doesn’t scale”. Agree, so triage. Invisible or pure fixes: owner + notes. User-visible and customer-facing: the acknowledgement test above. Match the process to how wide the change spreads. PostHog handbook addresses this by introducing tiered communications.

Deploy gets the bits into production. Release is when the product, the org, and the users are ready for what those bits do.

In a follow-up, Part 2: AI made deploys faster. It didn’t make releases happen, I look at why this gets harder as build and deploy accelerate, and how to read Cagan and the AI-native SDLC playbook as the next room over, not the whole house.