

01 停下来的那一秒
:::最近我在翻 Ben Horowitz 那篇老文章——《好 PM / 差 PM》。这篇写于 2004 年,已经成了产品经理界的某种入门圣经。我大概每隔两三年会重读一次,每次都有不同的感受。
这次读完,我停了一下。
不是因为文章过时了。恰恰相反——很多内容在 AI 时代变得更扎心了。Horowitz 说的核心区别是:好 PM 对结果负责,差 PM 对过程负责(或者说,对"看起来很忙"负责)。这条区别在今天依然成立。但它的含义已经变了。
AI 把这条界线,变成了肉眼可见的边界。
02 那层缓冲没了
:::过去,很多产品经理的日常工作是这样的:整理客户访谈录音,写 PRD,拆分 tickets,做 roadmap 更新,发 launch notes,同步 stakeholders,把模糊的需求翻译成看起来合理的文档。这些工作有些是有价值的,但相当一部分,只是在维持一层叫做"协调成本"的东西。
这层东西是真实的。它需要时间,它也确实可以让人显得很忙。
AI 把它压缩了。
客户访谈总结,便宜了。PRD 初稿,便宜了。tickets 拆分,便宜了。roadmap 更新,便宜了。发布说明,便宜了。跨部门同步,正在变便宜。甚至连功能的第一个版本,都开始变便宜了。
你数一下,这几乎覆盖了一个普通 PM 一周里大半的时间。
曾经,平庸的 PM 可以藏在协调成本里。他们看起来很忙,因为他们确实很忙——参加会议、维护追踪表、综合反馈、推动对齐、把模糊的需求翻译成看起来合理的文档。一部分这类工作是有意义的,但相当一部分,是一种职业化的外壳,包裹着真正重要的产品工作。
AI 正在拆这层外壳。
03 藏不住了
:::这不意味着 PM 不重要了。恰恰相反——它意味着好 PM 和差 PM 的区别,变得一眼就能看出来了。
文章作者 Dhruv Vasishtha 是 PatientPing 和 firsthand 的前产品负责人,现在在做医疗领域的新项目。他说,他跟今年遇到的每个 CPO 聊下来,他们都提到了同一件事:很多 PM 先感受到的是压力,而不是机会。
如果你不变成 AI 原生,你会落后。如果你变成了 AI 原生,你只是跟上了大家,但接了更多工作。
我理解这种感受。但我觉得他说的那个框架,比大多数人意识到的要重要得多。
而且不只是 PM 的问题。这一套逻辑,对任何知识工作者都成立:AI 压缩的是可编码的、可重复的、靠信息综合就能完成的那些工作。剩下的,是判断、关系、现场感,和只有在具体情境里才能理解的那类东西。这些,从来不是可以自动化的。
04 信息不对称机器
:::他的核心论点是这样的:
好 PM 会成为一台面向客户的信息不对称机器。他们的工作,是挖掘那些会改变公司应该做什么的隐藏信息。
公开信息已经被大语言模型大面积索引了。原来靠"能综合公开研究"获得的优势正在消失。如果答案就在公开互联网上,模型大概能帮任何人得到一个还不错的版本。
所以 PM 必须去找模型找不到的东西。
那是什么东西?
05 AI 找不到什么
:::他列了四类:私密的、非结构化的、本地的、或者客户自己都还说不清楚的信息。
买家只有在信任你之后才会说的那句话。用户因为觉得太奇怪而不好意思承认的那个变通方法。公司"官方流程"和"周五下午四点半实际运作方式"之间的那个落差。
这些,模型都不知道。
最重要的产品洞察,往往不在于功能请求本身,而在功能请求之后的那句话。在那个用户因为觉得工作流太奇怪而道歉但你注意到了的那个瞬间。在客户用自己做的那张 Excel 表里,因为产品根本不符合他们团队的实际工作方式。在用户说他们很喜欢某个功能,但你发现他们已经一周没登录了。
这类洞察,不是靠"做更好的三级研究"找到的。你需要离客户近到他们愿意把那些奇怪、具体、不方便的真相展示给你看。
这里有个有点讽刺的事情:AI 让"生成看起来有深度的市场分析"越来越容易,但这类分析的信息价值,也在同步下降。你的 AI 能生成,别人的 AI 也能生成。真正产生竞争优势的,是那些还没被任何 AI 索引过的信息——而那些信息,只存在于现实关系里。
06 PatientPing 的故事
:::PatientPing 是一家医疗 SaaS 公司,核心产品是帮助医疗机构之间协调患者护理。听起来很明确的 B2B 需求。但 Dhruv 说,真正重要的洞察从来不是坐在办公室里能想到的。
医院、ACO(责任制护理组织)、亚急性护理机构、支付方——他们可能都在关注同一个患者的流转,但对工作流的体验完全不一样。价值医疗的"公开故事"能告诉你一件事,而各机构实际推行价值医疗的方式,能告诉你完全不同的另一件事。
有时候洞察在于护理团队如何协作,有时候在于用户如何绕开产品,有时候在于管理层对流程的理论设想和一线用户的实际体验之间的巨大落差。
这些不是靠做二手研究能发现的。
07 firsthand 更明显
:::在 firsthand,这个问题变得更加突出。firsthand 是一家科技驱动的护理公司,软件需要嵌入人工护理模型里运转。很多最难的产品问题不是软件问题,而是服务范围问题:护理团队里不同角色各自认为哪些是"底层工作",哪些是"顶层工作"?同伴支持者、社工、执业护士之间应该如何协调?
还有一类信息,是"攻击性的本地化"。大语言模型能告诉你关于食品不安全、医疗补助、严重精神疾病的泛泛信息。但它不知道哪个教堂每周都可靠地分发食物。它不知道哪个本地组织真的接电话。它不知道哪个社区资源名单看起来很完整,但已经六个月没人更新了。
这类信息,只能靠人去找。
我读到这里的时候有点触动。因为这不是一个抽象的论点,而是 Dhruv 在两家具体的公司里,用真实的工作反复验证过的东西。那些最重要的产品决策,背后的原材料,是只有足够靠近才能发现的真相。
这让我想到另一件事:AI 时代的 PM 面临的最大陷阱,不是"不会用 AI",而是"用 AI 替代了那些本来应该亲自去做的观察"。拿着模型生成的用户画像去做产品决策,跟拿着二手报告去做产品决策,本质上没什么区别——你离那些最重要的信息,永远差了一层。
08 两种好 PM
:::Dhruv 区分了两种 AI 时代的好 PM。
第一种,是上面说的那种:靠近客户的信息不对称猎手。他们离经典的"授权产品团队"原型最近。他们理解客户、市场、商业模式,以及那些不明显的痛点。他们在买家和用户中建立信任。他们寻找信息不对称。他们找到那条改变 roadmap 的隐藏洞察。
第二种,是彻底加速迭代的 PM。表面上看起来更像"功能团队"里的人,但那个标签在今天已经没那么负面了。当执行变便宜、协调成本下降,瓶颈就转移到了"品位"。
有一点我觉得他说得很精准:历史上,"产品团队"和"功能团队"的区别,隐含着一种鄙视链。产品团队是"有自主权、对结果负责的那群人",功能团队是"照单执行的那群人"。AI 让这个区别变得更锐利,但也让两种模式都变得更有意思。
这类 PM 帮工程团队更快推进,同时不让产品变成一堆功能的堆砌。他们知道什么需要验证,什么版本够用来测试,哪个功能是标配,哪个功能真的创造喜悦。他们知道什么时候该发布,什么时候该做原型,什么时候该"假装",什么时候该停止。
09 品位是练出来的
:::大家谈到"产品品位"的时候,好像它是某种玄学天赋,有的人天生就有,没有的人怎么努力都难。面试里要用"重新设计电梯"或者"飞机里能装多少个高尔夫球"来测它。
Dhruv 的观点是:品位是真实的,但它是通过练习积累的。
品位是"能预判落点"的能力——能说"我认为客户会朝这个方向走;这是用户在能说清楚之前就会想要的东西;这个改动看起来小,但会产生影响;这个功能看起来显而易见,但会让产品更差"。
AI 改变了品位的形成方式,因为它改变了 PM 能积累多少次练习。
以前,一次认真的迭代可能要几周甚至几个月。循环很慢:和客户聊,综合反馈,写文档,和设计评审,和工程评审,向 stakeholder 同步,开发,上线,等待信号。因为循环慢,大家会非常执着于"第一次就要对"。
现在,PM 可以跑一个快得多的循环。拿到客户对话,聚类主题,生成多个产品方向,压力测试假设,做原型,比较用户反应,识别矛盾,带着更清晰的观点回到团队。PM 仍然要做最终判断,但在做判断之前,他们现在能产生多得多的信号。
他把这个叫做"Agent 编排的品位发现"。
我觉得这个描述抓住了一个容易被误解的点。很多人谈"AI 帮助 PM",想象的是 AI 帮你生成更漂亮的 PRD、更完整的需求文档、更快的 roadmap 草稿。Dhruv 说的不是这个。他说的是一个用 AI 来加速"自己的判断力积累"的系统——AI 负责处理信息,人负责形成判断。
这两件事,差距大了去了。前者只是让你生产更多文档,后者让你变成一个更有判断力的人。
当然,他没说这很容易。PM 仍然需要知道什么值得去学,Agent 处理哪些任务有帮助,哪些任务表面上节省时间、但实际上切断了你对产品感知的那个关键渠道。比如让模型总结所有客户访谈,听起来很高效——但你因此错过的那些细节里,可能就有下一个最重要的洞察。
目标不是把品位外包给模型。目标是建立一个帮助 PM 更快发现品位的系统。Agent 做那些枯燥但耗时的管理工作,但也可以承担更多创意使能工作:帮助维护客户记忆,把分散的反馈变成规律,把上个月客户说的话和这个月他们实际在做的事之间的矛盾浮现出来,生成 PM 自己不会单独产生的选项。PM 仍然要决定什么重要。
10 底牌翻出来了
:::这就是为什么 PM 再也藏不住在流程背后了。
状态更新、会议记录、反馈总结、roadmap 更新、发布清单、客户摘要、PRD 草稿——这些,正是 Agent 最擅长的事。底层任务正在被自动化,或者至少被大幅压缩。
它们不会消失。只是不再能证明你有多重要了。
剩下的问题就赤裸裸摆在那里了:你到底发掘了什么客户洞察?你学到了什么市场上没人知道的东西?你通过更快的迭代,到底积累了多少判断力?你帮团队跑得更快了,还是只是帮团队生产了更多文档?
| 底层工作(AI 正在接管) | 顶层工作(人的核心竞争力) |
|---|---|
| 整理用户访谈笔记 | 发现访谈里那句改变方向的话 |
| 写 PRD 和需求文档 | 判断应该做什么、不应该做什么 |
| 生成 roadmap 更新和状态同步 | 理解市场和商业模式的深层结构 |
| 综合公开市场研究 | 挖掘 AI 访问不到的私密本地信息 |
| 创建原型第一版 | 知道什么时候该停止、什么时候该发 |
11 对我们意味着什么
:::PM 的工作,核心没变:帮公司找到产品市场匹配。确保客户和用户得到了他们来这里希望得到的结果。确保公司从中创造的价值足以支撑一个可持续的业务。
这永远是那份工作。
每次大的平台转型,都改写过 PM 这份工作。互联网把它从硬件设计工作变成了我们今天认识的样子。移动和云再改了一遍。社交和电商让它变成了 A/B 实验。API 和 SaaS 又改了一遍。AI 会改得更快,但这个模式,其实不陌生。
有一件事我觉得挺有意思:Dhruv 这篇文章本身,就在示范他自己说的那件事。他没有给出什么"AI PM 转型路径图",而是在讲两家公司、两段具体的经历,那些他只有在现场才会发现的东西。这就是对他核心论点最直接的注脚——
AI 能告诉你产品经理的职责是什么。但它不知道 PatientPing 护理协调流程里哪个节点是断的。那需要一个人在场。
差 PM 用 AI 生产更多文档。好 PM 用 AI 产生更多学习。
我还没想清楚这对不对。整篇文章我最认同的那句话是"AI 找不到的东西,只存在于现实关系里"。但我同时也有一个没有答案的疑问:那些"够近才能看到的真相",是靠某种性格才能发现的,还是靠某种方法?
如果是性格,AI 根本不改变什么,这些人原本就会赢。如果是方法,我们需要的不只是"去靠近客户"这个建议,而是一整套关于如何靠近、靠近之后看什么、看完了怎么不把它变成又一份文档的具体训练。Dhruv 的文章给了我前者的信念,但没给我后者的路径。
但有一件事我觉得可以确定:那个"功能请求之后的那句话",不会自己跳出来找你。你得在场,得沉默,得忍住不去填满那个停顿。这件事,AI 教不了。

◇ ◆ ◇
• 原文:Dhruv Vasishtha, "Good AI PM / Bad AI PM"
• 来源:https://x.com/dvasishtha/status/2053944554273816612
夜雨聆风