Twitter 前产品增长总监：不要为了招产品经理而招产品经理

#660. Twitter 前产品增长总监：不要为了招产品经理而招产品经理

我们之所以这样表述，是为了逼自己记住，不要为了招产品经理而招产品经理，只有在确实有明确需求的时候才招。最好别默认每个地方都需要产品经理。

来源：小宇宙节目页

开场与预告

00:00–03:45。中文版主持人一凯介绍：本期克隆 Lenny's Podcast，Lenny 对谈 Tom Verrilli。Tom 是 Whatnot 首席产品官，此前长期担任 Twitch CPO 和 Twitter 产品增长总监。

预告里先抛出后面会展开的几句：

「每招六个工程师，就配一个设计师，一个产品经理。招这么多产品经理，反而把工程师和设计师当成了小孩。他们本来完全有能力做出好决策，只是从来不需要这么做，因为总有产品经理在旁边盯着他们。」（01:18）

「Whatnot 产品团队建立在一个相当简单的理念之上，我们为产品管理的存在而感到遗憾。」（01:39）

「过去两年有三万一千八百三十二人申请 Whatnot 的产品经理职位，我们只招了一个。」（02:23）

「我们把所有 A 级选手都提拔到不再做具体事情的位置上去了。你为什么不希望梅西在你的球队里踢球，而是一直指望青训营出人？」（02:53）

Whatnot：直播购物平台，「有史以来增长最快的美国市场电商业务」。后面 Tom 会讲从渔民手里买活龙虾。

「我们为产品管理的存在而感到遗憾」

04:00。Lenny 从 Tom 网上那段话切入：「从成立之初起，Whatnot 产品团队就建立在一个相当简单的理念之上，我们为产品管理的存在而感到遗憾。」Tom：「没错，先生，这话你可能很少从首席产品官嘴里听到。」

04:39。Tom 说他总喜欢先从历史讲起。产品管理这个岗位一开始不存在。当时是业务方，通常是创始人或 CEO，直接跟工程和设计说我们要做什么，大家一起做出来。后来互联网业务的发展速度「比历史上任何其他业务都要快得多」，规模就意味着要把具体执行的细节委托出去，因为事情太多，一个人盯不过来。

那其实是一个专家角色，由某个人专门把这事儿想清楚。通常你跟工程师说的话变少了，也不需要向设计师描述那么多细节，因为他们懂，或者他们一直参与其中。

「而我们需要在科技行业里有一类专门做决策的人，这个想法其实是一个比较现代的功能，而不是纯粹的必需品。」（05:33）

Whatnot 的处理方式：

「如果工程和设计团队拥有他们需要的上下文，能直接做出好的决策，那其实会好得多。如果他们跟用户和用户的需求贴得足够近，他们就能做出跟产品经理一样的决策。」（05:40）

产品管理是手艺，不是资格

05:59。

「支持产品管理应该是一个专业职能的唯一论据，其实是它是一门手艺而不是一种资格。我的意思是它是靠做才能做好的东西，它是一种肌肉，找不到更好的词了。」

「肌肉是靠反复训练练出来的，你做的越多就越擅长。」另一面：你越把工程师和设计师从做同样的事情中抽离出来，他们的肌肉就越得不到锻炼。

产品管理确实扮演非常重要的角色，可以部署到那些必须做好的关键事情上，发挥杠杆，让设计和工程在那些场景下把手艺发挥到极致。但：

「只要有可能，最优解其实是不要产品经理，而是让设计和工程自己去走那些步骤，确保他们的肌肉得到充分训练。」（06:37）

Lenny 问：是不是早期很有用，后来 PM 太多、很多都不怎么样，现在又回到「什么样的 PM 才真正优秀，也许数量更少」？Tom：「对。」

「如果你去问大多数工程师甚至设计师，他们都会记得跟他们合作过的优秀产品经理，主要是因为跟他们合作过的糟糕产品经理太多了。」（07:08）

他不是在贬低谁，但作为一个职能如果非常苛刻地审视自己：「普通的产品经理真的能给周围的人带来巨大价值吗？」

「真正高质量的产品管理能做到的是传递清晰度，吸收模糊性，或者帮人做出及时的决策。」（07:31）

HR 配比、婴儿化，以及专业化是双向的

07:46。Tom 不想把责任推给 HR，但就是在某个节点，这种 HR 配比、一个 POD 凭空出现了：

「每招六个工程师，就配一个设计师，一个产品经理，一个工程经理，这个核心小组就成立了。」

服务十亿日活时，工程师很多，突然就有了一堆产品经理。大多数情况下，通知、基础设施这种东西可能根本不需要产品经理。工程师完全有能力理解那东西怎么运作。

「雇这么多产品经理反而把工程师和设计师给婴儿化了。他们完全有能力做出好的决策，只是从来不需要做，因为总有个产品经理在旁边看着他们。」（08:12）

08:28。Lenny：工程师和设计师不一定想做产品经理的工作，很多其实挺烦人、挺没意思；工程师想写代码，设计师想做设计。随着公司变大，还要对齐、写文档、协调、做笔记。

Tom：这正是专业化双向起作用的地方。有一批擅长做决策的人，这很有用。同样，有人站出来说「我是基础设施负责人，我想花很多心思在规模上，我不想把时间花在争论对齐、抠那些细节上」，这也完全合理。某些技能不一定能很好迁移：特别擅长在脑子里搭建基础设施怎么扩展的人，未必具备倾听客户、真正理解核心问题而不是他们嘴上说的那个问题的能力。

「所以我说我们感到遗憾，并不是说我们不要产品经理来做这些事。我们承认在那些场景下，你确实需要帮其他职能去专业化。但我觉得我们之所以这样表述，是为了逼自己记住，你不是为了招产品经理而招产品经理，你是在有明确需求的地方才招。」（09:44）

PM 绑到问题上，不硬绑到团队上

10:04。围绕这一点建设组织文化。每次写关于怎么交付、在做什么的文档，都讲清楚：任何人都可以推动变革。

「新产品的直接负责人可以是工程师，也可以是设计师，但每个人都要经过同样一层职能，就是你必须过产品评审，你必须真正去做那份工作，因为那是实打实的工作。」（10:24）

如果人们不想做，随时可以把产品经理调来调去。

