我们为何后悔产品管理存在

随着科技公司规模扩张，不知从何时起，这种小组的人力配置比例就出现了。每招六名工程师，就配一名设计师、一名产品经理。招这么多产品经理，会让工程师和设计师变得幼稚化，他们完全有能力做出好决策，但从来不需要这么做，因为总有产品经理在旁边当保姆。你在网上写的一些东西让很多人感到意外，而且 Whatnot 的产品团队建立在一个相当简单的理念之上：我们后悔产品管理这个岗位存在。这话从很多首席产品官嘴里说出来，你可能不太常听到。我们这样表述，是为了强迫自己记住：不要为了招产品经理而招产品经理，只有在确实有特定需求时才招。

As tech companies scaled, somewhere along the line, this HR ratio of a pod popped into being. Every time you hire six engineers, you add a designer, you add a PM. Hiring so many PMs infantilizes the engineers and the designers who are perfectly capable of making good decisions but just never had to because there was always a PM to babysit them. Something you wrote online that surprised a lot of people and whatnot product team was built on the somewhat simple premise. We regret that product management exists. Not a thing you probably hear from a lot of CPOs. We articulate it that way to force ourselves to remember that you don't hire a PM just for the sake of hiring one. You hire one where there's really specific need.

最好不要假设每个地方都需要产品经理。

It is better to not assume we need a PM in every place.

为什么要把产品管理当作一个专业职能，唯一的理由其实是：它是一门手艺，而不是一种资格。它是通过实践才能擅长的东西，是一块肌肉。但反过来说，你越是让工程师和设计师远离做同样的事情，他们的肌肉就越不发达。他还写了这样一句狠话：过去两年，有 31,832 人申请 Whatnot 的产品经理职位，我们只招了一个。那你招人的时候看重什么？

The only argument for why you would want product management to be a specialist function is really it's a trade not a qualification. It's something you get good at by doing. It's a muscle. But the flip side of that is the more you abstract your engineers and your designers from doing the same thing, their muscle gets underdeveloped. He also wrote this brutal quote. In the last 2 years, 31,832 people applied to be a product manager at Whatnot. We hired one. What does he look for in the folks that you hire?

我可以告诉你什么肯定在走下坡路：那些在面试中花大量时间谈论推动对齐和利益相关者管理的人。因为确实有一类产品经理，他们的专长不是技术，而是政治。

I can tell you what's definitely trending down. Folks who spend a lot of their time in their interviews talking about driving alignment and stakeholder management because there's definitely a group of PMs whose specialty wasn't technical, it was politics.

你对转向独立贡献者工作非常兴奋。产品经理正在远离这种大型组织管理世界。如果你作为产品经理真的很成功，你就会被提升为总监。我们把所有 A 级人才都提拔到不再做事的位置。为什么你不想让梅西为你的球队踢球，而不是一直试图让青训营跟上？今天我的嘉宾是 Tom Verrilli。Tom 是 Whatnot 的首席产品官，曾任 Twitch 的长期首席产品官，以及 Twitter 的产品增长总监。他也是我一直很想请到播客的人。Tom 有很多热门观点，对产品角色的未来、他看到的顶尖产品经理如今的不同做法，以及他招人时看重什么，都有非常独特和重要的见解。如果你不熟悉 Whatnot，它是一个直播购物平台，是有史以来增长最快的美国市场业务。有一次，Tom 分享了他是如何在平台上从一位渔民那里买了一只新鲜龙虾。在开始之前，别忘了访问 lenny'spass.com，获取一年免费的最热门、制作最精美的 AI 产品，这些产品仅对 Lenny 的新闻通讯订阅者开放。那么，有请 Tom Verrilli。Tom，非常感谢你来到这里，欢迎来到播客。

You're very excited about this move to IC work. PM's moving away from this big org management world. If you were really successful as a PM, you got promoted into being a director. We took all of our A players and then promoted them out of doing things. Why wouldn't you want Messi playing for your team rather than trying to have the academy coming along all the time? Today, my guest is Tom Verrilli. Tom is chief product officer at Whatnot, former longtime chief product officer at Twitch, and former director of product growth at Twitter. He's also someone I've been wanting to get on this podcast for so long. Tom has a lot of hot takes and really unique and important insights on the future of the product role, what he's seeing the best PMs doing differently these days, and what he's looking for when he's hiring product people for his team. Now, if you're not familiar with Whatnot, it's a live stream shopping platform. It's the fastest growing US marketplace business of all time. At one point, Tom shares how he bought a fresh lobster from a fisherman on the platform. Before we get into it, don't forget to check out lenny'spass.com for a free year of the hottest and most beautifully crafted AI products in the world available exclusively to Lenny's newsletter subscribers. With that, I bring you Tom Verrilli. Tom, thank you so much for being here and welcome to the podcast.

非常感谢，老兄。看了这么多年，感觉有点不真实。

Thank you so much, dude. It feels kind of surreal after years of watching.

我常听到这个。人们来上播客时都这么说。你来了，第一次来，但感觉认识很久了。

I hear that. I hear that when people come on the podcast. Here you are. giving you first time long time.

没错。

That's right.

我想从你在网上写的一些东西开始，这让很多人感到意外，我想也会让很多人感到意外，尤其是出自一位长期担任首席产品官、长期打造产品、并且建立过许多非常成功的产品和团队的人之口。你写的是：从一开始，Whatnot 的产品团队就建立在一个相当简单的理念之上：我们后悔产品管理这个岗位存在。是的，先生。这话从很多首席产品官嘴里说出来，你可能不太常听到。

I want to start with something that you wrote online that surprised a lot of people and I think will surprise a lot of people coming from a longtime chief product officer, longtime product builder, someone that's built a lot of very successful products and teams. What you wrote is since its earliest inception, the Whatnot product team has built was built on the somewhat simple premise. We regret that product management exists. Yes sir. Not a thing you probably hear from a lot of CPOs.

不会。

No.

谈谈你为什么会有这种感觉，你是怎么走到这一步的，以及这意味着什么。

Talk about why you feel this way. Talk about how you got to this place. Talk about what this means.

当然。我总是试着从历史开始，以便理解事物。关于产品管理，如果你追溯到最早，产品管理根本不存在，对吧？就是业务，创始人或 CEO 类型的人直接与工程和设计讨论需要构建什么，然后一起执行。事实证明，互联网业务的扩张速度比历史上任何其他业务都要快得多。所以在某个阶段，规模意味着将执行的具体细节委托给某人，或者信任其他人来规划下一步，因为事情太多，一个人无法全部顾及。但如果你想想大多数初创公司，或者想想这种演变是如何发生的，那很少是一个专家角色，通常是你对工程师说得更少，对设计师描述得更简略，因为他们理解，或者他们已经参与其中。而我们需要在科技领域有这种专门的决策者阶层，这其实是一个更现代的功能，而不是纯粹的必要性。我的思考方式，也是 Whatnot 一直以来的处理方式，是如果工程和设计拥有他们需要的背景信息，能够做出好的决策，如果他们与用户及其需求如此紧密相连，以至于他们能做出产品经理会做的同样决策，那会好得多。据我所知，为什么要把产品管理当作一个专业职能，唯一的理由其实是：它是一门手艺，而不是一种资格。我的意思是，它是通过实践才能擅长的东西，用更好的说法就是一块肌肉。正如每位私人教练告诉我的，肌肉是通过重复训练练出来的。你做得越多，就越擅长。但反过来说，你越是让工程师和设计师远离做同样的事情，他们的肌肉就越不发达。所以我认为产品管理扮演着非常重要的角色。而且，你可以部署产品管理，在那些需要特别顺利的事情上产生非常重要的杠杆作用。在很多方面，这样做能让设计和工程在那些情况下发挥出最佳水平。但只要有可能，不设产品经理反而是最优的，而是让设计和工程经历这些步骤，确保他们的肌肉得到充分锻炼。

Sure. I mean I always try and start with like history in order to understand kind of things. And one of the things when you come to product management is if you go all the way back like product management didn't exist, right? It was like the business and you know very often founder or CEO types talking directly to engineering and design about what we needed to build and then executing it together. And you know internet businesses it turns out scaled a lot faster than any other businesses in history. And so at some point scale meant delegating the specifics of execution to somebody or trusting somebody else to work out what comes next because there's just too many things on for somebody to sit with. But if you think about most startups or you think about how that evolution worked, that was rarely a specialist role where somebody was working it out, it was usually you said less things to the engineer where you had to describe in less detail what you were trying to get done to to a designer because they understood or they they'd been involved. And this idea that we need this kind of specialist decision-making class of humans in tech is really a more modern function than it is a like pure necessity. You know, the way I would think about it and the way that Whatnot is always treated is like it would actually be way better if engineering and design had the context that they needed to just make great decisions there if they were so in touch with users and what they needed that they could kind of make the same decisions that a product manager is. The only argument as far as I'm aware for why you would want product management to be a specialist function is really it's a trade, not a qualification. And and what I mean by that is it's something you get good at by doing. It's a muscle for one of a better term. And as every private trainer has ever told me, muscles are built by reps. And so the more you do it, the better you get at it. But the the flip side of that is the more you abstract your engineers and your designers from doing the same thing, their muscle gets underdeveloped. And so I think product management plays a really important role. And I think, you know, you can deploy product management to have really important leverage on particular things that need to go really well. Um, and in a lot of ways doing that lets design and engineering be the best they can be at their craft in those situations. But wherever possible it's kind of optimal to not have a product manager uh and instead have design and engineering going through those those kind of steps and making sure that their muscles are well repped.

你觉得产品管理在早期是不是非常有帮助、很重要，然后经历了一个“哇，有太多不怎么样产品经理”的时期，现在又回归到“好吧，到底什么是优秀的产品经理，也许我们需要更少的人”这样的状态？

Do you feel like product management was very helpful early on and was important and then it kind of went through a period of wow there's way too many PMs that are not that amazing and now there's kind of this coming back to okay what is actually an amazing PM and maybe we need fewer of them.

是的。有趣的是，我觉得如果你和大多数工程师甚至设计师交谈，他们会记得那些合作过的优秀产品经理，主要是因为他们合作过太多糟糕的了。

Yeah. Uh the funny thing is I think if you talk to most engineers or even designers they will remember the great PMs that they've worked with mostly because they've worked with so many bad ones.

我这么说并不是要打击大家，但我觉得更多的是，如果你真的以批判的眼光看待这个职能，普通的产品经理是否真的能为周围的人带来巨大价值？就像高质量的产品管理能做到的那样，传播清晰度、吸收模糊性，或者帮助人们做出及时的决定。我认为这在很大程度上是随着科技公司规模扩大，我们最终雇佣了这么多工程师，在某个阶段，我不想把责任推给 HR，但确实在某个阶段，这种类似 HR 配比的小组模式就出现了。你知道，每招六个工程师，就配一个设计师、一个产品经理、一个工程经理，这个核心就形成了。然后当你现在服务的是十亿日活的产品时，你有很多工程师，所以突然之间你也有很多产品经理。但在大多数情况下，你可能不需要为通知基础设施配一个产品经理，对吧？工程师完全有能力理解那部分工作。而且在很多方面，正如我们刚才描述的，雇佣这么多产品经理反而让工程师和设计师变得幼稚化，他们完全有能力做出好的决策，但从来不需要，因为总有产品经理在照看他们。

And I don't mean that as a disheartening pejorative for folks, but I think it's more, you know, if you're being really self-critical as a function. Does the average PM add a ton of value to folks around them in the way that having really high quality product management can, you know, disseminate clarity and absorb ambiguity in the ways that they can or help people make really timely decisions? And I think a lot of it is this function of like as tech companies scaled and we ended up hiring so many engineers, somewhere along the line, and I don't want to pin it on HR, but somewhere along the line this kind of HR ratio of a pod popped into being. You know, every time you hire six engineers, you add a designer, you add a PM, you add an EM, and the nucleus exists. And then when you're now serving billion DAU products, you got a lot of engineers, and so now all of a sudden you got a lot of product managers. And in most cases, you probably don't need a PM for notifications infrastructure, right? Engineers are perfectly capable of understanding how that works. And in a lot of ways, as we just described, hiring so many PMs infantilizes the engineers and the designers who are perfectly capable of making good decisions, but just never had to because there was always a PM to babysit them.

本期节目由本季赞助商 Work OS 呈献。OpenAI、Anthropic、Cursor、Vercel、Replit、Sierra、Clay 以及数百家其他成功公司有什么共同点？它们都由 Work OS 提供支持。如果你正在为企业打造产品，你一定体会过集成单点登录、SCIM、审计日志以及大公司要求的其他功能的痛苦。Work OS 通过一个专为 B2B SaaS 打造的现代开发者平台，将这些交易障碍转化为即插即用的 API。实际上，我投资的每一家开始向上游市场扩张的初创公司，最终都会与 Work OS 合作。那是因为他们是最好的。无论你是试图拿下第一个企业客户的种子期初创公司，还是全球扩张的独角兽，Work OS 都是实现企业就绪和释放增长的最快路径。它本质上就是企业功能的 Stripe。访问 works.com 开始使用，或者直接联系他们的 Slack，那里有真正的工程师等着回答你的问题。Work OS 让你通过愉悦的 API、全面的文档和流畅的开发者体验更快地构建。今天就访问 works.com，让你的应用企业就绪。

This episode is brought to you by our season's presenting sponsor, Work OS. What do OpenAI, Anthropic, Cursor, Vercel, Replit, Sierra, Clay, and hundreds of other winning companies all have in common? They are all powered by Work OS. If you're building a product for the enterprise, you've felt the pain of integrating single sign-on, SCIM, audit logs, and other features required by large companies. Work OS turns those deal blockers into drop-in APIs with a modern developer platform built specifically for B2B SaaS. Literally every startup that I'm an investor in that starts to expand upmarket ends up working with Work OS. And that's because they are the best. Whether you are a seed-stage startup trying to land your first enterprise customer or a unicorn expanding globally, Work OS is the fastest path to becoming enterprise-ready and unblocking growth. It's essentially Stripe for enterprise features. Visit works.com to get started or just hit up their Slack where they have actual engineers waiting to answer your questions. Work OS allows you to build faster with delightful APIs, comprehensive docs, and a smooth developer experience. Go to works.com to make your app enterprise-ready today.

我发现人们最终会遇到一个问题，我想听听你的看法，那就是工程师和设计师不一定想做产品经理的工作，因为产品经理的很多工作有点烦人，也不有趣。你知道，有些光鲜的部分，比如做决策。

Something that I find people run into eventually when they think this way, that I want to get your take on, is engineers and designers don't necessarily want to be doing the work of a PM because a lot of the work of a PM is kind of annoying and not fun. And you know, there's a glamour part like making decisions.

肯定比人们想的要不光鲜。是的。

Definitely less glamorous than people think. Yeah.

是的。完全正确。你怎么看这个问题？尤其是随着公司规模扩大，工程师必须参加对齐会议，必须写文档让所有人对齐，还要做笔记，你知道，这些都是产品经理工作的琐碎部分，而且从大局来看，他们也想要，你知道，工程师想构建，工程师想写代码，设计师想设计。你怎么看待他们可能实际上并不想做那部分工作这一点？

Yes. Exactly. How do you think about that? Just like, especially as a company scales, engineers having to be in alignment meetings, having to write docs aligning everyone and taking notes, you know, all these kind of minutiae parts of PM, and also just the big picture, they also want to, you know, engineers want to build, engineers want to code, designers want to design. How do you think about that element of they may not actually want to be doing that work?

我认为这就是专业化双向起作用的地方，对吧？拥有擅长做决策的人是有用的。有人这样说也完全合理：听着，我是基础设施负责人，我想多思考规模问题，我不想花时间争论对齐问题或处理那些琐碎细节。而且某些技能不一定能很好地转化，对吧？如果你很擅长在脑海中构建基础设施应该如何扩展的大模型，你可能不具备倾听客户并真正理解核心问题的技能，而不是他们说的表面问题，这又是我们随着时间积累的能力。所以我说“我们后悔”并不是说我们不想让产品经理做这些事；我们认识到在那些情况下，你确实需要帮助其他职能专业化。但我认为我们这样表达是为了强迫自己记住，你不是为了招产品经理而招产品经理。你是在有真正特定需求时才招一个。而且我认为随之而来的是，Lenny，你必须围绕这一点建立组织文化。例如，当我们说我们后悔产品管理存在时，每次我们写关于如何发布或我们正在做什么的文档时，我们都很明确，任何人都可以提出变革，我们可以让工程师或设计师担任新产品开发的 DRI，但每个人都要经历同样级别的职能，比如你必须经过产品评审，你必须真正做这项工作，因为这是实际的工作。如果人们不想做，如果他们想做别的事情，我们总是可以调整产品管理。所以，与其把产品经理映射到团队，假设产品经理总是做那些事，我们倾向于把他们映射到问题或核心项目上。这意味着可能有一年或更长时间，某个特定工程团队没有产品经理，即使有很多正在进行的产品工作要做。

I think this is where specialization works both ways, right? It is useful to have folks who are well-honed in making decisions. It's totally reasonable as well for someone to say, listen, I'm an infrastructure lead and I want to think a lot about scale and I do not want to have to spend my time debating alignment or getting those minutiae right. And certain skill sets don't necessarily translate super well, right? If you're really good at building big mental models in your head of how infrastructure should scale, you may not have the skill set of listening to a customer and actually understanding the core problem as opposed to the thing that they said, which again is just a thing that we've built over time. So my supposition of 'we regret' isn't to say that we don't want product managers to do this; we recognize in those situations that you do need to kind of help other functions specialize. But I think it's we articulate it that way to kind of force ourselves to remember that you don't hire a PM just for the sake of hiring one. You hire one where there's a really specific need. And I think what goes with it, Lenny, is like you have to build the culture of the organization around that. So for example, when we say we regret product management exists, every time we write documents about how we ship or what we're doing, we're very kind of clear that anyone can bring change forward, that we can have DRI of new product development that is an engineer or is a designer, but that everybody goes through that same level of function of like you've got to go through product review, you've got to actually do the work because it is real work. And if people don't want to do that, if they kind of want to do something else, we can always move product management. And so rather than mapping PMs to teams where you kind of assume that the PM will always do that, we tend to map them to kind of problems or kind of core projects. And that means that there will be a year or more where there isn't a PM attached to a particular engineering team even though there's lots of ongoing product work to do.

