4 篇博文 含有标签「innovation」

Marty Cagan 的《启示录：如何打造用户喜爱的产品》(2017版) 是一本关于顶尖科技公司如何打造备受用户青睐的产品的杰作。它提炼了产品管理的最佳实践——从组建合适的团队、定义引人入胜的愿景，到通过快速实验发现正确的产品，再到维持强大的产品文化。Cagan 借鉴了亚马逊、谷歌、Facebook、奈飞、特斯拉等公司的案例，阐明了真正伟大的产品并非偶然；它们是授权团队以一种与传统组织截然不同的方式工作的结果。这份深度解读提供了对2017版《启示录》核心思想和要点的逐章分析。无论你是一位有抱负的产品经理还是一名科技专业人士，本文旨在用清晰、引人入胜的语言解释这些思想，并通过有用的框架和示例来说明关键概念。

第一部分：顶尖科技公司的经验​

第一部分通过审视顶尖科技公司的运作方式以及众多其他公司为何表现不佳，为全书提供了背景。它探讨了技术驱动型产品对企业意味着什么，创业公司、成长阶段公司和大型企业面临的不同挑战，以及产品工作中常见的陷阱。贯穿始终的主题是，像亚马逊或谷歌这样的公司从根本上以不同的方式进行产品开发——尽早解决风险，跨角色深度协作，并执着于解决正确的问题。而传统公司通常遵循一种“功能工厂”模式，这导致了大量的资源浪费和产品失败。

每个伟大产品背后​

每个成功产品的背后都有一个具备正确心态和技能的专注的产品团队。Cagan 强调，产品管理是一个全职的、关乎使命成败的角色——不是一份兼职或一个委员会的决定。伟大的产品不是偶然碰上的；它们源于由**“传教士”而非“雇佣兵”组成的团队。传教士是那些真正信奉产品愿景、对解决客户问题充满热情的人，而雇佣兵只是为了薪水工作。这本书本身主要为产品经理（PM）而写，强调了产品经理的领导力是伟大产品的关键**。开篇章节就定下了基调：世界级的产品来自那些被充分授权、深刻理解客户并能自由地创造性解决问题的团队。它邀请读者在自己的组织中采纳顶尖科技公司的技术和心态。

技术驱动的产品与服务​

在现代，几乎所有产品都在某种程度上是“技术驱动的”。本章解释说，成功的公司将技术作为其产品战略的核心，无论它们是在构建软件、物理设备还是服务。拥抱技术驱动的方法意味着持续改进、快速迭代，并常常伴随着新的商业模式。例如，特斯拉通过无线软件更新来改进已售出的汽车，亚马逊利用其云和数据来增强购物体验。核心思想是，技术使得产品能够扩展到数百万用户并频繁更新，这改变了我们管理产品的方式。公司需要超越一次性的项目发布，而是将产品视为一个不断演进的、以用户为中心的服务。在实践中，这意味着产品经理必须精通技术，并能与工程师舒适地合作，组织也必须投资于能够快速向客户交付价值的平台、自动化和工具。通过强调“技术驱动”的含义，Cagan 为读者理解为什么传统的产品流程（借鉴自非科技行业）在软件世界中常常失败做好了准备。

创业公司：实现产品与市场契合（Product/Market Fit）​

在早期创业公司，首要目标是找到产品与市场契合点（PMF）——即产品满足真实市场需求，并且客户愿意使用或购买它的那个点。在这个阶段，一切都关乎快速学习和迭代。通常，创始人之一会扮演产品经理的角色，直接引导要构建什么。创业团队非常小（通常只有几个工程师和一个跨职能团队），这意味着沟通紧密，变更易于实施。本章强调，创业公司必须专注于一个狭窄的目标，快速行动，并通过迭代找到与用户产生共鸣的产品。这里没有官僚作风或正式流程——全凭试错和基于客户反馈的直觉。Cagan 指出，创业公司初期通常拥有少于25名工程师，分为1-5个产品团队。每个人都身兼数职，但成功的公司会确保有人明确地指导产品决策（通常是创始人-PM）。核心要点是，实现产品与市场契合需要不懈地强调测试想法，抛弃那些行不通的，并专注于为可定义客户群体真正解决问题的功能。一旦找到契合点，创业公司才能考虑扩大规模——但在此之前不行。

成长阶段公司：成功扩展​

当一家公司超越了初创阶段（拥有数十到数百名工程师），它就进入了成长阶段，并面临新的挑战。扩展产品和组织会引入复杂性：更多的人员、更多的客户，以及通常更多的流程。Cagan 指出了成长阶段公司产品团队的常见抱怨：

• 团队开始忽视大局——单个团队可能看不到他们的工作如何与整体产品愿景相连。
• 不清楚每个团队的努力如何为顶层目标做贡献，这可能会损害积极性。
• 对于**“被授权”或“自主”**的真正含义感到困惑；人们可能听到这些词，但仍然觉得每个决定都需要获得批准。

此外，随着产品变得成功，销售和市场团队会推动那些帮助他们达成交易或进入新细分市场的功能，而这些功能未必总与产品战略一致。公司的内部技术（IT系统）可能会滞后并积累技术债，从而减缓开发速度。简而言之，扩展带来了失去创业公司赖以成功的敏捷性和清晰度的风险。本章强调了在成长过程中强有力地沟通愿景和战略的必要性。成功的成长阶段公司会维持一个每个人都理解的清晰产品愿景，投资于平台和技术卓越以避免被技术债拖累，并改进其流程以使团队在规模扩大后仍保持授权（而非被微观管理）。核心要点是：如果你不深思熟虑，成功可能会滋生混乱——你必须有意识地扩展文化、流程和团队结构，以保持高创新和高效率。

大型企业：持续的产品创新​

大型、成熟的企业（例如成立十年以上，拥有数百或数千名员工的公司）通常在持续创新方面举步维艰。Cagan 描述了大型公司的典型症状：

• 缺乏创新——团队不断地增强现有的摇钱树产品，但很少创造出大胆的新产品。
• 士气下降——员工觉得自己的工作意义不大，或者公司过于官僚，这会消磨热情。
• 交付速度减慢——由于流程复杂和协调开销，发布一个简单的功能可能需要数月之久。
• 可能没有明确的产品愿景来指导无数的项目，让团队感到没有方向。

通常，这些公司被困于保护旧的成功产品，而不是进行新的创新。Cagan 建议，为了重获创新优势，企业必须重启其产品文化。这意味着（即使在大型组织内）也要授权给小型产品团队，建立一个引人注目的愿景来团结团队，并鼓励一种像初创公司一样的实验心态。他强调，大型企业的持续产品创新需要领导层愿意颠覆自己的业务——例如，在竞争对手之前，从旧的商业模式转向新的商业模式。核心要点是，规模和成功会使公司陷入自满。为了保持创新，企业需要在所有层级培养一种产品心态：痴迷于客户，促进跨职能协作，并简化决策流程，以便新思想不会被层级制度扼杀。

产品失败的根源​

为什么在传统组织中，如此多的产品计划会失败或被浪费？Cagan 指出了一系列根本原因，其中大部分源于旧的“瀑布式”流程和以项目为中心的思维。以下是他指出的主要问题：

• 想法来源错误： 许多公司从远离实际用户的销售团队或高层利益相关者那里收集想法。这意味着项目始于功能请求或高管的一时兴起，而非真正的客户需求。
• 早期的商业案例基本上是猜测： 团队被迫在过早的阶段撰写详细的商业案例（估算收入、投资回报率等）——那时你根本不可能知道这些数字。这给人一种虚假的安全感，并常常用乐观的猜测来为坏主意辩护。
• 将功能路线图视为承诺： 组织创建的路线图充满了按季度或年度安排的功能。这些路线图很少承认两个事实——“半数到四分之三的想法行不通，而那些确实可行的想法通常需要数次迭代”。然而，团队却埋头构建清单上的所有内容，致力于交付日期而非成果。
• 产品管理沦为项目管理： 在这个有缺陷的模型中，产品经理的角色仅仅是跟踪他人下达的时间表和需求，而不是去发现客户真正需要什么。
• 设计和工程介入太晚： 设计师通常在需求定义后才被引入，所以他们只能做一些表面的用户体验调整。工程师被当作不应过早打扰的编码机器——这意味着那些本可以发明创造性技术解决方案或发现可行性问题的人，在为时已晚时才被咨询。这是个悲剧，因为如果从一开始就参与进来，工程师通常是创新的关键来源。
• 名义上的敏捷： 许多公司“做敏捷”（Scrum、冲刺等），但仅限于交付阶段。他们仍然预先决定了所有功能（瀑布式规划）。敏捷最终意味着开发人员在冲刺中交付预定义的待办事项——它不包括探索或学习。因此，它在执行上是敏捷的，但在决定构建什么上并非如此。
• 以项目为中心、注重产出的心态： 成功的衡量标准是按时按预算完成项目，而不是实现有意义的结果。团队庆祝产出（发布的功能），而不是成果（创造的客户价值）。
• 客户验证晚且少： 也许最大的缺陷是，与真实用户的任何测试都发生在最后阶段（如果 überhaupt 的话）。当客户看到产品时，团队已经完全投入其中，发现任何重大问题都为时已晚或修复成本高昂。通常产品会失败，而机会成本——所有本可以花在更好想法上的时间和金钱——是巨大的。

总而言之，大多数失败的产品都遵循一个共同的模式：一个从想法到发布的流程，没有真正的验证，没有迭代，也没有对团队的真正授权。一切都是自上而下决定，并以线性路径执行。Cagan 敦促彻底摆脱这种模式。相反，团队应该采用一种产品方法，即他们迭代想法，尽早测试假设，并以成果而非产出来衡量成功。认识到这些根本原因很重要，因为它解释了为什么这本书推动一种不同的工作方式（顶尖科技公司的方式）。它为下一章的原则奠定了基础。

超越精益与敏捷​

许多组织已经尝试采用敏捷方法或精益创业思想，但仍然没有看到像亚马逊或谷歌那样的成功。Cagan 解释说，最好的产品团队确实利用了精益和敏捷，但使他们与众不同的是超越基本方法论的三个核心原则：

1. 预先处理风险： 强大的团队不会立即开始编写详细的规格或代码，而是首先解决任何产品创意的四个主要风险——价值风险（客户会想要它吗？）、可用性风险（用户能弄清楚如何使用它吗？）、可行性风险（我们有时间和技术来构建它吗？），以及商业可行性风险（这个解决方案对我们的业务是否有效——法律、市场、财务等方面？）。他们在投入开发之前，先完成艰难的学习过程。在实践中，这意味着尽早使用原型、客户访谈和其他实验来验证一个想法是否值得构建，并在各个方面都可行。
2. 协作、持续的设计——而非顺序的孤岛： 在顶尖公司，产品、设计和工程从一开始就协同工作。他们不会互相扔文档。设计师和工程师从定义解决方案阶段就参与其中，与产品经理实时迭代。这种协作能产生更好的解决方案（因为考虑了所有视角），并避免了后期出现大的意外。相比之下，不太成功的团队通常在需求确定后才让设计介入，在设计完成后才让工程师介入——这是平庸产品的配方。
3. 专注于解决问题，而非实现功能： 强大的团队不是通过交付了多少功能来衡量成功，而是将成功定义为解决了一个客户或业务问题。他们拥抱一种以成果为导向的心态。例如，他们不会说“在第四季度前构建功能X”，而是将其表述为“通过解决流失问题，将成功结账率提高20%”。这将团队的注意力转移到考虑任何能够实现结果的解决方案上，而不仅仅是最初设想的那一个。正如 Cagan 所说，伟大的团队关心结果，而不仅仅是产出。他们庆祝的是问题被解决或关键绩效指标（KPI）得到提升，而不是功能发布。

这三个原则基本上总结了顶尖公司如何将精益和敏捷融入更宏大的产品战略中。他们仍然使用快速迭代和以用户为中心的测试（精益创业风格），并以增量方式交付（敏捷），但他们是以一种面向使命、跨职能的方式来做的。本章强调，仅仅采用敏捷流程是不够的——真正起作用的是采纳这些降低风险、协作和注重成果的心态。能够做到这一点的公司，才能持续创新，避免构建客户不想要的东西。

关键概念​

在深入探讨战术之前，Cagan 定义了现代产品管理的一些基本概念：

• 整体性产品 (Holistic Product)： 当我们谈论“产品”时，它不仅仅指软件功能。一个真正的产品包含功能性、底层技术、用户体验设计、盈利模式，以及如何获取和支持用户。换句话说，一个伟大的产品不仅仅是一个巧妙的应用程序；它还拥有吸引人的用户体验、可扩展的技术、可行的商业模式和获取用户的策略。这种广阔的视角对产品经理至关重要——忽略任何一部分（例如，忽略用户体验或盈利模式）都可能导致产品失败，即使核心功能很好。
• 双轨制：探索与交付 (Dual Tracks: Discovery and Delivery)： 每个产品团队都从事两项基本活动：- 产品探索 (Product Discovery)——弄清楚要构建什么。在探索阶段，团队致力于区分好点子和坏点子，通常通过头脑风暴、原型制作和测试假设来实现。探索的产出是一个经过验证的产品待办事项列表（backlog）——即团队有信心认为有价值、可用、可行且商业上可行的功能/故事集。- 产品交付 (Product Delivery)——实际构建、发布和维护生产环境中的产品。交付将想法转化为客户可以使用的生产质量的软件，具备应有的完善度、可扩展性和可靠性。 在高效团队中，这两条轨道持续并行地进行（这通常被称为双轨敏捷）。探索是为了快速学习，而交付是为了执行并将那些经过验证的想法推向市场。Cagan 强调两者都是持续的——你不会只做一次探索阶段然后就停止思考；即使在交付过程中，你也会不断发现新的增强功能。
• 四大关键风险 (The Four Critical Risks)： 探索的一个主要部分是为任何提议的产品或功能回答四个问题：- 价值 (Value) – 用户会购买或选择使用它吗？（它是否解决了他们关心的真实问题？）- 可用性 (Usability) – 用户能弄清楚如何使用它吗？（如果人们无法使用或理解，解决方案就没有价值。）- 可行性 (Feasibility) – 我们的工程师能用我们现有的时间、技能和技术来构建它吗？- 商业可行性 (Business Viability) – 这个解决方案对我们的业务是否有效？（例如，是否符合我们的品牌，法律是否能批准，是否支持我们的销售和收入模式）。 这些通常被称为四大产品风险，伟大的团队会在承诺构建产品之前解决所有这四个风险。如果其中任何一个的答案是“否”，那么这个想法就需要重新考虑或放弃。通过早期（通过原型和利益相关者反馈）验证价值、可用性、可行性和商业可行性，团队可以避免日后代价高昂的失败。一个简单的记忆方法是：做正确的事（价值/可用性）并把事情做对（可行/可行）。
• 原型优于文档 (Prototypes over Documents)： 为了快速测试想法，产品团队使用原型——轻量级、通常是可抛弃的产品版本——而不是大型需求文档或完全构建的功能。原型可以是草图、可点击的设计或一小段代码，任何能回答当前问题的形式都可以。伟大的产品团队每周使用原型测试10-20个想法。这种高通量的实验使他们与那些可能在会议室里辩论想法却从未与用户尝试的慢速团队区分开来。事实上，Cagan 调侃说，对于探索来说，MVP 这个缩写应该代表**“最小可行原型 (minimum viable prototype)”**，而不是产品。其理念是尽可能快速、廉价地学习。
• 产品与市场契合 (Product/Market Fit)： 这个概念通常与创业公司相关，被定义为你已经构建了能够成功满足特定市场需求的最小可能产品的那个点。Cagan 提醒我们，达到产品与市场契合是一个重要的里程碑——这意味着你已经找到了一个客户喜爱到足以维持业务的产品。在 PMF 之前的一切都是实验；之后的一切都是扩展。让团队专注于实现 PMF（而不是被那些“锦上添花”的功能或过于宽泛的市场分心）是至关重要的。
• 产品愿景 (Product Vision)： 产品愿景是你产品的长期（2-10年） aspirational 目标。它描述了你试图创造的未来世界或你旨在解决的重大问题，并且应该与公司的使命保持一致。一个强有力的愿景能激励团队，并为产品的演进提供连贯性。例如，亚马逊早期的产品愿景是成为“地球上最大的书店”，这指导了多年的工作。愿景很重要，因为它在你经历许多短期迭代和实验时提供了连续性。

