解读亚马逊独特的工作方式 | Bill Carr（《逆向工作》作者）

Bill Carr 2023-11-02

解读亚马逊独特的工作方式 | Bill Carr（《逆向工作》作者）

解读亚马逊独特的工作方式 | Bill Carr（《逆向工作》作者）

文字记录

……Jeff 会说，我们将其视为一条信念：如果我们服务好客户，如果我们把客户放在首位并为他们创造价值，那么销售额、营收、活跃用户数，乃至于股价和自由现金流，这些东西自然会随之而来。因此，当我们做决策、思考问题时，我们会从”什么对客户最有利”出发，然后从那里往回推导。这就决定了你需要做什么样的工作，才能为客户打造出新的解决方案。

Lenny： 今天的嘉宾是 Bill Carr。Bill 是《逆向工作》一书的合著者，这本书是他和合著者在亚马逊多年工作中最重要的经验总结。Bill 在亚马逊成立仅五年后加入，在那里工作了 15 年，最初负责图书业务，后来担任数字媒体副总裁，创建并管理公司的全球数字音乐和视频业务，包括 Amazon Music、Prime Video 和 Amazon Studios。离开亚马逊后，Bill 曾在早期风投公司 Maveron 担任驻场高管，之后担任 OfferUp 的首席运营官。如今，Bill 经营着一家名为 Working Backwards, LLC 的咨询公司，与合著者 Colin Breyer 一起帮助成长期和上市公司落地在亚马逊发展出的各项实践方法。

在这次对话中，我们深入探讨了如何真正落地那些帮助亚马逊取得如今成就的工作方法和实践，包括”逆向工作”的具体流程、如何用单线程负责人（single-threaded leader）来组织团队、如何将指标划分为投入指标和产出指标、如何实践” disagree and commit”（反对但执行）、如何在招聘流程中实施 Bar Raiser 项目等等，内容非常丰富。

非常感谢 Ethan Evans 促成这一期节目并将我介绍给 Bill。好了，简短的赞助商环节之后，有请 Bill Carr。

亚马逊贡献的独特工作方式

Lenny： Bill，非常感谢你的到来，欢迎来到播客。

Bill Carr： 谢谢，Lenny。非常感谢邀请，很高兴来到这里。

Lenny： 这是我的荣幸。我在读你的书时注意到一件事——亚马逊对科技和商业界的运作方式贡献了非常多的新方法。我列了一个小清单，想看看有没有什么我遗漏的显而易见的东西。比如，“逆向工作”的理念、单向门与双向门决策、“反对但执行”、投入指标和产出指标、用备忘录代替 PPT、两个披萨团队，以及后来演变为单线程负责人的概念。还有没有其他几乎太显而易见以至于我没意识到的、亚马逊贡献的核心做法？

Bill Carr： 有一个不那么显而易见的，就是亚马逊创建了一套非常真实有效的领导力准则（leadership principles），以及配套的流程来强化这些准则。我认为我确实没有见过任何其他公司做到类似程度的事情。这是非常刻意为之的。所以这也是我们在书中试图指出的一个独特之处。

Lenny： 太好了。我们之后也许会回到这个话题，因为这也是一种非常强大的机制。我想问的问题是，有些公司比亚马逊更大、更成功、历史更悠久，但我认为没有哪家公司贡献了如此多独特的新工作方法，并且还能把它们提炼成如此易于传播的形式。你认为亚马逊之所以能够形成这种工作方式，并让这些做法在企业文化中如此广泛渗透，原因是什么？

产品创新与流程创新

Bill Carr： 这其实也是 Colin 和我决定写这本书的原因之一，因为大家都知道亚马逊是一家创新产品公司——至少在我任职的那段时间，也就是 1999 年到 2014 年底，公司推出了各种创新产品：Kindle、AWS、Alexa、Echo，还有 Prime 会员订阅本身也是创新性的……

Lenny： 顺便说一句，这些东西大家都用。

Bill Carr： 是的，全球有很多人在使用这些产品。显然，Jeff 是推动这些产品的重要力量。但人们没有意识到的是，亚马逊在某种程度上同样专注于流程创新。顺便说一句，在很多情况下，我们是站在他人肩膀上的，我们不能把功劳都归于自己……这些做法中的大多数都有其他灵感来源，或者是在他人工作的基础上发展而来的——顺便说一句，我认为所有伟大的公司都应该这样做。这也是我们写书的另一个原因：我们希望让人们站在亚马逊的肩膀上，学习我们的经验，然后选择全部或部分采纳这些做法，在此基础上继续构建。

但更直接地回答你的问题——这一切是如何发生的、为什么发生。产品创新和流程创新实际上都集中发生在一个很窄的时间窗口内，即 2003 年到 2007 年。在这段时间里，我刚才提到的所有产品，以及除一项之外的所有流程，都是在短短四年内开发出来的。

Lenny： 哇。

从超高速增长到规模化

Bill Carr： 这个时期实际上正是我们从超高速增长阶段——从零到一的公司——转向我所说的从一到一百、到一千、到无穷的阶段。公司必须迈出的下一步，就是一切开始变得非常复杂。我们不再只是一家书店，我们卖很多东西。事实上，我们已经不只做零售业务了，我们有了第三方平台业务，那时候还在试验为第三方零售商代运营网站。我们在不断开发新业务，在全球许多国家开展经营。所以我们变得非常复杂。这时你会到达一个临界点——CEO 无法再参加每一个重要会议，无法再参与每一个人的招聘。你需要一套系统、一套方法来高效地运营公司。而 Jeff Bezos 本质上是一个非常注重科学和分析的思考者。

他的本科学位是计算机科学，我相当确定。不过我想他最初其实是想拿物理学学位的，后来转到了计算机科学。他早年在 DE Shaw 做华尔街的量化分析师，是非常有量化思维的人。所以当他思考这个问题时，他用了这种思维方式，他说：“我需要用科学的方法来对待这件事。需要有一套系统、某种方法或机制，让我能够管理这样规模的公司。所以我要像科学家一样做实验——尝试不同的想法和假设，实施它们，看哪些有效，然后迭代改进。“这就是我们采取的思路……顺便说一下，这种思路我们既应用于流程创新，也应用于产品创新。

未能推广的流程实验

Lenny： 太棒了。我曾经采访过 Eric Reson，他也碰巧……我当时也想到了这一点，他对科技行业的运作方式贡献了很多核心概念，而且他实际上提到了一些被搁置的想法，基本上是他认为大家会在各处采纳但最终没有的东西。我很好奇，在亚马逊有没有这样的例子——你们建立了一个流程，给它起了一个很巧妙的名称，但最终从未推广开来，或者在亚马逊内部根本就没有奏效？有什么例子吗？

Bill Carr： 开发团队、设计团队、产品团队都在一个组里，他们会自主运作，但并非完全自主，因为我们——高级管理团队、Jeff 和 S-Team——需要确保他们的方向是对的。所以我们创建了一个叫适应度函数（fitness function）的东西：找出对你这个领域最重要的四五个或六个指标，给每一个设定权重，然后创建一个综合指数，我们上下追踪这个指数。这就是适应度函数。

Lenny： 这是一种非常极客的组织团队的方式。我喜欢。

Bill Carr： 是的，非常极客。但做了不知道多久，几个月或者一年之后，我们意识到适应度函数并不是一个好主意。这就是我所说的复合指标（compound metric）——试图把几个重要指标揉合成一个。问题是它实际上变得完全没有意义。当你衡量事物时，你试图理解哪些行动或反应正在创造你想要的良好产出——收入、客户增长。但把它们全部合在一起，你基本上就把因果关系遮蔽了。我们真正意识到的是，需要把这些指标逐个拆开，分别以各自的方式去管理。所以今天，我不鼓励团队和公司创建任何类型的复合指标。

Lenny： 我曾经也做过一次，也是个糟糕的主意。我们有六个不同的指标，每个季度我们打算提升其中一个，它们共同贡献于一个更高的指标。结果我们发现，我们永远无法在某一件事情上变得擅长，而且结果发现总有一件事对更大的目标影响最大。所以最终你还是只会专注在那件事上。

深入理解单线程负责人

Lenny： 让我们更深入地聊聊单线程负责人这个话题，既然你提到了它。这个概念在我的播客上已经多次出现，很多人都在以这种方式工作——设有单线程负责人。显然，这种做法是有效的。我想帮助大家理解，单线程负责人到底是什么意思，以及为什么它是一种如此有效的工作方式。

Bill Carr： 单线程领导力的概念最初正是诞生于亚马逊这段复杂化时期。再说一遍，大型组织——一旦达到一定规模，你会面对相互竞争的部门、相互竞争的利益，它们在争夺某个集中的资源池。对于在科技公司工作的人来说，这个池子就是工程资源，或者今天的数据科学和 AI 资源。可能还有其他稀缺资源，设计往往也被视为稀缺资源。但关键在于，现在所有这些团队都想要那池资源来为他们构建东西，但他们彼此之间存在竞争。大多数公司通过建立一个高度集中、高度协作的流程来解决这个问题。而我们决定反其道而行之，原因我前面提到过——我们发现大量时间都花在这些会议上做规划，而我们做的很多工作、创建的产出物、文档、预测，实际上也没有太大用处，很大程度上是官僚主义的时间浪费，因为其中很多假设本身就存在严重缺陷。

