Tom Verrilli：这位 CPO 后悔产品管理存在
节目信息
- 节目：Lenny's Podcast
- 单集：This CPO regrets that product management exists | Tom Verrilli (CPO of Whatnot)
- 嘉宾：Tom Verrilli，Whatnot 首席产品官；曾任 Twitch 首席产品官、Twitter 产品增长负责人
- 核心命题：产品管理不是每个团队都要按比例配置的标配；真正稀缺的是能在宏观判断和微观执行之间来回切换、亲自推动决策的人。
- 发布时间：2026 年 8 月 2 日 20:32（中国标准时间）3
嘉宾背景
Tom Verrilli 现任 Whatnot 首席产品官，负责产品、设计与增长。此前他在 Twitch 长期担任首席产品官，负责消费者产品相关的产品、工程和应用科学；更早曾在 Twitter 担任高级产品领导职务。公开履历显示，他出生于悉尼，现居旧金山。4 5
节目精读
先给结论
Tom 所说的「我们后悔产品管理存在」，不是要取消 PM，而是拒绝把 PM 当成组织结构里的自动配件。只有当问题确实需要这项专门能力时，才配置 PM；其他情况下，工程师和设计师应该拥有足够上下文，自己做出好的产品判断。
这套做法的代价与收益都很具体：PM 不再固定绑定某个工程团队，而是围绕半年度最重要的问题重新分配；招聘时少看「对齐」和「干系人管理」话术，多看系统思维、用户理解、决策速度，以及能不能把问题真正做出来；AI 则让有判断力的 IC 更容易直接查数据、理解代码和推进工作。
观点与事实
- Whatnot 的产品团队从一个反直觉的前提出发：不要为了「有一个 PM」而招聘 PM。产品管理是一种通过反复实践形成的技能，不是只有 PM 才能拥有的资格证；如果工程和设计长期不做这些判断，他们的判断能力反而会萎缩。
- Tom 不否认 PM 在复杂问题上能提供杠杆。高质量 PM 的价值，是传播清晰度、吸收模糊性、帮助团队及时决策；问题在于把这项能力按人数比例普遍铺开，最后会让并不需要 PM 的团队也依赖 PM。
- Whatnot 当时约有 21 到 22 名 PM，按 Buyer、Seller、Trust and Risk 三个大方向松散组织。PM 会根据问题和优先级经常移动，而不是永久绑定某个团队。
- Whatnot 以六个月为规划周期。CEO、Tom 和其他高级负责人先定义未来六个月公司必须实现的结果与关键项目，再逐项寻找 DRI，也就是直接负责的人。这个人不一定是 PM，但通常会由技能匹配的 PM 负责。
- 两年里有 31,832 人申请 Whatnot 的产品经理岗位，最后只录用 1 人。Tom 认为招聘时越来越不重要的是反复讲「推动对齐」「管理干系人」；更重要的是能否同时进行系统级思考和细节级推进，能否把一个问题从模糊状态带到可验证、可交付的状态。
- Tom 反复追问实验结果为正或为负时团队要做什么。系统思维不是抽象地谈大局，而是在写文档或代码之前，先想清楚不同结果、规模放大和意外连锁反应会怎样改变策略。
- AI 不是这场组织变化的根本起点，但明显降低了个人贡献者完成 PM 类工作的成本。Tom 举例说，现在通过自然语言取数，可能几分钟就能完成过去需要一两周、由高级数据科学家协助完成的分析。
- 「招聘优秀的人，然后别妨碍他们」曾经是科技公司的文化口号，但 Tom 认为，仅靠放权并不够。高层如果真正接触一线事实、拥有足够判断力，自上而下做出快速决定，有时比让多个初级 PM 层层对齐更高效。
逐句全文翻译
00:00:00 - 00:05:39
Tom：随着科技公司不断扩大，某个时候，团队里出现了一种人力配置比例。每招聘六名工程师，就加一名设计师，再加一名产品经理。招这么多 PM，会把工程师和设计师当成需要被照看的孩子；他们完全有能力做出好决定，只是一直没有机会，因为总有 PM 在旁边替他们操心。
Lenny：你曾经在网上写过一段话，让很多人都很惊讶：Whatnot 的产品团队建立在一个相当简单的前提上，「我们后悔产品管理存在」。
Tom：这大概不是很多 CPO 会说的话。我们之所以用这样的说法，是为了强迫自己记住：不能只是为了招聘一个 PM 而招聘 PM。只有在确实存在非常具体的需求时，才应该招聘 PM。更好的做法，是不要默认每个地方都需要 PM。
Tom：如果一定要解释为什么产品管理应该是一项专门职能，唯一的理由是：它是一门技艺，而不是一种资格。你要靠亲自做来变得擅长，它是一块肌肉。但反过来，如果把工程师和设计师隔离在这些工作之外，他们的这块肌肉就会发育不足。
Lenny：他还写过一句很狠的话：过去两年，31,832 人申请 Whatnot 的产品经理岗位，我们只录用了 1 人。那他招聘时究竟看重什么？
Tom：我可以告诉你，什么东西正在明显降温：候选人在面试里花大量时间谈推动对齐、干系人管理。确实有一类 PM，他们的专长不是技术，也不是用户，而是政治。
Lenny：你非常看好转向 IC 工作，也就是 PM 离开那种庞大的组织管理世界。如果一个 PM 做得很成功，往往就会被升成总监。我们把所有 A 级选手都提拔到不再亲自做事的位置上。为什么不让梅西继续为你的球队踢球，而是总想着让青训学院慢慢培养人呢？
Lenny：今天的嘉宾是 Tom Verrilli。Tom 是 Whatnot 的首席产品官，曾长期担任 Twitch 的首席产品官，也曾在 Twitter 担任产品增长总监。我一直想邀请 Tom 来这个播客，已经很久了。Tom 对产品角色的未来有很多大胆判断，也有非常独特而重要的洞察，包括如今最优秀的 PM 在哪些方面做得不同，以及他现在为团队招聘产品人才时究竟在寻找什么。
Lenny：如果你还不了解 Whatnot，它是一个直播购物平台，是美国历史上增长最快的市场业务。节目中，Tom 还会分享自己如何在这个平台上从一位渔民手里买到一只新鲜龙虾。
广告旁白：在进入节目之前，别忘了去看看 Lenny's Product Pass dot com。Lenny 的 Newsletter 订阅者可以独家获得世界上最热门、制作最精美的 AI 产品的一年免费使用权。
Lenny：有了这些，下面请出 Tom Verrilli。Tom，非常感谢你来到节目，欢迎来到播客。
Tom：非常感谢，兄弟。看了这个节目这么多年之后，真的有点不真实。
Lenny：我懂。很多人来到节目时都会这么说。现在你也在这里了。有人第一次就直接实现了长期目标？
Tom：没错。
Lenny：我想从你在网上写过的一段话开始。这段话让很多人惊讶，我觉得也会让很多人惊讶。你是一位长期担任首席产品官的人，也是一位长期做产品的人，做出过很多非常成功的产品和团队。你写道：从最早开始，Whatnot 的产品团队就建立在一个相当简单的前提上，「我们后悔产品管理存在」。
Tom：是的，先生。
Lenny：这大概不是很多 CPO 会说的话。你为什么会有这样的感受？你是怎么走到这个结论的？这对团队又意味着什么？
Tom：我总是喜欢从历史讲起，因为这样才能理解事情是怎么变成今天这样的。说到产品管理，其中一件事是，如果你一路往回追，产品管理其实一开始并不存在，对吧？过去通常是业务方，往往是创始人或 CEO，直接和工程、设计沟通我们需要做什么，然后一起把它执行出来。
Tom：后来互联网业务的增长速度远远超过历史上的其他业务。于是，规模扩大意味着你必须把执行细节交给别人，或者相信别人能推导出下一步该做什么，因为一个人已经不可能同时坐在那里处理所有事情。
Tom：但如果回头看看大多数创业公司，看看这种演化是如何发生的，你会发现那原本是一种专门角色：有人负责把问题想清楚。通常，你对工程师只需要说更少的事情，不必把每个细节都描述出来；对设计师也一样，因为他们已经理解，或者他们曾经参与过这个过程。
Tom：而「科技公司需要一群专门负责决策的人」这个想法，与其说是纯粹的必然，不如说是更现代的组织职能。Whatnot 一直以来的想法是：如果工程和设计拥有做出好决定所需的上下文，如果他们和用户以及用户需求保持足够紧密的联系，他们其实完全可以做出 PM 会做的同样决定。
Tom：在我看来，如果要为产品管理成为专门职能找一个理由，那就是它是一门技艺，而不是一种资格。我的意思是，你要靠亲自做来变得擅长。它是一块肌肉，至少这是我能想到的最好说法。每一位私人教练都告诉过我，肌肉是靠重复训练练出来的。你做得越多，就越擅长。
Tom：但反过来，如果你越多地把工程师和设计师隔离在这些工作之外，他们的这块肌肉就越不发达。所以我认为，产品管理确实能发挥非常重要的作用。在某些必须做好的事情上，产品管理可以提供很大的杠杆。这样做，也能让设计和工程在各自的专业上发挥到最好。
Tom：但只要情况允许，最理想的状态其实是不安排产品经理，而是让设计和工程自己走过这些步骤，确保他们的判断肌肉得到充分训练。
Lenny：你觉得产品管理在早期非常有帮助、非常重要，后来经历了一段「PM 太多，而且很多 PM 并不出色」的时期，现在又回到了这样一个阶段：究竟什么才是优秀 PM，也许我们需要的 PM 更少？
Tom：是的。很有意思的是，如果你去问大多数工程师，甚至设计师，他们都会记得自己合作过的优秀 PM，主要是因为他们合作过太多糟糕的 PM。我并不是想用贬义的方式让谁泄气，但如果这个职能真的愿意严格自省，就应该问：普通 PM 是否真的为身边的人增加了很多价值？高质量的产品管理，能够传播清晰度、吸收模糊性，帮助人们及时做出决定；普通 PM 是否也能做到这一点？
Tom：我认为，这很大程度上源于科技公司扩张、招聘了大量工程师之后，某个时候出现了一种人力配置比例。我不想把责任归到 HR 头上，但某个时候，团队配置比例就这样出现了：每招聘六名工程师，就加一名设计师、一名 PM，再加一名工程经理，于是一个基本单元就形成了。
Tom：当你服务的是每天十亿级别的用户时，你手里会有很多工程师，于是突然之间，你也有了很多产品经理。但在大多数情况下，你可能根本不需要为通知基础设施配一名 PM，对吧？工程师完全有能力理解它是怎么工作的。
Tom：正如我们刚刚说的，招这么多 PM，会把工程师和设计师当成需要被照看的孩子。他们完全有能力做出好决定，只是一直没有机会，因为总有 PM 在旁边替他们操心。
广告旁白：本期节目由本季冠名赞助商 WorkOS 提供。OpenAI、Anthropic、Cursor、Vercel、Replit、Sierra、Clay，以及数百家其他优秀公司有什么共同点？它们都由 WorkOS 提供支持。
广告旁白：如果你正在为企业构建产品，就一定感受过集成单点登录、SCIM、RBAC、审计日志，以及大型公司要求的其他功能时的痛苦。WorkOS 把这些可能阻塞交易的要求变成可直接接入的 API，提供专为 B2B SaaS 打造的现代开发者平台。
广告旁白：我投资的每一家开始向高端市场扩张的创业公司，最后都会和 WorkOS 合作，因为他们是最好的。无论你是试图拿下第一家企业客户的种子期创业公司，还是正在全球扩张的独角兽，WorkOS 都是最快成为企业级产品、解除增长阻塞的路径。它基本上就是企业功能领域的 Stripe。
广告旁白：访问 WorkOS.com 开始使用，或者直接加入他们的 Slack 社区，那里有真正的工程师等着回答你的问题。WorkOS 通过让人愉快的 API、完整的文档和顺畅的开发者体验，帮助你更快构建产品。今天就去 WorkOS.com，让你的应用准备好服务企业客户。
Lenny：我想听听你对另一个问题的看法。人们采用这种思路时，最后经常会遇到：工程师和设计师未必想做 PM 的工作，因为 PM 的很多工作其实很烦，也不有趣。大家想象中最光鲜的部分可能是做决定，但它其实远没有人们以为的那么光鲜。
Tom：是的。
Lenny：尤其是公司规模变大以后，工程师要参加对齐会议、写文档、让所有人对齐、做记录，还有所有这些 PM 工作中的琐碎部分。同时，工程师还是想构建、想写代码，设计师还是想做设计。你怎么看他们可能根本不想做这些工作？
Tom：我认为，这正是专业化可以双向发挥作用的地方。让擅长做决定的人去做决定当然有用。一个人说「听着，我是基础设施负责人，我想认真思考规模问题，但我不想把时间花在争论对齐或把那些琐碎细节处理到位」——这完全合理。
Tom：不同技能之间也不一定能很好迁移。如果你非常擅长在脑中建立基础设施应该如何扩展的大型心智模型，你可能并不具备倾听客户、理解核心问题的技能。你需要分辨客户真正的问题，而不是只重复他们说出来的那个表面需求。这种能力同样是随着时间训练出来的。
Tom：所以我说「我们后悔产品管理存在」，并不是说我们不希望 PM 做这些事。我们知道，在某些情况下，你确实需要帮助其他职能完成专业化。但我们用这样的说法，是为了强迫自己记住：不能只是为了招聘 PM 而招聘 PM。只有在确实存在非常具体的需求时，才招聘 PM。
Tom：这还要求你围绕这个原则建立组织文化。比如，我们说「我们后悔产品管理存在」，那么每次写关于如何发布产品、我们正在做什么的文档时，都会明确：任何人都可以提出变化；新产品开发的 DRI 可以是工程师，也可以是设计师。但所有人都必须经过同样的产品评审流程。你必须真正把工作做完，因为这是真实的工作。
Tom：如果有人不想做这件事，或者他们想做别的事情，我们总可以重新调动产品管理。我们不会把 PM 映射到团队上，默认某个 PM 永远负责某个团队；我们更倾向于把 PM 映射到问题或核心项目上。这意味着，有时一个工程团队有大量持续进行的产品工作，却可能在一整年里都没有专门绑定的 PM。
Lenny：我很喜欢这一点。我们经常听到偏工程导向的产品这样说，比如开发者工具公司会说「我们不需要 PM，为什么需要 PM？」这通常来自 Linear 这类公司，或者来自构建开发者工具的公司。在那些地方，你能理解为什么工程师就足够了。
Lenny：但从你的角度听到这些很有意思，因为你构建过非常面向消费者的产品，而这类产品需要你认为很强的 PM 技能。所以你说 PM 在构建优秀产品时没有人们想象的那么必要，这件事从你口中说出来，分量更重。
Tom：我认为这里有两个推动因素。我现在谈的很多事情，都是我随着时间学到的。我在 Twitch 待了七年，然后才来到 Whatnot。那是一种亚马逊式的两披萨团队，按比例驱动。我在 Twitter 开始自己的硅谷经历时，情况也很类似：总是有非常紧密的对齐。天啊，那时候有太多对齐会议了。你可以想象为什么工程师不想参加。
Tom：随着时间推移，我逐渐明白，其中很大一部分只是因为管理层看不见正在发生什么。于是你招聘更多人，建立更多层级，系统催生系统。我认为真正发生变化的是，人们开始意识到，获得杠杆的方式不再只有一种：不是只能在自己下面招聘更多 PM，然后让自己变得更资深。
Tom：我们现在对业务的理解更好了，也比任何时候都更容易直接和代码库对话、直接和工程师沟通。所以你不必再进入那种「一切都要规模化」的模式。我不认为消费业务和企业业务现在还是分界点。更重要的是组织自身的文化。
Lenny：在你看来，这种转变有多少是 AI 驱动的？因为现在 AI 让非 PM 也能做 PM 类的工作。有多少是 AI 之前就已经发生的？之后我还想谈谈这在你们团队里究竟是什么样子，但先问这个问题。
Tom：我不认为它明确是因为 AI 才发生的，但我确实认为 AI 让这件事容易了很多。
Tom：我觉得有两件事。第一，AI 确实意味着 IC 现在拥有巨大的杠杆。我不知道别人是不是也有同感，但前几天我和几位高级负责人聊天时，我们都觉得，现在借助 AI 能做的事情太多了，以至于你会对自己还没有做的事情感到压力，因为你知道，只要再腾出几个小时，就能推进大量工作。
Tom：如果你已经磨练出很好的判断力，借助 AI 工具快速推进就容易多了。现在你可以通过 Hex 的对话线程取数；这件事放在 2017 年，可能要由一名亚马逊 L7 级别的数据科学家花一周、两周才能完成。
Tom：所以，只要你被赋予权限，而且判断力足够好，就可以非常快地做出决定，让团队继续向前走。这非常了不起。
Tom：但除了 AI，我认为还有很多比例化组织带来的文化推动。比如「招聘优秀的人，然后别妨碍他们」、自下而上的路线图，以及所有类似的东西。过去一段时间，科技行业的文化确实发生了一点变化：自上而下其实相当好，因为高层通常能快速做决定，消除所有对齐争论。他们可能比大多数人拥有更多宏观上下文。
Tom：只要这些高层确实接触一线事实，而且判断力足够好，让高级领导参与很多这类决定，其实是一种非常高效的模式。这意味着，不只是工具让他们更高效；你还可以让一名非常资深的 PM 覆盖更多事情，而且比安排三名相对初级的 PM 更高效。
Tom：当然，AI 又让这一切容易了很多。回到最初那个大前提，我想明确一点：「后悔产品管理存在」并不是说我们不需要 PM，也不是说 PM 没有用。它的意思是：不要默认每个地方都需要 PM。
Tom：让其他职能去做 PM 的工作是好事。PM 也会拿走其他人亲自做这些事情的重复训练机会。如果他们能做这些工作，就能更好地执行，构建更好的产品。
Tom：对 PM 来说，与其被明确绑定到某个团队，不如围绕不同问题移动。这样他们会获得更多、更好的重复训练，会锻炼到更多不同的肌肉群，而不是说「我属于某个工程经理负责的团队」。
Lenny：那我们沿着这条线继续。Whatnot 的团队是什么样的？PM、工程、设计组成的团队，在这种世界观下是什么样的组织？
Tom：我们刚刚超过 20 名 PM。现在大楼里大概有 21、22 名 PM。对于关注 Whatnot 发展轨迹的人来说，考虑到卖家创造的 GMV 规模，这个数量相当小。我们大致松散地分成三组：买家、卖家，以及我们所说的信任与风险。后者负责平台标准、支付、安全之类的事情。
00:21:18 - 00:31:41
Tom：你可以把所有可能出错的地方都想一遍，理解规模扩大后哪里会断、可能发生什么，然后还是继续往前走。因为如果你已经想过规模化之后可能发生的所有事情，大概就能提前处理其中一大部分。
Tom：所以我很喜欢 Elizabeth 的那句话，但我的建议只是：做一次心智演练。把事情真正大规模采用之后会怎样、如果真的发生了会怎样、如果出了问题会是什么问题，都在脑中走一遍。你不需要把所有问题都解决，但你必须把它们都想一遍；这样最后解决的问题会比你原本以为的更多。
Lenny：我喜欢这个说法。也就是说，不要只关注这个实验会不会有影响力，还要想清楚接下来会发生什么，如果这个判断是真的，下一步又会发生什么。尤其是在高速增长的环境里，你找的不是 Statsig 上 5% 的小胜利，而是能彻底改变业务、并且随着时间产生复利效应的东西。所以你必须把那会是什么想清楚。
Lenny：你还提到 PM 的工作方式正在发生另一个变化，而且你对此非常兴奋：转向 IC 工作。PM 正在离开那种庞大的组织管理世界，回到真正做事。谈谈这对产品管理角色意味着什么。
Tom：我刚才稍微提过。在那种按比例配置人员的世界里，如果你作为 PM 做得非常成功，就会被升成总监。然后突然之间，大家会告诉你不要再亲自做事，你的目标只是指导和辅导。于是我们把所有 A 级选手都提拔到不再做事的位置上。他们把全部时间花在对齐上，花在辅导上，花在辅导团队、调整团队工作上。
Tom：最后就会形成一种来回摇摆的开发流程：有人做了一大堆工作，拿去评审，被告知不行，然后又回去改，再回来评审。你能看到我身上的伤疤了。我们团队的情况是，当然也有管理者；整个团队里大概有四五个人负责管理其他 PM。但他们所有人都会把 90% 以上的时间花在 IC 工作上。我自己现在大概也有 50% 的时间在做 IC 工作。
Tom：我认为这样有几个真正的优势。第一个，如果你是做产品很多年的人，已经有十几年、甚至十五年的构建经验，那么希望到了这个阶段，你对于什么可能奏效的直觉已经磨得相当好了。你可以比别人更快做决定，也可以非常快地产生真正的影响。对组织来说，有这样一个人非常好，总比把问题拆给三层人、再让几名 PM 对齐、让不同工程团队反复争论要好。
Tom：第二件事是，它有两种方式产生杠杆。理论上，一名 VP 可以承担多名相对初级 PM 的工作量，因为正如我说的，他们效率更高。这意味着，在任意时刻，你能看到更完整的棋盘，因此更有可能对问题做出直觉上正确的决定，比如发现算法应该如何调整、怎样处理发货慢的卖家。这是电商里永远存在的问题。
Tom：如果你同时在思考如何管理发货慢的卖家，以及发现机制的力量，你无论从哪个角度出发，都能做出正确的决定。
Tom：我记得 Twitch 有很长一段时间一直被一个问题困扰，而我可能比任何人都更应该为此负责：发现团队和广告团队总是在争夺曝光。广告应该放在信息流的什么位置？对发现指标有什么影响？对广告收入有什么影响？
Tom：我到 Twitch 后做的第一件事之一，就是把广告放进发现环节，并确保同一个 PM 同时对两边负责。这样，他自然会做出取舍：目标是信息流创造的 GMV，其中一部分来自自然流量，另一部分来自售出的付费替代流量。当同一个人同时负责多个部分时，他会自然地让这些部分对齐，于是你能省掉好几个月、好几个月、好几个月的来回拉扯，也能减少把公司利益变成个人职业利益的那种政治。
Tom：所以，让 VP 大部分时间处在 IC 世界里，让总监大部分时间做 IC 工作，甚至让我自己也必须面对 IC 工作，会让所有人都和真实发生在一线的事情保持连接，而不是只接触评审里看起来是真的东西。这样也更容易尽早做出直觉上正确的决定。为什么不让梅西为你的球队踢球，而是总想着让青训学院慢慢培养人？
Lenny：我很喜欢这个观点。你说 PM 的 IC 工作时，具体指什么？是发布代码、构建东西，还是管理团队、负责路线图、写战略文档？
Tom：想象一下是后面那一类。最简短的答案是：为了最有效地发布产品，所需要做的一切。我的确在 Whatnot 发布过生产代码吗？是的。我认为那是我时间的最佳用法吗？其实不是。
Tom：我敢肯定，私下里一定有人重写了我大部分代码，确保 lint 正确、国际化正常，以及软件工程几十年积累下来的所有细节都没问题，而我和 Claude Code 没有把这些做好。
Tom：但我认为，起点是：你是否真的在看支持工单？你知不知道客户遇到了哪些问题？你有没有自己把所有数据拉出来，真正理解数据？你有没有和工程、设计坐在一起？你有没有直接查询代码库，理解系统是怎么工作的，然后写出规格说明？你接下来是否会在一周后主持一次站会？
Tom：我认为这些都是核心的个人 IC 工作。有很多人沿着产品管理的阶梯一路爬升，成为 VP，然后觉得回去做 IC 并不令人兴奋。有些人显然像你一样喜欢这件事，享受这件事；但很多人会说：「我以为自己已经结束了这段经历。我可以只通过别人做事，可以只思考宏观问题。」你怎么看？你会对这类人说什么？
Tom：我认为，行业里仍然有大量组织认为那种方式非常有价值，他们也会继续那样做。我的招聘对象通常是这样的人：他们会说，「天啊，我以前喜欢产品管理，但我已经受够了坐在对齐会议里。」然后我会去找 CPO 和产品 VP，对他们说：「你难道不想念真正做事的感觉吗？你想不想回来？」
Tom：我们也应该承认，整个行业会出现分化。有些组织已经足够大，也许让所有人都亲自动手并不合适。我之前说过，采用这种工作方式必须有匹配的文化。你得生活在这样一个环境里：大家的期待是，不要只讨论，我们直接去把事情做了。
Tom：很多时候，每家创业公司都是创始人的映射。创始人怎么思考、想怎样经营组织，组织自然就会呈现出什么样子。但我发现，在很多情况下，你去和一个在 Meta 做了五六年高级总监的人聊天，他过去把全部时间花在对齐会议里，却非常想念真正和客户沟通、和工程师沟通、把东西发布出去的感觉。
Lenny：这让我想到，我猜你也看过那份名单：很多首席技术官后来去了 Anthropic，只做工程师。我刚才说话时把名单找出来了。Workday 的 CTO 现在只是 Anthropic 的技术员工；Instagram 的 CTO、Box 的 CTO、Super.com 的 CTO，现在也都只是 Anthropic 的工程师。
Tom：是的，是的。我最大的愿望，就是 Whatnot 的产品人才储备最终也能变成这样：这些人有很强的技能、很深的理解，最后都回来作为 IC 构建东西。
Lenny：那这条路径的薪酬怎么样？很多人的梦想是一路升到 VP，赚几百万美元。有没有可能既做到这些，又保持 IC 身份？
Tom：我其实认为这样更容易。这是个大胆的说法，但你可以把五名 L5 向一名 L7 汇报、四名 L7 再向一名 VP 汇报所需要的薪酬加起来，然后看看整个产品组织的总薪酬，再反过来问：如果我只有三个人呢？为什么不能给他们每个人都支付 D 级到 VP 级别的薪酬，尤其是当他们产生的影响力已经达到那个层级？为什么不行？
Lenny：为了彻底理解这件事为什么会发生、为什么应该发生，我听到的原因有好几种。一个原因是 AI 让它成为可能，这很好，而且时机正好。除此之外，还有哪些动力？是产品最后会变得更好？还是因为人数更少？
Tom：我当然认为产品最后会变得更好。很长时间以来，人们一直告诉我们：「这不可能扩展。领导层不可能一直亲自参与正在发生的事情，你最终会需要招聘更多层级。」但我们发现，这其实不是真的。
Tom：它要求你训练另一块肌肉。你必须努力确保自己真正理解一线事实。我们经常举一个例子：在增长会议上，有人会说，「对，但那是欺诈。」你转过身问：「你怎么知道那是欺诈？」对方说：「数据集里把它标成了欺诈。」你再问：「你知道它是怎么被标记的吗？」对方说：「我猜是运营团队里有人标的。」你再问：「你知道他们的标准作业流程吗？知道他们具体如何标记吗？」对方说：「不知道。」
Tom：那你其实并不知道它是欺诈。如果你这样追问一位经验丰富的产品总监，他会说：「你说得有道理。我不知道，我去查清楚。」然后你通常会强化代理人正在使用的数据标注系统，因为突然有一个很聪明、很投入的人开始认真理解这件事，并帮助改进它。
Tom：所以，关键是形成这样的态度：我们要少做一些事情，但把它们做到极致；我们要推动最优秀的人深入每一个细节。这意味着，你会在前进过程中修复很多问题，而不是不断做出大量权衡取舍。
Tom：否则，增长太容易掩盖所有罪过。业务变大了，规模扩张了，最后每个人都只在平均值上工作。文化上，你必须真正下定决心：像我有时说的那样，少做几件事，但把它们整个做扎实。向 Ron Swanson 致意。然后推动最优秀的人真正深入细节。
Tom：随着时间推移，你会发现这样做反而更高效，因为你第一次就真正理解了系统如何运行，也能做出最好的决定。再加上 AI，这一切都拥有巨大的杠杆。我作为初级 PM 时，不知道花了多少时间去问工程师某件事有多难，打断他们真正的开发速度，只是为了帮助自己规划未来工作。
00:31:41 - 00:42:04
Tom：现在我可以坐下来和 Claude 对话，大致了解工作量估算。我可以说：「我感觉新用户打开应用时，似乎有一堆弹窗撞在一起。我们把信息流加载出来，告诉我谁在什么顺序、什么时间看到什么，以及这个东西什么时候触发。」你很快就能得到答案。
Tom：如果一个人有足够的任职时间，也有足够多的重复训练，他看到这些之后可以直接说：「这很糟糕，我们改一下这些内容的排序。」我现在只要让一个有权限的人去做决定，就省掉了一次启动会、一次对齐会、一周写 PRD 的时间，以及实验时间，所有这些都省下来了。
Lenny：回到那些正在找 PM 工作的人。先不谈新人，谈那些已经是管理者、已经很资深，但现在看到市场发生巨大变化的人。大家现在经常说，你需要适应重新回到 IC，放下漂亮的头衔。对于正在找工作、找得很辛苦的人，你还有什么建议？
Tom：我的建议是，在你现在的岗位里就开始做 IC 工作。回到基础，确保自己承担一些实际工作。我认为，保持这些肌肉的良好状态很重要。你也可以从内部推动这些事情。我敢打赌，如果你把这种生产力带回现在的角色，既能帮助你留在现在的位置，也能帮助你走向下一站。
Tom：网上现在当然有很多讨论，说 PM 现在都要变成工程师。我认为这很好，这是一块值得磨练的肌肉。正如我说的，我曾经把一些生产代码推上线，因为我想通过这个过程理解它。但在真正开始构建东西之前，更重要的是：你能多快重新找回正确界定问题的能力，理解问题，定义什么叫做好，并利用你所在位置的规模和视野，看到更多东西，给工作带来更多东西。
Tom：我想，大多数做过总监及以上岗位的人都知道那种痛苦：你坐在那里，看着一个初级 PM 围绕同一个 PRD 来回摇摆，不断拿去评审，而你其实知道答案是什么。我们不知道从什么时候开始，管理方式变成了把马牵到水边，却不真正帮助他理解答案，然后继续往前走。
Tom：我们的辅导方式里，有些东西可以找回来：相对快速地帮助一个人理解什么叫做好，而不是让他陷入没完没了的来回评审。
Lenny：你提到 PM 不一定要把代码推到生产环境，这一点我非常同意。最近我在一个之前的播客嘉宾那里改变了看法：如果 PM 不坐在那里试图把东西推到生产环境，反而拥有更大的杠杆。帮助团队更好、更快地发布，确保发布的东西质量更高，比 PM 自己坐在那里发布东西更好地利用了时间。
Tom：听起来可能很傻，但我花在 Git 提交以及所有工程师已经习以为常的细节上的时间，远远多于真正弄清楚问题是什么、并且把它描述清楚所需要的时间。所以，尝试亲自做一些事情当然是很好的实践。
Tom：比如，我不想只根据别人告诉我的话来判断我们的开发工具是不是变容易了。我会自己去试，然后说：「对，这比我上次做的时候容易。」但我认为，只要理解代码库，再和真正能把事情执行好的人沟通，你就可以走得很远。否则，你会掉进一千个经典陷阱，而那些陷阱是每个工程师在 L4 阶段都已经学会如何避开的。
Lenny：沿着这条线再问一点：AI 具体如何帮助你和团队更快推进、更有生产力？除了原型制作，这是 AI 对 PM 和产品团队最明显的好处。还有什么？有哪些事情能进入前三名，让你觉得「这真的解锁了我们的生产力，也提升了工作质量」？
Tom：第一名毫无疑问是数据科学。我们在 Whatnot 内部使用 Hex 对话线程。我相信还有其他类似产品，但现在几乎很难回忆起，在有这类工具之前，作为 PM 是怎么工作的。
Tom：过去，你可以开始拉取非常细致的数据群组，找到一个你听说过问题的具体用户，拉日志，准确理解这个用户做了什么、看到了什么，再问有多少其他用户和他相似、可能产生什么影响。突然之间，你就能非常快地建立有意义的敏感性模型，或者预测可能发生什么，甚至运行回归模型。这非常、非常、非常强大。
Tom：我们发现的另一个好处，是它让我们发布东西时快得多。你能比过去更快地发现回归问题，以及两个产品混在一起后产生的奇怪连锁反应。在非常庞大、非常复杂的系统里，这通常就是发布节奏被拖慢的原因。但如果你构建了正确的 AI 工具，就能非常快地发现回归问题，基本上让大家直接加速。
Tom：我不知道数据科学的未来会是什么样，但作为一名产品经理，我过去一年和数据科学家交流的时间，比职业生涯任何时候都少；与此同时，我花在数据上、花在真正理解产品如何运行上的时间，可能是职业生涯任何时候的十倍。所以我认为，第一点非常有力。
Tom：第二点我之前已经提到过：别再去打扰工程师问代码库是怎么工作的，直接和 Claude 对话，自己把它理解清楚。这非常有帮助。
Tom：我职业生涯早期常说，目标始终是理解系统的方框和连线：哪个系统驱动哪个东西。现在，没有理由不理解这些，甚至没有理由不理解更细致的一层。
Tom：还有一点可能很具体地适用于 Whatnot，所以我不知道它对所有人是否有帮助。我很幸运，职业生涯里已经做了十年的实时产品。把产品发布出去，然后看着客户使用它、看着客户摸索它，一直很有意思。
Tom：我想，最近很多人通过 Listen Labs 以及同一批产品获得了观察用户使用产品的体验。但我一直可以坐在那里，看着用户第一次使用一个东西，观察他们如何跨过新用户理解上的鸿沟。
Tom：现在很多 AI 工具很酷的一点是，当用户描述「我遇到了一个问题」时，你可以实时看着代码库，判断这到底是正在发生的 bug，还是用户对产品的理解出现了偏差，也就是产品没有按照预期工作。
Tom：突然之间，你手里有了一段用户使用产品的视频记录，同时还能实时分析代码库。你可以通过 AI 和代码库对话，理解真实发生了什么。这就像把反馈闭环开到了加速模式：客户侧发生了什么、代码侧发生了什么、可观测性侧发生了什么，你都能像一个实时观看者一样看到。
Lenny：听起来既棒又让人压力很大。构建这种实时产品一定很刺激。我想到 Netflix，他们现在也在投入实时业务。对他们来说，那是一个多么大的转变，而你已经做了十年。我知道规模不同，但这确实很特别。
Tom：说实话，我加入 Whatnot 的第二周，就记得自己坐在一个房间里观察一件事。对不了解 Whatnot 的人来说，它是一种电商平台，主要是拍卖平台，也是直播电商平台。拍卖有多种运行方式，其中一种叫突然死亡式拍卖：计时器结束，拍卖就结束。另一种更传统：有人在最后五秒出价，计时器就重新增加十秒。
Tom：卖家可以选择自己想要的模式。我当时看到一位卖家说：「这些拍卖花的时间太长了。我希望七秒计时器其实只有三秒，因为我想卖掉更多产品。」我看到办公室里的两名工程师互相看了一眼，说：「这和我们现在的设置冲突，但完全可以做到。」
Tom：于是他们实时更新了设置，然后进入那场直播的聊天区，只说了一句：「刷新你的应用。」接着，砰的一下，系统就按新的方式运行了。我当时想：「好，我和我的人待在一起，我来对地方了。」因为在直播环境里，你能获得的就是这种响应速度。
Tom：显然，AI 也意味着很多人很容易承担这类工作。我不是说我会用那种方式碰生产代码，因为那是个灾难性的想法；但对于有资格这么做的人来说，这是一件很棒的事。
Lenny：确实很酷。
广告旁白：本期节目由 Mercury 赞助。Mercury 是深受 30 多万名创业者喜爱的、彻底不同的银行服务，现在还推出了 Command。
广告旁白：我使用 Mercury 已经六年多了，从来没有想过离开。Mercury 基本上就是由产品人而不是银行家打造银行服务的结果。他们让开具发票、转移资金、为团队成员设置虚拟卡变得如此简单，甚至可以说很有趣。
广告旁白：你的银行有 API、原生支持终端的 CLI，或者可以使用 AI 的 MCP 服务器吗？我想应该没有。Mercury 最近推出了 Command，这是直接构建在 Mercury 里的对话式界面，可以充当你的财务运营人员。
广告旁白：我一直用 Command 转账、查看自己在哪些类别上花钱最多、分析现金流。就在今天，我还用它查了一位特定赞助商在过去一年给我带来了多少收入。我只需要问：「过去一年，我从 X 赚了多少钱？」十秒后就能得到答案。真的太酷了。
广告旁白：访问 mercury.com 了解更多，并在几分钟内在线申请。Mercury 是一家金融科技公司，不是 FDIC 承保的银行。银行服务由 Choice Financial Group 和 Column N.A. 提供，它们都是 FDIC 成员机构。
Lenny：回到刚才的数据科学这个话题。我有一位朋友是数据科学家，他说，正因为这件事，数据科学家的日子很难过。再具体一点：过去，他们的时间通常是用来做一些数据分析、处理数据，然后回来告诉你结果，并且说自己对结论有多大把握。
Tom：现在，他们的时间基本变成了查看非数据科学家做的半吊子数据科学工作，然后被问：「你帮我看看，这对不对？」结果一半时间都是错的。于是他们会想：「那我现在到底是干什么的？这太糟糕了。」
Lenny：我对此非常有同理心，因为我确实见过这种情况。这也再次说明，为什么少一些、但更资深的 PM 会有帮助：他们做过更多次这样的工作，也更理解其中的细节。但我还认为，很多时候……
00:42:04 - 00:52:56
Tom：这种不清晰，也来自很多组织过去没有在数据工程、数据结构、良好的数据标注上投入足够多。问题不只是分类体系是否正确，还包括你是否真正理解自己的数据系统和结构是否搭得足够好。
Tom：我们发现，很多最优秀的数据科学家正在推动这件事：我们是否正确更新了追踪和归因的全部方式，让人们更不容易误解这些数据？使用 AI 工具寻找一条数据，就像使用 AI 工具写代码一样，并不会免除你确保分析质量、代码质量的责任。它只是会被那些本来就倾向于这样工作的人拿来放大能力。
Lenny：把这些职能放在一起看：数据科学、用户研究、设计、工程、PM。到目前为止，我听到的是，我们可能需要更少的 PM，也可能需要更少的数据科学家。还有没有哪些角色，你觉得需求会下降？有没有哪些角色会明显上升，让你觉得「这种人我们需要更多」？
Tom：有意思的是，正如我说的，我已经有一段时间没和数据科学家交流了。但我们当然还招了很多数据科学家，因为我认为追踪、归因和度量仍然非常有力量。
Tom：我认为，「需要更少」的另一面是：用更少的人完成同样的产出。它不一定意味着宏观意义上的总人数更少。因为如果你能使用这些系统，你就能更快增长、构建更多东西、承担更多工作。所以如果最后我们得到的是净减少的人数，我反而会感到意外。更准确地说，应该是以更少的人产生同等的客户影响。
Tom：我认为未来这些职能中会越来越多的一类人，是某种技术负责人。我不记得过去大家用的准确称呼了，但大致是混合型工程经理：带着一个非常小的团队，亲自推动事情。
Tom：正如我们会说，尝试的成本已经下降了；孵化小团队、让他们待在角落里，专门去尝试构建一件事，也变得更便宜、更有杠杆。它不完全是原型制作，而是去挑战那些历史上被认为太难的事情。
Tom：所以，姑且称之为「轻量工程经理」吧，我认为这种角色一定会越来越多。它不完全是技术员工，虽然那种岗位当然也很好；但它也不是完整的工程经理角色。
Lenny：把这部分对话收束一下：现在有一种趋势，大家都在构建东西。PM 会多发布一点，变得更像工程师；工程师也会承担更多 PM 工作。未来几年，产品团队大体上会变成什么样？还会是 PM、工程师、设计师，某处再加上数据科学家吗？你想象中的标准产品团队是什么样？
Tom：这是个好问题。我不知道自己是否了解所有地方会变成什么样，但在 Whatnot，我认为它大概仍然会和过去很像。确实有理由配置专门的设计师、专门的工程师、专门的产品管理人员。
Tom：我认为，这些非常具体的团队会主要保留给明确的项目，或者那些我们高度确定、非常坚信必须解决的问题；也可能是我们高度确信已经找到路径、希望取得实质进展的事情。
Tom：在这些团队的边缘，会有更多自由空间。任何人都可以说：「我相当确定，自己可以对这个东西做出有意义的改进。」你是设计师、工程师、PM，还是数据科学家并不重要。周五下午，如果你无法集中精力继续写手头的东西，但你很确定自己可以去修好另一个问题，那就去做。
Tom：所以，正式的组织结构可能不会发生剧烈变形，但我确实认为，熟悉客户问题、熟悉代码库、理解部分宏观上下文的人，会获得更多授权，去做越来越多的事情。
Lenny：两年半前，你发过一篇文章，标题大意是「为什么 PM 是科技行业里最适合在 AI 世界中繁荣的角色」。虽然我们的对话一开始说的是，我们应该生活在一个「后悔 PM 存在」的世界里，但我觉得我们其实同意：最重要、最有价值的技能，不管是 PM、工程师还是设计师在做，都是很像 PM 的技能。
Lenny：你在文章里举了几个例子：识别应该构建什么；提炼并沟通需求；从所有人的想法里挑出投资回报率最高的机会；给设计反馈以提升影响；制定进入市场的策略；理解业务战略。对我来说，这些就是 PM 在做的事情，而且它们似乎越来越重要。你是否同意，随着 AI 接手构建工作，PM 类技能反而变得最有价值？
Tom：我完全同意。而且我要夸你把证据带来了，还带了时间戳。做得好。
Tom：我唯一想补充的是，过去五年里，我们奖励 PM 的东西，未必就是这些核心 PM 技能，反而经常是讲故事、对齐和战略。所以你说得完全正确：我能不能真正理解客户？我能不能真正理解业务？我能不能真正理解技术？我能不能把这三者翻译在一起，达到最优效率？
Tom：当做事变便宜、尝试变便宜时，这就是杠杆所在。因此我完全同意，产品技能可能是最耐用的技能。
Tom：但我想补充的是，有很多人拥有 PM 这个头衔，却在过去五年里没有花太多时间锻炼这些技能，反而变得很擅长向领导沟通框架。所以，作为一个职能，我们需要把自己拉回那些核心工作。
Lenny：Marty Kagan 把这叫作产品剧场。很多人只是做着 PM 应该做的那些表面动作。听着，我也对此有责任。我们奖励这种行为太久了，所以很多人的核心能力就是产品剧场，这并不让我意外。但我认为，现在已经没有太多地方可以藏在剧场里了。
Lenny：回到那 32,000 多名申请者。我猜，其中很多人只是认为自己是 PM，或者有 PM 这个头衔，但其实没有你描述的那些能力。他们只关注对齐、写文档、开会之类的事情，而不是亲自构建、理解构建一个成功产品需要什么。
Tom：是的。Lenny，在产品面试里表现得非常好，拿到 case study 之后却完全不同的人，数量很多。Whatnot 无论招聘什么岗位，每个被录用的人都必须做一次真正的实操 case study。
Tom：但有些人展示时表现得极其出色，你给他们一个问题、一组数据，让他们回来讲自己的判断，然后要求他们口头捍卫这个判断。你会看到，有些人很擅长产品剧场，却不擅长具体问题；他们的思考很快就开始衰减。这一点非常说明问题。
Lenny：那我们超越招聘这一步。假设你已经招到了一个人，你学到过哪些方法，能让你从这些人身上获得最大的价值？你提到过一个反直觉的看法：你并不认同「招优秀的人，然后别妨碍他们」。我想听你展开，也想知道你还学到了哪些构建世界级产品团队的要素。
Tom：我得说，生活需要细节。「招人，然后别妨碍他们」是错的。
Tom：这句话后来变成了一种宏观口号：让他们自己决定路线图，让他们自己找出问题，把所有事情完全下放。但真实答案显然是，你招的人越优秀，就越可以完全相信他们知道自己在做什么。
Tom：不过，我们更倾向于生活在「验证之后再信任」的世界里，而不是「完全信任」，甚至也不是简单的「信任但验证」。我可能比任何一位直接下属都更适合理解 Whatnot 的不同系统如何拼在一起：买家、卖家、信任与风险。但他们几乎一定比我更适合理解其中任何一个具体功能的细节。
Tom：如果今天有人考我 Whatnot 发现模型里的全部权重，我相对于那支团队里的工程师、相对于那支团队里的 PM，肯定会答错。
Tom：但我有责任随着时间推移学会并理解这些东西，因为我要求他们做决定，也在评估他们正在做的事情。真正和这些团队并肩工作、深入一线、一起解决问题，力量非常大。
Tom：我加入 Whatnot 之后很早就看到，我们的创始人兼 CEO Grant 会这样做：他坐在评审里说：「我觉得这不对。」然后停一下，说：「我今天剩下的时间都空出来，我们坐下来把它弄清楚。」
Tom：接着，他真的会和团队坐在一起。现在有 AI 数据工具，这件事更容易了。我们把支持工单调出来，把代码调出来，逐行检查数据，理解真实发生了什么，然后在现场做出决定。
Tom：这让他非常了解当前发生的事情，也在文化上给团队定了调：我们只是想找到事实。这会让事情变成「我们对你们」的关系。评审曾经有一段时间变得像是在争取一个「是」。PM 唯一想做的，是拿到绿灯，好回去告诉工程师：「我有一些可信度，我能让 CPO 批准我们正在构建的东西。」
Tom：但真正的理念应该是，我们只是想找出正确答案。理论上，每个人都希望我们找到正确答案。我们用规划让全公司对必须解决的重点达成一致，但规划主要是资源讨论：如果我们挑对问题、把它们排好优先级，我最终最需要负责的，就是确保正确的资源放在正确的位置上。
Tom：但如果我只是把任务交给团队去想办法，却没有定期和他们深入到「这个东西究竟是怎么工作的」的程度，我不知道那些资源是不是放对了位置。
Tom：我们的推荐机制是怎么工作的？具体来说，欺诈系统可能依据什么逻辑，让一条推荐失效？是根据地址信号吗？地址信号是怎么计算的？这是经过 Google 归一化的东西，还是让人输入的自由文本？
00:52:56 - 01:03:07
Tom：如果你不把自己逼到一线，和 IC 工程师、IC 设计师、IC PM 坐在一起，你其实不知道这些东西。因此，没有微观细节，你就无法做出好的宏观决定。
Tom：所以我越来越要求自己成为 T 型的人：需要时可以非常、非常深入，但大多数时候要横向了解各个部分。单纯把人招进来，然后不再问问题，把所有细节都下放，并不是从组织里获得最大产出的最成功模式。
Lenny：如果创始人非常懂产品，CPO 通常是个很有挑战的角色，因为你处在一个观点强烈的创始人和负责构建产品的团队之间。你发现怎样才能创造一个让自己在这个位置上感到舒服的环境？
Tom：有意思的是，这几乎贯穿了我的职业生涯。我连续为三位创始人工作，他们都非常懂产品。在 Whatnot，我面对的是两位创始人，这其实是件幸运的事。
Tom：一般来说，如果 Grant 或 Logan，也就是我们的创始人，正在负责某件事，我尽量不重复参与。多加一层的优势是什么？团队里有位 PM 开玩笑说，这叫「两个爸爸的问题」：两个人发出相互冲突的指令，或者一个人要求评审，你花了很多时间准备，拿给我看，回去之后却又变成了另一件事。
Tom：所以我的第一原则是，如果 Grant 或 Logan 在负责某件事，我会确认他们在关注它、对它负责，然后退出。可能会有很长一段时间，我团队里一半的人都在做某件事，但我说不出他们每天做到哪一步，因为那件事在 Grant 或 Logan 手里。这完全没问题。我不需要掌握他们正在做的所有事情；我们只需要确保有人在把标准往上抬。
Tom：第二件事是，如果你是创始人主导公司的产品负责人，你必须明白：这不是你的公司，是他们的公司。你要找到合适的相处节奏：你可以问「你愿意听听这件事的反馈吗？」也可以问「你已经做决定了吗？」或者「你愿意让我推动一下吗？」然后和他们一起找到合作的节奏。
Tom：创始人主导的公司在我们这个行业表现好是有原因的。最初做出这个产品所需要的洞察、客户直觉和持续投入，往往非常重要。我的工作是确保创始人亲自覆盖的地方之外，其他重要位置也有人负责。
Lenny：你刚才说的这些，对构建团队很有启发。尤其在消费产品里，这和很多人以为组织应该如何运作恰恰相反。你发现最好的团队、公司和产品，最后往往来自自上而下、创始人主导的方式，甚至接近「微观管理」——这个词对很多人来说很脏，但你实际说的是深入细节。
Tom：自上而下只有在领导层足够优秀、能够深入细节、而且具体判断正确时才有效。它失效的地方，是领导层并不知道一线事实，却试图从上面管理人。我认为「微观管理」这个词就是从那里来的。
Tom：如果你和团队基于同一批数据工作，而且你真的掌握这些数据，我不知道哪个初级工程师或入门级设计师会不愿意和 CPO 或 CEO 一起工作、一起把东西发布出去。因为你已经把他们解锁了：没有对齐会议，也没有一堆事情等着他们处理。
Tom：他们也会发现，如果你真的深入细节，就能给出好得多的反馈。关键是，你如何确保自己能在足够多的地方做到这一点？现在是尝试深入细节的最好时代，因为你可以实时查询信息。
Lenny：这里的细微差别非常重要。Grant 说「我把今天空出来，花时间深入研究这件事」，这个故事非常有力量。一个处在最高位置的人要做微观决策，这似乎是必要条件。因为正如你说的，如果他没有全部细节，他的决定就不是基于真实数据。
Tom：我们之所以能做到，是因为我们先规划要做什么，再分配资源，然后分工协作、各自攻坚。他大概会一次集中解决三四件最重要的事。毕竟他是 CEO，他会直接宣布：「现在这四件事归我。」然后我会说：「好，那我去处理别的。」
Tom：在这四件事之外，我要问自己：今天剩下的时间里，还有什么比把我说过这个半年要完成的五件事做好更重要？如果答案不是招聘，或者不是某个真正必要的会议，就可以清掉它，为团队定下调子：在我们理解清楚之前，其他事情都不能做。
Lenny：假设有人正在寻找 CPO 职位，或者第一次做 PM，基本上都是为创始人工作。你会建议他们怎样找到一个让自己开心的地方，而不是被这种没有实际自主权的中间层彻底折磨？
Tom：我认为第一件要弄清楚的事是：你为什么想要这个职位？很多人有一个想法，好像 CPO 的工作就是决定所有路线图和所有事情。但我有个坏消息：严格说，并不是这样。
Tom：接下来，你需要花时间和那位创始人相处，弄清楚你们怎样一起讨论一个主题、他们喜欢别人怎样推动、又不喜欢怎样被推动。之后，你要花很多时间校准。
Tom：在我加入 Whatnot 之前，我和 Grant 大概喝过五六次咖啡，反复聊：怎样让这种团队运转起来？应该怎样推进这些事情？之后我又经历了一系列面试，最后去了当时 Grant 和 Logan 所在的洛杉矶，和他们一起待了一整天。
Tom：我们就待在一个房间里，讨论几个不同的问题，谈路线图里的不同事情，真正把问题摊开来。我努力在整个过程中做最普通的自己，而不是进入「面试状态」。因为你必须问自己：我真的想把全部时间都花在这样的讨论和争论上吗？
Tom：我喜欢做 CPO 或产品负责人，是因为很多时候，我做的是把创始人的愿景和直觉翻译成现实。你还要学会在推动一个人的同时，不和他竞争。我见过很多 CPO 和 CEO 的关系最后变糟，原因是 CPO 开始和 CEO 争夺愿景，最后双方针锋相对。
Tom：但那不是你的工作。
Lenny：我想继续问这个「推动和 nudging」的艺术。有没有一个小技巧或建议，可以分享给那些想做好这件事的人？很多人面对高层时，总是试图让对方同意自己想要的答案。
Tom：第一件事是，不要把它当成技巧。你不是在设法得到一个答案、得到一个「是」。我的第一原则是，你是在寻找事实。
Tom：我不敢说我们经常一开始就不一致，但如果你是房间里资历更高的产品负责人，而 CEO 在场；或者你是总监，而 CFO 在场，那么你的职责之一，就是推动团队面对一个你没有预料到、或者你还没有理解的方向。
Tom：从好奇心开始。对方是不是比你拥有更多上下文？是不是有一件你不知道的事情在引导他？所以我经常先问：「我理解得对吗？你的前提是这个？」然后再问：「是不是有一部分上下文或某件事我还不知道，但它影响了这个前提？」
Tom：很好，先确保所有人站在同一个基线上。我也一直教我的团队这样对我做：如果我以一个你没有预期的角度来找你，先停下来，确认你理解我为什么会这样做。
Tom：之后我会做几件事。人就是人，对吧？有好日子，也有坏日子。有时事情很简单，你只需要问：「你已经决定了吗？还是愿意听取意见？」
Tom：如果对方说：「不，我基本已经确定答案了」，那你就闭嘴。不要为了争论而争论。如果对方说：「可以，你可以推动我，但我需要看到数据」，而现场没有数据，只有我的观点，那么讨论的条件就很清楚了。
Tom：如果我有新数据，就把数据拿出来。如果我真的相信某件事，却没有数据，那就质疑自己的判断，或者去把数据找来，再拿着数据回去。但如果没有任何人有数据，现场只是两个观点，那么 CEO 的观点会赢。这没关系。把自尊留在门外，先找到答案。如果你有数据，就把数据拿出来。
Tom：有时还要确认，你是在为正确的理由争论。我认为，在你说的那种产品剧场里，人很容易执着于框架和语气，想确保自己设定了正确的叙事。有时，行业里的术语确实很重要，具体使用哪个词也确实可能很关键。
Tom：但很多时候，术语并没有那么重要。
Lenny：我和很多与你共事的人聊天时，经常听到一个概念。他们用的说法是：「拉手风琴。」
Tom：是的。我之前说过，我并不特别热衷于框架，但我确实认为，有一个很有用的心智模型，正好对应我们之前讨论的事情：先把问题想清楚，做完心智工作，即使你还没有发布任何东西。
Tom：代码的魔力显然在于，你可以快速发布、快速迭代，并且一路获得数据。但它也带来一种陷阱：你只是不断往前迭代，把各种东西像意大利面一样往墙上扔，却并不知道自己正在往哪个方向走。
Tom：另一个失败模式是，人们坐下来写很长的路线图和战略愿景文档，规划未来两三年要做什么，最后反而失去了我们相对于其他行业的比较优势：学习。A/B 测试意味着你可以更新自己对问题的理解，因此在前进过程中改变方向。
Tom：所以「拉手风琴」这个比喻是这样的：想象一架钢琴手风琴。在你演奏一个音符之前，必须先把它完全拉开，让空气进入。也就是说，你先要问：「我们究竟要完成什么？」
Tom：但只有按下琴键、把它完全推回到 V1，你才真正开始演奏。接着，当你要演奏下一段旋律时，又要把它完全拉开。好，根据我们刚刚学到的东西，下一步要做什么？
Tom：然后你再次构建下一件东西。你必须习惯这种运动：把它拉开本身不会创造价值，真正创造价值的是……
01:03:08 - 01:10:08
Tom：把它拉开本身其实什么也没做，价值是在这里被创造出来的。但如果你不持续经历这样的运动——重新评估我们已经理解的东西，再问「这会怎样改变我们正在做的事」——你可能就没有在演奏正确的东西。
Tom：我知道自己可能把这个比喻说得不够准确，评论区里一定会有音乐家指出，这其实也是音乐创作的方式之一。但对 PM 来说，它是一个非常有用的记忆装置：你必须不断拉远视角，再把视角推回细节；拉远，再推回。
Lenny：这是个非常有趣的比喻。虽然你通过把手风琴拉开来演奏音乐，但它似乎是在向内收缩，或者说，是从压缩中学习。我们学到了什么？怎样把这些东西传达给所有人？
Tom：没错。回到发布上，这是一种不同的音乐：内部的音乐，外部的实验。
Lenny：确实，有些人非常重视路线图，有些人非常重视迭代。
Tom：诚实的答案是，两者都要做，不能过度偏向任何一边。这里的教训是：运行实验，但一定要思考结果对更大图景的影响。同时，你还得知道自己想完成什么，得有一个计划。
Tom：比如，我认为系统是这样运行的；我相信，如果因为某些原因改变发现算法，它会产生这样的影响。那我能做的最小实验是什么，足以证明这个判断？如果它有效，好，那就按计划进入 V2，不需要改变方向。如果它没效果，那糟糕，V3 就必须不同。你要一直保持这种拉开、收回的运动。
Lenny：没有在 YouTube 上观看的人可能看不到：Tom 现在的手在空中比划，动作非常夸张。什么情况下，你会对一个人说「去拉手风琴」，或者说「我们正在拉手风琴」？他们通常做错了什么？
Tom：通常是他们只在非常局部的意义上发布了某个东西，却没有理解它的影响。
Tom：举个现在的例子。大多数市场的核心是商品列表。如果没有商品列表，你很难想象 Amazon.com 会是什么样：可能只剩左边一栏、右边一栏和一些视频。
Tom：在视频电商和直播电商里，历史上并不一定需要商品列表。如果我想卖你一副 AirPods，我可以直接把它举到镜头前，展示它、描述它，说这是 AirPods，然后从一美元开始拍卖。作为买家，你已经得到了做购买决定所需要的全部信息。
Tom：这很好，也意味着你可能不需要像其他平台那样投入大量精力制作商品列表。对卖家来说，这总体上是好事，因为做一个商品列表要花三分半钟，而描述一件东西、把它举起来，只需要零分钟。
Tom：但你接着把视角拉远，会发现：新买家会来到直播电商，并且期待搜索能正常工作。如果我直到你卖完之后才知道你卖的是什么，那我根本不可能把用户导入卖 AirPods 的直播间，因为我们不知道你手里有 AirPods，也就无法把人引过去。
Tom：于是你会经历这样的过程：我们不需要修它，它能用。好，那它对其他事情有什么影响？接下来怎么办？那我们让所有人都制作商品列表。接着你又把视角拉远：如果每个卖家为每件商品都要花三分钟制作列表，那么他们每小时能卖出的东西数量就会大幅下降，这对卖家是坏事。
Tom：所以你又会说，不能这么做。你必须不断拉开视角，问我们正在做的事情有哪些长期影响、会产生哪些连锁反应。
Lenny：这非常有帮助。有意思的是，Whatnot 处在一个光谱的一端，而另一端是 agentic commerce 的趋势：代理会替你购买商品，代理之间彼此协作，创造一种全新的代理经济。这几乎是相反的方向：人类直播、相互交谈、彼此购买。你怎么看这个趋势？它会怎样影响 Whatnot？
Tom：首先，对于灯泡、空气过滤器，以及所有我需要用来维持生活、但不想亲自思考的程序化事务，我欢迎代理统治者。对于那些购买意图非常明确的东西，我也完全接受：我需要一根特定的电脑线，我在找家里的户外灯，或者我必须参加一场婚礼，需要黑色鞋子，而且必须在周四前送到。周四前到不了，对我来说就没用了。
Tom：但美国大多数电商其实并不是高意图购物。美国进入电商时代大约三十年了，电商占零售支出的比例从来没有超过 20%。美国绝大多数零售购物仍然是人们亲自到店里购买。
Tom：英国的比例大概是 75 比 25。事实证明，大量购物其实是低意图的。你去商场，是因为要参加婚礼，却没有合适的衣服；你会四处逛，看看别人有什么，因为你根本不知道自己具体想要什么。
Tom：实体店的价值在于，经营鞋店的人有自己的判断和品味，会为你策划一批可供选择的鞋子；她提供客户服务，还有橱窗展示，向你展示她有哪些东西。你可以在商场里走一圈，真正弄清楚自己想买什么，或者从她那里获得启发。事实证明，这种体验很愉快。商场之所以具有社交属性，是有原因的。
Tom：所以我认为 agentic commerce 会非常大，但美国零售是 7.5 万亿美元的行业，我不认为这是一个赢家通吃的事情。直播电商做的，是第一次把互联网的规模与便利，和线下购物同样的社交、文化体验结合起来。
Tom：在 Twitch 的时候，我们过去基本认为，如果一个直播间的人数少于一千人，因为收入依赖 CPM，那它就不具备经济性。但你可以在 Whatnot 进入一个只有 30 或 50 人的直播间。想象一下，你在商场经营一家鞋店，店里同时有 50 个人。你永远不会关门，因为那是你很难想象会出现在实体店里的客流量。
Tom：电商和娱乐的经济学完全不同，你不需要只盯着 CPM。所以我不认为直播电商和 agentic commerce 是竞争关系，它们服务的是完全不同的客户需求。
Lenny：太棒了，市场里可以容纳所有人。我想用一个关于 Twitter 的问题结束。你曾经在 Twitter 工作。
Tom：是的，先生。
01:10:08 - 01:17:55
Lenny：你在 Twitter 负责增长的 PM 工作。我感觉所有曾在 Twitter 做过 PM 的人，都被那段经历留下了创伤。大家都会说：「千万不要这样做。」那段经历有什么东西一直留在你身上？你学到了什么，又忘掉了什么？
Tom：很有意思。我以前对朋友说过，问一个 2015、2016 年在 Twitter 工作过的人那段经历，有点像治疗师请人讲述自己的童年。你知道自己正在唤起什么创伤。
Tom：不了解这段传闻的人可能不知道：我在那里工作的两年里，产品负责人换了九个，混乱就是那个程度。我最喜欢的一句话来自合作团队的一位同事，他说：「感觉 Kara Swisher 就住在新闻事件里。」那个地方的戏剧性就是这么频繁。
Tom：Lenny，我大概从 Twitter 时代带走了两个压倒性的教训。除了结交了很多非常好的朋友之外，我还要说，那一时期 Twitter 的产品人才流散到各处，形成的影响非常惊人。
Tom：第一个教训是，如果你真的找到了产品市场匹配，如果你成功把闪电装进瓶子里，那么你把组织管理搞得多糟，产品仍然会非常强大。
Tom：Twitter 的产品市场匹配确实达到了那种程度：你能从情感上感受到人们有多喜欢你的产品。这是职业生涯早期就应该学会的一项很强的检验标准。产品市场匹配不是「图表看起来还行」，而是有一种真正的热情在里面。
Tom：从不那么积极的一面说，我明确学到的是：很多时候，当你听到有人说「这件事非常复杂」，其实并不复杂，领导力只是很弱。
Tom：我在 Twitter 的两年里，所有人都知道我们迟早要取消 140 字符限制，对吧？一个又一个工作组不断出现，「超越 140」的项目到处都是，因为我们知道，例如，日本用户发推的频率是西方市场用户的六倍。
Tom：很大一部分原因是，汉字在同样的字符数里能表达比罗曼语族语言更多的内容。我们知道取消限制是不可避免的终局，但显然还有大量工作和取舍，而就是没有人愿意做最后决定。
Tom：于是又来了一轮设计冲刺，又来了一轮流程。直到我离开一年半之后，甚至可能接近两年之后，才终于有人真正做了这件事。结果没人死，Twitter 的灵魂也没有崩溃。编辑推文的讨论大概也是这样，之后又拖了两年半。
Tom：有时事情真的没有那么复杂，只是领导力很弱。
Lenny：现在它已经走得很远了，你甚至可以在 Twitter 上写完整的博客文章，「文章」本身都成了一个大赌注。说到产品市场匹配，我觉得更重要的是 Twitter 的网络效应。你花了很多时间思考市场和网络的构建。
Lenny：看着 Elon 基本上改变了一切，我甚至忘了是谁发的那条推文，但确实是一切都变了：品牌、名称、网站、在那里活动的人数，所有东西。
Tom：还有团队。那到底有什么没变？
Lenny：基本上是 Twitter 的网络效应。
Tom：是的，那里仍然是大家想去的地方，所有人都在那里，而这种网络效应很难被破坏。即使你想尽办法把一切搞乱，它仍然在运转。如果你真的把闪电装进瓶子里，确实能看出来。
Lenny：好，我要进入播客的固定环节：失败角。我喜欢做这个环节，是因为听众看到像你这样拥有辉煌职业生涯的人，会觉得一切都一直进展顺利，你一直在赢。但他们看不到那些没能成功的事情，也看不到你失败的时刻，而他们自己的生活经常会出问题。
Lenny：所以请你举一个职业生涯里失败的例子：某件你构建的东西，或者某个你做出的职业选择，最后没有奏效。你从中学到了什么？
Tom：说实话，朋友，你这样夸我当然很好听，但我感觉自己在整个职业生涯里失败的次数比成功的次数多。真的。
Tom：回到你开头提到的那篇文章，我在文章后面放出了我们内部讨论产品构建时真正使用的文档。它一开始就写着：击球率达到 500，也就是打对一半，才是目标。你希望自己对的时候和错的时候差不多多。
Tom：所以我职业生涯里搞砸的具体例子太多了，但它们大概有一条共同线索，而且任何 PM 都很容易掉进这个陷阱：平均值对个体毫无意义。
Tom：在任何规模足够大的群体里，人们很容易去看某个东西的平均效用、平均采用率。然后你发现只有 3% 的人使用某个功能，就会说：「好，我们大概可以把这个功能删掉，因为它没有被广泛使用。」
Tom：但如果你不再深入一层，就不会发现：它虽然只占某个指标的 3%，但对一群人来说，它却是他们全部工作流程的 100%，是他们的核心使用场景。为了省事，因为有人不想再维护这个功能，你就把它废弃。结果你摧毁了那群人的使用场景。
Tom：再结合你刚才说的网络效应，这件事会产生巨大的持续性连锁影响。我经常从电商的角度想：这就是某个人的生意。如果我们的服务不可靠，或者我们废弃了一个功能，就像 Westfield 商场在圣诞节前突然断掉电，却根本没有考虑后果。
Tom：人们的生意会受到真实的下游影响，而这些影响常常只是来自对指标缺乏细节理解，尤其是对平均值缺乏理解。平均值一直在欺骗你。
Tom：我职业生涯里大概以各种方式犯过错，但那些让我真正失望、让我觉得自己做出糟糕决定的时刻，通常都是因为我依赖了平均值，没有想清楚隐藏在平均值下面的个体使用场景。
Lenny：这让我想到 Jeff Bezos 的一句话：当你同时拥有数据和一个用户故事时，相信那个用户故事。
Tom：完全正确。
Lenny：Tom，我们已经谈完了我想谈的所有事情。在进入非常精彩的闪电问答之前，还有什么想和听众分享、留下的话吗？
Tom：我想补充的是：我不认为产品管理只有一种做法，也不认为 AI 只有一种塑造行业的方式。对于 Whatnot、我们正在构建的产品和公司的文化，我们非常确信：更少的 PM、但更资深、拥有更多自主权的 PM，这个模型适合我们。
Tom：我不敢假设它对整个行业都成立，但我确实认为，现在是回到真正产品工作的根部、离开产品剧场的最好时机。我认为这一点可能在任何地方都成立。
Tom：当然，如果你是非常优秀的人员管理者，从人员培养和辅导中获得满足感，我相信仍然会有很多地方需要这种能力。所以，请假设我说的话至少有一半是错的，就像我职业生涯里发布过的东西大概有一半不正确一样。
Lenny：这正是我喜欢这种对话、也认为我们一起做的这件事很重要的原因。我们正在经历职业生涯里最疯狂的时代，很多事情都在改变，很多事情都在被重新思考。我们能成功穿过这段时期的唯一方式，可能就是学习别人如何面对它，看看他们学到了什么、什么没有奏效；拿走有共鸣的部分，忽略那些夸张或不适用的部分。
Tom：没错。没有人确切知道接下来会怎样。Elizabeth Stone 有个很好的说法：我们正在经历从成形到规范化之前的「风暴期」。我们现在就是在风暴期里，感觉一切都在说：「天啊！」
Lenny：我刚开始写作时，人们总问我：「过去十年，产品管理发生了什么变化？」我会说：「其实没变，基本还是一样。」但现在感觉它真的发生了重大变化。虽然正如你前面说的，核心事情也不会全部变掉。
Tom：是的。
Lenny：所以这些对话很有用。读者可以看到一支团队如何运作、他们学到了什么；可以尝试其中一些方法，也可以发现它未必适合自己。但我们就是这样相互学习的。
Lenny：好了，现在进入非常精彩的闪电问答。我有五个问题。
Tom：好，来吧。
01:17:55 - 01:24:55
Lenny：第一个问题：你最常向别人推荐哪两三本书？
Tom：不想说得太陈词滥调，但《艰难的创业》仍然是我认为关于产品管理最好的书。它覆盖了你必须经历、尝试、并且会搞砸的大量事情。
Tom：另一本有点偏门，但可能是别人推荐给我的、我最喜欢的书，现在我也会推荐给别人：《标杆教会》，作者是牧师 Rick Warren。Twitch 的 CEO Emmett Shearer 过去会确保团队成员读这本书。
Tom：这是一本非常特别的书，研究人们为什么会在情感上投入某件事，以及怎样让一群人对某件事产生情感投入。它本质上是一本「如何建立教会」的指南，写于 90 年代。如果你在做任何形式的社区产品，很值得读。
Tom：最后一本，如果你晚上喜欢读小说或奇幻作品，我推荐 R.F. Kuang 的《Babel》。我很喜欢一本原本没人提过的书，后来把它加入自己的推荐书单。这个过程很有趣。
Lenny：最近有没有特别喜欢的电影或电视剧？
Tom：《星城》，Apple TV 上的。如果你喜欢《为了全人类》，它有点像反过来的版本，但视角是苏联一边。你可以把它想象成苏联版和《为了全人类》混在一起。
Lenny：最近发现、而且很喜欢的产品是什么？
Tom：这是个非常冷门的答案，先向大多数听众道歉。希望你们已经听出我的口音。我经常被人说，我的澳大利亚口音正在消失。但我每次回家都会发现，澳大利亚有一批政府服务应用已经做得非常出色。
Tom：你有没有过这样的想法：「我希望政府已经有我的全部数据；我希望有一个地方，点一下就能续驾照、转移车辆所有权、完成那些拖慢生活的行政事务。」新南威尔士州的 Services 应用真的做到了。
Tom：对我来说很奇怪，我居然会来到一个播客里说，澳大利亚的政府应用竟然是我最近发现的好产品之一。但我前段时间回家，需要处理生活中的各种行政事务，体验真的非常棒。
Lenny：既然聊到澳大利亚，闪电问答之外插一句。我最近听说，澳大利亚因为太阳能板的建设，现在产生的电力多到用不完。
Tom：是的，太阳能在澳大利亚非常普及。白天他们甚至会给人免费电，因为可用电力太多了。他们会说：「白天把所有设备都用起来，否则这些电就浪费了。」
Tom：如果 AI 数据中心真的需要大量电力，那么澳大利亚整个 21 世纪的经济都可以围绕电力展开。
Lenny：太棒了。我们居然找到了通过太阳能板产生如此多能源的方法，这真是个好消息。
Tom：二十年前有一条很小的法规：如果你要建造新房产，就必须在屋顶安装太阳能板。结果证明，它真的非常有效。
Lenny：天啊，我喜欢这种对未来的乐观。气候变化的答案是能源，不是问题。
Tom：说得好。
Lenny：好，还有两个问题。你在工作或生活中经常回到的一句人生格言是什么？
Tom：我上大学时，曾经把 Kipling 的《如果》背下来，当作一个小才艺，因为我觉得它很深刻，也很有意义。
Tom：但如果完全诚实地说，最接近我的格言可能是：「我会想办法解决。」事实证明，大多数事情都没有人们想象的那么难。我们会把它做出来，我会想办法把它做出来。
Tom：只要你愿意投入必要的时间、金钱、努力和精力，几乎什么问题都能解决。如果你不愿意投入，那它可能本来就没有那么大的问题。
Lenny：最后一个问题。我猜你经常被问到这个，但我也很好奇：过去一个月左右，你在 Whatnot 上买过什么特别棒、特别愉快、特别出人意料的东西？
Tom：我最近买到的最有趣的东西，不开玩笑，是一只活龙虾。
Tom：最近，Whatnot 上有一个增长很快的品类：新鲜和特色食品。有一位很棒的卖家，叫 E Fish Co，在圣迭戈码头上经营一家海鲜店。每天早上船只进港时，他会直接出去直播，把船上运来的所有海鲜箱展示出来，然后在 Whatnot 上直播拍卖，第二天寄到买家门口。
Tom：我买了一只加州刺龙虾，直接寄到家里。
Lenny：通过直播？这具体怎么运作？他们把它放在冰里，当天寄出吗？
Tom：它会放在类似干冰的容器里，通过 UPS 隔夜配送，第二天送到我家。
Tom：这正是为什么 agentic commerce 会很棒、但不会包办一切：那天早上，我原本完全没打算买一只加州刺龙虾。
Lenny：除非你的代理决定你今天需要龙虾。
Tom：我得诚实说，它非常美味。
Lenny：太惊人了。我以前不知道还能这样买东西。Tom，如果听众想关注你的写作或招聘，在哪里可以找到你？你们正在招什么人？最后，听众怎样能对你有所帮助？
Tom：如果你想在网上找到我，我在 Twitter 或 X 上的账号是 TDRobbo，拼写是 T-R-O-B-B-O。我大多数想法都在那里发布，内容大致是产品管理，以及对 Warriors 比赛的呐喊，提前向大家道歉。
Tom：LinkedIn 是我发布大部分工作写作的另一个地方。我追求质量而不是数量，所以不要期待我每天在这两个平台更新。偶尔来一篇真正有分量的内容，一年一次。
Lenny：这是关于「隔很久才发一篇」最体面的说法。偶尔来一篇重磅内容。那听众怎样能帮到你？
Tom：说实话，我一直欢迎大家反馈 Whatnot，告诉我大家如何使用它、遇到了什么问题，以及我们还能怎样做得更好。可以在这两个平台中的任何一个联系我，给我一些大胆的观点、反馈或想法。
Lenny：你们仍然在招聘 PM，对吧？尽管你对产品管理有很多强烈的观点。能不能讲讲大家在哪里申请？
Tom：当然。我们一直在寻找 PM。我们解释申请人数和录用人数的意图，并不是想劝退大家，而是想说，产品管理的扩张本身，并不会自动带来我们过去九十分钟一直讨论的那种能力。
Tom：但我们昨天刚招了两个人，我非常期待他们来入职。我们一直都有各种 PM 岗位开放。你只要搜索 Whatnot jobs，就能找到正确的申请流程。
Tom：或者，我发现 Whatnot 的规模还不算太大，产品管理也不是那么神秘。你大概可以找到在 Whatnot 工作的二十来个人中的一个，直接联系他们。
Tom：我们现在正在看很多方向，支付是非常重要的方向，物流也是。所以，如果有人对参与「隔夜运送龙虾的未来」特别兴奋，事实证明，那里有大量细致而复杂的产品工作。
Lenny：太棒了。Tom，非常感谢你来到这里。
Tom：很荣幸，兄弟。谢谢你邀请我。
Lenny：大家再见。也非常感谢你的收听。如果你觉得这一期有价值，可以在 Apple Podcasts、Spotify 或你常用的播客应用里订阅节目。也请考虑给节目评分或留下评论，这会真正帮助其他听众找到这个播客。你可以在 Lenny's Podcast dot com 找到往期所有节目，也可以在那里了解更多。下一期见。
Comments
Sign in to comment.