总而言之，这个“关键概念”章节为读者提供了将在整本书中使用的词汇和心智模型。它断言，成为一个优秀的产品团队意味着对你的产品进行整体思考，持续并行地进行探索和交付，并系统地降低想法的风险。有了这些概念，本书的其余部分将深入探讨如何在实践中做到这些。

第二部分：对的人​

伟大的产品由伟大的团队打造。Cagan 接下来的章节专注于人——使产品成功的角色、技能和团队结构。一个反复出现的主题是，产品开发是一项团队运动：你需要在正确的环境中拥有正确的参与者（产品经理、设计师、工程师等）。正如 Cagan 所说，这“完全关乎产品团队”。在这一部分，他剖析了强大产品团队的关键原则，详细说明了核心角色的职责，并讨论了领导层应如何组织和赋权这些团队。

强大产品团队的原则​

强大的产品团队共享某些核心原则和特征：

• 他们是跨职能且持久的。一个典型的产品团队包括一名产品经理、一名产品设计师（UX）和2-10名工程师，他们会长期合作。由于是跨职能的，团队拥有发现和交付解决方案所需的所有技能，无需频繁交接。由于是长期的（而不是为每个项目重新组合），他们培养了深厚的专业知识和信任，这带来了更好的协作和创新。
• 他们的行为像**“传教士，而非雇佣兵”**。这个著名的理念（归功于一位风险投资家，并由 Cagan 引用）意味着每个团队成员都受到对愿景和客户问题的热情驱动，而不仅仅是完成任务。传教士会主动思考，创造性地解决问题，并坚持不懈；雇佣兵只做他们被告知的事情。Cagan 认为，传教士团队的表现始终优于雇佣兵团队，因为他们更关心、更深入地思考成功。
• 他们是被授权且负责任的。一个好的产品团队被赋予一个明确的目标（例如，将留存率提高X%），但不被微观管理如何实现它。他们有自主权决定要做哪些功能或改变。伴随这种自主权而来的是责任——团队对结果负责。他们对产品的成果负责，而不仅仅是交付任务。这种主人翁意识对于激励和质量至关重要。
• 他们偏好同地协作和紧密合作。虽然远程团队也能成功，但 Cagan 指出，“在所有其他条件相同的情况下，一个同地协作的团队将显著优于一个分散的团队”。物理上的接近（或至少非常紧密的沟通）有助于建立关系，并实现难以通过文档或电子邮件复制的快速、丰富的协作。这关乎流动的沟通——随时拉上一位设计师进行头脑风暴，或者工程师自发地在白板讨论中插话。也就是说，即使是分布式的团队，强大的团队也会通过文化和工具找到模拟这种亲密性的方法。
• 他们力求目标明确。每个成员都应该理解他们工作背后的为什么——客户的痛点、业务目标、产品愿景。这个共同的目标使团队保持一致，并让他们能够独立地做出正确的微观决策。它也激发了那种传教士般的热情。
• 他们注重结果而非产出（呼应了早前的原则）。一个强大的团队不会在他们完成一个功能的编码时庆祝；他们会在客户行为向好改变时庆祝。这让他们保持诚实——如果一个发布没有产生效果，他们会将其视为一次学习，而不是宣布胜利。好的团队是数据驱动和成果驱动的。

Cagan 认为，以这种方式组建团队不仅仅是感觉良好的哲学；它有实际的原因。他给出了三个理由说明为什么这样构建的团队会表现出色：（1）关系促进协作——互相信任的人沟通更好，更自由地分享想法。（2）专业知识来自稳定——一个持久的团队在共同工作中获得领域知识和技能，这会随着时间的推移带来创新。（3）主人翁精神孕育责任感——当一个团队感到完全的主人翁精神时，他们会主动推动业务成果，而不是仅仅听从命令。简而言之，如何构建和赋权团队是一个基础性选择，它可能成就或毁掉你的产品努力。

产品经理​

产品经理（PM）通常被称为产品的“迷你CEO”，但 Cagan 澄清说，这并非关乎层级——而是关乎责任。产品经理对产品的成功负责。这意味着他们的工作是确保构建出来的东西能为客户和业务带来价值。以下是《启示录》中关于产品经理角色的要点：

• 决定构建什么： 产品经理是确定优先级和选择想法的关键人物。他们综合来自用户、数据和利益相关者的输入，但最终帮助团队决定：“在我们可以做的100件事中，我们接下来要做这1-3件事。”他们以最大化成果为愿景，维护着产品待办事项列表。
• 深厚的知识领域： 一个优秀的产品经理需要在四个领域拥有极其渊博的知识：1. 客户 (The Customer) – 你必须了解目标用户的问题、痛点、愿望，以及他们实际如何使用产品。这包括定性理解（他们的动机、工作流程）和定量理解（使用指标、用户分群）。2. 数据 (The Data) – 产品经理应该对分析感到自在。他们需要知道关键指标是什么，如何检索和解释关于产品使用、转化率等的数据，以告知决策。3. 业务 (The Business) – 这意味着了解你公司的商业模式，如何赚钱，行业格局，以及公司战略。产品经理处于产品和业务的交汇点，所以他们必须确保产品支持业务目标（例如，它如何推动收入或客户忠诚度？）。4. 行业与市场 (The Industry and Market) – 产品经理应该了解市场趋势、竞争对手的产品，以及可能影响产品的新兴技术。这种外部意识有助于塑造战略并保持领先。 Cagan 经常总结说，产品经理是团队的“知识经纪人”：他们将关于客户、数据、业务和行业的知识带到桌面上，以便团队做出好的决策。
• 关键特质： 除了知识，最好的产品经理还表现出某些个人特质。Cagan 强调聪明、有创造力、执着是三个核心品质。
  • 聪明 不仅仅指书本上的聪明；它意味着能够快速学习新领域，分析性地思考问题，并做出合理的决定。它还意味着某种敏锐——比如识别出别人错过的模式或洞察。
  • 有创造力 意味着产品经理能够跳出“只添加功能”的框框思考。他们能为问题提出新颖的解决方案，并对以不明显的方式迭代想法持开放态度。产品创新通常需要挑战假设，而一个有创造力的产品经理有助于促进这一点。
  • 执着 意味着在面对障碍时坚持不懈。产品不可避免地会遇到挫折——技术障碍、失败的用户测试、内部阻力。一个优秀的产品经理有毅力建设性地继续前进，鼓舞团队，调整方向，而不是放弃。通常，即使别人怀疑，也需要产品经理来捍卫产品。
• 非朝九晚五的工作： Cagan 直言不讳地指出，产品管理不是一个典型的办公桌工作，你不能按时打卡上下班。这是一个由热情驱动的角色，可能会占据一个人的思绪。产品经理经常会做得更多——在奇怪的时间与客户交谈，在周末处理故障，或者不断观察市场。这并不意味着不健康的过度工作，而是意味着真正的产品经理非常在乎，因此投入了大量的自己。如果有人想要一个严格的作息和低责任感的工作，产品经理可能不是合适的角色。

本质上，产品经理是产品团队的粘合剂。他们不编码，也可能不设计用户界面，但他们确保所有部分都能结合在一起，解决正确的问题。他们对成果负责，因此必须通过影响力来领导——统一团队，说服利益相关者，并用证据和洞察力来驱动决策。Cagan 甚至指出，由于这项工作的范围和难度，产品经理理想上应该是公司中最有才华的人之一。这是一个为那些既能与工程师讨论技术细节，又能向高管展示商业案例的领导者准备的角色。最终，产品经理的北极星是产品在市场上的成功——他们所做的一切都应该追溯到这一点。

产品设计师​

产品设计师（通常是用户体验或交互设计师）是用户的拥护者。Cagan 强调，一个优秀的产品设计师的责任远不止是让屏幕看起来漂亮——他们设计整个用户体验，并从一开始就与产品经理和工程师紧密合作。要点：

• 整体用户体验： 设计师考虑的是整个客户旅程，而不仅仅是单个功能。这包括用户如何首次了解产品、入门流程、日常互动，甚至用户变得更熟练或他们与产品的关系发展时体验如何变化。这可能涉及的考虑因素包括：我们发送什么样的电子邮件或通知？客户支持如何与产品集成？用户第一次登录时，空状态是什么样的？Cagan 指出，设计师会考虑每一个接触点，甚至包括市场营销和销售材料，以确保一致和积极的体验。
• 在探索中的角色： 产品设计师是产品探索的核心参与者。他们以产品的成功来衡量，而不仅仅是设计的美感。这意味着他们与产品经理一起制作想法的原型，并持续参与用户测试。他们经常主导可用性测试会话，即时绘制新的解决方案草图，并根据真实的用户反馈迭代设计。在一个强大的团队中，设计师不是接受命令的艺术部门；他们是与产品经理一起探索正确产品是什么的创造性问题解决者。
• 设计职责： Cagan 列出了设计师的几个关键职责：
  1. 交互设计 (UX) – 打造产品的行为方式，信息如何组织，并使其对用户实现目标直观易用。
  2. 视觉设计 – 美学：布局、颜色、字体以及使产品吸引人并与品牌保持一致的整体外观。
  3. 原型制作 – 构建原型（从纸质草图到高保真交互式模型）以快速测试想法。设计师通常会创建多个原型来探索不同的方法。
  4. 持续用户测试 – 不断与用户验证设计。好的设计师不是每季度等待一次大型可用性实验室测试，而是每周都会把东西放到用户面前，即使是非正式的，以收集反馈。
  5. 整体性思维 – 确保用户体验在产品的每个部分甚至产品之外都是一致的。例如，设计师可能会考虑用户注册后收到的电子邮件——其语气和设计是否与应用内体验一致？（Cagan 明确提到电子邮件、市场营销、销售流程是整体用户体验的一部分。）
• 战略合作伙伴： 产品设计师是产品经理的战略合作伙伴，而不仅仅是服务提供者。如果他们看到用户需求没有得到满足，他们应该挑战产品方向，同样地，产品经理也应该让他们参与问题定义。在伟大的团队中，产品经理和设计师几乎像产品的联合创始人一样运作，各自带来不同的专业知识。
• 设计的重要性： Cagan 直截了当地说，在许多方面**“用户体验比工程更难、更关键”**。这很有挑衅性，但其要点是，如果用户体验是错误的，世界上最优雅的代码也无法拯救产品。用户看不到代码；他们看到的是界面，感受到的是体验。好的设计可以使复杂的技术易于接近，而糟糕的设计可以毁掉一个辉煌的技术成就。因此，投资于一流的产品设计人才并给予他们发言权是创造客户喜爱的产品的关键。

总而言之，产品设计师的角色是确保产品对客户来说是可用的、有用的，甚至是令人愉悦的。他们弥合了用户需求和产品功能之间的差距。通过在探索的早期和整个开发过程中让设计师参与进来，团队大大提高了为用户以正确的方式构建正确东西的机会。一句能抓住这一点的话是：“好的产品设计师会思考客户随着时间的推整个旅程……” 包括如何引导新用户和保持长期用户的参与度。那种整体的、共情的思维是他们带给团队的。

工程师​

工程师（开发人员、程序员——那些编写代码的人）是产品的创造者。Cagan 在《启示录》中对工程师的论述强调了他们的角色远不止是编写代码。在强大的产品团队中，工程师是探索和创新的关键贡献者，而不仅仅是执行者：

• 构建产品： 首先，工程师负责高质量地实现产品的功能。他们设计系统架构，编写干净的代码，修复错误，并确保产品平稳运行、扩展和表现良好。他们将原型和想法转化为可以交付给客户的真实、可用的产品。这是他们工作的显而易见的部分，但 Cagan 敦促这并非唯一的部分。
• 在探索中的技术洞察： 工程师通常最了解技术上什么是可能的。当早期参与时，他们可以提出产品经理或设计师可能不知道的创造性解决方案。例如，一个工程师可能会说：“我们其实已经收集了数据X，所以我们可以相当容易地个性化这个功能”，或者相反，“那个想法真的很难，但这里有一个使用不同技术的替代方法。”通过参与构思，工程师有助于评估可行性，甚至可以通过提出由技术赋能的创新解决方案来影响方向。
• 可行性与原型验证： 在探索期间，工程师可以编写快速的“验证（spike）”原型或进行研究，以降低可行性问题的风险（例如，在数据集上测试新算法，或查看第三方API是否能满足需求）。这类似于可行性原型的概念，即“刚好足够的代码来降低技术未知数的风险”。让工程师尽早这样做，可以确保团队不会承诺他们无法构建的东西。
• 持续协作： 在最好的团队中，工程师不会等到一个完全完善的设计或规格才开始贡献。他们参与关于权衡（“如果我们简化这个工作流程，我们可以在2周内交付，而不是2个月”）和用户影响（“这个功能可能会减慢应用；我们如何为用户保持其快速？”）的讨论。他们与设计师合作，找到伟大用户体验和技术上合理的实现的交集。
• 主人翁精神与质量： 工程师为产品的性能、安全性和可维护性感到自豪。他们倡导必要的技术工作（如重构或构建内部工具），这些工作最终会通过可靠性或速度带来更好的用户体验。Cagan 指出，许多团队在关注质量方面比关注速度做得更好，这意味着工程师通常自然地专注于把事情做好——但需要与产品经理/设计师合作，以快速地做正确的事情。
• 工程师数量： 一个产品团队通常有2-12名工程师（通常约3-8人是一个最佳点）。如果人数更多，通常会分成多个团队。这样的规模确保团队足够大，拥有多样化的技能，但又足够小，可以有效沟通。工程师通常占团队的大多数，所以他们的文化和态度显著地塑造了团队的产出。

值得强调的是 Cagan 的观点，即工程师通常是产品团队中创新的最佳单一来源。这是因为他们深刻理解技术的能力，并常常能看到利用技术的新方法。例如，一个工程师可能会意识到为某个功能开发的技术可以催生一个全新的产品想法。像谷歌这样的公司，以允许工程师花一部分时间在实验性想法上而闻名（这催生了Gmail和其他产品）。对于产品经理和领导者来说，其要点是将工程师视为创造性的合作伙伴，而不仅仅是执行者。

总而言之，在一个被授权的产品团队中，工程师贡献于产品应该是什么（通过评估可行性和提出想法），然后擅长于高质量地交付它。他们确保产品能够实际构建并在规模上运作。而且因为他们参与了探索，团队中有了共同的理解——工程师知道功能背后的背景和原因，这有助于他们在编码中做出更符合用户意图的细微决策。这是一个良性循环：被授权的工程师感到主人翁精神，这带来了更好的产品。Cagan 的建议很明确：在产品流程中尽早并经常地让工程师参与进来，因为他们的贡献将大大提高产品成功的机会。

产品营销经理​

产品营销经理（PMM）将产品与市场连接起来。在《启示录》中，Cagan 指出，这个角色通常不是核心产品团队的专职全职成员，尤其是在小公司或早期阶段，但他们的工作对于产品的定位和发布至关重要。关于 PMM 的要点：

• 市场定义与信息传递： 产品营销负责了解目标受众并打造产品的营销信息——基本上，就是弄清楚产品是为谁服务的以及如何传达其价值。他们研究客户细分，研究竞争对手，并确定描述产品的最佳方式，使其产生共鸣。这可能包括为功能命名，制定价值主张，以及为不同渠道或客户画像量身定制信息。
• 上市（Go-to-Market, GTM）策略： PMM 通常推动新产品或功能的发布计划。这包括决定定价、包装、销售培训、广告、公关、活动和内容营销。他们确保当产品准备就绪时，合适的用户能够听到它，并理解他们为什么应该关心。一个伟大的产品如果营销不佳也可能失败，所以这个角色的作用就是弥合这一差距。
• 确保商业可行性： Cagan 在 PMM 的背景下提到了“商业可行性”。这意味着 PMM 帮助确保产品在商业上是可行的——例如，定价是否有利可图，销售团队是否有他们销售所需的工具，以及它是否符合公司的品牌和分销渠道。他们可能会运行测试版程序或从市场收集反馈以完善产品。
• 并非总是嵌入团队： 在许多科技公司，一个产品营销经理可能会支持多个产品团队。他们可能在市场部门工作，而不是在研发部门。因此，产品经理（推动产品探索/开发）和产品营销经理（推动产品发布/市场采纳）之间的沟通至关重要。在理想情况下，PMM 会足够早地参与进来，为产品团队提供市场背景，并在发布前很早就开始准备营销计划。
• 讲故事与宣传： PMM 常常充当产品对外的声音。他们可能会制作演示视频，撰写博客文章，用关键谈话要点培训销售队伍，或在会议上发言。他们的角色在很大程度上是以引人入胜的方式讲述产品的故事，以便客户感到兴奋并理解它如何帮助他们。

