From Roles to Builders: A Field Report

It's easy to write about how product should work. It's harder to run it inside a real organization, with real people, real constraints, and real politics. So this is a field report, not a theory, and I'll be honest about the limits of it.

At one large software company, I helped move a product organization out of the old split and into something closer to a builder model. The starting point was the standard arrangement most teams will recognize. Product managers owned the requirements. Designers owned the screens. The two negotiated across a wall, and work crossed that wall as documents. Context leaked at every pass, in exactly the ways the handoff tax predicts: the user who started a problem was usually gone by the time anything shipped, replaced by a stack of assumptions.

We made two changes, and we ran them together.

The first was structural. We moved more than forty product leads out of the old split and into a single role that owned the problem and the solution end to end, backed by tooling that absorbed the coordination work that used to fill their calendars. Instead of a product person handing requirements to a design person handing mockups to an engineer, one owner carried the job from the user's reality to the working system, with design and engineering in the room from the start.

The second was procedural. We made intent the mandatory front door for product work. No stated intent, no build. Raw input, calls, tickets, research, was turned into a structured description of the job before anyone opened a design tool. The screens and the specs came out the back of that process as a byproduct, not as the starting point. The order of operations was the whole point: capture the signal, extract the intent, build the context, and only then generate the artifacts.

Here's what moved. The time from raw input to a build-ready spec fell from weeks to days. Teams shipped more with flatter staffing. There were far fewer rounds of the most expensive question in product, "wait, what are we actually building," because the answer was settled before anyone started building. And the people doing the work described feeling more capable rather than more burdened, which surprised some of the skeptics who assumed collapsing two roles into one would just mean more work per person.

Now the honest part, because a field report that only contains wins isn't a report, it's a brochure. It was not painless. Collapsing two roles into one created real organizational strain while responsibilities rebalanced. Some people thrived in the new model and some never wanted it, and a few of those never came around. Identities were tied to the old boundaries, and moving the boundaries cost something. The direction held anyway, but it held because the work itself rewarded it, not because a reorg announcement made it true.

I want to be careful about what this is and isn't. It's one operator's report from inside one real organization, not a controlled study with a clean counterfactual. I can't hand you a randomized trial proving the model caused the numbers. What I can tell you is that the system described in the abstract, intent first, builders instead of role-holders, context preserved instead of translated away, was run with real teams and moved real metrics, and that the failure modes showed up exactly where the theory said they would.

That distinction matters more than the numbers themselves. There's a difference between describing a machine and having run one. Most writing about how product should work is the first kind, a confident description of a system the author has reasoned about but never operated at scale. This was the second kind. The model has scar tissue now. It has a record of where it strains, who resists it, and what it costs to push through, alongside what it pays back when you do.

If you're considering a shift like this, that's the part to take seriously. The upside is real and it shows up faster than you'd expect. So does the friction, and pretending otherwise is how good ideas die in their first quarter. Plan for both. Pick one job and one team, prove the model on something real before you try to convert the org, and be honest with everyone about the fact that the transition will be uncomfortable before it's obviously better.

The full operating model is in my book, Intent: How to Build Products That Last in the AI Era.