← All Articles

精读 Dhruv Vasishtha《Good AI PM / Bad AI PM》——AI 时代 PM 角色重构 + 投资人 DD 视角

Dhruv Vasishtha X long post，2026-05-11 发布 · 2026-05-30 · Original

受众：Justin（红杉中国 MD） 来源：Dhruv Vasishtha X long post，2026-05-11 发布 作者背景：PatientPing（医疗护理协调 SaaS）+ firsthand（科技驱动的护理公司）前产品负责人，现在 25m Health 做新的医疗创业 配套：中文公众号转译评论（鼹鼠 5/30 浅读已发） 我的用途：把这套框架转成投资人评估 SaaS / 应用层公司 PM 团队的具体 DD 问题

一、原作者真正在说的事

Dhruv 这篇本质是借 Ben Horowitz 2004 年那篇《好 PM / 差 PM》经典框架（“好 PM 对结果负责，差 PM 对过程负责”），加一层 AI 时代的修正。Horowitz 原文的核心是 ownership——所有权 / 担责 / 对最终结果负责。这条放到今天仍然成立，但 AI 让它从一条”价值观区别”变成了”肉眼可见的能力区别”。

为什么？因为 PM 工作历史上有一层叫”协调成本”的缓冲——会议记录、客户访谈总结、PRD 初稿、roadmap 更新、状态同步、ticket 拆分、跨部门对齐、模糊需求翻译成”看起来合理的文档”。这些工作里有一部分有真实价值，但相当一部分是 Dhruv 直接定义的”professionalized layer of motion around the actual product work”——包裹在真正产品工作外面的职业化外壳。

AI 抹掉了这层外壳。客户访谈总结便宜了，PRD 便宜了，ticket 便宜了，roadmap 更新便宜了，发布说明便宜了，跨部门同步正在变便宜，连”功能第一个版本”都在变便宜。这覆盖了一个普通 PM 一周大部分时间。

Horowitz 框架下的”差 PM 藏在过程里”变成了”差 PM 藏在协调成本里”。AI 拿走协调成本之后，差 PM 没地方躲。剩下来要做的事是只有人类、且只有”靠近客户到一定程度的人”才能做的——这就是 Dhruv 全文的核心。

二、“信息不对称机器”框架——好 PM 找的到底是什么

Dhruv 给好 AI PM 起了一个具体定义：a customer-facing asymmetry machine——一台面向客户的信息不对称机器。这台机器的工作是挖出能改变公司应该建什么的隐藏信息。

公开信息已经被大模型大面积索引。原来靠”能综合公开研究”获得的优势正在消失——如果答案就在公开互联网上，模型能帮任何人得到一个还不错的版本。所以 PM 必须去找模型找不到的东西。

Dhruv 把这类信息分成四种：

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

这一层框架的真正威力在于：它把”客户调研”这种已经做烂了的活，重新定义成”挖隐藏信息”这种 AI 抢不走的活。Dhruv 没说要去找客户聊天——他说要去找那些 AI 索引不到的真相。这是把 PM 的核心能力从”做事”重新定义成”获取信息的稀缺性”。

三、PatientPing 和 firsthand 的真实场景——为什么这套框架不是空话

Dhruv 在两家公司都验证过这个框架，描述很具体。

PatientPing：医疗护理协调 SaaS

PatientPing 帮医疗机构之间协调患者护理。听起来很明确的 B2B SaaS。但 Dhruv 说真正重要的洞察从来不在办公室里。

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

具体例子（Dhruv 在文中举的）：

这些不是二手研究能发现的。要靠近到客户愿意把”奇怪、具体、不方便的真相”展示给你看。

firsthand：科技驱动的护理公司

firsthand 把这个问题推到极端——它是 tech-enabled care company（科技赋能的护理服务公司），软件要嵌入人工护理模型里运转。很多最难的产品问题不是软件问题，是”scope of work”——服务范围问题：

更极端的是 firsthand 里有一类信息叫”aggressively local”（攻击性的本地化）——大模型能告诉你食品不安全、医疗补助、严重精神疾病、社区资源的泛泛信息，但它不知道：

这类信息只能靠人去找。

这两段是全文最有信号价值的部分——它把”信息不对称”这个抽象框架，落到具体可观察的产品决策上。给投资人评估垂直 SaaS 标的提供了一个具体的检查角度：这家公司的核心产品洞察，是不是建立在 AI 索引不到的本地化、私密、非结构化信息上。

四、两种好 AI PM 的二分

Dhruv 区分两种好 PM，两种都比”AI 抹平之前的中等 PM”更值钱：

第一种：Customer-facing PM（客户面的信息不对称猎手）