「与其把产品经理硬绑到团队上，默认产品经理永远干那些活，我们更倾向于把他们绑到问题上或者核心项目上。这意味着，可能有一整年，某个工程团队没有配产品经理，哪怕有大量产品工作在推进。」（10:41）

Lenny：这种话通常来自 Linear 这类开发者工具公司；Tom 做的是「非常非常消费级的产品」，这话分量更重。

Tom：这些是这些年慢慢学到的。Whatnot 之前在 Twitch 待了七年，「非常亚马逊式的两个 pizza 团队，很讲配比」。硅谷起步在 Twitter，「对齐会议多得要命」。后来意识到：很多这种东西只是管理层看不到底下在发生什么的结果。于是招更多人，建更多层级，系统催生系统。

真正在变的是：过去那种唯一获得杠杆的方式——往你下面多招产品经理让自己更资深——已经不成立了。现在对业务里发生的事有了更好的理解，直接跟代码库对话、跟工程师沟通，比以往任何时候都容易，不必陷入全面扩张的套路。他不觉得消费级还是企业级是分界线，「更多是组织自身的文化」。

这不完全是 AI 导致的

12:34。Lenny 问：这个转变有多少是 AI 驱动的？

「我觉得这倒不完全是 AI 直接导致的，但 AI 确实让这件事容易得多。」（12:46）

一方面，一个个人贡献者现在能撬动巨大的杠杆。他前几天跟几位资深负责人聊，大家都觉得：有了 AI，能做的事太多了，以至于会因为没做的事感到压力——再多挤出几个小时，就能推动一大堆事情。有了 AI 工具，再加上判断力够好，跑起来快多了。

「现在你在一个 Hex 线程上就能拉数据。这在 2017 年基本得靠亚马逊 L7 的数据科学家干一两周才能搞定。」（13:16）

除了 AI，配比上的推动也伴随着文化变化：招优秀的人然后别挡他们的路、自下而上的路线图。过去这段时间科技行业有点转向：自上而下其实挺好的，因为高层通常能快速决策，省掉一大堆对齐扯皮，他们掌握的大局背景可能比大多数人都多——只要他们真的贴近一线实情，能力也够。

「你可以让一个非常资深的产品经理覆盖更多事情，比用三个相对初级的 PM 更高效。当然，I/O 让这一切容易得多。」（14:04）

Lenny 把大前提再说清楚：说感到遗憾，并不是不想要 PM 或觉得 PM 没用，而是最好不要默认每个地方都需要一个 PM；让其他职能的人去做 PM 的工作，这是很好的。而且 PM 本身也会抢走别人练手的机会——那些人如果能做那些工作，其实能执行得更好，做出更好的产品。对 PM 来说，不固定绑定在某个团队，「哪里有活儿我们就去哪儿」，能积累更多实战，锻炼更多肌肉群。

Whatnot 现在怎么分人

15:03。

「我们刚过了二十个 PM，现在公司里大概有二十一二十二个 PM。考虑到我们卖家跑出来的 GMV 体量，这个数字算是相当小了。」

大致松散分成三个组：买家、卖家、信任与风控（标准、支付、安全）。组内会比较频繁地重新分配 PM，只有松散归属，比如大致是增长 PM，或大致做发现推荐；组内也会很快调配和流动。

规划方式：每六个月，CEO、Tom、其他一些人和资深负责人坐下来，定义未来六个月必须达成什么，包括结果和关键项目，然后过清单——谁是直接负责人。他们今天早上刚结束一个规划周期。经常到最后发现：有件事在好几个团队的路线图里都排第二第三优先级，感觉挺重要，但还没有负责人，于是抓一个 PM：「恭喜你，这是未来六个月需要你交付的事。」

很少会说「你要做一个功能必须严格按这个方式工作」。更宏观：你怎么去搞清楚需要达成什么，然后把觉得能引导这件事的人安排上去。不一定每个名字都是 PM，但过规划流程时绝大多数情况下落在 PM 身上，而且往往是技能跟任务匹配的（偏财务、偏算法和推荐系统、偏核心用户功能）。

招人：走下坡路的和出彩的

16:52。过去两年 31832 人申请，只招了一个。Lenny 问：哪些特质在上升，哪些在下降？

走下坡路的：

「那些在面试里花大量时间讲对齐会议，推动对齐，利益相关者管理这些事的人。」（17:21）

「确实有一类产品经理，我自己职业生涯早期也是其中之一，他们的专长不是技术，也不是客户导向，而是搞政治。」（17:30）

天然倾向于推动对齐、经营关系的人，你问一次失败经历，他回答「我没及时跟 CEO 同步某件事，结果导致方向调整了」——「这绝对是反模式，正在走下坡路。」

真正出彩的：

「在面试过程或案例研究里，能不能同时看到宏观思考和微观思考。」（17:53）

例如：我觉得系统大概是这么运作的，我能描述一个中态；但同时能不能表现出一种急切——这是我验证它的最快方法，这是我要推动它落地的地方。还有：对自己做过的东西够不够具体。

现在有太多人待过「发个优步、随便哪家大规模公司」，只是照看已经存在的东西，顶多打磨边角，而不是拿到问题去想出独特新颖的东西，或在复杂变革中反复迭代，一路上是自己在做决策。在惯性很大的大组织里，随大流很容易。

「不一定要成为变革的推动者或决策者，但决策者恰恰是产品经理最终要做的事。」（18:38）

每个岗位入职的人都要做一个实打实的案例题：给题目、一些数据，回来给一个观点，再口头辩护。演示特别漂亮、擅长剧场但不擅长具体细节的人，思路崩得有多快，非常说明问题。（45:18）

怎么练系统思维：「先想清楚，然后干」

18:44。Lenny 刚请了奈飞首席产品与技术官 Elizabeth Stone。她最看重、上升趋势最强的特质也是系统思维；她的建议是从问题往后撤一步，想想经理会怎么看，又会怎么影响公司其他业务。

Tom：这种能力靠纯脑力练习就能练出来，可以从很小的方式开始。他在产品评审里经常问：

「当有人说我们想跑个实验时，我会问，好，如果结果是绿的怎么办？如果结果是红的怎么办？如果对方说其实我不知道我的策略会怎么变，那好，我们还没真正想过这个。」（19:20）

同理：如果这个功能的使用量比预期高一千倍会怎样？可能带来哪些意想不到的连锁反应？怎么在动笔之前、往系统里写代码之前，就在脑子里全过一遍？