我喜欢这一点的是，我们经常听到面向开发者的产品公司这样说，比如开发者工具，我们不需要产品经理。为什么我们需要产品经理？而且这通常来自像 Linear 和 Anthropic 这样的公司，这些公司构建开发者工具，你可以理解为什么工程师就够了。所以从你的角度来看真的很有趣，因为你构建了非常面向消费者的产品，非常非常面向消费者的产品，这些产品需要你认为非常强的产品经理技能。所以从你口中说出来更有分量，你觉得产品经理并不像人们可能认为的那样必要，来打造伟大的产品。

What I love about this is we often hear people at developer-oriented products talk like this, like developer tools where we don't need PMs. Why do we need PMs? And it's often comes from companies like Linear and Anthropic, like companies that are building developer tools where you could see why engineers are enough. And so it's really interesting to hear from your perspective because you've built very consumer-y products, very very consumer-y products that require what you think are very strong PM skills. So it means a lot even more so coming from you that you find that PMs aren't as necessary as people may think in building something great.

是的，我认为有两个原因驱动了这一点。而且我当然，就像我在这里谈到的很多内容，都是随着时间逐渐学到的。你知道，我在 Whatnot 之前在 Twitch 待了七年。那非常受亚马逊两个披萨团队配比的驱动。我在硅谷从 Twitter 开始，那也很类似，总是有非常紧密的对齐，而且，天哪，有很多对齐会议。所以你可以想象为什么工程师不想参加。随着时间推移，我逐渐理解到，实际上很多这些只是管理层无法看清正在发生的事情的结果。所以你雇佣更多人，建立更多层级，你的系统催生系统。

Yeah, I think there were like two parts that drove it. And I've certainly, like a lot of what I'm kind of talking about here are things that I've definitely learned over time. You know, I spent seven years at Twitch prior to time at Whatnot. And that was very Amazon two-pizza team ratio driven. I started in the valley at Twitter and that was similar, very like you always had this kind of very tight alignment and there was, God, there was a lot of alignment meetings. So you can imagine why engineers didn't want to be in them. And it's kind of evolved over time to understand that like actually a lot of that is just a function of like management not being able to see what's going on. And so you hire more folks and you build more layers and your systems beget systems.

我认为真正在变化的是，人们开始意识到，获得杠杆的唯一途径不再只是招更多下属 PM、让自己更资深。我们现在对业务中发生的事情有了更好的理解。直接与代码库对话、与工程师交流，比以往任何时候都更容易。所以你其实不必陷入那种全面扩张的套路。而且我认为消费者或企业市场不再是分水岭，更重要的是组织自身的文化。

And I think what's really changing is people are realizing that it's not true anymore that the only way to get leverage is just to hire more PMs underneath you and be more senior. We've got a better understanding of what's happening in businesses now. It's easier to converse directly with the codebase and talk to engineers than it ever has been. So you don't actually have to get into this all-scale thing. And I don't really think consumer or enterprise is the cutting point anymore. I think it's more the culture of the organization itself.

在你看来，这种转变有多少是由 AI 驱动的，因为 AI 现在让非 PM 也能做 PM 的工作，又有多少是 AI 之前就有的？然后我想聊聊这在你的团队里实际是什么样子。但先让我问这个问题。

How much of this shift in your mind is AI driven, because AI now enables non-PMs to do PM work, and how much of it was like pre-AI? And then I want to talk about just what this actually looks like in your team. But let me ask that question first.

我不认为这完全是 AI 的原因，但我确实认为 AI 让这一切变得容易得多。我觉得有两方面。AI 肯定意味着个人贡献者（IC）拥有巨大的杠杆。我不知道其他人感受如何，但我前几天和几位资深负责人聊过，我们都觉得现在有了 AI，我们做事的能力太强了，以至于你会感到一种压力，觉得自己还有很多事没做，因为你知道如果能多挤出几个小时，就能推进很多事情。如果你有敏锐的判断力，用 AI 工具确实更容易快速行动。现在你可以在 Hex 上拉数据，基本上相当于 2017 年用一个亚马逊 L7 数据科学家花一两周才能完成的工作。所以如果你被授权并且有良好的判断力，你基本上可以做出非常快速的决策，让大家保持前进，这非常了不起。但不仅仅是 AI，我认为还有很多这种比例上的推动，也伴随着其他文化上的推动，比如“招优秀的人，然后别挡他们的路”、自下而上的路线图，以及所有这些。我认为过去一段时间科技界出现了一种文化转变，那就是自上而下其实相当不错，因为高层通常能快速决策，消除所有这些对齐争论。他们可能比大多数人拥有更多的宏观背景，假设他们真正了解实际情况并且足够优秀，那么让高层领导参与很多决策实际上是一个非常高效的模型。这意味着不仅仅是工具让他们高效，而且你可以让一个非常资深的 PM 负责更多事情，比三个相对初级的 PM 更高效。但当然，AI 让这一切变得容易得多。

I don't think it's explicitly because of AI, but I do think AI makes it a lot easier. I think it's two things. AI certainly means that there's an enormous amount of leverage for an IC. Now, I don't know how much other people feel this, but I was talking to a couple of our senior leads the other day and we feel that we're so capable of doing things now with AI that you almost feel a bunch of pressure of the stuff you're not doing, because you know that if you carved out a couple more hours, you could move a lot of stuff. It's certainly easier to move fast with AI tooling if you've got well-honed judgment. You can pull data now on a Hex thread that is basically what it would take a week or two weeks with an Amazon L7 data scientist in 2017. So if you're empowered and have good judgment, you can basically make really quick decisions and just keep people moving, which is extraordinary. But more than just AI, I think it's also a lot of those kind of ratio pushes that came with a bunch of other cultural pushes, like hire great people and get out of their way, bottoms-up roadmaps, and all of those pieces. I think there's been a bit of a cultural shift in tech over the last little while, which is that actually top-down's pretty good, because folks at the top generally speaking can make quick decisions and remove all of this alignment debate. They have probably more macro context than most folks, and assuming that they are genuinely in touch with ground truth and are good enough, it's actually a really efficient model to be able to have senior leadership involved in a lot of those decisions. Which means it's not just the tooling that makes them efficient, but you can have one very senior PM across more things, and they can be more efficient than having three relatively entry-level PMs. But certainly AI makes all of that a lot easier.

所以回到这个大的前提，我认为澄清这一点非常重要：关于“后悔产品管理存在”这个观点，并不是说我们不想要 PM 或认为 PM 没用，而是说最好不要假设每个地方都需要一个 PM，并且让其他职能也能做 PM 的工作是很好的。另外，PM 某种程度上剥夺了其他人做 PM 工作的机会。如果他们能做这些工作，他们实际上能执行得更好，构建出更好的产品。

So just to come back to the broad premise, which I think is very important to clarify, this point about regretting product management exists isn't saying we don't want or think PMs are useful. It's that it is better to not assume we need a PM in every place, and it is great to enable other functions to do the PM work. Also, PMs kind of take away the reps from people being able to do the things that PMs do. And if they can do that work, they can actually execute better, build better products.

我认为，与其让 PM 固定映射到一个团队，不如说“我们去工作所在的地方”，这对 PM 也更好。你会积累更多、更好的经验。你会通过在不同的事情上移动来锻炼更多的“肌肉群”，而不是说“我固定在这个工程经理负责的范围”。

I think it's also better for PMs to not be mapped specifically to a team than it is to say, we go where the work is. You will build more and better reps. You're going to work out more muscle groups by moving around on the things you work on, as opposed to saying I'm attached to whatever this EM owns.

那我们顺着这条线聊。团队是什么样子的？Whatnot 的 PM、工程、设计团队是什么样的？在这种世界观下，这个组织是什么样子的？

So let's follow that thread. What does the team look like? What does the PM/Eng/Design team look like at Whatnot? What does this org look like in this world view?

是的，我们刚刚超过 20 个 PM。今天公司里有 21 或 22 个 PM，对于关注我们发展轨迹的人来说，考虑到我们卖家带来的 GMV 规模，这个数字相当小。我们非常松散地组织成三个组：买家、卖家，以及我们所说的信任与风险。也就是负责标准、支付、安全等的团队。然后在这些大组内部，我们基本上定期重新分配 PM。所以人们有松散的定位。你可能大致是一个增长 PM，或者大致做发现相关的工作。但即使在这些组内，也会很快地分配和调动。这是因为我们的规划方式是，每六个月，CEO、我、其他一些人以及资深负责人会坐下来，定义未来六个月需要实现什么。作为公司，我们必须完成什么？既包括结果，也包括关键项目。然后我们坐下来，浏览这个清单，说谁是 DRI，谁对此负责。这基本上就是我们分配 PM 工作的主要方式。所以经常地，我们刚刚在今天早上完成了一个规划周期，你会经常浏览这些清单，最后说，好，有件事在多个团队的路线图中是第二或第三优先级，感觉非常重要，谁负责？我们实际上没有负责人。然后我们会去找一个 PM，说，恭喜，这是未来六个月我们需要你交付的事情。很少是“你需要构建一个功能，它必须完全这样工作，做这件事”，而是比这更高层次一些。但你怎么去弄清楚需要实现什么，然后把你认为能引导这个的人映射上去？不是每个名字都是 PM，但在你经历这个规划过程时，绝大多数情况下是 PM，而且是那些拥有正确技能组合的 PM，无论更偏财务、更偏算法和推荐，还是更偏核心用户功能。

Yeah, we've just passed 20 PMs. We have, I think, 21 or 22 PMs in the building today, which for those following what trajectory is, is pretty small considering the volume of GMV that our sellers move. We're very loosely organized into three groups: buyer, seller, and what we would call trust and risk. So the folks looking after our standards, payments, safety, etc. And then within those broad groups, we basically reassign the PMs pretty regularly. So people have loose alignment. You might be broadly a growth PM or broadly work on discovery. But even amongst those groups, it gets allocated and moved around pretty quickly. And that's because the way we do planning is like every six months, the CEO, myself, some other folks, and senior leads will sit down and just define what needs to be true over the next six months. What do we have to get done as a company? Both in terms of outcomes and critical projects. Then we sit down and go through that list and say who's the DRI, who's accountable for that. And that's mostly how we end up allocating PM work. So quite regularly, we've just finished a planning cycle literally this morning, and you'll quite regularly go through those and get to the end and say, cool, there's this thing that's like second or third priority in a bunch of different teams' roadmaps that feels really important, who owns that? We actually don't have an owner for that. And we'll go and grab a PM and be like, congratulations, this is the thing we need you to deliver over the next six months. It's rarely you need to build a feature that works exactly this way that does this thing; it's a little more high-level than that. But how do you go and work out what needs to be true, and then you map the human beings that you think can guide that? Not every name is a PM name, but overwhelmingly when you go through that planning process, it tends to be PMs, and it tends to be PMs who have the right skill set vis-à-vis what it is. Whether it's more financial, whether it's more algorithmic and recommendations-based, or whether it's core user feature.

让我顺着你最后提到的那个具体线索，聊聊你招聘产品经理时看重什么。他还写了这样一句残酷的话：过去两年，有 31,832 人申请 Whatnot 的产品经理职位，我们只招了一个。

Let me follow that actual specific thread at the end there around what you look for in product managers that you hire. So he also wrote this brutal quote: in the last two years, 31,832 people applied to be a product manager at Whatnot. We hired one.

是的，没错。

Yes sir.

相当厉害。所以这里有几件事我想聊聊。一是你招聘的人，尤其是现在，你看重什么？你发现了什么？在 Whatnot 真正成功的 PM 身上，你觉得哪些需求在上升，哪些可能在下降？

Pretty great. So there's a few things here I want to talk about. One is just what do you look for in the folks that you hire, especially these days? What do you find? What's kind of like trending up in what you find you need in really successful PMs at Whatnot, and what's maybe trending down?

我可以告诉你什么肯定在下降。

I can tell you what's definitely trending down.

有些人在面试中花大量时间谈论那些对齐会议、推动对齐和利益相关者管理，因为确实有一类产品经理——我职业生涯早期肯定也是其中之一——他们的专长不是技术或客户导向，而是政治。所以那些自然倾向于推动对齐、建立关系的人……你知道，当被问到“告诉我一次你失败的经历”时，他们会说“哦，我没有让 CEO 及时了解某件事，导致了一次转向”，这绝对是一种反模式，而且这种趋势在下降。

It's folks who spend a lot of their time in their interviews talking about those alignment meetings and driving alignment and stakeholder management, because there's definitely a group of PMs—and I certainly used to be one of them earlier in my career—whose specialty wasn't technical or customer oriented. It was politics. So folks who tend to naturally lean towards driving alignment, building relationships... you know, tell me about a time when you failed, like, oh, I didn't keep the CEO up to date with something and that led to a pivot, is definitely kind of a thing that is a bit of an anti-pattern that trends down.

我们往往发现，在 PM 面试中真正出彩的是：在整个面试或案例研究过程中，我们能否看到宏观思维和微观思维？我认为系统大致是这样运作的。我能描述一个最终状态，但我能否几乎表现出一种急切，比如“这就是我如何快速验证它的方法，这就是我要推动完成的地方”。而且你对自己构建的东西是否具体？有很多人曾在 FAANG 或任何规模的公司工作，他们只是照看已有的东西，也许打磨了边缘，而不是说“我们被给了这个问题，我必须去提出一些独特新颖的东西，或者我必须通过复杂的变革来迭代”。但我在过程中做了决定，我们推进了，因为我认为在大型组织中，很容易随波逐流，而不一定成为变革的推动者或决策者，而这正是 PM 最终需要做的。

What we tend to find that really jumps in a PM interview is, over the course of your interviews or your case study, can we see both the macro thinking and the micro thinking? I think the system works something like this. And I can describe an end state, but can I almost exude impatience on, and here's how I would validate that very quickly. Here's where I would push to get that done. And are you specific about the things that you've built? There's an awful lot of folks who've worked at, you know, FAANG or any scale company where they babysat things that existed and they've maybe polished the edges of it, as opposed to the idea of saying we were given this problem and I had to go and come up with something unique and novel, or I had to really iterate our way through a complicated change. But I made decisions along the way and we moved, because I think it's easy in a very large organization with inertia to kind of go along with what's happening and not necessarily be an agent of change or be a decision maker, which is ultimately what you need PMs to do.

你刚才说的有一点，我最近请了 Elizabeth Stone 上播客。她是 Netflix 的首席产品和技术官，我问她最上升的特质是什么，她说的正是你最初说的，就是系统思维、大局观、思考更大的业务。她对此的建议是努力提升这一点，我想问你有没有其他建议。假设有人听到这个，你会说“哦，哇，我得提升我的系统思维能力”。她的建议是：从你的问题后退一步，想想“好吧，对我的经理来说，他们如何看待这个问题？这如何影响业务的其余部分？”你对如何培养这项技能、提升系统思维有什么想法？

There's something you said there that I just had Elizabeth Stone on the podcast. She's CPTO at Netflix, and I asked her what's the trait that is also most trending up, and she said exactly what you said initially, which was the systems thinking, thinking big picture, thinking about the bigger business. And her advice there is to work on this, and I want to ask you if you have any other advice here. Say someone hears this and you're like, oh wow, I got to work on my systems thinking skills. Her advice is take one click back from your problem and think about, okay, for my manager, how do they think about this problem and how does that impact the rest of the business? Thoughts on how somebody might develop the skill and get better at systems thinking?

我认为用“技能”这个词非常准确。我觉得你可以通过纯粹的心智练习来擅长它。你可以从小处着手。我在产品评审中经常问的一个问题是，当有人说“嘿，我们想跑一个实验”时，我会问“好，如果结果是绿的怎么办？如果结果是红的怎么办？”如果人们说“实际上我不知道我的策略会怎么改变”，那好，我们还没真正想过。所以停下来，做一下心智练习，想想它会如何运作。然后我认为同样地，如果你在脑子里做过心智练习，比如“如果我们对这个东西的使用量比预期多一千倍会怎样？”或者“这可能会产生哪些意想不到的连锁反应？”那么你就可以快速构建本地解决方案。在动笔之前，在写代码之前，先在脑子里开始做所有这些。我认为这实际上也能帮助人们更快地行动，因为我认为 PM 经常被拖慢的另一个原因是“哦，风险，哦，法务可能会，财务可能会，另一个团队可能会”。我们在内部使用的一个口号是“先知道，再行动”，意思是把可能出错的所有事情都想清楚。理解规模会在哪里崩溃。理解可能发生的事情，然后无论如何继续前进，因为如果你已经想过所有可能在大规模下发生的事情，你可能会预先避免其中很多。所以我真的很喜欢 Elizabeth 的那句话，但我的建议是：做心智练习，设想如果它被广泛采用会怎样。如果出了问题，会是什么问题？你不必解决所有问题。你只需要把它们都想一遍，然后你最终会解决比你想象的更多的问题。

