一年前说 PM 会被淘汰，现在 Anthropic 说：人人都得学会当 PM

guozi

在一场现场对话里，Anthropic 的 Ami Vora 把产品定义成连接人们的问题与可用技术的桥：人的一侧变得慢，技术的一侧却从五年一变变成两个月一变。她的同事 Mike Krieger 转做一线贡献者后，被提醒项目需要一个 PM。



一年前，有人说 AI 可能让 PM（product manager，产品经理）变得多余。现在，气氛变成了人人都要学会当 PM。这是主持人 Dan Shipper 在开场时的原话，台下笑了，但他问的是一个真问题：做东西越来越容易，为什么反而更需要有人去决定做什么、对结果负责？

这是 9 月 10 日 Lenny and Friends Summit 在旧金山的一场现场对话，Lenny’s Podcast 在 9 月 29 日发布了视频。嘉宾是 Anthropic 的 Ami Vora 和 Mike Krieger，两人都在做产品，Mike 今年年初转做 IC（individual contributor，一线贡献者），现在主要自己动手做东西。他们要回答的是：当技术每隔两个月就变一次，PM 这个角色还剩什么，又有哪些东西该扔掉？我看完的判断是，PM 的工作没有消失，只是最贵的部分换了位置。
技术两个月变一次，人的问题没有变
Ami 对 PM 的定义很简单：产品是连接现实中人们的问题和可用技术的一座桥。这一点一直没变，变的是节奏。过去技术可能五年、十年才变一次，现在感觉是两个月一次。她说，作为一个人，要适应这种速度真的很难。

所以她的办法是把两边拆开看。人的一侧变得慢，大家遇到的还是那些问题，那就一直盯着人的问题不放。技术的一侧则要保持新鲜的眼光：把自己知道的“过去这个问题怎么解决”大部分扔掉，带着对问题的理解重新试一遍。

她还说，现在有点像把时钟拨了回去。她刚入行的时候，这份工作没有清晰的定义，PM 就是一个通用的问题解决者，到处走，撞到墙了就去问人或者想办法。现在角色的边界又在变模糊，只不过这一次，撞墙之后手边有各种各样的脚手架可以用。

我觉得这段话把“变”和“不变”拆得很清楚。很多关于 PM 会不会消失的争论，其实是把两件事混在了一起：做事的方法在飞快过期，做事的理由却没有。理由没变，就意味着这个角色不会凭空消失，但做法要随时准备重来。
Mike 以为 Claude 能顶替 PM，被提醒后改了口
Mike 讲了一个最近的经历，几乎就是对开场问题的回答。他转做 IC 以后，手上有个项目快要上线，一位和 Ami 合作的 PM lead 把他拉到一边，说这个项目需要一个 PM。他的第一反应是：真的需要吗？Claude 不是已经能搞定了吗，我们手上事情还很多。对方坚持说需要。等她加入之后，他才看到所有那些如果自己不管就会掉在地上的胶水和连接工作。一周后他回头给她发消息说，你是对的。

他列了一串这个角色在做的事。Anthropic 的客户从个人专业用户到大型企业都有，各种情况有没有考虑到？客户成功团队要在问题实时冒出来时给出解释，有没有人想过？安全防护有没有拉进来？大家是不是都在正轨上？哪怕有 AI 帮忙，也没有人有无限的精力。需要有人确保一切接得上，始终惦记着最终用户，这样埋头做事的人才能一直埋头，不用时不时抬起头去做另一种完全不同的活。

Dan 追问得很直接：为什么不干脆让 Fable 来做？Mike 的回答是，他们内部确实在用 Claude 做很多连接工作，它能提醒你，组织里另一个角落正在发生和你有关的事。但他认为，Claude 目前还不是一个 convenor（召集人）：总得有人把 Claude 们和人聚到一起，让事情落地。他开玩笑说，等哪天 Claude 自己给他排了一个会，他会问是谁约的，然后发现是 Claude 觉得他们两个该聊聊。这件事还没发生，“但不是因为做不到，大概只是我们还没打开那个设置”。

我的想法是，这一段值得小心读。Mike 自己都说了，“还不是召集人”不等于“做不到”，所以拿它当 PM 的护身符是靠不住的，它有保质期。更稳的理解是，这类工作的难点在于需要有人对“整体有没有接上”负责。速度变快以后，漏掉的东西更容易悄悄溜走，Mike 也说，这个角色现在要做得比以前更精细。如果你在组建团队，这顶帽子只会越来越重要。
过去引以为傲的手艺，有一部分已经过期
Ami 讲了一件让她不太舒服的事。她花了很长时间训练自己站到用户的角度，想象一个功能怎么放进别人的生活。因为过去做出来、上线一个东西太贵，所以评审会上要反复讨论按钮放哪里，手指在手机上怎么移动，用户是在什么情境下把手机从口袋里掏出来的。她说，现在大概没有人会再问她这类问题了，更快的办法是直接做三个版本试一试。