简而言之，产品经理确保产品解决了一个真实的问题，而产品营销经理则确保世界知道这个解决方案并感知到它的价值。Cagan 暗示，在强大的产品组织中，产品经理和产品营销经理紧密合作，将产品功能与面向客户的利益对齐。PMM 可以被看作是客户理解的倡导者：“我们如何确保人们理解为什么这个东西很棒？”他们还向团队反馈客户和市场的洞察（例如，什么信息传递能产生共鸣，或者竞争对手的说法是什么），这可以影响产品策略。

值得注意的是，PMM 通常不是开发团队的核心成员，但他们围绕其运作。可以说，他们处于产品战略和市场执行的交汇点。产品的成功发布和采纳是他们成功的衡量标准。因此，尽管这本书专注于构建正确的产品，但它承认通过有效的营销将该产品与客户连接起来，是使产品受人喜爱的一部分。

支持性角色​

除了产品经理、设计师和工程师这个核心三人组之外，许多公司还有专家来支持产品团队。Cagan 简要描述了几个支持性角色，指出他们通常不是全职专属于一个团队，而是根据需要提供专业知识。关键的支持性角色包括：

• 用户研究员 (User Researchers)： 他们是研究用户行为和偏好的专家。他们进行深入访谈、可用性测试、调查和人种学研究。他们的目标是帮助产品团队尽可能多地从用户那里学习——通常会发现用户自己可能没有明确表达的需求或痛点。在实践中，用户研究员可能会组织一次可用性测试，系统地观察人们如何使用原型，然后分析结果。他们也可能进行实地研究（例如，在客户的实际环境中拜访他们，观察他们今天如何执行一项任务）。Cagan 说，研究员*“帮助团队从用户测试中学到最多”*。他们为收集用户反馈的过程带来了严谨性和客观性，确保团队不仅仅听到他们想听到的。
• 数据分析师 (或数据科学家)： 这些团队成员专门分析产品数据——使用日志、A/B 测试结果、收入指标等。他们可以设置仪表板，对问题进行深入分析（例如，“哪些功能与更高的留存率相关？”），并帮助运行实验。虽然产品经理也应该精通数据，但数据分析师带来了更高级的统计技能，并且可以投入时间以一个忙碌的产品经理或工程师可能做不到的方式来剖析数据。他们的分析可以揭示增长机会或问题（比如某个漏斗的转化率下降），从而为产品决策提供信息。从本质上讲，他们帮助团队更加以证据为驱动。
• 测试自动化工程师 (Test Automation Engineers)： 质量至关重要，这些工程师专注于构建自动化测试和工具，以确保产品在规模扩大时能够正常工作并保持工作状态。他们创建一套测试（单元测试、集成测试、端到端测试），每当代码更改时就会运行，从而及早发现错误。他们也可能开发用于模拟用户操作的框架。通过自动化重复性测试，他们解放了开发团队，使其能够在不牺牲稳定性的情况下更快地行动。Cagan 将他们列为支持性角色，以强调质量不是事后考虑——它是一项持续的投资。特别是在持续交付的环境中，拥有强大的测试自动化是让你能够快速、自信地部署变更的关键。

这些支持性角色通常为多个产品团队服务。例如，一家公司可能有3名用户研究员，他们根据不同研究的需要轮流服务于10个产品团队。或者一个中央数据团队处理分析请求。关键是协作：核心产品三人组应该在适当的时候主动邀请这些专家（比如计划一次主要的可用性研究或分析测试版的结果）。Cagan 提到这些角色“不是全职专职成员”，这表明他们也不应该被孤立——他们可能向一个中央小组（如用户体验研究部或质量保证部）汇报，但在与团队合作时必须紧密集成。

在实践中，一个强大的产品团队会利用这些专家来增强其能力。他们请用户研究员验证棘手的可用性问题或获取无偏见的反馈。他们依赖数据分析师来处理数字，以便团队可以专注于解读和决策。他们与测试自动化专家协调，以保持代码库的健康。通过这样做，团队可以保持高节奏的交付和学习，并有信心他们不会在用户理解或产品质量方面积累盲点。

领导层的角色​

产品领导层（如总监、副总裁或产品/设计/工程负责人）在创造一个能让产品团队茁壮成长的环境中扮演着至关重要的角色。Cagan 概述了产品组织中领导层的主要职责：

• 招聘、培养和留住优秀人才： 领导者的首要任务是建立强大的团队。这意味着要花大量时间招聘合适的人才（聪明、充满热情并符合授权文化的人）。这也意味着要指导和培养现有的团队成员——给予反馈，支持他们的成长，并确保他们有职业发展路径。当然，还有留住他们——这通常取决于提供一个引人注目的使命和一个支持性的环境。如果你在每个角色上都有一流的人才，你的产品成功几率会大大提高。领导者无法微观管理每一个决定，所以他们的影响力来自于他们安排在各个角色上的人才的素质。
• 设定整体产品愿景： 随着组织的发展，领导者必须保持对产品组合的整体视角。单个团队可能各自负责一部分（例如，每个功能区一个团队），但领导层要确保所有部分都能协同工作，朝着一个连贯的愿景和用户体验发展。他们还不断地沟通和完善产品愿景和战略，以便每个团队都明白他们的工作如何做出贡献（解决在成长阶段公司章节中提到的宏观问题）。如果一个公司缺乏统一的愿景，团队可能会偏离方向或产生冲突，所以领导层需要提供这种一致性。
• 创造文化和环境： 领导者塑造产品文化——团队是真正被授权还是口头上的？他们是重视从失败中学习还是惩罚失败？领导层必须示范和执行创新产品文化的价值观（第五部分将详细介绍）。他们应该鼓励实验，坚持以成果为导向的路线图，并打破部门间的壁垒。例如，一个伟大的领导者会保护团队免受过多官僚主义或干预，而是促进跨职能的信任。
• 支持和挑战团队： 领导层应该清除障碍（例如，解决资源冲突，争取必要的预算），并不断挑战团队追求更高的目标。Cagan 暗示，好的领导者会问一些恰当的难题（“我们怎么知道这能解决问题？有没有更快的方法来测试这个？”）而不会指定解决方案。他们确保责任制——即团队真正地提升了指标，而不仅仅满足于产出——同时仍然给予团队自主权来找出如何做。

总结领导层角色的一种方式是：领导者致力于 构建 系统（团队、结构、文化），而不是在系统中 工作。他们的重点是建立一个能够自己创造出伟大产品的组织。例如，一个产品负责人不应该在写用户故事或设计模型；他们应该确保他们拥有优秀的PM和设计师来做好这些事，并且这些PM和设计师有明确的使命和正确的背景。

Cagan 指出，随着公司的发展，领导层必须保持这种整体视角，因为单个团队自然会专注于他们自己的部分。领导者需要确保，例如，学习成果在团队间共享，冗余的工作被最小化，以及战略优先级是明确的。此外，当一个公司从一个阶段过渡到另一个阶段（从创业到成长，从成长到大型企业），领导层通常需要推动结构或流程的改变来支持这一点。

本质上，强大的产品领导者是产品愿景和团队质量的推动者和守护者。他们雇佣优秀的人才，用鼓舞人心的方向使他们保持一致，然后放手让他们去做——只在高层次上进行指导、支持或纠正方向。这为书中所有原则（如被授权的团队、快速探索等）的实际蓬勃发展奠定了基础。

产品负责人的角色​

Cagan 特别关注产品负责人（有时称为首席产品官或产品副总裁）——负责产品管理组织的人。这个角色通常向CEO汇报，在产品驱动型公司中至关重要。以下是《启示录》中关于产品负责人的要点：

• 顶尖产品人才和团队建设者： 产品负责人的首要职责是建立和培养一支强大的产品经理团队（如果设计也向他们汇报，通常也包括产品设计师）。他们需要招聘优秀的产品经理，保持高人才标准，然后指导他们成为各自产品领域的战略领导者。这意味着要创建产品经理的职业阶梯，进行定期的1对1辅导，提供培训，并确保每位产品经理在关键能力（客户理解、分析等）上得到成长。产品负责人还应确保每个产品团队都有合适的产品经理，并对不达标的PM进行重新分配或移除，因为一个薄弱的PM可能会拖累整个团队。从本质上讲，产品负责人扮演着产品管理团队教练的角色。Cagan 说，一个强大的产品组织是强大的产品负责人直接作用的结果，他不妥协于人才标准，并不断提升他的PM们。
• 产品愿景和战略领导： 产品负责人通常要么制定，要么共同拥有公司的产品愿景和战略（特别是如果CEO不是一个产品远见者）。如果CEO是主要远见者（像史蒂夫·乔布斯那样），产品负责人则将该愿景转化为可操作的战略和计划。如果CEO更偏向于业务/财务，产品负责人可能就是那个为产品设定方向的人。无论哪种情况，他们都要确保有一个清晰且鼓舞人心的产品愿景，以及一个与业务目标一致的、重点突出的战略。他们可能会领导年度产品愿景更新或重大的战略举措（例如，决定用新产品进入新市场）。Cagan 指出，这只是工作的一部分，如果CEO还没有在做——在一些公司，CEO本人就是产品远见者，产品负责人则在其指导下执行（比如在较小的创业公司或创始人领导的公司）。但通常在规模化时，产品负责人必须为公司制定和阐明产品战略（这涉及综合PM、设计、工程以及市场趋势的输入）。
• 执行与结果监督： 产品负责人对整体产品执行负责——确保产品团队实际交付的解决方案对业务和客户都有效。这并不意味着微观管理每个项目，而是要对进展有可见性，并在出现严重问题时介入（例如，如果一个关键目标屡次未达成，产品负责人可能会调整资源或寻找额外帮助）。他们建立产品规划系统（如季度OKR），并审查结果，以确保每个团队的成果都与公司目标一致。他们经常与CEO进行产品审查，总结产品计划的进展情况。如果某个产品领域表现不佳，产品负责人有责任采取行动——这可能是更换PM或团队负责人，重新聚焦战略，或争取更多时间/资源等。从本质上讲，他们确保（思想和工作的）列车准时并朝着正确的方向行驶。
• 产品文化与跨职能协调： 产品负责人在建立强大的产品文化方面发挥着关键作用（如第五部分所述）。他们设定了PM和团队遵循的规范：例如，“我们首先与客户验证”，“我们庆祝成果而不仅仅是发布”，“工程师和设计师有平等的发言权”等。他们还处理高层次的跨职能关系——例如，与销售、市场、客户支持等负责人协调，以确保产品团队与这些职能部门和谐工作（例如，协商销售反馈如何传达给PM，或如何协调市场发布）。如果产品团队与其他部门之间存在冲突，产品负责人通常会与该部门的同行合作解决，或在必要时向CEO升级。产品负责人还在高管团队中倡导产品思维——向同事们介绍产品流程，倡导必要的研发投资，抵制不切实际的要求（“我们不能在下个月前承诺那个功能而不牺牲质量——让我们找一个替代方案”）。所以，产品负责人的一部分角色是为良好的产品实践进行内部宣传，并维护一个有利于团队成功的环境。

简而言之，产品负责人应该体现《启示录》的原则并加以推广。他们确保产品组织有高标准（人才和愿景），并且团队以授权和责任感运作。他们将公司战略转化为产品战略，反之亦然（将产品学习成果反馈以告知业务战略）。Marty Cagan 希望这个角色的人能够深刻“理解”现代产品开发，并能保护和培养团队做出他们最好的工作。

技术负责人的角色​

技术负责人（通常是CTO或工程副总裁）是领导层的对应角色，专注于工程组织和技术能力。Cagan 与产品负责人并行地概述了该角色的职责，强调了强大的技术领导力对于实现伟大产品是多么关键。要点：

• 组织与人员： 技术负责人的首要任务是建立和构建工程团队，以满足公司的需求。这意味着要招聘顶尖的工程人才，确保团队拥有高级和初级开发人员的适当组合，并使工程团队结构与产品战略保持一致（类似于产品团队结构原则）。他们还应专注于培养工程领导者（技术主管、工程经理）以扩大组织规模。从本质上讲，人员和组织是第一位的：将合适的工程师安排在合适的角色上，并设定合适的团队边界（例如，平台团队与功能团队等）。一个结构良好的工程组织可以更快地执行并更具创新性。
• 技术战略与愿景： 技术负责人设定技术方向——选择能够支持当前和未来产品需求的关键平台、工具和架构方法。他们需要将技术与产品愿景对齐：例如，如果战略是支持企业客户，技术负责人要确保基础设施满足安全和可扩展性要求；如果产品愿景涉及AI，技术负责人可能会投资于机器学习专业知识和平台。他们通常维护一个技术路线图（基础设施升级、技术债偿还、新能力开发），以补充产品路线图。例如，技术负责人可能会推动一项重构或模块化计划，以便团队可以更自由地进行实验——这是为产品敏捷性服务的技术战略。他们还应关注新兴技术（云、框架等），这些技术可能为产品带来竞争优势，并决定是否/何时采用它们。
• 交付与质量（执行）： 技术负责人对软件的可靠交付负责——确保工程团队以健康的节奏交付高质量的产品增量。这包括建立强大的工程实践（持续集成/部署、自动化测试、代码审查标准）。当涉及到交付时间表和高完整性承诺（例如，与业务事件相关的必须达到的日期）时，技术负责人需要介入并确保工程能够满足，或者在无法满足时协商权衡。如果一个工程团队遇到困难（持续的生产错误、延误），技术负责人会通过提供支持或重组来解决。从本质上讲，他们确保产品可以按时以良好质量交付——不是通过强加不切实际的最后期限，而是通过培养一种卓越和高效的工程文化。
• 架构与技术基础设施： 这个角色还拥有产品的架构——确保其可扩展、模块化、安全等，以支持产品演进。一个好的技术负责人会推动一个与产品愿景相匹配的架构（例如，如果需要快速实验，确保有一个微服务或功能标志架构来支持）。他们还管理重大的技术投资，如迁移到云、采用新数据库等，平衡短期需求与长期平台健康。他们必须明智地处理技术债——不忽视它（这会减慢未来的速度），但也不过度追求完美。他们的工作是通过随时间推移消除技术限制来拓宽产品的技术可能性——这意味着，他们投资于新的技术能力（如如果产品愿景需要，则实现实时分析）并不断改进平台，使其不会成为瓶颈。
• 探索与创新参与： 重要的是，Cagan 将确保工程师（特别是高级工程师）参与产品探索作为技术负责人的责任。这意味着技术领导者应该鼓励并分配时间让工程师参与原型制作、用户研究、黑客马拉松等。他们可能会制定一项政策或文化，即工程师花N%的时间在探索工作或黑客项目上（像谷歌著名的20%时间概念，尽管那更多是个人创新，但技术负责人可以倡导这样的想法）。CTO对探索的支持至关重要——如果技术负责人只关心编码功能，而不关心工程师参与用户访谈，那么工程经理可能会不鼓励他们的团队花时间在探索上。所以技术负责人必须明确地重视这一点（例如，赞扬那些提出一个原型，从而使团队免于构建错误功能的工程师）。通过这样做，他们将工程嵌入到产品创新过程中，而不仅仅是执行。
• 内部技术宣传： 技术负责人常常在高管团队中扮演**“工程声音”**的角色，有时也在外部（在会议上等）扮演这一角色。在内部，他们宣传技术可以为业务做什么（例如，“如果我们投资于一个AI平台，我们可以解锁哪些新的产品能力”），并确保公司战略理解技术影响（“那个新的商业模式将需要X个月的平台工作——这就是原因以及它还将带来什么好处”）。在外部，他们可能会谈论公司的技术创新，以帮助招聘和定位为技术领导者（例如，发布工程博客文章，开源一些工具）。

总而言之，技术负责人确保工程组织和技术栈是产品成功的强大推动者，而非限制因素。他们招聘优秀的工程师，选择正确的技术，保持质量和速度，并与产品领导层合作，以快速、可靠地创新。他们消除技术障碍，拓展可能性，正如摘要所说。如果产品负责人关注的是做正确的事，那么技术负责人关注的是把事情做对（有时还通过技术拓展了可以做的正确事情的范围）。

交付经理的角色​

交付经理（DM）——在敏捷环境中，有时被称为项目经理、Scrum Master 或工程项目经理——是一个专注于团队流程和执行效率的角色。Cagan 提到这个角色是为了澄清，虽然产品团队是跨职能和被授权的，但许多团队仍然受益于有一个专门负责理顺开发流程和消除障碍的人。