I mean, I think the skill is exactly the right way to say it. I think you can get good at it from just a mental exercise. So you can do it in small ways. One of the things I ask a lot in product review when someone says, hey, we want to run an experiment, is okay, what do we do if it's green? What do we do if it's red? And if folks are like, actually I don't know how my strategy would change, like cool, we haven't really thought about that. So stop and go do the mental exercise of how it would work. And then I think it's the same thing of you can build quick local solutions if you have done the mental exercise in your head of, say, well, what would happen if we had a thousand times more usage of this than we expected, or what are the unexpected knock-on effects that this could have, and how do you just start doing all of that in your head before you get pen on paper, before you get code on the system. And I think it helps actually unblock people to move faster too, because I think the other thing that PMs are often slowed down by is like, oh risk, oh legal might, finance might, another team might. And I think one of the monikers we use internally is know then go, as in just think through all the things that could go wrong. Understand where scale will break. Understand the things that might happen, and then make the move on anyway, because if you've thought through all the things that could happen at scale, you're probably going to preempt a bunch of them. So I really like Elizabeth's quote there, but mine is just do the mental exercise of playing out if it gets really widely adopted. If something goes wrong, what will it be? You don't have to solve all of them. You've just got to think through all of them, and then you end up solving more than you think.

我喜欢这个。所以本质上不要只关注这个实验会不会有影响力，还要想想接下来会发生什么，再接下来会发生什么。如果这是真的……

I love that. So it's essentially don't just focus on will this be an impactful experiment, and think about what comes next and what comes next. If this is true...

就像，好吧，它动了。特别是在高增长环境中，你并不是在寻找 5% 的统计胜利，你是在寻找某种能彻底改变业务的东西，并且随着时间的推移会产生复利效应。所以你必须想清楚那是什么。

Like, okay, it's moved. Particularly in a higher growth environment, you're not really looking for a 5% stat win, you're looking for something that kind of totally moves the business, and that has kind of compounding effect over time. And so you just got to think through what that is.

你提到的另一件让你非常兴奋的 PM 运作方式的变化，是向 IC 工作的转变。PM 从这种大型组织管理世界转向实际做工作。谈谈这一点，以及这对产品管理角色意味着什么。

Something else you said that is changing in how PMs operate that you're very excited about is this move to IC work. PMs moving away from this kind of big org management world to actually doing the work. Talk about that and what that means for the role of product management.

我前面提到过一点，但在那种层级管理文化中，如果你作为 PM 非常成功，你会被提升为总监，然后突然间你就不能再亲力亲为了。你的目标只是教练和指导。所以我们把所有 A 级人才都提拔到不再做具体事情的位置。他们把时间都花在对齐上，花在指导团队和调整团队工作上。你会得到这种非常反复的开发过程：有人做了所有工作，经过评审，被告知不行，然后你就在评审中来回折腾。你可以看到我的伤疤。在我们的团队里，有经理，我想全团队大概有四五个管理其他 PM 的人。他们所有人都会把 90% 以上的时间花在 IC 工作上。我个人可能仍然有 50% 的时间在做 IC 工作。我认为这有几个真正的好处。首先，如果你是一个资深产品人，有十年以上、也许十五年的构建经验，希望你的直觉已经磨练得很好。你可以比其他人更快地做出决定，你可以非常非常快地产生真正的影响，组织里有这样的人真是太好了，而不是那种通过三层流程的想法——我们把问题分给几个 PM，那些人需要达成一致。不同的工程团队在争论，你往往就直接推进了。所以这很棒。

And I mentioned a little bit earlier, but there was this thing in the, you know, in the ratio land where what you did if you were really successful as a PM is you got promoted into being a director, and then all of a sudden it was like don't be hands-on anymore. Your goal is just to coach and guide. And so we took all of our A players and then promoted them out of doing things. And they spent all of their time in alignment, and they spent all of their time kind of coaching and tweaking what their team was doing. And you get this really yo-yo development process where somebody does all this work, it goes through review, it gets told no, and you're just kind of going back and forward in reviews. You can see my scar tissue coming through. On our team, everybody is like there are managers, there's like I think four or five people across the team who manage other PMs. All of them would spend 90 plus percent of their time doing IC work. I'm still probably 50% of my time doing IC work personally. And I think there's kind of a couple real advantages of it. The first is, if you are a kind of senior product person where you've got a decade plus, maybe 15 years of experience building things, hopefully your instincts as to what's going to work are fairly well honed at this point. You can just make decisions more quickly than people, you can have real impact very, very quickly, and it's really great for the organization to have somebody who can do that, as opposed to the idea of working through three layers of, you know, we divide the problem up amongst a couple PMs, those folks need to get into alignment. There's different engineering teams debating stuff, you just tend to go. So that's wonderful.

我认为第二点是，这种模式通过两种方式带来杠杆效应。其一，一位 VP 理论上能承担多位初级 PM 的工作量，因为他们效率更高，这意味着你在任何时间点都能看到更全面的局面，因此你更有可能做出直觉上正确的决策，比如如何调整发现算法以应对发货慢的卖家，这在电商领域是个永恒的话题。如果你在考虑如何管理发货慢的卖家，并且了解发现算法的力量，你无论哪种情况都能做出正确的决策。我记得困扰 Twitch 很久的一件事，我可能比任何人都更负有责任，就是发现团队和广告团队总是在争夺曝光量，对吧？广告在信息流里放哪里？对发现指标有什么影响？对广告收入有什么影响？我到 Twitch 后做的第一件事就是把广告放进发现里，并确保同一个 PM 对两者负责，因为他们会做出自然的权衡，比如目标是从信息流产生的 GMV。一个是通过自然流量，一个是通过付费替代。当你把同一个人放在多个事情上，他们往往会自然地协调这些事，你就省去了数月数月的来回沟通和那些把公司利益放在个人职业利益之前的政治斗争。让 VP 们主要做 IC 工作，让总监们主要做 IC 工作，甚至让我自己也要处理 IC 工作，这能让每个人都与真实情况保持联系，而不是在评审中看起来的样子。这也意味着你更有可能尽早做出直觉上正确的决策，因为为什么不希望梅西在你的队里，而不是总是让青训营来呢？

I think the second thing is there's two ways that ends up driving leverage. One is a VP can handle the workload of multiple more junior PMs just because they're more efficient, and that means you see more of the board at any given point in time, so you're far more likely to make the intuitively correct decision for how to tune the discovery algorithm vis-à-vis people who ship slowly, which is an evergreen thing in e-commerce. If you're thinking about how to manage sellers who ship slowly and you know about the power of discovery, you can in either case make the correct decision. One of the things that I remember plaguing Twitch for a long time, and I was probably one of the people more at fault than ever, was the discovery team and the ads team were always at war for impressions, right? Where do ads go in the feed? What's the impact on discovery metrics? What's the impact on ad dollars? One of the first things I did when I got to Twitch was just put ads in discovery and make sure that the same PM is accountable for both, because they're going to make the natural trade-off that says the goal is GMV generated from the feed. One is through organic, one is through a paid substitution. When you put the same person across multiple things, they tend to organically align those things, and you just cut out months and months of back and forth and the politics that tends to take it from being company-first to career-first. Having VPs mostly in IC land, having directors mostly doing IC work, even having me having to grapple with IC work, keeps everybody connected to the ground floor of what's actually true as opposed to what seems true in a review. It also means you're more likely to make the intuitively correct decision early, just because why wouldn't you want Messi playing for your team rather than trying to have the academy coming along all the time.

我很喜欢这个观点。那么当你谈到 PM 的 IC 工作时，在这个语境下，PM 的 IC 工作具体指什么？是指交付代码、构建产品，还是像管理团队、负责路线图、写战略文档这样的工作？

I love this. So when you talk about IC work for PM, what does IC work for PM in this context mean? Does it mean shipping code, building, or is it like running a team, owning a roadmap, writing the strategy doc?

想象一下是第二类。简而言之，就是任何能最有效交付产品所需的工作。我个人是否在 Whatnot 交付过一些生产代码？是的。但我认为那真的是我时间的最佳利用方式吗？并不尽然。我确信有人悄悄重写了我大部分代码，以确保代码规范正确、本地化工作正常，以及那些数十年软件工程经验教会你的、我和 Claude Code 都没能搞对的细微之处。但我确实认为，这始于：你是否真的在处理支持工单？你是否了解我们遇到的客户问题？你是否自己拉取了所有数据以便真正理解？你是否与工程和设计团队坐在一起？你是否直接查询过代码库以理解事物如何运作？然后你是否写了规格说明？你是否主持了站会？我认为这些都是核心的 IC 工作。

Imagine it's the second bucket. Whatever is required to most effectively ship is the short answer. Have I personally shipped some production code at Whatnot? Yes. Do I think that's really the best use of my time? Not really. I'm certain that somebody quietly reworked most of my code to make sure the linting was correct and the localization worked, and all the nuance that decades of software engineering has taught you that me and Claude Code did not get right. But I do think it starts with: are you literally in the support tickets? Do you know what customer problems we're having? Have you pulled all the data yourself so that you actually understand it? Have you sat with engineering and design? Have you queried the codebase directly to understand how things work? And then have you written the spec? Are you then running your stand-up? I think all of that is core individual IC work.

有很多人在产品领域一步步晋升，成为 VP，但回到 IC 角色并不让他们感到兴奋。有些人，显然你热爱它，你享受其中。很多人会说，我以为我已经完成了这个阶段，我可以只通过他人来工作，我可以思考大局。你对此怎么看？你会对那些处于这种情况的人说什么？

There are a lot of people that have worked their way up the ladder in product, become a VP, and it doesn't feel exciting to go back to being an IC. Some people, clearly you love it, you enjoy it. A lot of people are like, I thought I was done with this, I could just work through people, I could think big picture. How do you feel about that? What would you say to folks in that bucket?

我认为可能仍有很多组织认为那种模式非常有价值，他们会继续那样做。我招聘的人往往是那些说：“天哪，我以前热爱产品管理，但我厌倦了坐在对齐会议里，我到处向 CPO 和产品 VP 推销，问他们，难道你们不怀念真正做事的感觉吗？你们想回来吗？”我认为我们可以承认行业会出现分化。我确实认为有些组织规模足够大，可能让每个人都亲力亲为并不合适。我也认为你需要有与之匹配的文化来配合这种环境，在这种环境中，人们会说，我不想讨论它，我只想去做那件事。在很多方面，每个创业公司都是创始人的反映，所以这自然倾向于他们的思维方式以及他们想如何运营组织。但我实际上发现，在很多情况下，你去和那些在 Meta 做了五六年高级总监的人交谈，他们把所有时间都花在对齐会议上，他们怀念真正与客户交谈、与工程师交流、交付产品。

I think there are probably still a lot of organizations where that is really valuable, and they will go. My recruiting tends to be the folks who are, "Oh my god, I used to love product management and I'm so sick of sitting in alignment meetings, and I'm out there pitching CPOs and VPs of product to be like, don't you miss actually doing things? Do you want to come back?" And I think it's okay for us to acknowledge that there will be a bifurcation across the industry. I do think that there are organizations that are sufficiently large that maybe everyone being hands-on isn't right. I also think you have to have a matching culture to go with this kind of environment where that's the expectation, where people are like, I don't want to talk about it, I want to just go and do that thing. In a lot of ways, every startup is a reflection of their founders, so that naturally tends to be how they think and how they want to run the organization. But I've actually found that in a lot of cases, you go and talk to somebody who's spent the last five or six years as a senior director at Meta, who spends their entire time in alignment meetings, and they miss actually talking to customers and talking to engineers and shipping things.

这让我想到，我想你已经看到了那份名单，所有那些首席技术官都去 Anthropic 成为普通工程师。你说话的时候我调出了这份名单。Workday 的 CTO 现在只是 Anthropic 的技术人员。Instagram 的 CTO、Box 的 CTO、Super.com 的 CTO，他们现在都像工程师一样在 Anthropic。是的。如果这是我最大的愿望，那么 Whatnot 的产品团队基本上就是这样——所有这些拥有出色技能和深刻理解的人最终都作为 IC 来构建产品。

What makes me think about it, I imagine you've seen this list of all these chief technology officers that have gone to become just engineers at Anthropic. I pulled up this list as you were talking. The CTO of Workday is just a member of technical staff at Anthropic. The CTO of Instagram, Box is CTO, Super.com CTO. They're just like engineers now at Anthropic. Yep. If this is my greatest desire, that the Whatnot product bench basically looks like that—all of these people with great skills and great understanding actually end up coming and building as ICs.

那么这条路径的薪酬呢？你知道，人们梦想升到 VP，赚数百万美元。有没有可能既做到这一点又保持 IC 身份？

What about the comp of this path? You know, that's people's dream move up to VP, make millions of dollars. Is there a world where you can still do that and be an IC?

我实际上认为这更容易——这是个大胆的观点——你去算一下，让五个 L5 向一个 L7 汇报，然后四个 L7 向一个 VP 汇报，现在把那个产品组织的总薪酬加起来，然后回头说，如果我只有三个人呢？为什么我不能给他们都支付 D2 级别的 VP 薪酬，特别是如果他们能产生那些人所产生的影响？为什么不呢？

I actually think it's easier—spicy take—but you go and take the comp required to have five L5s reporting to one L7, and then four L7s reporting to one VP, and now total the comp of that product org, and turn around and say, what if I had three people? Why can't I pay them all D2 VP money, particularly if they're having the level of impact that those folks are having? Like why not?

为了完全理解为什么会发生这种情况，为什么应该发生，我所听到的，有很多组合。一是 AI 正在促成这一点，这很棒。时机正好。

And just to fully understand why this is happening, why this should happen, what I'm hearing, there's kind of many combinations. One is AI is enabling this, which is great. Perfect timing.

是的。

Yes.

这样做的其他动机是什么？仅仅是产品最终变得更好吗？还是人更少？

What are the other motivations to do this? Is it just the product ends up being better? Is it fewer people?

我当然认为产品最终会变得更好。长期以来人们一直告诉我们的一件事是，是的，那不会扩展。比如，哦，领导层不可能对正在发生的事情保持亲力亲为。你将需要去雇佣更多层级。

I certainly think the product ends up being better. One of the things that folks have been telling us for a long time is, yeah, that won't scale. Like, oh, leadership isn't going to be able to stay hands-on with what's going on. You're going to need to go and hire tons more layers.

我们发现事实并非如此，对吧？这需要不同的能力。你必须努力确保自己真正理解，比如，事实真相。我们经常用的一个例子是，在增长会议上，有人说：“哦，对，但那是欺诈。”然后你转身问：“你怎么知道那是欺诈？”哦，数据集里标着呢。好。你知道它是怎么被标注的吗？我猜是运营的人做的。好。你知道他们的标准操作流程或具体怎么标注的吗？不知道。好，那你就不知道它是不是欺诈。如果你这样追问一位非常有经验的产品总监，他们会说：“说得好，我不知道，我去查一下。”然后你最终必然会强化智能体用来标注数据的系统，因为突然有一个非常聪明的人，非常投入地去理解我们怎么做这件事，并帮助指导它。

And what we found is that's actually not true, right? It requires a different muscle. You have to make an effort to make sure you genuinely understand, you know, like ground truth. An example we use all the time is we'll be talking in a growth meeting and someone will say, "Oh, yeah, but that was fraud." You know, turn around and be like, "How do you know that was fraud?" Oh, it's labeled in the data set as fraud. Okay. Do you know how it gets labeled? I assume someone in ops does it. Okay. Do you know the SOP or how they label that? No. Okay. Okay, so you don't know it's fraud. Uh, and if you push, you know, a really experienced product director like that, they're going to go, "Good point. I don't. I'm going to go find out." And then you invariably end up strengthening the system that agents are using to kind of, you know, data label because suddenly there's a very smart person who's very invested in like understanding how we do that and helping guide it.

所以，那种“我们要做更少的事，但要把它们做到极致，并且让最优秀的人深入一线”的态度，意味着你在过程中解决很多问题，而不会最终做出大量妥协。我认为人们普遍认为，否则增长太容易掩盖所有问题。你变得更大，最终只是 Scaling（规模扩张），每个人都基于平均值工作。所以从文化上讲，你必须真正致力于，就像我有时说的，全力以赴做好少数几件事。向 Ron Swanson 致敬。然后把最优秀的人推到事情的最深处。实际上，随着时间的推移，你会发现这样做最终会更高效，因为你第一次就真正理解了事情的工作原理，并做出了最好的决策。

And so just that attitude that says like we're going to do fewer things. We're going to make sure we execute the hell out of them and we're going to kind of push our best people to be in the weeds everywhere means that you fix lots of things as you go and you don't end up kind of just making loads of trade-offs. And I think there's a general belief that like it's too easy otherwise for growth to hide all sins. Like you get bigger and you just end up scaling and everybody's kind of like working off of averages. So culturally I think you got to be really committed to like let's you know whole ass few things as I tend to say sometimes. Shout out Ron Swanson. uh and then push your best people to be really in the weeds of stuff. And actually what you find over time is you end up being more efficient by doing that because you actually understand how things work the first time and you make the best decisions.

然后，AI 为这一切提供了巨大的杠杆。我无法想象我作为初级产品经理时花了多少时间问工程师某件事有多难，为了帮助规划未来的事情而分散了实际开发速度。所以现在我可以坐下来，和 Claude 聊聊，大致了解工作量。我可以坐在那里，过一遍，比如感觉有些模态的碰撞，新用户打开应用时一定会遇到。你可以直接说，让我们加载信息流，告诉我谁在什么顺序看到什么内容的逻辑，以及这个功能什么时候触发，然后很快得到答案。而且，正如我之前所说，有足够资历和经验的人能够看出问题，说“你知道这很糟糕，让我们做个好决定，改变顺序”。我节省了启动会议、对齐会议、写 PRD 的一周时间、实验时间，所有这些，只因为有一个被授权去做决定的人。

