The "PM Who Codes" Problem
In an internal Meta post that went viral, a senior Product Manager shares his sharp opinion on a trend shaking tech: PMs who code and push to production.
The Argument Against Prod Code
The reasoning is brutal but logical:
- If the feature is important, fix the prioritization system rather than bypassing it
- You code like a slow E3 but cost an IC7 salary
- Tech debt accumulates with PM "pet features"
- Your senior TL friends review your code, but it's poorly used time
The verdict: PMs landing prod diffs are "snacking" — mistaking motion for progress.
So Why Should PMs Code?
The author doesn't say PMs should never code. He clarifies when it's useful:
- Better communicate an idea: showing beats telling
- Understand the systems: prioritizing and communicating with engineers is easier when you understand how things are built
- Realistic experiments: mocks and UXR studies with static prototypes are dead
- Leverage unique talent: for example, deep knowledge of an API from your previous company
- Fun: coding can be enjoyable, and that's ok
The "Vibe Coding" Context
The term "vibe coding" describes this trend where non-developers use AI to generate code and push to production. With Claude Code, Cursor, and other tools, the barrier to entry has never been lower.
But low barrier doesn't mean no risks. Generated code can work locally and break in production. Edge cases aren't handled. Maintainability doesn't exist.
The Real PM Skill
The post concludes on what PMs should really do with AI: build EVALS. Understanding how to measure AI output quality is far more valuable than generating code yourself.
It's a nuanced position worth reflecting on: AI changes the game, but the PM's role remains strategy and prioritization, not implementation.