她觉得最难的是身份。大家都知道创新者的窘境，说的是一家公司太擅长某件事，就一直做下去，哪怕应该试试别的。她说个人也一样：你知道自己擅长什么，就想继续做下去，哪怕新的方法在未来更重要。她也没有在模型公司工作过的背景，所以每过几个月，就得对自己说：好，那就试试这个，看能不能弄明白。

那什么能力是现在更需要的？她列了三个：适应力，也就是把自己对变化的容忍上限抬高；判断力；还有一股不屈不挠的劲。后两个其实来自同一个变化：工具越好，能做的东西越多，岔路就越多。你得在信息有限的情况下判断要做什么，然后比过去更执着地让它真的发生。

她也谈到怎么带团队。不确定的时候，人会忍不住想把一切规划清楚，包括要做哪些产品、职业会怎么走，这是一种拿回控制感的办法，但会把你锁在新东西之外。她的做法是 frame the chaos（给混乱搭一个框架），让大家觉得参与进来是安全的，也承认这里面有情绪，不轻松。Mike 补了一句，混乱之外需要清晰的 DRI（directly responsible individual，直接责任人）。实验室里把一个个尝试叫做 bet，每个 bet 都有一个 lead，由他来说该不该加码、该不该收掉、团队要加人还是减人。用他的话说，大家一起在黑暗里摸索，但总得有人握着笔。

我觉得这里有个容易被忽略的细节：被淘汰的不是某个岗位，而是岗位里一些很具体的手艺。按钮该放哪里这种判断，过去是稀缺能力，现在被“做三个版本试一试”取代了。真正难的不是学新东西，而是承认自己最拿手的那一块已经不值钱了。
软件要让 agent 也能用，先把基础零件做对
话题转到产品本身，Dan 问 Mike，当软件的使用者从只有人，变成人和 AI agent 一起用，应该怎么设计。Mike 给了一条时间线。最早是把 AI 放在一个侧边栏或者小窗口里，和产品其余部分是断开的。后来有一些功能本身由 AI 驱动。再往后是 agent-native（原生为 agent 设计）：人能做的事，agent 也应该都能做。他说很少有产品真的做到了这一点，包括他们自己的产品。可一旦做到，就会冒出一些新的行为，比如 agent 能把以前没连起来的东西拼到一起，或者主动提出别的做法。

他认为下一步是界面本身也能被 agent 改写，也就是 malleable software（可塑软件）。这个概念谈了很多年，他觉得现在真的在变成现实。他举了一个内部的例子：他们正在做一个比较复杂的项目，至少有四条独立的工作线。团队让 Claude 一边盯着进展，一边生成界面，先给 TPM（technical program manager，技术项目经理），再给整个团队看项目现状。你不喜欢这个界面，就不必接受别人决定好的样子，可以和 Claude 一起改。他说，过去一年 Anthropic 里最大的变化之一，就是大量日常用的软件由 Claude 构建、维护和迭代，随时都在变。这也带来新问题，比如谁可以更新数据，是人点击，还是 Claude 在后台改，数据的来源该怎么追溯。

如果你是一家已经有成熟 SaaS 产品的公司，该怎么选？Mike 的建议是，核心是在产品里建好 primitives（基础组件），像一层基础设施。他自己每次用新产品，都会让它做一件人能做、但需要想一想的事，看操作是否都走同一套底层通道，让 agent 和 REST API（常规的程序接口）能共用。想得周全的产品，用起来能感觉出来。他也承认，一个做了 20 年的应用要后补这一层很难。好处是一旦做对，就可以一步步演进：先保留侧边栏，再试一个更可塑的个人首页，用的是同一套底层，不必重新发明基础设施。感觉“贴上去”的产品，就是没有这一层。

我觉得 Mike 的这个检验法比很多方法论都实在。判断一个产品是不是 agent-native，不看它宣传里有没有 AI，而看它里面一件稍微复杂的事，是不是走同一条底层。如果每个入口各走各的，那 agent 永远只是后加的访客。
多押几注，再收拢成一个产品
Anthropic 要同时服务很大一段范围的用户：想往前冲的人，只想聊天的人，有大企业合同、不能一天之内换掉界面的客户。Dan 问，这怎么平衡？Ami 说得很坦率：这是个很难的问题，他们的做法是尽量在每个人所在的位置上接住他们。现在要弄清楚什么有效还太早，产品不是稳定的，不是找到正确答案做出来就行，是大家一起探索。所以她鼓励团队多试，哪怕几个东西有点重叠、有点重复，等弄清楚、找到 PMF（product-market fit，产品和市场匹配）之后，再回过头把它们整合成一个对所有人都说得通的东西。

她把最坏的结果说得很具体：一开始就根据一套理论认定“应该这样”，把产品限制得死死的，一个连接市场的机会都没给。她宁愿要五个互相重叠、各有做法的产品，也不要一个被过度约束的。Mike 补充了一个关键条件：这些方向要有真正兴奋的团队。他说，让一个对方向不感兴趣的团队去做一个“B 队”的产品，从来没成功过，结果一定很糟。