你在这类文档中辩论的数据，建立在有缺陷的假设之上，这是浪费时间。所以我们转而思考如何获得……我们真正想要的三个东西是主人翁精神、速度和敏捷性。于是我们进行实验，说：“让我们创建能够独立运作的团队——有一个单一负责人，他所需要的跨职能资源要么直接向他汇报，要么是专门分配给他的。“所以他们不一定必须是直线汇报关系。在亚马逊，大部分是直接汇报，也有一些虚线汇报的情况，但也可以全部是直线汇报，也可以全部是虚线汇报，也可以两者混合。但从根本上，我们从所谓的项目导向（project orientation）转向了项目制导向（program orientation）。

项目导向意味着：哦，我们要做一个改变搜索结果页面和算法的项目，项目以这种方式定义，需要六个月。资源会集中过来做这件事，然后又转到公司其他地方的另一件事上。而项目制导向则是——继续用搜索为例——有一个团队专门做搜索，他们一直做搜索。他们不再以逐个项目的方式来思考问题，而是从全局出发思考需要做什么来改进搜索。他们有一组指标，以此为目标来推动这些指标，这些指标很大程度上是他们可以控制的。比如：客户在搜索页面点击前三个结果的比例是多少，或者在某种浏览器、某种设备上页面加载需要多少毫秒，等等。

团队自主路线图与资源管理

Bill Carr： 他们可以运营自己的路线图。他们自己决定最重要的事情是什么，排出优先级清单，用手中拥有的资源从列表顶端开始逐一推进。有时候——实际上大多数时候——他们可能想要更多资源来完成更多事情，但他们花在争夺资源、资源内耗上的时间更少了，转而专注于用手头的资源去构建他们能构建的东西。

这样做的好处是，无论成功还是失败，现在都取决于他们自己了。他们唯一可以争辩的是如果有更多资源会做得更好，这一点可以向管理层申请。但这种方式同时也解决了一个重大的管理问题——高层管理者不再需要为路线图上的每一个项目做裁判，而是裁判哪些团队拥有多少资源，这更像是一年一两次或三次的决策，而不是对产品路线图上的每一件事都做裁判。而资源争夺问题是每天都在发生的。所以，这让团队真正解放出来全力冲刺。不过，要为此做好准备需要做大量工作。比如，在软件环境下，我们刚起步时有一个不太美观的单体代码库（monolithic code base），那时候我们还没准备好做这件事，因为存在大量相互依赖。

架构转型与对策措施

一旦我们转向基于服务的架构（service-based architecture），团队就能拥有自己的代码，有定义清晰的端点、有文档完善的 API 供其他团队理解，我们才能朝那个方向推进。另一件事是我们必须创建我所说的”对策措施”（countermeasures），因为组织架构中没有免费的午餐——任何组织架构都是在做取舍。在这种情况下，你可能牺牲的是职能卓越（functional excellence）。换句话说，如果你不再让每一个工程师、每一个市场人员、每一个产品人员或每一个商务拓展人员向该职能的 C 级领导汇报，而是把他们分散到公司各处的小团队中，向一位很可能并不具备其所领导的多个职能领域专业知识的通才汇报，你就会面临一个风险：这些团队中的人无法提升职能能力。这就是弊端。我们可以展开谈更多，但我们创建了许多对策措施，在构建这些单线程团队的同时仍然保持职能卓越。

Lenny： 再深入挖一下，这个模式的起源是亚马逊认识到最好的成果来自一个人的愿景、一个人推动、一个人的责任由一个人承担，而不是常常出现的委员会决策方式吗？

Bill Carr： 与其说是这个原因。我想澄清的是，这是一个领导者及其团队共同承担责任。关于我们要构建什么、如何衡量成功等等，这个团队和这位领导者负责将其写成文档、制定计划。当然，他们不是随随便便就可以放手去做。亚马逊有非常严格的评审流程，在某个层级——可能是副总裁、高级副总裁，一直到 Jeff 层面和他的直系下属组成的 S-Team——这个计划会被深入审查和质询，会有讨论和交流，基本上是在高层领导团队和各个单线程团队之间就计划达成一致，然后团队才能放手执行。

放权与问责

美妙之处在于，一旦我们完成了那些讨论和交流，团队就可以按照自己的计划全力冲刺。他们不用再担心”我和 CEO 对齐了吗？我和高级副总裁对齐了吗？“他们可以确定自己已经对齐了。但这种方式确实创造了清晰的问责——他们能否交付，取决于那个负责人和那个团队。而当你采用高度跨职能的方式，路线图上的某个项目没有一个明确的负责人时，我见过很多 CEO 气得抓狂，说：“这里没有任何主人翁精神和问责制，我该怎么办？“他们就像在推一根绳子，使不上力。因为做不到——不同的人、不同的领导各自部分拥有一长串事务的所有权，而不是完全拥有少量事务的所有权。

GM 模式与单线程负责人

Lenny： 很好。我喜欢”推绳子”这个比喻。这种方式和 GM 模式类似吗？还是说当有人考虑采用 GM 模式还是单线程负责人方式时，有很大区别？

Bill Carr： 是的。显然，人们对 GM 模式可能有不同的定义，但我认为它的核心是这个人是一个 P&L 负责人，当然你可以在一个 P&L 内部再创建更小的 P&L。比如在图书业务中，我们可以——虽然大多数时候我们没有这么做——为虚构类图书单独设立一个 P&L 负责人，或者为专业和技术类图书设立一个，那是一个非常大的品类，与其他品类有很大差异。然后你说：“好，这个团队拥有自己专门的团队，完全对营收数字和其他指标负责。“但你在执行时需要深思熟虑，因为建立这类团队时必须问的三个问题之一是：这个团队是否有足够的资源处于自己的控制范围内，来有效管理这个部门的这一部分、这个产品、这个 P&L？

有时候，如果你在某些情况下把范围缩得太窄，答案就是否定的。在其他情况下，答案可以很容易是肯定的。一个很好的例子是在 Prime Video——我管理的业务之一——我们可以创建一个单线程团队专门做电视设备上的应用，比如三星、索尼。我们可以创建另一个团队做游戏主机，还有一个团队做手机和平板。然后在每一类里面，还可以进一步拆分。可以有一个团队专门做 Xbox，另一个做 PlayStation，另一个只做 iOS。在这些情况下，如何拆分团队就非常清晰，他们也能拥有非常明确的职责边界。

职能对策措施的具体实践

Lenny： 很好。让我们回到对策措施这个话题，然后再更广泛地展开。你提到在转向单线程负责人模式之前，有一件需要先落实的重要事情是创建 API，基本上是拆分那个单体架构。你认为要成功转向这个模式，还需要落实哪些东西？

Bill Carr： 另一件就是这些职能对策措施。我们以工程为例来说明。2004 年、2005 年左右，我开始管理一个单线程团队。实际上管理了两个不同的团队，一个做音乐，一个做视频，也就是现在的 Amazon Music 和 Prime Video。当时还不叫这些名字。但那时我开始管理一个小规模的软件工程师团队。而我呢……我确实写过代码，但那要追溯到高中时代了，而且我们说的是 Basic 和 Pascal。我有一个商科硕士学位，背景是市场营销。我是一个通才。所以我没有能力去做辅导——我不可能做代码评审，不可能做架构评审，不可能辅导或指导一个工程师如何提升专业技能。但像我这样的例子在亚马逊比比皆是。

也可能出现相反的情况：我未必是业务出身的负责人，而可能是一个纯粹的工程师，现在却要管理一个负责市场营销和商务拓展的团队。如果我的背景一直偏工程，那我对这些事情就一无所知。所以我们的做法是——我还是继续以工程为例——我们制定了各种对策措施。其中一个例子是，我们仍然有一位 C 级别的工程负责人，就是 Rick Dalzell，大多数核心基础设施和核心服务仍然向 Rick 汇报。所以——

Bill Carr： 核心服务仍然向 Rick 汇报，比如支付、基础设施搜索等等。Rick 仍然可以担任整个公司的技术领导者，他和他的团队可以制定诸如：我们在全公司范围内进行代码评审的标准方式是什么？我们在全公司范围内面试和筛选工程师的标准方式是什么？晋升流程是什么样的？从 SD1 到 SD2、SD3 的明确步骤是什么？我们如何记录和描述各个级别的要求？类似这样的事情有很多。

这实际上也意味着，任何一位工程副总裁，或者在很多情况下一位总监，他们除了本职工作之外，通常还会承担一些与专业领域相关的额外工作，为公司做出贡献。一个很好的例子是，他们可能会参与工程领域某个级别到另一个级别晋升的评审委员会，或者他们可能会为其他组织做本职组织之外的代码评审。所以人们除了日常本职工作之外还有其他职责，以建设和维护职能卓越。全公司有很多这样的例子。

“反对但执行”原则的正确理解

Lenny： 让我们换个方向，聊聊我最喜欢的亚马逊领导力准则之一——“反对但执行”（disagree and commit）。我觉得连我自己描述它的方式都是不对的。我觉得人们听到这个词后，经常错误地使用这条准则。比如，它实际上是从”敢于坚持立场”开始的，然后才是反对和执行。我很想听听你怎么看这条准则在实践中被正确执行的例子，以及人们在自己公司尝试落地时应该怎么做、怎么思考。

