AI · PB · 083
工程即 PM 两周法则
Two Week Rule Engineer As PM · two-week-rule-engineer-as-pm--amol-avasare
所属簇 AI 时代的工程组织与管理
解决什么问题
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
提炼自 Lenny Rachitsky 的 Lenny’s Newsletter & Podcast(2019–2026)。本站为个人学习用途的二次创作,与 Lenny’s Newsletter 无官方关联。
provenance · 已核验 · glm-5.2