关于交付经理角色的要点：

• 促进敏捷流程： 交付经理的工作是确保团队选择的开发流程（例如，Scrum、Kanban）运行顺畅。他们安排和主持仪式（站会、冲刺规划、回顾会议），跟踪任务燃尽图或流程，并总的来说确保团队以协调的方式工作。如果团队使用Scrum，这基本上就是Scrum Master的角色：不是老板，而是流程的仆人式领导者。他们执行敏捷最佳实践和纪律（例如，确保团队在一个冲刺中不会承诺超出他们能力范围的工作，或者确保回顾会议举行并且回顾会议的行动项得到跟进）。他们帮助维持一个可持续的节奏。
• 消除障碍（项目管理）： 交付经理主动识别并消除可能减慢团队速度的障碍。例如，如果团队正在等待另一个小组的法律批准，交付经理可能会去催促或升级。如果两名工程师因同时管理一些运营任务而超负荷，交付经理可以与运营团队协调，接手这些任务。他们还处理外部依赖关系——也许团队需要在某个日期前从另一个小组获得一个API；交付经理与该小组的产品经理/交付经理沟通以确保一致。从本质上讲，他们通过处理协调和外部问题，让核心团队可以专注于构建产品。Cagan 明确指出交付经理的职责是“消除障碍”。
• 项目透明度与沟通： 交付经理常常让利益相关者了解进展情况（这样产品经理就可以专注于产品决策，而不是详细的甘特图或状态报告）。他们可能会维护一个项目仪表板或每周发送关于已完成和下一步工作的更新。在一些组织中，他们协调多个团队（如果一个大功能需要团队A和团队B的工作，交付经理或一个总交付经理会同步计划，以便所有内容都能按时集成）。因此，他们确保没有意外——如果可能出现延误，交付经理会及早提出，并与产品经理和团队一起研究缓解措施（重新确定范围的优先级等）。
• 保护团队： 一个好的交付经理还充当团队的缓冲或盾牌。例如，如果高层或其他部门不断地提出临时请求或旁支项目，交付经理可以帮助过滤这些——与产品经理核实它们是否符合优先级，否则礼貌地推迟它们。如果团队被拉入太多会议或上下文切换，交付经理可能会介入以简化沟通（也许他们代表团队参加一些会议以收集信息，而不是拉入所有工程师）。他们保护团队的时间，以便他们能够保持生产力。
• 流程改进： 交付经理促进团队工作方式的持续改进。在回顾会议中，他们主持讨论哪些方面可以改进，并帮助实施这些变革。例如，如果团队发现早期的需求不清楚，交付经理可能会建议为每个故事增加一个简短的启动会议，与产品经理/设计师/QA一起澄清。或者如果部署一直存在问题，交付经理可能会协调一个“修复管道”的迷你项目。他们总是在调整团队合作的机制，以实现更高的速度和质量。

Cagan 提到“通常是 Scrum Master”，这表明在敏捷团队中，这个职能是被认可的，但它不一定是一个产品角色——它更像是一个工程/运营角色。它可能向工程管理层或项目管理办公室（PMO）汇报。重要的是，《启示录》并没有过多地美化或讨论项目管理层；相反，Cagan 警告不要将产品经理变回项目经理。但他承认，有一个人关注交付机制可能是有用的，特别是当团队和依赖关系增长时。

总而言之，交付经理就像团队的流程教练和流程管家。他们让列车准时运行，清除轨道上的障碍，并确保团队能够专注于产品问题而不是行政问题。这个角色虽然不直接参与产品决策，但通过确保团队有健康的开发节奏和最小的将想法变为现实的摩擦，间接地支持了产品的成功。

构建产品团队的原则​

公司应该如何组织其产品团队？Cagan 提供了一套原则，而不是一个“一刀切”的组织结构图。目标是以最大化自主性、一致性和有效性的方式来构建团队。关键原则包括：

1. 将团队结构与产品/组合投资策略对齐： 团队的划分方式应反映公司选择投资产品领域的方式。例如，如果一家公司有两条主要产品线，那么它很可能应该为每条产品线设立独立的团队（或团队组），而不是让一个团队跨越两者。如果某个领域更关键（比如80%的收入来自它），你可能会在该领域安排更多的团队或人员。从本质上讲，把你的员工放在你的战略所在之处。
2. 最小化团队间的依赖关系： 每个产品团队理想上都应该是自主的——能够以最少的交接或需要其他团队批准的情况下设计、编码和发布价值。依赖关系会减慢速度并削弱责任感。为了最小化依赖关系，应按功能/领域而非层次来构建团队。例如，不要有一个“前端团队”和一个“后端团队”，而是有一个跨职能团队，端到端地拥有一个完整的功能。
3. 明确的所有权和自主权： 每个团队都应该有一个明确定义的责任领域（一个功能、一个用户旅程、一个微型产品等），并被授权在该领域内做出决策。当团队的职责重叠或不明确时，就会出现差距和冲突。自主权意味着他们可以在其领域内运行探索、做出路线图选择（在战略范围内），并在没有大量协调的情况下部署变更。
4. 最大化杠杆作用（但要谨慎）： 这指的是在能带来显著好处时，在团队间共享能力。例如，一个构建通用工具的“共享平台团队”可以增加杠杆作用，避免每个团队都重新发明轮子。然而，共享团队必须谨慎使用：每次你集中化某样东西，你都会创造一个潜在的瓶颈，并减少单个团队的自主权。
5. 遵循产品愿景和战略： 随着产品的演进，团队结构也会演变。如果产品愿景指向新的领域，你最终可能会为这些领域创建新的团队。Cagan 建议至少每年重新审视一次团队结构——它是一个移动的目标。
6. 最佳团队规模： 他提到3-12人是一个产品团队规模的指导方针。少于3人几乎不算一个团队，超过10-12人则沟通起来会变得笨拙。
7. 与架构对齐（架构又应与产品愿景对齐）： 软件架构和团队边界应该相对应。如果系统是作为微服务构建的，团队通常会围绕这些服务或其集群组织起来。这种对齐减少了跨团队的技术工作。
8. 与用户或客户对齐： 理想情况下，每个团队专注于某一类型的用户或特定的客户旅程。例如，一个团队可能拥有市场中的“卖家体验”，另一个拥有“买家体验”。这种以用户为中心的结构有助于团队深入共情他们的用户并为他们创新。
9. 与业务领域或单元对齐： 在某些情况下，特别是在大公司，产品团队会映射到业务单元或产品线。与业务单元对齐有助于问责制（每个单元的损益表都与一个团队的产出挂钩）。
10. 随时间演变结构： Cagan 强调团队结构不是永久的。随着公司和产品的变化，重组团队是健康的（至少每年一次或当战略转变时）。像亚马逊这样的公司就经常这样做；这可以防止停滞，并确保资源跟着机会走。

这些原则指导领导者创建一个组织，其中每个团队都可以快速行动（拥有自主权和最小的依赖关系）并保持一致（围绕明确的产品领域和战略构建）。

重要的一点是，组织设计是提高产品吞吐量和创新的工具。一个糟糕的结构可能会让进展陷入停滞。一个好的结构则能让团队专注于他们的目标。Cagan 的观点鼓励不断地问：“我们的团队结构对于我们试图实现的目标是否有意义？如果没有，就改变它。”形式应服务于功能——塑造团队以最好地交付你的战略所要求的成果。

第三部分：对的产品​

拥有合适的团队（对的人）和深刻理解工作方法（对的流程，稍后介绍）之后，下一个关键要素是构建对的产品——也就是说，决定要构建什么，以便它能为客户带来真正的价值并实现业务目标。第三部分专注于产品战略和规划：从高层愿景到具体的、以成果为导向的计划，并用更有效的技术取代传统的功能路线图。

产品路线图的问题​

传统的产品路线图在许多组织中都是标配：一个按时间规划的功能或项目列表。Cagan 认为，以功能为中心的路线图存在根本性问题，并常常导致资源浪费和机会错失。他指出的关键问题包括：

• 产出 vs 成果： 路线图列出的是产出（Q1的功能A，Q2的功能B），并常常将成功等同于按时交付这些产出。它们通常不传达正在解决的问题或预期的成果。结果，团队专注于完成功能，而不是确保这些功能达到目标。Cagan 称之为*“以项目为中心”*的思维，并将其确定为产品失败的根源。
• 确定性的幻觉 / 没有探索空间： 一个固定的路线图假设我们预先知道这些特定功能是正确的，并且可以按预期交付。实际上，至少有一半的想法可能行不通或需要重大修改。但路线图不允许这种学习——它让团队一个接一个地致力于功能，几乎没有空间根据反馈进行调整。
• 将日期视为承诺： 一旦功能和日期出现在路线图上，这些日期在利益相关者心中就成了最后期限。这导致了一种环境，即按时完成可能比把功能做好或测试其是否真正需要更重要。团队可能会为了赶上Q4的承诺而仓促实施，推出一个半成品或未经证实的东西。
• 鼓励“功能工厂”和孤岛行为： 当成功以交付路线图上的功能来衡量时，团队可能会采取工厂心态——只是生产功能，然后扔给下一个环节。这不利于创新，因为创新通常需要迭代和从实际使用中学习。
• 不传达“为什么”： 路线图常常未能传达背景——为什么每个功能被优先考虑或它支持什么目标。这不仅让团队缺乏动力，也阻碍了创造性解决方案的产生。
• 难以拒绝 / 过度承诺： 一旦某样东西上了路线图，产品经理就很难拒绝增加更多的请求。这可能导致路线图过满，时间表不切实际，以及团队士气低落。
• 忽略学习与探索： 也许最大的问题是：一个静态的路线图不包含学习。如果Q1的实验显示用户不需要计划在Q3的功能B，一个死守路线图的公司可能仍然会在Q3构建B，因为“它在计划上”。

Cagan 并不是说不要计划；他是说要以不同的方式计划（剧透：围绕成果和目标，他将在后面介绍）。他承认领导层需要知道团队正在做最重要的事情——但功能路线图是完成这项工作的错误工具。

总而言之，专注于功能和日期的路线图鼓励一种按计划构建的心态，而不是解决问题的心态。它们使得调整方向变得困难，不能以目标激励团队，并导致交付大量价值可疑的功能，同时可能错失真正的机会。

路线图的替代方案​

Cagan 提倡一种替代方法，既能提供清晰度又没有传统路线图的缺点。该替代方案的精髓是围绕成果和战略背景进行规划，而不是固定的功能集。其关键要素包括：

• 定义成果（目标），而非功能列表： 领导层应该传达需要实现的业务和客户成果，而不是要构建的功能列表。例如，不说“Q3构建一个新的入门教程”，而说“到Q3将新用户7天留存率从20%提高到40%”——然后让团队去想办法。Cagan 称之为**“基于成果的路线图”**。
• 提供战略背景——愿景与主题： 除了目标，领导层还应分享产品愿景和战略主题来指导团队的工作。例如，一个主题可能是“使产品更自助化以支持规模化”。这用宏观方向取代了功能路线图的微观细节。
• 路线图的两个有效用途： Cagan 承认，规划在两个方面是必要的：成果的优先级排序（确保团队首先处理最重要的问题）和跟踪外部承诺。所以替代方案仍然涉及对目标的优先级排序。并且，如果有特定的日期承诺（如法规遵从日期），这些仍然可以在时间轴上跟踪。但他建议最小化最后期限——只在真正必要时使用。
• 基于成果的路线图格式： 可以想象一个简单的表格：季度 / 成果（目标） / 指标（关键结果） / 负责团队。例如：
  • Q1：提高入门转化率（从20%到35%）– Alpha团队。
  • Q2：将基础设施成本降低10% – 平台团队。
  • 这传达了领导层希望发生什么，而不是具体怎么做。
• 赋权团队并允许灵活性： 一旦确定了成果并分配了团队，领导层就退后一步，让团队通过探索找出解决方案和时间表细节。
• 高完整性承诺仍然存在，但时间点更晚： Cagan 引入了**“高完整性承诺”**——即团队只有在有了证据和信心后才做出的最后期限或承诺。换句话说，你在晚期做出承诺，当你有了证据表明你的解决方案很可能会满足需求并且你了解其实施范围时。
• 通过背景而非功能列表实现业务对齐： 他还指出，这种规划方式为利益相关者提供了他们真正需要的东西：确保团队正在从事高价值的工作，并且这些工作与业务成果挂钩。

从本质上讲，功能路线图的替代方案体现在像**OKR（目标与关键结果）**这样的技术中，Cagan 明确推荐了这种技术。第三部分的其余部分（关于愿景、原则、战略和OKR的章节）提供了实施这种方法所需的工具。

产品愿景与产品策略​

Cagan 区分了产品愿景和产品策略，这两个高层概念指导着你的组织中“对的产品”意味着什么：

• 产品愿景是你产品的长期、鼓舞人心的目标——你希望实现的未来状态，通常是2年、5年甚至10年之后。它是对“我们试图为客户创造一个什么样的世界？”的回答。一个好的愿景是鼓舞人心的、清晰的，并且与公司的使命一致。例如，亚马逊早期的产品愿景是“在60秒内提供任何语言的、任何已印刷的书籍”。它是具体的、以用户为中心的、雄心勃勃的。愿景是北极星——它指引方向，但本身不是一个计划。
• 产品策略是你选择实现愿景的路径。它关乎专注——选择首先服务哪个目标市场或画像，首先解决哪个问题或强调哪个差异化因素，以及按什么顺序进行。好的策略承认约束（你不能一次做所有事情），并与业务战略保持一致。Cagan 说，策略确保团队在创新时有专注点和边界。关键要素包括：
  • 目标市场或细分市场： 策略明确了首先为谁服务。
  • 价值主张与差异化： 策略概述了你的产品将如何取胜。
  • 业务对齐： 策略必须与商业模式和上市策略相适应。
  • 一系列赌注的顺序： 策略通常包含一个大致的顺序，指导产品的演进。
  • 适应性： 愿景相对稳定，而策略可以根据学习情况演变。

简单来说，如果愿景是“我们最终想去哪里”，那么策略就是“我们将走哪条路以及如何行进”。Cagan 指出，许多公司要么缺乏清晰的愿景，要么缺乏连贯的策略。他认为两者都不可或缺：愿景激励人心；策略指引方向。

产品愿景的原则​

Cagan 列举了制定和使用强大产品愿景的原则：

1. 从“为什么”开始（使命）： 一个伟大的愿景清晰地与一个更大的目的相连。
2. 爱上问题，而非解决方案： 愿景应专注于你打算解决的客户问题或需求，而不是特定的解决方案。
3. 敢于大胆思考（颠覆自己）： 愿景应该是雄心勃勃的——它甚至可能威胁到你当前的业务方式。
4. 必须鼓舞人心： 愿景必须激励团队，并且应该是简短、难忘、富有感染力的。
5. 拥抱并预见趋势（滑向冰球将要去的地方）： 一个强大的愿景应考虑到产品将要生存的未来背景。
6. 对愿景执着，对细节灵活： 一旦你设定了一个引人注目的愿景，就把它当作你的北极星，但在如何实现它上保持开放。
7. 愿景是一种信念的飞跃： Cagan 指出，如果你今天就能完全验证这个愿景，那它就不够雄心勃勃。
8. 持续宣传： 产品愿景必须由领导者和产品经理反复沟通，使其深入人心。

这些原则有助于打造一个以问题为中心、雄心勃勃、鼓舞人心、紧跟趋势并具有指导性的愿景。

产品策略的原则​

对于产品策略，Cagan 概述了确保策略有效和一致的原则：

1. 一次只专注于一个目标市场/画像： 成功的产品通常始于深入地攻克一个目标市场或画像，即使它们可以服务于许多市场。
2. 与业务战略对齐： 确保产品策略支持公司的整体业务战略。
3. 与销售和上市策略对齐： 产品策略应考虑销售渠道和营销策略。
4. 痴迷于客户，而非竞争对手： Cagan 建议，虽然你必须了解竞争对手，但不要让他们决定你的策略。应专注于更好地理解和服务你的客户。
5. 在整个组织中清晰地传达策略： 一旦确定了愿景和策略，领导者必须广泛而反复地进行沟通。

总而言之，这些原则确保产品策略是专注的、一致的、以客户为驱动的，并且被充分理解的。

产品原则​

