To save you some time and frustration, here’s the debate in a nutshell:
Camp 1 - Generalists: PMs should vibe code, because then one person can do everything, and we don’t need those slow painful handovers between PMs, designers, and engineers
Camp 2 - Specialists: PMs should not vibe code, since they will never be as fast and good as engineers. Instead they should focus their energy and time into getting better at what product managers do: Financial acumen, strategy, discovery, empathy etc.
Camp 3 - idiots: RAAH RAAAAH IF YOU DON’T LET CLAUDE RUN YOUR LIFE BY NOW YOU’RE GOING TO LOSE YOUR JOB RAAH RAH
If we disregard the madness of camp 3, camp 1 and 2 both make valid, paradoxical points. I consider myself a proud member of both.
I know. Nuance. Boring.
I’ve been in tech for 15 years. In by far most product/tech organizations I’ve worked in/with, Product spent *way* too little time doing “proper” product work: getting inside the heads of the target audience, understanding what the core value of our product is/should be, and making sure we live up to that promise.
Instead, most product people spend far more time
Managing stakeholders, as if they’re a rabid pack of dogs that needs to be lulled into submission
Writing the perfect Jira ticket to make engineers purr like happy little kittens
Translating useless story points into more useless “the feature will be done by date” estimates
Sitting in scrum meetings, to varying degrees of uselessness
What Marty Cagan so aptly calls product management theater. 80% of our time went to the work organizations made necessary to make delivery work, leaving us with only 20% to check whether that was even the right thing to build.
With coding agents, we have a whole new army of people who can waste time building the wrong thing. But now we get to waste time in a new, shiny way.
The problem is, and always has been, that we have far too much conviction in what needs to be built.
We fall in love with the very first idea the CEO/ some expert at a conference/ a customer / (fill in the blank) puts forward. We fail to wonder about the underlying customer opportunity (why is this a good idea? What might it accomplish?); we don’t do the legwork to understand if that opportunity actually matters; We don’t come up with varied solution ideas to make sure we pick the best one; We skip straight past testing.
Confirmation bias ruled us before AI, and it still rules us today.
The real distinction: Build to ship vs. build to learn.
Building to sell means creating production-grade software you intend to commercialize, roll out, and maintain. It has customers who depend on it, code that must be reviewed and owned, and a long tail of support. Engineers own this.
Building to learn means creating something small and disposable to validate a risky assumption. Its job is to produce evidence, and once it has taught you what you needed to know, you throw it away. Nobody maintains it, because there’s nothing to maintain.
When a PM vibe codes to learn, camp 2’s objection evaporates, because that hour was never stolen from discovery (actually quite the opposite - it speeds up discovery dramatically).
Imagine we want to run a 1:1 landing page test with 10 participants to see if our new value proposition is understood and resonates. Traditionally, the PM running this test would collaborate with Product Marketing to come up with different versions of the wording, then create a ticket for Design to mock up one or more landing pages, and then wait, because the designer is *maxxed* out creating designs for the feature to be delivered this sprint. Now the PM can vibe code those pages in an afternoon (ideally using a predefined design kit or a skill created by the designer), and the test runs this week instead of next quarter.
Or imagine you have ten competing ideas. In the past, we had to talk in hypotheticals endlessly to decide which one to invest in. Today, we can quickly spin up a rough prototype for each idea, try each on for size, and throw away 80% of them. It’s like the difference between browsing cars online and getting to test drive them.
This is just solid product management work. No shiny new object syndrome here.
Raise your hand, if you’ve ever built an MVP (a real one, with the purpose of just learning one important thing), and then have been asked to work magic to turn this thing into a scalable Product Capital P. My high hopes are that thanks to agentic engineering the temptation of doing this will be lower. We’ll have invested far less energy and resources into the MVP, so throwing it away should hurt less. If the MVP proves the assumption to be true, and leads us to decide we should build for production, then the rebuild is owned fully by engineers.
But what about PMs shipping small changes to actual users? Those crazy “builder” types that are submitting PRs left, right, and center? I’d still call it building to learn, since the intent is evidence rather than revenue, but the artifact is production code, and so the artifact’s rules win: an engineer reviews it, an engineer owns it.
The question to ask before anyone builds anything
Are we building to learn, or building to sell?
Building to learn: the PM builds it (or the designer, or whoever is closest to the assumption), it stays disposable, and nobody maintains it. Vibe coding becomes a tool to do discovery and build that illicit “product sense” over time.
Building to sell: engineers own it, whatever tools they use to write it.
Hold that line and both camps 1 and 2 are right. The generalists are right that the distance between the person closest to the customer and the person building should be as small as possible. The specialists are right that production software deserves specialists.
Work with me? I am available for interim and consulting work from 15.09.26.
Connect with me on LinkedIn and reach out via DM, or first browse my portfolio.
No posts
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.