操盘手年鉴The Operators’ Almanac
AI · PB · 083

工程即 PM 两周法则

Two Week Rule Engineer As PM · two-week-rule-engineer-as-pm--amol-avasare
AI 与新工作方式 操作手册 AI 时代 2026-04 Amol Avasare ✓ 已核验出处

解决什么问题

AI(尤其 Claude Code 类工具)让工程产能 2-3 倍放大后,PM 和设计成为瓶颈、被严重挤压。这套规则回答:项目所有权如何在 PM 和工程师之间重新划分,PM 的时间该花在哪。

核心内容

背景判断:目前 AI 给工程的杠杆最大。一个默认团队(5 工程 + 1 PM + 1 设计)产出上等效于旧世界的 15-20 工程 + 1.5-2 PM + 1.5-2 设计——头衔和编制没变,但 PM/设计实际在服务一个大得多的工程组。

两周规则

  • 项目 ≤ 2 个工程周 → 工程师全权充当 mini-PM:自己对接安全、法务、跨职能 stakeholder 并推进;PM 只做顾问,项目严重跑偏才介入。
  • 项目 > 2 个工程周 → PM 默认负全责(可以多授权给工程,但 squarely accountable)。
  • 例外靠判断:一周的项目如果极具争议,仍应由 PM 主导。

配套动作

  • 刻意招聘 product-minded 工程师——能当 mini-PM 的工程师价值数量级上升("unicorn");同时照常多招 PM,两条腿走路。
  • PM 时间的最高杠杆(规模化公司):不是自己 ship 第 21 个 feature,而是把团队"why/what"的判断质量提高哪怕 5%、把工程师带成更好的 mini-PM。小公司或工程紧张时 PM 仍应亲自 ship;用 prototype 表达脑中想法仍然高价值(prototype 即新 PRD)。
  • 文档观:约 60-80% 的 ship 没有 PRD,小事直接 Slack 来回;投入大的事必须开 30 分钟跨职能 kickoff(法务、safeguards 等全拉进来,逐个问"你 care 什么"),前置消除后期的混乱。

适用边界

  • 面向 AI 加速下的中大型组织;15-20 人小公司会走向极端角色融合(PM 直接设计、发版),不需要这套划分。
  • 开发者产品团队天然更依赖工程师(Claude Code 团队的 PM 本身就是工程师背景),阈值可再放宽。
  • 作者强调"is not fully clean-cut",规则是过滤器不是铁律。

关键引述 · 原话

"If a project is two weeks of engineering time or less, then the engineer is on the hook to effectively be the PM for that." — Amol Avasare

"The engineer who is highly product-minded is a unicorn, is an absolute unicorn." — Amol Avasare

关联卡片

- 与 cash-automated-growth-loop 卡呼应:跨职能 stakeholder 管理是最难自动化、也是 PM 保留价值最高的环节。 - 与"PM 应该人人写代码"的流行叙事相反:在工程被 AI 放大的组织里,PM 的相对稀缺资源是判断力而非产能。

被这些卡引用

出处Amol Avasare (Anthropic Head of Growth) · 03-podcasts/amol-avasare.md
提炼自 Lenny Rachitsky 的 Lenny’s Newsletter & Podcast(2019–2026)。本站为个人学习用途的二次创作,与 Lenny’s Newsletter 无官方关联。
provenance · 已核验 · glm-5.2