And then listen AI huge leverage for all of this. I I can't think of how much time I spent as a junior PM asking my engineers how hard something would be and you know distracting actual velocity in order to help scope future stuff. So now I can sit and you know talk to Claude and understand roughly LOE's. Um I can sit there and go through and be like it feels like there's some car crash of modals that must be hitting new users as they open up the app. And you can literally just go through and be like let's let's load up the feed and talk to me about the logic of who sees what in what order and when does this thing fire and you can get answers really quickly. And having as I said before folks with enough tenure and enough reps that they can see that and say you know what that's bad. Let's just make a good decision and change the ordering of those. I've saved now a kickoff meeting, an alignment meeting, a week writing PRDS, experiment time, all of that by just having somebody who's kind of empowered to go and make a decision.

那么，回到那些想找产品经理工作的人，无论是新人——我们先不谈新人——而是那些经理、资深人士，他们觉得“哇，市场真的变了”。我们现在听到的一个大问题是，你需要适应回到个人贡献者角色，放弃你光鲜的头衔。对于这些正在找工作、苦苦挣扎的人，还有什么类似的建议吗？

So, coming back to people that are trying to get a job as a PM, uh whether you're new, let's actually hold off on new people, but people that are say managers, senior folks that are just like, "Wow, the market has really shifted." The a big thing we're hearing right now is you need to be comfortable with moving back into IC, giving up your fancy title. Is there anything more along those lines of just people looking for a job, struggling to find a job? Any other advice for them?

我的建议是，在你现在的角色中开始做个人贡献者的工作。回到基础，确保你承担一些实际工作，因为我认为保持这些技能敏锐是好的。我认为这也始于在内部推动这些事情。我敢打赌，如果你开始把那种生产力带回你现在的角色，可能对你在当前职位有帮助，同时也有助于你未来的发展。但显然网上有很多关于产品经理或工程师的讨论。我认为这很好，这是一个很好的技能去磨练。如我所说，我推过一些生产代码，因为我想通过练习来理解它。但我也认为，在你去构建东西之前，关键是你能多快回到正确界定范围、理解问题、定义什么是好的状态，并利用你拥有的规模和范围，看到更多并带来更多。

Start doing IC work in the role you're in would be my push. Like get back to the basics of like make sure that you're taking on kind of practical work because I just think it's like good to make sure that you're keeping those muscles, you know, well honed. I think it also starts with like pushing internally for those things. Like I I would bet that if you started bringing that level of productivity back into the role that you're in, probably helps you where you are in addition to kind of help you where you might move to. But I think there's a lot of chatter online obviously about like PMs or engineers now. And I think that's all well and good like it's a great muscle to go and go and hone. As I said, I've I've pushed some production code because I wanted to go through the exercise of understanding it. But I think there's also before you get to like building things, it's like how quickly can you get back into the muscle of scoping the correct thing, understanding the problem, being able to define what good looks like, and like take advantage of the scale and the scope that you've got that you can see more and bring more to things.

我认为大多数担任过总监以上职位的人都知道那种痛苦：坐在那里看着一个初级产品经理在同一个 PRD 上来回折腾，反复审查，而你其实知道答案是什么。不知从何时起，我们决定“引马到水边”而不是帮助他们理解答案然后继续前进。我认为我们的指导风格中有些东西可以回归，比如帮助别人相对快速地理解什么是好的，而不是无休止的审查循环。

Like I think most folks who've sat in a, you know, director plus role will know the pain of sitting there and watching a junior PM yo-yo back and forth on the same PRD back to review where you kind of know what the answer is. Somewhere along the way, we decided that, you know, lead a horse to water as opposed to kind of help them understand the answer and then keep moving. And I think there's like something in our coaching styles that we can get back to of like help somebody understand what good looks like relatively quickly as opposed to just endless review yo-yo.

你提出的关于产品经理不直接发布到生产环境的观点，我非常同意。我最近因为一位播客嘉宾改变了想法，他认为产品经理如果不在那里试图发布到生产环境，他们的杠杆作用会大得多。他们可以让团队更好更快地发布，并确保发布的东西更好，这比坐在那里自己发布东西更能利用产品经理的时间。

Uh this point you make about PMs not uh shipping to production, I so agree with this. My mind changed on this recently with a previous podcast guest um with this point that PMS already like the leverage PMs have so much more leverage if they're not sitting there trying to ship to production. They can enabling the team to ship better and faster and making sure the things that are shipping are better is a much better use of PM's time than sitting there shipping stuff.

这听起来很傻，但对我来说，经历提交代码的细节和那些对工程师来说习以为常的步骤，比实际弄清楚问题并能够描述它要花的时间长得多。所以，是的，好的实践是尝试并确保你在做某事，例如，我不想根据别人告诉我来判断我们的开发工具是否变得更容易。我会亲自去尝试，然后说“是的，这比上次我做的更容易”。但我确实认为，理解代码库然后与能很好执行的人交谈，可以让你走得很远。否则，你就会陷入每个工程师在 L4 级别时都学会避免的无数经典陷阱。

I mean this sounds really silly mate but like it takes me substantially longer to go through the minutiae of like getting g get commit and all of the kind of like pieces that are second nature to engineer aligned than it does to actually work out what the problem is and be able to describe it. So yes like good practice to try and you know make sure you're doing something uh for example I don't want to judge if our dev tools have gotten easier or not based on what someone tells me. I'm going to go and try it and be like yep that was easier than last time I did it. But I do think you can get an awful long way understanding the codebase and then talking to somebody who can actually execute well. You know, otherwise you're just going to get you're going to fall foul of like a thousand classic traps that every other engineer learned how not to do when they were in L4.

顺着这个话题再聊一下，AI 有哪些方式让你或你的团队能更快、更高效？除了原型设计——这对产品经理和产品团队来说是 AI 最明显的优势——还有哪些？可能排前三的、让你觉得“哇，这真的释放了我们的生产力”和“提升了我们工作质量”的，是什么？

So following that thread a little bit, what are some of the ways that AI has enabled you and or your team to move faster and be more productive? Other than prototyping, which is the very clear benefit of AI for PMs and product teams, what else? What are maybe the top three of like, wow, this has really unlocked our productivity and the quality of what we do?

我觉得第一个，毫无疑问是数据科学。你知道，我们内部用 Hex threads 之类的工具，我肯定还有其他类似的产品。但我觉得，在拥有这样的工具之前，作为产品经理，你几乎很难记得那段时光。有了它，你可以真正开始拉取非常细粒度的用户群组数据报告，可以抓取单个用户，听到报告后，真正理解——比如，拉取日志，帮我理解这个用户到底做了什么、看到了什么，有多少其他用户像这样，影响会是什么。然后突然间，你就能非常非常快地构建出相当有意义的敏感性模型，或者预测可能发生什么的预测模型、回归模型等等，这真的非常强大。

I mean, the first one I think by a country mile is data science. You know, we use Hex threads internally or whatnot. I'm sure there are other kind of comparable products. But I think it's almost hard to remember time as a PM before you had tooling like that, where you could genuinely start pulling very nuanced cohort reports of data, where you could kind of grab an individual user where you've heard a report, actually understand, you know, like, let's pull logs, help me understand exactly what this user did and saw, how many other users look like this, you know, what would impact be. And then all of a sudden you can build pretty meaningful sensitivity models or like forecasts of what might happen, regression models, etc., really, really, really quickly, which is like incredibly powerful.

我们发现的另一件事是，它帮助我们更快地发布产品，因为你能够比以前更快地发现回归问题，以及两个产品混合产生的奇怪连锁反应。我认为在非常庞大复杂的系统中，这总是会拖慢你速度的事情之一，比如发布列车之类的。但如果你构建了合适的 AI 工具，你就能很快发现回归问题，这基本上让人们可以放手去干。

The other thing that we found is it helps us move much more quickly with shipping things, because you can spot regressions and weird knock-on effects of two products intermixing more quickly than you used to be able to. And I think in really large, complicated systems, that's always one of the things that ends up slowing you down, like release trains and all of that, versus if you build the right AI tooling, you can spot regressions really quickly, which basically lets people just kind of go.

所以我不知道数据科学的未来会是什么样子，但我觉得作为产品经理，过去一年我和数据科学家交流的时间比职业生涯中任何时候都少，尽管我花在数据上、理解产品实际运作方式上的时间，可能比职业生涯中任何时候都多 10 倍。所以我觉得这一点非常强大。

So I don't know what the future of data science looks like, but I think as a product manager, I've spent less time in the last year talking to a data scientist than I ever have in my career, even though I've probably spent 10 times more time in data and understanding actually how the product's working than I have ever have in my career. So that one I think is really powerful.

第二个我已经提到过，就是别再拿代码库怎么运作这种问题去烦工程师，直接去和 Claude 聊，理解它，这真的很有帮助。你知道，我职业生涯早期常说，目标总是要在框和线的层面理解你的系统，哪个系统驱动哪个东西。现在，没有理由不去理解这些，或者理解更细的层面。

Second one I've already mentioned, which is like stop bothering engineers with how does the codebase work and actually just go and talk to Claude and understand it, which is really helpful. You know, I used to say early on in my career that the goal was always to understand your systems at the boxes and lines level, you know, which system drives which thing. And now there's no excuse not to understand that or a nuance layer.

但另一个，这可能非常 specific 到 whatnot，所以我不知道这对所有人都有帮助，但我职业生涯中很幸运能做的一件事，就是基本上做直播产品做了十年。所以能够发布产品，然后看着客户使用它，看着他们摸索出来，这总是很酷。所以我觉得人们通过 Listen Labs 和那一类产品，已经体验过看着别人使用你的产品。但我一直能够坐下来，看着人们第一次使用某个东西，经历那个新用户理解差距。

But the other one, and this might be very specific to whatnot, so I don't know that this will help everyone, but one of the things that I've been lucky to do in my career is basically worked on live products for a decade now. And so it's always been really cool to be able to ship a product and then watch a customer use it and watch them kind of figure it out. So like, I think people have just gotten this experience with like Listen Labs and others in that cohort of watching people use your product. But I've always been able to sit and watch people use a thing for the first time and go through that new user comprehension gap.

现在很多 AI 工具真正酷的地方在于，当他们在描述“哦，我遇到了问题”时，你可以实时看着代码库，弄清楚这到底是现在正在发生的 bug，还是理解差距，即它没有按预期工作。然后突然你就有了某人使用你产品的视频记录。你可以实时分析代码库，通过 AI 和代码库对话，理解到底发生了什么。这就像一个打了类固醇的反馈循环，因为突然间你就能实时知道客户那边、代码那边以及作为观察者的你这边到底发生了什么，这真的很酷。

What's really cool with a bunch of the AI tooling right now is as they're describing, oh, I'm having a problem, you can literally be watching the codebase live and work out, is that actually a bug that's happening right now, right now, or is that a comprehension gap where it doesn't work as expected. And suddenly you've got this video artifact of someone using your product. You can be analyzing the codebase in real time and you can be just talking kind of through AI to the codebase to understand what's actually happening. And it's this, it's like a feedback loop on steroids, because all of a sudden you know exactly what's going on customer side, code side, and observer side as a viewer in real time, which is really cool.

这听起来既棒又压力山大，要构建那样实时直播的产品。我想到了 Netflix，他们现在投资直播，那就像你十年来一直在做的事情，对他们来说那是多大的事。我知道规模不同，但是……

That sounds both awesome and very stressful, to be building products that are that live in real time. I think about Netflix, where they invest in live now, and that's just like all you've done for 10 years, and how big of a deal that was for them. I know the scale is different, but...

说实话，我在 whatnot 的第二周，我记得坐在一个房间里看……对于不熟悉的人，whatnot 是一个电商，主要是拍卖平台，一个直播电商平台。运行拍卖有多种方式，其中一种是所谓的“突然死亡”，就是计时器一结束就结束。否则，在经典拍卖环境中，如果有人在最后 5 秒出价，时钟会加回 10 秒。卖家可以决定他们想要哪种拍卖模式。我坐在那里看着一个卖家说：“这些太久了。我希望这个 7 秒计时器实际上是 3 秒，因为我想卖更多产品。”我看到办公室里的两个工程师互相看了看，说：“那是个配置。我们完全可以做到。”然后他们就去实时更新了，然后跳到节目聊天里说：“刷新你的应用。”然后突然间，砰，它就以那种方式运行了。我当时想：“酷，我和我的人在一起，我来对地方了。”因为那就是在直播环境中你能得到的响应水平。显然，AI 意味着很多人很容易就能做到。不是说我会那样碰生产代码，因为那是个灾难性的想法。但对于合格的人来说，这是个很棒的想法。

Honestly, my second week at whatnot, I remember sitting in a room watching... So whatnot, for those not familiar, is kind of commerce, largely auction platform, a live commerce platform. And there are varieties of different ways to run an auction, but one of them is what's called sudden death, which is like when the timer ends, it ends. Right, otherwise the classic auction environment, somebody bids in the last 5 seconds, it adds 10 seconds back on the clock. And a seller can decide what auction model they want. And I was sitting there watching a seller who was like, these are taking too long. I wish this 7-second timer was actually 3 seconds, because I want to move more product. And I watched two engineers in the office look at each other and be like, "That's a config. We could totally do that." And so they went and updated it in real time, and then jumped in the chat of a show and just said, "Refresh your app." And then all of a sudden, bang, it was operating that way. And I was like, "Cool. I'm with my people. I'm in the right place." Because that's the level of responsiveness that you can get in a live environment. And obviously AI means that that's really easy for lots of people to take on. Not that I would touch production code in that kind of way, because that's a disastrous idea. But the qualified humans, it's a wonderful one.

那太酷了。本期节目由 Mercury 赞助。Mercury 是颠覆性的银行服务，深受超过 30 万创业者的喜爱，现在还有 Command 功能。我使用 Mercury 已经超过 6 年了，从未想过离开。Mercury 基本上就是当银行由产品人而不是银行家打造时会发生的事情。他们让发送发票、转账、为团队成员设置虚拟卡变得如此简单，我敢说是很有趣。你的银行有 API、终端原生 CLI 或 AI 就绪的 MCP 服务器吗？我觉得没有。就在最近，他们推出了 Command，这是一个直接内置于 Mercury 的对话式界面，充当你的财务操作员。我一直在用 Command 转账、查看哪些类别花钱最多、分析现金流，就在今天，我用它查了过去一年从某个特定赞助商那里赚了多少钱。我就问：“过去一年我从 X 赚了多少？”10 秒后，我就得到了答案。这太酷了。访问 mercury.com 了解更多，几分钟内即可在线申请。Mercury 是一家金融科技公司，不是 FDIC 保险银行。银行服务由 Choice Financial Group 和 Column NA 提供，均为 FDIC 成员。

That is very cool. This episode is brought to you by Mercury. Radically different banking, loved by over 300,000 entrepreneurs, and now with Command. I've been a customer of Mercury's for over 6 years. I have never once thought about leaving. Mercury is basically what happens when banking is built by product people, not by bankers. They make it so easy, dare I say fun, to send invoices, move money around, set up virtual cards for folks on my team. Does your bank have an API, a terminal native CLI, or an AI ready MCP server? I don't think so. And just recently, they launched Command, a conversational interface built directly into Mercury, which acts as your financial operator. I've been using Command to transfer money around, to figure out what categories I've been spending the most money in, analyze my cash flows, and just today I used it to find out how much I've made from a specific sponsor over the past year. I just ask, "How much have I made from X over the past year?" 10 seconds later, I have an answer. It is so freaking cool. Visit mercury.com to learn more and apply online in minutes. Mercury is a fintech company, not an FDIC insured bank. Banking services provided through Choice Financial Group and Column NA, members FDIC.

回到数据科学这个话题，我有个朋友是数据科学家，他说因为这件事，现在数据科学家的日子不好过。再补充一点细节，以前他们的时间是被要求做数据分析、处理数据，然后回来汇报结果，说‘这是结果，我对这个结论有信心’。现在他们的时间基本上是在看非数据科学家做的半吊子数据科学工作，然后就是‘帮我看看这对不对’，而且一半时间都是错的，他们就会想‘我现在到底他妈是干什么的？’这很糟糕。

Coming back to this data science point, I had a friend who's a data scientist and he said it's a rough time for data scientists because of this exact thing. To add a little more color, basically their time used to be asked to do some data analysis, do some work with the data, come back, here's the results, here's I'm confident in this conclusion. Now their time is basically seeing half-assed data science work from non-data scientists and just like 'show me is this right' and half the time it's wrong and they're like 'what the hell is my job now?' It sucks.

是的。听着，我对这种情况深有感触，因为我确实见过。这也再次说明为什么拥有更少但更资深的产品经理是有帮助的，因为有些人见过更多这样的重复，并且理解。但我也认为，很多时候这种缺乏清晰度来自另一个方面，那就是组织在历史上对数据工程、数据结构、良好的数据标注投入不足，不仅是你是否把分类法搞对了，还有你是否真正理解你的数据系统和结构是否设置得当。所以我们发现，我们很多最优秀的数据科学家正在朝这个方向努力，比如，我们是否真的正确更新了所有追踪和归因的方式，这样人们就不太容易误解这些数据。然后，是的，使用 AI 工具查找数据，就像使用 AI 工具编写代码一样，并不能免除你确保这是好的分析、好的代码的责任。它只是倾向于为那些天生倾向于这样做的人提供杠杆。

Yeah. Listen, I have a lot of empathy for that because I've certainly seen it. Another plug for why having fewer more senior PMs is helpful, because there are folks who've seen more of those reps and understand. But I also think a lot of the time that lack of clarity comes from the other thing, which is organizations have historically underinvested in data engineering and data structures and good data labeling, and whether or not you've got your taxonomies right, but also whether or not you really understand whether your data systems and structures are set up well. And so what we found is a lot of our best data scientists are pushing in that direction of like, are we actually correctly updating all of the ways in which our tracking and attribution works so that it's less easy for people to misunderstand those. And then yeah, using an AI tool to find a piece of data, much like using an AI tool to write code, doesn't absolve you of responsibility to make sure that that was good analysis, good code. It's just tends to be leveraged for those people who are naturally inclined that way.

