This CPO regrets that product management exists | Tom Verrilli (CPO of Whatnot)

Whatnot CPO Tom Verilli：过去两年 31,832 人申请 PM 岗位，只招了 1 个。他的理念是“我们后悔产品管理存在”，让工程师和设计师自己拿主意。

PM越多，团队越不会做决策

Tom Verrilli 是 Whatnot 的 CPO，曾任 Twitch CPO、Twitter 产品增长总监。Whatnot 是直播购物平台，被节目称为美国历史上增长最快的 marketplace business。一个做过 Twitter、Twitch、如今又在直播电商一线的人，说产品团队的前提是“后悔产品管理存在”，听上去像在砸自己的饭碗。但他真正反对的不是 PM，而是把 PM 当成团队标配、把决策外包给一个职能的习惯。AI 让这件事更尖锐：当查数据、读代码、做原型都变快，谁还真正理解客户、系统和生意，谁就更有资格做判断。

这期回答了 8 个问题：

1. 为什么一位资深 CPO 会说“后悔产品管理存在”？
2. 什么情况下该配 PM，什么情况下反而不该配？
3. 3.18 万人申请却只录用 1 人，Whatnot 在筛掉什么样的 PM？
4. AI 没有取代 PM，却具体改变了 PM 的哪些工作杠杆？
5. 为什么最优秀的 PM 不该靠晋升离开一线？
6. “自上而下”怎样才不是令人反感的微观管理？
7. 产品团队该如何在长期路线图与快速实验之间来回切换？
8. 为什么一个只有 3% 人使用的功能，仍可能绝不能删？

被问到 Why Whatnot 会以“后悔产品管理存在”为团队前提时，Tom 先回溯了一条很多公司都走过的扩张路径：团队长大后，渐渐形成一套 pod 配比——每新招 6 名工程师，就配设计师、PM 和工程经理。久而久之，组织图像生产线，每个格子都要补齐人头。可他举了一个很朴素的反例：通知基础设施通常并不需要 PM。工程师完全能理解这类系统该如何演进，未必需要一个人替他访谈用户、写文档、组织决策。

Tom 将产品管理视作一种靠反复练出来的 trade，即手艺，而不是拿到头衔就天然拥有的资格。"the more you abstract your engineers and your designers from doing the same thing, their muscle gets underdeveloped."（你越是让工程师和设计师脱离同样的决策工作，他们的这块肌肉就越得不到发展。） PM 如果替工程、设计吸收所有模糊性，也替他们拍板优先级，短期看像是省事，长期却像总有人替你健身：肌肉没练出来，下一次没有 PM 在场，团队就不会判断。

这意味着，产品组织的默认问题不该是“这个团队缺几个 PM”，而该是“这件事究竟需不需要专职决策者”。当然，这不是让基础设施负责人必须去跑客户访谈。有人最擅长规模、架构和可靠性，也明确不想陷入协调细节；专业分工依然成立。Tom 反对的，是把“每个团队都必须有 PM”误当成分工本身。

被问到 Whatnot 的 PM、设计和工程组织如何运作时，Tom 给出的数字很克制：公司当时只有约 21 到 22 位 PM，粗分为买家、卖家、信任与风险三组。对一个要处理直播、交易、支付、风控和履约的平台来说，这不是按每支工程队伍常驻一个 PM 的配置。它的核心动作发生在每 6 个月一次的规划：CEO、CPO、核心负责人和 senior leads 先定义未来半年必须实现的结果与关键项目，再逐项确定 DRI，也就是直接负责结果的人。

规划做完，才开始配人。若有一件横跨多个团队、各团队都排在第二或第三优先级、却又不能没人管的事，Whatnot 不会让它自然消失，而是直接抽调一位 PM：接下来半年，这就是你的问题。Tom 说，有工程团队即使一直有产品工作，也可能一年多没有挂靠 PM。"you don't hire a PM just for the sake of hiring one, you hire one with this really specific need."（你不是为了招一个 PM 而招 PM；你是因为有一个非常具体的需要，才去招他。）

这意味着 PM 的位置不再绑定汇报线，而是绑定公司级难题。固定驻场的 PM 很容易变成流程接口：收需求、排会议、催进度。流动的 PM 则要对一个结果负责，尤其适合那些需要跨团队取舍、尚未被某个职能自然认领的问题。边界也很清楚：任何人都可以担任新产品开发的 DRI，但都得走 product review，完成同样的产品工作。去 PM 化，不等于没人承担决策责任。

被问到过去两年有 31,832 人申请 Whatnot PM、最终却只录用 1 人时，Tom 先说了一个正在“降分”的信号：候选人在面试中大量谈推动对齐、利益相关者管理、维系关系。这些能力并非无用，但当它们压过客户、技术和构建经历时，往往说明候选人把会议运转当成了产品能力。Tom 对这类 PM 的描述很尖锐："whose specialty wasn't technical or customer-oriented, it was politics."（他们的专长既不是技术，也不是面向客户，而是政治。）