Bill Carr： 我在亚马逊的时候，一共有十条领导力准则，后来他们扩充了。但在这十条中，这条一直是理解得最差的，我在亚马逊的时候也是如此。部分原因是它实际上是所有准则中最微妙、最难以真正使用的。那么它的含义是什么呢？“敢于坚持立场并反对”，意思是当我们做出任何类型的决策——重要的决策——时，如果你是那个团队、那个单位的一员，你有义务在你不同意所采取的方向时说出你的观点。顺便说一下，这种反对的目的，通常是提供人们没有考虑过的额外信息或新的视角。

我对决策过程有点着迷，读过越来越多这方面的内容。我觉得彼得·德鲁克关于这个话题的论述可能是最好的。正如他所描述的，好的决策首先要了解当前问题或潜在方向的所有不同观点和利弊，而伟大的领导者所做的事情是主动征求这些不同的观点。他们有一个团队来辩论和讨论问题。换一种方式来理解这个概念——国王和他的廷臣。在理想世界中，假设没有政治动机，廷臣的职责是建议国王，帮助他们思考不同的问题，提供不同甚至对立的观点，让国王做出正确的决策。

这本质上没有什么不同。“反对”的部分就是提出新的信息、新的数据、新的视角，而这些与当前方向相反。这就是”反对”的部分，你有义务这样做——正如我们会描述的那样——如果有必要的话，一直上报到链条的上层，如果这是一个重要的问题而人们没有听到或理解你的观点。这里的关键点首先是关于对方是否听到并理解了你的观点。

我可以说，很多时候如果有人处于领导岗位，有人来找我表达不同意见，我往往会欣赏，因为他们会带来一些有用的视角。但有时候他们表达了反对并陈述了背后的理由，而我其实已经知道那个理由了。我们已经想过那个理由了，已经考虑过那个因素了。这种情况下我会说：“我听到了你的反对意见。我们已经考虑了那个因素。但即使存在那个因素，还有这些其他因素比它更重要。”

这就是关键节点——只要反对者从领导者那里听到对方理解了自己的观点，理解了自己为什么反对，并且似乎完全理解了，已经将其纳入考量，那就是他们应该执行的时刻。因为核心在于：你提供了你的信息，他们处理了这些信息，在了解这些信息的基础上决定了走这个方向。人们困惑的地方在于，他们可能不清楚自己应该在什么时候停止反对——这是一方面。希望刚才的解释让人们清楚了应该在什么时候停止。而”执行”的部分，做得好的话，不是那种”好吧，我执行吧，虽然我不太同意我们要做的这件事，但我会站在后面支持”。

理想的情况是——哦，现在我听到了这个论点，我实际上认真思考了这个论点，希望那个人现在已经理解了我们为什么要走这个方向。所以他们的执行承诺是建立在这种理解之上的，因为他们也可以把这种理解传达回自己的组织。因为最糟糕的做法是说：“是的，我们承诺做这件事。我其实不同意，我仍然觉得它是错的，但我承诺做。“那不是真正的执行承诺。这本质上是关于决策的——理解人们用来做决策的事实和信息，然后能够把这种理解传达回去。

仍然不认同时该怎么办

Lenny： 我能想象很多次我经历了这个流程之后仍然不认同。你对于管理者或者下属有什么建议？就是当你确实仍然不认同的时候，你该怎么做？你是表现得像”好的，我同意”而不再表达你的顾虑，还是有其他做法？

Bill Carr： 我和 Jeff 在各种新想法上有过很多合作。Jeff 的思维方式不是普通人那样的。他的创造力水平、他思考问题的方式、他思考的时间尺度——在很多方面，亚马逊没有其他人像他那样思考。所以会有一些时候，即使在我们进行了那种讨论之后，我可能仍然不同意。但接下来我会做的是，我会聚焦于：好吧，Jeff 认为我们应该做这件事的核心原因或关键点是什么？我会聚焦于那个核心。事实上，我曾经从我的一个上级 Steve Kessel 那里得到了很好的建议，他说：“你必须找到那个核心是什么，然后你的工作就是拿着那个核心去尝试推进它、扩展它，看看我怎样才能把这个想法、这个概念变成一个可行的东西。“

找到核心后再推进

Bill Carr： 这并不总是奏效，但关键在于你要真正理解那个核心是什么，而不是走过场式地敷衍了事。那样是行不通的。而且，我也见过有些人尝试敷衍了事，他们的职业发展也不会走太远。你需要有一定程度的信念，相信其中有道理，然后尽自己所能去把那部分做好。我该怎么把这个想法产品化？我该怎么从商业角度或其他各种约束条件下让它变得可行？

Lenny： 很好。所以建议就是聚焦于你认同的部分，思考如何验证它是否真的正确。

Bill Carr： 是你认同的部分，甚至你可能都不认同，而是对方认为最大的好处、最优的思考方向（thinking vector）是什么——是什么驱动他们想要往这个方向走。

Lenny： 思考方向，我喜欢这个词。顺着这个思路，另一个我很喜欢的准则是”领导者常常正确”（leaders are right a lot）。我觉得这句话几乎是不言自明的，几乎在任何公司都可以这么说。我很好奇这条准则为什么会成为一条重要的领导力准则（leadership principles），以及它在亚马逊是如何实践的。

Bill Carr： 好。回到刚才的讨论，我们都应该承认一个谬误：当你做这些决策时，当你试图用数据来做决策时，你可以让数据呈现出你想要的样子来支持你的决定。如果我在看某个问题，手头有一个大型数据集，我可以找到一些方式来看这个数据集来支持某个想法，也可以找到一些方式来看同一个数据集来反对它。所以数据很少能替你做决定。真正发生的是大量的判断和对数据的解读，权衡各种因素，然后做出决策。

这就是”常常正确”的部分。“常常正确”来自于我们所说的良好判断力，这种判断力一般来自……也许有些人天生就有，但不多，大多数人是通过经验获得的。实际上，很多经验来自于犯错，来自于做出错误的判断，通过看过大量问题、做过决策或观察过他人做决策，做一个用心的学生，然后利用这些来理解决策时如何权衡不同的信息。

所以”常常正确”意味着你擅长这一点，而且这一点会被验证。而且一般来说，人们愿意追随一个大致上方向正确的人，对吧？你是一个团队的领导者，团队从四面八方向你提出各种诉求。如果你一直往某个大多数团队成员都挠头的方向走——“我觉得那不是正确的决定”——他们不会愿意追随你太远，而你自己大概率也走不了太远。所以这是你通过经验培养的能力，我认为也来自于有机会观察和为擅长此道的人工作。

Lenny： 我喜欢这个”常常”（a lot）。我喜欢它不是”领导者总是正确”，而是”常常正确”。

Bill Carr： 对，对。没有人每次都对。那完全不现实。是的。

逆向工作

Lenny： 让我们来谈谈你这本书的核心概念——书名本身，也就是逆向工作（working backwards）。首先，逆向工作相对于正向工作到底是什么意思？

Bill Carr： 书名来源于两件事。一是领导力准则（leadership principles）中的一条，即客户至尚（customer obsession），这条准则大致说的是：优秀的领导者从客户需求出发，从那里逆向工作，去满足或解决这些需求。另一件事是，在我之前提到的那个时期，2004 到 2007 年间，我们为新产品创新创建了一个流程，叫做逆向工作 PR/FAQ 流程。这两者都指向同一个理念：你的北极星、你的出发点是——客户的问题是什么、客户的需求是什么，然后弄清楚，好吧，解决方案是什么，可能的解决方案有哪些？

去做这些事情的时候，要从不受我的财务约束、资源约束、法律约束、工程约束等所有这些约束条件限制的角度出发，因为我们大多数人的问题是，我们从那些约束条件出发，从那里正向推导；或者我们从”我需要增加收入”这样的事情出发。怎么增加收入？我需要增加活跃客户数。怎么增加活跃客户数？对于面向客户的行为，我们往往从这些出发点开始，而这经常会把你引向错误的方向。

而正如 Jeff 会说的，我们将其视为一种信念——如果我们很好地服务客户，如果我们优先考虑客户并为他们交付价值，我们将其视为一种信念，那么销售额、收入、活跃客户数、股价和自由现金流这些自然会随之而来。这一点很重要，因为至今我仍然无法给你客观的证据证明这是对的，我也不知道谁能给得出，所以这就是一种信念——如果我们这样做，我们认为其他那些事情自然会解决。

因此，当我们做决策、思考问题时，我们会从什么对客户最好出发，然后从那里往回推。在这个往回推的过程中，我们需要想清楚：要实现这个目标，我得解决这个工程问题，或者我得想办法降低这个产品的成本，或者让这个东西更快，或者解决一个或多个问题。这就是逆向的部分——它告诉你需要做什么工作才能为客户创造这个新的解决方案。

Lenny： 很好。总结一下，就是从客户的需求和问题出发，而且我认为亚马逊方法的一个很大特点是关注客户始终会有的持久问题，比如更低的价格、更快的配送等等，然后在不受约束的情况下去思考。当你帮助其他公司实施逆向工作这个理念时，是否总是从客户的问题和需求出发，而不是从收入或增长出发？还是说在不同的公司里有其他逆向工作的例子？

