10.14 产品管理与探索

概述与动机

产品管理是一门学科，负责决定要构建什么以及为什么要构建，并对其是否奏效负责。产品经理拥有的是问题、客户和结果的所有权，而不是拥有日程表、工单队列，或利益相关者交办下来的功能清单。这个区别一句话就概括了本章的核心。当产品管理退化为项目协调或被动接单时，团队就会变成一座”功能工厂”：不停发布、速度指标漂亮，却撼动不了任何业务指标。这个角色存在的意义，正是为了防止这种情况发生。

对大型团队而言，薄弱的产品管理往往是代价最高、却最不引人注意的失败模式。工程可以做得非常出色，交付可以非常迅速，而整台机器仍然可能用极高的效率花上一年时间构建错误的东西。这种成本不会出现在工程仪表盘上，而是表现为收入停滞不前、客户流失，以及一大堆没人使用却人人都得维护的功能积压。好的产品管理能在投入资金之前让这种风险变得可见，做法是坚持目标必须明确、可衡量，并与真实的客户问题相挂钩。

企业和政府场景会提高风险，也会改变这项工作的形态。企业正日益从项目运营模式（为项目拨款、交付、然后解散团队）转向产品运营模式（为长期存续、拥有多年成果所有权的团队拨款），并把内部平台当作拥有真实客户的产品来对待。政府也在”以用户为中心的设计”这面旗帜下学到同样的教训：为服务而非项目拨款，并衡量公民是否真正得到了服务。本章讲的正是让这种转变落地的思维方式与具体机制。它与第 11.1 章（发现流水线）紧密配套（）该章详述流水线的运作机制；本章则聚焦于角色、策略，以及”发现”这项工作的日常习惯。

关键原则

拥有”是什么”与”为什么”的所有权。 产品经理对结果负责，而不是负责协调任务。
结果重于产出。 发布本身是一种成本，而不是结果；结果是客户行为或业务指标发生了改变。
比任何人都更了解客户和问题。 脱离客户接触的策略只是猜测。
发现是持续的，而不是一个阶段。 你每周都要与客户交谈，与交付并行进行。
优先级框架是判断的辅助工具，不是神谕。 数字为决策提供参考，但不能替你做决定。
路线图是意图声明，不是带日期的承诺。 对问题要坚定承诺，对解决方案要保持灵活。
赋能三人组。 产品、设计和工程共同决策；产品经理单打独斗做出的决策往往很糟糕。

建议

拥有”是什么”与”为什么”的所有权，把”怎么做”交给团队

判断产品管理是否健康，最清晰的测试就是看谁拥有哪个问题的决定权。产品经理拥有的是我们要解决什么问题以及为什么现在这件事很重要；设计拥有的是用户的体验应该是什么感觉；工程拥有的是我们该如何构建。当产品经理开始亲自指定解决方案、截止日期和实现细节时，他们就变成了一个顶着产品头衔的项目经理，也剥夺了赋能型团队之所以有效的那份自主权（第 5.1 章讨论了与设计的协作关系，第 10.7 章讨论了敏捷交付模型）。

一个被赋能的产品团队，有时被称为”产品三人组”（product trio），由产品、设计、工程共同组成，拿到的是一个待解决的问题，而不是一个待构建的功能。这就是”把新用户 30 天留存率提高”和”3 月前做出通知中心”之间的区别。前者赋能团队去寻找最佳解决方案，并要求他们对结果负责；后者则把团队降格为交付的执行臂，并悄悄把”判断错误”的风险转嫁给了写下这条需求的人。如果你想让团队对结果负责，就必须放弃对产出的控制权。

制定以客户为根基的产品愿景与策略

产品策略是一组艰难而精简的选择：你要服务哪些客户、为他们解决哪些问题，以及同样重要的（）你拒绝做什么。愿景是你想要创造的世界的持久图景，通常展望两到五年；策略则是通向那个图景的一系列行动。缺少这两者，优先级排序就会退化成谁嗓门大谁说了算，路线图也会变成把每个人心心念念的功能拼凑到一起的清单。