那么考虑到这些不同的职能，数据科学、用户研究、设计、工程、产品管理。到目前为止我听到的是，我们可能需要更少的产品经理，需要更少的数据科学家。你认为还有其他角色会呈下降趋势吗？有没有哪些角色呈上升趋势？比如‘哇，我们会需要很多这样的人’。

So thinking about these different functions, data science, user research, design, engineering, PM. What I'm hearing so far is we'll need probably fewer PMs, we'll need fewer data scientists. Are there any other roles that you think they'll be trending down in terms of we'll need, and are there any roles trending up? Like wow, we're going to need a lot more of this kind of person.

嗯，有趣的是，正如我所说，我有一段时间没和数据科学家聊过了。我们当然还在大量招聘，因为我确实认为所有那些追踪、归因和衡量都非常非常强大。我也认为，我们说需要更少的一个方面是，同样的产出需要更少的人，但这并不一定意味着宏观上更少，因为如果你正确使用这些系统，你就能更快地成长。你可以构建更多东西。你可以承担更多任务。所以，你知道，如果最终净减少，我实际上会感到惊讶。我认为这更像是相对于客户影响而言的净减少，对两者都是如此。当然，我认为在这些角色中，随着时间的推移，有一种趋势是上升的，那就是……我不记得人们过去使用的确切标签，但就是这种技术负责人的概念，有点像混合型工程经理，你管理一个非常小的团队，快速推进事情。因为就像我们说的，尝试某件事的成本已经下降，你可以有核心焦点，这是我们非常重视的，我们也发现孵化很多小团队，让他们去角落里尝试构建这个东西。去试试吧，虽然不是完全的原型设计，但就像是去尝试我们历来认为太难的事情，这变得越来越便宜，而且杠杆率越来越高。所以，工程经理轻量版，如果有个更好的说法的话，是我绝对认为我们会越来越多看到的东西。它不完全是技术员工，虽然那一定很好。但肯定不是那种完整的工程经理角色，我认为这种角色肯定会更频繁地出现。

Well, funnily enough, as I say, I haven't spoken to a data scientist in a while. We've certainly still hired plenty because I do think that kind of all that tracking and attribution and measurement is really really powerful. I also think one of the flip sides of we say we need fewer is like fewer of for the same output doesn't necessarily mean fewer in macro, because if you are using these systems right, you can just grow more quickly. You can build more things. You can take on more stuff. So, you know, I would be surprised actually if we ended up with like net fewer. I think it's more like net fewer vis-à-vis customer impact for both. Certainly I think kind of like trending up over time within these roles are these kind of like, and I don't remember the exact label that people used to use, but this idea of like tech leads that are kind of like a hybrid EM where you're running a very small team kind of running at things, because the same way that we'd say you know the cost of trying something has come down, the idea that you can have kind of core focus, which is a thing we're very big on, we've also found incubating a lot of smaller teams to kind of go over and sit in the corner and just try and build this thing. Go and you know it's not quite prototyping, but it's like go and take a swing at a thing that we've historically thought was too hard is getting cheaper and increasingly has very high leverage. So the idea of like engineering manager light, for one of a better term, is a thing that I'm definitely think that we'll see more and more of. It's like not quite the technical member of staff, although that must be lovely. Um, but certainly not the kind of like full-blown EM role, I think is one that definitely will come about more often.

那么也许为了结束这部分对话，现在有一种趋势，每个人都是某种意义上的构建者。产品经理在交付一些东西，变得更像工程师，工程师在承担更多产品经理的工作。你认为这在未来几年会如何发展，从产品团队的整体形态来看？仍然是产品经理、工程师、设计师、数据科学家这样的组合吗？你如何设想未来几年典型的产品团队？

So maybe just to close the loop on this part of the conversation, there's this trend towards everyone's kind of a builder. PMs are shipping a little bit, being a little more engineer, engineers are taking on more of the PM work. How do you think this just kind of maybe plays out over the next couple years in terms of what product teams look like broadly? Is it still PM, engineers, a designer, data scientist somewhere? Is there how do you kind of envision the canonical product team over the coming years?

好问题。我不知道它在所有地方会是什么样子。我认为在 Whatnot，它可能仍然和历史上差不多，你知道，有理由拥有专业的设计师、专业的工程师、专业的产品管理。我认为那些非常具体的团队将在很大程度上保留给非常具体的项目，或者那些我们有高度信心或信念需要解决的问题，或者我们非常有信心在某个场景中有前进路径并希望取得良好进展的事情。我认为在边缘地带，会有更多自由空间让人们去尝试，比如，‘嘿，我相当确定我可以去对这个东西做出有意义的改进。’不管你是设计师、工程师、产品经理还是数据科学家，你都可以，也应该去做，对吧？如果你周五下午坐在那里，无法专注于你正在写的产品需求文档，但你相当确定你可以去修复某个东西，那就去做吧。所以我认为它可能不会在更正式的意义上发生转变，但我确实认为，对于那些精通客户问题、精通代码库、并理解一些宏观背景的人来说，会有更多的自由空间，他们将被赋予权力去做越来越多的事情。

Great question. And I don't know that I know what it looks like everywhere. I think what it'll look like at Whatnot is it probably still looks mostly like it has historically, which is you know there are reasons that you would have a specialist designer, specialist engineers, specialist product management. I think those kind of very concrete teams will largely be reserved for like very specific projects or like things that we have high confidence or conviction that we need to solve or we're pretty high confidence conviction that we have a path forward on a scene and we want to make good progress. And I think at the edges around that, there's going to be a lot more free space for people to play on like, hey, I'm reasonably sure I can go and make a meaningful improvement to this thing. And it doesn't matter if you are a designer, an engineer, a product manager, a data scientist, you can and you should, right? If you're sitting there on a Friday afternoon and you can't focus on the POD you're writing, but you're pretty sure you can go and fix something, go for it. And so I think it probably doesn't morph in the more formal sense, but I do think there's just a lot more free space for people who are well-versed in the customer problems, well-versed in the codebase, and understand some of that macro context will just be empowered to do more and more things.

两、两年半前，我发过一篇文章，说为什么产品经理是科技行业在 AI 时代蓬勃发展的最佳角色。我觉得，即使我们对话的开始是‘我们应该生活在一个后悔有产品经理存在的世界’，我感觉我们同意这个观点，即那些似乎最重要、最有价值的技能，无论是产品经理、工程师还是设计师来做，都是非常产品经理式的技能。我分享这篇文章中的几个例子，比如，谁真正擅长这些事情：确定要构建什么，提炼和传达需求，为最高 ROI 的机会优先排序每个人的想法，提供设计反馈以提高影响力，制定上市策略，理解商业策略。对我来说，这就是产品经理所做的，而且感觉这变得越来越重要。所以我想问你的问题是，你是否同意这个观点，即随着 AI 承担构建工作，产品经理技能似乎是最有价值的？

Two, two and a half years ago, I had this post I put out where I said why PMs are the best positioned role in tech to thrive in an AI world. And I feel like even though the beginning of our conversation was like we should live in a world where we regret PM exists, I feel like we agree on this idea that the skills that seem to matter most and are going to be most valuable, whether it's a PM doing them or an engineer or designer, is very PM-y skills. I'll share a few examples from this post, like what do we, who is really good at this stuff, these things: identifying what to build, distilling and communicating requirements, prioritizing everyone's ideas for the highest ROI opportunities, giving feedback on design to improve impact, developing go-to-market strategy, understanding business strategy. Like to me this is what PMs do and it feels like that's becoming more and more important. So I guess the question to you is, do you agree with this idea that the PM skills seem to be the most valuable now as AI takes on the building?

完全同意，也为你拿出实据、还带时间戳点赞，朋友。干得漂亮。

Definitely agree, or also props for bringing the receipts even with a time stamp, my friend. Well done.

嗯。我想在此基础上补充的是，我认为那些核心的产品经理技能，未必是过去 5 年里我们奖励产品经理的东西，相比之下，讲故事、对齐、战略才是。所以我确实认为你说得 100% 正确：我能不能真正理解客户？我能不能真正理解业务？我能不能真正理解技术？并且能不能把这三者高效地翻译整合起来？当做事成本变低、尝试成本变低时，这就是杠杆点。所以绝对同意，产品技能可能是最持久的。我的补充只是说，有很多顶着产品经理头衔的人，在过去 5 年里并没有花太多时间打磨这些技能，但非常擅长向领导层传达框架。所以我只是想把我们作为一个职能拉回到核心工作上。

Mhm. I think what I would build on that is to say that I think those core PM skills aren't necessarily the things that we have rewarded PMs for over the last 5 years versus storytelling, alignment, strategy. And so I do think you're 100% correct that, like, can I genuinely understand the customer? Can I genuinely understand the business? Can I genuinely understand the tech? And can I translate the three together for optimal efficiency? That is the point of leverage when doing things gets cheaper, trying things is cheaper, etc. So absolutely agree that product skills are probably the most durable. My build would just be that there's a lot of people who have the title PM who haven't spent a lot of time building those skills in the last 5 years but have gotten really good at communicating frameworks to leadership. And so I just kind of push us back as a function into that core work.

是的。Marty Kagan 称之为“产品表演”。很多人只是做产品经理该做的事的表面功夫。

Yeah. Marty Kagan calls this product theater. A lot of people just do the things that PM should be doing.

听着，我也有罪。我们长期奖励这种行为。所以产品表演成为很多人的核心技能，我并不意外。我只是觉得，这已经没什么藏身之处了。

And listen, I'm guilty of this. We rewarded it for so long. That it doesn't surprise me that product theater is a core skill set for a lot of folks. I just think that there's not a lot of place to hide in that anymore.

这就回到了那 3.2 万人申请工作的事。我猜其中很多人是自认为是产品经理、或者头衔是产品经理，但并没有——但正是你描述的那种人。他们主要专注于对齐、写文档、开会之类的事，而不是真正去构建、去理解打造成功产品需要什么。是的。很多人在产品面试中表现很好，Lenny，然后你给他们一个案例研究。每个在 Whatnot 被录用的人，无论什么职位，都要做一个实际动手的案例研究。但有多少人展示得非常好，然后你给他们一个提示和一些数据，让他们带着对某事的观点回来，然后我们让他们口头辩护。那些擅长表演但不擅长细节的人，思维崩溃得有多快，我觉得这很能说明问题。

And this comes back to that 32,000 people applied for jobs. I imagine a lot of that is just people who think they're PMs or have the title PM but don't have—but are exactly what you described. They just focus a lot on alignment, writing docs, meetings, things like that, and not actual building, understanding what it takes to build a successful product. Yeah. The number of people who do really well in a product interview, Lenny, and then you give them a case study. So everyone who gets hired at Whatnot in any role has to do an actual hands-on case study. But the number of people who present incredibly well and then you give them a prompt and some data and ask them to come back with a POV on something, and then we make them verbally defend it. How quickly the thinking decays from folks who are good at the theater but not the specifics is kind of really telling, I think.

好的。那么，超越招聘这一步，假设你雇了人，关于如何从你雇佣的人身上获得最大价值，你学到了哪些东西？你提到了这种反直觉的观点，你不同意“雇佣优秀的人，然后别挡他们的路”。所以我想多听听这个，还有没有其他关于打造一个非常成功的世界级产品团队的经验？

Okay. So kind of going beyond the hiring step, say you hire somebody, what are some things you've learned about how to get the most out of the people you hire? You mentioned this kind of contrarian take that you don't agree with this 'hire great people, get out of their way.' So I want to hear more about that, and just is there anything else you've learned about just elements to building a very successful world-class product team?

我的意思是，需要细微差别。我会说，“雇佣优秀的人，然后别挡他们的路”是错的。但可以在此基础上补充几点。我认为总的来说，“雇佣优秀的人，然后别挡他们的路”变成了一种宏观说法，意思是“让他们自己制定路线图，让他们自己找出问题”，完全放任自流。而我认为真正的答案是，显然你雇佣的人越好，你就越能完全信任他们知道自己在做什么。但我们往往生活在“先验证后信任”的领域，而不是“完全信任”甚至“信任但验证”。也就是说，我可能比我的任何直接下属都更能理解我们系统中所有不同部分——买家或卖家、信任——如何组合在一起。他们几乎肯定比我更能理解这些个别功能如何运作的细微差别。你知道，如果今天有人考我 Whatnot 发现模型中的所有权重，我肯定会答错，相比那个团队的任何工程师，相比那个团队的任何产品经理。但随着时间的推移，我确实有责任去学习和理解这些，因为我在要求他们做决定，而我在验证他们做的事情。所以，花时间真正与那些团队并肩工作，深入一线，尝试解决一些问题，真的非常强大。我加入 Whatnot 时最早看到的一件事，也是我看到我们的创始人兼 CEO Grant 做的，就是他会坐在评审会上说，“我觉得这不对”，然后他会停顿一下说，“我要清空今天剩下的时间，我们坐下来弄清楚。”他最后真的会和团队坐在一起，通过——你知道，再说一次，用 AI 数据工具更容易——我们真的拉出工单，真的拉出代码，逐行查看数据，理解实际发生了什么，以便我们能在那里做决定。这意味着他对正在发生的事情非常了解。在文化上为团队定下了基调，那就是我们只是在寻求真相。这使它变得非常像“我们 vs 你们”。有一段时间，评审变得非常“听好话”，作为产品经理，你只想得到绿灯，这样你就可以回到你的工程师那里说，“我有信誉，我能让 CPO 批准我们正在构建的东西”，而不是这种想法：我们只是在试图找出正确答案，理论上每个人都希望我们得出正确答案。所以，你知道，我们用规划来让公司对齐，比如我们必须解决的重要事情是什么。这主要是一个资源讨论，对吧？如果我们选对了事情，对它们进行排序，最终我最负责的是确保我们在正确的地方有正确的资源来达成目标。但如果我只是把任务委派给团队去弄清楚，而不是定期和他们深入探讨具体如何运作，我就不知道那些是否是正确的地方。你知道，我们的推荐如何运作？具体来说，欺诈可能用什么逻辑来基于地址信号使一个失效？我们如何计算地址信号？那是像 Google 标准化之类的东西，还是像输入的免费文本？如果你不真正把自己放低，与你的 IC 工程师、IC 设计师和 IC 产品经理并肩工作，你实际上不会知道那些东西。所以，没有微观，你就无法做出好的宏观决策。因此，我越来越觉得，我推动自己努力成为 T 型人才。我可以在需要时非常深入，但大多数时候我在各个部分都很广泛。我认为，仅仅雇佣人，然后不再问任何问题，把所有细节都委派出去，并不是从组织中获得最大价值的最成功模式。

I mean, nuance required. Like 'hire people and get out of the way' is wrong, I will say. But a couple pieces to build off of it. I think in general, 'hire great people and get out of their way' became this kind of macro saying for 'let them work out what the roadmap is. Let them work out what the problems are.' Just completely devolve, you know, like what's going on. And I think the real answer is obviously the better people you hire, the more you can kind of totally trust that they know what they're doing. But we tend to live in a 'verify then trust' land, as opposed to a 'totally trust' or even 'trust but verify.' Which is like, I'm probably in a better position than any of my directs to understand how all of the different pieces of our system—buyer or seller, kind of trust—fit together. They're almost certainly in a better position than me to understand the nuance of how any of those individual features work. You know, if somebody quizzed me today on exactly all the weightings in the Whatnot discovery model, I would definitely be wrong, vis-à-vis any of the engineers on that team, vis-à-vis any of the PMs on that team. Good. But it's actually kind of incumbent on me to learn that and understand that over time, because I'm asking them to make decisions and I am proving things that they're doing. And so time spent actually working alongside those teams, like in the trenches, trying to solve something, is really, really powerful. One of the things that I saw earliest when I joined Whatnot, that I've seen Grant, who's our founder CEO, do, is he'll sit in a review and be like, 'I don't think this is right,' and then he'll pause and say, 'I'm going to clear the rest of my day. Let's sit and figure it out.' And he'll actually end up sitting with the team and going through—you know, again, easier with AI data tools—let's literally pull up the tickets. Let's literally pull up the code. Let's go through the data line by line and understand what's actually happening so that we can make a decision there. And it means he's very up to date with what's going on. Kind of very culturally sets the tone for the team that we're just seeking truth. And it makes it very much a 'us versus you' thing. Like reviews got very into 'listen for yes' for a little while there, where all you're trying to do as a PM is just get a green light so that you can go back to your engineers and say, 'I have some credibility. I can get the CPO to approve what we're building,' as opposed to this idea that says we're just trying to find out the right answer, and in theory everyone wants us to come up with the right answer. So, you know, we use planning to align the company on like what are the really important things we have to solve. That's mostly a resourcing discussion, right? Like if we pick the right things, stack rank them all, ultimately I'm most accountable for making sure that we have the right resources in the right places to hit things. But I don't know if those are the right places if all I do is delegate to the team to go figure it out and I'm not actually periodically very deep with them on like exactly how does that work. You know, how do our referrals work? Literally, what is the logic that fraud might use in order to invalidate one based on address signals? How do we calculate address signals? Is that like a Google normalized thing or is that like free text that's put in? And if you don't actually push yourself down to sit alongside your IC engineers and your IC designers and your IC PMs, you don't actually know that stuff. So you can't make good macro decisions without the micro. So increasingly, I think, I push myself to try and be T-shaped. I can go very, very deep when required, but I'm mostly broad across pieces. And I think the idea of just hiring people and then not asking any more questions and delegating all of the detail just isn't really the most successful model for getting the most out of an organization.