Bill Carr： 逆向工作这个部分严格来说是关于客户需求的。对，我们不想从收入出发逆向工作。我们没有真正把这个词用在比如成本结构这类事情上。成本结构实际上是从客户出发逆向工作的一部分——如果我们有低成本结构，我们就能给客户提供更低的价格，因此我们要想办法拥有低成本结构。因为降低成本、提高效率本身并不天然地惠及客户，因为你完全可以选择获取更多利润。只有当你决定在这样做的过程中降低对客户的价格或提供其他好处时，它才对客户有益。所以不是的，我们是在”从客户出发”这个意义上使用它，而且非常具体地，我们是在为客户打造新产品和新功能这个方法论中使用它。

PR/FAQ 流程的落地实施

Lenny： 那么当你去帮助一家公司实施”逆向工作”这个理念时，具体在战术层面你会做哪些事情？我知道 PR/FAQ 是其中的一部分，那我们来聊聊如何真正落地实施吧。转向逆向工作的步骤是什么？

Bill Carr： 第一个转变是要把”逆向工作”这个概念——它本身只是一个概念——转化成一个可规模化、可重复的流程。Jeff 的思路正是如此。最终，不展开讲起源故事了，我们开发出了这套叫做 PR/FAQ 的流程。它的意思是，每当我们要构思一个新产品或新功能时，我们先写一篇新闻稿来描述这个功能，以一种面向客户、某种程度上也面向外部媒体和公众的方式来描述它。核心理念是，这个描述必须让人一看就觉得——哇，作为客户我真的需要这个东西。

我首先做的工作就是帮助他们对产品开发流程进行调整，把 PR/FAQ 作为起点，用它来决定要构建什么。同时，也用它来在众多可能要构建的方案中进行筛选。总结来说，这个流程中的 PR 部分，你需要非常仔细、非常清晰地描述：客户是谁，他们的问题是什么，以及你计划构建的解决方案是什么。这听起来很简单、很容易，但实际上要把它做好、做到简洁清晰地定义这三点，是非常困难的。前两点是最难定义的——客户是谁？有人说”所有餐厅都是我的客户”。好吧，这是个错误。我是说，到底是哪些类型的餐厅？在什么类型的城市？什么业态？等等。然后你要解决的具体问题是什么？理想情况下，你应该能以某种方式量化这个问题，或者有某种数据或客户洞察让你理解这个问题，让你知道它是一个重要的、足够大的问题。最好是一个人们愿意花钱请你来解决的问题，因为你可以直接看这个问题的经济账——如果他们转而使用你的解决方案，对他们来说是有益的。

所以我首先帮助他们落地实施 PR/FAQ 流程，这是第一步。接下来就是在写好 PR/FAQ 之后，怎么真正去使用它们？怎么真正去完善它们？因为写 PR/FAQ 有一种迭代的性质，有点像同心圆式的评审。你一开始很小范围，一个作者，低精度地写这些内容，然后你开始分享给一个小群体，获得反馈、改进，再扩大范围，获得反馈、改进，如此循环，一直到——取决于你公司的规模和层级——最终呈到 CEO 面前。这个过程是为了强化、改进、真正把想法固化下来，并判断它到底是不是一个好想法。所以我帮助他们理解这个过程怎么运作，怎么执行这个迭代流程。完成之后，接下来就是——我拿着这些 PR/FAQ 该怎么办？我怎么把它们与我自己的路线图结合起来考虑？

PR/FAQ 的形式与写法

Lenny： 非常好，很棒的概述。我对第一部分有几个问题。你现在仍然建议人们以新闻稿的形式来做吗？感觉新闻稿已经不再流行了。你有没有建议过用推文、TikTok 视频或者博客文章的形式来替代？

Bill Carr： 好问题。首先，它并不是一份真正的新闻稿，好吗？我们可以改变它的形式，比如我们完全可以把它叫做”客户问题解决方案声明”。因为这里面真正核心的其实就是三个关键段落。对，它本来就不是一份真正的新闻稿，所以不要用那种真正对外发布新闻稿时才会用的语言。这是一个内部文档。这是第一点。

第二点，它的核心确实是第一段——一段简短的描述；第二段——问题陈述；第三段——解决方案陈述。如果你想舍弃其余部分和新闻稿的那些格式要素，完全可以。不过我认为新闻稿的形式还有其他好处，比如标题——如果标题冗长拖沓，看了半天都不知道这东西到底是什么，那就有问题了。如果你用推文的形式，反而不太合适。

日期在写新闻稿时也是一个有意义的要素。日期代表的是一个假设性的时间点，也就是你设想发布这个产品的时间。这向读者传达了信息——你是觉得这个东西简单到下个月就能上线，还是复杂到需要一年以后才能发布。所以新闻稿中还有其他一些方向性的提示。就像我说的，所有这些都是人们可以使用的工具，我相信各公司也会找到其他方式来改进这些工具。但如果你不正确地使用其中的这些部分，你其实会错失它能带来的主要收益。

Lenny： 你会尝试以那种新闻发布的方式来写吗？还是说主要就是客户是谁？你会把它包装成一种体验介绍吗？

Bill Carr： 你会尝试以那种方式来写，但有一点——不要用夸张的修辞。它应该非常注重事实，包含大量数字和数据。所以再说一次，它不像一份真正的新闻稿。很多内部的机密数据都会出现在这份新闻稿里。

Lenny： 明白了。

Bill Carr： 所以它是一个有非常特定用途的工具。

Lenny： 有没有我们可以放在节目备注里帮助大家起草这个的模板？我记得你书里可能有一个版本，但网上有没有我们可以推荐的？

Bill Carr： 有的，我们有一个与书配套的网站，是 www.workingbackwards.com，里面有一个资源板块，你可以找到模板。

Lenny： 太好了。然后关于同心圆评审那部分，核心意思就是从公司越来越大的范围内获取反馈，而且听起来其中一个重要作用就是在推进的过程中逐步获得各方的认同和支持。

PR/FAQ 并非每篇都要走到 CEO

Bill Carr： 既是也不是。首先，有些东西你可能写完之后，作为作者自己就会发现——如果我们还生活在旧时代的话——会把那张纸揉成一团扔进垃圾桶。也就是说，你自己把它落到纸面上读了一遍之后，意识到”这个想法其实没那么好，我要换一个试试”。同样地，你可能写了一篇觉得还不错，然后给你的经理或者上级看了，他们给你的反馈让你也想把它揉成一团扔进垃圾桶。

所以这个同心圆评审的部分，并不是说你写的每一篇都会一直活下去，一直走到 CEO 那里。这里没有具体统计数据，但我们可以想象一个虚拟的世界——你是一个产品经理，上面有一位产品总监，再往上是事业部的高级副总裁，最上面是 CEO。如果你真的一年写了 100 篇 PR/FAQ，可能其中 20 篇能最终到达 CEO 那里。关键在于，并不是每一篇都注定要走那么远，越往上数量越少。这引出了一个概念：你真正要创建的是一个产品漏斗（funnel），而不是产品管道（tunnel）。漏斗意味着上面进得多、下面出得少；管道意味着进去多少，另一头就出来多少。

管道方式的问题在于，你实际上没有一个方法去评估和比较——与其他你可能要构建的东西做比较，或者考虑如何配置大多数公司最宝贵的资源，也就是你的工程团队。你应该审视各种选择，而且说实话，你应该把自己当作风险投资人来看待。风投不会给他们见过的每家公司都投钱，实际上他们投资的比例非常非常低。在亚马逊，我们有大量 PR/FAQ，都是好想法，但我们没有把它们做出来，因为我们有更好的想法，潜在影响更大。这就是你想要的——创建这样一个经过深思熟虑的想法集合，然后从中挑选最好的。

将”想清楚做什么”与”怎么做出来”分成两个流程

Lenny： 感觉上这些流程基本上都是为了阻止蠢事发生。我觉得叙述文档就是一个很好的例子——你必须深入暴露自己的思考过程。这就是一个典型的例子。

Bill Carr： 是的。我想说这也是一个例子——这个流程是为了防止另一个流程，也就是产品开发流程，变成那种你只盯着”这个冲刺我们要做什么、我们要完成什么”，一味聚焦于发布东西的状态。我建议你把这两件事拆成两个不同的流程：一个是决定”我们应该去做什么”，这正是 PR/FAQ 所设计的；一旦你做出了决定，那就没问题了，把所有好的思考都用上——“现在我怎样高效、有效地发布它，尽量少出 bug 甚至不出 bug？”

Lenny： 我刚在读一篇《哈佛商业评论》的文章，好像叫”从思考到行动的鸿沟”，讲的是很多公司花了大量时间讨论想法和方案，但实际上什么都没做。所以我很好奇，在亚马逊你们是如何避免这个问题的？毕竟你们有一段时期就是在”探索、探索、再探索”，而且你们觉得这没问题。

Bill Carr： 有几种方式。当然，我多少需要想象一下那些公司具体存在什么问题。其中一个版本的问题，我称之为”大想法没有充分展开”的问题。我确信每个听这个播客的人都自己做过这件事，或者在公司里见过别人这样做——有人提出了一个概念，“我觉得如果我们做这个东西，真的能解决问题，或者效果很好，或者能带来增长。“听起来对谁都好，对你好，对大家都好，然后你也许就开始动手构建它了。但现实是，一旦你花时间更深入地审视这个想法，你就会开始发现几个障碍，或者甚至发现一个致命缺陷。实际上，你不应该浪费任何时间去构建那个东西，因为它有致命缺陷。