产品经理经常被拖慢的另一件事是：有风险，法律那边可能，财务那边可能，另一个团队可能。内部说法：

「先想清楚，然后干。」就是说把所有可能出错的地方想一遍，搞清楚规模会在哪里崩，想清楚可能发生什么，然后照样往前推进。（20:07）

他的版本：做那个脑力练习，把场景推演出来——如果它被大规模采用会怎样？如果它真发生了会怎样？如果有地方出错了，会是哪里？

「你不需要把每个都解决，你只需要把每个都想过一遍，然后你会发现你实际解决掉的比你预想的多。」（20:50）

高增长环境里，要找的不是一个 5% 的统计显著胜利，而是能彻底改变业务并且随时间产生复利效应的东西。

转向个人贡献者工作

21:23。Lenny：产品经理从大型组织管理世界，转向真正去做事儿。

职级体系里，如果你作为产品经理非常成功，会被提拔成总监，突然变成别再亲自动手，目标只是辅导和引导。

「于是我们把所有 A 级人才都提拔到不再做事的位置上，他们把全部时间花在拉齐对齐上，花在辅导和微调团队工作上，结果就出现那种特别反复的开发流程，某人做完所有工作拿去评审被否掉，然后就在评审里来回折腾。」（21:52）

Whatnot：整个团队大概有四五个管理其他产品经理的人，他们所有人都会把百分之九十以上的时间花在个人贡献者工作上；Tom 自己大概还有百分之五十。

好处：第一，如果你是产品副总裁，有十年以上、可能十五年做产品经验，对什么能成的直觉应该已经磨得很准，能比别人更快做决定，非常快地产生实际影响。有这样一个能直接干活的人，而不是把问题拆给几个产品经理层层对齐、不同工程团队来回争论，「你直接往前冲就行」。

第二，一个副总裁能承担多个初级产品经理的工作量，任何时间点都能看到更大的棋盘，更可能做出直觉上正确的决定——比如怎么调优推荐算法，而不是去管那些发货慢的人。如果你在思考怎么管理发货慢的卖家，又了解推荐算法的威力，不管哪种情况你都能做出正确的决定。

Twitch 的例子：推荐团队和广告团队总是在抢曝光量。他到 Twitch 做的第一件事是把广告放进推荐里，确保同一个产品经理对两者负责，他们会做出自然的权衡——目标是信息流产生的 GMV，一部分来自自然流量，一部分来自付费替代方案。同一个人负责多件事情，会自然拉起这些目标，省掉几个月来回扯皮，以及把公司优先变成个人职业优先的政治斗争。

「这能让每个人都连接到底层真实的情况，而不是评审里看起来的样子。」（24:19）

「你为什么不想要一个能为你团队冲锋陷阵的人，而不是总等着那个学院派来指手画脚呢？」（24:31）

IC 具体指什么；薪酬；少而精

24:44。Lenny：是写代码，还是带团队、负责路线图、写战略文档？

「简短的回答是，什么最能有效地把东西发出去就做什么。我有没有在 Whatnot 亲自写过一些生产代码？有。我是不是觉得那真的是我时间的最佳用途？也不完全是。」（24:56）

他确信有人悄悄把大部分代码重写了一遍，确保 lint 正确、本地化没问题，还有那些几十年软件工程经验教会你的、他和 Claude 都没搞对的细节。

核心是：有没有真的在看支持工单，知不知道客户遇到什么问题；有没有自己拉取所有数据、真正理解它们；有没有和工程、设计坐在一起；有没有直接查询代码库来理解事情怎么运作；然后有没有写规格文档，有没有主持站会推动进度。「这些都是核心的个人贡献者工作。」

对「我以为过了这个阶段了，可以靠别人干活、想大局」的人：可能很多组织那种做法确实很有价值，他们也会继续那样做。他招人倾向于找那种「我以前真的很爱产品管理，但我已经受够了整天开对齐会议」的人。他到处跟 CPO、产品副总裁说：「你们难道不想念真正动手做事的感觉吗？要不要回来？」行业会出现分化，有些组织规模大到可能不适合人人都亲力亲为，也得有配套文化。每个创业公司都是创始人的缩影。但跟在 Meta 当了五六年高级总监、整天泡在对齐会议里的人聊，他们会说自己真的很想念跟客户聊天、跟工程师聊天、真正把东西发出去的感觉。

Lenny 翻出那份名单：Workday 的 CTO、Instagram 的 CEO、Box 的 CTO、Super.com 的 CTO，现在都只是 Anthropic 的工程师了。Tom：

「我最大的愿望就是 Whatnot 的产品团队也能变成那样，一群能力很强，理解很深的人，最后以个人贡献者的身份来这儿干活，做东西。」（27:29）

薪酬：Lenny 问有没有可能既当个人贡献者，又拿到副总裁级别的钱。Tom：「我反而觉得更容易。」

「五个 L5 汇报给一个 L7，四个 L7 汇报给一个副总裁，把整个产品组织的薪酬加起来，然后反过来问，如果我只要三个人呢？为什么不能给他们都开副总裁级别的钱？尤其是当他们的影响力跟那些副总裁一样大的时候，为什么不行？」（27:48）

产品会做得更好，还是人更少？「我当然觉得产品会做得更好。」大家说了很久：领导层不可能一直对一线保持亲力亲为，你得招更多层级。他们发现其实不是这样，需要的是另一种能力：刻意去确保自己真正理解事情的真相。

增长会上的例子：有人说「那是欺诈」。反问：你怎么知道？数据集里标着欺诈。那他是怎么被标出来的？我猜是运营标的。标注的标准流程是什么？不知道。「那你其实并不知道他是不是欺诈。」这么追问一个很有经验的产品总监，他们会说有道理、去查一下。然后几乎必然会去强化用来做数据标注的那套系统，因为突然有个很聪明又很上心的人去理解我们到底怎么做的。

「我们要做更少的事，但要把每件事做到极致，把最优秀的人推到各个角落的细节里去。意味着你在过程中会修掉很多问题，而不是一路做一堆妥协。」（29:19）

增长太容易掩盖所有问题。所有人都在按平均值干活。文化上得下定决心：「少而精地干几件事儿。这里致敬一下 Ron Swanson。」把最优秀的人推到一线，真正扎进细节。时间一长反而更高效，因为第一次就把事情真正搞懂了。

