启示录：如何打造用户喜爱的产品 (2017版) by Marty Cagan
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 解释说，最好的产品团队确实利用了精益和敏捷，但使他们与众不同的是超越基本方法论的三个核心原则：
- 预先处理风险： 强大的团队不会立即开始编写详细的规格或代码，而是首先解决任何产品创意的四个主要风险——价值风险（客户会想要它吗？）、可用性风险（用户能弄清楚如何使用它吗？）、可行性风险（我们有时间和技术来构建它吗？），以及商业可行性风险（这个解决方案对我们的业务是否有效——法律、市场、财务等方面？）。他们在投入开发之前，先完成艰难的学习过程。在实践中，这意味着尽早使用原型、客户访谈和其他实验来验证一个想法是否值得构建，并在各个方面都可行。
- 协作、持续的设计——而非顺序的孤岛： 在顶尖公司，产品、设计和工程从一开始就协同工作。他们不会互相扔文档。设计师和工程师从定义解决方案阶段就参与其中，与产品经理实时迭代。这种协作能产生更好的解决方案（因 为考虑了所有视角），并避免了后期出现大的意外。相比之下，不太成功的团队通常在需求确定后才让设计介入，在设计完成后才让工程师介入——这是平庸产品的配方。
- 专注于解决问题，而非实现功能： 强大的团队不是通过交付了多少功能来衡量成功，而是将成功定义为解决了一个客户或业务问题。他们拥抱一种以成果为导向的心态。例如，他们不会说“在第四季度前构建功能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 列出了设计师的几个关键职责：
- 交互设计 (UX) – 打造产品的行为方式，信息如何组织，并使其对用户实现目标直观易用。
- 视觉设计 – 美学：布局、颜色、字体以及使产品吸引人并与品牌保持一致的整体外观。
- 原型制作 – 构建原型（从纸质草图到高保真交互式模型）以快速测试想法。设计师通常会创建多个原型来探索不同的方法。
- 持续用户测试 – 不断与用户验证设计。好的设计师不是每季度等待一次大型可用性实验室测试，而是每周都会把东西放到用户面前，即使是非正式的，以收集反馈。
- 整体性思维 – 确保用户体验在产品的每个部分甚至产品之外都是一致的。例如，设计师可能会考虑用户注册后收到的电子邮件——其语气和设计是否与应用内体验一致？（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 提供了一套原则，而不是一个“一刀切”的组织结构图。目标是以最大化自主性、一致性和有效性的方式来构建团队。关键原则包括：
- 将团队结构与产品/组合投资策略对齐： 团队的划分方式应反映公司选择投资产品领域的方式。例如，如果一家公司有两条主要产品线，那么它很可能应该为每条产品线设立独立的团队（或团队组），而不是让一个团队跨越两者。如果某个领域更关键（比如80%的收入来自它 ），你可能会在该领域安排更多的团队或人员。从本质上讲，把你的员工放在你的战略所在之处。
- 最小化团队间的依赖关系： 每个产品团队理想上都应该是自主的——能够以最少的交接或需要其他团队批准的情况下设计、编码和发布价值。依赖关系会减慢速度并削弱责任感。为了最小化依赖关系，应按功能/领域而非层次来构建团队。例如，不要有一个“前端团队”和一个“后端团队”，而是有一个跨职能团队，端到端地拥有一个完整的功能。
- 明确的所有权和自主权： 每个团队都应该有一个明确定义的责任领域（一个功能、一个用户旅程、一个微型产品等），并被授权在该领域内做出决策。当团队的职责重叠或不明确时，就会出现差距和冲突。自主权意味着他们可以在其领域内运行探索、做出路线图选择（在战略范围内），并在没有大量协调的情况下部署变更。
- 最大化杠杆作用（但要谨慎）： 这指的是在能带来显著好处时，在团队间共享能力。例如，一个构建通用工具的“共享平台团队”可以增加杠杆作用，避免每个团队都重新发明轮子。然而，共享团队必须谨慎使用：每次你集中化某样东西，你都会创造一个潜在的瓶颈，并减少单个团队的自主权。
- 遵循产品愿景和战略： 随着产品的演进，团队结构也会演变。如果产品愿景指向新的领域，你最终可能会为这些领域创建新的团队。Cagan 建议至少每年重新审视一次团队结构——它是一个移动的目标。
- 最佳团队规模： 他提到3-12人是一个产品团队规模的指导方针。少于3人几乎不算一个团队，超过10-12人则沟通起来会变得笨拙。
- 与架构对齐（架构又应与产品愿景对齐）： 软件架构和团队边界应该相对应。如果系统是作为微服务构建的，团队通常会围绕这些服务或其集群组织起来。这种对齐减少了跨团队的技术工作。
- 与用户或客户对齐： 理想情况下，每个团队专注于某一类型的用户或特定的客户旅程。例如，一个团队可能拥有市场中的“卖家体验”，另一个拥有“买家体验”。这种以用户为中心的结构有助于团队深入共情他们的用户并为他们创新。
- 与业务领域或单元对齐： 在某些情况下，特别是在大公司，产品团队会映射到业务单元或产品线。与业务单元对齐有助于问责制（每个单元的损益表都与一个团队的产出挂钩）。
- 随时间演变结构： 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 列举了制定和使用强大产品愿景的原则：
- 从“为什么”开始（使命）： 一个伟大的愿景清晰地与一个更大的目的相连。
- 爱上问题，而非解决方案： 愿景应专注于你打算解决的客户问题或需求，而不是特定的解决方案。
- 敢于大胆思考（颠覆自己）： 愿景应该是雄心勃勃的——它甚至可能威胁到你当前的业务方式。
- 必须鼓舞人心： 愿景必须激励团队，并且应该是简短、难忘、富有感染力的。
- 拥抱并预见趋势（滑向冰球将要去的地方）： 一个强大的愿景应考虑到产品将要生存的未来背景。
- 对愿景执着，对细节灵活： 一旦你设定了一个引人注目的愿景，就把它当作你的北极星，但在如何实现它上保持开放。
- 愿景是一种信念的飞跃： Cagan 指出，如果你今天就能完全验证这个愿景，那它就不够雄心勃勃。
- 持续宣传： 产品愿景必须由领导者和产品经理反复沟通，使其深入人心。
这些原则有助于打造一个以问题为中心、雄心勃勃、鼓舞人心、紧跟趋势并具有指导性的愿景。
产品策略的原则
对于产品策略，Cagan 概述了确保策略有效和一致的原则：
- 一次只专注于一个目标市场/画像： 成功的产品通常始于深入地攻克一个目标市场或画像，即使它们可以服务于许多市场。
- 与业务战略对齐： 确保产品策略支持公司的整体业务战略。
- 与销售和上市策略对齐： 产品策略应考虑销售渠道和营销策略。
- 痴迷于客户，而非竞争对手： Cagan 建议，虽然你必须了解竞争对手，但不要让他们决定你的策略。应专注于更好地理解和服务你的客户。
- 在整个组织中清晰地传达策略： 一旦确定了愿景和策略，领导者必须广泛而反复地进行沟通。
总而言之，这些原则确保产品策略是专注的、一致的、以客户为驱动的，并且被充分理解的。
产品原则
Cagan 提到产品原则是进一步指导产品决策、使其与愿景和战略保持一致的工具。产品原则本质上是描述公司/团队旨在创造何种产品体验以及避免何种体验的信条或价值观。它们通过提供日常决策的准则来补充愿景/策略。要点：
- 定义： 产品原则是产品应遵守的高层标准或口号。例如，“简单 > 强大”意味着在权衡时，宁愿选择为用户提供简单性，而不是以复杂性为代价增加功能。
- 为何要有： 原则帮助团队做出一致的决策，这些决策与产品的特性和愿景保持一致，而无需总是向上级寻求批准。它们充当产品设计和功能辩论的北极星。
- 示例： 一些常见的公司产品原则：
- “别让我思考”（用于用户体验——一切都应直观）。
- “性能也是一个功能”（快速响应时间至关重要）。
- “一个产品，一种体验”（跨平台的一致性）。
- “用小细节取悦用户”（可能用于消费类应用）。
- 实践中的使用： 在辩论一个功能或设计时，团队可以参考原则。例如，“我们的原则是‘尽可能少的点击’，所以这个需要5个步骤的流程与此相冲突——我们如何缩短它？”
- 与公司价值观的区别： 它们与公司价值观相关，但更具体于产品决策。
总而言之，产品原则就像设计和开发选择的北极星。它们不断提醒你在你的产品中哪些品质是不可协商的。
第四部分：对的流程
第一至三部分确立了我们所需要的（优秀的团队、明智的产品愿景/策略、对成果的关注）。第四部分深入探讨了在实践中如何实际探索和构建产品——即强大产品团队用来持续创新和交付的流程。这关乎产品探索技巧、验证方法和工作流程，旨在最小化风险并最大化速度和学习。
产品探索的原则
Cagan 概述了关于产品探索的核心原则或真理——在探索构建什么时应遵循的规则：
- 客户（和利益相关者）无法告诉你他们想要什么： 一个基本原则：你不能简单地向客户或高管询问解决方案然后构建它。 探索不是接受命令——它是深入理解问题然后测试解决方案。
- 最重要的是建立真正的价值： 价值风险是探索中首先要解决的问题。 如果产品创意不能带来价值，其他一切都无关紧要。
- 用户体验通常更难（也更关键）： Cagan 断言使产品易于使用和愉悦通常比使其在技术上可行更棘手，而且这绝对至关重要。
- 功能、设计和技术是相互交织的——要协同工作： 一个早前提到的原则——整体地对待产品开发。探索应该涉及三方协作。
- 大多数想法行不通；可行的想法通常需要迭代： 接受失败是正常的——预计你的许多初步想法或实验不会产生积极结果。
- 尽早与真实用户验证： 要知道一个想法是否好，就要尽早并贯穿整个探索过程与实际用户一起测试它。
- 以最快、最廉价的方式验证： 测试想法时，使用能够回答问题的最低保真度方法——以节省时间和金钱。
- 共享学习——整个团队负责学习： 团队中的每个人都应该参与探索并分享所学。
这些原则共同鼓励一种思维转变：
- 从在会议室做决定到在实地学习。
- 从承诺想法到测试想法。
- 从单打独斗到团队理解和调整。
探索技巧概述
Cagan 概述了一套有组织的探索技巧，并按其在探索过程中的目的进行分组：
- 框架构建技巧 (Framing Techniques)： 用于在构思解决方案之前正确地定义机会或问题空间。
- 规划技巧 (Planning Techniques)： 帮助规划如何进行探索并收集所需输入。
- 构思技巧 (Ideation Techniques)： 用于在了解问题和目标后 产生和探索解决方案。
- 原型制作技巧 (Prototyping Techniques)： 详细介绍不同类型的原型，以回答探索中的不同风险问题。
- 测试/验证技巧 (Testing/Validation Techniques)： 系统地测试四大风险（可用性、价值、可行性、商业可行性）。
- 转型技巧 (Transformation Techniques)： 介绍如何将组织转变为采用这些新实践。
总而言之，探索过程是全面的——不是随意的头脑风暴然后编码，而是一套结构化的步骤，大大降低了产品开发的风险，并以可控的方式释放了创造力。
探索框架构建技巧 – 机会评估、客户信、创业画布
机会评估 (Opportunity Assessment) (第35章): 这是一个简单但强大的技术，用于根据其解决的机会来定义一个提议的产品创意。Cagan 的机会评估要求团队（尤其是PM）预先回答四个基本问题：
- 这项工作旨在解决什么业务目标？
- 我们如何知道我们是否成功了？（即成功的关键结果或指标是什么）。
- 这将为我们的客户解决什么问题？
- 我们为谁解决这个问题（目标客户）？
客户信 / 新闻稿 (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 概述了强大产品文化的两个维度：持续创新和持续执行。
-
要持续创新，公司需要：
- 一种实验和开放心态的文化。
- 被授权的、多元化的、并且精通业务和客户的团队。
- 现代技术和探索技巧的常规使用。
-
要持续执行，公司需要：
- 一种紧迫感和高完整性的承诺。
- 被授权的、具有强烈责任感的团队。
- 一种协作的文化，并专注于结果而非产出。
- 对实现影响和展现正确行为的认可。
Cagan 指出，很少有公司能在创新和执行两方面都表现出色，但那些做到的公司往往能主导其行业。目标是建立一个两者都优先的文化。这需要有意的领导力来塑造这些价值观，并创建强化这些价值观的流程。最终，强大的产品文化是终极的竞争优势。