Whatnot 的筛法不是只听故事。所有岗位都要做实际 case study；PM 会拿到题目和数据，写出 PRD，再当面答辩。这个过程会迅速分开两种人：一种人能把过往项目讲得很漂亮；另一种人能在信息不全时解释，自己会如何判断、先验证什么、如果结果为正或为负下一步分别怎么改。Tom 要的是后一种人：既能描述终局，说明系统最终应如何运作；又有微观推进力，急着把假设压缩成可验证的行动。

这意味着 PM 招聘的尺度正从“能否让很多人同意”转向“能否把客户、业务与技术之间的冲突，变成一个有证据的具体选择”。大公司履历、头衔和表达都不能替代真实构建经历。协作当然仍必要，但协作的目的应是让正确决策落地，而不是让所有人都参加过会议。

被问到“play the accordion，也就是拉手风琴”是什么意思时，Tom 用产品过程解释了这个动作：先把风琴拉开，重新理解要解决什么；再压回去，做出 V1；拿到结果后，再拉开，调整模型，再推进下一版。"you've got to constantly be zooming out and pushing back in, zooming out and and pushing back in."（你必须不断拉远再推进、拉远再推进。） 拉开本身不创造价值，真正的价值来自压回去、把东西做出来；但如果不反复拉开，团队会不知道自己正在制造什么副作用。

Whatnot 的 listings 很能说明问题。直播卖家举起一副 AirPods，口头描述、直接开拍卖，理论上无需先建商品页。这让卖家少花时间：每个 listing 大约要 3 分半钟，不做就能多卖货。但新用户会期待搜索。如果平台事前不知道某位卖家要卖 AirPods，它就无法把想买 AirPods 的用户导向正确直播间。解决方案似乎很直接：强制创建 listing。可一旦这么做，卖家每小时能卖的商品数又会显著下降。

这意味着，局部实验的“绿灯”并不等于系统正确。团队既不能只写两三年路线图，把互联网最便宜的学习能力浪费掉；也不能只顾做 A/B 测试，像“往墙上扔意大利面”，碰到哪里算哪里。每轮实验之后，都要重写一个问题：它改变了谁的行为，又让别的环节失去了什么。

被问到除原型制作外，AI 怎样提升产品团队生产力时，Tom 的第一答案不是写 PRD，而是数据。Whatnot 用 Hex Threads，让 PM 自己拉取细颗粒度用户 cohort，也就是按相似行为或属性分组的人群；也能查日志、做敏感性模型、预测和回归分析。他说，过去一年里自己和数据科学家直接沟通的时间，是职业生涯中最少的；但自己花在数据、花在理解产品如何运作的时间，可能多了 10 倍。

第二个变化是读代码。过去 PM 想知道一项需求的工作量、两个系统如何关联，往往要打断工程师。现在 Tom 会直接问 Claude：代码库怎样运作？某条逻辑什么时候触发？直播产品尤其能放大这种能力：团队一边看用户实际使用，一边让 AI 分析代码库，判断用户眼前的问题究竟是实时 bug，还是用户理解偏差。"you can spot regressions and weird knock-on effects of two products intermixing more quickly than you used to be able to."（你能比过去更快发现回归问题，以及两个产品相互作用产生的奇怪连锁影响。）

这意味着 AI 压缩的首先不是思考，而是等待。取数、理解系统、排查异常，不必在多个职能之间层层排队。判断力强的 IC 能更快完成“看到问题—拿到证据—作出决定”的闭环。但 AI 找到的数据未必分析正确，AI 写出的代码也未必可靠；懂数据结构和系统边界的人，仍要对结论负责。

被问到为何特别看好 PM 回归 IC 工作时，Tom 指出传统晋升路径里的怪现象：最成功的 PM 被升成 director，随后被要求少做具体事情，多花时间指导、审核和对齐。组织以为这是奖励，实际却像把最强前锋换到场边当教练。Whatnot 的产品团队约有 4 到 5 位 PM 管理者，但每个人仍把 90% 以上时间投入 IC 工作；Tom 自己也约有 50% 时间在做 IC 工作，包括看支持工单、拉数据、理解代码、写规格和与工程设计一起推进交付。

他在 Twitch 的经历说明了这样做为什么更高效。当时 discovery 团队与广告团队长期争夺 feed 曝光：广告多一点，收入可能增加；推荐内容多一点，发现体验可能更好。两个团队各自为指标辩护，来回拉扯很久。Tom 到 Whatnot 后的做法是，让同一位 PM 同时对两者负责，并以 feed 产生的 GMV，即成交总额，作为共同目标。原本是部门政治的问题，变成了一次明确的业务取舍。

这意味着，资深人才的价值不只在审批他人的方案，还在于同时看见多个彼此冲突的上下文。一个经验足够深的 VP，理论上能覆盖多位初级 PM 的工作吞吐量，也更容易提前看到联动关系。当然，足够庞大的组织仍可能需要纯管理岗位；这套模式更适合那些厌倦无尽会议、仍愿意回到客户和交付现场的资深产品人。