以前做初级 PM 时花多少时间问工程师某件事有多难做，为了帮未来排期，反而拖慢实际开发。现在可以坐下来跟 Claude 聊一聊，大概就知道工作量级别；可以翻一遍说，感觉有一堆弹窗在撞车，新用户一打开 App 肯定会被砸到；把信息流加载出来，问谁在什么顺序下看到什么、什么时候触发。有足够资历的同事一看就能说：这不行，直接做个好决定，把顺序改一改。

「我现在省掉了一场启动会，一场对齐会，一周写 PRD 的时间，实验周期，所有这些，就因为有一个被授权去拍板的人。」（30:38）

给正在找工作的资深 PM

30:56。大话题是：你得接受退回个人贡献者，放弃光鲜头衔。还有别的建议吗？

「我的建议是先在你现在的岗位上开始做个人贡献者的活儿，回到基本功，确保你在承担一些实际的动手的工作，因为我觉得保持这些肌肉的锋利是件好事。我觉得这也得从在公司内部主动争取这些事儿开始。」（31:18）

把那种生产力带回现在的岗位，对你在哪儿都有帮助。网上聊 PM 现在都变成工程师了，「我觉得这挺好，这是个值得去练的好肌肉」。他也推过一些生产代码，想通过这个练习去理解它。但动手之前更重要的是：

「你能多快回到正确界定范围这个肌肉上，理解问题，能定义清楚什么叫做的好。」（31:58）

大多数做过总监以上职位的人都体会过那种痛苦：坐在那儿看着一个初级产品经理在同一条 PRD 上来回折腾、反复送审，而你其实早就知道答案是什么。「不知道从什么时候起，我们变成了把马牵到水边这种叫法，而不是帮他们理解答案，然后继续往前走。」辅导风格里有些东西可以找回来，帮人相对快地理解什么叫做得好，而不是没完没了地审。

Lenny：最近一位嘉宾说，PM 杠杆已经很大了，如果不坐在那儿试图往生产环境推代码，杠杆会大得多。Tom：「这话听起来挺傻的，兄弟。」走完提交代码那一整套细枝末节，花的时间比想清楚问题是什么、并能把它描述出来要长得多。练一练、确保自己在做点实际的事是好的——比如自己去试开发工具是不是变好用。但理解代码库，然后跟一个真正能高效执行的人聊，能让你走很远。不然会掉进一千个经典陷阱，那些都是别的工程师在 L4 时早就学会怎么避开的。

AI 让团队更快的前三

33:44。Lenny 问除了原型制作，前三是什么。

第一条，遥遥领先的是数据科学。 Whatnot 内部用 Hex 拉数据。有了这种工具之后，几乎很难再想起以前当产品经理的日子。以前没法真正拉非常细分的用户群数据，没法在听到某个报告之后直接抓出某一个用户去理解。现在可以把日志拉出来：这个用户到底做了什么、看到了什么，有多少其他用户跟他一样，影响会是什么；很快建出敏感性模型、预测模型、回归模型。「这强大的不可思议。」也更容易发现回归问题，以及两个产品混在一起产生的奇怪连锁反应。庞大复杂系统里拖慢你的往往就是这些东西，比如发布列车。建对了 AI 工具，就能很快发现回归，基本上等于让大家放手去干。

「作为一个产品经理，过去这一年我跟数据科学家说话的时间，比我职业生涯里任何时候都少。尽管我花在数据上真正理解产品运行情况上的时间可能是我职业生涯里任何时候的十倍。」（35:11）

第二条： 别再拿「代码库是怎么工作的」去烦工程师，直接去问 Claude。职业生涯早期常说：目标永远是理解你的系统，要细到哪个盒子、哪一行代码、哪个系统驱动哪个东西。「现在没有任何借口不去理解这些，甚至理解到更细的层面。」

第三条，可能非常 Whatnot 特有： 做直播产品十年，能把一个产品发出去，看着客户用它、看着他们自己摸索明白。现在很多人通过 Listen Labs 之类也体验到看着别人用你产品的感觉。AI 特别酷的地方：当他们说「我遇到问题了」，可以实时盯着代码库判断——这真的是正在发生的 bug，还是理解落差？你突然有了一个人用你产品的视频记录，可以实时分析代码库，还可以通过 AI 直接跟代码库对话。

「一个打了类固醇的反馈回路……客户那边，代码那边，还有作为旁观者的观察那边，全部实时掌握。」（36:47）

37:15。入职「沃纳」第二周：这基本上是个电商平台，很大程度是拍卖平台，本质是直播电商。一种玩法叫突然死亡，倒计时一结束就成交；传统拍卖是最后五秒有人出价，时钟加回十秒，卖家可以自己决定用哪种。他看着一个卖家说：这些太慢了，希望七秒倒计时变成三秒，因为想多卖点货。办公室里两个工程师对视一眼：「那是个配置项，我们完全能改。」实时改了，跳进直播间聊天区说刷新一下 App，「砰，就按那个方式跑了」。他当时想：「酷，我跟自己人在一起，我来对地方了。」AI 让很多人做这种事变得容易。「不是说我会去碰生产代码，用那种方式，因为那是个灾难性的想法。但合格的工程师去做，那是个绝妙的主意。」

数据科学、角色升降、未来团队长什么样

38:22。Lenny 的朋友是数据科学家，说现在是艰难时期。以前是被要求做某个分析，处理数据，回来：这是结果，我对这个结论有信心。现在时间变成看非数据科学家做的半吊子工作，「帮我看看这个对吗？」一半的时候是错的，「我他妈现在的工作到底是什么？」

Tom 有共鸣，也因此主张少而精的高级产品经理更有帮助，这些人见过更多类似案例。但很多不清晰来自另一个根源：有些组织长期以来在数据工程、数据结构、数据标注上投入不足。不只是分类体系对不对，而是数据系统和结构到底搭得好不好。很多最优秀的数据科学家都在往那个方向使劲：追踪和归因机制是不是都在正确更新，让那些东西不那么容易被误解。

「用 AI 工具去查一份数据跟用 AI 工具去写代码一样，并不能免除你的责任，你还是得确认那是好的分析，好的代码。它只是让那些天生有这方面倾向的人更容易发挥。」（39:32）