最接近 Marty Cagan 经典的”empowered product team”原型。他们理解客户、市场、商业模式、不明显的痛点。他们在买家和用户中建立信任。他们寻找信息不对称。他们找到那条改变 roadmap 的隐藏洞察。

第二种：Iteration Accelerator（彻底加速迭代的 PM）

表面看起来更像”功能团队”里的人，但 Dhruv 明确说”that phrase is less dismissive than it used to be”——这个标签今天不那么贬义了。当执行变便宜、协调成本下降，瓶颈就转移到”taste”（产品品位）。

这类 PM 帮工程团队更快推进，同时不让产品变成一堆功能的堆砌。他们知道什么需要验证、什么版本够用来测试、哪个功能是标配、哪个功能真的创造喜悦。他们知道什么时候 ship、什么时候 prototype、什么时候 fake（假装做了某个功能看反应）、什么时候 stop。

这个二分有意思的地方：它打破了”empowered product team vs feature team”的传统鄙视链。在 AI 抹平协调成本之前，“feature team”PM 是被看低的——他们被认为是接需求的人，不是发现需求的人。AI 之后，“快速跑迭代 + 攒品位”本身变成了独立有价值的能力——只要你跑得够快、能区分什么值得 ship 什么不值得，“看起来像 feature team”也是好 PM。

五、“agent-orchestrated taste discovery”——这是全文最反共识的一点

大家谈”产品品位”的时候，常常把它说成某种玄学天赋——有的人天生有，没有的人怎么努力都难。面试里要用”重新设计电梯”或者”747 里能装多少个高尔夫球”来测它。

Dhruv 直接打破：Taste is real and it’s built through reps。品位是真实的，是通过 reps（练习次数）积累的。AI 改变了品位的形成方式，因为它改变了 PM 能积累多少次练习。

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

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

Dhruv 给这个起了名字：agent-orchestrated taste discovery（agent 编排的品位发现）。关键定义：

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

这段是这篇真正反共识的地方。大部分讨论”AI 帮 PM”的文章想象的是 AI 生成更漂亮的 PRD、更完整的需求文档、更快的 roadmap 草稿。Dhruv 说的不是这个——他说的是用 AI 加速 PM 自己判断力积累的系统。AI 处理信息，人形成判断。

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

六、回应一个被 X 上回复者也提出来的关键反问

X 上回复者 @adityapuranik99 提了一个最重要的问题：“taste 可以是 differentiator，但你怎么让那些 reps 真的 count，达到 customer-facing asymmetry？”

中文公众号转译者的疑问异曲同工：“那些’够近才能看到的真相’，是靠某种性格才能发现的，还是靠某种方法？如果是性格，AI 根本不改变什么，这些人原本就会赢。如果是方法，我们需要的不只是’去靠近客户’这个建议，而是一整套关于如何靠近、靠近之后看什么、看完了怎么不把它变成又一份文档的具体训练。Dhruv 的文章给了我前者的信念，但没给我后者的路径。”

Dhruv 文章本身没回答这个问题——他给了诊断和方向，没给方法论。但读他文章细节能拼出一个隐含的答案：方法 = 设计自己工作流的能力 + 主动暴露在客户现场的纪律 + 知道哪些事不能外包给模型的判断。

具体三件可观察的事：

  1. 在公司没有官方流程之前，自己搭小系统——Dhruv 原文：“They will build small systems around their own workflow before the company has an official process.” 好 PM 不等公司给工具，自己拼一套。这件事可观察。
  2. 超出”用 AI 写更好的 PRD”——开始问”AI 怎么改变整个产品开发循环”。这是从”工具用户”切换到”流程设计者”的转变。
  3. 知道什么不能交给 agent——比如”让模型总结所有客户访谈”听起来高效，但你因此错过的细节里可能就有最重要的洞察。中文转译者那句”AI 教不了的那个停顿——你得在场，得沉默，得忍住不去填满那个停顿”——这是方法层面最具体的一条。

这是隐含的方法论，但不是完整的——Dhruv 没把这套训练具象化。回复者和中文转译者的疑问都成立，这是这篇文章的 unfinished 部分。

七、给红杉中国 MD 的 due diligence 清单

把这套框架转成你评估 SaaS / 应用层公司 PM 团队的具体问题——能直接用在 portfolio 公司 PM 面谈或者新项目 DD：

