PMs Shouldn't Vibe Code: Why Product Managers Should Stay in Their Lane

A Meta PM argues that product managers wasting time landing production code is low-leverage work that creates tech debt, advocating instead for focusing on prioritization and building EVALS.

Daniel D. McKinnon, a product manager at Meta, has sparked debate with his internal memo that's now gone viral: product managers shouldn't waste time landing production diffs, no matter how tempting AI coding tools make it seem.

The core argument is brutally simple: if a feature is actually important, fix the prioritization system rather than circumventing it. McKinnon points out that PMs coding at Meta scale is like "a slow E3" costing the company an "IC7 salary" - a stark reminder of the economics at play.

The Real Cost of PM Code

The problems McKinnon identifies go beyond just wasted salary:

Tech debt accumulation: Random PM pet features create maintenance burden
Production risk: Even intern tool changes can break production
False progress: "Snacking" on small diffs while mistaking motion for progress
Leverage issues: Using senior tech leads' time for PM code reviews isn't high-impact

When PMs Should Code

McKinnon isn't anti-coding for PMs entirely. He sees value in coding for:

Better communication: Showing rather than telling ideas
System understanding: Making prioritization and engineering communication easier
Realistic experiments: Moving beyond static prototypes to test with human volunteers
Unique resource leverage: Using domain expertise (like deep API knowledge from previous roles)
Fun: Sometimes you just want to build something

The AI Era: Build EVALS

McKinnon's most actionable advice for PMs in the AI era is refreshingly specific: "Build EVALS!!!" This suggests PMs should focus on evaluation frameworks and metrics rather than production code, ensuring AI features actually work before they ship.

The Broader Question

The memo raises a fundamental question about role boundaries in tech companies. As AI coding tools democratize software development, should PMs expand their technical scope? McKinnon's answer is clear: at scale, the opportunity cost is too high. The PM's unique value lies in prioritization, communication, and strategic thinking - not in becoming a junior engineer.

For PMs tempted by the allure of landing their own diffs, McKinnon's message is sobering: your time is better spent fixing the system that determines what gets built, not building things yourself. In an era where everyone can code, the real skill might be knowing when not to.