没有对客户和问题的深入、第一手了解，策略就无从谈起。一个说不出客户具体是谁、他们想完成什么任务、目前卡在哪里的产品经理，还没有资格对任何事情排优先级。这不是一次性委托做的调研，而是一种持续接触的习惯。最优秀的产品负责人能凭记忆讲出上周和客户的对话，而不是上个季度的调研报告。当你把问题吃透了，大多数优先级之争都会自行消解，因为团队可以靠证据而不是意见来推理。

面向结果管理，摆脱功能工厂

当”成功”被定义为”我们把它发布了”时，你得到的就是功能工厂：团队衡量速度、统计发布次数、为上线庆祝，而真正关系到营收的指标却纹丝不动。解药是把成功定义为一种结果（客户或业务行为的改变），并在动工之前就为它附上一个衡量指标。这正是产品管理与目标与关键成果（第 11.4 章）交汇之处：目标描述你想要的改变，关键成果衡量这种改变，而一条写成”上线功能 X”的关键成果，其实是伪装成结果的任务。

留意这些警示信号：如果你的路线图是一份没有说明结果的功能清单，如果没人说得出某个已发布功能撬动了哪个指标，如果回顾会议从不问”这管用吗”而只问”我们发布了吗”，那你就身处功能工厂之中。摆脱它主要靠纪律：在有人说清楚问题和衡量指标之前，拒绝接受被包装成解决方案的工作。产品分析与对照实验（第 7.4 章）给了你一套仪表盘，能把真实的结果和一个让人心安的故事区分开来。

让发现与交付并行、持续进行

持续产品发现意味着：每一周，与交付并行，团队都在从客户身上学习，并检验支撑其构建计划的各项假设。这个模型是双轨的：发现轨道为想法去风险，交付轨道构建已经过验证的想法，两条轨道持续并行运转，而不是按先后顺序分阶段进行（第 11.1 章详述了这条流水线）。其背后的实际承诺很小，但要毫不松懈：每一周都要和客户交谈，哪怕你很忙（）尤其是在你很忙的时候。

支撑这一点的一个有用骨架是”机会-方案树”（opportunity-solution tree）：从一个期望达成的结果出发，向下分支出可能推动它的客户机会（需求、痛点、渴望），再分支出针对每个机会的候选方案，最后分支出能告诉你某个方案是否奏效的假设检验。这棵树能让团队对”为什么某个功能被摆上台面”保持诚实，并迫使你去比较各种机会，而不是一见钟情地爱上第一个方案。在投入工程资源之前，用成本最低的实验（）一次访谈、一个原型、一个”假门”测试、一次 A/B 测试（）去检验风险最大的那条假设。发现的产出不是一份功能清单，而是一连串已经验证过、可衡量、随时可以交付的赌注。

把优先级框架当作判断的辅助工具，而不是神谕

优先级框架能为一个混乱的决策带来有用的结构，但只要你把它给出的数字当作真理，每一个框架都会出错。RICE 通过覆盖面（Reach，多少用户）、影响力（Impact）、信心（Confidence）和工作量（Effort）为每个想法打分，再按 (Reach x Impact x Confidence) / Effort 排序。加权评分根据若干条加权标准给各选项打分。延迟成本（cost of delay）问的是每多等一周会让你付出什么代价，这往往是排序时最锋利的一把尺子。Kano 模型把功能分为基本期望、性能需求和惊喜项，提醒你满意度并非线性关系。

使用这些框架是为了把你的假设暴露出来，让权衡变得可以讨论，而不是为了让你放弃决策权。RICE 中的信心项和加权评分中的各项估值，本质上都是披着算术外衣的主观判断，虚假的精确度会把一个糟糕的赌注洗白成一份看起来客观的排名。先算出分数，再问这个排名是否符合你的策略和你对客户的了解。如果不符合，就相信判断，去质询输入项。框架是思考的辅助工具，真正要对结果负责的人始终是你。