被问到为何不认同“招到好人就别管”的管理信条时，Tom 讲了 Whatnot 增长会议中的一个追问链：有人说，某个异常数据是欺诈造成的。接下来不会直接接受这个字段，而是继续问：谁把它标成欺诈？按什么 SOP，也就是标准操作流程？用了哪些规则？如果答案只是“数据集就是这么写的”，那实际上没人知道这是不是欺诈，只是知道系统有一个叫“fraud”的标签。

这类追问会迫使一位有经验的负责人走到系统底层：查标签如何生成，查运营人员如何操作，查数据是否只是把模糊判断伪装成确定事实。Tom 还观察到，Whatnot 创始人兼 CEO Grant 在评审里发现问题后，会直接清空当天日程，和团队一起打开工单、代码和数据，一行行弄清楚。他将自己的工作方式称为 T 型：大部分时间横向理解全局，必要时能往某个系统扎得很深。"Top-down works well if leadership is good enough to be in the weeds and be specifically correct."（只要领导层足够深入细节、并且能具体地判断对错，自上而下就能运作得很好。）

这意味着，好的自上而下不是高层更快地下命令，而是高层能否和一线站在同一份事实之上。领导不了解 ground truth，也就是真实现场，却从上方干预，才会变成人人讨厌的微观管理。反过来，领导愿意自己验证细节，很多中间层的“对齐成本”会直接消失。

被问到未来两年典型产品团队会长什么样时，Tom 没有拿出一张“AI 时代组织图”。他的回答先是承认不确定："Great question, and I don't know that I know what it looks like everywhere."（这是个好问题，但我不认为自己知道它在所有地方会是什么样子。） 这不是客套。因为 Whatnot 的模式建立在直播电商、创始人深度参与、快速交付的文化上，不能直接套给每一家企业。

他对 Whatnot 的预期是，设计、工程、产品等专业角色组成的正式团队仍会存在，但主要服务于目标明确、信心较高、推进路径已知的项目。比如团队已经确认某项支付能力必须建设，也大致知道怎样建设，那么稳定协作的编制依然有效。变化会出现在这些正式项目的边缘：只要一个人理解客户问题、代码库和宏观业务背景，他就应该能自主改善某件事，不论他是设计师、工程师、PM 还是数据科学家。

Tom 的例子很具体：一个人在周五下午写不动 PRD，但确信自己能修好一个有意义的问题，应该直接去修。这里的重点不是鼓励随意插单，而是区分确定性。确定性高的项目需要固定协作和清晰分工；不确定、成本低、值得试探的问题，应给有上下文的人留出行动空间。组织设计的重点不再是复制标准答案，而是划清这两类工作的边界。

在 fail corner 被问到最深刻的失败教训时，Tom 说 Whatnot 内部关于如何构建产品的文件，开头就写着“batting 500”：正确和错误大致各半，已经是合理目标。他最警惕的一种错误，是看见某功能只有 3% 用户使用，就顺理成章地决定下线。3% 从总量视角看很小，维护还要成本，删掉似乎是干净利落的产品决策。

但这个 3% 里面，可能有一群人把它当作 100% 的核心用例。功能一删，他们不是“体验稍差一点”，而是整个使用方式被摧毁。放在电商里，后果尤其具体：这可能是卖家赖以经营的一项能力。Tom 把这种无预警的下线，比作购物中心在圣诞节前突然断电。商场整体也许还有别的店在营业，但对正在旺季做生意的商户，损失不是平均数能抹平的。"averages mean nothing to the individual."（平均数对个体毫无意义。）

这意味着，规模越大的产品越不能只看聚合指标。团队要追问：低使用率人群是谁？他们是不是高依赖用户？替代路径是否存在？不维护低频功能当然有成本，也不是每个功能都该永久保留；但“只有 3% 使用”只能说明它不普遍，不能证明它不重要。平均数擅长总结总体，却最容易掩盖具体人的损失。

Tom 的主线不是“PM 会消失”，而是产品管理不该是一张按人头配比的组织图。“PM配得越标准化，工程与设计越像被代管”说的是，决策能力不能被单一职能垄断；“AI没有替PM做判断，却把数据和代码的解释权下放了”说的是，更多人现在有机会直接接触证据，而不必等别人转述。

这两件事指向同一件事：谁离客户、系统和真实后果更近，谁就应该有更大的行动空间。于是，“晋升不该把最会做事的人赶出一线”不是反管理，而是反对把最强判断力困在审批链里；“平均数让你删掉3%的功能，也可能删掉一群人的全部生计”也不是反数据，而是要求数据决策回到具体人的处境。

对读者来说，真正该问的或许不是“AI 会不会替代我的岗位”，而是：当 AI 让取数、读代码、做实验都更便宜时，你是否能更快接近事实？你能否说清一个指标背后是谁、一个需求改变了什么、一次实验无论成败下一步该怎么走？会议、层级和头衔可以暂时掩盖判断不足，但它们无法替你完成这一步。