评估 Customer Insight Hunter 类型（必问）

  1. “过去一个月你做了几次客户对话？这些对话里你听到的最让你 surprise 的事是什么？” ——观察的是有没有真去客户现场，以及有没有捕捉”surprise”的敏感度。如果回答的都是 PRD 里能写出来的需求，就是 process-bound PM。
  2. “你能讲一个’客户用自己 Excel 表绕开你产品’的具体例子吗？” ——这是 Dhruv 原文里举的 telltale sign。如果 PM 答不上来，要么他们的产品做得太好（不太可能），要么他们没近到能看到。
  3. “你的产品有哪些’aggressively local’信息是 AI 找不到的？” ——直接套 Dhruv 的术语。如果 PM 没听过这个概念但能答出具体例子，是真懂；如果只会复读”客户洞察很重要”，是装懂。
  4. “上一次因为客户对话改了 roadmap 是什么时候？改了什么？” ——观察客户信号是否真能反向影响产品决策，还是只是装饰性的访谈。

评估 Iteration Accelerator / Taste 类型（必问）

  1. “你一周能跑几次完整的’客户对话 → 聚类 → 原型 → 比较反应’循环？” ——Dhruv 说的”agent-orchestrated taste discovery”的可测量版本。一周一次以下基本是 process-bound；一周三次以上是真 AI-native。
  2. “你最近做了一个看起来显而易见但实际上会让产品更差的功能决定吗？” ——Dhruv 原文：“This is the feature that looks obvious but will make the product worse.” 这是 taste 的具体表现——能拒绝看起来合理但实际有害的功能。
  3. “你最近什么时候决定 stop 一个正在做的功能？” ——好 PM 知道什么时候停。
  4. “你自己在 AI 工具栈里搭了什么自己的小系统？” ——Dhruv：“They will build small systems around their own workflow before the company has an official process.” 没自己搭的 = 在等公司发，不是 AI-native。

评估”知道什么不能外包给 AI”（最反共识也最值钱）

  1. “哪类客户对话你坚持不让 AI 转写？为什么？” ——好 PM 知道有些访谈细节是 AI 转写后会丢的（语气 / 停顿 / 矛盾），坚持自己听。
  2. “AI 帮你生成的客户洞察 summary，你怎么知道它漏了什么？” ——观察 PM 对 AI 输出的批判能力。如果回答”AI 没漏”，是危险信号。

Red flag（直接淘汰信号）

八、跟你已经吃过的内容串起来

这篇能直接挂到你已经读过的几条线上：

拾象 Era of Agent——里讲过的 vertical agent “不可能三角”（行业知识 / 客户关系 / 数据飞轮），Dhruv 这套是 PM 视角的”如何攒行业知识 + 建客户关系”的执行细节。两者是同一件事的不同层面。

Anthropic Founder’s Playbook——里那条”领域知识 → 专有 AI 上下文 → 护城河”。PM 是把领域知识转成专有上下文的关键岗位，Dhruv 给的是这个岗位的能力模型。

Garry Tan 复杂度棘轮——里说”testable + harnessable = 可持续质量地板”。Dhruv 说的”reps + taste”是另一种棘轮——好 PM 的判断力是只升不降的、靠 reps 累积的。两者都在讲”积累式优势在 AI 时代变得更值钱”。

a16z Seema Amble “Is Software Losing Its Head?”——里那张 6 维护城河评分卡。Dhruv 这篇是”哪种 PM 能挖出来这 6 个维度真正有差异化的信号”的执行版。评分卡告诉你看什么，Dhruv 告诉你谁能看到。

OpenAI / Anthropic 部署公司 PE 合资（今天另一篇浅读）——labs 自己下场做”前置部署工程师”业务，本质就是 labs 自己在解决 Dhruv 说的”customer-facing asymmetry”——他们没法做到大模型对客户场景的近距离接触，所以并购咨询公司 + 拉 PE 来补。Dhruv 这套 PM 框架，labs 也在用，只是他们用的是公司层面的解决方案（并购 + 合资）。

九、最值得记的几条原文措辞（少而精）

十、一句话总判

这篇值得读不是因为它颠覆了什么——它没有颠覆任何 Horowitz / Cagan / Lenny 框架。它的价值是把”AI 时代 PM 是什么”从抽象焦虑（“我会不会被替代”）转成了具体能力定义和可观察行为。

对你最直接的用处：这是一份 portfolio 公司 PM 面谈的标尺，比单纯问”你怎么用 AI”更有信号。

最大的开放问题是 Dhruv 自己没回答的——“信息不对称能力”到底是性格还是方法？如果是性格，这套框架只能帮你识别已经有这能力的人，不能帮你培养；如果是方法，需要一套训练体系（如何靠近客户、看什么、记什么、不变成又一份文档）。这是这篇文章未完成的部分，也是你 portfolio 公司 PM 培训如果要做，需要自己搭的部分。

主要来源

配套精读 / 浅读（你已读过）