所以一个问题是，公司之所以陷入困境，我认为是因为他们从来没有真正去做那份文档化工作。大家只是围绕一些没有充分展开的概念进行辩论和讨论，所以人们并没有一个好的方式在任何现实层面上去评估这些想法。在这种情况下，最终做什么更多取决于政治、个人意志，或者一种完全自上而下的文化。另一种情况是，他们在讨论和辩论的东西缺乏好的方法让想法推进到实际构建阶段——也就是说他们可能没有合适的组织架构或流程，把好想法交给一个负责人去深入调研，调研之后如果可行，再由他和他的团队真正去构建。

随着我在公司级别越来越高、职责范围越来越大，我常常发现当一个想法出现，而这个想法又不完全适合我现有的组织架构时，我没法简单地把它委派给某个人。我只有两个选择：要么干脆搁置，因为否则它只会分散大家的注意力；要么我认为这个想法足够有说服力，决定调配一个资源——可能是一个人，也可能是一整个团队，取决于想法的大小——让这个资源专门去研究它、推进它。否则，这件事永远不会发生。

Lenny： 这种情况我经历过很多次。好的，结束之前我还想再聊两个概念。下一个是投入指标（input metrics）和产出指标（output metrics）的概念。这在 Airbnb 时我们大力推行过，变成了一种非常有效的思维方式。实际上 Airbnb 后来招了很多亚马逊的人，很多高管。所以我们做了不少类似的事情，比如叙述文档。关于投入指标和产出指标，你能描述一下这是什么、为什么这么重要，以及为什么人们往往以错误的方式思考指标吗？

投入指标与产出指标

Bill Carr： 好。这个概念的起源，同样来自亚马逊早期，99 年、2000 年、2001 年。那时我们已经是上市公司，在增长。但后来增长开始……不是一路向右上角冲的那种”太棒了”。每家公司最终都会撞到一堵墙。如果你运气好到经历过一家公司永远向右上角走、没有重力的，那你走运了，因为大多数人没体验过那种事。

大多数人经历的现实是，有很多重力在拉扯你的营收数字。你制定了一个计划，想要增长 15%、20% 或 75%，或者不管什么数字，结果看起来这个季度要达不到了。于是接下来就是”我们达不到目标了，怎么办才能达标？“这通常发生在季度还剩一个月或一个半月的时候，然后我们就像无头苍蝇一样到处乱跑，想出一堆点子——往往是促销性质的、降价性质的，或者多发一封邮件、多投一个广告之类的——

Lenny： 又一个 Prime Day。

Bill Carr： 对。现实情况是，我们确实那么做了，经历了足够多次，好几个季度，然后开始意识到，“嗯，这些消防演习其实没什么用。“那些最后关头决定去做的事情，并没有真正对数字产生有意义的推动。而且，顺带一提，它们还是巨大的干扰。即使真的起了点作用，也不过把下个月或下个季度本来就会进来的收入提前拉到了这个季度而已。所以这并不是一个真正的零和博弈。我们意识到，我们并没有真正在做那些对客户重要、能在长期内真正推动变化的事情。

大约在同一时期，Jeff 和 S-Team 正在读《从优秀到卓越》这本书。你得去问 Jeff 具体是什么感受，但如果你问我，我认为这是对我们公司影响最大、最有效的一本管理书。因为它促使 Jeff 做了一些事情，我不会详细描述……你们大多数人可能知道这本书是什么，如果不知道，去读一读《从优秀到卓越》。在我看来，这是你能读到的最好、最重要的管理书。因为它帮助我们系统化地梳理了我们的增长飞轮——也就是说，如果我们改善了这些因素，哪些东西会被带动起来。在我们的案例中，就是：我们如何拥有广泛的选品？我们如何提供出色的客户体验——或者更准确地说，在零售业务中提供出色的客户体验？比如，找到你想买的东西有多容易，购买过程有多容易，送到你手上有多快。价格够低吗？我们的平台上有大量商家吗？以及，我们能否持续降低成本？

于是我们在飞轮上识别出了这些要素。这个识别过程对公司的意义极为重大，因为它让我们意识到，“好，那我们需要做的就是集中精力，搞清楚如何衡量每一个要素，然后如何改善每一个要素。“所以它把我们的注意力从短期思维——即推高营收数字——转移到了长期思维：只要我们持续改善这些东西……不会有人十年、二十年、三十年后醒来然后说，“在其他条件相同的情况下，我更愿意在一个商品更少而不是更多的商店购物，更愿意在价格更高而不是更低的商店购物，更愿意在一个送达更慢而不是更快的商店购物。“所以只要我们能持续改善这些东西，这就是我们通向胜利的路径。这些全部都是客户体验的投入要素。于是我们找到了衡量它们的方法，创建了一套投入指标（input metrics）。

S-Team 目标与投入指标

之后，当我们制定运营计划、每周复盘业务、设定目标时，我们高度聚焦于这些投入要素和投入指标。举个简单的例子，Jeff 和领导团队、S-Team 有一个工具叫 S-Team 目标（S-Team goals），本质上就是他们从所有运营计划中提取出的一份清单——“这是我从所有运营计划中汇总出来的公司最重要的目标。“我记不清具体是哪一年了，大概是 2007、2008 年左右，他们看了那份清单——顺便说一句，上面大约有 500 个条目——然后数了一下。在那份清单中，只有 10 个实际上包含了财务指标，比如营收、自由现金流或毛利。其余的，总体来说，全部都是那些投入要素，就像我刚才提到的低价、选品丰富度、客户体验的速度等等。

所以没错，关键就在于此——我们把这当作一条信念（article of faith）：只要我们能持续改善这些投入要素，产出自然会水到渠成。投入要素是驱动产出的因素——产出就是营收、客户活跃度、自由现金流。所以亚马逊的……这算不上什么秘密，但亚马逊最大的优势之一就是对那些投入要素的高度聚焦，对每一个都持续改进、持续优化，并严格衡量。

飞轮与如何找到好的投入指标

Lenny： 飞轮，你提醒了我。感觉这又是亚马逊向所有企业推广开来的一个概念——现在每家公司都在试图打造自己的小飞轮。我猜每个人脑海中都有那张亚马逊飞轮的图像：中间一个橙色小圆圈，周围一圈黑色箭头。回到投入指标的话题，简单说一下，什么是一个好的投入指标的例子？因为我猜听众中会有人说，“天哪，我也得把我的指标分成投入和产出了。“一个投入指标是好指标，有什么标志？

Bill Carr： 判断一个投入指标好不好，首先，梳理你的端到端客户体验。我从没在 Airbnb 工作过，但假设——第一步，客户在某个地方点了一个广告，进入了网站或应用。现在你在应用里了。你看到了第一个界面。好，用户做的第一件事就是浏览和/或搜索。我们如何衡量浏览和搜索的速度、质量和便捷程度？然后他们进入了某个房源的详情页。我们如何衡量他们可能采取的各种操作——比如预订——的速度、便捷度和质量。抱歉如果我术语用得不对，我不是 Airbnb 的——

Lenny： 你说得挺准的，差不多，没关系。

Bill Carr： 然后你完成了预订。接下来你要和房东进行沟通互动。我如何衡量这些互动的质量？来回发多少条消息？消息多是好事还是坏事？一开始你可能不知道答案。每一个步骤都是如此。然后是实际的入住体验。我如何对客户体验的每一个环节进行埋点和衡量？所以，如果一个指标是在衡量与客户体验相关的某个方面，那它就是一个投入指标。哪些指标是正确的，哪些与产出之间因果关系最强，我没法告诉你——这恰恰是你拿薪水要做的事情。你在 Airbnb 就是要搞清楚这个。基本上就是通过一个迭代的过程：衡量、观察、改善，然后看对产出有什么影响。

六西格玛与 DMAIC 方法

所以我们其实并没有发明这个概念。这个概念来自六西格玛（Six Sigma），使用的是 DMAIC 方法——即我有一个流程，这个流程有一个产出，但投入对我来说是一个黑箱。那么我如何理解这些投入？DMAIC 代表定义（Define）……哦，天哪。定义、衡量……A 等我一下想得起来。改善（Improve）和控制（Control）。我得……哦，天哪，A 想不起来了，我一时卡住了。但是——

Lenny： 哦，在这儿呢，我在看……定义、衡量、分析（Analyze）、改善——

Bill Carr： 分析。谢谢。对，分析，这不明摆着嘛。所以我们就是用了那个流程，这个流程是……顺便说一句，我们最初的思路是，“你需要往墙上多扔些东西看看。你并不真正知道这些东西里哪些因果关系最强。“所以你判断自己在做投入指标的依据是：你能控制它吗？也就是说，你能投入资源让这个东西变好或变差吗？它涉及客户吗？不一定非要涉及客户，但如果它在影响客户体验，那几乎肯定是投入要素。然后你打算如何衡量这个投入？你需要尝试不止一种方式，因为说到底，我们在书里讲了一个故事，关于我们最重要的一个投入指标——我们有多少选品——我们实际上有好几年都没有正确地衡量它，我们不得不反复打磨那个衡量方式。

关于产品失败的经验