并行实验要能做起来，靠的是底层。Mike 说，几个月前，chat 和 Cowork 的记忆系统、MCP（Model Context Protocol，让 AI 调用外部工具的协议）和文件存储方式都不一样，在上面做新实验会很吃亏：做出来第三个东西，和另外两个都不共享记忆，一开始就像是被孤立了。所以他们有个 foundations 团队专门解决，让你不管在哪个产品里，都能带着自己的记忆。他强调，这类事要交给不同于创新团队的人去做，实验才会彼此互补，哪怕有重叠。Ami 则强调，要把话说出来：三个方向并行，有时会让人沮丧，觉得自己是不是被放弃了。这没关系，这是我们所处的世界，没有人知道答案，我们都在同一个团队里。

怎么知道一个东西开始有效了？Ami 说，大部分还是普通的 PMF 信号：人们用不用，喜不喜欢，会不会回来，会不会和别人聊，有没有得到价值。产品的目标没变，还是解决问题。

Mike 还讲了一个很有意思的做法：把项目“停放”。他们 2024 年在 Anthropic 内部做出了第一个 computer use 产品，当时模型还不够强，用起来很糟。起初他们想，也许它不适合做自动化，但适合做教学，比如问怎么在 Photoshop 里做一件复杂的事。结果它能做到，但是用的是早期 agent 那种方式：试一下，不行，关掉再来，二十分钟后终于做成了，你什么也没学到。自动化和教学两头都不行。于是他们把它停放了，之后每出一个新模型，就放进 eval harness（评测框架）里跑一遍。有一次换了新模型，他们突然发现它成功的次数多过失败，翻看记录，意识到这是真正的变化。他们在实验室里把这也算作一次胜利：就算项目只证明了模型还没准备好，只要沉淀成 eval，或者和研究团队建立了连接，几个月后就可以重新来过。他的看法是，要早点做，才会有这种直觉。

Dan 接着说，这有点像一种 capability blind（能力盲区）：试过一次，没成，就再也不试，也不做评测，结果三个月后新模型出来，在他们想不到的地方变好了。他说自己常遇到别人说“它做不到这个”，一问，用的还是旧模型。

最后一个难题，是并行实验里有一个跑通了，要怎么放回产品。加一个 tab，tab 越来越多，各自的用法不同，看着很难看。做成独立的 app，又永远不合并。Ami 半开玩笑说“我不知道你在说什么”，然后承认没有完全想清楚。她的方向是回到 primitives，让产品用起来是该有的样子，别把认知负担一股脑转给用户，说“这里有一堆工具，你自己选吧”。Mike 从 Instagram 的经验补了一个现实判断：使用高度集中在主 feed，大概占 80%，把 explore 做好，也许只是从 10% 到 15%。所以永远要问，主 tab 是什么，怎么把这个体验做好，再让它成为通向其他体验的入口。他说，PM 一半的工作，是对侧边栏里多一个东西、多一个 tab 说不，同时又判断它能不能在验证后被合并进来，而不是太早杀掉。
做东西变便宜之后，值钱的是判断和收拢
回到 Dan 的问题，我对这场对话的理解是：AI 没有取消 PM 的工作，是换掉了这份工作里最贵的部分。以前贵在做之前想清楚，因为做错的代价高，所以才会为按钮放在哪里反复开会。现在做错便宜了，贵的是三件事：信息不足时决定做什么；在越来越多的岔路里持续推进；把并行出来的东西接起来、收拢成一个产品。Mike 讲的接缝工作、Ami 讲的判断和执着、两人都讲的主 tab 和 primitives，其实说的是同一件事。

不过要读出这场对话的边界。这是模型公司的内部视角。Anthropic 有 foundations 团队专门去统一记忆这类底层，有实验室可以把项目停放起来等新模型，这样的余量大多数公司没有。视频里也没有给出任何数据，说明并行押多个方向的成本有多大。而且“PM”在这里更像是一顶帽子：Mike 自己是 IC，也需要有人替他戴上。他说 Claude 还不是召集人，却没有说它做不到，所以这个结论会过期。

如果要把这场对话变成具体的行动，我会留两个检验。一个是 Mike 的：让自己的产品做一件人能做、但要动点脑筋的事，看它是不是和 agent 走同一条路。另一个是 Ami 的：列出自己最引以为傲的几项手艺，问问哪一项现在用“做三个版本试一试”就能替代。技术每过几个月就换一次，该扔掉的是做法，留下来的，应该是“这个人到底遇到了什么问题”。

本文由人人都是产品经理作者【深思圈】，微信公众号：【深思圈】，原创/授权 发布于人人都是产品经理，未经许可，禁止转载

题图来自Unsplash，基于 CC0 协议

--------------------------------------------------
本文转载自：https://www.woshipm.com/pmd/6473402.html