Cagan 提到产品原则是进一步指导产品决策、使其与愿景和战略保持一致的工具。产品原则本质上是描述公司/团队旨在创造何种产品体验以及避免何种体验的信条或价值观。它们通过提供日常决策的准则来补充愿景/策略。要点：

• 定义： 产品原则是产品应遵守的高层标准或口号。例如，“简单 > 强大”意味着在权衡时，宁愿选择为用户提供简单性，而不是以复杂性为代价增加功能。
• 为何要有： 原则帮助团队做出一致的决策，这些决策与产品的特性和愿景保持一致，而无需总是向上级寻求批准。它们充当产品设计和功能辩论的北极星。
• 示例： 一些常见的公司产品原则：
  • “别让我思考”（用于用户体验——一切都应直观）。
  • “性能也是一个功能”（快速响应时间至关重要）。
  • “一个产品，一种体验”（跨平台的一致性）。
  • “用小细节取悦用户”（可能用于消费类应用）。
• 实践中的使用： 在辩论一个功能或设计时，团队可以参考原则。例如，“我们的原则是‘尽可能少的点击’，所以这个需要5个步骤的流程与此相冲突——我们如何缩短它？”
• 与公司价值观的区别： 它们与公司价值观相关，但更具体于产品决策。

总而言之，产品原则就像设计和开发选择的北极星。它们不断提醒你在你的产品中哪些品质是不可协商的。

第四部分：对的流程​

第一至三部分确立了我们所需要的（优秀的团队、明智的产品愿景/策略、对成果的关注）。第四部分深入探讨了在实践中如何实际探索和构建产品——即强大产品团队用来持续创新和交付的流程。这关乎产品探索技巧、验证方法和工作流程，旨在最小化风险并最大化速度和学习。

产品探索的原则​

Cagan 概述了关于产品探索的核心原则或真理——在探索构建什么时应遵循的规则：

1. 客户（和利益相关者）无法告诉你他们想要什么： 一个基本原则：你不能简单地向客户或高管询问解决方案然后构建它。 探索不是接受命令——它是深入理解问题然后测试解决方案。
2. 最重要的是建立真正的价值： 价值风险是探索中首先要解决的问题。 如果产品创意不能带来价值，其他一切都无关紧要。
3. 用户体验通常更难（也更关键）： Cagan 断言使产品易于使用和愉悦通常比使其在技术上可行更棘手，而且这绝对至关重要。
4. 功能、设计和技术是相互交织的——要协同工作： 一个早前提到的原则——整体地对待产品开发。探索应该涉及三方协作。
5. 大多数想法行不通；可行的想法通常需要迭代： 接受失败是正常的——预计你的许多初步想法或实验不会产生积极结果。
6. 尽早与真实用户验证： 要知道一个想法是否好，就要尽早并贯穿整个探索过程与实际用户一起测试它。
7. 以最快、最廉价的方式验证： 测试想法时，使用能够回答问题的最低保真度方法——以节省时间和金钱。
8. 共享学习——整个团队负责学习： 团队中的每个人都应该参与探索并分享所学。

这些原则共同鼓励一种思维转变：

• 从在会议室做决定到在实地学习。
• 从承诺想法到测试想法。
• 从单打独斗到团队理解和调整。

探索技巧概述​

Cagan 概述了一套有组织的探索技巧，并按其在探索过程中的目的进行分组：

1. 框架构建技巧 (Framing Techniques)： 用于在构思解决方案之前正确地定义机会或问题空间。
2. 规划技巧 (Planning Techniques)： 帮助规划如何进行探索并收集所需输入。
3. 构思技巧 (Ideation Techniques)： 用于在了解问题和目标后产生和探索解决方案。
4. 原型制作技巧 (Prototyping Techniques)： 详细介绍不同类型的原型，以回答探索中的不同风险问题。
5. 测试/验证技巧 (Testing/Validation Techniques)： 系统地测试四大风险（可用性、价值、可行性、商业可行性）。
6. 转型技巧 (Transformation Techniques)： 介绍如何将组织转变为采用这些新实践。

总而言之，探索过程是全面的——不是随意的头脑风暴然后编码，而是一套结构化的步骤，大大降低了产品开发的风险，并以可控的方式释放了创造力。

探索框架构建技巧 – 机会评估、客户信、创业画布​

机会评估 (Opportunity Assessment) (第35章): 这是一个简单但强大的技术，用于根据其解决的机会来定义一个提议的产品创意。Cagan 的机会评估要求团队（尤其是PM）预先回答四个基本问题：

1. 这项工作旨在解决什么业务目标？
2. 我们如何知道我们是否成功了？（即成功的关键结果或指标是什么）。
3. 这将为我们的客户解决什么问题？
4. 我们为谁解决这个问题（目标客户）？

客户信 / 新闻稿 (Customer Letter / Press Release) (第36章): 借鉴亚马逊的“逆向工作法”，这项技术让团队在构建产品或功能之前撰写：

• 一份想象中的新闻稿，向客户宣布产品成功发布。
• 有时也写一封想象中的**“客户来信”**给CEO，描述产品如何改善了他们的生活/业务。 其理念是如此生动地构想最终状态，以至于它澄清了什么将使产品真正卓越。

创业画布 (Startup Canvas) (第37章): 当处理一个全新的产品时（比如在创业公司或一个有许多未知数的新产品线中），创业画布（或精益画布、商业模式画布）是关键假设/风险领域的一页蓝图。它有效地一次性框定了所有风险领域，并决定哪些需要首先进行探索。

探索规划技巧 – 故事地图、客户探索计划​

故事地图 (Story Map) (第38章):

• 故事地图技术（由 Jeff Patton 提出）是一种将用户任务和工作流程捕获并组织成一个视觉地图的方法。
• 它沿着顶部（从左到右作为主干）写出用户的旅程步骤。
• 在每个步骤下，团队列出用户在该步骤可能做的故事或任务。
• 这创建了一个网格，可以在上面画一条水平线来表示MVP的分割：线上是第一个版本中要包含的内容，线下是以后要做的事情。

客户探索计划 (Customer Discovery Program) (第39章):

• 这涉及到招募一组目标客户（通常是6-10个），他们在探索期间成为你产品的设计合作伙伴或早期测试者。
• 该计划寻找真正迫切需要解决方案的真实客户。
• Cagan 称之为他“最喜欢的未来成功的领先指标”——意思是，如果你能让几个真实客户早期高度参与，这表明你走在正确的轨道上。
• 它提供了持续的现实检验和洞察来源，而不是一次性的访谈。

探索构思技巧 – 客户访谈、礼宾服务、客户的“不当行为”、黑客日​

客户访谈 (Customer Interviews) (第41章):

• 可能是最重要的探索活动：直接与用户/客户交谈以获得洞察。
• 以学习而非证明的心态进行访谈。
• 理想情况下，产品经理、设计师和工程师都应以某种身份参与访谈。

礼宾测试 (Concierge Test) (第42章):

• 这涉及到手动为几个客户提供服务或解决方案，就像你是他们的“礼宾员”一样，以在投资自动化之前衡量价值。
• 它强调谦逊：先做那些不能规模化的事情，以学习什么需要规模化。

客户“不当行为”的力量 (The Power of Customer Misbehavior) (第43章):

• 这是关于观察和利用客户以意想不到的方式使用你的产品来解决其他问题。
• 用户“滥用”或破解产品可能揭示了你的产品部分满足的一个潜在需求或市场。
• 例如：Twitter 用户在 Twitter 正式支持之前发明了标签和@回复。

黑客日 (Hack Days) (第44章):

• 这是定期的活动，团队成员（特别是工程师、设计师）在短时间内（通常是1-2天）自由地从事任何与产品/使命相关的项目或想法。
• 优点：
  • 让工程师参与构思： 明确地让工程师和他人提出和原型化正常待办事项之外的想法。
  • 士气与文化： 鼓励“创客”文化，带来乐趣，并表明领导层重视创新。

探索原型制作技巧 – 原型原则、可行性、用户、实时数据、混合原型​

原型原则 (Principles of Prototypes) (第45章):

• 为学习而原型，非为炫耀： 原型的目标是廉价地回答问题和处理风险。
• 廉价且快速： 原型应该是你可以毫不后悔地扔掉的东西。
• 深入思考： 原型制作的行为迫使团队详细思考解决方案的各个方面。
• 共享理解： 原型是比会议更好的沟通工具。
• 为正确的风险选择正确的保真度： 根据需要测试的内容选择合适的保真度级别。
• 原型可作为规格说明： 一旦原型产生了测试良好的设计，它通常可以作为开发人员构建的蓝图。

可行性原型 (Feasibility Prototype) (第46章):

• 旨在回答：“我们能用现有的时间/技术构建这个解决方案吗？我们将如何构建它？”
• 通常是代码或技术驱动的，但很小——例如，“刚好足够的代码来降低风险”。

用户原型 (User Prototype) (第47章):

• 旨在模拟用户界面和体验，以便与用户进行定性测试。
• 通常是高保真UI模拟，如在 Figma/InVision 中制作的可点击原型。
• Cagan 指出“它不适合证明任何东西”——意思是它提供洞察，而非统计上显著的验证。

实时数据原型 (Live-Data Prototype) (第48章):

• 这是一个在真实环境中部分功能可用，使用实际数据或系统的原型，但并未完全构建或准备好投入使用。
• Cagan 警告：“PM告诉工程师原型已经足够好可以用于生产是不行的。”

混合原型 (Hybrid Prototype) (第49章):

• 通常被称为绿野仙踪 (Wizard of Oz) 原型，其中系统的部分由人类在用户不知情的情况下伪造。
• 你呈现一个看起来功能齐全的高保真前端，但幕后由一个人处理部分或全部流程。
• 用于测试需要复杂后端/AI才能实现的高保真体验的用户反应，而无需先构建该后端。

探索测试技巧 – 测试可用性、价值（需求、定性、定量）、可行性、商业可行性​

这个章节组涵盖了如何测试每个风险领域：

• 测试可用性 (Testing Usability) (第50章):

  • 使用高保真原型。
  • 让产品经理、设计师和工程师都观察测试。
  • 让用户大声思考。
  • 保持用户处于“使用模式”而非“评论模式”。
  • 主持人应保持安静，不引导用户。

• 测试价值 (Testing Value) (第51章):

  • 本章可能介绍了测试产品对用户是否有价值的必要性，并涵盖了定性和定量方法。

• 需求测试技巧 (Demand Testing Techniques) (第52章):

  • 在完全构建之前衡量市场需求的方法：
    • 假门测试 (Fake door test): 添加一个尚不存在的功能的UI元素（按钮、链接），并测量点击率。
    • 着陆页测试 (Landing page test): 创建一个描述产品/功能概念的简单网站，看是否有人注册或表示兴趣。

• 定性价值测试技巧 (Qualitative Value Testing Techniques) (第53章):

  • 这些是为了获得快速的洞察和重大发现，而非为了“证明”。Cagan 称之为*“最重要的单一探索活动”*。
  • 核心思想是看用户是否愿意以某种方式付出或承诺：
    • 金钱： 让他们签署购买意向书（LOI）。
    • 声誉： 询问他们是否会推荐朋友或公开代言。
    • 时间： 询问他们是否愿意投入时间来试用产品。

• 定量价值测试技巧 (Quantitative Value Testing Techniques) (第54章):

  • 这些涉及更大规模或基于数据的测试，以收集价值的证据：
    • 使用实时数据原型对一小部分真实用户进行测试，看指标是否变化。
    • A/B 测试： 如果有足够的流量，向一小部分用户展示新功能，以衡量行为影响。
    • 邀请制 Beta 测试： 对于流量较小或风险较高的产品，邀请选定的一组用户试用并测量他们的使用情况。

• 测试可行性 (Testing Feasibility) (第55章):

  • 这涉及到确保提议的解决方案在技术上是可行的，能够在规模上、预算内和时间表上实现。它超越了早期原型，包括架构审查、性能和负载测试等活动，以及在承诺全面构建之前确保所有技术依赖项都能得到满足。

• 测试商业可行性 (Testing Business Viability) (第56章):

  • 确保设想的产品在所有业务约束下都能运作，并得到所有业务利益相关者（市场、销售、客户成功、财务、法务、业务发展、安全和高管）的支持。
  • 为了“测试”可行性，产品经理基本上会与每个领域的代表会面，并向他们介绍计划中的解决方案概念，解决他们的担忧。

第五部分：对的文化​

《启示录》的最后一部分讨论了公司文化——那些支持或阻碍持续创新和产品卓越的环境与价值观。

好产品团队 / 坏产品团队​

Cagan 对比了好团队与坏团队的行为，以突出文化差异：

• 工程师的参与：
  • 坏团队只在冲刺规划时向工程师展示原型以进行估算。
  • 好团队从早期就让工程师持续参与探索。
• 对待速度的态度：
  • 坏团队试图通过更努力地推动员工来提速。
  • 好团队通过更好的技术和减少浪费来提高速度。
• 对数据与分析的态度：
  • 坏团队认为分析是“锦上添花”，经常在没有埋点的情况下发布功能。
  • 好团队痴迷于数据，并将分析融入一切以指导决策。
• 竞争对手导向 vs 客户导向：
  • 坏团队痴迷于竞争对手并复制他们的功能。
  • 好团队痴迷于他们的客户并解决他们的需求。
• 成功标准与庆祝方式：
  • 坏团队在功能发布时庆祝（产出）。
  • 好团队在实现有意义的影响时庆祝（成果）。

创新力丧失的主要原因​

Cagan 列出了公司创新力下降的几个关键缺失因素：

• 以客户为中心的文化
• 引人入胜的产品愿景
• 重点突出的产品策略
• 强大的产品经理
• 稳定的产品团队
• 工程师参与探索
• 企业的勇气
• 被授权的产品团队
• 创新的时间
• 产品思维

如果一家公司想知道“我们为什么不创新？”，答案很可能就在这些缺失的元素中。

效率丧失的主要原因​

Cagan 指出了团队效率随时间下降的最常见原因：

• 技术债
• 缺乏强大的产品经理
• 缺乏交付管理
• 发布频率低
• 缺乏产品愿景/策略
• 缺乏同地协作、持久的团队
• 没有尽早让工程师参与
• 没有在探索中利用设计
• 频繁变更优先级
• 共识文化

建立强大的产品文化​

在最后一章，Cagan 概述了强大产品文化的两个维度：持续创新和持续执行。

1. 要持续创新，公司需要：

   • 一种实验和开放心态的文化。
   • 被授权的、多元化的、并且精通业务和客户的团队。
   • 现代技术和探索技巧的常规使用。

2. 要持续执行，公司需要：

   • 一种紧迫感和高完整性的承诺。
   • 被授权的、具有强烈责任感的团队。
   • 一种协作的文化，并专注于结果而非产出。
   • 对实现影响和展现正确行为的认可。

Cagan 指出，很少有公司能在创新和执行两方面都表现出色，但那些做到的公司往往能主导其行业。目标是建立一个两者都优先的文化。这需要有意的领导力来塑造这些价值观，并创建强化这些价值观的流程。最终，强大的产品文化是终极的竞争优势。

这不仅仅是一台电脑的诞生史，更是一群才华横溢、充满激情的“海盗”们，在一位传奇领袖的带领下，如何挑战常规、颠覆行业，最终用“疯狂而伟大”的产品改变世界的故事。通过亲历者安迪·赫茨菲尔德（Andy Hertzfeld）的视角，我们得以窥见那段发生在硅谷的革命岁月。

1979年：Woz造就的奇迹（What Hath Woz Wrought）​

1979年的夏天，年轻的安迪·赫茨菲尔德放弃了研究生学业，加入了当时正冉冉升起的苹果电脑公司。他接到的第一个任务，是为一款名为 Apple Silentype 的廉价热敏打印机编写固件。这个项目完美体现了苹果的工程哲学。硬件负责人维克·布尔（Vic Bull）设计的接口板极为简洁，打印机本身则由苹果与一家名为Trendcom的小公司合作提供。其核心理念源自苹果的联合创始人史蒂夫·沃兹尼亚克（Steve Wozniak，简称“沃兹”）。沃兹在设计Apple II软驱控制器时，就开创性地用软件替代了大量复杂的硬件电路，从而大幅降低了成本。