Lenny： 我不知道你有没有看到，我在 Twitter 上问大家应该问你什么问题，也告诉大家你要来做客。有很多人提到的一个话题是：在使用逆向工作方法的情况下，亚马逊显然也推出过一些不成功的产品。比如 Fire Phone 就是一个经典的例子。你从那个过程中学到了什么——就是”好吧，这个做不下去”的时候？而且你也知道很多东西注定做不成，没有办法真正预先判断。

Bill Carr： 好。有一件重要的事情需要说明：这本书中描述的、亚马逊正在使用的所有这些工具——无论是用文档开会还是 PR/FAQ 流程或投入指标——它们中没有哪一个能直接给你答案。它们是帮助你做决策的工具。所以有时候你会做出错误的决策。Fire Phone 是一个经常被提起的好例子，人们会问：“既然你们有这么好的 PR/FAQ 流程，怎么还会做出 Fire Phone？“我算是 Fire Phone 团队的外围成员，跟他们密切合作过。不同的人有不同的看法，所以我只分享我自己的观点。大家可以想一想，PR/FAQ 流程是怎么运作的？首先会有一个客户问题。

那么 Fire Phone 要为客户解决的是什么问题？我认为这是一个我们犯了错误的案例——我们脑子里已经有了一个技术方案，就是 3D 效果。然后我们拿着这个方案去寻找一个问题。我不认为它解决了客户任何有意义的问题。坦率地说，我们不得不为这款手机开发音乐应用和 Prime Video 应用的版本，而我搞不清楚这个 3D 功能怎么能帮助客户更好地发现、观看或播放这些媒体内容。也许有些游戏可以利用这个做出很棒的体验，我不确定。但我认为，当你看到一个失败的产品时，最直接的切入点就是问自己：你解决了什么问题？我可以举很多亚马逊以外的例子，但十有八九，问题就出在这里……如果不是执行出了问题，如果产品的执行是正确的，那么产品概念本身出了什么问题？

Lenny： 我想象在那个同心圆评审过程中，应该有很多”反对但执行”的情况。你有没有发现——在这个 PR/FAQ 筛选过程中，反对和执行的次数本身能不能告诉你，也许这不是一个好主意？

Bill Carr： 不一定。我可以部分解释一下为什么 Fire Phone 会出现。在我看来，我认为我们之前已经有了几款成功的产品，而在某些情况下，有很多人曾怀疑它们是否行得通。亚马逊内部有很多人怀疑 Kindle 会是一个好主意。我记得关于这个话题的董事会会议争论很激烈。所以即使在一个被认为很有创新力的公司内部，也会有很多人对事物持怀疑态度。我可以告诉你，我在做 Prime Video 的那些年里，我会跟别人描述我们的愿景——你可以在电视上观看，我们会有自己的电影工作室，自己制作电影和电视剧。他们会笑话我，觉得那太疯狂了。所以这并不一定能作为产品是对还是错的信号。这其实也是一个问题，让你更难判断。

Lenny： 对。我觉得亚马逊非常擅长的一点就是能够接受大量的失败，我认为这也是为什么会有这么多创新的原因之一。是这样吗？

Bill Carr： 我说这只是一部分原因。我的意思是，我很难拿其他公司来做对比。但我可以告诉你，我们是否推出过很多失败的产品？是的。其中一些非常公开、显而易见。我给你举一个大家不太知道的例子。有一个功能……我们在 2000 年代初有一个叫 Slots 的功能。它的基本原理是第三方可以对不同的搜索词竞价，然后在那里放一个小广告。

Lenny： 听起来很熟悉。

Bill Carr： 嗯，显然，这个模式现在在亚马逊上行得通，但当时不行，因为亚马逊当时根本没有今天这样的规模。所以很多时候，一个产品想法本身完全没问题，只是时机不对，或者技术还没到位。Jeff 曾经写过一种产品——一个小圆盘，放在厨房里，你可以跟它说话、提要求，还可以用它购物。他在 2004 年就写到了这个概念。但当时的技术还造不出那个小圆盘，而这个小圆盘有一天会变成 Echo。那还需要十年的时间。但我们确实推出过很多失败的产品。我们不怕承担我们认为经过审慎计算的风险。我认为很多公司不太愿意这样做，对产品创新的投入不够，而且确实害怕失败，他们真正关注的是短期财务目标。这不是他们的错，上市公司和华尔街之间的互动方式造就了这种局面。

如何真正接受失败

Lenny： 我想就这个话题再多聊一点。感觉很多公司都在说”我们接受失败，我们不怕推出行不通的东西”，但在实际操作中，你的绩效评估会受影响，团队会被解散，预算会被砍掉。对于那些真正想在这方面改进的公司，你有什么建议？他们到底能改变什么，才能真正做好这件事？

Bill Carr： 好，前几天我正好跟一家知名硅谷公司的一位高管聊过这个话题，我说：“亚马逊在结构上，尤其是在人的层面，有什么东西能够鼓励或促使人们去承担这些风险？“因为确实，在很多公司，如果你去做的项目失败了，你的职业生涯就完蛋了，或者你的薪酬体系会让你拿不到那笔奖金。亚马逊有两点很重要。第一是我们的薪酬体系。我们没有绩效奖金。所以如果我负责图书业务，财务上业绩非常好，我也拿不到额外的奖励。如果我负责图书业务，那一年业绩不好，我也不会受到经济上的惩罚，因为我们的薪酬是基于股价的。

所以我们所有人的激励都是去做对公司长期来说正确的事情，因为试图从华尔街的短期波动中获利是一种必输的策略。因此，如果我……正因为有这种制度，我从负责我们最大的 P&L 转岗——从图书业务、音乐和视频业务，转去做数字媒体。那边完全没有业务。这可能做不成。但我的薪酬并没有因此改变，不会变多也不会变少。我们的绩效管理体系也倾向于更多从投入的角度来评估你实际交付了什么，然后据此调整薪酬。我们也关心产出，但确实有很多人可能——

有很多人可能身处一个蒸蒸日上的业务中，但这跟他们本人没什么关系。所以我们更专注于——你实际构建了什么、贡献了什么，你以哪些方式改善了选品或降低了价格，诸如此类的事情。所以薪酬体系中的这两点非常重要。第二件事是，要有一位真正对此充满 commitment 的 CEO，而且这不是他可以委派给别人去做的事情。

关于组织结构与创新

Safi Bahcall 我想在他的书 Loonshots 里写过这个观点，他提到创新发生所需的部分条件是，如果你要组建一个团队去构建新的创新事物，你必须实际创造不同的决策结构、审批结构和各种其他结构。因为大公司内部的大多数结构，设计的初衷就是压制和阻碍那些试图构建新东西的小型创新团队。他们需要速度，但这里要审批、那里要审批，这些都会成为他们的障碍。

我们用两种方式解决了这个问题。第一，当我们去构建数字媒体和 AWS 时，我们派了公司里两位最聪明的领导者来负责——Steve Kessel 和 Andy Jassy。第二，他们定期与 Jeff 开会。Jeff 深度参与其中，评审我们要构建什么，这也是决定我们去哪里构建什么的决策的一部分。因此，凭借他们的资历，再加上 Jeff 当然是 CEO，他们也能在这些事情上起到屏蔽干扰的作用。所以，即使你真心想要创新，即使你确实渴望创新，也愿意承担风险，但如果你没有以正确的方式组织起来，你就是无法得到创新。

Bar Raiser 招聘流程

Lenny： 太棒了。很高兴我们聊到了这个话题，我原本没打算谈这个，但很高兴我们谈了。最后一个话题，Bar Raiser 这个概念，它似乎是亚马逊能够成功扩展的一个核心机制，而且我觉得这是很多人可以落地实施的东西，它是一件你可以直接在自己公司推行的事情。你能不能谈谈 Bar Raiser 在招聘流程中到底是一个什么样的理念，以及如果有人想在自己的招聘流程中加入这个机制，可以怎么做？

Bill Carr： Bar Raiser 招聘流程是一种流程，它实际上是亚马逊最早建立和发布的流程之一，在公司历史相当早期的 1999 年就建立了。我们创建它的原因很简单，引用亚马逊一位高管的话来说，“我们让新人招新人，新人再招新人。” 当时我们正处于高速增长期。公司才不过三四年的历史，那时候我们已经像野草一样疯长了。

这个做法其实最初是从我们的技术团队开始的。我们技术团队的高管们意识到，天哪，我们招了一位新的工程负责人，接下来他的工作就是去招高级经理，然后高级经理再去招经理。这些人来公司才一个星期，他们甚至还不了解我们的公司，不了解我们的文化，不了解我们的标准。那么他们凭什么信息来做这些招聘决策呢？他们所依据的信息，显然只是他们自己的个人判断，而他们的个人判断结合的是他们在之前公司使用的任何标准。比如说，如果他们是从微软过来的，微软有什么方法论或标准，他们可能就直接照搬过来。

那么，那些方法论或标准适合我们公司吗？因为每家公司都有不同的文化，我在这里可以负责任地告诉你，如果有人在微软是一位非常成功的副总裁，并不意味着他在亚马逊、在 Google 或 Facebook 也能同样成功。有时候可以，但这些公司非常不同，它们的工作方式确实很不一样。领导力的运作方式和决策的方式都很不同。那么我们如何解决这个问题呢？总不能放任不管，招一堆我们不知道是否符合公司文化、也不知道是否达到我们对工程负责人或工程师所设高标准的员工吧？

