For most of my career, the cross-functional model has looked like a relay race. Product hands a brief to design. Design hands a spec to engineering. Engineering ships. Each leg of the race had a baton, an owner, and a clear moment of handoff. It worked. The lines were the point.
That model is starting to break. Not because anyone got worse at their job, but because the constraints that made the relay format efficient are gone.
The old model worked because it matched the cost structure of the work. Writing a spec was cheap. Building a real prototype was expensive. So we put the cheap work upstream and the expensive work at the end. PMs and designers described the thing. Engineers built it. The handoff was the place where description turned into reality.
That cost structure has changed. Code is cheaper now. Prototyping is cheaper. The boundary between describing a thing and building a thing is thinner than it has ever been. A PM with the right tools can ship a working prototype in an afternoon. A designer can push production-ready components through a coding agent. An engineer can draft a real product argument with the same rigor a PM brings to a brief.
None of this means the disciplines are merging. Expertise still matters. A PM with deep customer knowledge will still see things a designer misses. A designer with system-level pattern fluency will still catch decisions an engineer wouldn't think to question. Engineers still own the architecture, the quality, the scale. The circles are still anchored in deep expertise. The edges are now permeable.
The new shape isn't a relay. It's three overlapping circles.
Each discipline still owns its core. Product owns strategy and outcomes. Design owns craft, systems, and judgment. Engineering owns architecture, quality, and scale. None of that goes away. What's new is what happens in the overlap.
In the overlap, PMs prototype and designers shape strategy. PMs build working demos and designers ship production code. The work that used to require a handoff now happens collaboratively, often in real time, often inside the same tool. The team gets smaller because each person can carry a little more of the work. The team also gets faster because there are fewer batons to drop.
AI didn't erase the circles. It gave each one reach.
This is the part people get wrong when they panic about AI replacing roles. Nobody got cut out. Our roles got bigger, and so did our reliance on each other. A designer who can ship code isn't replacing engineers. They're meeting engineering in the overlap, with enough fluency to have the right conversation. The same goes for a PM who can prototype, or an engineer who can argue product strategy. Reach is not replacement.
The most interesting thing about the new shape isn't the overlap. It's the center.
"Can we build it?" used to be the hard question. It was the question that gated whether something happened at all. Engineering owned the answer because engineering owned the cost. If the cost was too high, the project died.
That question isn't hard anymore. We can build almost anything. We can prototype it before lunch. We can ship it by Friday. The constraint moved.
The hard question now is "Should we build it?" Which problem is worth solving? Is this the right experience for the user? Is it technically honest, or are we hiding complexity that will hurt us later? Is the value real, or are we shipping because shipping is cheap? No single role can answer those questions alone. Product brings strategy. Design brings judgment. Engineering brings honesty about what the system can actually carry.
"Should we build it?" is the question that sits in the center of the three circles. It's collaborative by definition. It's also where I think product leadership is heading, because it's the question AI most clearly cannot answer for us. Generative tools amplify what we can generate. Judgment about what's worth generating is still, and more than ever, a human act done together.
Here's where I think the most important shift is happening, and it's the one most teams miss.
The efficiency gains aren't supposed to make us ship code faster. They're supposed to keep us from writing the wrong code in the first place.
If a designer can produce a working prototype in an afternoon, that prototype belongs in front of a customer the next morning. If a PM can spin up a real demo without engineering, that demo should be tested with five users before the team commits a single sprint to it. The point of cheaper building isn't to build more. It's to validate before we build at all.
Put real things in front of customers before code ever enters the conversation.
This is core to product success right now, and most teams are still treating prototypes as deliverables to socialize internally. They make a beautiful prototype, walk it through a stakeholder meeting, get nods, and ship it. Then ship a v2 because customers didn't behave the way the deck assumed. Then ship a v3. The cost of being wrong is the same as it always was. The cost of being wrong fast just got cheaper.
The teams I want to work on use the new tools to compress the loop between idea and customer feedback. Prototype on Monday. In front of users by Wednesday. Decision to build, kill, or reshape by Friday. The roles overlap because the work overlaps: a designer running the user session, a PM watching for confused moments, an engineer asking whether what we're seeing is something the system can support. All three in the room. Or all three on the call. None of them waiting for a handoff.
Smaller teams. Less waiting. More learning before more building. And the conversation shifts from what should this be? to did we just learn this is the right thing to be building at all? That's the conversation I most want to be in.
The overlaps aren't contested territory. They're shared ground.
I'm not pretending this is a fully solved model. We're early. The norms are still forming. There's plenty to figure out about how authority works when the lines blur, how performance gets measured when the work is shared, how juniors learn when the senior people on each circle are also doing the overlap. Real questions. Worth working on.
What I'm confident about is the direction. The relay is over. The overlap is where the next era of product gets built, and the work that happens there should answer one question first, every time: is what we're about to spend code on actually worth spending code on? If we're not doing that, the speed-up just becomes a faster way to ship the wrong thing.