Sami Surakka

In Part 1: Deployment is not a release I argued that deploy, live, release, rollout, and launch are different things, and that feature flags solve the engineering half of separating deploy from release, not the product half. This piece picks up where that leaves off. Continuous delivery is still right. AI made the cost of skipping product-side release higher, not lower.

Continuous delivery is not the villain

I would still choose continuous delivery. That lines up with how Marty Cagan and SVPG describe product delivery. Changing How You Build sets the cadence: every other week at minimum, several times a day for the strongest teams. In Transformed, Cagan is more specific still: product teams need “frequent, small, reliable, and decoupled releases that are instrumented and monitored”. That last clause is the precondition in achieving the mentioned frequencies. You cannot honestly aim for that frequency without instrumentation and monitoring already in place. Without them, “ship often” is just dumping more surface on users with no shorter path to evidence. The point of shipping often is shortening the loop between change and evidence, which means the product team’s work does not end at the release.

Small fixes can go out quickly with release notes and team awareness. When the product surface changes more, more coordination is required. Product maturity matters here too. Early products with a thin audience and habits still forming can move the surface 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.

If release is treated as a one-way operation where code leaves and feedback is someone else’s problem, the team pays later when it drowns in reactions it never planned for. Instrumentation is what turns frequent release into a learning loop instead of that trap.

The failure mode is not speed. It is treating “merged to production” or “flag on” as the moment the org and the customer were supposed to already understand what changed. Transformed is explicit that this requires releases that are decoupled, instrumented, and monitored. Decoupled here means separating the deploy from the release decision. That is the enabling condition. Staged exposure (5%, then 25%, then everyone, or the parallel and incremental patterns in Gentle Deployment) is one way to act on that decoupling once you have it. Without the setup Cagan names, and without treating release as a product event, “ship like the best companies” is just copying the cadence.

Why the misconception gets stickier

Engineering language already uses “release” for “production deploy”. Feature flags then made going live an individual action instead of a shared event. Chat made “we communicated” cheap to claim. Delivery metrics score the deploy. Lead time tracking often ends at the deploy step. None of that scores whether the people who represent the product can take in the change on time.

AI raised the stakes. Anthropic’s AI-native SDLC playbook is, for my money, one of the clearest current takes on deploy-side controls when agents write code. Once build accelerates, the bottleneck moves to plan, review, and deploy. Stage 5 keeps humans in the loop: hooks as approval gates, roles, and a named release manager authorizing production. That is real release control for the deploy path.

It also stops exactly at the production gate. There is little after “code is in production” about staged exposure, enablement, or whether CSMs and PMs can explain the change, and it does not discuss feature flags at all. Flags are how many teams already separate deploy from live. Without a product-shaped release around the toggle, the gate you just protected gets undone by someone flipping a switch when they feel like it.

So the playbook is the eng room. Discovery and intake sit before its Plan stage. Customer-facing release, rollout, and launch sit after Deploy. The product-side controls that have to exist alongside that deploy gate are the wider lens on the process.

The cartoon version of SaaS sounds like this: Facebook ships constantly, so we should not care much how people adapt, because that is how SaaS works. Facebook does ship constantly. It also runs an expensive rollout machine: flags, experiments, gated exposure, kill switches, research, in-product education. It is safe to say the big players put far more resources into this than most product orgs will ever have. Users still complain when the surface moves. The lesson is not “don’t care about adoption”. It is “measure adoption so you can change the product often without surprising yourself”. Copy the shipping speed without the setup behind it and you get cognitive fatigue, especially for B2B users with workflows, training, and tickets, not a feed they can ignore. The executive pressure underneath (“AI means we ship more, and adoption is the user’s problem”) is that cartoon with a new coat of paint.

AI helps with build and deploy speed. That does not remove the need for controlled releases. It raises the cost of skipping them. AI can draft notes, changelogs, and enablement. It cannot replace the decision that release is part of the product experience.

Pushbacks worth taking seriously

• “This recreates waterfall / release trains”. No. Continuous delivery stays the default, and for AI-accelerated development it is closer to a requirement than a preference. Launch stays rare. Match the process to how wide the change spreads, not to ceremony.
• “Cagan says ship continuously — you’re adding friction”. Transformed is explicit that teams need releases that are “frequent, small, reliable, and decoupled” and “instrumented and monitored”. Decoupled enables the release decision. Staged exposure is how you often use that decision. Naming release as a product event makes that pairing explicit. It does not walk Cagan back.
• “You’re misreading the AI-native SDLC playbook”. It does gate production deploys with roles and release authorization. I am not arguing it failed at its job. I am arguing its job ends at the deploy gate, and product-side release still has to live next to it, including staged exposure, enablement, and flags as a first-class concern.
• “Flags are the release process”. Flags separate deploy from live. Without who, when, ownership, and awareness, you have only made the change live. See the minimum bar in Part 1.

Deploy gets faster. Release is still when the product, the org, and the users are ready for what those bits do. AI can help here, too, but only when the distinction between deploy and release is identified.