把路线图当作意图声明来对待

一份承诺在特定季度交付特定功能、带有明确日期的路线图，是每个人都会签字、却没人能兑现的虚构，因为它把”解决方案”这个本该由发现过程不断学习和调整的东西给固定死了。更可取的是现在/下一步/以后（now/next/later）式路线图：我们现在在做什么、接下来可能做什么、以后可能会考虑什么，用问题和结果来表达，而不是带日期的既定功能承诺。这样既能诚实地传达方向，又能保留在证据出现后调整解决方案的自由。

其背后的核心动作是：对问题和结果坚定承诺，对解决方案保持松散承诺。要求确定日期的功能承诺的利益相关者，通常是在寻求可预期性，这本身是合理的诉求；那就在结果和时间范围的层面上满足他们（“这半年我们会显著降低新用户流失率”），而不是在你尚未验证过的具体功能层面上满足他们。当你必须给出一个硬性日期时，把它和一个有价值的结果绑定，让解决方案的范围保持弹性（）这正是第 10.6 章对项目交付给出的建议。

验证可取性、可行性、技术可行性与可用性

在投入真正的资源之前，一个产品想法必须闯过四道风险关卡。可取性（Desirability）：客户真的想要它吗？商业可行性（Viability）：它对企业（法务、财务、品牌、销售）是否行得通？技术可行性（Feasibility）：以现有的时间和技术，工程能否把它做出来？可用性（Usability）：人们真的用得起来吗？三人组的设置正是为了覆盖这些：产品负责商业可行性，设计负责可用性，工程负责技术可行性，而可取性是所有人共同的责任。漏掉任何一项，它都会以另一种方式反弹回来（）要么是客户不理会的发布，要么是被法务拦下，要么是工程做不出来，要么是用户根本搞不明白怎么用。

这同样也是自建、购买或合作伙伴决策的思考框架。如果某项能力是你差异化优势的核心，就自己构建；如果它是必需但不具差异性的（如计费、身份认证、邮件发送），就应该强烈倾向于购买或寻求合作，因为你自己构建的每一个功能，都会背负一条永无止境的维护、安全暴露面和认知负担的尾巴。最小可行产品（MVP）是能检验你最大风险假设的最廉价方案，而不是一个你发布之后就丢在一边的精简版 1.0；判断它是否诚实的方法，是问你将从中学到什么，而不只是问你将要发布什么。

认识产品市场契合度，并投资于产品运营

产品市场契合度（product-market fit）是产品满足强烈市场需求的那个时刻，你通常在能证明它之前就已经感受到了：留存曲线趋于平缓而不是逐渐归零，使用量靠口碑增长，客户如果失去这款产品会真正感到懊恼，而你面对的挑战是跟上需求而不是创造需求。在达到契合度之前，你的工作就是去找到它，其他事几乎都不重要；达到契合度之后，你的工作转变为扩展和守护它。把这两个阶段混为一谈（在尚未获得契合度前就开始规模化，或者已经获得契合度后仍在苦苦寻找）是一个经典且代价高昂的错误。

随着产品团队数量的增长，要投资于产品运营（product operations）：共享的调研、数据、工具和实践，让众多团队能够做好发现工作，而不必各自重新发明一遍。产品运营负责让客户访谈的节奏保持人手充足、让分析数据值得信赖、让路线图格式保持一致、让 OKR 的节律持续运转。在正转向产品运营模式的企业中，以及在内部平台拥有真实内部客户的”平台即产品”组织中，产品运营正是让这套模式在数十个团队之间保持连贯、而不是分裂成各自为政的局面的关键。

权衡：优点与缺点