面对一位非常有产品思维的创始人，CPO 这个角色对人们来说通常非常具有挑战性，因为你基本上是这个在非常有主见的创始人和构建它的团队之间的人。

With a very product-minded founder, CPO classically is a very challenging role for people because you're basically this person between a very opinionated founder and the team building it.

你发现什么方法能营造一个让你在这个角色中感到快乐的环境？

Uh what have you found works in creating a you know environment where you are happy in that role?

是的，有意思的是，这其实占据了我职业生涯的大部分时间。我连续为三位创始人工作过，他们都很有产品思维。而且我实际上有两位创始人，这算是种福气。总的来说，我尽量不重复劳动——如果 Grant 或 Logan 我们的创始人已经在处理某件事，那可能就不需要我了。多一层有什么好处呢？嗯，你知道，我们团队里有个产品经理开玩笑说这叫“两个爸爸问题”——就是有两个人发出互相冲突的指令，或者有人想审查，然后你做了所有工作呈现给我，回去之后又得到不同的反馈。所以我的第一原则是：如果 Grant 或 Logan 在管某件事，我会确认他们在关注、他们对此负责，然后我就退出。所以会有很长一段时间，我团队里整整一半的人可能在忙某件事，而我无法告诉你它每天进展如何，因为它在 Grant 那里、在 Logan 那里，这完全没问题。我不必了解他们做的所有事情。我们只需要确保有人在提升标准。所以我们花了很多时间做这种对齐。

Yeah, I mean kind of funnily that's been most of my career actually. I worked for three founder founders in a row who are all kind of very product minded. Um and whatnot I've got two which is a blessing actually. In general uh I try not to kind of double up if you know Grant or Logan our our founders are on a thing probably doesn't need me. Like what's the advantage of an extra layer? Um, you know, I think jokingly one of the PMs on the team has referred to it as the two dads problem where you've just got like two people issuing kind of like conflicting instructions or somebody wants to review and then you do all this work to present it to me and then you go back and it gets a different thing. So my first thing is like if Grant or Logan are on it, I check that they're watching it, they're accountable for it and I step out. So there'll be long periods of time where like fully half my team can be working on something and I couldn't tell you day-to-day where it is because you know it's with Grant, it's with Logan and that's totally fine. I don't have to be across all of the things they're doing. We just need to make sure that there is somebody doing that bar raising. So we spend a much time doing that alignment.

第二点是，归根结底，如果你在创始人公司做产品负责人，你必须明白这不是你的公司，而是他们的。你只需要找到合适的平衡点，比如：嘿，你对这个反馈持开放态度吗？你已经下定决心了吗？你对这个推动开放吗？然后你就和伙伴们找到那种节奏。总的来说，在我们这个行业，创始人领导的公司做得这么好是有原因的。首先，创造产品所需的洞察力和客户直觉往往非常重要。然后我只是把我的工作看作确保我们在创始人关注的领域有覆盖。

I think the second one is like ultimately if you are a product leader in a founder company, you have to understand it's not your company, it's theirs and you just find the right balance of like you know hey are you open to feedback on this? Have you made up your mind? You know, are you open to a push on this? And you just find that rhythm kind of working with folks. Generally speaking, you know, there there's a reason that founderled companies do so well in our industry. You know, the insight required and the kind of customer intuition to make the thing in the first place and work tends to be really important. Um, and then I just view my job as, you know, making sure that we've got coverage on the places where our founders are.

太棒了。所以你在这里学到的关于构建的几件事，我认为在消费领域尤其重要——这与人们可能认为的运作方式相反，你发现最好的团队、公司、产品最终来自自上而下的创始人几乎……你知道，微观管理对很多人来说是个贬义词，但基本上深入细节——尽管人们可能怎么感觉，这实际上最终会带来更好的东西。

Awesome. So a couple things you've learned here for building and this I think in consumer this is especially important is uh counterintuitively to how maybe people think things should work you're finding that the best teams companies products end up coming from top down founder almost you know micromanagement is a is a dirty word to a lot of people but it's basically being in the weeds is uh in spite of how people may feel this actually ends up being leading to better stuff there

自上而下管理如果领导层足够优秀，能深入细节并具体正确，那就会奏效。我认为它崩溃的地方在于你并不真正了解底层事实，然后你试图从上面管理人们——这就是“微观管理”这个词的来源。否则，如果你基于相同的数据并且拥有这些数据，我不知道有哪个初级工程师或入门级设计师会不高兴坐在那里和 CPO 或 CEO 一起工作并发布产品，因为你只是被解除了阻塞。没有对齐会议，没有其他事要做。我还发现，如果你真的在细节中，你可以给出更好的反馈。我认为微妙之处在于如何确保你能在足够多的地方做到这一点。从来没有比现在更好的时机去尝试深入细节，因为你可以实时查询它。

Topown works well if leadership is good enough to be in the weeds and be specifically correct. I think where it falls apart is where you don't actually know ground truth and then you attempt to manage people from above and that's where I think the term micromanagement comes from. Otherwise, if you're working from the same data and you have it, I don't know a junior engineer or a entry- level designer who isn't stoked to sit there and work alongside the CPO or the CEO and ship something because you're just unblocked. There's no alignment meetings. There's nothing to do. I also find that like you can give way better feedback if you're literally in the detail. And I think the nuance is just like how do you make sure you can do that in enough places. There's never been a better time to be in to attempt to be in the detail on things because you can literally query it in real time.

我认为这是这里非常重要的一个细微差别。这个故事讲得很有力。Grant 就是那种“好吧，我要清空我的一天，我要花时间深入这些东西”的想法。这感觉像是高层做出微观决策的一个非常必要的要素，因为正如你所说，如果他们不了解所有细节，他们就不是基于真实数据做决策。而我们可以做到这一点，因为正如我所说，我们规划我们要做的事情，然后分配资源，然后分工攻克。所以他可能同时专注于三四个最重要的事情，你知道，他是 CEO，他会拍板说“这些是我现在负责的四件事”，然后我会说“太好了，那我就在那边”。然后在这些事情中，我一天中还有什么比完成我承诺这半年要完成的五件事更重要的事呢？如果除了招聘、例会之类的，其他都可以清掉，并为团队定下基调：在我们理解它之前，我们无法做其他任何事。

I think that's such an important nuance here. The story told is so um powerful. This idea of grant just okay I'm going to clear my day. I'm going to spend time going deep on this stuff. that feels like a very necessary ingredient for someone at the top to be making micro decisions because to your point if they don't have all the details they don't they're not making a decision out of real data and we can do that because you know as I said we we plan what we're doing and then we allocate and then we're dividing and conquering so like he's probably trying to nail three or four most important things at a time and you know he's the CEO he's going to call the ball and say these are the four things I own right now and I'm gonna be like great I'll be over here then and then within those Like what am I doing with the rest of my day that is more important than nailing the five things I've said will get done this half. Like if it's anything other than maybe hiring, standing meetings, any of that stuff, you can just clear it and set the tone for the team that like until we understand it, we can't do anything else.

假设有人在找 CPO 角色或第一个 PM 角色，情况类似，基本上是为创始人工作。你对他们有什么建议，让他们能找到一个快乐的地方，而不是因为这种中间层而超级沮丧，在那里他们实际上没有任何自主权？

Say somebody is looking for a CPR role or a first PM role, kind of similar, basically working for a founder. uh what would be your advice for them to land in a place where they're happy and not just super frustrated by by this kind of middle layer where they just don't actually have any agency.

是的，我认为第一件要弄清楚的事情是：你为什么想要这个角色，对吧？有一种想法是，CPO 的工作就是决定所有路线图之类的事情，但我有个坏消息要告诉你：这并不完全正确。但我觉得这也归结为花时间和那个人相处，弄清楚我们如何就某个话题进行深入讨论？他们喜欢怎样被推动？不喜欢怎样？然后你会花很多时间进行校准。所以在我加入 Whatnot 之前，我记得 Grant 和我大概喝了五六次咖啡，我们讨论如何让这种类型的团队前进？如何处理这些事情？然后我显然经历了一系列面试，最后去了洛杉矶，当时 Grant 和 Logan 在那里，我和他们待了一整天，就在一个房间里，讨论几个不同的问题，谈论路线图中的不同事情，真正深入进去。在那过程中，我尽量做最普通的自己，而不是面试状态下的自己，如果你明白我的意思，因为你得问自己：我真的想把所有时间都花在这种讨论和辩论上吗？但我喜欢做 CPO 或产品负责人，因为在很多方面，我所做的是帮助把那种愿景和直觉转化为现实。然后你知道，学会如何在不与对方竞争的情况下推动对方，这是一门艺术。我见过很多次 CPO 和 CEO 的关系恶化，最终 CPO 与 CEO 争夺愿景，最后陷入僵局，而我认为那不是你的工作。

Yeah, I mean I think the first thing you've got to work out is like why do you want it, right? There's this idea that like the CPO's job you get to decide all of the road maps and all those things and I've got bad news for you that's like not strictly true. But I think it also comes down to like spending some time with that person to work out like how do we jam on a topic? How do they like to get pushed? How do they not? And then you spend a lot of your time calibrating. So like before I joined whatnot, I think Grant and I had like five or six different coffees where we talked about like how do you get, you know, this type of team to move? How do you work on those things? And then I obviously went through a series of interviews and actually came down to kind of LA where Grant and Logan were based at the time and spent a whole day with them just like in a room going through a couple different problems, talking through different things in the road map, just like really getting into it. And I tried through that to kind of be my most ordinary self as opposed to like interview self if that makes sense because you kind of got to ask yourself, do I really want to spend my whole time like having this discussion and this debate? But like I like being a CPO or kind of a product lead because in a lot of ways what I'm doing is I'm like helping translate that vision and that intuition into reality. And then you know there is an art to learning how to push somebody without kind of competing with them. And I think a lot of the times I've seen the CPO CEO relationship go badly and ends up with like the CPO is competing with the CEO for vision and they end up at like loggerheads and I think you know that's not your job.

我想多问一下关于这种推回的艺术，以及你知道的，推动事情朝某个方向发展的技巧。有没有一个诀窍或一个建议你可以分享给大家，让他们变得擅长这个？因为很多人面对高管，总是试图让他们同意自己想要的东西。

I want to ask more about that this art of pushing back and and you know nudging things in direction. Is there kind of one trick or one tip you might share with folks to get to be good at because a lot of people deal with exacts and they're always trying to you know get them to agree to what they want.

我认为第一件事是：不要把它当作一个诀窍。

I think the first thing is like don't treat it as a trick.

我的意思是，你不是在试图得到一个答案和“是”。你是在试图寻求真相，就像我一开始说的那样。所以，我不会说我们一开始就经常意见不合，但我确实认为，如果你是房间里更资深的产品人员，而对方是 CEO，或者如果你是总监，而对方是 CPO，你的部分职责就是以你不太预期或不太理解的方式推动团队。从好奇出发。那个人是否比你拥有更多背景信息，或者是否有你不知道的事情在引导这个方向？所以我经常试着这样开始：“你能——我有没有听错，这是你的先验判断？有没有什么背景信息或我不知道的东西，能帮助形成那个先验判断？”好，确保每个人都在同一个基线上。你知道，我也一直这样指导我的产品经理，比如如果我以一个你意想不到的角度来找你，停下来确保你理解为什么。然后在那之后，我试着做几件不同的事情。显然，人就是人，对吧？他们有心情好的时候，也有心情差的时候。有时事情可以简单到问：“你对这件事已经下定决心了，还是愿意接受输入？”如果答案是“不，我相当确定这就是答案”，那就闭嘴。不要为了吵架而吵架。如果答案是“实际上，是的，欢迎你挑战我，但我需要看到数据”。如果我在房间里没有任何数据，如果那只是我的观点，那么辩论的条件就很清楚了。如果我有新鲜数据，就拿出来。如果我真的很相信某件事，但我没有数据，那就质疑为什么，或者去获取数据，然后带着数据回去找他们。但如果答案是，如果没人有数据，只是两种观点，那么 CEO 的观点会赢。这没关系。把自尊放在门口，直奔答案。但如果你有数据，就拿出来。然后有时就像确保你为了正确的理由而辩论。我认为在你描述的产品经理剧场中，很容易想要确保你设定了框架和基调，在我们这个行业里，确实有时候术语很重要，确切使用哪个词可能非常重要，但很多时候并不重要。

I mean, you're not trying to get an answer and a yes. You're trying to seek truth, like my first statement. And so, I wouldn't say it's especially common that we start out of alignment, but I do think, you know, part of your role if you're one of the more senior product folks in the room and the CEO, or if you're a director and it's the CPO in the room, is pushing the team in a way that you don't really expect or you don't really understand. Start from a place of curiosity. Does that person have more context than you, or is there a thing that you're not aware of that is guiding it? So I often try and start with like, 'Can you, am I hearing you right that this is your prior? Is there a piece of context or something that I don't have that helps inform that prior?' Cool. Make sure everybody's on that same baseline. And you know, I coach my PMs to do this with me all the time too, like if I'm coming at you from an angle you don't expect, pause and make sure that you understand why. And then after that, I try and do a couple different things. Obviously, people are people, right? They have good days, they have bad days. Sometimes it can be as simple as, 'Is your mind made up on this or are you open to input?' If the answer is like, 'No, I'm pretty set that this is the answer,' shut up. Don't pick a fight for the purposes of picking a fight. If the answer is like, 'Actually, yes, you're welcome to push me, but I'd need to see data.' If I don't have any data in the room, if it's just my opinion, then the terms of the debate are pretty clear. If I have fresh data, bring it. If I really believe a thing and I don't have data, question why, or go get it and then go back to them with the data. But if the answer is like, if it's nobody's got data, it's just two opinions, the CEO's opinion is going to win. And that's okay. Check your ego at the door, get to the answer. But if you've got data, bring it. And then sometimes it's like just make sure that you're debating for the right reasons. I think it's easy in your PM theater that you're describing, like wanting to make sure that you set the framing and the tone, and there are genuinely times in our industry where nomenclature matters and exactly what word is used can be really important, but a lot of the time it doesn't.

有一个概念，我在和你共事的人交谈时多次听到。这个说法是“拉手风琴”。解释一下。

There's a concept that I heard come up a bunch when I talk to people who work with you. The phrase was 'play the accordion.' Explain.

所以我之前提到我不太喜欢框架，但我确实认为有一个心智模型非常有用，它涉及我们之前讨论过的事情，比如思考一个问题，即使你完全不发布产品，也要做脑力工作。显然，代码的神奇之处在于你可以快速发布东西并迭代，边做边获取数据。我认为随之而来的一个陷阱是，你只是在向前迭代，把意大利面扔到墙上，却不知道自己在往哪个方向走。我认为还有第二种失败模式，就是人们坐下来写下这些长长的路线图和战略愿景文档，说明我们在未来两三年要做什么，这有点失去了我们相对于其他所有行业的比较优势，那就是学习。比如 AB 测试意味着你可以更新你对问题的理解，从而在前进过程中改变方向。所以“拉手风琴”这个比喻的重点是：如果你想想钢琴手风琴，在你能弹出一个音符之前，你必须把它完全拉开，让空气进来。所以，就像，我们在这里想要完成什么？但直到你按下琴键并把它推回到 V1，你才奏出音乐。然后当你演奏下一个进程时，你再次把它完全拉开。好的，鉴于我们刚刚学到的，我们该怎么做？然后你再去构建下一个东西。你必须习惯这种动作，它说这并不创造价值。就像拉开它实际上并不产生任何作用。所有的价值都在这里创造。但除非你不断经历这种动作，说：“好吧，重新评估我们的理解。这如何改变我们正在做的事情？”你可能没有在演奏正确的东西。我知道我可能在歪曲。在评论区的某个地方，会有一位音乐家指出，这实际上也是你创作音乐的一种方式，但我发现它对于产品经理来说是一个非常宝贵的记忆工具，就像你必须不断地缩小范围，再推回去，再缩小，再推回去。

So I mentioned earlier I'm not huge on frameworks, but I do think there's a mental model which is quite useful that goes to the thing that you and I discussed earlier on, like think through a problem, do the mental work even if you're not shipping at all. Obviously the magic of code is that you can kind of ship things and iterate really quickly and get data as you go. And I think one of the trappings that comes with that is you're just iterating forward and throwing spaghetti at a wall and you don't really know what direction you're going in. I think there's a second failure mode which is people sit down and write out these long roadmaps and strategic vision docs of what we'll do over the next two or three years that kind of loses the comparative advantage we have over every other industry, which is learning. Like AB tests mean that you can update your understanding of a problem and therefore change your direction as you go. So the point of the analogy of play the accordion: if you think about a piano accordion, before you can play a note, you got to stretch it all the way out, bring the air in. So, like, what is it we're trying to get done here? But you don't make music until you press the key and push it all the way back into V1. And then when you go to play the next kind of progression, you pull it all the way out again. Okay, given what we just learned, what do we do? And then you go and build the next thing again. And you've got to get used to this motion that says this isn't creating value. Like pulling it out doesn't actually do anything. All the value is created here. But until you are going through this motion constantly of saying, 'Well, re-evaluate what we understand. How does this change what we're doing?' You're probably not playing the right thing. And I know I'm probably bastardizing. Somewhere in the comments, there's going to be a musician who points out to me that this is actually also one of the ways you make music, but I found it just a generally very valuable memory device for PMs to be like, you've got to constantly be zooming out and pushing back in and zooming out and pushing back in.

是的，这个比喻太有趣了，因为你知道，即使你通过扩张来创作音乐，它更像是向内，或者像是从压缩中学习。

Yeah, that is such a fun analogy because you know it's like the even though you make music expanding it, it's like inward, or it's like learning from the compression.

我们学到了什么？你如何与每个人沟通？回到发布。

What do we learn? How do you communicate to everyone? Back to shipping.