Lenny：是不是需要更少的 PM、更少的数据科学家？哪些角色往下、哪些往上？

Tom 其实有一阵子没跟数据科学的人聊了，他们当然还在招不少人，追踪、归因、度量非常强大。「需要更少」有另一面：更少的人干同样的产出，并不一定意味着宏观上人数变少——系统用对了，就能更快增长、见更多东西、接更多事。「如果最后净人数变少了，我反而会惊讶。」更多是相对于客户影响而言，人均产出更高了。

往上走的：那种技术负责人，有点像工程经理和一线工程师的混合体，带一个很小的团队，直接冲着一个目标干。尝试一件事的成本降下来了，孵化很多小团队到角落里试着把某个东西做出来——不完全是原型，就是去试一把以前觉得太难的事儿。成本越来越低，杠杆越来越高。「轻量工程经理，姑且这么叫吧」，不完全是技术高管，也不是完整的工程经理角色。

41:25。人人都成了建造者。未来几年标准产品团队长什么样？Tom 不敢说所有地方。在「沃纳」，可能大体上还是跟以前差不多：确实有理由需要专职的设计师、工程师、产品经理。那些非常具体的团队大概率还是会保留，用来做很有信心、很确定必须解决的问题，或很有把握有路径想扎实推进的事情。核心团队周围会有更多自由空间。不管你是设计师、工程师、产品经理还是数据科学家，都可以去、也应该去。

「如果你周五下午坐在那儿写产品需求文档写不进去，但你挺确定自己能去修个什么东西，那就去修。」（42:30）

正式组织形态可能不会大变，但会有更多自由空间给那些既懂客户问题、又熟悉代码库、还理解宏观背景的人，他们会被赋予更多自主权。

产品技能与产品剧场

42:49。Lenny 两年前发过一篇：《为什么产品经理是科技行业里，在 AI 时代最有优势的岗位》。开头聊的是应该活在一个为产品管理的存在而感到遗憾的世界，但在这一点上其实一致：那些最重要、最有价值的技能，不管是 PM、工程师还是设计师来做，本质上都是产品经理的核心技能。例如：判断该做什么，提炼需求，把需求讲清楚，按投资回报率最高的机会排优先级，给设计反馈，制定市场拓展策略，理解商业战略。当 AI 承担了搭建的工作之后，这些是不是成了最有价值的东西？

Tom：「完全同意。」补充：

「这些核心的产品技能，未必是过去五年里我们奖励产品经理的那些东西。过去奖励的是讲故事，对齐，战略。」（43:48）

「我是不是真的懂客户，我是不是真的懂业务，我是不是真的懂技术，我能不能把这三者翻译到一起，实现最有效率。当做事变便宜了，试错变便宜了的时候，这才是杠杆的支点。」（44:04）

绝对同意产品技能可能是最持久的。补充只是：有很多顶着产品经理头衔的人，过去五年并没有花多少时间去打磨这些技能，而是特别擅长跟领导层讲框架。「所以我想把我们这个职能拉回到核心工作上来。」

Lenny：「Marty Gagin 管这个叫产品剧场，很多人只是在做产品经理该做的事的表面功夫。」

Tom：我自己也有这个问题。我们奖励这种行为太久了，所以产品剧场还在很多人身上延续。现在这种玩法已经没有多少藏身之处了。回到那三万二千人投简历：很大一部分人自认为是产品经理或者头衔是产品经理，但实际上并不具备；把大量精力放在对齐、写文档、开会上，而不是真正去搭建、去理解做一个成功产品需要什么。

「招到优秀的人然后别挡路」是错的

45:41。怎么让招来的人发挥最大价值？Tom 不同意「招到优秀的人然后别挡他们的路」。

「我得说需要加个限定，招到优秀的人然后别挡路，这个说法是错的，但可以在这个基础上展开几点。」（46:01）

它变成了一种笼统的口号：让他们自己定路线图，自己找问题，完全放权，什么都不管。真正的答案显然是：你招的人越好，你就越能完全信任他们知道自己在做什么。但他们倾向于先验证再信任，而不是完全信任，甚至也不是信任但验证。

他可能比任何直接下属都更清楚系统里各个部分——买家、卖家、信任——怎么拼在一起。但他们几乎肯定比他更懂那些单个功能的具体细节。今天有人考他「Wanna 推荐模型里所有权重」，他肯定答得不如那个团队里的任何工程师、任何产品经理。话说回来，他有责任随着时间慢慢去学、去理解，因为是他在让他们做决策，而他在验证他们做的事。真正花时间跟那些团队一起干活，在战壕里一起解决问题，是非常有力量的。

加入之后最早观察到、也是创始人兼 CEO Grant 一直在做的：坐在评审会上说「我觉得这个不对」，停一下，「我把今天剩下的时间都空出来，咱们坐下来把它搞清楚。」最后真的跟团队坐在一起逐项过。有了 AI 数据工具，这事儿容易多了：把工单调出来，把代码调出来，把数据一行一行过一遍，搞清楚到底发生了什么，然后在那儿做决定。这意味着他对正在发生的事儿非常了解，也在文化上定调：我们就是在求真。

有一阵子评审变得很像「我们 VS 你们」，变得特别像「就等你点头」——作为产品经理，全部目标就是拿到绿灯，回去跟工程师说「我有话语权，我能让 CPO 批准我们要做的东西」，而不是「我们就是想找到正确答案」。

规划是让全公司对齐哪些是必须解决的最重要的事，基本上是个资源分配的讨论。最终他要负最大责任的是：确保把合适的资源放在合适的位置去达成目标。但如果只是把事儿都派给团队让他们自己琢磨，自己不定期扎得很深，也没法确定那些位置是不是对的。例如：推荐到底怎么运作？欺诈检测用什么样的逻辑判定一个推荐无效？基于地址信号。地址信号怎么算出来的？是 Google 归一化过的数据，还是用户随便填的自由文本？

「如果你不逼自己下沉，跟你的个人贡献者工程师、个人贡献者设计师、个人贡献者产品经理坐在一起干活，你根本不会知道这些事儿。所以没有微观，你就做不好宏观决策。」（48:39）

他逼自己做 T 型人才：需要的时候能扎得非常深，大多数时候在各个板块之间保持广度。「招了人就不再追问，把所有细节都委派下去的做法，真的不是把组织潜力发挥到最大的最成功模式。」