方案	优点	缺点
赋能型产品团队（面向结果）	对结果负责；能找到更好的方案；士气高	需要资深人才和真正的信任；更难自上而下地指挥
功能团队 / 被动接单模式	产出可预期；便于管理和签约	高效地交付了错误的东西；没有人对结果负责
持续发现	每周为赌注去风险；学习速度快；浪费少	需要调研能力和纪律；更难排期
重前期需求分析	对出资方来说更安心；范围清晰	假设未经检验；反馈滞后；存在”大爆炸式”风险
现在/下一步/以后路线图	对不确定性坦诚；保留学习空间	令想要带日期功能承诺的利益相关者感到沮丧
带日期的功能路线图	显得可预期；便于沟通	承诺了你无法确知的事情；奖励产出而非结果
按框架分数排优先级	结构化、可讨论、减少政治博弈	虚假的精确度；可能把一个糟糕的赌注洗白成客观决策

核心张力在于承诺与学习之间的矛盾。预算、合同和高管都希望得到确定的承诺，这会把你推向带日期的功能路线图和重前期需求分析；而好的产品需要发现的空间，这又会把你推向面向结果和持续实验。本指南通篇采用同一种方式来化解这种张力：对问题、结果和时间范围坚定承诺，对具体解决方案保持松散态度。这样既能给领导层他们真正需要的可预期性（在重要事项上取得可衡量的进展），又不会强迫团队去承诺尚未验证的功能。

与团队讨论的问题

