我赌产品经理这个岗位会消失
当代码近乎免费、迭代成本崩溃，把「想清楚」和「做」分开反而成了最大的瓶颈。PM 这个 title 正在被解构——一部分上移到 founder，一部分下沉到 agent。
三个月前，我撤掉了公司里最后一个产品经理岗位。
不是因为他不行——他是个非常好的 PM，去了 Anthropic。是因为我把一件让自己都不太舒服的事情想清楚了：在 2026 年这个时间点上，产品经理这个角色不再让我的公司变快，它让我的公司变慢。
这篇文章是我想清楚这件事的过程。
如果你今天是 PM，请你读完。我没打算骂 PM 群体——我攻击的是这个岗位的定义，不是个体。我也会在文末给你一条我认为更值得走的路。
一、PM 是怎么来的
软件公司的 PM 这个职位，并不是从产品本身长出来的。它是从「代码贵 + 工程师不懂用户 + 决策需要前置规划」这三个约束里长出来的。
90 年代微软定型的"program manager"，2000 年代 Google 把它变成"PM = 半 CEO"，2010 年代 Lean Startup 又把它压成"假设-验证-迭代"的中枢。每一次迭代，核心都没变——
PM 是一个协调成本的应答。
它应答的是这样一个世界：写代码很贵，所以你必须先想清楚再写；工程师离用户太远，所以你需要一个翻译；多个团队要对齐，所以你需要一个调度。
在这个世界里，PM 的存在完全合理。过去 20 年软件行业能跑成今天这样，PM 群体功不可没。我必须先说清楚这一点，下面的话才有意义。
二、三个假设，在过去 18 个月崩了
让我把上面那个世界的三个假设一条一条拆开。
假设 A：写代码很贵。
2024 年初，我们做一个中等复杂度的 feature，从 spec 到上线大概 5–7 个工作日。2026 年 5 月，同样复杂度的 feature，从一句话描述到上线，常常是同一个下午。
不是"AI 写代码"这么简单。是工程师 + Cursor + Claude Code 的组合，让"写"这个动作从最贵的环节，变成了最便宜的环节。当写变便宜，"想清楚再写"这个前提就动摇了。
假设 B：决策需要前置规划。
PRD 这个东西，它的隐含寿命是"比实现长"。你花两周写 PRD，是因为实现要花六周。如果实现只需要两天，PRD 的存在反而是负担——它的更新成本，比直接做一个原型还高。
我们公司现在的 spec 流程是这样的：一个想法，一个段落，一个 30 分钟的 Cursor session，一个能点的原型。这个原型本身就是 PRD。它不需要被翻译成代码，因为它已经是代码了。
假设 C：工程师不懂用户。
这一条，过去十年其实就一直在松动。今天的工程师工具是「PM-aware」的——Linear 让你看到 issue 背后的客户、Notion AI 让你写 PRD 像写代码、Cursor 在 review 你的 PR 时会问"这个改动对用户的影响是什么"。
工具在反向训练工程师。一个 2026 年的中级工程师对用户的理解，常常比 2018 年的中级 PM 更扎实。因为他每天都在用一套内嵌了"用户视角"的工具。
这三个假设里，任何一个崩，PM 的存在意义都要被重新打分。三个一起崩——这不是"PM 要少招"，这是 role 本身要被解构。
三、PM 现在让公司变慢的四个机制
承认 PM 不再是加速器之后，我观察到四个具体的减速机制：
1. Context tax（上下文税）
每一次 PM 把客户的话翻译给工程师，信息都要被压缩、再展开。压缩的过程丢东西，展开的过程加噪音。当工程师能直接接触客户、直接跑 prototype 时，PM 这一层翻译反而是损耗。
2. Handoff loss（交接损失）
经典软件工程里有 Conway's Law：组织结构会决定系统结构。PM-Designer-Engineer 这个三人 handoff，不可避免地会把一个本来连续的产品决策，切成三个不连续的"模块"。每个交接点都掉信息，最后的产品就长得像一个组织图，而不是像一个用户的需要。
3. Roadmap as fiction（路线图是写给上面看的小说）
老实说——你们公司的 roadmap，有多少是真的指引执行，有多少是写给投资人和老板看的剧本？
我自己经营公司这几年，越来越觉得 roadmap 这个 artifact 是给"上层"消费的，不是给"做事的人"消费的。一个本来用来对齐的工具，慢慢变成了一个用来 perform 的剧本。
4. Political layer（政治层）
最致命的一条。当公司有 5 个 PM，他们之间的优先级谈判、KPI 博弈、roadmap 抢占，会变成 founder 必须介入的政治。这个政治层不创造任何客户价值，它只消耗组织里最稀缺的资源——founder 的注意力。
四、PM 的工作流，去了哪里
我把 PM 这个 role 拆解成具体动作，每个动作问一句"这件事 2026 年最该谁做"，得到下面这张表：
| PM 原本的动作 | 在新世界里去了哪 |
|---|---|
| Vision、品味、客户爱 | 上移到 founder |
| Spec、协调、QA、release 管理 | 下沉到 agent |
| 用户研究 | 保留，但叫 researcher，不叫 PM |
| 优先级 | 保留，但是 CEO 的工作 |
| 跨团队对齐 | 如果你需要这个，说明组织太大了，先缩团队 |
| Design taste、edge case | 平移到 engineer |
最关键的一行是"下沉到 agent"。
Spec、协调、QA 这三件事，过去之所以贵，是因为它们是"需要懂上下文、又愿意做重复事"的工作——人类做这种事很贵，AI 做这种事极便宜。当你的 spec 由 agent 起草、agent 协调、agent 跑 QA，PM 这个角色里最大的一块工作量，几乎是免费的。
这就是为什么 Linear 200 人、Midjourney 50 人、Cursor 一个相当克制的 team——它们做的产品体量，过去需要 PM 团队 20 人才能撑起来。
五、给今天还是 PM 的你
如果你今天是 PM，我必须诚实地说：我不建议你转行，但我建议你转身份。
我观察到三条出路，都是我身边真实在发生的：
1. Product Engineer。 学会自己写代码——Cursor 让这件事不再可怕。一年之后，你会是这个时代最值钱的 hybrid：既有 PM 的判断力，又有工程师的执行力。Stripe、Linear、Cursor 都在抢这种人，title 通常叫"product engineer"或"founding engineer"。
2. Independent builder。 PM 的真正 superpower 是"能把一团模糊的需求收敛成一个可被实现的东西"。这个能力加上现在的 AI 工具，意味着你可以直接做产品。过去三年我看到最多的 PM 转向，是自己 ship 出了一个小产品，然后这个小产品变成了一份比简历更好的简历。
3. Founder 的 Chief of Staff。 在更大的公司里，PM 这个 title 会逐渐演化成"founder 的延伸"——不是"中层管理"，而是"上层放大"。这个角色不会消失，但它的人数会从一个公司 20 个，回到一个公司 1–2 个。
我攻击的是 role definition，不是 个人能力。如果你是个好 PM，你的能力非常稀缺；只是承载这个能力的容器要变了。
六、一个实验
我不想用任何"未来已来"这种话结尾。
我想给你一个具体的、明天就可以做的实验：
下周，挑一个你最近正在 spec 的 feature。不要写 PRD。打开 Cursor，把这个 feature 的第一版自己写出来。不为了交付，为了感受。
感受完，你自己会知道我这篇文章是夸张了，还是说轻了。
90 年前，经济学家 Ronald Coase 问过一个看起来很无聊的问题："公司为什么会存在？" 他的答案，奠定了过去一个世纪我们关于组织的全部直觉。
我下一篇文章想写的是：Coase 的答案，正在 90 年里第二次失效。PM 这个岗位的命运，只是这个更大故事里的一个小注脚。