给创始人打工：两个爸爸问题

49:35。CPO 夹在很有主见的创始人和执行团队之间。Tom 连续给三位产品意识非常强的创始人打过工；在 Whatnot 有两位创始人，这其实是件好事。总的来说，尽量不重复劳动。

「如果 Grant 或者 Logan，我们的创始人已经在管某件事了，那大概就不需要我了。多一层有什么好处呢？」（49:49）

团队里有个产品经理开玩笑管这叫「两个爸爸问题」：两个人发出互相矛盾的指令，或者有人想先过目一下，你费半天劲做出来给我看，拿回去又变成另一个说法。

第一原则：如果 Grant 或 Logan 已经在管了，确认他们在盯着、对此负责，然后他退出。会有很长一段时间，手下整整一半的团队可能在忙某件事儿，而他每天都不知道进展到哪儿了。这完全没问题。不需要过问他们做的所有事，只需要确保有人在承担那个抬高标准的工作。

第二点：

「如果你在创始人领导的公司做产品负责人，你必须明白这不是你的公司，是他们的。」（50:40）

找到合适的平衡：这事你愿意听反馈吗？已经下定决心了吗？愿意接受别人推一把吗？磨合出那个节奏。创始人领导的公司在这个行业做得这么好是有原因的：最初做出来并让它跑起来所需要的洞察力和客户直觉，通常非常重要。他把自己的工作看成：确保创始人不覆盖的地方，我们有补位。

自上而下和微管理

51:24。Lenny：最好的团队、公司、产品，最终都来自自上而下、创始人主导的，几乎是微管理——对很多人是贬义词，但基本上就是扎进细节里。

Tom：自上而下这套，只要领导层足够深入细节、判断足够具体，就能运转得很好。

「它出问题的地方在于，你其实并不掌握真实情况，却想从上面去管人，这才是微管理这个词的真正来源。」（51:41）

反过来，如果你和大家看的是同一份数据，手里有真东西，「我还没见过哪个初级工程师或刚入行的设计师，不愿意坐在 CPO 或 CEO 旁边一起把东西做出来的」，因为完全不会被卡住，没有对齐会议，没有那些杂事。真的扎在细节里，能给出的反馈质量会高得多。微妙之处是：你怎么保证自己能在足够多的地方做到这一点。「现在是从未有过的适合深入细节的时代，因为你真的可以实时去查询这些信息。」

Grant 会说：好，我今天把日程清空，我要花时间把这件事彻底搞透。他们能这么做，是因为先规划要做什么，再分配任务，再分头推进。CEO 大概同时盯三到四件最重要的事，拍板说这四件事现在归我管；Tom 去管别的。在那些事之外，这一天里做的什么事能比承诺这半年要完成的五件事更重要？如果不是招聘、固定会议之类的，那就直接清掉。「给团队定个调子，在我们把这件事搞明白之前，别的什么都先放一放。」

53:23。给想找 CPO、或给创始人打工的第一个产品经理的建议：第一件要搞清楚的是你到底为什么想要这个职位。大家有个印象，觉得 CPO 的工作就是你能决定所有路线图。「那我得告诉你个坏消息，这并不完全是真的。」得花时间和那个人相处：怎么在一个话题上碰撞，他喜欢别人怎么提反对意见，不喜欢哪种方式。Tom 加入前和 Grant 大概喝了五六次咖啡；走了一轮面试，最后飞到洛杉矶，和 Grant、Logan 整整待了一天，过几个不同的问题，聊路线图，真正深入进去。过程中尽量表现出最平常的自己，而不是面试状态的自己。得问自己：我真的愿意把全部时间都花在这种讨论和辩论上吗？

「我喜欢当 CPO 或者说产品负责人，是因为在很多方面，我做的是把那种愿景和直觉翻译成现实，然后学会怎么在不去和对方竞争的前提下推动对方，这是一门艺术。」（54:37）

见过很多 CPO 和 CEO 的关系搞砸，最后变成 CPO 在跟 CEO 争愿景。「我觉得那不是你的工作。」

温和地推动方向

55:01。Lenny 问有没有诀窍。面对很强势的人，总想让对方同意自己想要的东西。

「第一件事就是别把它当成什么技巧。你不是为了得到一个答案，你是在寻求真相。」（55:15）

一开始意见不一致其实不算特别常见。但如果你是房间里比较资深的产品负责人、对面是 CEO，或你是总监、对面是 CPO，职责之一是：在对方给你一个你没想到或不理解的方向时，从好奇出发——那个人是不是比你掌握更多上下文？

开场：

「我有没有听错？这是你的先验判断，有没有什么我不知道的上下文能帮我理解这个判断？」（55:50）

确保大家都站在同一个基准线上。他也这么教自己的产品经理：如果我从一个你没想到的角度来，你先停下来，确保你理解我为什么这么来。

人有状态好的时候，也有状态差的时候。有时候问题可以很简单：这件事你心里已经有定论了，还是愿意听意见？

• 如果「不，我已经很确定这就是答案了」，那就闭嘴。「别为了抬杠而抬杠。」
• 如果「其实可以，你尽管来推我，但我需要看到数据」：现场没有数据、只有观点，辩论条件就很清楚——有新数据就拿出来。真的很相信但没有数据，就问问自己为什么，或者去把数据拿到再回去。
• 如果谁都没数据，就是两个观点对撞：「那 CEO 的观点会赢，这没关系，把自尊放在门口，去找到答案。」
• 如果你有数据，就拿出来。

要确保自己是为了正确的理由在辩论。产品剧场里很容易变成你想确保自己设定了框架和基调。有些时候术语很重要，具体用哪个词可能真的很关键，但很多时候其实没那么重要。

拉手风琴

57:16。跟共事过的人聊时听到过好多次，这个说法叫拉手风琴。Tom 不太喜欢框架，但觉得有一个思维模型挺有用，正好对应前面说的：把问题想透，在脑子里做功课，哪怕什么都没上线。代码的神奇之处是可以很快发布、快速迭代、边做边拿数据。

两种失败模式：

1. 只是一直往前迭代，「把面条往墙上扔」，却不太清楚自己在往哪个方向走。
2. 坐下来写出长长的路线图和战略愿景文档，规划未来两三年要做什么，反而丢掉了相对于其他所有行业的比较优势——学习。A/B 测试意味着你可以更新对问题的理解，从而边走边调整方向。