你们的产品经理拥有的是一个结果，还是一份待办列表？ 这是揭示团队真实运作方式最有说服力的一个问题。如果产品经理的考核标准是发布路线图、追赶利益相关者的请求、把冲刺排满，那你拥有的其实是一个顶着产品头衔的项目协调员，没有任何人真正对工作是否撬动了某个指标负责。拿出证据来：看看你们产品经理最近三次交付成果，问一问每一次本应改变的客户或业务结果是什么，以及有没有人核实过。在大型组织里，这种代价会成倍放大，因为一个只盯着产出的团队可能会耗费数个季度去构建那些在演示里表现很好、上线后却什么都没改变的功能。这个问题的答案应该重塑你们衡量产品经理的方式，以及你们愿意把多少方案控制权交给团队。如果没有人拥有结果，先解决这个问题，再去争论路线图。
团队里上一次有人和客户交谈是什么时候，是不是这一周？ 持续发现的生死存亡系于这个习惯，而它恰恰是交付压力上升时最先被砍掉的东西（）而那也正是你最需要它的时候。停止和客户交谈的团队不会察觉自己已经”失明”，他们只会开始依赖内部意见和陈旧调研来推理，变得越来越自信，却越来越不准确。拿出真实的记录：数一数你们最近十个功能中，有多少经过了有据可查的假设检验和廉价实验才动工，又有多少是从利益相关者的嘴里直接进了待办列表。对于企业和政府团队来说，一个方向错误的举措可能浪费掉许多个团队季度，在公共部门还会浪费真实的公众信任，因此要明确谁对维持每周客户接触负责。如果诚实的答案是”这周没有”或者”不确定”，那你们其实是在凭假设飞行，却把它称为策略。
要从项目运营模式转向产品运营模式，需要什么条件，是什么在阻碍你们？ 许多企业仍然为临时项目拨款、配置人员、交付、然后解散团队，这会摧毁良好产品工作所依赖的持久所有权和客户知识。转向拥有多年成果所有权的持久团队，包括把内部平台当作拥有真实客户的产品来对待，这是拨款方式、组织设计和治理机制的变革，而不仅仅是换个头衔。拿出证据来：追溯一个当前举措是如何获得拨款和配置人员的，问问项目结束、团队解散之后，积累下来的经验教训会发生什么。与之相对的考量也是真实存在的，因为年度项目预算和采购规则的存在有其正当的问责理由，你必须满足这些要求，而不是无视它们。答案应该找出能证明这套模式可行的最小具体一步（比如让一个持久团队拥有一个结果，配一份稳定的预算），然后再尝试转换整个产品组合（第 10.1 章）。
当我们运行一个优先级框架时，它是在为决策提供信息，还是仅仅在为一个已经做出的决定背书？ RICE、加权评分和延迟成本之所以有用，恰恰是因为它们迫使假设摆到台面上；而一旦某个数字变成停止思考的借口，它们就会变得有害。与之相对的考量也是真实的：框架能减少政治博弈，提供一条大型组织确实需要的可辩护记录，然而信心和影响力这些项目本质上是披着算术外衣的判断，可能把一个糟糕的赌注洗白成一份看起来客观的排名。拿出你们最近几次优先级决策，检查两件事：当策略或客户认知与分数不符时，是否有人推翻过这个分数；以及薪酬最高者的偏好是否悄悄设定了产生这个排名的输入项。在企业和政府场景中，一份打了分的待办列表常常会成为呈现给指导委员会和审计人员的证据，因此要明确谁有权、基于什么理由推翻这个数字，因为一个没人能推翻的框架已经不再是思考辅助工具，而变成了一枚橡皮图章。
我们向利益相关者承诺过哪些带日期的功能，能不能在不失去他们信任的前提下，把这些承诺重新表述为结果？ 带日期的功能路线图给人一种可预期的感觉，但通常是虚构的，因为它把本该由发现过程持续学习的解决方案固定了下来；在大型组织里，每一个这样的承诺都会波及下游团队、营销计划和高管的预期。这种张力是合理的：出资方和利益相关者出于预算和问责的理由需要确定性，所以你不能简单地拒绝做出承诺；你需要在结果和时间范围的层面提供可预期性，而不是在尚未验证的功能层面。拿出当前的路线图，把每一项标记为你能够承诺的结果，还是你在赌的具体方案，然后起草如何把这些”赌注”重新表述为现在/下一步/以后式的问题。对于受年度预算和采购里程碑约束的企业和公共部门团队，要区分哪些承诺是真正具有合同约束力的，哪些只是出于习惯（）习惯性的那部分正是你可以用诚实的方向换掉虚假精确度的地方，而合同约束的那部分则必须去协商，把承诺定在结果层面，而不是功能层面。
我们在哪些地方构建的是本可以购买或寻求合作的、不具差异性的能力，这由谁来决定？ 你自己构建的每一个功能，都背负着永无止境的维护、安全暴露面和支持负担，所以自行搭建计费、身份认证或邮件发送系统，会把你最稀缺的产能耗费在无法体现差异化的工作上（第 10.4 章）。与之相对的考量是：“购买”用速度和更低的自持成本换来了控制权和贴合度的牺牲，而有时候你以为是商品化的能力，其实恰恰是你优势的核心，因此可取性，商业可行性，技术可行性，可用性这个框架必须被诚实地运用，而不是被当作偏好的遮羞布。拿出一份清单，列出你们团队目前在自行构建的东西，标记每一项是核心差异化因素还是不具差异性的基础设施，并估算这些基础设施持续拥有的成本，与供应商替代方案相比如何。在企业和政府场景中，要把采购规则、数据驻留与安全要求，以及供应商锁定和退出条款也纳入考量，因为在这些场景中，自建，购买，合作的决策不仅仅是一个工程权衡，更是一个合规与问责问题，负责这项决定的人应该能向审计人员为这个选择辩护。

行业视角

初创企业。 跑道有限时，发现工作是生存所需，而不是走流程。一位创始人身兼产品职责，不讲排场地每周和客户交谈，并在让工程师投入构建之前，运行成本最低的测试（一个”假门”按钮、五次访谈）。跳过重型框架和带日期的路线图；整个公司都能把策略装在脑子里，所以把纪律用在拒绝构建那些嗓门最大的请求上，直到有人说清楚问题和衡量指标。