所以他们创建了这个 Bar Raiser 流程，顺便说一下，这个流程是从微软借鉴来的，微软有一个叫 As Appropriate 的流程。其核心理念是，每一个面试循环中都有一个人，这个人不是招聘经理，不向招聘经理汇报，也不是招聘的 HR 人员，他们是业务线上的人，可能是软件开发经理，也可能是市场经理，他们参与面试循环，并且他们是 Bar Raiser。这意味着当我们进入 debrief 会议时，由他们来主持那个会议，不是招聘经理，不是 HR，由他们来主持会议。同时这也意味着他们在技术上对招聘经理拥有否决权。不过，一个好的 Bar Raiser 从来不会使用这个权力，至少我从未见过 Bar Raiser 使用它。我自己就是 Bar Raiser，在亚马逊的 15 年里我从未使用过，也从未见过有人使用。

最后一点——其实在 1999 年时还不是这样，后来才变成这样——就是我们一旦确立了领导力准则（leadership principles），就创建了一套客观标准和一个面试方法论，会在每次面试中使用。客观标准就是我们的领导力准则（leadership principles），方法论则是行为面试法。

所以这位 Bar Raiser 基本上就是这个流程运作方式的主题专家，他们会主持 debrief，确保我们实际遵循了流程，确保大家在坚持客观标准，而不是说”我觉得我们不应该招这个人，因为怎么说呢，他看起来好像不太想来这里工作。“也许这是一个合理的理由，但它实际上不属于我们的客观标准。Bar Raiser 在那里的作用也是平衡每位招聘经理都有的紧迫感偏差，就是”我必须尽快填满这些岗位”，但与其让他们用下一个有体温的人来填补，不如确保他们招到的是真正符合我们标准、契合我们文化、并且也达到我们对职能卓越（functional excellence）所设标准的人。

Lenny： 真是一个很棒的流程。这方面我有两个问题，第一个是，招聘中的最终决策权在谁手里，是招聘经理吗？

Bill Carr： 是的。

Lenny： 那这个就只是 Bar Raiser 给出的建议？

Bill Carr： 对，这一点经常被误解。决策者是招聘经理，整个面试循环和 Bar Raiser 其实只是在那里帮助招聘经理做出正确的决策。当然，招聘经理有时候会觉得这实际上是一个官僚化的流程，是一群他需要说服的人，是他们横在他和招到这个人之间的障碍，这是一种很自然的感受。

但我总是给刚接触这个流程的经理们一个反馈：不不不，不应该这样想，你应该把这些看作是在帮助你的人。因为你在招聘流程中投入的时间可能看起来很多，但如果你招错了人，天哪，你要花在管理那个人上的时间会多得多，对团队的影响，对你自己的影响。所以在这里做出一个出色的决策很重要，他们是来帮你的。

所以是的，最终决策权在招聘经理手里。从技术上讲，Bar Raiser 可以阻止他们录用某个人的决定，但一个做得好的 Bar Raiser 会通过苏格拉底式的方法，引导招聘经理自己看到不应该录用这个人的原因，通过他们引导讨论的方式来实现。

Lenny： 那在选择 Bar Raiser 的时候，你对于应该选谁、多久让他们参与一次这些事情有什么建议吗？因为这也有可能变成一个巨大的时间黑洞。

Bill Carr： 这确实非常耗时，有时候我作为 Bar Raiser 每周要花多达 10 个小时。选拔流程是这样的：作为一家公司，我建议如果你想实施这个机制，先选一个部门来试点。挑选那些 A、非常关心招聘流程的人，B、看起来擅长面试的人，C、似乎有高标准的人。这个角色也非常适合职业生涯早期的人，通过这个额外的领导力机会来培养他们。顺便说一下，这也是培养领导者的一种很好的方式，因为这项额外的责任让他们可以开始锻炼领导力。你必须对他们进行适当的培训，并且要对这个流程保持投入，但我通常会先在一个小组内进行试点。

Lenny： 在进入我们非常令人期待的快问快答环节之前，最后一个问题。很多听众正在考虑实施其中一些做法，试图弄清楚如何真正落地。如果有人想朝着更具亚马逊风格的方向迈进，你认为这些要素和流程中哪一个通常影响最大？或者根据你的经验，是否有什么根本性的东西需要先改变，才能让这样的变革在公司里发生？

Bill Carr： 好问题。我想说的第一件事是要注意的一点是，很多时候我和公司谈论这些流程时，他们会说，这是否意味着我们需要变成亚马逊？我首先告诉他们的是，首先，即使我想，我也无法把你们变成亚马逊，因为你们有自己的文化。其次，不是的，目的不是让你试图变成亚马逊，而是审视这些流程和最佳实践，考虑将其中部分或全部采纳到你的组织中加以改进。每家达到一定规模的公司都有这些相同的流程，这不过是做这些事情的另一种方式而已。你应该为每一个流程建立可扩展、可重复的机制，从中选一个，这里提供了一种选择。

另一个建议是，这些变革中有许多相当深刻，真正需要一直到 CEO 层面的认同。如果你真的想改变产品开发的方式，或者真的想改变招聘的方式，那很可能需要 CEO 的认可，所以我建议在推进太快之前先争取到这一点。不过，其中一些东西可以在你自己的小团队里试点，比如你的一个小产品开发团队。如果你决定开始写 PR/FAQ，你自己大概就能决定这么做。但同样，尽量和你的领导层沟通一下。

还有一点我想告诉你们的是，对于任何这些流程，不管是我们在书中的还是任何书中的，实施一个新流程都不容易。如果你轻率地对待它，只是浅尝辄止地试一试，那很可能不会奏效。因为一开始会很困难，需要一定程度的投入才能真正渡过那个困难阶段，说”我真的 committed 要做好这件事”，而且你需要几个月的时间才能变得擅长。所以你必须有投入和纪律性才能坚持下来。任何人都可以做到这些事情，只是需要投入和纪律性。

Lenny： 在我们的对话中，我们基本上只是触及了很多这些话题的表面。如果人们想深入了解，显然有你们的书《逆向工作》，我们会在节目说明中附上链接。我知道你们也和公司合作来实施很多这些实践。你能谈谈你能帮助大家做什么，以及如果感兴趣的话如何联系你们吗？

Bill Carr： 当然，好的。Colin 和我写这本书的原因之一，是通过书籍将我们学到的东西大规模地传递给下一代商业领袖，但同时也因为我们有一腔热情，想一对一地直接和公司合作。所以我们是顾问、咨询师，随你怎么称呼，但不是传统意义上的那种——我们没有一个团队在为我们工作。我们每个人都是直接和聘请我们的公司合作。

一般来说，适合我们合作的公司的类型，首先必须达到一定的规模。那些还在寻找产品市场契合（product-market fit）阶段的公司，需要专注于找到产品市场契合，他们可能还不需要太关注如何建立可扩展、持久的流程。当然，即使你处于那个阶段，其中一些做法对你肯定也有帮助，但这些流程真正设计的目标是——我的公司现在变得复杂了，有多个产品线，年收入远超一亿美元，增长迅速，组织复杂。所以我们的客户大多数要么是大型、远超 C 轮的私营公司，要么是上市公司。在大多数情况下，是某位 C 级别领导者或 CEO 本人读了我们的书，认识到他们面临着和我们在亚马逊时遇到的很多相同的问题，并把这些视为有用的解决方案，希望我们帮助他们实施。

所以我们通常会先去了解他们目前的做事方式，做一个评估，因为要帮助人们从一个地方走到另一个地方，我们必须先了解他们现在在哪里。然后我们和 CEO 以及 C 级别领导者一起制定一个优先级清单——哪些事情最有用，你们遇到了哪些症状和问题，这些流程中可以找到哪些根因解决方案。然后我们对这些进行排序，制定一个在组织内部推进的计划来帮助他们实施。还有一个不同的地方是，我们非常深入实际工作，在公司各个层级参与，在做的时候我们会和团队一起出席会议，现场辅导和教学，确保流程得到正确的实施，达到他们期望的效果。

Lenny： 听起来很棒。如果人们想进一步了解，应该怎么联系你们？

Bill Carr： 最简单的方式是发邮件，我的邮箱是 bill@workingbackwards.com，Colin 的是 colin@workingbackwards.com。你也可以访问我们的网站 www.workingbackwards.com，上面有一些信息，还有联系表单，这些是最好的方式。

Lenny： 好。那么现在我们进入了非常令人期待的快问快答环节。我有六个问题，准备好了吗？

Bill Carr： 我试试。

Lenny： 有趣的是，我看了一下问题清单，很多都和使用亚马逊有关，这挺逗的。第一个问题是，你向别人推荐最多的两三本书是什么？

Bill Carr： 在管理领域的话，毫不意外地，《从优秀到卓越》。我会推荐 Drucker 的《管理》（Drucker on Management），或者 Drucker 的《卓有成效的管理者》（The Effective Executive）。另外还有一本不太一样的，我会推荐史蒂夫·乔布斯传记。我从未在苹果工作过，但看那段历程，很多事情的运作方式和我在亚马逊经历的并没有太大不同，所以这是一个很好的窗口，让你了解身处一家经历产品创新和高速增长的科技公司是什么感受。个人方面，最近最喜欢的书是 Neal Stephenson 的《Seveneves》，还有《莫斯科绅士》（A Gentleman in Moscow）。

Lenny： 太棒了。这些都能在亚马逊上买到吗？

