I Already Was the Product Builder, Twice

For about six months I had a git checkout and a roadmap at the same time, and nobody at the company thought that was strange, because nobody had a word yet for what I was doing.

I had come up as a developer. Then I moved over to what I still jokingly call the dark side and became the first product manager the company ever had. There was no template for the job. No PM career ladder, no onboarding doc, no title anybody recognised from a conference talk. I still fixed frontend bugs on Fridays for a while, mostly because the queue was mine and it felt wrong to hand it over.

Fast forward. I build alone now. Code and product decisions land in the same afternoon, sometimes the same hour.

Which is why, when a report started circulating saying the "product builder" grew tenfold in a single year and the classic product manager will be gone by 2030, my first reaction was a smile. They are forecasting a role I have already lived. Twice.

The Numbers Are Probably Fine. The Inference Is Not.

I have no argument with the data. Roles are blending, the tooling genuinely allows one person to cover ground that used to need three, and the count of people doing both jobs is very likely up sharply.

What gives me pause is the leap people make from there. It goes something like this. The engineer becomes customer facing, the product manager picks up architecture, and everyone melts together into one figure called the builder. Same person, same shape, roughly interchangeable.

Some people will make that jump and be brilliant at it. Many will not, and that is not a failure of ambition.

A specialist does not turn back into a generalist just because the tooling got stronger.

The reason this framing spreads is not that anyone tested it. It is that reorganising labels is the cheapest thing a leader can do that still looks decisive. Redefining a job family takes an afternoon in a spreadsheet. Actually changing how a team decides what to build takes quarters, and it does not fit on a slide.

What a Team Is Actually Short Of

I have sat in a lot of rooms where everyone agreed and nothing moved.

Not because people were confused about their titles. Because it was genuinely unclear who got to make the call, and who would be standing there in three months if it went wrong. So the decision drifted, and the loudest person in the room decided by default, and that person was usually neither the engineer nor the product manager.

That is the actual shortage. Not skills, not headcount, not a modern job architecture. Clarity about direction and accountability.

Titles were downstream of that the whole time. A title is a rough guess about what somebody is accountable for, useful in job ads and mostly irrelevant on a Tuesday. If a team knows who owns the direction, who owns the delivery, and who has to answer for the outcome, you can call them whatever you want and the product management process works.

Rename everyone to product builder without settling any of that and you have not built a modern team. You have made the missing clarity harder to see, because now the ambiguity has a fashionable name.

The Part That Actually Costs Money

I keep thinking about what disappears when a company takes the flattening literally.

The developer who can look at a slow query and tell you which index is missing. The one who has been in the codebase for six years and knows which module you touch at your own risk. The product person who can sit with an angry enterprise customer for an hour, say almost nothing, and come out with the actual problem. These people are not partially completed generalists. They are the reason the hard things ship at all.

Ask them to become half of something else and some of them will quietly stop being excellent at the thing you actually needed. That cost does not show up in any quarter you can point at. It shows up two releases later, when nobody notices the query plan.

And there is a worse version, which I have watched happen. A leadership team reads the AI story, decides the role is obsolete, cuts people, and rehires roughly the same profile eleven months later once it turns out the thing was harder than the deck suggested. Everybody involved knows it was a mistake. Nobody can undo it. The people are gone, the institutional memory went with them, and the replacements need a year to become useful.

That is the most expensive product management decision I have seen made on the basis of a trend line.

Adapt, Then Look, Then Change

The sequence I would hold to is boring and it is the one people skip. Adapt first. Then inspect honestly. Then change the structure.

Adapting means letting the work actually shift for a few months and watching where it goes. My own product discovery work looks nothing like it did eighteen months ago, and I did not plan that. It changed under me because the cost of trying something dropped. If I had reorganised on day one I would have designed for a workflow I had not yet had.

Inspecting means asking what genuinely moved. Usually less than the discourse suggests, and in different places than expected.

There is real homework on both sides, and it is not free. Engineers moving closer to the customer and to the commercial side of the business, which most engineering orgs have never trained anybody to do. Product people going properly into the architecture they have been talking around for years, which takes more than reading about it. Both of those need training, time, and a leader with the patience to let people be mediocre at something new for a while.

Then, at the end, if a label needs to change, change it. The title can come last, honestly.

The Question Underneath the Trend

What I hear when people talk about the product builder is mostly a hope that the messy human part of building products can be reduced to one job description. It cannot. The tooling collapsed the distance between deciding and building, which is real and is the most interesting shift in my career. It did not make people interchangeable.

I have been the developer, the first product manager nobody had a name for, the CPO, and now the whole product organisation in one person. Across all of it the thing that determined whether the product went anywhere was never how the roles were labelled.

So before you redraw the boxes, one thing worth checking. Take the last significant call your team made about what to build.

Could everyone in the room have named who made it?