The Collapse of the Product Org
Most software companies are organized around a fiction: that building a product is a relay race. The best products have rarely been built this way.
March 2026
Most software companies are organized around a fiction: that building a product is a relay race.
The product manager figures out what to build. The designer figures out what it looks like. The engineer figures out how to make it work. Each person does their leg and passes the baton. Clean, logical, manageable.
There's just one problem. The best products have rarely been built this way.
The relay model exists because of a constraint that used to be real: building software was so hard that you needed deep specialists at every stage. Design was a discipline that took years to master. Engineering even longer. And someone needed to talk to customers and wrangle priorities, so the PM role emerged to fill the gap between business and build.
Each of these specializations made sense in isolation. The trouble started when you wired them together into a pipeline.
Every handoff in the relay is a lossy compression.
The PM talks to users and hears the frustration in their voice, sees the workaround they've hacked together, feels the urgency of the problem. Then they go write a document. Already, something is lost. The document captures the what but not the why it matters. It records the feature request but not the look on the user's face.
The designer reads the document and makes a mockup. More is lost. They're designing for a problem they didn't witness firsthand. They're making interaction decisions without feeling the workflow the user actually lives in. They do their best, but they're working from a translation of a translation.
The engineer reads the mockup and builds it. By now, the signal has been compressed so many times that what gets shipped is often technically correct but emotionally wrong. It solves the problem on paper. But it doesn't solve it the way it would have been solved by someone who sat with the user and then went straight to their keyboard.
This is the real cost of the relay model. Not that it's slow, and not that it's expensive. The real cost is fidelity. Every handoff loses information that no document or mockup can capture.
Everyone in a product org can feel this. Ask any PM what frustrates them most and they'll describe watching a feature ship that matches the spec but misses the point. The signal was there at the start. It just didn't survive the relay.
This frustration isn't new. What's new is that something can finally be done about it.
I should acknowledge that people have tried to fix this before. Agile was supposed to kill the waterfall relay with tight feedback loops and cross-functional collaboration. Squads and tribes were supposed to break down silos by putting PM, design, and engineering in the same room. DevOps collapsed the wall between writing code and running it. Each of these helped. None of them solved the core problem.
Here's why. All of those reforms kept the fundamental division of labor intact. Agile made the relay faster — shorter sprints, quicker handoffs — but the handoffs were still there. Cross-functional squads put the relay runners in the same room, but they were still running separate legs. The PM still wrote the spec. The designer still made the mockup. The engineer still implemented it. The information still degraded at every exchange.
It's like the difference between making a photocopy faster and eliminating the need to photocopy at all.
Previous reforms optimized the copying. What's happening now removes it.
The reason this time is different is simple, even if the implications are huge: AI tools — LLMs, coding assistants — have made it possible for a single person to hold the full loop. Not in theory, not as a rare genius, but as a normal working practice. A PM who identifies a problem can build a working version of the solution that same afternoon. A designer can go from sketch to functional interface without waiting for someone else to "implement" it. The handoffs don't get faster. They disappear.
This is where I need to be careful, because there's a seductive version of this argument that dismisses specialization entirely. It goes: anyone can do everything now, specialists are dead, long live the generalist. That's wrong.
Design, product thinking, and engineering are genuinely different cognitive activities. Understanding user motivation is not the same skill as creating coherent interaction patterns, which is not the same skill as building reliable systems. Someone who's spent ten years doing user research will see things in a customer interview that a generalist will miss. A senior engineer will make architectural decisions that keep a system running under load in ways a weekend prototyper can't.
What's changed is not that these skills stopped mattering. What's changed is how combinable they've become. The floor for "good enough" in each discipline has risen dramatically. A PM with no engineering background can now build something that works — not something production-ready, but something real enough to test, to learn from, to show whether the idea has merit. A designer can produce functional code, not just static mockups. An engineer can iterate on interaction design in real time, not just implement someone else's wireframes.
The ceiling of each specialization is as high as ever. But the floor of adjacent ones has risen enough that one person can now do the whole cycle at a quality level that used to be impossible.
And that changes how you should organize a team.
Think about how a restaurant works. A big operation separates menu planning, cooking, and plating. You have a head chef for the menu, line cooks at their stations, and a plating team that assembles the final dish. This makes sense at scale. A restaurant serving four hundred covers a night needs that division.
But the best meal you've ever had was probably cooked by someone who did all three — who chose the ingredients because they understood the dish, who cooked it because they understood the ingredients, and who plated it because they understood the feeling they wanted you to have when it arrived.
The product org of the last twenty years was the industrial kitchen. Efficient at scale, but optimized for throughput rather than fidelity. What's emerging now looks more like the chef who holds the whole meal in their head — not because they're mediocre at all three, but because the act of making something good requires holding all three simultaneously.
If one person can go from problem to shipped solution with zero handoffs, you don't need a triad for every feature. You need people who can hold the whole thing.
I know a team — four people, a startup building a logistics tool — that spent three months shipping more features than their previous company's twenty-person product org shipped in a year. Not because they were dramatically more talented. Because every one of them could talk to a customer in the morning and ship a fix by the afternoon. No spec. No mockup handoff. No "can we get this prioritized for next sprint." The signal went from the user's problem to the product without passing through a game of telephone. You could feel the difference when you used their software. Every interaction felt considered. Nothing felt like it was lost in translation. That's what you get when the signal survives intact.
The uncomfortable question for most companies is: are we organized around building great products, or around managing the complexity of building products? For a long time, those were the same thing. When building was genuinely hard, managing that complexity was building the product. But when the complexity drops, the machine becomes the problem. Every layer of coordination, every handoff document, every alignment meeting — these were solutions to a constraint that's shrinking. And when the constraint shrinks but the machine doesn't, you get an organization that spends more energy coordinating work than doing it.
I don't think the traditional product org disappears overnight. Large companies with large codebases and millions of users will still need specialists. The relay model will persist where scale demands it, the same way the industrial kitchen still feeds more people than the solo chef ever could. Some products — payments infrastructure, regulatory compliance systems, platforms with millions of concurrent users — will still need deep, dedicated expertise at every layer.
But the frontier — the place where new products get invented and new companies get built — is going to look very different. Small teams, each person carrying the full cycle of product sense, design thinking, and technical skill. Shipping faster, not because they're smarter, but because they have zero handoffs. No lossy compression. No signal lost in translation.
The product org isn't being killed by AI. It's being made unnecessary by the same force that created it in the first place: the economics of building software. When building was expensive, we created structures to manage that expense. As building gets cheaper, those structures become the thing slowing you down.
And the products that come out the other side — built by people who held the whole problem in their head, who felt the user's frustration and went straight to their keyboard — will have a quality that's hard to name but impossible to miss. It's the quality of something that was never translated. Something that arrived exactly as it was intended.
That's what fidelity sounds like.