最近总有老板拿同一道题来找我对答案：「Airbnb 连 PM 都不要了，我们也砍，活让 AI 接走，这账对吧？」
我每次都回同一句：先别急着抄。Airbnb 那本账，你只看了半页。
把 PM 从组织图上划掉之后，Airbnb 转头新设了一个职能——program management，专门接住 PM 留下的排期和跨团队协调。头衔没了，活一件没少。
本篇判断：你以为的裁员，其实是一场拆账——头衔是会计科目，PM 手里的活一件没少，被拆成几份记到别人名下。组织图做的是减法，工作账做的是转移。
这篇解决什么问题：砍岗动手之前，先把「活去了哪」这笔账算清——写给手里正拿着组织图和预算表的老板、CHO 与 AI 转型负责人。
适用边界：两本账均为当事人自述，非独立审计，不构成控制实验；能回答「活去了哪」，回答不了「该不该砍」。
头衔先动了，活没动静
头衔的数据先动了。有机构做过一份 directional 抽样：2025 年 12 月对比 100 家 AI 与科技公司的在招岗位，模型厂和 AI 编程平台里，PM 头衔的占比比参照组少了三成多。可另一面，Lenny 那边 2025 年 5 月的市场数据又显示：尽管「AI 抢工作」的叙事弥漫，全球在招的产品经理岗位还有六千多个，比低谷期回升超过五成。
两笔数据摆在一起：头衔的统计吵得再热闹，也回答不了一个真正的问题——活去了哪。
手里正拿着组织图和预算表的，先别动手，读完再砍。
第一本账：Airbnb，砍了头衔，长出岗位
Lenny 做了很多年产品经理。他那位在 Airbnb 带过他多年的老上级，在播客里把这场改制的账摊开讲了一遍——先说清成色，以下是当事人自述。
账面是这么记的。
PM 这个头衔，改成了 PMM，产品营销经理。名字里带「营销」不是随手起的——营销是需要多年练习的专门能力，不是砍完岗顺手捡起来的杂活。
同时，公司新设了 program management，专门承接时间表和跨职能协调。这正是 PM 的活里最难随手塞给人的那部分：把散在各处、各管一段的团队，拉到同一张时间表上。
配套打法也变了：领导该介入自己有优势的决策，其他地方放手。
这位老上级补了句关键的话：这轮改制不是把 PM 的活一笔勾销，也不认为别的公司都该照抄这个做法。
组织图上少了「产品经理」一行字，工作账上多出两个承接方：营销的活记进 PMM，协调的活记给新设的 program management。
头衔的葬礼，可能是岗位的迁移。
第二本账：Linear 和 Mercury，从头不设这个岗
第二本账方向相反：Linear 少设 PM，Mercury 很晚才设 PM。
先看 Linear。约 50 人时只有一位 PM，当期访谈里他们自己讲，预计还要增招。
那 PM 的活谁在干？项目 lead 和设计工程，分担了 PM 的协调范围和进度工作。
三个细节值得盯住。lead 是任务指派，不是职级。他们明确说，这活不是人人都愿意接——它是从专业时间里硬剜出来的一块。招人标准也跟着改了：要挑有产品判断、能把自己的想法讲清楚的人。活摊下去了，人的底子得接得住。
再看 Mercury。涨到约 400 人时——粗估口径——名册上找不到一个正式 PM。
其实百人以下时，堵点就出现过。当时的解法是先设 business leads 顶着，后来才把名字改成 PM。
早期撑得住，靠创始人亲自贴着客户，加上一支有产品心的工程团队。等公司长大，创始人决策开始排队，合规、法务、风险的跨职能协作开始挤占每个人的本职——通才就算改个头衔，也补不上研究和规划的功课。
Mercury 后来怎么补课？先把对 PM 的期待写成职级矩阵，再照着矩阵招人——缺什么补什么，不是先砍人再指望补锅。
这两家的活账，记在了谁的工资单上？创始人的时间，工程师的专业时间，设计工程的注意力。免费寄生，不进任何一张报表。
省岗位不等于省工作。活没消失，只是在别人的工资单里白干。
两本账对上：活一件没少，AI 不在账上
把两本账对着读，条件相反，逻辑是同一条。PM 留下的活摊开来就三样：排期、对齐、盯上市。两家给出的答案一模一样——这三样一件没少，只是记账的科目变了。
| 公司 | 组织图上的动作 | 工作账上的去向 | 到头信号 |
|---|---|---|---|
| Airbnb | 划掉 PM 头衔 | 营销的活记进 PMM；协调的活记进新设的 program management | 不适用——已设专职承接 |
| Linear | 约 50 人只设 1 位 PM | 项目 lead 和设计工程分担协调与进度 | 当期自述：预计还要增招 |
| Mercury | 约 400 人（粗估口径）名册上无正式 PM | 前期靠创始人贴客户加有产品心的工程；百人以下先设 business leads 顶着，后来才改名 PM | 决策排队、跨职能协作挤占本职——写职级矩阵，照矩阵招人 |
组织图做的是减法，工作账做的是转移。
Airbnb 砍了头衔，新设岗位接活；Linear 和 Mercury 不设头衔，活先寄生在创始人、lead、设计工程自己那份工作上——直到协调开始挤占专业工作，才到了把这份活买回全职的时候。
Mercury 那期给过三个自查信号：决策出现瓶颈；专业工作被协调挤占；相邻的新客户群体需要正经研究。没有固定的人数阈值，只有这三条。
那 AI 呢？今年所有人抢答的答案。
我把话说明白：这两家处理 PM 头衔的时候，账本上接走活的，是 program management，是 PMM，是项目 lead，是创始人和工程师。AI 一个字都没出现。
这不是说 AI 接不了任何活。是说「AI 接走了」不能靠默认抢答——它得像每笔账一样，写清楚接的是哪一项、给了谁、验收人是谁。
至于满屏那句「PM 会不会消失」，吵的全是头衔：组织图上这个抬头有还是没有。头衔是会计科目，吵得再凶，也数不出活去了哪——吵了这么久，没有人下车间去数活。
改编制之前，先过四栏
给你一张表。这张表写给三类人：老板、CHO、AI 转型负责人。
动手之前先立一个规矩：按「活」过，不按「岗」过。组织图上的一行字，你没法判断该不该删。但「把三个团队拉上同一张时间表」这是一件具体的活，有人干、有成本、有产出，留不留，一眼可判。岗是科目，活是流水。对账，从来对的是流水。
把要砍的岗按「活」逐项过一遍，每项标进四栏：
| 四栏 | 要回答的问题 | 填不出来时说明什么 |
|---|---|---|
| 保留 | 这项活还必须有人干：还给谁？接手的人本职会被挤掉多少？ | 最常见的自欺是把「保留」填成「先让他兼着」——「兼着」不是答案，是把「迁移」留了白 |
| 取消 | 凭什么能取消？是产品真的简化到不再需要它，还是只是没人愿意承认它还在？ | 活还在，只是没人肯认 |
| 自动化 | AI 真正接走的是哪几项？哪一项、省出多少小时、谁来验收？ | 写不出具体项次的，先别写「已自动化」——那不是方案，是挡箭牌 |
| 迁移 | 新承担者是谁？他自己认了吗？ | 没让接活的人当面点头，这活就成了他深夜的义务劳动 |
砍完再装一个警报：当协调开始挤占专业工作——创始人排着队等人拍板、工程师白天写代码晚上拉通会——就是把这份活买回全职的时候。
这张表别做成 PPT。拿你公司真实在砍的那个岗，一行一行填，填不出来的格子，就是你要补的那场会。
省下来的是头衔还是排期，一查便知。
这张表什么时候失效
最要紧的一条：产品真的简化了，协调工作真的会变少。四栏里「取消」那一栏可以有实实在在的内容，别为了「活必须有人接」硬造岗位。
少设 PM 可以是合理选择——Airbnb 那位老上级自己都说，他们的做法不是每家公司都该抄。
再看成色：这两本账都是当事人自述，两家公司不构成控制实验。它们能告诉你「活去了哪」，回答不了「该不该砍」——那道题里装着你自己的产品阶段、团队底子和牌桌筹码。
我做了 18 年 HR，改过的组织图比我写过的文章多。每改一次都提醒自己：划掉一个名字只要一秒钟，接住他手里的活要一个季度。
下次再看到「某公司取消 PM」的新闻，别问「AI 什么时候接走」，先问：排期给了谁，对齐给了谁，上市那天谁站在发布按钮旁边？
这三个名字凑不齐，你砍掉的就不是岗位，是没人看管的活。
这张四栏表不用收藏，拿去就能用：挑出你正在砍的那个岗，今天填第一行，填不出来的格子，就是你下周要补的那场会。同一路问题的更多账本，收在「AI × 组织」主题页，正好接着翻。
继续看
- AI连入门活都包了，新人拿什么长出判断力？——AI 接走活的另一本账：判断力去哪儿长
- 小团队的人效神话，漏算了谁？——「省岗位不等于省工作」的另一半账