AI重塑产品管理：真正的洞察来自人情世故

最近重温 Ben Horowitz 的经典文章《好 PM / 差 PM》。这篇写于 2004 年的作品，已成为产品经理领域的必读文献。我通常每两三年重读一次，每次都有新的体会。

这次读完，我停顿了片刻。

并非因为文章内容过时，恰恰相反——许多观点在 AI 时代显得更加扎眼。Horowitz 强调的核心差异是：优秀的产品经理对结果负责，而平庸的产品经理对过程负责（或者说，对"看起来很忙"负责）。这一区别在今天依然适用，但其内涵已经发生了变化。

AI 将这条分界线变得清晰可见。

过去，许多产品经理的日常任务包括：整理客户访谈录音、撰写 PRD、拆分任务、更新路线图、发布通知、同步利益相关者、将模糊需求转化为看似合理的文档。这些工作有些有价值，但相当一部分只是为了维持一层称为"协调成本"的东西。

这层东西是真实存在的。它需要时间投入，也能让人显得很忙碌。

AI 正在压缩这一层。

客户访谈总结，变得廉价。PRD 初稿，变得廉价。任务拆分，变得廉价。路线图更新，变得廉价。发布说明，变得廉价。跨部门沟通，正在变得廉价。甚至产品的第一个版本，也开始变得廉价。

你数一下，这几乎涵盖了一个普通 PM 一周工作的大部分时间。

曾经，平庸的 PM 可以隐藏在协调成本中。他们看起来很忙，因为他们确实很忙——参加各种会议、维护追踪表、整合反馈、推动对齐、将模糊需求转化为看似合理的文档。其中一部分工作是有意义的，但相当一部分，只是一种职业化的外壳，包裹着真正重要的产品工作。

AI 正在剥离这层外壳。

这并不意味着 PM 不再重要。恰恰相反——它意味着优秀 PM 与平庸 PM 的区别变得一目了然。

文章作者 Dhruv Vasishtha 曾担任 PatientPing 和 firsthand 的产品负责人，目前正从事医疗领域的新项目。他表示，今年与他接触的每位 CPO 都提到了同一件事：许多 PM 首先感受到的是压力，而非机会。

如果你不成为 AI 原生型，你会落后。如果你成为 AI 原生型，你只是跟上了大家的步伐，但承担了更多工作。

我理解这种感受。但我认为他提出的框架比大多数人意识到的更重要。

这不仅仅是 PM 的问题。这一逻辑对任何知识工作者都适用：AI 压缩的是那些可编码、可重复、仅需信息综合就能完成的工作。剩下的，是判断力、人际关系、现场感，以及只有在具体情境中才能理解的内容。这些，从来无法被自动化。

他的核心论点如下：

优秀 PM 会成为一台面向客户的信息不对称机器。他们的工作是挖掘那些会改变公司战略的隐藏信息。

公开信息已被大语言模型大规模索引。原来靠"能综合公开研究"获得的优势正在消失。如果答案就在公开互联网上，模型大概能帮任何人得到一个还不错的版本。

因此 PM 必须寻找模型无法找到的东西。

那是什么？

他列出了四类：私密的、非结构化的、本地的，或客户自己都说不清楚的信息。

买家只有在信任你之后才会说的那句话。用户因为觉得太奇怪而不好意思承认的那个变通方法。公司"官方流程"和"周五下午四点半实际运作方式"之间的落差。

这些，模型都不知道。

最重要的产品洞察，往往不在于功能请求本身，而在于功能请求之后的那句话。在用户因为觉得工作流太奇怪而道歉但你注意到了的那个瞬间。在客户用自己做的那张 Excel 表里，因为产品根本不符合他们团队的实际工作方式。在用户说他们很喜欢某个功能，但你发现他们已经一周没登录了。

这类洞察，不是靠"做更好的三级研究"找到的。你需要离客户足够近，让他们愿意把那些奇怪、具体、不方便的真相展示给你看。

这里有个有点讽刺的事情：AI 让"生成看起来有深度的市场分析"越来越容易，但这类分析的信息价值，也在同步下降。你的 AI 能生成，别人的 AI 也能生成。真正产生竞争优势的，是那些还没被任何 AI 索引过的信息——而那些信息，只存在于现实关系里。

PatientPing 是一家医疗 SaaS 公司，核心产品是帮助医疗机构之间协调患者护理。听起来很明确的 B2B 需求。但 Dhruv 说，真正重要的洞察从来不是坐在办公室里能想到的。

医院、ACO（责任制护理组织）、亚急性护理机构、支付方——他们可能都在关注同一个患者的流转，但对工作流的体验完全不一样。价值医疗的"公开故事"能告诉你一件事，而各机构实际推行价值医疗的方式，能告诉你完全不同的另一件事。

有时候洞察在于护理团队如何协作，有时候在于用户如何绕开产品，有时候在于管理层对流程的理论设想和一线用户的实际体验之间的巨大落差。

这些不是靠做二手研究能发现的。

在 firsthand，这个问题变得更加突出。firsthand 是一家科技驱动的护理公司，软件需要嵌入人工护理模型里运转。许多最难的产品问题不是软件问题，而是服务范围问题：护理团队里不同角色各自认为哪些是"底层工作"，哪些是"顶层工作"？同伴支持者、社工、执业护士之间应该如何协调？