小型企业。 你没有专职产品经理，所以产品思维是老板或某位主力工程师在其他职责之外维持的一种习惯。让大多数自建还是购买的决定倾向于购买：预订、支付、邮件这类不具差异性的能力应该交给供应商，把你稀缺的注意力留给真正能赢得客户的那一两件事。维护一份轻量的现在/下一步/以后清单，而不是正式路线图，并把一个领先指标（回头客数量、爽约率）当作你的结果，而不是搭建一整套 OKR 体系。

企业。 这里的工作是在不让模式分裂的前提下协调众多产品团队：持久的三人组拥有各自的结果，路线图格式保持一致，产品运营让访谈节奏、分析数据和 OKR 节律在数十个团队之间保持连贯。治理和审计需要可追溯性，因此要让结果、优先级排序的依据和”砍掉”决策都清晰可查，而不是退回到那种能取悦委员会、却奖励产出而非影响力的带日期功能承诺。要有意识地管理从项目拨款到产品运营模式的转变，因为组织设计和预算编制的变化速度比换头衔要慢得多。

政府。 采购规则、透明度和公共问责塑造着每一个选择。为持久的服务团队拨款，而不是为固定范围的项目拨款；把成功定义为可被监督机构核实的公民结果（申请所需时间、自助服务完成率）；把以用户为中心的设计和无障碍标准当作硬性要求，用真实的申请人，，包括使用辅助技术的用户，，来测试。公开发布结果和进展，让外部审查能看到公共价值；围绕数据可携带性和退出机制来构建自建，购买决策和供应商合同，这样今天的供应商选择就不会变成十年的锁定。

示例

初创企业。 一家六人规模、为独立诊所打造排班工具的初创公司，顶住了构建三位反馈最强烈的客户不断要求的”在线预约”大功能的诱惑。兼任产品经理的创始人转而做了一周的发现工作：五次诊所主访谈、营销网站上的一个”假门”按钮，以及一个领先指标（以爽约收场的预约比例）。证据表明，真正的痛点是爽约，而不是预约本身，于是团队把一个结果作为目标（本季度将试点诊所的爽约率降到 10% 以下），发布了一个小型的”押金+提醒”MVP 来检验风险最大的假设，并在写下一行代码之前就砍掉了预约功能。路线图是一份现在/下一步/以后清单，而不是带日期的计划，整个团队都能凭记忆讲出上周和客户的通话内容。

企业。 一家零售银行把其支付团队从项目模式转向产品模式：一个持久的三人组（产品、设计、工程）拥有”日常支付体验如丝般顺滑”这个长期存在的结果，配有稳定的年度预算，而不是一系列临时立项的项目。团队每周进行客户访谈，维护一棵机会，方案树，用 RICE 为候选方案排序，但在延迟成本分析显示某个延迟修复更为重要时推翻了这个排名，并向利益相关者发布现在/下一步/以后路线图，而不是带日期的功能承诺。两个提议的功能因为未能撬动领先指标而在发现阶段就被砍掉，估计节省了两个季度的构建工作量；产品运营则让访谈节奏和分析数据在该银行的十五个产品团队之间保持可信、连贯。

政府。 一家正在现代化福利申请系统的国家机构，采纳了各数字化服务团队所倡导的公共部门产品思维：它为一个持久的服务团队拨款，而不是一个固定范围的项目，并把成功定义为公民结果（将申请所需的中位时间从 40 分钟缩短到 15 分钟，把自助服务的成功完成率从 55% 提高到 85%），而不是已交付的模块数量。以用户为中心的设计没有商量余地：团队在每次发布前都会与真实申请人（）包括使用辅助技术的用户（）进行有主持人引导的可用性测试，并把无障碍标准当作硬性要求。由于路线图以结果为框架，团队又拥有该服务多年的所有权，监督机构看到的是可衡量的公共价值，而不是一份支出报告，该机构也因此能够尽早交付有用的能力，而不是把一切都押在遥远的某个上线日期上（第 11.1、5.1 章）。

商业理由：动机、投资回报率与总拥有成本

