The Product Builder Was Never About Coding

LinkedIn just validated a thesis I have been arguing for two years, and got the mechanism wrong while doing it.

The short version

Product Builder was never about a PM learning to write React. LinkedIn replaced its APM program with a Product Builder program, and most coverage read it as a generalist story: PMs who can touch design, product, and engineering. That is the surface. The real shift is collapsing the distance between deciding and making. The traditional PM job was coordination, a relay race that existed only because turning an idea into a working artifact was expensive and slow. When one person can go from idea to prototype in an afternoon, the specialization that justified the handoffs stops paying for itself. So framing Product Builder as a skills question solves the wrong problem. The right question is organizational: what do you still need a coordinator for once the person with the idea can produce the artifact?

Tomer Cohen replaced LinkedIn's APM program with a Product Builder program. The framing in most of the coverage is that this is about generalists who can touch design, product, and engineering. That is the surface reading. It misses the actual shift.

Product Builder was never about a PM learning to write React. It was about collapsing the distance between deciding and making. The traditional PM job was coordination: gather requirements, write a PRD, hand it to design, hand it to engineering, manage the relay race. That job dies not because AI teaches PMs to code, but because AI kills the reason the relay race existed in the first place. The relay race existed because translating an idea into a working artifact was expensive and slow, so you needed specialists to do each leg. When a single person can go from idea to a working prototype in an afternoon, the specialization that justified the handoffs stops paying for itself. This is the same collapse I traced when the APM program stopped making sense.

So when companies frame Product Builder as a skills question, upskill your PMs, teach them Figma and a bit of code, they are solving the wrong problem. The real question is organizational: what do you still need a coordinator for once the person with the idea can produce the artifact? The answer, in most cases, is less than you think.

Here is where I differ from the generalist framing. I do not think the future PM needs to be good at everything. I think the future PM needs to be good at prototyping and evaluation, specifically, and can outsource or automate almost everything else. That is a narrower and sharper skill set than being a generalist across product, design, and engineering. Generalism is the consolation prize for people who have not figured out which two skills actually matter. Prototyping is the instant-prototype loop any PM can now run; evaluation is the eval discipline that keeps a cheap prototype honest.

The companies that will win this transition are not the ones retraining PMs to be full-stack. They are the ones who figure out that the PRD, the roadmap deck, and the handoff meeting were never the job. They were the tax you paid for not being able to build. This is the job the Product Builder ladder is actually describing, and the reason I have argued we do not need a church built around the old model.

Name the two skills that matter. Get good at those. Let the coordination tax expire.