Bill Carr： 可以。

Lenny： 另一个可能和亚马逊有关的问题是，你最近有没有最喜欢的电影或电视剧？可能在 Prime 上，也可能不在。

Bill Carr： 有，我最近最喜欢的电影是最新的《沙丘》，而且我迫不及待想看新的一部。

最近的影视和产品推荐

Lenny： 那个什么时候上映？我感觉已经等了很久了。

Bill Carr： 我记得应该是下个月上映。我以前知道这个，以前必须得知道这类问题的答案，但现在不需要了。不过我翘首以待下一部，我觉得上一部非常精彩。我甚至喜欢最初的那部 Dune 电影，所以在这方面我可能比较特别。还有我最近和妻子一起看了一部电视剧叫《A Spy Among Friends》，在 MGM+ 上播的。

Lenny： MGM+，我甚至都没听说过这个。

Bill Carr： 我之前也没听说过。

Lenny： 又多了一个要订阅的。

Bill Carr： 不过你基本上可以上 Prime Video，找到这部剧，然后通过它订阅 MGM+。

Lenny： 谢谢 Prime。你最近有没有发现一个特别喜欢的产品？也许是在亚马逊上买的，也许不是。

Bill Carr： 这个不是在亚马逊上买的，而且可能大多数人都不会理解这个，但我是一个狂热的骑行爱好者，今年我给自己的公路自行车换了新轮组，实际上我的公路车和砾石公路车都换了。是 Zipp 303 Firecrest 的最新款，这些轮组真的太棒了。它们轻便、结实，减震效果很好，公路车和砾石公路车都能用，非常棒的轮组。

Lenny： 哇，这可能是我们节目里出现过的最冷门最随机的产品了。最近我们还有人推荐了加湿器，所以我挺喜欢我们这里收集起来的产品组合。也许可以在亚马逊上建一个心愿单了。

Bill Carr： 不错。

最喜欢的面试问题

Lenny： 你有没有一个特别喜欢问的面试问题？

Bill Carr： 有的，其实很基础，就是”告诉我你最重要的职业成就”。我总是需要澄清一下，我的意思不是你获得了什么奖项或升了什么职，而是你构建了什么东西——某个产品、某个流程、某个组织之类的。然后一旦他们开始讲述这个例子，我就可以追问很多后续问题，我可以仅围绕这一个例子就填满整整一小时的面试，真正了解他们是如何……运用 STAR 方法，试图从情境到结果了解所有细节，以及他们在中间做了什么、影响了谁、如何影响的、做了哪些决策、遇到了什么障碍。如果我顺着这一条线一直拉下去，我能了解一个候选人的很多信息。

人生信条

Lenny： 下一个问题，你有没有一个最喜欢的人生信条，经常回想起来的、会和朋友们分享的、觉得很有用的？

Bill Carr： 在职业上，也包括在个人生活中，我经常回想起的一句话叫做”慢就是顺，顺就是快”。这句话据我所知最早来自海军陆战队的侦察狙击手，所以并不是要宣扬那种技艺，它的要点是——实际上我们在亚马逊也经常这样做——很多时候，为了真正快起来，你首先需要慢下来，非常清楚你在做什么、你要去哪里。大多数人把速度和速率混为一谈，两者之间的区别在于速率同时包含速度和方向，也就是说有一个明确的目的地。我见过很多人跑得非常非常快，但目的地并不清楚，他们并没有真正想好。所以，慢就是顺，顺就是快。

Lenny： 有一句类似的话我一直在想，就是”欲速则不达，慢才能快”。我一直以为是史蒂芬·柯维说的，但刚才你说话的时候我搜了一下，是一个叫 Peter Senge 的人在《第五项修炼》这本书里写的。

Bill Carr： 我也花了一段时间才领悟。我以前总想先快起来，而不是先慢下来，所以我会说我个人的很多成长和发展，都是从 Jeff 身上在亚马逊学到的很重要的一课。

使用亚马逊的小窍门

Lenny： 最后一个问题，不知道你有没有答案，关于使用亚马逊，你有没有什么专业小窍门可以建议？一些人们可能不知道的、能更好地利用 amazon.com 的方法？

Bill Carr： 抱歉，我没有什么秘密心得。没有什么比如说周一早上某个时间点价格会更低之类的，或者库存会更好的说法。不，我不知道有这种事。

Lenny： 我觉得这其实挺好的，因为它正是按照客户需要的方式构建的。

Bill Carr： 我想是的。不过在以前网速比较慢的时候，我可能会告诉你在非高峰时段去上，但现在这已经不是问题了。

Lenny： 如果这还是问题的话就太疯狂了。Bill，这次访谈完全达到了我的期望，非常感谢你能来。你已经分享了大家在网上可以找到你的方式，所以我就跳过那个问题了。最后的问题是，听众怎样才能帮到你？

Bill Carr： 我们一直在寻求反馈。你可以在亚马逊上为我们的书写评论，这可能是最好的方式。你可以填写联系我们表单或发电子邮件，告诉我们你觉得书中哪些内容最有用，或者你觉得缺了什么、想了解更多什么。如果我们以后要再写一本书或写更多内容，你希望我们写些什么？

Lenny： 太好了，反馈可以发到 bill@workingbackwards.com。去亚马逊和其他平台购买《逆向工作》这本书，访问 workingbackwards.com 了解更多。Bill，再次非常感谢你来参加节目。

Bill Carr： 非常感谢，Lenny，我很享受这次对话。

Lenny： 我也是，大家再见。

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

术语表

原文中文
A Gentleman in Moscow《莫斯科绅士》（A Gentleman in Moscow，Amor Towles 著小说）
Andy JassyAndy Jassy（保留原文，亚马逊高管，后任 CEO）
article of faith信念
As AppropriateAs Appropriate（保留原文，微软的面试流程名称）
Bar RaiserBar Raiser（保留原文，亚马逊招聘机制）
behavioral based interviewing行为面试法（behavioral based interviewing）
Bill CarrBill Carr（保留原文，Amazon 高管、《逆向工作》合著者）
Colin BreyerColin Breyer（保留原文，Bill Carr 的合著者）
compound metric复合指标（compound metric）
concentric circle review同心圆评审
countermeasures对策措施（countermeasures）
customer obsession客户至尚（customer obsession）
customer problem solution statement客户问题解决方案声明
DE ShawDE Shaw（保留原文，华尔街量化对冲基金）
debriefdebrief（保留原文，面试后的讨论会议）
disagree and commit”反对但执行”（disagree and commit）
DMAICDMAIC（定义、衡量、分析、改善、控制）
Dune《沙丘》（保留原文指代时可作 Dune）
EchoEcho（保留原文，亚马逊智能音箱产品）
Eric ResonEric Reson（保留原文，Lenny 播客嘉宾）
Ethan EvansEthan Evans（保留原文，节目介绍人）
Fifth Discipline《第五项修炼》（Peter Senge 著管理经典）
fitness function适应度函数（fitness function）
flywheel飞轮（flywheel）
functional excellence职能卓越（functional excellence）
GM modelGM 模式（GM model）
Good to Great《从优秀到卓越》（Jim Collins 著管理经典）
input metrics投入指标（input metrics）
JeffJeff（指 Jeff Bezos）
KindleKindle（保留原文，亚马逊电子阅读器）
leadership principles领导力准则（leadership principles）
LennyLenny（保留原文，播客主持人）
LoonshotsLoonshots（保留原文，Safi Bahcall 著书名）
MaveronMaveron（保留原文，早期风投公司）
monolithic code base单体代码库（monolithic code base）
Neal StephensonNeal Stephenson（保留原文，科幻小说作家）
OfferUpOfferUp（保留原文，公司名）
output metrics产出指标（output metrics）
P&LP&L（损益）
Peter Drucker彼得·德鲁克（管理学大师）
Peter SengePeter Senge（保留原文，《第五项修炼》作者）
PR/FAQ processPR/FAQ 流程
Prime VideoPrime Video（保留原文，亚马逊流媒体服务）
product-market fit产品市场契合（product-market fit）
program orientation项目制导向（program orientation）
project orientation项目导向（project orientation）
Rick DalzellRick Dalzell（保留原文，亚马逊前 C 级别工程负责人）
S-TeamS-Team（保留原文，亚马逊最高管理团队）
S-Team goalsS-Team 目标（S-Team goals）
Safi BahcallSafi Bahcall（保留原文，Loonshots 作者）
service-based architecture基于服务的架构（service-based architecture）
SevenevesSeveneves（保留原文，Neal Stephenson 著科幻小说）
single-threaded leader单线程负责人（single-threaded leader）
Six Sigma六西格玛（Six Sigma）
SlotsSlots（保留原文，亚马逊早期广告功能名称）
STAR methodSTAR 方法（情境、任务、行动、结果）
Stephen Covey史蒂芬·柯维（管理思想作家，《高效能人士的七个习惯》作者）
Steve KesselSteve Kessel（保留原文，Bill Carr 的上级管理者）
thinking vector思考方向（thinking vector）
two-pizza team两个披萨团队（two-pizza team）
Working Backwards《逆向工作》
Working Backwards PR/FAQ逆向工作 PR/FAQ
Zipp 303 FirecrestZipp 303 Firecrest（保留原文，自行车轮组品牌型号）

此文档由 AI 分片翻译（translate_long_document）