「你想想钢琴手风琴，在你能弹出一个音符之前，你得先把它完全拉开，把空气吸进来，也就是我们到底想做成什么。但直到你按下琴键，把它一路推回去，推到 V1，音乐才真正产生。然后当你弹下一个乐句的时候，你又得把它完全拉开。」（58:10）

「拉开它本身不创造价值，拉开这个动作本身不产生任何东西，所有的价值都在推回去的时候产生。但如果你不持续做这个动作，不断重新评估我们理解了什么，这如何改变我们在做的事，你很可能谈的不是该谈的东西。」（58:41）

记忆工具：「你得不断的拉远，再推回来，拉远，再推回来。」Lenny：拉开的时候也在制造音乐，但是向内的——我们学到了什么，你怎么把它传达给大家，然后回到发布。「内在的音乐，外在的实验。」诚实的答案是两者都得做，哪一边都不能过度偏重。

教训：跑实验，但跑完之后要思考结果在更大图景里的含义，带着「我们到底想达成什么」。我有个信念：如果我们因为这样那样的原因改变发现算法的运作方式，它就会产生这样的影响。那我能做的最小验证是什么？奏效了，计划不变，第二版。这版不行，第三版就得换个思路。「你就得一直保持这种循环往复的节奏。」

1:00:21。具体场景里他们通常错在哪？通常是正在交付某个东西，但只是非常局部地看，没有真正理解它的影响。

例子：大多数市场平台的核心是商品条目。没有商品条目，Amazon.com 基本上什么都不剩。但在视频电商和直播电商里，Whatnot 历史上其实并不需要商品条目。想卖一副 AirPods，可以直接举到镜头前，说这是 AirPods，从一美元起拍。作为买家，已经掌握了做购买决策所需的全部信息。创建商品条目大约要花三分半钟，描述并举起来是零分钟，对卖家大概率是净好处。再拉远看：新买家会期待搜索功能能用。如果不知道你在卖什么、直到你卖完才知道，就不可能把想买 AirPods 的人导流到你的直播间。于是：我们不需要修这个，它现在能用 → 那让每个卖家都创建商品条目 → 再拉远：每个条目花三分钟，每小时能卖的东西数量会大幅下降，对卖家不利。这条路又走不通。

「你就得不断地在这些事情的长期影响是什么，和我们正在做的东西会带来什么连锁反应之间来回拉伸。」（1:02:08）

Whatnot 和 Agent 电商

1:02:17。光谱一端是 Whatnot 真人实时买卖，另一端是 Agent 替你买、Agent 之间互相协作。

Tom：「我本人是欢迎 Agent 统治者的」——灯泡、空气滤芯，任何维持生活运转的程序化采购。高意图购买也很乐意交给他：一根特定的电脑线、户外的灯、要去参加婚礼所以需要一双黑鞋且必须周四前送到。绝对没问题。但美国大部分电商其实并不是高意图的。电商快三十年了，「电商在美国零售支出里从来没超过百分之二十」。美国零售绝大部分仍然是人们亲自去店里买。英国也类似，大概七十五比二十五。很多购物其实是低意图的：去商场可能因为有个婚礼要参加但没衣服穿，到处逛逛，并不确切知道自己想要什么。商店的价值在于经营那家鞋店的人有判断力和品味，精选、客户服务、橱窗展示。可以慢慢搞清楚想买什么，或者被他教育一番，而且这还挺愉快。「商场之所以是一种社交活动是有原因的。」

Agent 这块会非常庞大。美国零售是个七万五千亿美元的行业，「我不觉得这是赢家通吃的事」。直播电商做的是第一次真正把互联网的规模和便利，跟线下购物那种社交文化体验结合到一起。Twitch 时基本默认一个直播间不到一千人就不经济，因为要靠 CPM。Whatnot 上可以进一个直播间，里面有三五十个人。「你在商场里开一家鞋店，店里有五十个顾客，你根本不会关门。」客流量远超任何实体店，电商的经济模型跟娱乐完全不一样，根本不用操心 CPM。

「所以我觉得它跟 Agent 不是竞争关系，它满足的完全是另一种客户需求。」（1:04:46）

Twitter 带走的两样东西

1:05:00。Lenny：每个在 Twitter 当过 PM 的人都被那段经历留下了阴影。

Tom：问一个 2015、16 年待过 Twitter 的人，有点像让治疗师去问一个人他的童年。他在那儿的两年里换了九任产品负责人。合作伙伴团队有人说：感觉 Karl Swisher 就住在活动现场，那地方隔三差五就有戏。那个时代 Twitter 的产品流散相当惊人。

第一样：

「如果你真的找到了产品市场契合度，如果你真的把闪电装进了瓶子里，那不管你把组织搞得有多烂，它都照样巨大。」（1:06:04）

Twitter 当年真的有那种产品市场契合度。能真切感受到人们有多爱你的产品。这就是 PMF，「不是嘿图表看着还行，而是有一种狂热在里面。」

另一面：

「大多数时候你听到这事真的很复杂，其实并不复杂，就是领导层太弱。」（1:06:29）

在那儿的两年，所有人都知道迟早要放开 140 字限制，一个接一个的工作组，「超越 140」项目到处都是。日本人发推频率是西方市场的六倍，因为汉字能在同样字数里表达多得多的内容。那是必然的终点，但需要一堆工作、一堆权衡，就是没人愿意拍板，于是又是一个设计冲刺、又是一个循环。他离开之后又过了一年半、可能快两年，才终于有人真做了。「结果呢，没人死，那个地方的灵魂也没散架。」编辑推文也经历了同样的讨论，又花了两年半。

Lenny：马斯克基本把一切都改了——品牌、名字、网站、员工人数。什么没变？基本上就是 Twitter 的网络效应。「它就是那个该在的地方，所有人都在那儿。这很难打破，而且就算你费了多大劲想把它搞砸，它还在撑着。」「如果你真的把闪电装进了瓶子，你一眼就能看出来。」

失败角落：平均值对个体毫无意义

1:08:06。Lenny 问职业生涯里失败的例子。

Tom：整个职业生涯里失败的时候比成功的时候多得多。那篇文章末尾附了他们内部实际用来讨论怎么做事的文档，开头就说「五成胜率就是目标」——希望自己对的时候和错的时候一样多。搞砸的具体例子太多了，但背后有一条很常见的线索：