真正的产品管理带来的回报，主要体现在避免浪费上。大型科技公司的对照实验项目一再发现，已构建功能中有很大一部分（）常被引用的数字约为一半（）没有产生可衡量的改善，甚至对目标指标产生了负面影响。如果哪怕四分之一的团队产能被用于持续发现本可以廉价扼杀的想法，那么这项纪律带来的回报就足以多次收回成本：一周的客户访谈和一次”假门”测试的成本，相对于一个季度的工程投入，以及一个没人使用的功能永久性的维护成本而言，几乎可以忽略不计。功能工厂的主要成本，不在于它发布了哪些功能，而在于它从未撬动的那些结果所带来的机会成本。

在总拥有成本方面，每一个已发布的功能都是一项长期负债：维护、测试、安全暴露面、支持负担，以及每个必须在产品中摸索前行的人所承受的认知负担（第 10.4 章）。产品管理通过两种方式降低这项成本：它在发现阶段就扼杀掉糟糕的想法，不仅省下了构建成本，也省下了整条拥有成本的尾巴；它还引导自建（购买）合作决策倾向于购买不具差异性的能力，从而让团队有限的产能投向真正能带来差异化的地方。从项目运营模式转向产品运营模式还带来了一项更微妙的额外回报：持久团队保留了客户知识和代码库背景，而这些正是项目团队每次解散重组时都会丢失的东西。

要向领导层论证这一点，把对话从”我们发布了多少”转变为”我们撬动了多少真正重要的指标”，并展示两三个花费不菲却没有撬动任何指标的具体功能案例。采用这套做法的成本并不高：调研能力、一个发现节律、一份以结果为导向的路线图，以及在动工之前先定义成功标准的纪律。而不投资的风险是无声的、无从统计的、却在不断累积的，因为功能工厂看起来一直很有生产力（）直到你发现业务其实纹丝未动。

反模式与陷阱

功能工厂： 把成功定义为”我们把它发布了”，速度受到追捧，而业务指标却纹丝不动。
产品经理沦为项目经理： 负责的是日程表和工单队列，而不是问题和结果。
产品经理沦为功能秘书： 把利益相关者的请求原样转录进待办列表，既没有问题、也没有衡量指标。
路线图沦为带日期的功能承诺： 在你尚无法验证的特定季度，承诺交付特定的解决方案。
发现沦为一次性阶段： 前期做一次发现冲刺，之后数月只顾构建，不再接触客户。
由 HiPPO 主导的优先级排序： 薪酬最高者的意见凌驾于证据之上，框架沦为为其背书的表演。
框架崇拜： 把 RICE 或加权分数当作真理，让虚假的精确度把一个糟糕的赌注洗白。
构建不具差异性的基础设施： 自行搭建供应商本可以提供得更好、更便宜的计费或身份认证系统。
在获得产品市场契合度之前就开始规模化： 把钱大量投入增长，而市场其实还没有真正强烈地渴望这款产品。
内部平台没有产品负责人： 平台团队构建的是自己觉得有意思的东西，而不是其内部客户真正需要的东西。

成熟度模型

