Your Release Velocity Is Not Your Customer’s Capacity for Change

We spent years learning to release faster. Now we need to get better at deciding when customers should feel the change.

Picture a daily user opening your product on Monday to find reorganized navigation. On Wednesday, the approval flow changes. On Friday, there’s a new default dashboard.

Every team involved may have made a thoughtful improvement. The customer has still had to stop and relearn three times.

I’ve spent my career watching the time between releases shrink, and it usually felt like progress. At Rosetta Stone, I saw physical CDs give way to subscription software, and annual releases give way to monthly cloud releases. At Front Gate Tickets, weekly releases were timed around festivals, where a badly timed change could affect people trying to get through a gate. On a B2B video conferencing product, I met customers who used the software every day and wanted their needs addressed every day. I understood the urge to move faster, and I still do.

But as AI compresses the time between an idea and working software, we’re approaching a different constraint.

Our ability to ship is growing faster than our customers’ capacity to absorb change.

1. Faster building means more change to absorb

The 2025 DORA research found that AI adoption now correlates with higher software delivery throughput, but also with continued higher instability (Google Cloud). Faster shipping with more instability can mean more change, and more rework, reaching customers.

Nielsen Norman Group describes how experienced users depend on familiar interfaces and automated routine behaviors, so even a better redesign can initially frustrate people who were already proficient (Fresh vs. Familiar). “But it’s more intuitive now” doesn’t settle the question. Someone who knew exactly where to click yesterday has to think about it today.

In B2B software, the interruption spreads: update the training guide, replace the screenshots, explain the change to coworkers. A small improvement for us can become a small project for them. We count the work saved by the new experience. We also need to count the work required to get there.

AI adds a second kind of change. A model update can alter outputs, tone, or behavior without moving a single button. The screen looks the same, but what customers can rely on has changed.

There’s no single threshold for every user or workflow. But we shouldn’t assume their capacity to adapt grows alongside our capacity to build.

2. Being ready to release gives us a choice

Continuous delivery keeps software ready to release. Continuous deployment goes further, automatically putting changes into production. Martin Fowler explicitly distinguishes the ability to deploy frequently from the decision to do so (Continuous Delivery). That distinction matters more as AI speeds up building.

You’ve heard “it’s coming in the next sprint.” I’m not suggesting we return to sprint-based releases or make finished improvements wait for an arbitrary calendar boundary. But our internal cadence shouldn’t dictate the customer’s experience, or become the language we use to explain it. Customers need clear expectations about what’s changing, when, and how it affects their work.

So keep software ready to release, and choose deliberately when and how customers experience the change. Fixes and performance improvements can reach people quickly. Changes to familiar workflows deserve a deliberate rollout, with previews, feature flags, or staged access.

“But our competitor ships AI features every week.” Customer-paced release is a proven model in enterprise software. Microsoft delivers Dynamics 365 in two release waves a year, publishes release plans ahead of each wave, and offers early access before general availability (Microsoft Learn). Salesforce has long used three seasonal releases a year. Their customers still get new capability, with notice and time to prepare.

3. Product leaders need a customer change budget

At Front Gate Tickets, the festival calendar made the consequences of release timing visible. An ordinary workday deserves that consideration too. I’d like product leaders to budget the relearning we ask of customers.

Five teams can each ship one reasonable improvement and collectively create an unreasonable week for the same person. Someone needs to own that combined experience, whether that’s product operations, a release council, or the CPO.

Before changing a core workflow, I’d want four answers:

What must customers relearn? Include familiar actions, defaults, and internal procedures.
What else is changing for these users? Look across teams at the workflows affected.
How will we bring them along? Give useful notice, a clear rollout window, and help when they need it. Design for familiarity wherever possible.
When will the benefit repay the disruption? Track task completion, errors, support contacts, and time to regain proficiency alongside adoption.

Three practical handles help: segment by who is affected (admins versus occasional users, new versus mature accounts), keep a shared change calendar across teams, and offer opt-in early access.

That won’t always mean fewer releases. Bundling everything into one large update can overwhelm people too. It means choosing the timing and size of visible changes around the people receiving them.

4. The user should influence the cadence

Customers shouldn’t just receive the pace. They should help set it. Opt-in rings, admin controls over when changes land, and customer advisory groups give them that voice.

Different users also need different things. In Your Next User Might Not Be Human, I explored what changes when agents operate software on our behalf. An agent using a stable API may benefit from an improvement immediately, though changes to contracts or behavior can still break it. A person relying on learned habits and a team’s established procedures needs notice and time. Our release strategies should reflect that difference.

I’m glad we stopped making customers wait for a physical box, and glad useful improvements no longer sit around for an annual release. The desire to help faster was a good instinct. It still is. Following it now means paying closer attention to what happens after we ship.

Your release velocity is not your customer’s capacity for change.