这就像一种不同的音乐。内在的音乐，外在的实验。

It's like a different kind of music. Internal music, external experiment.

是的。因为确实有些人非常看重路线图，有些人非常看重迭代。我认为诚实的答案是两者都要做。你不能过度偏向任何一方。所以这里的教训是运行实验，但然后确保你思考结果对大局的影响。然后我们想要做什么？有一个计划。比如，我认为系统是这样运作的。我有这个信念，如果我们出于某些原因改变发现算法的工作方式，它会产生这样的影响。我能做的最小的证明它的事情是什么？好的，它起作用了。太好了。计划不变。V2。哦，那没起作用。V3 必须有所不同。你只是想要一直经历那种动作。

Yeah. Because genuinely there are people who are really big on roadmaps and there are people who are really big on iteration. I think the honest answer is you got to do both. You can't overindex on either. So the lesson here is run experiments, but then make sure you think about the implication of the result at the bigger picture. And then what are we trying to do? Have a plan. Like, I think the system works this way. I have this belief that if we change the way that discovery algorithms work for XYZ reasons, it will have this impact. What's the smallest thing I can do to prove that? Okay, it worked. Great. No change to plan. V2. Oh, that didn't work. V3 is going to have to be different. And you just kind of want to always be going through that motion.

没在 YouTube 上看的人，Tom 正在挥舞双手，手势夸张。

People not watching on YouTube, Tom is moving his hands, gesticulating wildly.

在什么情况下你会对某人说：“嘿，去拉手风琴”或“我们在拉手风琴”？比如，他们通常做错了什么？

What's a context where you have said to someone, 'Hey, go play the accordion' or 'we're playing the accordion'? Like, what are they usually doing wrong?

这往往是因为你在非常局部的意义上发布东西，而不一定理解其影响。所以现在的一个例子是，你知道，大多数市场的核心是列表，对吧？比如如果你试着想象没有列表的 Amazon.com，那里基本上什么都没有。它只是一堆，你知道，左栏或右栏和一些视频。在视频电商和直播电商中，什么的，你历史上并不真正需要列表。如果我想卖给你一副 AirPods，我可以直接把它们举到屏幕前给你看，描述它们，说它们是 AirPods。我将以 1 美元起拍。作为买家，你现在拥有了做出购买决定所需的所有信息，这很棒。

It tends to be that you're shipping something in a very local sense without necessarily understanding impact. So an example right now is, you know, the core of most marketplaces is listings, right? Like if you try and think about Amazon.com without listings, there's basically nothing there. It's a bunch of, you know, it's a left rail or right rail and some videos. In video commerce and live commerce, whatnot, you don't really historically need listings. If I want to sell you a pair of AirPods, I could literally hold them up to screen and show you them and describe them and say they're AirPods. I'm going to start them at a dollar. And as a buyer, you now have all the information you need in order to make a purchase decision, which is great.

所以你可能不必像其他人那样投入精力去制作商品列表。这对卖家来说可能是净收益，因为制作一个列表大约需要三分半钟，而描述一件东西并拿起来展示则零分钟。但你再放大来看，说：“哦，新买家会来到直播电商，并期望搜索功能正常运作。如果我不知道你在卖什么，直到你卖完之后，我根本不可能把某人引导到正确的耳机直播流，因为我们不知道你有这些商品，因此我也无法将人们引导到那里。”于是你经历这样的思考过程：我们不需要修复它，它有效。然后你想，好的，那这对其他事情有什么影响？那我们该怎么办？哦，我们要让每个卖家都制作列表。然后你又放大视角：如果每个卖家现在为每个列表花费三分钟，他们每小时能卖出的商品数量就会大幅下降，这对卖家不利。好吧，我们不能那样做。所以你不得不不断延伸思考，想想我们正在构建的东西的长期影响或连锁反应。

And so you may not have to invest in making listings the way that someone else does. And that's probably net good for a seller because it takes like three and a half minutes to make a listing. And it takes zero minutes to describe a thing and hold it up. But you then zoom out and say, "Oh new buyers are going to come to live commerce and expect search to function. If I don't know what you're selling until after you've sold it, there's no possible way that I can put somebody in the right stream for earpods because they didn't we didn't know you have them and I therefore can't direct people to it." And so you go through this exercise of like we don't need to fix it. It works. And then you're like, okay, great. What does that have implications for other things? Okay, then what would we do? Oh, we're going to make everyone make listings. And you're like, zoom back out again. If every seller is now spending three minutes for every listing that they're making, the number of things they can sell per hour is now dramatically dramatically lower, which means it's bad for sellers. Okay, we can't do that again. And so you just you have to keep stretching through the like what are the longerterm implications or what are the knock-on effects of things we're building.

这非常有帮助。Whatnot 的有趣之处在于，它处于一个光谱上，而整个智能体式商务的趋势是，智能体会为你购买东西，并相互协作，创造一种全新的智能体经济，这与人类现场交谈、互相购买恰恰相反。你对这个趋势有什么看法？它可能对你们产生什么影响？

That is extremely helpful. What's interesting about whatnot is it's there's like this spectrum of like whatnot and then there's this whole trend of agentic commerce where agents are going to be buying the things for you and just working with each other create a whole new agentic economy and this is like the opposite humans live talking to each other buying from each other. Uh thoughts on that on that trend and and how may that might impact you guys?

听着，我个人欢迎我们的智能体霸主，比如我不想操心灯泡、空气过滤器，以及任何维持我生活的程序化事务，对吧？我也很乐意用它来处理高意图的事情，比如我需要一根特定的电脑线缆，或者我在找我家户外的灯。这些搜索确实很繁琐。我想到，比如要去参加婚礼，这意味着我需要黑色鞋子，但必须在周四前送到，因为如果周四之前到不了，对我就没用了。绝对如此。但美国的大多数商务实际上并不是高意图的。我们进入电商时代多少年了？大约 30 年，而电商在美国零售支出中从未超过 20%。美国绝大多数的零售购物仍然是人们亲自去店里购买。在英国大约是 75 比 25。事实证明，很多购物是低意图的。我去商场，可能是因为我有个婚礼要参加，但我没有衣服穿，我会四处逛逛，看看别人有什么，因为我并不确切知道自己想要什么。实际上，商店的价值在于，经营那家鞋店的人有自主权和品味，她精心挑选鞋子。她有一定水平的客户服务，有橱窗展示，可以让我看到她有哪些类型的商品。我可以在商场里闲逛，弄清楚我想买什么，或者从中受到教育。事实证明，这相当令人愉快。商场之所以是一种社交活动，是有原因的。所以我认为智能体式商务将会非常庞大。但美国零售业是一个 7.5 万亿美元的产业。所以我不认为这是一个赢家通吃的事情。我认为直播商务所做的是，它第一次成功地将互联网的规模和便利性与实体购物的那种社会文化体验结合在一起。因为在 Twitch 时，我们通常假设如果直播中少于一千人，就不经济，因为你依靠千次展示成本运营。但在 Whatnot 上，你可以进入一个直播，看到 30 到 50 人，你想象一下，如果你在商场经营一家鞋店，店里有 50 个人，你永远不会关门。你真的永远不会关店，因为那比你想象的任何实体店客流量都要大得多。因为商务的经济学与娱乐完全不同，你不需要担心千次展示成本。所以我认为这并非真正与智能体式商务竞争。我认为这是一种完全不同的客户需求。

Listen, I for one welcome our agentic overlords for things like I don't want to have to think about light bulbs, air filters, any of the programmatic stuff that I need to run my life, right? I'm also pretty great with it for like really high intent things. I need a particular cable for my computer. I'm looking for, you know, outdoor lights for my house. Things where there are really taxing searches. I think about this, you know, got to go to a wedding which means I need black shoes but delivered by Thursday because if they don't get here before Thursday they're a no good for me kind of things like absolutely but most of commerce in America isn't actually high intent like how many years are we into ecom now like 30 years into ecom and e-commerce has never exceeded 20% of retail spend in America right the vast vast vast majority of retail shopping in the United States is still people going in person and buying things uh in the UK somewhere. It's like 7525. And it turns out actually that a lot of shopping is low intent. I'm going to the mall. I might be because I've got a wedding coming up and I don't have anything to wear and I'm going to wander around and see what people have available because I don't actually know specifically what I want. And actually the value of stores is that that person who runs that shoe store has agency and taste and she curates a selection of shoes. She has, you know, a level of customer service. She has a window display which can show me the types of things she has. And I can wander around the mall and actually work out what it is I want to buy or be educated by it. And as it turns out, it's quite pleasant. Like there's a reason that the mall is a social thing. And so I think you know that Agentic is going to be huge. Retail is a 7.5 trillion dollar industry in the US though. So I don't think it's a like winner takes all thing. What I think live commerce does is it's the first time that we've ever managed to kind of like bring together scale and convenience of the internet and also that same kind of like social cultural experience uh of physical shopping because you know at at Twitch we used to basically assume that if it's less than a thousand people in the stream it's non-economic because you're you're operating on CPMs. So but you can go into a stream on whatnot and see 30 50 people in that stream and you you imagine for a moment that you're running a shoe store at a mall and you had 50 people in your store, you'd never close. Like, you would literally never shut down the store because that's so much more foot traffic than you can ever imagine being in a store because commerce has totally different economics to entertainment and CPMs aren't the thing that you have to worry about. So, I think it's not really in kind of like competition with aic. I think it's a completely different kind of like customer need.

太棒了。每个人都有空间。我想最后问一个关于 Twitter 的问题。所以，你曾在 Twitter 工作过。

Amazing. There's room for everyone. I want to end maybe with a question about Twitter. So, you were a Twitter.

是的，先生。

Yes, sir.

你曾是 Twitter 的增长产品经理。我觉得每个在 Twitter 担任产品经理的人都被那段经历留下了创伤。每个人都说不要这样做事情。那段经历中有什么让你印象深刻？你学到了什么？又摒弃了什么？

A PM at Twitter working on growth. I feel like everybody that worked at Twitter as a PM was just scarred from the experience of Twitter. Everyone said do not do things this way. What's uh what's something that stuck with you from that experience? What did you learn? What did you unlearn?

这很有趣。我以前跟朋友说过，问一个在 2015 到 2016 年期间在 Twitter 工作过的人，有点像治疗师让某人讲述他们的童年。你知道你正在提起的创伤。

It is funny. I have said to a friend before that asking someone who was at Twitter in like the 2015 16 era is a little bit like a therapist asking somebody to tell them about their childhood. It's like you know the trauma that you're you're bringing up.

是的。

Yeah.

对于那些不熟悉那段历史的人，我在那里的两年里，我们换了九位产品负责人。就是那种程度的混乱。我最喜欢的一句话来自合作伙伴团队的人，他说感觉就像卡拉萨住在活动里。那就是那里戏剧性事件发生的频率。我想我从 Twitter 的经历中带走了两件最重要的事情，除了交到一些很棒的朋友，而且我要说，那个时代 Twitter 的产品人才散落各处，非常了不起。第一点是，如果你真正找到了产品市场契合，如果你成功捕捉到了闪电，无论你把组织搞得多么糟糕，它都依然巨大。Twitter 确实拥有那种程度的产品市场契合，你能从情感上感受到人们有多爱你的产品。这是一个非常有力的试金石，让你在职业生涯早期就明白什么是产品市场契合。不是像“嘿，图表看起来不错”那样，而是有更深层次的东西。我想，从不太积极的一面来看，我肯定学到的是，大多数时候你听到“这真的很复杂”，其实并非如此。只是领导力薄弱。所以，你知道，我在那里的两年里，每个人都知道我们必须取消 140 个字符的限制，对吧？工作组一个接一个。

For those who not familiar with that law, I think we had nine heads of product in the two years that I was there. It was that level of kind of chaos. I think my favorite quote was from someone on the partnership team who said it felt like Carasa lived in the events. That was like how often drama was going on about the place. I think Lenny I probably took two overwhelming things away from from my time at Twitter and other than like some incredible friends and I will say that the the product diaspora from that era of Twitter is pretty incredible and and everywhere. The first one is like if you truly find product market fit, like if you manage to bottle lightning, doesn't matter how badly you screw up the organization uh of it, like it's huge. And like Twitter genuinely had that level of product market fit that you could emotionally feel how much people loved your product. And it's a really powerful litmus test to learn relatively early in your career. That's what PMF is. Not like, hey, the graphs look okay, right? There's like a level of further that goes in. I think maybe on the flip side of like less positive is like what I definitely learned is like most of the time you hear it's really complex. It it isn't. Leadership is just weak. So, you know, the two years that I was there, everyone knew we were going to have to lift the 140 character limit, right? There was working group after working group.

比如 140 字限制的项目，当时到处都是，因为我们知道，比如日本用户发推的频率是西方市场的六倍，而且我们跟他们聊过之后发现，主要是因为汉字能在同样字数里表达更多内容，比罗曼语系语言多得多。我们知道那是不可避免的终局，但显然需要做很多工作，还要权衡取舍，就是没人愿意拍板。所以又是一轮设计冲刺，又是一轮循环。我离开之后又过了一年半，可能快两年，才有人真正做了。结果呢，没人死，公司的灵魂也没散。我猜编辑推文的功能也经历了同样的讨论，又花了两年半。有时候事情其实没那么复杂，只是每周都在拖。

Like the project beyond 140 was like everywhere because we knew for example that people in Japan tweeted six times more often than people in western markets, and it was largely, when we spoke to them, because kanji let you say heaps more in the same number of characters than a romance language did. We knew that was the inevitable end state, but there's obviously a bunch of work that was needed and trade-offs, and no one wanted to make the call. And so there was just yet another design sprint, yet another cycle. And it was another year and a half after I left. I think it was maybe even almost two years after I left before someone actually did it. And it turns out, you know, nobody died. The soul of a place didn't fall apart. I imagine the same discussion went on for editing tweets, which took another two and a half years. Like sometimes things aren't actually that complicated. It's just weekly to

是啊，现在发展到这一步真有意思。你可以在 Twitter 上写一整篇博客，比如长文章就是个很大的赌注。

Yeah, it's funny how far it's come now. You can write an entire blog post on Twitter, like articles is a big bet.

关于产品市场契合这一点，我觉得更重要的是 Twitter 的网络效应，你在构建市场方面花了很多时间思考。对我来说，看着 Elon 基本上改变了一切。我忘了是谁发的推文，但就是一切都变了：品牌、名字、网站、员工人数，所有东西。

On the product market fit piece. I think even more important there is the network effects of a Twitter, which you spent a lot of time thinking about building marketplaces. Like to me, watching Elon basically change everything. I forget who tweeted this, but just like everything changed: the brand, the name, the website, the number of people working there, everything.

对。

Yeah.

人、团队，那什么没变？基本上就是 Twitter 的网络效应。

People, the team, like what was the thing that stayed the same? And it was basically the network effects of Twitter.

没错。

Yep.

它是必去之地。所有人都在那儿。这很难打破。而且即使你费了那么大劲想搞砸它，它还是活得好好的。

It's the place to be. So everyone's there. And that's hard to break. And even in spite of how much you tried to mess it all up, it's still kicking.

那是瓶装闪电，真的，你能看出来。

That's bottle lightning. Genuinely, you can tell.

好，我们进入播客的固定环节：失败角落。我之所以喜欢这个环节，是因为人们看到像你这样的嘉宾上节目，职业生涯辉煌，一切顺风顺水，但他们看不到那些不顺利的事情，看不到你失败的时刻，而他们自己的生活里经常出问题。所以问题就是：你职业生涯中有没有一个例子，事情失败了，你做的某个东西、某个职业选择没成，然后你从中学到了什么？

Yeah. Okay. I'm going to take us to a recurring corner of the podcast: Fail Corner. Why I like doing this is because people see people like you coming on the podcast, having this illustrious career, everything's going great constantly or just killing it, and they don't see the things that don't work out and the times that you failed, and in their life things often go wrong. So the question for you is just: what's an example of a time in your career where things failed, something you built, some career move you made that didn't work out, and then what did you learn from that experience?

说实话，兄弟，你夸我我很感激，但我感觉整个职业生涯里，我失败的时候比成功的时候多。真的，回到你一开始提到的那篇博客，我在后面附了我们内部用来讨论如何构建产品的实际文档，开头就说“五成胜率就是目标”。所以你希望自己对错的次数一样多。所以具体例子太多了，我在职业生涯里搞砸过太多次。但可能有一个共同的线索，我觉得这是任何产品经理都容易掉进去的陷阱，就是“平均值对个体毫无意义”，这大概是我被伤得最深的一点。在任何一个足够大的群体里，去看某个东西的平均效用或平均采用率很有吸引力，然后你发现只有 3% 的人用某个功能，你就想，好，我们可以砍掉这个功能。它用得不多，但如果你不深入一层，不去想其实只有 3% 的人用，但对这群人来说，这就是他们 100% 在做的事，这是他们的核心用例。然后为了省事，因为有人不想再维护这个功能了，你就直接弃用它，结果你毁掉了那群人的用例。然后回到你刚才说的网络效应，这种螺旋式的影响可能巨大。我在电商领域经常想这个：这是某人的生意，对吧？如果我们不可靠，我们弃用一个功能，就像 Westfield 购物中心在圣诞节前不假思索地断电。所以对人们的生意有真实的下游影响，而这往往源于对指标理解不够细致，尤其是平均值。它们总是在骗你。我觉得我在职业生涯里可能各种方式都搞砸过，但大多数时候，我做出那些真正让自己失望的决定，通常是因为我依赖平均值，而没有考虑隐藏在下面的个体用例。

