The Builder PM trap • Clément Boutignon<br>Clement Boutignon<br>LinkedIn<br>GitHub

The Builder PM trap

Product Managers shouldn’t build

I love building. That’s the reason I went into digital project management in the late 2000’s. It’s undeniable that having first hand experience in building and deploying digital artifacts is going to help PMs with this part of the job. But, while I have always been a capable builder, I see PMs building as an organizational failure rather than a win for the business .

At first, when you build something that would have taken weeks to be shipped by your engineering team, it feels great. You gain months of insights, but the half-life of such a move is terribly long as, if successful, you will end up having to merge back whatever you have built into the actual product, cut where you've been too far, and catch up on all the discovery that didn't happen because you were firefighting. Not to mention managing stakeholders expectations considering such pace is now the new normal.

AI makes building look easy, but anyone honest about their own vibe coding practice will admit that building seriously with AI requires technical expertise, and takes time . Should PMs spend time figuring out what lib or framework they should pick, or knowing when to give permissions or not to an agent when many PMs simply don't have the technical skills to make that call?

Building digital products at tech companies happens in context, and that context is what Product Managers need to master . Building prototypes leads to earlier validation and to valuable insights, de-risking the next decisions, but building prototypes cannot be the only way. Importantly, prototypes are discovery artifacts – if they go to prod, we enter MVP territory, and that’s where the line is crossed. AI makes this crossing more likely.

One of the reasons for the sudden interest in getting PMs to build is the misconception that Engineering is the bottleneck, and that tooling PMs with the sudden ability to code is going to compress the current production timeline. Yes, building 3 MVPs with Claude in a week feels faster than waiting on a team of engineers, but what’s the opportunity cost for PMs? What didn’t happen while the PM was busy fixing a state management issue in a React app, or trying to understand what Claude Code did under the hood when business logic isn’t matching requirements.

If building got much easier, but resources that aren’t meant to build start building, organizations aren’t going faster, they’re shifting production capacity upstream, undercutting engineers and hampering their own ability to bring healthy solutions to the market. Adding a fast production step on top of an existing process doesn’t make delivery faster, it slows it down and creates an unsustainable overlap in the delivery chain.

PMs aren't useful when they build, they are useful when they own the rationale for building.

If PMs shouldn't build, who should?

Engineers are trained to design systems, and know what good software looks like. They guarantee to end users that what they sign up for isn’t slop, is secure, and can be trusted in the long run, even when it's an MVP. Not to mention engineers own mistakes and their resolution – how many PMs will fix a production incident while staying cool headed? Same question at 1 AM on a Saturday night.

Advocates will say that Product Builders are only here to perform accelerated discovery, iterate quickly and churn prototypes hitting real user base until PMF is found, and then those artifacts can be picked up by engineering to be developed thoroughly. But I’m pretty confident this fine print will be skipped by most. Slop will go to prod, and this will have both dire consequences for end users and tech companies themselves. We know heavily relying on vibe coding to ship entire apps can lead to security issues, half of the PMs I come across have questionable understanding of basic security concepts - Furthermore, who wants to review thousands of lines of code written by someone else’s Claude? I repeat, slop will go to prod.

However, the case for AI native Product Builders, so knowledgeable about their industry, and so expert with Gen AI that they are the best placed to come up with one-click-wonders is attractive. I agree it can work, but the profiles who can pull this off today have 1/ huge taste 2/ are market visionaries 3/ are highly technical – often coming from engineering. It appears that you don’t get many profiles like these, and usually, if you have these 3 skills and a Claude subscription, it won’t take long to realize you don’t need a C-Suite to come up with something that sells…

If engineers have the means to be faster at their job, what prevents PMs from relying on their supercharged engineering team to build MVPs healthily without having to fiddle with the technical details? When did we come to the conclusion that PMs would be better builders than engineers? If strategic alignment isn’t a total...