还有一类信息，是"攻击性的本地化"。大语言模型能告诉你关于食品不安全、医疗补助、严重精神疾病的泛泛信息。但它不知道哪个教堂每周都可靠地分发食物。它不知道哪个本地组织真的接电话。它不知道哪个社区资源名单看起来很完整，但已经六个月没人更新了。

这类信息，只能靠人去找。

我读到这里的时候有点触动。因为这不是一个抽象的论点，而是 Dhruv 在两家具体的公司里，用真实的工作反复验证过的东西。那些最重要的产品决策，背后的原材料，是只有足够靠近才能发现的真相。

这让我想到另一件事：AI 时代的 PM 面临的最大陷阱，不是"不会用 AI"，而是"用 AI 替代了那些本来应该亲自去做的观察"。拿着模型生成的用户画像去做产品决策，跟拿着二手报告去做产品决策，本质上没什么区别——你离那些最重要的信息，永远差了一层。

Dhruv 区分了两种 AI 时代的好 PM。

第一种，是上面说的那种：靠近客户的信息不对称猎手。他们离经典的"授权产品团队"原型最近。他们理解客户、市场、商业模式，以及那些不明显的痛点。他们在买家和用户中建立信任。他们寻找信息不对称。他们找到那条改变 roadmap 的隐藏洞察。

第二种，是彻底加速迭代的 PM。表面上看起来更像"功能团队"里的人，但那个标签在今天已经没那么负面了。当执行变便宜、协调成本下降，瓶颈就转移到了"品位"。

有一点我觉得他说得很精准：历史上，"产品团队"和"功能团队"的区别，隐含着一种鄙视链。产品团队是"有自主权、对结果负责的那群人"，功能团队是"照单执行的那群人"。AI 让这个区别变得更锐利，但也让两种模式都变得更有意思。

这类 PM 帮工程团队更快推进，同时不让产品变成一堆功能的堆砌。他们知道什么需要验证，什么版本够用来测试，哪个功能是标配，哪个功能真的创造喜悦。他们知道什么时候该发布，什么时候该做原型，什么时候该"假装"，什么时候该停止。

大家谈到"产品品位"的时候，好像它是某种玄学天赋，有的人天生就有，没有的人怎么努力都难。面试里要用"重新设计电梯"或者"飞机里能装多少个高尔夫球"来测它。

Dhruv 的观点是：品位是真实的，但它是通过练习积累的。

品位是"能预判落点"的能力——能说"我认为客户会朝这个方向走；这是用户在能说清楚之前就会想要的东西；这个改动看起来小，但会产生影响；这个功能看起来显而易见，但会让产品更差"。

AI 改变了品位的形成方式，因为它改变了 PM 能积累多少次练习。

以前，一次认真的迭代可能要几周甚至几个月。循环很慢：和客户聊，综合反馈，写文档，和设计评审，和工程评审，向 stakeholder 同步，开发，上线，等待信号。因为循环慢，大家会非常执着于"第一次就要对"。

现在，PM 可以跑一个快得多的循环。拿到客户对话，聚类主题，生成多个产品方向，压力测试假设，做原型，比较用户反应，识别矛盾，带着更清晰的观点回到团队。PM 仍然要做最终判断，但在做判断之前，他们现在能产生多得多的信号。

他把这个叫做"Agent 编排的品位发现"。

我觉得这个描述抓住了一个容易被误解的点。很多人谈"AI 帮助 PM"，想象的是 AI 帮你生成更漂亮的 PRD、更完整的需求文档、更快的 roadmap 草稿。Dhruv 说的不是这个。他说的是一个用 AI 来加速"自己的判断力积累"的系统——AI 负责处理信息，人负责形成判断。

这两件事，差距大了去了。前者只是让你生产更多文档，后者让你变成一个更有判断力的人。

当然，他没说这很容易。PM 仍然需要知道什么值得去学，Agent 处理哪些任务有帮助，哪些任务表面上节省时间、但实际上切断了你对产品感知的那个关键渠道。比如让模型总结所有客户访谈，听起来很高效——但你因此错过的那些细节里，可能就有下一个最重要的洞察。

目标不是把品位外包给模型。目标是建立一个帮助 PM 更快发现品位的系统。Agent 做那些枯燥但耗时的管理工作，但也可以承担更多创意使能工作：帮助维护客户记忆，把分散的反馈变成规律，把上个月客户说的话和这个月他们实际在做的事之间的矛盾浮现出来，生成 PM 自己不会单独产生的选项。PM 仍然要决定什么重要。

这就是为什么 PM 再也藏不住在流程背后了。

状态更新、会议记录、反馈总结、roadmap 更新、发布清单、客户摘要、PRD 草稿——这些，正是 Agent 最擅长的事。底层任务正在被自动化，或者至少被大幅压缩。

它们不会消失。只是不再能证明你有多重要了。

剩下的问题就赤裸裸摆在那里了：你到底发掘了什么客户洞察？你学到了什么市场上没人知道的东西？你通过更快的迭代，到底积累了多少判断力？你帮团队跑得更快了，还是只是帮团队生产了更多文档？

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"

•