When the bottleneck is no longer engineering

A few weeks ago, one of the teams I support finished a development in three days that we'd estimated for a full sprint. They used Claude Code, leaned on agents for the more mechanical parts, and the result was solid. Tests passing, feature complete, ready for review.

The next thing I heard was a conversation between two engineers on the team: "So... what do we do now?"

It was a genuine question. They'd finished ahead of schedule and the next initiative wasn't defined well enough to start. Not because there was a lack of ideas (there were plenty), but because the capacity to validate and define those ideas hadn't scaled at the same pace as the capacity to build them.

That line has been rattling around in my head ever since. Because this isn't just one team's problem. It's a shift in dynamics that I believe will redefine how we work for years to come.

The funnel we all knew

If you've worked in digital product, you know this picture. Product is the wide end of the funnel: lots of ideas, lots of initiatives, lots of ambition. Engineering is the narrow end: finite capacity, limited sprints, teams that can't keep up.

This imbalance has defined how we manage teams for the past decade. We prioritize with RICE or ICE because we can't build everything. We make quarterly roadmaps because we have to decide what gets in and what doesn't. The typical frustration of any Product Manager is exactly this: "I have twenty good ideas and can only execute three."

But that model had an advantage we didn't appreciate. If you can only build three things, you'd better choose well. The bottleneck in engineering was, unintentionally, a quality mechanism for product decisions. It forced you to think.

A change we didn't choose

Claude Code, Copilot, Cursor, agents that generate complete PRs. I'm not going to get into whether AI will replace developers (I've already written about that). What I do observe, in my day-to-day supporting seven teams, is something subtler: the capacity to implement is growing. Not for everything, not infinitely. But enough that the dynamic between product and engineering is changing.

And this is a change we didn't choose. It didn't come from a reorg or a new methodology. It came from the tools. Overnight, teams that used to take two weeks on a complete flow have it done in days. And that shifts the bottleneck: it's no longer about how many things you can build, but how many good things you can think up, validate, and define in time.

This isn't anyone's fault in particular. It's a new mismatch between two capabilities that until now were reasonably balanced. And I think the entire industry is going to run into it.

The two obvious responses (and why neither convinces me)

When you see that the funnel has flipped, there are two natural reactions. I've been turning both over in my head for weeks and I'll be honest: neither fully convinces me.

Slow engineering down to match

The first is to adjust downward. Don't build faster just because you can. Keep the pace, use the surplus capacity for refactoring, for slack, for quality.

It makes sense. In fact, elite teams have always operated below 100% capacity. Toyota does it deliberately: don't maximize machine utilization — maximize flow. Slack isn't waste; it's what lets you absorb variability.

When I saw what happened with my team, my first instinct was exactly this. Surplus capacity, pending quality work, so let's improve test coverage in areas that needed it. And it was useful. It's not wasted time.

But something kept nagging at me. We had the capacity to build something that would deliver value to users, and we redirected it to internal improvements. I'm not saying that's wrong — sometimes it's the best call. But there's a real opportunity cost. If that capacity exists and you don't use it, someone in your market will.

And some will say: "well, better to go slow and steady than fast and sloppy." Agreed. But that's not what I'm proposing. I'm asking what you do with the capacity you've gained. Wasting it isn't the only alternative to going off the rails.

Speed product up to match

The second reaction is to expand upward. If engineering can build more, let's generate more ideas, more initiatives, more product. Keep the queue from running dry.

This one worries me more. Because it's what happens naturally, without anyone deciding it.

I've seen this pattern across the industry (and sometimes in myself, if I'm honest): you see the team moving faster with the new tools and think "great, we can fit more initiatives into the quarter." You go from three to six. And what happens? By the end of the quarter you have six things at 70% and none at 100%. None measured, none validated, none with real usage data.

Here the analogy of a startup that scales too fast feels spot-on. A startup raises a round, hires 50 people in three months. Culture degrades, communication breaks down, newcomers don't understand the rationale behind decisions.

With the second option, the same thing happens — but with initiatives instead of people. You pile too many in at once, WIP skyrockets, focus evaporates. And the most dangerous part: decision quality drops without anyone noticing, because the volume of output masks the decline in outcomes.

What nobody measures: product WIP

There's a concept from queuing theory that I think is key here: Little's Law.

If you increase implementation throughput but don't increase validation capacity, what goes up isn't value delivered. What goes up is WIP. More things in progress. More things half-baked. More things that are "done" but nobody has checked whether they actually solve anything.

High WIP has a brutal cost you'll probably recognize: every new initiative competes with the others for attention, for user feedback, for data. And since validation capacity isn't infinite, what ends up happening is that all of them get a little and none of them get enough.

A pattern I've seen too many times: a team builds a feature, launches it, and moves on to the next one without looking at metrics. Why? Because there's already something else waiting in the queue. Throughput pressure kills learning.

The option that wasn't on my whiteboard

I'll be honest: when I drew this out on a whiteboard I only had the two previous options. Slow down or speed up. And both felt off.

The third one came up in a conversation with a colleague. It doesn't equalize the funnels. It transforms them.

The idea is this: instead of slowing engineering down or speeding product up, redirect surplus implementation capacity toward validation. Use the extra capacity not to build more finished product, but to build more experiments. Throwaway prototypes. Minimal MVPs. A/B tests. Proofs of concept that answer questions before committing to a full build.

What used to be "we have 20 ideas and can only build 3" becomes "we have 20 ideas, we've prototyped 10, discarded 6, and now we're building the 4 we know work."

That turns the validation bottleneck into something engineering can help solve. You don't generate more ideas. You filter the ones you have better. And you do it with what you know how to do: building.

I won't pretend this is a closed formula. It has its own open questions. Who decides what gets prototyped and what doesn't? How do you prevent a prototype from becoming product without going through real validation? How do you measure whether an experiment answered the question or generated three more? I don't have it figured out. But it feels like a direction with more future than the other two.

The question that matters now

The change I'm describing isn't technical. It's a mindset shift.

For years we've been asking "how do we produce more?" More features, more releases, more output. The question now is different: how do we learn faster?

Because if implementation is no longer the bottleneck, what separates teams that generate value from teams that just generate output is how fast they validate. How fast they discard what doesn't work and double down on what does.

When I heard that "so what do we do now?", the answer I wish I'd had ready wasn't "ship more features" or "do some refactoring in the meantime." It was "help me figure out whether the next thing we're going to build deserves to be built." Let engineering help product think. Not execute faster, but fail cheaper.

I don't know if this is the definitive answer. It probably isn't. But I know that sticking with the mental model of "ideas are plenty, hands are scarce" no longer works. The hands aren't scarce anymore. What's scarce is knowing what to do with them.

I'd love to hear how you're experiencing this on your teams. Has something similar happened to you? Have you found ways to deal with it?