在过去两年中，有 31,832 832 人申请成为 Whatnot 的产品经理。我们只录用了一个。你打出"一杆进洞的概率，是单纯通过投简历获得这份工作的两倍。
这并非流程上的失败。我从事产品及产品团队建设已超过十年，大约十年，大约三年前决定加入 Whatnot 的一个关键因素，正是其深思熟虑的产品文化。在 AI 时代，没人真正清楚产品经理意味着什么，但我看到的一切都表明，整个行业正在朝着我们的方向，朝着我们在这里构建的方式前进——因为如果你没有做对的工作，任何工具都无法让你变得有用。
首先，我们必须先承认：普通的产品经理，其实非常普通。
产品职能是因规模扩张而出现的——工程团队变得过于庞大，CEO 或总经理或 CEO 无法直接管理，因此需要一个连接业务与技术的桥梁。久而久之，我们偷懒地把这个角色概括为“每招聘一名工程经理，就同时招聘一名产品经理”。但工程总监可以通过工程经理管理 30-40 人，而产品总监却只管理 5 个人。激励机制主导世界，因此那些总监的工作就变成了“证明扩大我工程合作伙伴的编制是合理的”，以便他们也能扩大自己的团队，最终晋升为副总裁。慢慢地，初级产品经理的角色从“产品的 CEO”变成了“按钮的保姆”，而原本具有产品思维的工程师则沦为了被动的需求执行者。
然后疫情来了，整个行业在短短四年内令人难以置信地招聘了 50 万名新软件工程师，并相应地催生了大约 8 万名新的产品经理。这 8 万名产品经理深陷在 FAANG 庞大的团队中，远离客户，距离真正决策会议有 50 层之遥，在产品学校里学习着按图索骥式的产品管理方法，处在一个任何做法似乎都能奏效的、靠非自然增长驱动的增长时代。
在这样的环境中，能涌现出具备出色产品直觉、经验和韧性的人，其概率实际上比打出一次一杆进洞还要低。
第二：我们把自己最好的部分，变得更糟了。
当你的工作是监督五个人时，你一天能做的就只有插手别人的工作。他们不喜欢这样，并在匿名调查中将其标记为“微观管理”，于是你退让了。那你的时间怎么花？你讲故事，推动事情通过评审，让你的团队显得“成功”，为团队争取资源。但你不知道该讲什么故事，于是你组建一个用户研究团队来告诉你需要完成的任务，再设立一个产品营销职能来向客户讲述这个故事。这个原本因汇聚上下文和传递清晰度而具有战略重要性的职能，逐渐将自己抽象化，退入了越来越高的象牙塔越建越高。
但真正的真相存在于你系统的数据模型中，在销售电话里，在客户支持工单中，在数据分析里——而不是在那些为了简化一切而制作的漂亮 2x2 矩阵里。
你花在管理上花掉的所有时间，意味着你对问题的内在理解正在变得陈旧，你对客户的直觉正在变得迟钝，你做出正确判断的可能性正在下降。
我们作为职能部门的成功率之所以下降，既是因为分母扩大了，也是因为这种扩大意味着七年前擅长产品的人，要么被提拔到不再做实际工作的位置，要么已经足够富有，以至于留在公司，失去了留下来玩政治游戏的动力。
Whatnot 之道
从最早创立之初，Whatnot 的产品团队就建立在一个相当简单的理念之上：我们对产品管理这个职能的存在感到遗憾。在销售和工程团队被我们雇佣之前，他们合作得很好，所以只要可能，他们就应该直接交付，不需要程序性的审批或繁琐的文书工作。产品是一门手艺，不是一种资格认证。任何做得好的人，都是通过实践，以及和优秀的人一起实践来学习的。
我最近参加了一次面试，有人告诉我 Whatnot 感觉像是 Twitch 和 eBay 生了个孩子——从文化上讲，这错得离谱，但从产品范围来看，这倒是个不错的类比。保守估计，这两个组织加起来有超过 400 名产品经理。我们有 20 个。20 个产品经理服务于 1200 多名员工。
我们的产品经理对应的是问题，而不是工程经理。这两者经常重叠，但并非同一回事。如果你正在为时尚卖家的新销售形式，你会与负责列表和库存的工程经理紧密合作，同时也要与物流和支付的工程经理密切配合。
必须跨多个技术栈工作，并权衡对不同客户的影响，这并不容易——它需要对业务背景，具备预见任何功能变更下游影响的能力，拥有出色的上下文切换能力，以及在整个组织中建立和消耗信任的能力，而不仅仅是与一个合作伙伴。这就是为什么我们几乎只招聘高级产品经理。那些厌倦了无休止的对齐会议、渴望再次动手构建的产品经理。或者，我们会将有潜力的销售或运营人员转岗，让他们在实践中学习。我们一直在寻找能打出“一杆进洞”的中期 L5/L6 级别人才，但统计数据不会说谎，我们找到他们的概率有多低。
最后，每个人都要交付产品，包括我在内。我一直以一个独立贡献者的身份，直接与工程师和设计师团队合作交付功能，我们的两位联合创始人也是如此。当需要测试产品经理是否可以通过“氛围编码”来构建小功能时，我就是那个小白鼠。当需要在澳大利亚上线我们的第一个卖家时，是我们的联合创始人 Logan 去做的。当 Zendesk 开始出现客户工单问题时，是我们的 CEO Grant 在与他们的支持工程师沟通。
作为一家公司要求每位员工都必须参与销售、购买和处理客户工单，否则我们会给予低于预期的评级。如果产品经理要在一个如此致力于以客户为中心的公司中担任领导角色，我们就必须深入了解事物如何运作，并广泛理解其背后的原因。我们称之为“T 型人才”——同时拥有广博的背景知识和所在领域的深度。深度和经验让你能够快速做出决策，而不必等待五层管理层审批，这意味着这些决策能迅速转化为行动。
技术成员
现在关于“构建”的噪音太多了……不，产品需求文档并没有消亡。PRD 只是一个清晰思考问题并向他人阐述的载体。如果你喜欢，可以让它变得互动，没人在乎。不，交付一个糟糕产品的成本并没有降到零，它仍然由你的客户承担。以快 16 倍的速度向他们扔意大利面，实际上并不是一场革命，只会让人厌烦。而且，不，不是每个人都能同时成为 S 级的工程师、设计师和产品经理。少数人可以，但同样的专业化驱动力——人们喜欢什么、擅长什么——仍然会主导我们的工作方式。
真正在转变的是，人们意识到，做一个独立贡献者，对许多人的技能、经验以及在这个世界上有限的时间来说，是比第五次重写同一份文档以适应当前吹毛求疵者偏好的格式更好的利用方式。Whatnot 有几位产品经理是管理者，但他们每个人 90% 以上的时间都花在独立贡献者角色上。我们的头衔或薪酬对管理者和非管理者没有区别，因为我们不认为管理本身有什么固有的价值。AI 给了我们不可思议的杠杆作用——我几乎可以在开发过程的几乎每个任务上更快地行动，无论是理解过去需要数据科学家才能理清的数据，还是将 PRD 转化为客户支持标准操作流程的各种变体（这些通常需要在发布周在办公室熬夜完成）。我可以构建一个机器人来分类每周来自销售的 100 个问题，或者找出我们最近实验中遗留的本地化漏洞。
AI 对产品经理来说，AI 对产品经理来说最具颠覆性的一点是，它表明通过指导他人并让他们工作来获得杠杆，已不再是曾经那种单一的杠杆来源了。尤其是当那些人——并非他们自己的过错——非常平庸。但这种杠杆只对那些仍然知道如何做实际工作的人可用。
这个趋势特别令人鼓舞的地方在于，它将吸引最优秀的产品经理回归到真正的产品管理工作上。思考客户和业务的需求，以及用最佳方式解决这些问题的良好品味。作为其他公司的客户，我很高兴看到我们行业的杰出人物回归构建——这会让他们的产品变得更好。作为一个痴迷于打造历史上最小、杠杆率最高的产品团队的人，我很高兴看到它能释放那些五年来一直在敷衍路线图评审的杰出人才。
展示，而非告知
下面我将完整复制我们关于 Whatnot 产品工作方式的唯一文档。如果你和我见过哪怕一次面，你都不需要我告诉你作者是谁——这就是我们说话和工作的方式。
你也可以去看看我们团队有哪些人——团队里至少有六个人，他们有能力在 B 轮到 C 轮创业公司担任 CPO，却会花整个晚上与卖家通电话，在 Hex 线程中深入查询 400 次，或者起草明天发布的 v1 版本沟通稿。团队里有四位前创始人，他们一生中从未认为某件事超出了自己的职责范围。有四位前 FAANG 总监，他们不再花时间争论人们应该放在九宫格里的哪个位置。有六位早期阶段的产品经理，他们品味极佳，被告知需要尝试更多事情，因为我们只通过实践来学习。
我怀疑我们最初设定的最多 20 名产品经理的宣言不会持久——Whatnot 面前的机会如此巨大，我们不会武断地限制自己——但随着行业和 AI 工具继续奖励优秀的独立贡献者以杠杆，我们招聘的门槛只会越来越高。如果你是这样的人，并且我上面描述的内容让你感到兴奋，你会找到联系我的方式。
在 Whatnot 构建
构建伟大的产品很难。你不仅要对问题有正确的洞察，要处理好细节，要正确地将产品推向市场，要准确地衡量其表现以便理解其性能或快速迭代。你必须同时做到所有这些事情，否则就行不通。更糟糕的是，失败代价高昂。我们团队很少，但面前有巨大的机会——在 MLB 打出 0.300 的打击率很棒，但要实现我们的雄心，我们需要接近 500 的打击率。没有高成功率，我们要么在短期内限制短期增长，要么将业务增长与人员增长挂钩，从而限制长期发展。
本文档分为两部分：
- 我们的理念——这不会改变
- 我们的流程——这些会演变，当前状态记录在此
我们构建的方式赋予我们杠杆作用
你不能一个房间一个房间地建造一栋建筑，你必须一次性设计整栋建筑并一次性建造它。幸运的是，我们不是在建筑行业工作，我们在软件行业工作。迭代构建是我们的超能力。我们总是启动能提供真实用户价值和良好用户体验的最小单元，但我们会进行更长远的设计，以确保我们能够扩展它。
一个成功产品在这里的快乐路径，始终遵循 7 个步骤：
1) 它必须对用户和我们的业务至关重要
无情地优先处理那些能为用户和业务需求带来最大影响的事情。
- 你必须能够明确阐述其价值，例如“通过将‘发货地’从节目字段改为产品字段，使规模化零售商能够在单场节目中销售存储在多个地点的商品”
- 从系统角度思考。
- 这个产品在发布时是否立即可用？
- 它是否是其他功能的“构建模块”？
如果 (1) 不成立，就不要进行。如果 (1) 成立，则思考如何让它随着时间的推移变成 (2)。
2) 它是人们想要的东西
理解他们的痛点、欲望和行为，为他们创造产品。
- 除非你详细了解你为之构建的用户，否则你无法知道这一点。将定性和定量结合起来。
- 在现有产品工作流程的背景下思考你的产品。
- 不要在糟糕的基础上叠加。
- 不要因为你专注于问题 A，就破坏掉解决问题 B 的工作流程。
- 如果问题是真实的——你知道他们今天是如何绕开它的？
- 警惕华而不实的东西。尤其是你过去在其他地方构建过的华而不实的东西。
3) 客户需求与我们的组织架构图并不一致/永远无法通过单一功能满足。
如果你只在局部构建，那你就是在天真地构建。
- 你必须从完整的客户体验出发，而不是从代码所有权出发。去解决问题，就这么简单。
- 反之亦然——其他产品经理们也需要介入“你的领域”。帮助他们。
- 这个原则就是我们为什么力求拥有尽可能小的产品和设计团队。角色定义得越狭隘，路线图就越短视，我们浪费在协调和沟通上的时间就越多。
4) 这是解决问题的最简单方案。
快速构建用户喜爱的可靠产品的关键是避免不必要和没有影响的工作
- 简单不仅构建速度快，而且通常也是最成功的。
- 思考系统并不意味着要一次性构建整个系统。
- 在确定自己正确之前构建得越多，犯错时的代价就越大。
5) 它已经用最小的受众进行了验证。
在有人使用它之前，你只是在猜测。
- 尽快将纸质原型或可点击原型交到卖家手中。员工内部试用在发现错误方面比验证解决方案更有效，因为我们不是我们的客户。
- 思考你的市场进入策略
- 面向卖家的产品：从少于 10 个卖家开始，按卖家数量或品类扩展，然后再全面上线。
- 面向买家的产品：从一个品类或一小部分用户开始，根据信号逐步扩展。
- 生态系统产品（对双方都可见）：从一个品类或一个小市场开始
- 如果你处于验证模式，追求知名度（内部或外部）是一种失败模式。
- 规模太小，实际上不会对人们产生影响
- 你还不知道它是否会成功——不要浪费大家的时间
6) 一旦验证，我们就疯狂迭代。
一旦对客户上线，我们每周甚至每天都会进行改进。
- 如果你听到“一旦我们交付了 X，就可以转向 Y”，这是一个巨大的危险信号。
- 一旦我们知道它会成为一个东西，你需要回头解决品类和客户支持问题
- 发布、验证、衡量、迭代、再迭代 > 然后转向下一个优先级。
7) 一旦进入测试阶段，我们就要全力以赴。
获得一个火花很难。一旦你有了，就必须浇上燃料，否则它就会熄灭。
- 发布超简单、超早期产品的最大风险是它们不完整，因此不具备真正的长期价值。一旦发布，你就在倒计时，从高潜力转向高影响力。
- 专注于最大化你创造的价值，而不是处理每一个小小的抱怨、风险或后果。
- 弄清楚哪些抱怨、风险和后果需要担心，是每次发布都需要判断的问题。担心非风险与未能担心风险同样危险。
8) 这不是单身汉节目——解耦一切
在设计系统时，有一种自然倾向，即希望一次性交付多个部分。在我们这样足够复杂的系统中，很可能多个团队并行处理系统的不同组件，将它们一起交付似乎很合理，这样就是一个大变更而不是两个。但这也是一个陷阱。
- 只要每个部分对客户来说是独立可行且有益的，就尽快发布它们
- 这让我们能更有效地衡量每个部分，并理解它们的相对贡献
- - 让有益的产品在预发布环境中等待其他产品，对客户不利
评审和反馈的角色
我们记录了一个产品流程，其目的是确保我们在做正确的事情，并以正确的方式做。这包括可见性、审批和问责功能。然而，比盲目遵循该流程更重要的是内化其背后的理念——这在这篇推文中阐述得很好……（说真的，在继续之前先读一下）
- 在一个复杂的系统中，你需要比你以为的更多的对齐，才能真正得到正确的答案。因为这个词可能被误解：
- 对齐从不意味着共识。共识是良好决策的敌人。
- 对齐并不意味着耦合工作流。协调是速度的敌人。
- 对齐的试金石——一份书面计划。如果 Grant 在要求一份计划，说明我们还没有对齐。
- Whatnot 的自主权是执行层面的自主权。没有人拥有或应该期望战略层面的自主权。没有对齐，自主权就会被浪费。
要在 Whatnot 达到期望，产品经理或设计师必须：
- 立即识别需要对齐的事项并积极寻求对齐
- 从对齐快速过渡到执行，因为他们深刻理解讨论内容和对齐结果。他们不会在讨论中只等待一个“同意”。
- 能够与团队一起填充执行细节/快速解决对齐后遗留的决策问题。
为什么速度很重要
我们的整个系统都建立在最大化交付正确事物的速度之上。快乐路径的 1-3 步是关于弄清楚我们认为正确的事物是什么，4-7 步是关于我们如何验证、迭代和扩展该事物。我们这样做是因为：
1) 我们系统中的一切都会产生复利——好的和坏的
2025 年，我们在大约 250 个工作日里运行了 750 个实验，相当于每天大约做出 3 个“发布/不发布”决策。如果你模拟每个决策仅加快 3 个日历日的长期影响，在 2 年时间范围内，Whatnot 卖家将获得超过 11 亿美元的增量收益。这不是这些产品本身的影响，而仅仅是让这些决策稍微快一点所带来的影响。延迟交付正确产品的每一次，都会伤害我们的客户，而且我们规模越大，速度的机会成本就越高。
2) 速度一旦失去，就再也回不来
人类自然会遵从并依赖流程，因此即使是为狭隘用例发明的流程，也会被比预期更广泛地应用。激励机制转向遵循系统，而不是产生系统旨在确保的影响，组织的“知道，但立即行动”的肌肉记忆会萎缩并消失。几乎没有任何一个我们可以预防的单一错误，值得用长期降低我们构建速度来换取是值得的。
3) 速度并不是犯错/出错的原因
委员会只能通过阻止进步来防止错误。判断力才能真正防止错误。更频繁地交付能锻炼我们的判断力——就像运动员一样，我们通过重复练习变得更强。在积累重复练习的同时，团队可以利用拥有更多重复练习和更多背景的人的判断力——来自产品领导层的持续临时指导，在规划的最早阶段就进行关键风险缓解（如法律和公关）的可见性（如果大西洋上有飓风需要避开，我们需要在规划航线时就知道，而不是在起航时才知道），以及能够代理特定客户反应的品类或国家负责人。作为系统思考的一部分，产品经理应寻求预测其发布的影响，但绝不会因为寻求或接受了任何反馈/意见而被阻塞。产品评审是我们开发流程中唯一的关卡。