第 1 级，启动： 产品管理是被动接单和反应式的。一份带日期的功能路线图被自上而下地交办下来，成功就是把它发布出去。没有明确的结果，没有定期的客户接触，也没有人对工作是否撬动了某个指标负责。
第 2 级，发展： 基本的产品实践开始出现，但各团队之间并不一致。部分团队有了结果和 OKR，但目标往往仍是产出导向的，路线图仍然是功能清单。发现工作偶尔发生，通常作为一个前期阶段；优先级排序使用某种框架，有时只是给嗓门最大的声音充当掩护。
第 3 级，标准化： 被赋能的三人组拥有各自的结果，这种实践在整个组织内都有文档记录，并被普遍期待。路线图变成了现在/下一步/以后式的意图声明；持续发现是一项配有人手、每周进行、有据可查的假设检验习惯；优先级框架为判断提供参考，而不是取代判断；产品市场契合度被理解并被作为共享标准来追踪，而不再是某个团队的局部习惯。
第 4 级，管理： 这项实践相对于基线被衡量和控制。每个团队都会对照既定基线追踪领先和滞后的结果指标；每个功能上线后，都会对照一个预先登记的成功指标进行检查，并根据证据（而非意见）执行”砍掉”阈值。发现工作的健康度也被量化监测（访谈节奏是否达标、构建前假设是否经过检验、在发现阶段被砍掉的想法与已发布的想法之比），产品市场契合度的信号（）如留存曲线和”若失去会感到懊恼”的比例（）被量化，RICE 中的信心等框架输入项也会依据实际结果进行校准。
第 5 级，编排： 一套产品运营模式在整个产品组合范围内运行，并与拨款和策略持续整合、持续改进。持久团队拥有多年的结果所有权，内部平台被当作产品来管理；发现与交付持续循环往复；结果数据引导投资决策，自适应地重新平衡产品组合；产品运营让这套实践在整个规模上保持连贯；领导层管理的是一个结果组合，随着证据和市场变化，常态化地淘汰、重新界定范围、重新排序各项赌注。

讨论话题

看看你们当前的路线图：有多少项陈述了可衡量的结果，而不只是一个功能加一个日期？
团队里谁对客户关系的了解足够深入，能凭记忆讲出上周的对话内容？
如果先对风险最大的假设做一次廉价实验，你们最近的哪些功能会被砍掉？
你们在哪些地方构建着本可以购买或寻求合作的不具差异性的能力，这让你们付出了什么代价？
你们是否已经获得了产品市场契合度？你们要如何真正判断，而不是靠假设？
迈向产品运营模式，你们能迈出的最小一步是什么，又有什么治理障碍挡在路上？

关键要点

产品管理拥有的是是什么和为什么的所有权，对结果负责，而不是负责协调任务或转录请求。
通过在动工之前把成功定义为客户或业务行为的可衡量改变，来摆脱功能工厂。
让持续发现与交付并行：每周和客户交谈，用成本最低的实验检验风险最大的假设（第 11.1 章）。
把优先级框架（RICE、加权评分、延迟成本、Kano）当作判断的辅助工具，绝不能当作神谕。
把路线图当作意图声明（现在/下一步/以后）：对问题和结果坚定承诺，对解决方案保持松散。
赋能三人组，在投入资源之前验证可取性、商业可行性、技术可行性和可用性（第 5.1 章）。
在企业和政府场景中，从项目运营模式转向产品运营模式，为服务而非项目拨款，并投资于产品运营（第 10.1、11.4 章）。

参考资料与延伸阅读

Marty Cagan, Inspired and Empowered（关于被赋能的产品团队和产品运营模式）。
Marty Cagan and Chris Jones, Transformed（关于转向产品运营模式）。
Teresa Torres, Continuous Discovery Habits（关于机会-方案树、每周客户接触）。
Melissa Perri, Escaping the Build Trap（关于结果重于产出、产品运营）。
Roman Pichler, Strategize（关于产品愿景、策略与路线图）。
C. Todd Lombardo, Bruce McCarthy, Evan Ryan, and Michael Connors, Product Roadmaps Relaunched（关于现在/下一步/以后式路线图）。
Dan Olsen, The Lean Product Playbook（关于产品市场契合度）。
Eric Ries, The Lean Startup（关于最小可行产品、构建-衡量-学习）。
Noriaki Kano et al., “Attractive Quality and Must-Be Quality”（Journal of the Japanese Society for Quality Control, 1984）：Kano 模型的起源。
Melissa Perri and Denise Tilles, Product Operations（关于规模化产品实践）。
U.S. Digital Service, Digital Services Playbook; UK Government Digital Service, Government Design Principles and Service Standard（关于公共部门、以用户为中心的产品交付）。