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 failure in an organization, why can’t we just let the expert builders build, while PMs master the problem space, speak to more users and nail stakeholder management?

The real job hasn’t changed

It’s tempting to shove everything under existing PMs’ umbrella as PMs naturally own the end-to-end vision. But doing this is a pure “PM fills the gaps” play that overlooks the true reasons for the existence of the product function, while ignoring that there are limits to an individual's cognitive load as well. Rather than jumping on the obvious Builder PM path, PMs must see beyond the hype and figure out how AI can improve their grasp of the problem space, to the level of gains seen by Engineering.

The job of PM is full of use cases for AI within the PM scope: finally getting on top of all the context, analysing markets and competitors faster, automating recurring tasks such as writing documentation, release notes, or crafting flawless PRDs with half the effort. It's invisible to the external eye, but it makes the difference between a truly AI-native PM being better at their job, and one trying to do someone else's because it feels possible.

Sadly, the current ecosystem and job market make it super hard for PMs at companies under AI psychosis to avoid being forced into the Builder PM role without a fight. To those, the key thing is to never forget why PMs exist in the first place. Using tokens now may be the only way to keep a job, but it will only last until the market corrects and employers revert to expecting actual value creation – and this isn't building, it's rationalizing, it's researching, it's framing. All good long term investments to keep working on while Claude is clauding.

Product Managers will continue to deliver way more impact for their employers by sticking to the problem space, rather than going builder-mode because it’s become easy and hot. The Builder PM trend is, at its core, a way to avoid hard conversations about the role of engineering in tech, and more widely the role of product teams and the ways they communicate to deliver solutions to the market in this incredible new and challenging era.