31,832 人申请只录用 1 个：Whatnot 为什么不想「为了招产品经理而招产品经理」
Whatnot CPO Tom Verrilli 解释为何不把 PM 固定配给每个团队，以及 AI 时代产品岗位真正稀缺的判断、取舍与一线工作。
单集信息
| 项目 | 信息 |
|---|---|
| 播客 | 跨国串门儿计划（AI 翻译单集） |
| 中文节目引介 | 一凯；原始访谈主持人为 Lenny，来自 Lenny's Podcast |
| 嘉宾 | Tom Verrilli，Whatnot 首席产品官；曾任 Twitch 首席产品官、Twitter 产品增长总监 |
| 集标题 | #660.Twitter 前产品增长总监：不要为了招产品经理而招产品经理 |
| 发布日期 | 2026 年 8 月 3 日 07:00（北京时间） |
| 原集 | 小宇宙单集页；原始英文访谈页 |
小宇宙页面说明，本集是对 Lenny's Podcast 原访谈的 AI 翻译和声纹克隆版本。以下判断基于完整中文音频转录；引语均为中文转译，不把它们当作 Tom 的英文原话。时间段按本集音频计。
Tom Verrilli 不是在说「产品经理没用」。他的主张更窄，也更难执行：不要把 PM 固定配给每个团队，而要把 PM 放到真正需要产品判断的问题上。AI 让查数据、读代码、做原型的成本下降之后，产品岗位最值钱的部分，反而越来越不像开会和推动对齐，而像是理解真实用户、做取舍、把问题推进到可以验证的状态。
1. 「后悔产品管理的存在」是一条招聘约束
Whatnot 产品团队的口号是「我们为产品管理的存在而感到遗憾」。Tom 解释，这句话不是反对 PM，而是逼团队记住：只有出现明确需求时才招，不能默认每个地方都需要一个 PM。产品管理之所以值得成为专职职能，唯一有力的理由是它是一门靠反复实践练出来的手艺，不是一张资格证。（原集 04:19—06:54）
他把行业里常见的配比说得很直白：每 6 个工程师配 1 个设计师、1 个 PM、1 个工程经理。规模变大后，这个配比会自动制造出一堆岗位；但基础设施团队可能根本不需要 PM，工程师和设计师本来就能做决定，长期有人替他们盯着，反而让他们失去练习判断的机会。Whatnot 的做法是把 PM 绑在问题或核心项目上，而不是绑在某个工程团队上；甚至可能有一整年没有固定 PM，产品工作仍在推进。（原集 07:43—10:56）
这也保留了 PM 的必要性：优秀的产品管理能传递清晰度、吸收模糊性、帮助团队及时决策。争论的对象不是这个能力，而是把它变成每个团队的默认配置。
2. 31,832 份申请，只录用 1 人
Tom 说，过去两年 Whatnot 收到 31,832 份 PM 申请，最后只招了 1 人。这个数字在节目里不是招聘战绩，而是对岗位泛滥的反问：简历和头衔的数量，不等于真正做过产品。（原集 01:50—02:32、16:54—18:03）
Whatnot 当时约有 21—22 名 PM，按买家、卖家、信任与风控三个大组松散归属；每 6 个月，CEO、CPO 和资深负责人重新列出必须完成的结果，再给每个关键项目找直接负责人。一个项目不一定配 PM，谁最适合解决问题，谁就可能被放上去。PM 也会在组内流动，而不是守着一张固定路线图。（原集 15:10—16:48）
因此，面试里最不加分的，是反复讲利益相关者管理、对齐会议和「推动共识」。Tom 认为这很容易退化成搞政治。更好的候选人要同时展示宏观和微观：能解释系统怎样运作，也能说清楚自己要验证什么、如何把判断落地；案例题里，漂亮的表达如果经不起数据和细节追问，很快就会露馅。（原集 17:21—19:48、44:51—45:45）
3. 把资深 PM 拉回一线，不等于让他去写生产代码
Tom 所说的个人贡献者，不是要求每个 CPO 变成全职工程师，而是重新亲自做那些能改变结果的工作：看客户问题，拉数据，理解代码库，和工程师、设计师一起把方案做出来，并对关键取舍负责。他所在团队有四五名管理 PM 的管理者，他们把 90% 以上时间花在个人贡献者工作上；Tom 自己大约还有 50% 的时间在做同类工作。（原集 21:34—24:24）
这样做的收益不是省掉几个岗位，而是减少层层转译。Tom 举过 Twitch 的例子：他把广告和推荐交给同一个 PM 负责，让一个人同时看到自然流量和付费流量的权衡，省掉了几个月的拉扯。在 Whatnot，他用足够的产品经验和 AI 工具快速判断一个改动的工作量，曾经能省掉启动会、对齐会、一周 PRD 和一轮实验周期。（原集 23:30—24:24、30:04—30:56）
代价也很清楚：这种组织需要愿意下沉的领导者，也需要允许专业分化。不是每个工程师都想做产品工作，也不是每个 PM 都适合长期管理人。Tom 的判断是，未来会出现更多小团队和「轻量工程负责人」，但具体组织形态未必彻底改写。
4. AI 把「理解系统」从稀缺服务变成 PM 的基本功
AI 对产品工作的最大改变，不只是快速做原型。Tom 说，过去想拉一个细分用户群的数据，可能要找数据科学家做一两周；现在可以在内部工具 HACKS 里直接查日志，问某个用户做了什么、看到了什么、还有多少人处在同样情境，再快速搭出敏感性或预测模型。结果是，他过去一年和数据科学家沟通的时间比职业生涯任何阶段都少，但花在真正理解数据上的时间约多了 10 倍。（原集 12:34—14:17、33:44—35:34）
这不是把责任交给模型。Tom 明确说，AI 工具能帮你查数据、读代码，却不能替你确认分析和代码是否可靠。产品经理因此少了一层「等专家翻译」的缓冲，必须自己知道数据怎样标注、代码怎样运行、一个指标为什么会变。没有判断力的人，得到的只是更快的错误答案。
5. 「拉手风琴」：先想远，再把 V1 推出来
Tom 用手风琴描述产品节奏：先把问题完全拉开，想清楚要做成什么；再把它推回去，做到 V1，让真实反馈进入下一轮。只拉开不发布，是两三年的战略文档；只推不拉开，则是不断迭代却不知道方向。两边都要做，价值发生在推回去之后。（原集 57:28—59:59）
他用商品条目解释这个取舍：卖家创建一个商品条目大约需要 3 分半钟，短期看能让新买家搜索到商品，长期却可能降低卖家每小时能卖出的数量。只看「搜索需要商品条目」，会错过「条目成本会伤害供给」这条连锁反应。产品判断不是选一个局部指标，而是来回推演：这次修复会改变谁的行为，下一步又会伤到谁。（原集 01:00:32—01:02:18）
6. 平均值会遮住真正重要的用户
Tom 把职业生涯里最深的一次教训归结为一句话：「平均值对个体来说毫无意义。」如果一个功能只有 3% 的用户使用，团队很容易决定下线；但那 3% 可能正是某群人的 100% 核心场景。对电商平台而言，误删一个功能不只是少一个指标，还可能切断一个商家的生意。（原集 01:08:42—01:10:34）
这句话和整期节目的关系很紧：当 PM 不再靠「平均每个团队配一个」来证明存在价值，产品判断也不能靠「平均用户」来证明决策正确。真正需要保留的 PM，不是最会把流程说漂亮的人，而是能往下追问：谁在用、为什么用、删掉之后谁会先受伤。
收听判断
- 想判断 PM 是否正在被重新定义：听 01:18—10:56、15:10—19:48。这里有「6 个工程师配 1 个 PM」、31,832 份申请只录用 1 人，以及 Whatnot 如何按问题分配 PM 的完整逻辑。
- 正在做产品、工程或数据工作：听 12:34—14:17、21:34—35:34。重点不是「AI 能不能写代码」，而是它如何让一线人员直接理解用户、数据和代码，并承担更多判断。
- 负责团队规划或资源取舍：听 49:21—59:59、01:00:32—01:02:18。创始人与 CPO 如何避免重复劳动，以及「拉手风琴」如何把长期方向和短期 V1 接起来。
- 想听一段不太像成功学的产品复盘：听 01:08:42—01:10:34。平均值、3% 用户和个体场景之间的冲突，是整集最适合带回工作现场的一条提醒。
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.