安迪兴奋地意识到，他将在这个项目中“扮演沃兹的软件角色”。他需要在仅有2KB的ROM中，编写出能直接控制打印机7个微小加热元件的固件，实现打印Apple II屏幕上的图形或文本。安迪迅速完成了底层例程，让用户通过简单的组合键就能打印屏幕图形。然而，当他思考打印机的首次输出内容时，却希望能超越程序员惯用的“Hello, World!”。在同事的启发下，他想到了电报发明人萨缪尔·摩尔斯发出的第一条信息：“上帝造就了什么？”（What Hath God Wrought?）。为了向摩尔斯和苹果的传奇工程师沃兹双重致敬，安迪灵机一动，将打印机的第一句输出定为：“What Hath Woz Wrought?”（“沃兹造就了什么？”）。当这行字成功打印出来时，安迪将这张热敏纸珍藏了多年，它成为他苹果生涯的开篇注脚。

在这个项目中，安迪也初次领略了苹果自由甚至有些疯狂的工程文化。由于担心软件崩溃可能导致热敏头过热起火，维克特意在硬件上加入了定时断电保护电路。为了测试这个机制，安迪大胆地编写了一个恶作剧般的程序，以99%的占空比持续加热，试图让打印纸着火。结果，打印纸真的冒出刺鼻的浓烟，继而被烧穿，甚至蹿出了微小的火苗！幸好安迪眼疾手快用外套扑灭了火焰，虽然打印头也因此报废。这场“小火”不仅证明了保护电路的必要性，也体现了苹果鼓励工程师大胆探索技术极限的文化氛围。没人因此严厉指责他，这件轶事反而成了办公室里的笑谈，那台打印机甚至偶尔被用来“表演喷火”。最终，市场部为这款安静的热敏打印机起名为“Silentype”（谐音**“Silent type”，即“无声打印”**），这个双关语让热爱文字游戏的安迪会心一笑，也为他的苹果初体验画上了完美的句号。

1979年：做你的好朋友（I'll Be Your Best Friend）​

入职苹果仅一周，安迪的办公桌上出现了一本神秘的黑色活页册，封面手写着“Apple II原理简介”。这本手册对Apple II硬件的精妙设计做出了精辟解析，作者署名为伯勒尔·C·史密斯（Burrell C. Smith）。很快，一位留着金色长发、神情兴奋又略带局促的年轻人——伯勒尔本人，出现在安迪面前。他热情地称赞安迪发表过的技术文章，并郑重其事地与他握手，仿佛寻得知音。

伯勒尔是苹果第282号员工，一位自学成才的硬件奇才。他最初只是维修部门的一名底层技术员，却对沃兹的设计深深着迷。通过修理返厂的Apple II主板，他不仅完全掌握了其中的奥秘，还开始自行构思改进方案，并将心得写成了那本手册，毫无保留地与新同事安迪分享。两人迅速成为挚友，经常结伴午餐。安迪发现，伯勒尔不仅在工程上创意十足，生活中也充满奇思妙想。他会说服餐厅服务员将一份披萨做成三种甚至五种不同口味，或是将可乐与雪碧按特定比例混合当“鸡尾酒”品尝。这种在生活中无处不在的探索精神，正是他工程天赋的延伸。

伯勒尔的才华很快得到了证明。当高端机型Lisa团队为内存不足而苦恼时，他灵机一动，提出可以将Apple II的16KB语言卡改造成一张80KB的扩展卡。他利用银行切换（bank-switching）技术，巧妙地突破了Apple II的64KB内存寻址上限。这个想法立刻得到了资深程序员比尔·阿特金森（Bill Atkinson）的激赏。伯勒尔迅速焊出原型，比尔修改了软件支持，结果运行完美。这款“80KB语言卡”的成功，让伯勒尔从一个默默无闻的维修工一跃成为公司内的技术明星，也让他进入了“麦金塔之父”杰夫·拉斯金（Jef Raskin）的视野。正是比尔·阿特金森将伯勒尔引荐给拉斯金，并断言：“这小子能帮你设计麦金塔计算机！”

伯勒尔的幽默也为团队注入了活力。他喜欢用**“我会成为你最好的朋友！”（I'll be your best friend!）**作为请求同事帮忙的口头禅，并由此发展出一套“最佳朋友关系（B.F.R.）”的极客理论，声称这种关系高度动态，平均持续时间只有3到5毫秒。这种将技术术语融入日常的诙谐，是当时Mac团队文化的生动写照。他们轻松、平等，甚至在制作名片时，每个人都给自己起了有趣的头衔，安迪就自称为“软件巫师”（Software Wizard）。这种“海盗文化”鼓励创意与自嘲，为日后Mac团队的“疯狂”创新奠定了基调。

1979年：咱们走着瞧（We'll See About That）​

1979年末，苹果正秘密筹划一款面向大众、廉价易用的电脑——这便是Macintosh的最初构想。项目的发起人杰夫·拉斯金撰写了一系列论文，阐述他心目中“不超过500美元”的理想计算机，并为其选用了自己最喜欢的一种苹果品种（McIntosh）来命名。然而，拉斯金缺少能将他梦想变为现实的硬件工程师。

此时，伯勒尔·史密斯因改造80KB语言卡而声名鹊起。比尔·阿特金森带着年仅23岁、没有大学学历的伯勒尔来到拉斯金的家中，郑重推荐道：“杰夫，这位就是能为你设计出Macintosh的人。”面对这位年轻的奇才，拉斯金的态度颇为谨慎，他意味深长地回应了一句：“咱们走着瞧”（We'll see about that.）。这句话，既是挑战，也开启了Mac项目从概念走向现实的序幕。

伯勒尔接受了挑战。在1979年的圣诞假期，他夜以继日地工作，利用Apple II作为开发平台，于1980年1月设计出了第一台Macintosh原型机。它并非一台独立的电脑，而是一块搭载了摩托罗拉6809E处理器和64KB内存的接口卡，通过共享内存与Apple II主机通信，并将256x256像素的单色图像输出到一个小巧的7英寸显示器上。这种设计充分体现了伯勒尔“软硬结合”的巧思，用最少的硬件实现了功能。

硬件就绪，但缺少软件来验证。安迪·赫茨菲尔德再次挺身而出，利用业余时间编写了测试程序。然而，最大的挑战是如何在不关机重启的情况下，将磁盘控制卡插入正在运行的Apple II以加载程序。就在安迪一筹莫展之际，苹果的早期员工克里夫·休斯顿（Cliff Huston）自信地表示可以**“带电热插拔”**。在众人屏息注视下，克里夫以迅雷不及掩耳之势，稳稳地将磁盘卡插入插槽——奇迹发生了，Apple II丝毫未受影响，成功识别了新硬件。安迪随即加载并运行了他的程序，**一次成功！**Mac原型的小屏幕上清晰地显示出了图像。

这标志着Mac从无到有的飞跃。团队欢欣鼓舞，伯勒尔激动地向每一位经过的同事展示成果。拉斯金虽感欣慰，却对安迪这位“未经授权”的“黑客”式程序员略有不快。然而，这次成功已经悄然将一批充满激情的年轻工程师聚集在一起，一个即将改变个人计算机历史的团队已然成形。“咱们走着瞧”的预言，正以超乎想象的速度应验着。

1980年：守财老鸭诞生图（Scrooge McDuck）​

Macintosh第一次“睁开眼睛”看到世界，显示的图像是一幅别出心裁的迪士尼漫画：唐老鸭的富豪叔叔斯克鲁奇·麦克鸭（Scrooge McDuck），正满脸笑容地坐在金币堆上拉着小提琴。这张图成为了Mac历史上显示的第一幅图像，其诞生过程充满了戏剧性。

在1980年1月那个关键的夜晚，当克里夫·休斯顿完成了惊人的带电插拔后，安迪加载了他的测试程序。这张斯克鲁奇的图片，是他从一个包含许多迪士尼形象的软盘中偶然挑选的，他觉得这幅贪财又快乐的形象，恰好讽刺地契合了当时苹果公司财源滚滚又面临挑战的处境。为了给好友伯勒尔一个惊喜，安迪还巧妙地利用屏幕下方多出的空间，用漂亮的24点字体写上了一行问候：“Hi Burrell!”

第二天，伯勒尔看到屏幕上的图像和问候语，欣喜若狂，四处炫耀这个“麦金塔的第一张图”。这一突破迅速引起了高层的注意，工程副总裁汤姆·惠特尼看过演示后，对项目的可行性更加认可。然而，项目发起人杰夫·拉斯金却对安迪擅自向高层演示的行为略感不悦，认为他有“黑客”特质，不够循规蹈矩。

与拉斯金的谨慎不同，另一位苹果的灵魂人物——史蒂夫·乔布斯，在了解到这一进展后，敏锐地预感到了其中蕴藏的革命性潜力。一台廉价电脑竟能具备如此强大的图形能力，这正是他梦寐以求的未来方向。据说，乔布斯看到斯克鲁奇的图像后也爽朗地笑了，并调侃道：“我们可不能让Mac变成一个守财奴！”他一方面欣赏这份幽默，另一方面也借此提醒团队，Mac的使命是颠覆，而非守成。

这次成功的演示，综合了硬件的精巧设计、底层软件的高效编程以及现场操作的大胆机智，充分展现了Mac早期开发中工程师们“野路子”般的才华。它不仅点亮了一块屏幕，更点燃了整个团队的信念与凝聚力。这张斯克鲁奇老鸭的图像，不仅促使乔布斯最终决定亲自掌管Mac项目，更在1984年的正式发布会上作为彩蛋再次出现，向那段激情燃烧的草创岁月致敬。

1981年1月：创业“小楼”初长成（Texaco Towers）​

1981年初，Mac项目迎来了决定性的转折。史蒂夫·乔布斯正式从杰夫·拉斯金手中接管了项目，并将其提升为苹果的战略核心。他将这支小团队从苹果主园区搬到附近一栋曾是德士古（Texaco）石油公司办事处的不起眼办公楼里，这里从此被团队戏称为**“Texaco大楼”**。安迪后来回忆道：“就是在那栋楼里，麦金塔真正诞生了。”

这次搬迁象征着Mac团队进入了一个全新的独立发展阶段。乔布斯开始着手打造一支小而精的跨学科“梦之队”，他从苹果各处网罗顶尖人才：数字模拟天才乔治·克罗（George Crow）负责电源设计，系统软件专家巴德·特里布尔（Bud Tribble）担任软件经理，并吸引了如图标字体设计师苏珊·凯尔（Susan Kare）等一批艺术家和年轻工程师的加盟。

在Texaco大楼里，一种独特的“海盗文化”开始形成。团队在楼顶升起了一面由工程师史蒂夫·卡普斯（Steve Capps）手绘的海盗旗——黑色的骷髅头，眼罩则换成了苹果的彩虹标志，昭示着他们桀骜不驯、敢于挑战海军（暗指IBM或公司内部的官僚）的精神。办公室里杂乱却充满激情，工程师们常常通宵达旦，困了就在办公室打地铺。乔布斯则像一位严厉而富有感染力的船长，他穿梭于每个人的工位，提出各种大胆设想，并用一句名言激励大家：“真正的艺术家最终要交付产品”（Real artists ship）。

正是在这栋简陋的小楼里，Mac的技术开发进入了高速迭代期。硬件方面，伯勒尔·史密斯在两年内先后设计了五种不同架构的原型，不断在性能与成本之间寻求最佳平衡。软件方面，安迪·赫茨菲尔德与比尔·阿特金森等人紧密合作，将Lisa项目的图形界面模块进行瘦身和优化，开发出高效的图形库QuickDraw。他们面临的最大挑战，就是如何在仅有128KB内存的限制下，实现乔布斯所要求的流畅图形界面和鼠标操作。这栋楼见证了无数次的技术争论、深夜调试和成功突破后的欢呼。他们甚至制作了印有**“每周工作90小时，并乐在其中”**口号的T恤，以自嘲和自豪的态度拥抱这段疯狂的岁月。Texaco大楼，就是Mac团队的“创业车库”，孕育了这款革命性产品的灵魂。

1981年4月：和Adam Osborne的交锋（A Message For Adam）​

1981年4月的西海岸电脑博览会，是当时个人电脑行业的盛会。正是在这里，羽翼未丰的Mac团队遭遇了来自业界的首次公开挑衅。亚当·奥斯本（Adam Osborne），全球首款成功便携电脑“奥斯本1号”的创始人，以其直言不讳的风格著称。当他得知苹果正在研发一款带小屏幕的图形电脑Macintosh时，便当着乔布斯和几位团队成员的面，发出了极具攻击性的嘲讽。

奥斯本挥舞着他那台重达24磅的“便携机”，挖苦道：“你们的Mac用那么小的屏幕，能干什么？拿去垫桌脚吗？”他认为，用户绝不会喜欢一个屏幕只有9英寸的“小玩具”。面对这番奚落，乔布斯出人意料地保持了冷静，只是微笑着请奥斯本“拭目以待”，并未当场发作。然而，这番话深深刺痛了在场的Mac团队成员。

回到办公室后，他们誓言要“用产品让奥斯本闭嘴”。安迪在团队的布告板上贴了一张卡通画，画中一个大力士正举着一台小屏幕电脑，砸向一只喋喋不休的大嘴鸟（暗指奥斯本），标题赫然写着：“给亚当的信息”（A Message For Adam）。这种内部的黑色幽默，极大地鼓舞了团队的士气。乔布斯也利用这次事件激励团队：“也许亚当是对的，如果我们做不出惊艳的东西，那就真成了他嘴里的玩具。”

奥斯本的质疑并非毫无道理，小屏幕确实是Mac设计中的巨大挑战。为了在有限的512x342像素上提供实用的图形界面，团队付出了艰辛的努力。比尔·阿特金森的QuickDraw图形库为此进行了大量优化，苏珊·凯尔设计的清晰图标和字体，以及将菜单栏固定在屏幕顶部的创新，都是为了在有限空间内最大化利用每一个像素。

他们坚信自己的方向是正确的，正如乔布斯后来所说：“我们的屏幕虽然小，但每个像素都是精雕细琢的。”历史最终给出了答案。1984年，当优雅的Macintosh成功发布时，奥斯本的电脑公司已因经营不善宣告破产。Mac团队用无可辩驳的成功，向这位曾经的挑战者传递了最响亮的信息。

1981年5月：菠萝披萨之夜（Pineapple Pizza）​

1981年5月的一个周五下午，对Mac团队而言是一个里程碑时刻——第一块印刷电路板（PCB）样板送抵了苹果。这标志着Mac的硬件设计从繁杂的线缆原型，迈向了稳定可靠的集成电路板。硬件天才伯勒尔·史密斯和设计师科莱特·阿斯克兰为此付出了数周心血。

样板意外提早到达，伯勒尔和助手本打算下周再进行调试。然而，史蒂夫·乔布斯迫不及待地冲进实验室，问道：“今晚能让它跑起来吗？”伯勒尔解释说调试至少需要几个小时，现在开始太晚了。但乔布斯不想等待，他知道伯勒尔最近酷爱吃菠萝披萨，于是笑着许诺：“如果你今晚把板子点亮，我就请所有留下来的人吃菠萝披萨！”

这个简单而充满诱惑力的激励奏效了。伯勒尔、安迪等几位核心成员决定留下加班。实验室里，大家围坐在伯勒尔身旁，气氛紧张又兴奋，仿佛在见证一个新生儿的降生。经过数小时的紧张焊接和组装，晚上8点左右，伯勒尔深吸一口气，首次给新板卡通电。

屏幕亮了，但出现的并非预期的问候语，而是一片杂乱的棋盘格图案。一阵短暂的沉默后，伯勒尔却露出了笑容：“这不算太糟，至少说明内存和视频部分大致正常，我们很接近成功了。”他随即转向乔布斯，宣布：“但我太饿了，我觉得是时候吃菠萝披萨了！”

乔布斯也笑了，他认可了团队的阶段性成果。一行人驱车直奔那家著名的意大利餐厅，享用了一顿美味的菠萝披萨大餐。在餐桌上，乔布斯举杯感谢伯勒尔让板子“活了”，伯勒尔则风趣地回应：“谢谢披萨让我活了！”

这个“菠萝披萨之夜”生动地体现了Mac团队的文化：努力工作，也尽情庆祝。乔布斯独特的领导艺术，用恰到好处的激励取代了严苛的命令，营造出一种充满信任和人情味的氛围。正是无数个这样由友谊、激情和披萨构成的夜晚，最终铸就了Macintosh这部不可思议的机器。

1981年5月：圆角矩形无处不在！（Round Rects Are Everywhere!）​

在Macintosh图形界面的开发中，有一个元素看似微不足道，却深刻体现了乔布斯的美学偏执和Mac团队对细节的极致追求——那就是圆角矩形。在那个时代，电脑屏幕上的一切几乎都是由生硬的直角构成的。但乔布斯坚信，产品的友好度体现在每一个细节里，他希望Mac的窗口、按钮和对话框都拥有平滑的圆角，从而传递出一种温润、亲切的感觉。

