Walk into almost any post-Series B company right now and you’ll hear the same story. Growth is shipping AI-assisted experiments faster than ever. Product is generating AI-assisted specs in a fraction of the time. Marketing is producing creative at a rate that would have been unthinkable two years ago. Every leader has a slide showing how their team adopted AI, what tools they rolled out, and how much faster their cycle times look.

And yet, somehow, the actual rate of meaningful shipped work feels roughly the same. Sometimes worse.

If you’ve been quietly suspecting that something doesn’t add up, you’re right. This is the org-wide AI transformation that nobody is talking about honestly, and it’s the most important thing for Growth leaders to understand right now.

The promise of AI inside the modern company was simple. Every function gets faster. Growth ships more tests. Product writes more specs. Design produces more variants. Engineering merges more PRs. The whole machine speeds up.

The reality is more interesting, and a lot more uncomfortable.

What AI mostly does, in its current form, is accelerate the upstream functions that create demand on Engineering. Growth ships more experiments, which means more landing pages, more pricing tests, more onboarding tweaks. Product writes more specs, which means more features queued. Marketing ships more campaigns, which means more tracking, more integrations, more attribution requests.

All of that work eventually points back at the same place: a queue in front of Engineering that was already full before any of this started.

The constraint didn’t move. It just has more inbound.

There’s a piece of operations theory that’s older than most of our tech stacks and still describes what’s happening better than any AI vendor pitch. The throughput of a system is governed by its constraint. You can accelerate every non-constraint resource in the system, and total throughput does not improve. It often gets worse, because more work-in-progress means more context switching, more coordination overhead, more half-finished things sitting around.

If you’re a Growth leader, the implication is uncomfortable. The number of experiments you launch isn’t the same thing as the number of experiments that ship, get instrumented correctly, get analyzed, and influence the roadmap. The first number is yours to optimize. The second number is governed by a system you don’t fully control.

When you 3x your output and Engineering’s capacity stays roughly flat, you haven’t tripled your impact. You’ve tripled the size of the pile that Engineering has to triage, push back on, partially build, partially defer, and partially get blamed for not finishing.

This is where the conversation usually goes, and it’s worth being honest about it. The pitch is that AI-assisted engineering, agents, vibe coding, copilots of every flavor, will absorb the new demand. Engineering productivity will rise to match the new input.

In some cases, it does. In many cases, it doesn’t, and the reason is boring and structural.

AI generates code that looks right. Shipping code that actually works inside a specific codebase, with the right libraries, the right service boundaries, the right edge cases, the right observability, the right rollback story, is a different problem. When the engineer driving the AI is deep in the codebase and uses it as a force multiplier, output goes up. When the code is generated by someone with less context, it tends to almost work. Almost-working code is the most expensive kind. It passes review on the first glance, fails in production at 2am, and costs an engineer two days of forensics to unwind.

QA quietly becomes a second job. Senior engineers get pulled off feature work to clean up AI-generated code that almost merged. Net throughput, the thing that actually matters, slows down.

Moving fast with AI can create more rework than moving deliberately without it. That sentence is going to age well.

Here is the part I think Growth leaders, specifically, need to internalize. Designing a meaningful experiment is not the same as running one. Compressing time-to-insight on a hypothesis means nothing if the hypothesis sits in a backlog for a quarter. Reducing time-to-value for a customer is a fiction if the value lives in a feature that engineering deprioritized three sprints ago.

We’ve spent a decade defining the Growth function as the team that creates demand. Demand for sign-ups, demand for upgrades, demand for retention loops, demand for product changes that move the needle. AI didn’t change that mandate. It supercharged the part of the job that creates internal demand on other teams, and left untouched the part that determines whether any of that demand turns into shipped reality.

The Growth leaders who win the next two years are not going to be the ones who shipped the most experiments. They’re going to be the ones who understood that the job quietly expanded. Growth is no longer just the demand-creation function. It’s becoming the flow-ownership function, the team most accountable for making sure the work that matters actually moves through the system.

That sounds like Product’s job, or Eng’s job, or the COO’s job. In a lot of companies, it isn’t anyone’s job, which is exactly why the pile keeps growing.

If this lands for you, here are five moves worth making this week. None of them are about adopting another tool.

1. Map the actual constraint, not the one you assumed. Spend an hour with your Eng lead and a whiteboard. Where does work pile up? Is it design review? QA? Code review? Deployment? Data instrumentation? PM spec quality? You almost certainly don’t know, and your gut is almost certainly wrong. Find the real bottleneck before you optimize anything else.

2. Audit your AI-assisted output for finish rate, not start rate. Pull the last 90 days of Growth experiments. Of the ones you launched, what percentage shipped fully, got measured cleanly, and produced a decision? If that number is under 60%, your AI tooling isn’t your problem. Your handoff and flow are.

3. Stop measuring your team by volume. Replace “experiments launched” with “experiments that produced a shipped decision.” The metric you choose for your team is the behavior you’ll get. Volume metrics, in an AI-accelerated world, almost guarantee you’ll flood the constraint.

4. Convene the cross-functional unblock meeting nobody is holding. Pull Growth, Product, and Eng leadership into a recurring 45 minute session whose only job is to look at the backlog as a single system, not three separate queues. The first meeting will be uncomfortable. The third one will start changing how work flows.

5. Make the case for AI investment where the constraint actually lives. If Engineering is the bottleneck, the highest-leverage AI spend in your org isn’t another tool for Growth. It’s whatever makes the constrained team faster, safer, and less interrupted. Be the Growth leader who advocates for that, publicly. It will reshape how the rest of the org sees your function.

Most orgs are optimizing around the constraint right now. They’re giving every non-constrained team more horsepower, generating more demand against a fixed-capacity engineering team, and calling it transformation. It looks like progress, right up until the sprint retro where the same five things didn’t ship for the fifth quarter in a row.

True AI nativity is not giving every team a new tool. It’s rearchitecting how work flows across the entire system, and being honest about where the actual constraint lives. That’s not a procurement decision. It’s a leadership posture.

Growth leaders are in a strange and powerful position here. You sit closest to the revenue impact, you’re often the most data-literate function in the building, and you have the political capital that comes from owning the number that matters most to the board. If you don’t push your org to answer the harder question, nobody will.

So push it. Where is the actual constraint, and are we optimizing around it, or through it?

The answer, more often than not, is the difference between a company that gets faster and a company that just looks busier.