Honestly, mate, and it's very nice of you to say nice things, but I feel like I fail more often than I succeed across the course of my career. Genuinely, to the blog you referenced right at the start, I published in the back of that the actual document we use internally to talk about how we build, and it starts with like batting 500 is the goal. So you're hoping to be right as often as you're wrong. So there's probably just too many specific examples of times I've screwed up in my career. But there probably is a really common thread to it, and I think it's probably an easy trap for any PM to fall into, which is like averages mean nothing to the individual is probably the thing that I've been really scarred by. In any sizable population, it's really attractive to go and look at average utility or average adoption of something, and then you find that only 3% of people use something, and you're like cool, we can probably get rid of that feature. It's not used widely, but if you don't go a layer deeper and be like actually, it's only 3% of something, but there's a group of people for whom that's 100% of what they do. This is their core use case, and for expediency's sake, because somebody doesn't want to maintain a feature anymore, you're just going to deprecate it, and then it turns out you blow up the use case of that group of humans. And then to your last point about network effects, the ongoing spiral effect of that can be enormous. I think about it a lot in e-commerce: this is somebody's business, right? If we're just not reliable, we're deprecating a feature, it's kind of like a Westfield mall just turning off the power in the lead-up to Christmas without thinking about it. And so there are real downstream impacts to people's businesses that often come from just a lack of nuance in understanding metrics, particularly averages. They just lie to you all the time. And I think I've probably screwed up in all of the ways in my career, but most of the time I've made genuinely, like I'm disappointed in myself levels of decisions. It's typically that I've relied on averages without thinking about the individual use cases that are hidden underneath.

这让我想到 Jeff Bezos 有句话：“当你有数据和轶事时，相信轶事？”

Makes me think about Jeff Bezos has a quote, "When you have data and an anecdote, trust the anecdote?"

对，完全正确。

Yeah, that's exactly right.

好了，Tom，我们已经聊完了我想聊的所有话题。你还有什么想分享的吗？在进入非常刺激的快问快答环节之前，你想给听众留下点什么吗？

Well, Tom, we've gone through everything I wanted to talk about. Is there anything else that you wanted to share? Anything you want to leave listeners with before we get to a very exciting lightning round?

我想补充的就这些，兄弟，我真的很享受这次讨论，谢谢你。我觉得产品管理没有唯一的方法，AI 塑造行业的方式也没有唯一答案。所以我们很有信心，对于我们正在构建的产品和公司文化，这种“更少但更资深、拥有更多自主权的产品经理”模式适合我们。我不假装这适用于整个行业，但我确实认为，现在是最好的时机回归产品工作的本质，摆脱那些形式主义，我觉得这在任何地方都适用。即使有些人是很棒的团队管理者，他们从管理、培养和指导中获得满足感，我相信在很多地方这仍然有价值。所以请假设我说的话至少有一半是错的，就像我发布的东西可能有一半不正确一样。这就是为什么我喜欢这些对话，为什么我认为我们共同做的工作很重要：我们正经历职业生涯中最疯狂的时代。变化如此之多，正如你所说，很多东西都在被重新思考，我觉得要成功穿越这段时期，唯一的方法就是学习别人是怎么做的，看看他们学到了什么，看看什么没奏效。

I think all I'd add, mate, and I've really enjoyed the discussion, so thank you. Is like I don't think there is one way to do product management, and I don't think there is one way that AI will shape the industry. So we're pretty confident that for the product we're building and the culture of the company that we have, this model of fewer PMs who are more senior with a lot more autonomy is right for us. I don't pretend to presume that that will be true for the entire industry, but I do think there has never been a better time to go back to the roots of the actual product work and getting out of that theater, and I think that probably is true everywhere. Even if there are people who are wonderful people managers and really derive their satisfaction from doing that and growing and coaching, and I'm sure there'll be loads of places where that's still valuable. So assume that at least half of what I've said is wrong, on the same basis that half of the things I've probably ever shipped are not correct. That's why I love these conversations and why I think this work that we do together is important: we are living through the wildest time in our careers. So much is changing, so much is being rethought as you've described, and it feels like the only way we can make our way through this successfully is to learn from how other people are approaching it. See what they've learned, see what has not worked.

吸收那些引起共鸣的部分，忽略那些听起来夸张或不适用的部分。

Take bits that resonate, ignore the bits that seem bombastic or not applicable.

完全正确。因为没有人确切知道，Elizabeth Stone 有句很好的话。

Exactly. Because no one knows exactly where, Elizabeth Stone had this great way of putting it.

我们正处于某种风暴期和规范期，而我们现在就处在这个风暴期。就像我记得在我的产品经理职业生涯中，当我开始写作时，大家总是问我产品管理在过去十年里发生了怎样的变化。我说它没变，基本上是一样的，但现在感觉它确实发生了重大变化。

We're in this kind of there's a storming phase and the norming phase and we're in this storming phase of holy. Like I remember in my PM career as I started writing and stuff everyone was always asking me how has product management changed over the last decade. I'm like it hasn't changed. It's the same basically but it feels like now it actually significantly changed.

虽然你之前提到的核心东西，

Although to your point earlier actually the core things

而且也不是全都一样。

and also not all be the same.

是的。

Yeah.

是的，是的。所以这就是为什么这些如此有用，让人们看到团队是如何运作的，他们学到了什么，以及可以尝试的事情，可能对你不适用，但这就是我们互相学习的方式。说到这里，我们进入了一个非常激动人心的快速问答环节。我有五个问题要问你。好的，开始吧。你发现自己最常推荐给别人两三本书是什么？

Yeah. Yeah. So that's why these are so useful just for people to see here's how a team is operating and what they've learned and here's things to try and it may not work for you but this is how we learn from each other. With that, we have reached a very exciting lightning round. I've got five questions for you. All right, here we go. What are two or three books that you find yourself recommending most to other people?

好的。不想落入俗套，但《创业维艰》我仍然认为是最好的关于产品管理的书。从你必须经历、尝试、犯很多错误的各种事情来看。稍微有点偏门。但别人推荐给我读的最好的书，我现在也推荐给别人，是牧师里克·沃伦写的《目的导向的教会》。Twitch 的 CEO 埃米特·希尔基本上会确保人们读这本书。这本书对人们为什么会在情感上投入某件事，以及如何从一群人那里设计出情感投入进行了疯狂的探讨。这实际上是一本 90 年代写的关于如何建立教堂的指南。如果你从事任何形式的社区产品，绝对值得一读。最后一本，如果你在找小说或奇幻类，我晚上倾向于读这类，那就是 RF 匡的《巴别塔》。

Okay. Not to be cliched, but The Hard Thing About Hard Things, I still think is the best book written about product management. Just from a breadth of things that you have to go through and try and do and screw up a lot. Slightly left field. But the best book anyone's ever recommended to me to read, which I now recommend to others, is The Purpose-Driven Church by a pastor called Rick Warren. Emmett Shear, the CEO at Twitch, used to basically make sure that people read it. It's this wild examination of why people emotionally invest in something and how to engineer emotional investment into it from a group of people. It's literally a how to go and build a church guide book written in the '90s. Definitely worth a read if you're in a community product of any form. And the last one is if you're looking for kind of like fiction or fantasy, which is where I tend to go in the evening, Babel by RF Kuang.

我喜欢那些从未被提及的书被加入推荐书单。

I love when books have never been mentioned before get added to the canon of recommended books.

非常有趣。

It's very fun.

你最近真正喜欢的电影或电视剧是什么？

Favorite recent movie or TV show that you've really enjoyed?

Apple TV 上的《星空之城》。如果你喜欢《为了全人类》，它有点像那个的翻转，但它是苏联方面。就像看《美国谍梦》和《为了全人类》混合在一起。

Star City on Apple TV. If you liked For All Mankind, it's kind of like the flip of that, but it's the Soviet side. It's like watching the Americans and For All Mankind mixed together.

你最近发现并真正喜欢的产品是什么？

Favorite product that you have recently discovered that you really like.

这是一个非常冷门的选择，所以我先向大多数听众道歉。希望你们已经听出了我的口音。我经常被告知我的澳大利亚口音很重，但我喜欢的一件事是，每次我回家，我意识到澳大利亚的一堆政府服务应用变得非常出色。你有没有过这样的想法：我希望政府拥有我所有的数据，或者我希望有一个地方，我可以一键续签驾照，我可以转让所有权，做所有那些拖慢你生活的行政事务。新南威尔士州服务局真的做到了。对我来说很奇怪，我竟然会在播客上说，竟然是澳大利亚的政府应用？但我最近回家，不得不处理我所有的生活行政事务，它太棒了。

This is a very deep cut, so I will apologize to most listeners. Hopefully you've detected the accent. I'm told constantly that my Australian accent is going, but one of the things that I love is every time I go home, I realize actually a bunch of the government services apps in Australia have become phenomenal. You ever had that kind of concept where you're like, I wish the government has all my data or I wish there was just like one place where I could with one click get my driver's license renewed. I could like transfer titles and do all of the admin that slows you down in life. Services New South Wales actually nailed. Bizarre to me that I would ever come on a podcast and say actually a government run app in Australia of all places is it? But I was home recently and had to do all of my life admin and it's incredible.

哇。最近我听到一些关于澳大利亚的事情，既然我们谈到这个话题，快速偏离一下快速问答环节，随着那里太阳能电池板的建设，澳大利亚可用的电力比他们能用的还多。

Wow. Something I heard recently about Australia, while we're in that topic, real quick tangent from lightning round is with a solar panel buildout that has happened there, there's more electricity available in Australia than they can use.

是的。他们给人们

Yep. And they're giving people

在澳大利亚规模很大。

huge in Australia.

所以就像他们在中午给人们免费电力，因为可用电力太多了，他们说在中午用你所有的电器，否则就会浪费掉。有个说法是，如果 AI 真的需要大量电力来建数据中心，那么澳大利亚整个 21 世纪的经济应该是电力。

So it's like they're giving people free electricity in the middle of the day because there's so much available and they're like use all your stuff in the middle of the day because this is otherwise it's going to go to waste. There is a pitch somewhere that says if AI actually needs loads of electricity in order to be data centers, Australia's entire 21st century economy should be power.

太不可思议了。这真是好消息，我们找到了用太阳能电池板产生这么多能源的方法。

Incredible. That's like such good news that we are finding ways to generate so much energy from solar panels.

20 年前的一项小法规规定，如果你建新房产，必须在屋顶安装太阳能电池板。事实证明效果很好。

A small piece of regulation 20 years ago that said if you're building a new property, you got to put solar panels on the roof. And it turns out it works great.

天哪，我喜欢这个。我喜欢这种对未来的乐观，因为你知道解决之道，

Oh my god, I love this. I love this optimism of the future because you know the way through,

不是问题。

not the problem.

好了，还有两个问题。你有没有最喜欢的人生格言，在工作或生活中经常想起的？

Here. Okay, two more questions. Do you have a favorite life motto that you often come back to in work or in life?

在我的大学时代，或者用美国说法叫大学，我曾经有一个派对把戏，如果我背下了拉迪亚德·吉卜林的《如果》，因为我觉得它很深刻、很有意义。但如果我说实话，最接近的可能是“我会搞定的”。你知道，事实证明大多数事情并不像人们想的那么难。就像我们会解决的。我会搞定的。如果你愿意投入所需的时间、金钱、努力、精力，你几乎可以解决任何问题。如果你不愿意，那可能也不是什么大问题。

In my uni days or back in college for American translation, I used to have a party trick if I'd memorized If by Rudyard Kipling because I thought it was like deep and really meaningful. But I think if I'm being really honest, I'll figure it out is probably the closest. You know, it turns out most things are not as hard as people think. Like we'll work it out. I'll figure it out. If you're willing to devote the required time, money, effort, energy, you can solve almost anything. And if you're not, then it's probably not that big of a problem.

最后一个问题。我想人们经常问你这个问题，但我只是好奇。在过去一个月左右，你在 Whatnot 上买了什么？就是那种很棒、令人愉快、令人惊讶的东西。

Final question. I imagine people ask you this a lot, but I'm also just curious. What's something you bought on Whatnot in the past month or so? That was just awesome, delightful, surprising.

我最近买的最有趣的东西，我不是开玩笑，是一只活龙虾。所以，最近 Whatnot 上真正火起来的是我们的新鲜和特色食品类别。有一个很棒的卖家，叫 EFish Co.，在圣地亚哥的码头有一家海鲜店。每天早上船进来时，他真的会出去直播所有从船上卸下来的海鲜箱，然后在 Whatnot 上现场拍卖，第二天就送到你家门口。所以，我买了一只加州刺龙虾，直接送到我家门口，多亏了直播。

The most fun thing I've bought recently, I'm not joking, is a live lobster. So, recently one of the things that's really taken off on Whatnot is our fresh and specialty foods kind of category. And so, there's this wonderful seller who goes by EFish Co. who has a seafood store down on the dock in San Diego. And every morning as the boats come in, he literally goes out and live streams all of the crates of seafood coming in off the boats and then he auctions them off live on Whatnot and ships next day to your door. So, I got a California spiny lobster shipped direct to my door, courtesy of a live stream.

这是怎么运作的？他们用冰袋包装，用类似冰袋的容器，然后 UPS 隔夜送到我家门口。这就是我的智能体商务会很好，但不会包罗万象，因为我那天早上没有打算买一只加州刺龙虾。

And how does this work? They put an ice ship it next ice kind of like container and it's a UPS overnight on my door the next day. And that is my agent commerce is going to be great, but not all-encompassing because I have no intention of buying a spiny California lobster that morning.

除非你的智能体决定你今天吃龙虾。而且我们

Unless your agent decides you eating lobster today. And we

跟你说实话，它很好吃。

I got to be honest with you, it was delicious.

太棒了。我不知道你可以买那样的东西。

Amazing. I did not know you could buy stuff like that.

汤姆，如果人们想关注你的写作，在网上哪里可以找到你？

Tom, where can folks find you online if they want to follow your writing?

如果你在网上找我，我是 TD Robo，TD R O B B O，在 Twitter 上，或者叫 X，我猜，那是我大部分思考的地方。内容混合了产品管理和对勇士队比赛的喊叫。所以提前道歉。然后 LinkedIn 是我放大部分工作写作的另一个地方。我会说，我追求质量而非数量。所以不要指望我在任何一边每天更新。

If you're looking for me online, I'm TD Robo, TD R O B B O on Twitter, which is or X, I guess, which is where I do most of my musing. It's a mix of product management and yelling about Warriors games. So, apologies in advance. And then on LinkedIn is the other place I've put most of my kind of like work writing. I will say it's, I try for quality over volume. So don't expect daily drops from me on either side.

全是爆款，一年一次全是爆款。

Just bangers. Just bangers once a year.

这是别人对我年龄说过的最动听的话了。就是随便丢点爆款。老实说，大家怎么帮忙呢？我们一直欢迎关于 Whatnot 的反馈，比如大家觉得怎么样，我们还能怎么改进。所以，欢迎在那些平台上找我，给我点犀利观点、反馈或想法。

That was the nicest thing anyone said about being ages. Uh just just dropping casual bangers. And how can folks be be helpful honestly? Uh would always welcome feedback around whatnot uh and how people are finding it and what more we can do better. So like hit me up on either of those platforms with you know hot takes uh feedback or thoughts.

然后呢，尽管对产品管理有很多强烈的看法，你们还是在招产品经理。也许可以聊聊这个，以及大家可以在哪里申请。

And then uh you're hiring PMs even in spite of the many strong opinions about product management. Maybe just talk about that and where folks can apply it.

当然。听着，我们一直在找产品经理。解释申请人数与录用人数对比的意图，并不是要打击大家。更多是想说，产品管理的普及本身并不自然带来你和我刚才花了 90 分钟讨论的那种技能组合。不过，我们昨天雇了两个人，我很期待他们入职。我们一直有各种产品经理职位空缺。在 Whatnot，你只要谷歌一下 Whatnot 的职位，合适的申请流程就会出现在那里。或者我发现，硅谷圈子很小，产品管理也不是那么冷门，你大概能找到在 Whatnot 工作的 20 来个人之一，直接联系他们。我们现在在找各种方向的人，支付是我们目前工作重点中的重中之重，物流也是。所以如果有人特别想参与未来隔夜运送龙虾的物流工作，事实证明那里有很多产品细节。

Sure. Uh listen, we are constantly looking for PMs. The the intent of kind of like explaining how many people applied versus hired was not to discourage uh people. It was more along the lines of like the proliferation of product management doesn't itself naturally lend to the people with the skill set that you and I have spent the better part of 90 minutes talking about right now. But you know, we hired two people yesterday. I'm very excited for them to come start. Um and we've always got a variety of of PM roles open. the whatnot if you just kind of Google whatnot jobs um the the right kind of application process will will pop up there or I've found that you know the valley is small enough and product management is not that kind of obscure that you can probably find one of the 20 or so humans who work at whatnot and and reach out to them but we're looking at a variety of things right now payments very high on on our list of what we're doing as well as logistics so if anyone is really excited to come work on the future of shipping uh lobsters overnight uh it turns out there's quite a lot of nuance product happen there

太棒了，Tom，非常感谢你来做客。

Amazing Tom, thank you so much for being here.

这是我的荣幸，兄弟。谢谢邀请我。

It was a pleasure, mate. Thanks for having me.

大家再见。非常感谢收听。如果你觉得这期有价值，可以在 Apple Podcasts、Spotify 或你最喜欢的播客应用上订阅本节目。另外，请考虑给我们打个分或留个评论，这真的能帮助其他听众找到这个播客。你可以在 lennispodcast.com 找到所有往期节目或了解更多关于节目的信息。下期见。

Bye, everyone. Thank you so much for listening. If you found this valuable, you can subscribe to the show on Apple Podcasts, Spotify, or your favorite podcast app. Also, please consider giving us a rating or leaving a review as that really helps other listeners find the podcast. You can find all past episodes or learn more about the show at lennispodcast.com. See you in the next episode.