这个看似简单的要求，在当时却是技术上的一大挑战。负责图形库QuickDraw的天才程序员比尔·阿特金森，为此投入了大量精力，最终攻克了难题。他通过精巧的数学优化和查表法，编写出了能快速绘制平滑圆角的算法，而不会拖慢系统速度。

当比尔第一次向乔布斯展示这个成果时，乔布斯欣喜若狂。他拉着比尔，兴奋地宣称：“快看，圆角矩形无处不在！（Round Rects Are Everywhere!）”他开始在现实生活中四处寻找圆角设计的例子——从路牌到电视机外壳，并以此向团队强调，计算机界面也应该拥有这种源于自然的曲线美感。

“圆角矩形”迅速成为Mac团队的设计准则。安迪·赫茨菲尔德在编写界面代码时，充分利用了这个功能；设计师苏珊·凯尔在绘制图标时，也特意采用圆角边框以保持风格统一。圆角的设计哲学甚至延伸到了硬件，Mac电脑物理机箱的边缘也被设计成了柔和的圆弧。

这个故事完美诠释了Mac团队中设计与工程的紧密结合。一方面，乔布斯以其非凡的审美直觉，推动着看似“挑剔”的美学要求；另一方面，工程师们则以其卓越的才智，将这些艺术构想变为现实。他们会为了一个像素的差异反复调试，只为找到最令人舒适的曲率。这种对完美的共同执念，让Mac的界面在诞生之初就呈现出超越时代的精致与优雅，并深刻影响了此后几十年的软件设计风尚。

1981年7月：美学至上，连电路板都要好看（PC Board Esthetics）​

史蒂夫·乔布斯对美的追求是全方位的，甚至深入到了用户永远看不到的内部。1981年中，当第一版Mac印刷电路板（PCB）完成时，他提出了一个令所有工程师都目瞪口呆的要求：重新布局线路，让电路板本身看起来也要“漂亮”。

乔布斯坚信，伟大的工匠即使在人们看不见的家具背面也会精心打磨。他拿着那块从功能角度看毫无问题的电路板，指着上面为了性能而选择的最短路径走线说：“这几根线歪歪扭扭，看得我心烦。”他又指着元件排列说：“这些芯片不够整齐，挪一下，让它们排成一条直线。”

起初，硬件设计师伯勒尔·史密斯和乔治·克罗试图解释，电路板的布局是为了信号完整性和性能，不能随意更改。但乔布斯坚持己见：“我不在乎你们用什么方法，最终的成品拿在手里必须赏心悦目。”他甚至引用父亲教导他的话：“你自己知道那是否做好了。”

无奈之下，伯勒尔和PCB设计师科莱特·阿斯克兰只好花了额外一周的时间，在不牺牲核心性能的前提下，对电路板进行了“美学优化”。他们略微增大了板子面积，将许多信号线拉直或设计成优美的弧线，并调整了芯片和元件的排列，使其呈现出一种视觉上的对称与和谐。

当新版电路板完成后，乔布斯满意地点了点头。这件事在团队内部引发了巨大震动。一些人起初抱怨乔布斯“吹毛求疵”，但事后也不得不承认，重新布局后的电路板确实像一件精心打造的艺术品。这次“电路板美学”事件，向整个团队传递了一个强有力的信息：苹果对极致的追求绝不流于表面。它将“设计驱动”的理念深深地烙印在了公司的DNA中，并最终塑造了苹果产品“从里到外都精致”的传奇形象。

1981年7月：第一次微软演示（Shut Up!）​

1981年7月，为了构建未来的软件生态，苹果邀请了当时还远非巨头的微软公司高层，进行了一场高度机密的Macintosh原型演示。乔布斯希望说服比尔·盖茨为Mac开发应用软件，因此决定向他们展示Mac的革命性魅力。

演示由乔布斯亲自主持，比尔·盖茨和他的几位核心开发人员坐在台下。当乔布斯用鼠标在屏幕上流畅地进行绘图、撤销等“所见即所得”的操作时，习惯了命令行界面的微软工程师们被深深震撼了。

然而，微软团队中一位名叫查尔斯·西蒙伊（Charles Simonyi）的开发主管，出于技术人员的本能，在演示过程中不断插话，提出各种尖锐的技术问题，例如内存占用和多任务处理等。乔布斯起初还耐心解答，但随着西蒙伊的提问变得喋喋不休，他终于失去了耐心。在西蒙伊再次打断他时，乔布斯猛地转身，对着他厉声喝道：“Shut up!（闭嘴！）”

会议室瞬间陷入死寂，气氛一度非常尴尬。比尔·盖茨急忙打圆场，请乔布斯继续。演示结束后，尽管发生了不愉快的插曲，盖茨依然对Mac给予了高度评价，并当场承诺将为Mac开发新版的电子表格（即后来的Excel）和文字处理器。

这次充满戏剧性的演示，标志着苹果与微软早期合作关系的建立，也预示了两者未来复杂的竞合关系。乔布斯强悍的“现实扭曲力场”和对产品的绝对掌控欲展露无遗。对Mac团队而言，他们不仅见证了自家产品的魅力足以折服未来的行业霸主，更从领袖身上感受到了那种不容置疑、誓死捍卫梦想的决心。而这次演示也刺激了微软，使其更加重视图形界面的研发，间接催生了后来的Windows系统。

1981年8月：谁写了那款笨游戏？（Donkey）​

1981年夏天，IBM PC的横空出世给苹果带来了巨大的竞争压力。乔布斯立刻买来一台，供Mac团队研究对手。在探索这台新机器时，安迪·赫茨菲尔德发现了一款名为DONKEY.BAS的简单游戏。游戏中，玩家需要控制一辆汽车在路上躲避一头驴子，其画面、音效和玩法都显得异常粗糙和笨拙。

Mac团队的成员们一边玩一边嘲笑：“天哪，这也太糟糕了！是谁写的？”出于好奇，他们查看了程序的源代码，结果惊讶地发现，作者署名中赫然出现了两个名字：尼尔·康南（Neil Konzen），以及——比尔·盖茨。

这个发现让整个Mac团队乐不可支。原来，大名鼎鼎的软件业巨头比尔·盖茨，也曾写过如此蹩脚的游戏！这很可能是他在为IBM PC赶制BASIC解释器时，随手编写的一个演示程序。乔布斯听闻此事后也笑着说：“看来比尔在游戏设计上可没什么天赋。”

这件事迅速成为团队内部的流行笑料。“小心，不要被驴撞了！”成了一句广为流传的俏皮话，用来调侃技术上的粗糙或失误。这个小插曲极大地增强了Mac团队的优越感和自信心。尽管IBM PC在硬件上很强大，但他们坚信，凭借卓越的软件体验，Mac终将胜出。

“Donkey”的故事，就像一个轻松的注脚，反衬出Mac在用户体验和软件创意上的前瞻性。它激励着团队要创造出远超竞争对手的、真正精美而有趣的应用。多年以后，当比尔·盖茨被问及自己写过的最差的程序时，他苦笑着承认，大概就是那个“驴子游戏”了。而这头像素构成的小驴，也在Mac诞生的传奇中，留下了令人捧腹的一笔。

1982年2月：签名仪式（Signing Party）​

1982年2月，乔布斯提出了一个极具创意的想法，以此来纪念和表彰Mac团队的辛勤付出。他深受艺术家在作品上签名的传统启发，决定让每一位核心团队成员都在Macintosh的机壳内部留下自己的名字。这些签名将被蚀刻在注塑模具上，从而使每一台量产的Mac电脑内部，都永久地带上创造者们的印记。

为此，团队举行了一场别开生面的**“签名派对”**。在一块将用于制作模具的塑料板上，乔布斯率先签下了自己的名字。随后，安迪·赫茨菲尔德、伯勒尔·史密斯、比尔·阿特金森等47位工程师、设计师、市场人员和管理者，都郑重地找到了自己的位置，签下了大名。现场气氛轻松而神圣，大家互相打趣，有人还在签名旁画上了有趣的符号，比如苏珊·凯尔画下的小笑脸，后来竟成为开机时“微笑Mac”图标的灵感来源。

这个举动让所有团队成员深受感动。在那个时代，工程师们往往是幕后英雄，他们的名字很难与最终产品联系在一起。乔布斯却用这种方式，给予了他们最高的荣誉和认可。他在派对上说：“未来有一天，当Mac无处不在时，你们可以告诉家人和朋友：把这台电脑打开，里面有我的名字。”许多人当场热泪盈眶。

这次签名仪式，不仅是一次士气的极大提升，更是Mac团队文化的完美体现。它象征着Mac是集体智慧的结晶，是一种不可复制的团队荣誉。当Mac发布后，有极客拆开机器发现了这些隐藏的签名，此事迅速成为媒体热点，将Mac团队的“海盗”故事传遍了世界。这些签名，不仅刻在了塑料机壳上，更深深刻在了每个成员的心中，成为他们共同创造历史的永恒见证。

1982年3月：团队与Lisa的冲突（And Another Thing...）​

在苹果内部，Mac并非唯一在研发的图形界面电脑。启动更早、投入更多的Lisa项目，定位高端商用市场，与Mac团队形成了并行的竞争关系。随着乔布斯带领的Mac项目进展神速且更具革命性，两个团队之间的摩擦日益加剧。

Lisa团队认为，乔布斯和他的“海盗们”抢走了本该属于他们的资源和风头。在一场激烈的内部产品策略会议上，Lisa的硬件经理里奇·佩奇（Rich Page）愤怒地对乔布斯说：“我们Lisa费尽心血做出来的东西，你们Mac只是个小玩具罢了！”乔布斯则毫不示弱地反唇相讥：“Mac才是未来。”

争执不断升级，佩奇甚至暗示应该砍掉Mac以保全Lisa。会议不欢而散，临走时，佩奇还愤愤不平地回头补充了一句：“**还有一点……（And another thing...）**我受够了你对我们指手画脚！”这句话生动地捕捉了当时双方剑拔弩张的关系。

这场冲突背后，是技术路线和市场定位的根本分歧。Lisa追求功能全面，但因此成本高昂（最终定价近1万美元），系统略显臃肿；Mac则奉行简约哲学，力求在有限的成本和资源下实现极致的用户体验。

这种内部竞争虽然带来了紧张和内耗，但也像催化剂一样，激发了Mac团队更强的战斗意志。他们憋着一股劲，要向公司证明，“小团队也能干出大事业”。他们在图形响应速度、系统稳定性等方面拼命优化，力求在各项指标上超越“老大哥”Lisa。这段“我们与他们”的对抗岁月，虽然充满压力，却也磨砺出了Mac团队非凡的创造力和执行力。最终，市场的选择给出了答案：昂贵的Lisa昙花一现，而亲民的Macintosh开启了个人电脑的新纪元。

1983年2月：翘尾巴的绩效评估（Too Big For My Britches）​

随着Mac开发进入冲刺阶段，团队内部的管理问题也开始浮现。1983年初，作为软件核心的安迪·赫茨菲尔德，遭遇了一次令他心碎的绩效评估。他的直属上司、从施乐空降而来的软件经理鲍勃·贝尔维尔（Bob Belleville），在一次迟来的面谈中，给出了出人意料的苛刻评价。

贝尔维尔的管理风格传统而强硬，与Mac团队自由奔放的“海盗”文化格格不入。他认为安迪绕过他直接向乔布斯汇报，是“不够尊重管理层”。在评估中，他直截了当地对安迪说：“你最近尾巴翘得太高了（too big for your britches），不像以前那么谦逊了。”他指责安迪过多干预硬件讨论、逾越本职，并以此为由，拒绝了安迪的升职和加薪请求。

这次谈话让安迪感受到了莫大的委屈和背叛。他自觉为项目倾尽所有，贡献卓著，却换来上司的故意打压。贝尔维尔最后那句“要么接受，要么走人”更是让他心灰意冷。这件事在团队中引起了不小的波澜，大多数同事都站在安迪这边，认为贝尔维尔的管理方式过于刻薄官僚。

这次不愉快的评估，暴露了Mac团队在从创业激情向正规化管理过渡时出现的矛盾。它代表了两种不同文化的冲突：一方是以贡献和激情为导向的创始文化，另一方是强调等级和控制的传统管理。对安迪个人而言，这件事成为他最终决定离开苹果的导火索。在Mac发布后不久，他便辞职去追寻新的梦想。这起事件也成为苹果管理史上的一个反思案例：如何在一个伟大的项目中，有效地激励和留住那些才华横溢的核心人才。

1983年8月：偷偷合作索尼（Quick, Hide in This Closet!）​

在Mac开发后期，一个棘手的硬件问题摆在了团队面前：原计划使用的苹果自研Twiggy软盘驱动器性能不佳，可靠性极差。硬件工程师乔治·克罗深知，采用日本索尼公司新研发的3.5英寸软驱才是最佳选择。然而，史蒂夫·乔布斯出于维护苹果自研成果的自尊心，起初坚决反对，并明确禁止团队私下接触索尼。

为了产品的最终质量，乔治和几位工程师决定“将在外，君命有所不受”。他们背着乔布斯，偷偷与索尼的工程师展开了接触和评估。戏剧性的一幕发生在一次秘密会谈中：当索尼工程师Hideaki Kamoto正在Mac实验室展示样品时，乔布斯意外地提前返回了办公室。

情急之下，乔治·克罗和同事们急中生智，对惊慌失措的索尼工程师说：**“快，躲进这个柜子里去！”（Quick, Hide in This Closet!）**他们迅速将身材瘦小的Kamoto先生连同资料一起塞进了储物柜。乔布斯进来看了一圈，对这个多出来的柜子略感狐疑，但并未深究便离开了。

这次有惊无险的“藏人”事件，后来成为Mac团队津津乐道的传奇。它完美诠释了团队文化中的“海盗精神”：为了追求卓越的产品，他们敢于挑战权威，甚至冒着被解雇的风险。最终，事实证明工程师们的坚持是正确的。Macintosh采用了索尼的3.5英寸软驱，不仅大大提升了产品的可靠性，还一举推动了该规格成为全球行业标准。这段滑稽又意义重大的插曲，展现了工程师们为了工程真理而展现出的非凡勇气、智慧与坚持。

1983年9月：沃兹学苑（Steve Wozniak University）​

伯勒尔·史密斯，这位一手设计出Mac硬件的天才，却有一个在日益正规化的苹果公司里显得格格不入的“短板”——他没有大学学位。一些新来的管理者对此颇有微词，质疑他缺乏正规教育背景。

为了回击这种迂腐的学历论，并赞美伯勒尔超凡的才能，安迪和团队成员们开创了一个充满敬意的玩笑。他们声称，伯勒尔毕业于一所独一无二的学府——“史蒂夫·沃兹尼亚克大学”（Steve Wozniak University）。这个说法的寓意是，伯勒尔的才华师承于同样没有完成大学学业、却创造了Apple II的传奇工程师沃兹，这种在实践中获得的真知，远比一纸文凭更为宝贵。

这个玩笑迅速在团队中传开。当有内部刊物采访时，伯勒尔一本正经地回答自己的毕业院校是“沃兹大学”，让记者和那些质疑者都哑口无言。苹果的另一位创始人史蒂夫·沃兹尼亚克本人听闻后也哈哈大笑，他甚至真的在一张荣誉证书上签名，授予伯勒尔“自学成才”学位，以示支持。

“沃兹学苑”的故事，有力地捍卫了Mac团队能力至上、贡献为王的核心价值观。他们崇尚真才实学，鄙视官僚和形式主义。正是这种不拘一格、唯才是举的文化，才让像伯勒尔这样未经雕琢的璞玉得以大放异彩。最终，伯勒尔凭借其无可辩驳的贡献，被破格提升为“苹果院士”（Apple Fellow），享受公司最高技术职位待遇。事实证明，真正的创造力，是任何学历都无法衡量的。

1983年9月：玩物亦有悟（Make a Mess, Clean It Up!）​

在紧张的开发工作之余，Mac团队也需要放松。伯勒尔·史密斯当时迷上了一款名为《Defender》（捍卫者）的街机游戏。他玩得非常投入，但技术平平，每次游戏过程都是手忙脚乱、大呼小叫，最终在一片“混乱”中结束。