「这可能是任何一个产品经理都容易掉进去的陷阱，就是平均值对个体来说毫无意义。」（1:09:06）

这大概是他被伤得最深的一点。在任何一个规模不小的群体里，去看某个东西的平均效用或者平均采用率特别有吸引力。发现只有 3% 的人在用，就想这个功能可以砍掉了。但如果你不再往下挖一层：它虽然只占 3%，对某一群人来说这就是他们 100% 在做的事，是他们的核心使用场景。为了图省事、有人不想再维护，直接下线，「结果就是你把这群人的核心用例给炸掉了」。再回到网络效应，这件事引发的持续连锁反应可能是巨大的。

在电商里经常想：这是某个人的生意。

「如果我们只是不够可靠或者随便下线一个功能，那就有点像 Westfield 购物中心在圣诞节前把店给掐了，想都没想。」（1:09:58）

对别人的生意来说，真实的下游影响往往来自对指标理解得不够细致，尤其是平均值，他们一直在骗你。大多数时候，那些真的让自己都失望的决定，通常都是因为依赖了平均值，而没有去想藏在下面的那些个体使用场景。

Lenny：「当你有数据和一个个例时，相信那个个例。」（杰夫·贝索斯）Tom：「完全正确。」

留给听众的话

1:10:48。

「我不认为做产品管理只有一种方式，我也不认为 AI 会以某一种方式重塑这个行业。」

这种更少但更资深的产品经理、拥有更多自主权的模式，对 Whatnot 来说是合适的。「我不假装也不预设这对整个行业都适用。」

「但我确实认为现在是从产品剧场里走出来，回归真正产品工作本质的最好时机。」（1:11:11）

这一点在哪儿都成立。即使仍然有人是很棒的团队管理者，满足感就来自带人、培养人、指导人，在很多地方这依然很有价值。

「所以假设我说的话至少有一半是错的，就像我过去说过的那些话里大概也有一半是不对的。」（1:11:26）

正经历职业生涯里最疯狂的一段时期。唯一能顺利走过去的办法就是看看别人怎么应对、学到了什么、什么对他们没用。「有共鸣的部分就吸收，那些听起来太夸张或者不适用你的部分就忽略掉。」

Elizabeth Stone：我们处在一个从风暴期走向规范期的过程里，现在就在那个风暴期。Lenny 记得刚开始写东西时，总有人问过去十年产品管理怎么变化，他说没变啊、基本还是老样子；现在感觉真的发生了巨大变化。不过核心的东西其实都还是那些。这些对话有用，就是让大家看到一个团队怎么运作，有哪些可以试试，可能对你不适用，「但这就是我们互相学习的方式。」

快问快答

1:12:47。

两、三本书。 《创业维艰》仍然觉得是写产品管理最好的一本书，涵盖了你必须经历、尝试、然后搞砸一大堆事情的那种广度。稍微偏一点：《穆什里克》沃伦写的《目标驱动的教会》。Twitch 的 CEO 艾玛·希尔以前基本上会确保大家都读这本书——对人们为什么会在情感上投入某件事、以及如何从一群人身上设计出情感投入的深刻剖析，本质上是一本九十年代写的教你怎么建教堂的指南。做任何形式的社区产品，绝对值得一读。虚构/奇幻：RF Kwong 的《巴别塔》。

电影或剧集。 Apple TV 上的《新城》。如果你喜欢《为了全人类》，它有点像那部的反面，但讲的是苏联那边。

最近喜欢的产品。 非常冷门：澳大利亚政府服务应用，尤其是新南威尔士州服务应用。点一下就能续驾照、过户，搞定拖慢生活的行政事务。最近回家办一堆生活行政事务，真的太好用了。

（岔开：澳大利亚太阳能让电力供应超过使用量，中午给人们免费供电，让人把电器放到中午用。大约二十年前一条法规：建新房子必须在屋顶装太阳能板。）

座右铭。 大学时的派对绝活是背吉卜林的《如果》。但如果真要诚实说的话：

「我会搞定的。……事实证明大多数事情没有人们想的那么难，我们总能解决的。……只要你愿意投入必要的时间、金钱、精力和心力，你几乎能解决任何问题。如果你不愿意，那它大概也不是什么大问题。」（1:15:47）

最近在 Whatnot 上买了什么。 一只活龙虾。卖家叫 efishcall，在圣地亚哥码头开海鲜店，渔船一靠岸就把刚下船的海鲜直播拍卖，第二天发货。加州雌龙虾，冰块、干冰、保温箱，UPS 次日达。

「所以这就是为什么 Agent 电商会很棒，但不会包揽一切。因为我那天早上可没打算买一只加州雌龙虾。」（1:16:59）

在哪找他 / 怎么帮忙。 Twitter/X：TDROBB，一半产品管理，一半吐槽勇士队。LinkedIn 放工作相关文章，「追求的是质量而不是数量」。欢迎关于 Whatnot 的使用感受和能做得更好的地方。

一直在找产品经理。讲那么多人申请、最后只招了几个，目的不是劝退，「更多是想说，产品经理这个岗位的泛滥，并不天然意味着这些人就具备咱们俩刚才聊了将近九十分钟的那种能力。」昨天刚招了两个人。搜 Whatnot jobs。圈子很小，也能直接联系在 Whatnot 工作的二十来个人里的某一个。现在招的方向挺多，支付是目前的重中之重，物流也是。「如果有人特别想来做隔夜送龙虾的未来，其实这里面有大量精细的产品工作可以做。」

来源

• 小宇宙：跨国串门儿计划 ep660 Twitter 前产品增长总监：不要为了招产品经理而招产品经理
• 原访谈：Lenny's Podcast — This CPO regrets that product management exists | Tom Verrilli (CPO of Whatnot)

本文时间点取自小宇宙官方文稿。节目中的个人判断、招聘数字、公司案例和组织做法，以嘉宾原话与 Whatnot 官方页面的最新信息为准，不能直接当作通用规则。

发现错误？想一起完善？ 在 GitHub 上编辑此页！
本页面贡献者：AI-PM Wiki Team
本页面的全部内容在 CC BY-SA 4.0 和 SATA 协议之条款下提供，附加条款亦可能应用