AI Made the Build Faster. It Didn't Make Users Faster.

When I managed Yahoo Mail, 225+ million people used it every month.

That number is not a credential. It’s a reality that changed how our team made product decisions and changes.

Add a feature, remove something, move a button. One to two percent of those users would send us feedback. Immediately. Sounds small until you do the math. That’s two to four million people, typing into a box, telling (or yelling) us something was wrong. Every single time.

Not only that, there are downstream implications — especially for the customer care teams. Not all of them were polite about it.

After a while, that volume of signal becomes its own kind of discipline. You stop asking “can we ship this?” and you start asking the harder question. Do we know who we’re shipping this for? And do they want it? How do we manage the transition? How do we introduce these features? When do we listen to feedback? When do we take it as input?

At that scale, you learn the difference fast. Some changes delighted people. Some emptied inboxes. The inbox-emptiers were almost never the changes we would defend hardest internally.

A velocity moment

We are in a unique velocity moment with AI.

Every operator conversation I have right now is some version of the same thing: Faster prototypes. Ten times the features per sprint. 5x, 10x, 50x. Teams who used to ship one thing a quarter, are now shipping one thing a week. The tools got dramatically more capable, and the throughput numbers prove it.

That part is real. I’m not here to argue with it. I think the upside is real and I’m doing it myself.

But throughput is not the same thing as velocity.

Throughput is what happens inside the building. Prototypes, features, releases per sprint. AI multiplied that.

Velocity is what happens to the user. The rate at which their product changes underneath them. Their muscle memory, their workflow, their morning routine. The thing they actually pay for.

The AI tools made the first one faster. They did nothing for the second one.

Operators will recognize this in their own vocabulary.

Every AI build conversation right now is tracking where the bottleneck moved. Build cost collapsed. Spec quality became the bottleneck. Then judgment. Then eval. Then review. Then approval chains. We’ve gotten good at identifying which step we just compressed and which one is now choking the throughput.

There’s a bottleneck missing from that list.

The user.

The person on the other end of all this compression has not been compressed. Their attention hasn’t. Their learning rate hasn’t. Their tolerance for change hasn’t. They are the same human they were before AI showed up, standing at the receiving end of a pipe ten times wider than it was a year ago. They just want to send their email.

The question every operator should be asking is the one nobody is asking.

How does the user react when they become the final bottleneck?

If you’ve shipped at scale

If you’ve shipped a product to more than a few million users, you already know everything I just said. If nothing else, it’s a good reminder in this new world.

You’ve lived the support queue spike on a Tuesday after a Monday release. You were in the standup having to explain why retention dropped half a point. You watched a 2% feature unsubscribe rate become a board-level conversation, because at your scale that’s 4 million people walking out the door. You’ve sat through an outage post-mortem. You’ve had to explain a revenue dip to your CEO from the release three weeks ago.

You don’t need the bottleneck framing to recognize this. You have been the bottleneck.

The startup voice in your feed hasn’t.

When somebody with two thousand users tells you to ship faster, they are not wrong for their context. They are just describing different physics. Two thousand users is a focus group. Two hundred million users is an institution and real revenue. The same release does completely different things at those two scales, and the discipline that lets you compound at the second one is mostly invisible at the first.

Most of what I read about AI velocity right now is written from the first scale. Most of the people who actually have to live with the consequences are operating at the second.

Some change is good

I want to give the counter-argument its full credit, because it’s a real one. That’s how good products get even better.

Some change is good. Users do adapt. The AI features that have actually landed at scale, the ones people kept, did not come from explicit user requests. Nobody asked for predictive text. Nobody filed a ticket for smart compose. Nobody ran a focus group on search autocomplete. The teams that built those things understood a latent need, shipped them, and watched adoption happen.

That pattern is real. And it’s not the one I’m worried about.

The pattern I’m worried about is different. It’s where velocity becomes the goal instead of the byproduct. Where you ship because you can, not because you know why. Where the prototype cycle is so fast that “does this make the user’s morning better or worse” never gets asked. It gets assumed. AI might even decide the why.

There’s a difference between a feature users discover and a UX that changes every time they log in. It’s the difference between annoyance and delight.

Two velocity stories

There are two different velocity stories operators are telling right now, in the same vocabulary. Yet, they are not the same story.

The first is “build-new”. You are bringing something into the world that does not exist yet. There is no user with muscle memory to disrupt, no workflow built around your product, no expectation to violate. Velocity here is close to free. In fact, you want it. You want the user to change behavior, because behavior change is how you win a market. If they keep doing what they did yesterday, you do not have a company.

AI velocity is a genuine unlock here. The 0–1 discovery loop has never compressed faster. For now, velocity feels free, because for them it is. Eventually it won’t.

The second is “optimize-existing”. The user has been using your product for years. They have a Tuesday morning routine. They have buttons their fingers know how to find. They have a workflow that already works for them (it might not even make sense to you). They have absorbed your previous 12 changes without complaining publicly. Velocity here is a tax on every release. It costs trust. It costs muscle memory. It costs the part of the experience that doesn’t show up in any of your dashboards.

And some of them just leave. They find something more stable. You see it in the retention dashboard — six weeks later.

At scale, “more stable” is itself a competitive position. Reliability isn’t the absence of innovation. It’s a feature your displaced users actively shop for. Every release that breaks something is a quiet recruitment pitch for the competitor who didn’t break it.

And even mature orgs have 0–1 moments. New product lines. New market entries. Same physics apply: no muscle memory to disrupt, velocity close to free, behavior change is the point.

The startup-velocity excitement mostly comes from operators in the first story. They are not wrong about their world (some of us even straddle both worlds). They are wrong about yours.

Most of the AI velocity discourse right now is build-new advice being given to optimize-existing operators. The advice isn’t bad. It’s just for somebody else.

What the tool won’t say

One more thing about the “build-side”.

The tool you’re using to ship faster is also the tool telling you the idea is good (amazing even). That’s not a bug. It’s how it’s tuned. Fine when you’re right. When you’re not, it accelerates conviction in the wrong direction at the same speed it accelerates the build.

Ship faster on a wrong-direction call and you don’t just lose four million people. You lose them with more certainty.

The discipline

So what’s the move?

Not slowing down. Velocity inside the building is genuinely a win. The move is putting a kill function in the room.

When one person can generate 20 prototypes a week, the scarce skill isn’t building them. It’s killing 16 of them fast. The scoring function that used to be distributed across PM, design, and engineering now has to live somewhere deliberate, or every idea that gets built also ships.

And for what survives the kill filter, you still have to roll it out.

Velocity inside the building doesn’t equal velocity at the user. The user is still moving at human speed. The discipline isn’t just deciding what to ship. It’s how to ship it. When to introduce. When to gate. When to listen for feedback. When to treat it as input.

That used to live invisibly in operating cadence. AI velocity made it visible.

Most of the AI velocity advice right now leaves this out. The throughput numbers go up because building got cheaper. The discipline didn’t.

The PMs who survive this moment aren’t the ones who can prompt the fastest. They’re the ones who can say “good enough to keep” and “not yet” and “no, kill it” with conviction, in front of teams who would rather just keep building.

Two hundred and twenty-five million people don’t go away because the conversation moved on.

The user is still on the other end of every release. Always was. Always will be.

Software is moving faster than users were ever meant to. The next decade goes to the operators who remember which side of that gap pays the bills.

And one more layer is forming under the surface. Agents are starting to act on behalf of users. They hit the same churn. They don’t gracefully absorb constant change either. The user experience problem is becoming an agent experience problem too. Same discipline. Different consumer.

Next week: what AI removes, and what stays.