Organizations adopting AI in product development are shipping more and delivering worse outcomes. Not because AI failed them, but because it exposes a weakness they'd been hiding behind build-time.

The cost of producing a first working version has collapsed. The cost of producing a version you'd stake your business on has not. That gap, between "it works" and "we can rely on it", is where most of the AI-in-product conversation is currently confused as I hear it now.

Here's what I think is actually happening.

People think AI gives product teams speed to build. That's the surface story, we do build faster and it is faster to ship code. However, what it actually does is remove the excuse that build-time is the constraint. As you remove this excuse, you can see what is underneath it: most organizations were never particularly good at knowing what to build and measuring its success or not. Build-time was hiding it. The long cycles, the roadmap negotiations, the "we can only do three things this quarter", all of that gave the appearance of prioritization. It looked like discipline. In fact, a lot of it was just scarcity dressed up as strategy.

Now the scarcity is gone in one direction. Teams can produce and ship at a pace that would have been unthinkable two years ago. Now the question stops being how fast can we build it? and becomes how do we know it's worth building? Most organizations don't have a good answer to this. They have a backlog, a set of stakeholder requests, and some intuitions. This was survivable when building was slow, because slow building forced choices. Fast building doesn't force anything. It just produces more output.

The failure mode I'm watching play out is the following: organizations that don't restructure for this get more output and worse outcomes. Measurably shipping faster. Measurably missing more often. The dashboards look great and the product gets worse.

Who should be building, then?

Last week I asked who should build the agent. If validation is now the actual bottleneck, that question is really: who has enough proximity to the problem to validate a solution fast? That reframes the answer, and it reframes how you structure teams around it.

The classical product trio, PM, engineer, designer, was designed for a world where building was expensive. The whole shape of it assumed a small discovery team could hand off to a larger delivery team, because the delivery team was where the money went. The trio was the cheap part. Delivery was the investment.

Flip the cost curve and the handoff that made the trio work becomes the bottleneck it was meant to solve. Delivery is no longer the expensive part, so structuring around it optimizes for the wrong constraint.

Two paths, neither obviously right

There are two paths I see people reaching for, and I don't think either one is obviously right.

Path A: small end-to-end teams. Each one owns discovery and delivery for an outcome. Fewer engineers per team, broader skill mix, tight loops between problem and shipped code. What it buys you: proximity to the problem, no handoffs, real ownership of the outcome. What it costs you: fragmentation, duplicated infrastructure, every team quietly rebuilding the same auth flow, no compounding leverage across the org.

Path B: specialized discovery pods feeding shared delivery and platform capability. What it buys you: consistency, leverage, a real platform instead of five half-platforms. What it costs you: you reintroduce the handoff you were trying to escape. Discovery pods learn things that never make it into what actually gets built, because the people building it weren't in the room.

There's perhaps a third path. A platform team that treats itself as a product, with product teams as its customers. The platform has its own PM, its own discovery, its own success metrics and it ships capabilities that product teams choose to adopt. If nobody adopts what the platform ships, that's a platform team failure, not a product team failure.

I've seen this work. At Microsoft it works at scale, and when it works you get the leverage of shared capability without the handoff that Path B reintroduces. The product teams stay end-to-end on their outcomes; the platform is a tool they reach for, not a gate they pass through.

The catch is that it requires a certain size and a certain kind of leadership. You need a platform PM senior enough to say no to product teams. You need product teams mature enough to adopt shared capability instead of quietly rebuilding a shortcut. And you need enough product teams for the leverage math to actually work — a platform serving three teams isn't a platform, it's overhead. Most organizations aren't big enough for this path to be real. Some are big enough and still can't pull it off, because the leadership pattern isn't there.

So, the honest read is that most organizations will need some hybrid of A and B, and the hybrid is harder than either pure form, because it requires leadership to actually decide what is shared and what is owned, and to revisit that decision as the product grows. Most orgs won't. They'll pick a shape once, call it a reorg, and freeze.

The muscle nobody is building

Here's the beat almost nobody is talking about.

Every feature you ship without a validation gate is something you now own forever. Speed to production without a matching capability to kill things in production means your product surface grows without direction. You end up maintaining features you can't remember approving, integrations nobody uses, options that exist because someone shipped them in a sprint you don't remember.

The organizational muscle nobody is building right now is the muscle to remove things, the ability to Avert(o). And that's a leadership question, not an engineering one. Engineering alone can't decide what to kill. That's a product and business decision, and it requires someone with enough authority and enough context to look at something a team shipped six months ago and say this didn't work, take it out. Most orgs don't have that person. Or they have that person and haven't given them permission.

I don't know the answer to this yet.

What I do know is that the leaders I'm talking to are optimizing for the wrong variable. They're asking how to ship faster when they should be asking how to learn faster, and how to stop shipping things that shouldn't survive. The team-topology question, the tooling question, the measurement question all follow from that reframe.

I'm working through it. If you're working through it too, I'd like to hear how.