一年前,有人说 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 的:列出自己最引以为傲的几项手艺,问问哪一项现在用“做三个版本试一试”就能替代。技术每过几个月就换一次,该扔掉的是做法,留下来的,应该是“这个人到底遇到了什么问题”。
结尾
也欢迎大家留言讨论,分享你的观点!
觉得内容不错的朋友能够帮忙右下角点个赞,分享一下。您的每次分享,都是在激励我不断产出更好的内容。
欢迎关注深思圈,一起探索更大的世界。
两个“特别坑”的AI产品创业方向,你知道吗
速度将成为AI时代唯一的护城河
a16z重磅预测:Vibe coding赢者通吃?错了,垂直专业化才是未来
热门跟贴