然而，一个有趣的细节引起了同事们的注意。每次“制造了一团糟”之后，伯勒尔都会立刻拿出纸巾，认真地将游戏机的控制面板和屏幕擦拭得干干净净，再把摇杆归位。他解释说：“我搞得那么乱，得收拾干净，不然下一个人没法玩了。”

这个小小的举动，与他游戏时的疯狂形成了鲜明对比。同事Donn Denman从中看到了伯勒尔性格的缩影，并将其写成了一篇名为**“搞乱了就清理干净！”（Make a Mess, Clean It Up!）**的趣闻。这个故事迅速在团队中流传，并引发了共鸣。

大家意识到，这正是伯勒尔乃至整个Mac团队工作方式的写照。在研发过程中，他们勇于尝试各种疯狂的想法，不怕暂时“搞乱”系统或“制造麻烦”。但更重要的是，他们始终秉持着强烈的责任感，一旦出了问题，总会亲手将其修复完善，绝不留下烂摊子。这种**“允许试错，但必须负责”**的文化，鼓励了创新，也保证了最终产品的质量。这个源于游戏室的简单哲学，生动地诠释了Mac团队在追求突破过程中的勇气与担当。

1983年10月：“每周90小时，且乐在其中”（90 Hours A Week And Loving It）​

1983年秋，Macintosh的开发进入了白热化的最后冲刺阶段。团队成员几乎是以办公室为家，每周工作80到90个小时是家常便饭。然而，在这种极度高压的状态下，团队中弥漫的却不是抱怨，而是一种自豪和激情。

这股精神的完美体现，源自伯勒尔·史密斯的一件DIY卫衣。他将一件普通的苹果T恤剪成无袖衫，并用记号笔在上面潦草地写下了一句口号：“每周工作90小时，且乐在其中！”（90 Hours A Week And Loving It）。

这句看似自嘲的标语，瞬间点燃了整个团队。它精准地捕捉了大家当时的生活状态和内心感受——虽然身体极度疲惫，但精神上却因为正在创造历史而感到无比兴奋和快乐。乔布斯看到后也大加赞赏，并立刻让公司定制了一批印有这句口号的T恤，分发给每一位团队成员。

“每周90小时”从此成为Mac团队的非官方座右铭和荣誉勋章。他们穿着这件“战袍”，在最后的几个月里攻克了无数技术难关：在128KB的极限内存中为应用挤出空间，彻夜调试与激光打印机的通信协议，绘制数千个日文字符……他们不是被动加班，而是主动投入，舍不得离开实验室，生怕错过任何一个让Mac变得更完美的机会。这段疯狂燃烧的岁月，将一群独立的个体淬炼成一个无坚不摧的集体，他们的奉献精神，最终成就了一款伟大的产品。

1983年11月：来自邻居Xerox的富翁（A Rich Neighbor Named Xerox）​

随着Macintosh发布在即，微软宣布开发Windows 1.0的消息让乔布斯勃然大怒。他认定这是赤裸裸的抄袭，于是将比尔·盖茨召至苹果总部当面对质，质问他为何“偷我们的东西”。

面对乔布斯的雷霆之怒，比尔·盖茨的回应镇定而又充满了历史性的讽刺意味。他抛出了那段著名的比喻：“史蒂夫，我觉得我们更像是有个叫施乐（Xerox）的富邻居。我闯进他家想偷电视机，结果发现你已经抢先一步把它偷走了。”

盖茨的言下之意是，苹果的图形界面本身就借鉴了施乐帕洛阿尔托研究中心（Xerox PARC）的创意，因此苹果没有资格垄断这一理念。这句话虽然让乔布斯暴跳如雷，却也一针见血地指出了技术创新中复杂而微妙的传承关系。

的确，乔布斯在1979年对Xerox PARC的访问，是催生Lisa和Macintosh的关键。然而，Mac团队认为，他们是将施乐那些停留在实验室里的粗糙原型，真正转化为了优雅、可用、且能被大众消费的伟大产品，这本身就是一种革命性的创新。而微软则是坐享其成的“拿来主义”。

这场“富邻居施乐”的争论，标志着苹果与微软从合作走向全面竞争的转折点。它也让Mac团队深刻地意识到，创新是一场永不停歇的接力赛。如果不能持续奔跑，自己也可能成为下一个被超越的“富邻居”。这场来自竞争对手的挑战，反而更加坚定了他们必须保持领先的决心。

1983年12月：Capps万圣节（Steve Capps Day）​

1983年末，才华横溢的软件工程师史蒂夫·卡普斯（Steve Capps）从Lisa团队加入，为Mac开发关键的文件管理器（Finder）等应用。他个性活泼，喜欢穿着标志性的工装背带裤和棒球帽。为了欢迎这位重要的新成员，并延续团队的恶作剧传统，大家策划了一场惊喜。

圣诞节前的一天，被定为**“史蒂夫·卡普斯日”**。所有团队成员，包括史蒂夫·乔布斯在内，都 secretly 穿上了和卡普斯一样的蓝色工装背带裤和棒球帽。当卡普斯推门进入办公室时，他惊呆了——几十个“自己”正坐在那里对他微笑。

整个办公室爆发出震耳欲聋的笑声和欢呼声。乔布斯拍着卡普斯的肩膀说：“欢迎来到史蒂夫·卡普斯日！”这个精心策划的玩笑，瞬间消除了新成员的隔阂，让卡普斯感受到了家人般的温暖和接纳。

这次活动生动地展现了Mac团队独特的文化：在高强度的工作压力下，他们依然保持着幽默感和童心，懂得如何苦中作乐、凝聚士气。乔布斯也乐于参与其中，与员工们打成一片，毫无老板的架子。这种上下同乐、平等包容的氛围，是Mac团队能够不断吸引顶尖人才、并激发出惊人创造力的重要原因。它不仅仅是一次恶作剧，更是对团队中每一位成员个性和贡献的庆祝。

1984年1月：Mac诞生！​

1984年1月24日，在弗林特中心（Flint Center）的舞台上，史蒂夫·乔布斯向世界揭开了Macintosh的神秘面纱。在播放了那则石破天惊的“1984”超级碗广告后，他从一个帆布包里取出了小巧的Mac电脑。

在全场近三千名观众的注视下，乔布斯进行了一系列令人目眩的演示。最后，他微笑着说：“现在，我想请Macintosh自己说几句话。”

伴随着键盘的敲击声，Mac的屏幕上出现了一段文字，同时，一个清晰的合成语音从机器中传出：“Hello, I am Macintosh. It sure is great to get out of that bag…”（大家好，我是麦金塔。能从那个包里出来真是太好了…）。

全场先是死一般的寂静，随即爆发出雷鸣般的掌声和欢呼，经久不息。观众们起立致敬，乔布斯眼含热泪，骄傲地望向台下的团队。那一刻，所有的辛劳、争执、牺牲和梦想，都凝聚成了永恒的辉煌。Mac团队的成员们在台下相拥而泣，他们知道，自己真的改变了世界。

发布会取得了空前的成功。Macintosh以其友好的图形界面、创新的鼠标操作和革命性的设计理念，宣告了一个全新个人计算时代的到来。发布会后，Mac团队在苹果总部升起了那面著名的海盗旗，庆祝这场伟大的胜利。

---

这段从1979年到1984年的历程，充满了技术突破、团队冲突、管理博弈和无数闪光的个人英雄主义。Mac团队以其非凡的才华、不羁的“海盗精神”和对完美的偏执追求，克服了重重阻碍。他们不仅创造了一款伟大的产品，更铸就了一种独特的创新文化，其影响深远至今。正如他们所相信的：那些疯狂到以为自己能够改变世界的人，才能真正地改变世界。 而他们，做到了。

在 2018 年，FDA 终于批准了用于短肠综合症婴儿的鱼油营养——这种治疗在欧洲已经拯救了数十年的生命。延迟并不是由于监管者的无能，而是 Eliezer Yudkowsky 所称的“无效平衡”的教科书案例：一个稳定但不理想的状态，在这个状态下，明显的改进未能实现。虽然美国婴儿使用大豆基配方奶面临高达 30% 的死亡率，但接受鱼油基替代品治疗的欧洲婴儿，死亡率降至 9%。这种明显的差异揭示了即使是先进的系统也可能被惯性所困。

不充分的平衡出现在没有任何单一参与者——无论是公司、监管者还是个人——既没有激励也没有手段来改善系统时。当市场高效时，往往会消除这种低效。但在某些领域，系统性约束加剧了失败，为那些愿意挑战现状的人创造了机会。

系统惯性的隐性成本​

以美国医疗保健系统为例，医疗错误仍然是第三大死亡原因，每年导致超过 250,000 人死亡。与航空业通过严格的错误追踪将事故减少 65% 不同，医院很少追踪错误率或发布绩效指标。这种失败并不是由于医疗专业人员的无能，而是结构性障碍的结果。医院害怕诉讼、监管处罚和声誉损害，形成了一种隐瞒而非透明的文化。不充分的平衡：得以维持。

同样，在网络安全领域，尽管威胁不断上升，许多组织仍然依赖过时的做法。采购流程、合规要求和纯粹的组织惯性创造了一个即使是优越的解决方案也难以获得 traction 的系统。这些系统性盲点——嵌入在政策、习惯和文化中——将组织锁定在次优结果中。

来自技术的教训：打破平衡​

技术行业，常常因其活力而受到赞誉，也并未免于这些陷阱。几十年来，程序员忍受着笨拙的版本控制系统。像 CVS 和 Subversion 这样的工具充其量只是渐进式的改进，未能挑战根本性的低效。林纳斯·托瓦兹（Linus Torvalds）作为版本控制工具领域的外部人士，创造了 Git——这不是一个渐进式的改进，而是一个范式转变。Git 的分布式模型和性能优势打破了不充分的平衡，展示了大胆的、由外部驱动的创新如何使停滞的系统复苏。

识别机会的框架​

Yudkowsky 的不充分平衡概念提供了一种视角，以识别系统何时适合被颠覆。它依赖于三个问题：

1. 市场效率：该领域是否迅速消除低效？
   • 高效市场，如高频交易，几乎没有明显的机会。
   • 低效市场，如医疗保健，受到不透明定价和激励不对齐的困扰。
2. 系统性约束：是否存在阻碍改进的结构性障碍？
   • FDA 的规定要求昂贵的大规模研究，阻碍了像鱼油营养这样的解决方案，即使其好处已经很明显。
   • 学术研究优先考虑新颖性而非复制，导致关键发现未得到验证。
3. 信息不对称：你是否拥有他人所缺乏的见解？
   • 患者在小众疾病上往往比全科医生研究得更透彻。
   • 初创公司由于不受官僚主义的束缚，可以超越现有企业。

机会在召唤​

对于企业家和技术领导者，这一框架指向可操作的策略：

• 针对系统性约束限制现有企业的领域。
• 专注于远未达到最佳的“足够好”市场。
• 寻找低技术障碍的高摩擦问题。

例如，考虑气候技术。碳捕集充满了不充分的平衡：资金缺口、政策惯性和根深蒂固的能源利益减缓了采用。然而，那些能够绕过这些系统性障碍——通过模块化解决方案或非常规融资模式——可以改变这一格局。

打破不可能的神话​

“不充分的平衡”提醒我们，没有人解决一个问题的原因并不总是技术上的不可能——往往是系统性的不对齐。问“为什么没有人已经做到这一点？”是错误的问题。正确的问题是：

• 什么激励维持当前状态？
• 我可以绕过哪些他人无法绕过的障碍？
• 我如何在等待系统改变的同时提供价值？

考虑 OpenAI。当学术 AI 研究在资助周期和发表或灭亡的激励下停滞不前时，OpenAI 建立了一个以月球计划为重点的组织，优先考虑部署而非论文。通过绕过传统的学术约束，他们加速了进展并占领了前沿。

对于你内心的乐观主义者​

对于乐观主义者来说，不充分的平衡不仅仅是问题——它们是通往隐藏机会的地图。历史表明，系统不会自我修复；它们是由那些看到他人忽视的事物并在他人不愿意时采取行动的人修复的。无论是改变婴儿护理、重写网络安全规则，还是开创新技术，最大的突破来自于理解不仅是什么破碎的，还有为什么——并敢于去修复它。

因此，下次当你遇到一个破碎的系统时，不要将其视为一个无法解决的混乱。仔细看看。在它的约束中，潜藏着一个等待被抓住的机会。

为什么有些人想要通过成为企业家挣钱？因为他们想打败市场——以低于市场的成本，获得超出市场的回报——即获得高于市场的利润率。而超出市场的价格源自产品或者服务的稀缺性/独特性，想要有独特性就必须创新，所以，想要成为企业家必须至少是创新者。

大多数的公司之所以可以成功，都是因为他们知道如何持续地在对的事物上受到启发，持续地产生新想法。如何辨别最合适的创新之源，以战胜对手，从产业中脱颖而出？

七个创新之源​

• 内部

  • 意外之事：比如面对家用电器的购买量的突升，梅西限量销售，而 Bloomingdale's 利用这个机会扩充了电器部门，从而提升了利润。

  • 市场和行业的发展：比如汽车市场全球化的时候，沃尔沃也跟着全球化，从而比没有快速全球化的雪铁龙做得好。

  • 流程中薄弱的环节：医药销售商William Connor在意识到了眼科手术的一个麻烦环节 : 眼韧带出血。所以他建议用酶溶解韧带代替切割韧带，这大大减少了手术风险，并被眼科医学领域广泛接受。这次针对短处的革新使他的公司获得了极大的利润。

  • 现实与感知之沟（难道 TK 也是德鲁克的使徒？）：比如轮渡货运早年误以为缩短时间的关键在于提高航行速度，但实际上这样做会导致成本剧增，问题的关键其实在于降低船闲置在港口的时间。

• 外部：比如政治、学术、科学

  • 社会观念的变化：对于环保和高科技的趋之若鹜让电车市场火热。
  • 人口结构变化：比如中国数字原住民的增多和对线上社区的需求催生了 Bilibili。
  • 新知识的杂交：比如计算机是数百年来数学、电子、编程技术的杂交产物。

大小公司都需要创新​

一个新起步的公司需要具体目标和计划，具体见打造公司的五个阶段。

在创业初期，企业家应该要在尝试不同领域后，找到合适的市场。因为很有可能你会在一个你从未想过的领域最终创业成功。第二步则是确立好正确的财政重心。保证公司在遇到问题时有足够的解决资金是极其重要的。最后一步是为公司建立一个可信赖的管理团队。这个团队应该要在公司团队壮大之前就完善起来。

不仅是小商人需要改革创新，大产业也同样需要注入新鲜的血液。初始阶段，他们应该标准化企业内铸新淘旧的规则。其次，革新后的项目由全新的负责人管控。最后一点是，企业应该要设置褒奖机制，这样可以帮助提高员工的生产表现，并有效回顾创新的效果。

四个创新战略​

孤注一掷（Fustest with the mostest）​

一个有智慧的企业家应该目标成为该行业的先行者，倾其所有敢为人先。Hoffmann-La Roche 拥有一个小的化工公司，但他机智地发现了维生素行业的商机。所以为了生产和销售维生素，他投资了一大笔钱雇了许多专家。虽然听起来十分有风险，但这次“赌博”最终有了好结果，他在60年间都是维他命行业的领军者。

攻其软肋 (Hit them where they ain’t)​

发现对手注意不到的漏洞是十分不容易的，但有两种方法可以实现。第一个是用更新颖和吸引人的手法模仿对手的想法。举个例子，IBM 公司模仿对手 ENIAC 电脑公司的想法，并在此之上加以更创新的点子，最终从中获利。不仅如此，有些公司还可以通过痛击对方的短处而赢得胜利。这对于目中无人的大公司尤其奏效。

生态位 (Ecological Niches)​

这原本是一个生物学概念：生态位是一个物种所处的环境以及其本身生活习性的总称。每个物种都有自己独特的生态位，借以跟其他物种作出区别。

一个公司如果专攻于不可替代的领域，则更容易成功。一个很好的例子就是 William Connors 开发的酶类。这类酶在后来成为了消除白内障手术中至关重要的一步。但是值得注意的是，这个公司也有很可能在对手研发出可替代的药物后，失去在该产业中的绝对优势。

变价值和特征 (Changing values and characteristics)​

为了增加对于你的产品的需求量，你不一定需要改变产品本身。相反，找到一个更符合消费者利益的方法可能是更重要的。企业家应该要了解是什么让消费者愿意买单。举个例子，吉列公司之所以剃须刀免费、刀片付费，正是因为当时该公司意识到，消费者根本不愿意花高于刮胡刀本身得钱买刀片。