We are moving from Product Managers to Product Builders
A good friend of mine Christopher Brereton has spent two decades in product, moving all the way to CPO across the full arc of a career built around shaping what gets made and steering the people who make it. Today, in his fractional CPO and Co-Founder role at his startup, he is building rather than specifying and delegating and reviewing pull requests from a polite distance. Darren Ball is the same story told from a different angle, because his background sat at the thinking end of the spectrum, in validation and product thinking and product management, and he is now in the code himself, shipping the kind of work that until recently he would have had to hire someone else to do.
Neither of them retrained as engineers, and nothing about their fundamental skill set really changed. What changed is that they can now do what they could not do before, because of the tooling and the AI capability and the platforms and services being wrapped around it, places like Built With MOHARA, that turn raw capability into something a product person can actually build with. This is the Great Compression at work: AI speeding things up, and as a downstream effect collapsing the time and the cost of execution because you no longer have to pay other people to do it or wait while they do. The reduced cost is a real help, but it is the consequence rather than the cause, and as that distance between intent and execution collapses a role that has always been pulled apart into two people is quietly folding back into one. We are starting to hear a consistent name for the person who emerges on the other side of that fold, and it is the product builder.
What a product builder actually is
A product builder is someone with product judgement who now ships working software directly, using AI tooling and an engineering standard behind them, instead of writing tickets for someone else. A product builder is building capability and management capability wrapped into one, and it is worth sitting with that definition because of what it quietly replaces. Product management as a discipline was constructed around a separation, in which the product manager held the vision and the context and the prioritisation and the relationships while the engineers held the means of production. The PM could describe the thing but could not make the thing, and once you see it from that angle, an uncomfortable amount of modern product management starts to look like an elaborate machine built for one purpose: to manage the gap between the person who knows what to build and the people who can actually build it. The specs, the tickets, the standups, the roadmaps, the grooming sessions about the grooming sessions. We invented an entire profession of intermediaries to cope with a gap, and the tools have quietly closed the gap.
A product builder simply does not have the gap, because the same person who understands the problem can now produce the solution once the tools have removed the barrier that made execution a specialist function. This is not a hybrid, and it is emphatically not the PM who did a weekend course and added “technical” to their LinkedIn headline. It is a single mode of working in which thinking and making are no longer separate jobs held by separate people. The clearest way to picture it is translation. For years the product manager was the translator, taking an idea in one language and relaying it to people who spoke another, and like any relay it lost something at every pass and slowed to the speed of the slowest exchange. The product builder simply speaks both languages, so the conversation stops being a relay and becomes a single train of thought.
The evolution from product manager to product builder
It helps to see the two side by side. Product management is product management: vision, prioritisation, coordination and communication, the work of deciding what should exist and orchestrating the people who bring it into being. Product building is building plus management wrapped into one, the same judgement about what should exist now paired with the ability to bring it into being directly.
The product manager role was never an accident or an inefficiency, but rather the correct response to a real constraint, which was that execution required engineering and most product people did not have it. Remove the constraint and the role does not disappear, but its centre of gravity moves, so that the very things that made someone a good PM, the taste and the judgement and the instinct for what matters, are now the things that make someone a formidable product builder, except those instincts finally have a direct line to the product instead of being routed through other people. It is a sideways evolution rather than a promotion, and the product builder still works alongside engineers, often product engineers, on the genuinely hard problems. But the floor has shifted, and a great deal of what used to demand a handoff simply no longer does.
Why it matters
Here is the part that makes people in leadership roles sit forward. If you have someone who can both decide what to build and build it, the shape of the team changes underneath you. You may need one fewer engineer. You almost certainly need fewer of the handoffs and translation layers and coordination rituals that only ever existed to bridge the gap between deciding and doing, the same rituals we mistook for the actual work for the better part of two decades. The product builder compresses the team the same way the Great Compression compresses everything else, by collapsing the distance between intent and execution until the intermediate steps stop earning their place.
This is also where the honest version of the risk lives, and it is worth saying plainly rather than dressing up. The product manager who does not evolve does not get fired on Monday, but they do become a narrower instrument in an environment that increasingly rewards range, and once the person sitting next to them can both decide and build, pure coordination starts to look a lot like overhead. That is not a threat so much as a gradient, and tellingly the people leaning into it hardest are not the juniors trying to look clever. They are the experienced ones, the Chrises and the Darrens, who already have the judgement and have simply decided they would rather have the reach to match it than spend another year describing things to other people.
The transition, done properly
Recognising the shift is easy. Making it well is not, and this is where most of the breathless takes on the internet quietly fall apart. Every product person alive knows the specific feeling of demoing something that worked flawlessly right up until a real user laid a finger on it, and the new tools make that feeling cheaper and more frequent to produce, not less. Someone opens a coding tool, builds something that dazzles in the demo and disintegrates on contact with reality, and walks away either convinced they are not cut out for it or, worse, convinced the half-built thing is fine. Tools lower the barrier to starting. They do absolutely nothing, on their own, to teach you how to build something that holds.
That gap is the entire reason we built Built With MOHARA. It is a transitional programme and an enabler for the move from product manager to product builder, and it exists because the transition needs structure and judgement wrapped around the tools rather than just access to them. It takes people who already have the product instinct, the validation and prioritisation and the sense for what matters, and gives them a way to add real building capability on top, grounded in the methodology we use to take products from idea to something that actually ships and keeps standing. The point was never to turn product people into engineers. It was to turn them into product builders, and good ones.
Where this goes
We have been saying for a while that product managers could do this, that founders could do this, that the capability was within reach, and for a long time that was true in the way that most things are true on a slide. What is different now is that we can point at named, specific people who were doing something else six months ago, and we can describe the path rather than wave at the possibility. The product builder is not a forecast. It is a role that already exists and is already occupied. The only open question is the one every product manager reading this is now quietly asking themselves, which is not whether the role is real, but whether they are going to keep describing the thing or finally go and build it.