赋能 EMPOWERED — Ordinary People, Extraordinary Products

核心主张：最好的公司与其余公司的差距，"既根本又触目"，但它不止于"产品文化"——文化各异的四家公司（亚马逊、谷歌、苹果、奈飞）恰恰在"最重要的要素"上高度一致。卡根把差距归结为三条：① 公司如何看待技术的角色；② 产品领导扮演的角色；③ 公司如何看待产品团队的目的（产品经理、产品设计师、工程师）。

围绕这三条，他给出本书的核心对照——功能团队 vs. 被授权的产品团队：

• 功能团队：表面也跨职能（一个做着项目管理的产品经理 + 一个设计师 + 若干工程师），但被指派的是"要造的功能与项目"（output 产出），只对交付负责，无法对业务结果担责——"就算有人抱怨没有业务成果，你能追究谁？"
• 被授权的产品团队：同样跨职能，但被给到的是"要解决的问题"，并被授权"用自己认为最好的方式去解决"，然后对结果担责。

在这个模型里，产品经理负责确保方案有价值（valuable，客户愿买/愿用）且可行于商业（viable，满足业务需要）；设计师负责可用（usable）；技术负责人（tech lead）负责技术可行（feasible）。四类风险（价值、可用、可行、商业可行）由三个角色共同覆盖，共同拥有问题、共同担责。（卡根在脚注里点明：还有第三种团队——纯产出的"交付团队/Scrum 团队/dev team"，只有 product owner + 工程师，连产品团队都不假装；若你在跑 SAFe，"我实在不知道你为什么要读这本书"。）

最精彩的细节：作者抛出一条"产品探索的第一原则"——我们的客户和利益相关者无法告诉我们该造什么。不是因为他们不聪明，而是两个根本原因：① 他们不是使能技术的专家，不知道"现在刚刚变得可能"的是什么，因此无法判断最佳解法、甚至无法判断问题是否可解；② 技术产品极难事先预测哪种方案会奏效（客户可能不买账、可能撞上隐私/安全问题、可能远比预期更难造）。所以才叫"探索"（discovery）——承认我们无法预知，任务是去探索出一个客户爱、又对业务奏效的方案。

关键前提：一条贯穿全书的人物线索——传奇教练 Bill Campbell 曾亲自为苹果、亚马逊、谷歌的创始人做高管教练。卡根最爱引他的一句话："领导力，是认识到每个人身上都有伟大之处，而你的工作就是创造一个让那份伟大得以涌现的环境。" 这本书要识别的，正是"什么造就了这样的环境"。

核心主张（本书唯一一章作者承认要"稍微哲学一点"）：差距虽"一眼可见"，却没解释为何存在；要弥合差距就得看根因。根因在于对技术角色的根本分歧——大多数公司把技术当作"必要开支"（能外包更好），骨子里不认为自己在"做技术生意"，于是技术团队的存在是"服务业务"（serve the business，常常是原话）；而强产品公司里，技术不是开支，技术就是业务本身，技术团队的目的是"通过创造客户爱、又对业务奏效的产品来服务客户"。

最精彩的真实案例：作者用一连串行业例子做论据，其中最尖锐的是波音 737 MAX——把飞行控制软件当作"可省几个钱的成本"外包出去（脚注引彭博：外包给"时薪 9 美元"的工程师），而不是用一支被授权的产品团队持续打磨"最安全、最省油的关键控制软件"，这是其灾难的根本错误。正面对照是特斯拉：技术在汽车核心、加上 OTA 空中升级，一辆特斯拉竟会随时间变好而非单纯贬值——"请你为此停顿片刻想一想。"还有皮克斯：技术团队与创意团队同等被重视，让电影业看见技术在核心时的可能性。

作者还讲了一个反复发生的"晚宴场景"：当某位 CEO 说"我们不是科技公司，我们是保险/医疗/农业公司"，他会回敬——"让我告诉你，如果我是亚马逊或苹果的产品领导，决定杀进你这个又大又未被满足的市场，我会怎么做。"讲完打法后他点破：竞争上，我们就赌你回应不了，因为你正忙着保护你的旧生意。 一个反直觉的事实是：这些"不开窍"的公司往往在技术上花得比该花的多得多——"我从没见过比这些不懂技术真正角色的公司更多的技术投资浪费。"

关键推演：一个常被低估的组织信号——工程师究竟向 CIO（IT 负责人） 还是 CTO（工程负责人） 汇报。CIO 这个岗位"本身就是为服务业务而设"，"让强 CIO 之所以强的那些特质，恰恰可能拖垮公司的转型"；而公司未来所依赖的"产品工程师"，往往不愿为 CIO 工作，因为他们深知这种心态差异极其重要。卡根的处方：要么让够格的 CIO 改称 CTO 扛起更大角色，要么直接请一位真正的 CTO 来领导产品工程。

核心主张：本书的核心就是"强有力的产品领导"。卡根把它拆成"领导"与"管理"两类职责——领导求激励（inspiration），管理求执行（execution）——并明确：走向被授权的团队，不意味着需要更少的领导和管理者，而是需要更好的。（他特意纠偏一个误解：命令-控制式管理其实更省事，丢给团队一张功能清单催他们快点干即可，但那制造的是一群没有任何实质授权的"雇佣兵"。）

领导的四项显性职责：① 产品愿景与原则（描述 3–10 年后我们要创造的、能改善客户生活的未来，是组织的"北极星"，也是"招募强产品人最强大的工具"；原则则是面对艰难权衡时帮团队做对决定的价值观与若干战略取舍）；② 团队拓扑（如何切分团队以利做出好工作）；③ 产品战略（聚焦 focus → 借力洞察 insights → 转化为行动 action → 管理 manage 到完成）；④ 产品布道（evangelism）。

管理的三项关键职责（落在"一线带人经理"身上——"如果世上有那么多弱产品公司，这就是首要元凶"）：① 配备人员 staffing（招募、面试、入职、评估、晋升，必要时替换；HR 只是支持，绝不能替代经理）；② 教练 coaching（"最重要却最常被忽视的一环"，至少每周一次 1:1）；③ 团队目标 team objectives（每季给团队一两个清晰、源自产品战略的"要解决的问题"）。

最精彩的论据：① 关于布道，作者引著名风投 John Doerr 的话——"我们需要的是传教士团队，不是雇佣兵团队（teams of missionaries, not teams of mercenaries）"——并强调布道"永远没有'做完'的一天，必须持续不断"；他举的例子很具体：若愿景是造大众市场电动车，可以雇对"怎么实现"有不同看法的人，但不该雇一个内燃机的狂热拥护者。② 关于教练，他用设计经理带 6 个分属不同团队的设计师作例：每个设计师再优秀，也无法盯住其他所有团队在做什么——经理的职责正是发现这些冲突、把相关设计师拉到一起看全局（即所谓"连点成线"connecting the dots）。③ 关于授权，他给出授权的试金石：团队能自行决定解决被指派问题的最佳方式——"这需要足够自信、足够安全感的强经理，肯退后一步、让团队去领功劳。"

核心主张（一个短章，几句话讲透）：被授权团队的好处"并非秘密"，书和文章一大堆，可大多数公司就是没被说服去真正授权——为什么？卡根问遍 CEO 和关键领导后，答案归结为一个词：信任（trust）。领导不信任团队，具体说是不相信自己手里有能被授权的人才，于是和各业务头头一起"亲自、明确地指挥团队"，也就是命令-控制。

最精彩的反驳：当问"那你为什么不换上你信得过的人"，他们总说找不到、请不起、也吸引不来谷歌/亚马逊/苹果/奈飞那个级别的人。卡根的回击有两层：① 他认识许多从这类公司跳去那几家顶级公司、表现随之大幅跃升的人；② 他与这些顶级公司的许多人共事过，深知这些团队里绝大多数人其实相当普通。于是真正的差别也许不在人本身——"也许这些强公司只是在如何撬动人才上有不同的看法，从而帮普通人触及真正的潜能，一起造出非凡的产品。"（这句正是第二部分"教练"的引信。）

核心主张（结构性短章）：既然强产品公司的关键是强产品领导，那他们究竟长什么样、跟着他们干是什么体验？延续《INSPIRED》侧写六位"幕后产品经理"的做法，《EMPOWERED》侧写八位产品领导——两位产品管理领导、两位产品设计领导、两位工程领导、两位公司领导，"个个在标志性产品公司有过非凡履历，却大多默默无闻"。卡根不写完整传记，而是请他们用自己的话讲通往领导岗位的旅程，让读者体会"与一位强而有经验的产品领导共事、为其工作是什么感觉"。（侧写正文本身不在本片段内。）

核心主张（导航章）：本书面向产品领导与有志成为产品领导的人，尤其是产品经理、产品设计师、工程师这三类人的领导。书聚焦三个核心角色——PM、设计师、工程技术负责人（tech lead）；其中给 PM 及其领导的篇幅最多，因为转向被授权团队时，PM 这个角色离它该有的样子通常最远。

两点值得记的交代：① 作者之声——除非特别说明，叙述者要么是 Marty Cagan、要么是 Chris Jones（两人都是 SVPG 合伙人），不标注谁写哪章，因为"我们都认同书里每一句"；之所以用第一人称，是想尽量逼近"坐下来与你做一对一教练谈话"的体验。② 全书结构预告——第二部分=教练（coaching，全书最长，刻意为之）、第三部分=配备人员（staffing）、第四部分=产品愿景与原则、第五部分=团队拓扑、第六部分=产品战略、第七部分=团队目标、第八部分=案例研究、第九部分=与业务的协作、第十部分=组织转型计划。

核心主张：本章不谈"被教练的人"，只谈你作为教练所必需的心态——因为"错误的心态会让你把这些工具用成违背其本意的样子"（例如你坚持做每周 1:1，但谈的全是派活和排优先级，那它"不仅无益，甚至有害"）。卡根用 Bill Campbell 一段话给"教练"下定义：导师（mentor）只是"发放智慧的金句"，而教练"会卷起袖子、亲自下场"——"他们举起一面镜子让我们看见自己的盲点，逼我们直面痛处……他们为'让我们变得更好'负责，却不抢走我们的功劳。"

展开的七条心态准则：① 培养人是头号工作（Developing People Is Job #1）——你应把大部分时间精力花在教练团队上，并用团队成员的成功、而非产品的成功来衡量自己的绩效；② 授权才出最好结果——授权意味着"创造一个让人能拥有结果而不只是任务的环境"，这"不是更少管理，而是更好管理"，你要退后留出空间、同时挺身移除障碍/澄清语境/给予指导；③ 警惕你自己的不安全感——没安全感的经理会把团队的成功视为对自己的威胁（"傲慢本身常常就是不安全感的表现"）；④ 培育多元观点；⑤ 寻找教学时刻——"触及潜能需要穿越逆境"，你要找到能制造适度不适、又量体裁衣的机会；⑥ 持续赢得团队的信任——靠行动而非索取，"公开表扬，私下批评"；⑦ 有勇气纠正错误——这是"对许多经理最难的一条"，但当你确知某人不适合时，"别等（when you know, don't wait）"，拖着只会同时伤害你、团队和当事人。

最精彩的细节：作者给出一个"经理不是教练时怎么办"的现实方案。设想一支跨职能团队都汇报给一位来自商务拓展（BD）的总经理，她从没做过 PM、设计或工程——她怎么教练下属？卡根的答案是：让经理当教练只是首选，做不到时仍可有效教练——关键是组织里必须有人被明确指派去提供必要的教练（比如请另一个部门的设计经理来教练这位设计师），并确保"产品团队上的每个人都知道，到底是谁被指定来帮她成长、触及潜能"。（Chris 在此处插入亲历：他早年所在的公司"把教练价值观刻进了文化"，让他在一级级升任管理岗时始终有清晰的框架。）

核心主张：本章给出一个把人"教练到胜任"的起点工具——以差距分析（gap analysis）形式做的技能评估：沿若干必要维度，评估这个产品人当前的能力，再与该岗位应有的水平对照。它承认"并非所有技能同等重要、并非所有差距同等显著、期望会随责任层级而变"，目的是把注意力聚焦到最需要的地方。卡根以产品经理为例（设计师/tech lead 可微调），技能分类沿用《INSPIRED》的三支柱——人、流程、产品（People, Process, Product），并先讲"产品"，因为产品知识是一切的地基。

技能分类（三支柱）速记：

• 产品知识（属"入场门票 table stakes"，新 PM 通常需 2–3 个月、每天数小时才能补齐）：用户/客户知识、数据知识、行业与领域知识、业务与公司知识、产品操作知识。
• 流程技能与技术：产品探索（discovery）、产品优化、产品交付、产品开发流程。
• 人际技能与职责：团队协作、利益相关者协作、布道、领导力。

最精彩的方法细节：差距分析的做法是给每项技能打两个分——期望分（expectations，这岗位需要到几分） 与 能力分（capability，此人现在几分），按 1–10 打分（10 = 对该岗绝对必需）。例：若"产品探索技术"期望 8、而该 PM 当前能力仅 4，"这就是一项关键技能上的显著差距，你得动手教练了"。配套的教练计划只先聚焦差距最大的前三项；并且至少每周坐下来一次复盘进展。一条立场鲜明的提醒：期望分由经理（或组织）设定，主要功夫花在评能力分上；可以让 PM 做自评（作者鼓励），但一个只依赖自评、因为不敢直面认知分歧的经理，"在我看来是放弃了管理者的职责"。

关键边界：评估≠绩效考核。卡根直言"大多数公司的绩效考核对发展人几乎没用，更多是 HR 合规与薪酬管理"；你也许得照 HR 要求走年度考核，但它"绝不能替代"积极、持续、投入的教练。一个微妙提醒：为晋升做准备 ≠ 能授予晋升——许多公司有晋升政策，所以对员工的措辞应是"我会尽全力让你准备好、并为你的晋升奔走，但无法保证晋升何时发生"。

核心主张：上一章定位了差距，本章讲怎么逐项教练填平这些差距。卡根坦言"这份教练计划的完整版其实就是整本书"，本章给的是足够多的范例与建议，沿用同一套"人/流程/产品"分类（仍以 PM 为例）。

每一类的可操作打法（密度优先，挑最精彩的留住）：

• 用户与客户知识：先借同事之力（用户研究团队是他"最爱的起点"，客户成功/客服、产品营销、创始人/CEO 都是资源），再亲自下场。最精彩的真实故事：Marty 接手一个全新 B2B 产品时，他的经理要求他先拜访 30 个客户——而且坚持一半要来自美国之外——才允许做任何有意义的决定。"我不认为 30 这个数字有什么特别，但我能告诉你它绝不是 2、3 个。" 他通常建议新 PM 入职期至少拜访 15 个客户；那趟回来后，他"从几乎一无所知，变成了组织里懂得最多的人"，并把这些关系受用了好几年。每次接触至少要弄清：客户是不是你以为的那群人？他们有没有你以为的问题？今天怎么解决？要让他们切换得付出什么？
• 数据知识：通常要掌握三类数据/工具——用户分析、销售分析、数据仓库（看随时间变化）；既要会"用工具答问题"，更要"读懂数据想告诉你什么"；数据分析师是来教会并赋能你自己答问题的，不是给你派活的。
• 行业与领域知识：多数领域一搜即得；高度专门的领域（税务、外科器械、合规）通常有内部领域专家（SME）可建立关系。一个具体教练动作：让 PM 评估赛道内前 3–5 名玩家，写一篇对比其优劣、点出机会的叙述（narrative）。
• 业务与公司知识（"对多数新 PM 工作量最大，却常是胜任与否的本质差别"）：让新 PM 给自己的产品填一张商业模式画布（business model canvas），快速暴露盲区；再逐块吃透 go-to-market（在产品营销同事处学）、财务（"在财务部交个朋友"，搞懂 LTV 等 KPI 怎么算、自己产品处于什么水平）、法务（隐私/安全/合规/伦理）、商务拓展（合作协议带来的约束）。脚注还点了电商等"附加领域"——电商公司有商品/选品（merchandising）、媒体有编辑、硬件有制造、全球化有国际化。
• 产品操作知识：PM 必须是自己产品的专家级用户（手段含读文档、上培训课、泡客服、坚持 dogfooding 自用产品）。litmus test：若重要行业分析师来访谈你的产品，要么 PM 亲自讲，要么至少花大量时间帮主讲人（通常是产品营销经理）备稿。

流程与人际的要点：流程上，新 PM 至少要懂四类产品风险（价值/可用/可行/商业可行）与各类原型、定性定量验证；优化靠学一种工具跑 A/B；开发流程他建议新 PM 上 CSPO（认证 Scrum 产品负责人） 课——但反复强调"CSPO 的职责只是 PM 职责中很小的一个子集，太多 PM 只受过 CSPO 训练，却不懂自己为何失败"。人际上，区分"称职 PM"与"真正高效 PM"的往往是人际技能（"但他们得自己想变好"，否则经理就该帮他另谋更合适的岗位）；作者教练协作的方式是坐进 PM+设计师+tech lead 的真实会议去观察互动，会后单独把 PM 拉到一边复盘哪句话帮了/伤了信任——"一小时讨论一个问题或目标，通常能产出许多可用作教练的好例子。"

两段特别的角色教练：① 教练 tech lead——"我爱极了"，tech lead 是"承担起参与持续产品探索职责的资深工程师"，是 PM 与设计师的关键搭档，被要求不仅关心怎么造、更关心造什么；"深厚技术 + 对客户痛点的直接理解结合时，会有魔法发生"。卡根鼓励 tech lead 多拜访客户、甚至考虑做一两年 PM 再回工程（为日后创业铺路），并断言"你花在教练 tech lead 了解客户或业务上的每一分钟，都是时间最好的用法之一"。② 教练产品设计师——设计师"活儿尤其难"，要在服务/交互/视觉/工业设计、原型、用户研究等多面有广度；设计经理还是"确保设计整体性"的前线（跨团队让体验作为一个整体成立）。一个转型期难点：来自功能团队的 PM 和工程师从没与专业产品设计师共事过，根本不知道自己缺了什么，所以设计领导往往要"抬高标准、教育 PM 和 tech lead 何为强设计"。

备注：本章末尾整段嵌入了 SVPG 合伙人 Martina Lauchengco 即将出版的《LOVED》节选（产品营销主题，含"Company Z"案例：一群 PhD 技术惊艳却两年没卖出几单，直到产品营销总监 Josie 用一份白皮书把他们定位进一个自己命名的细分品类、三个月扭转局面）。卡根用它佐证"产品营销已变得比以往更关键"，与本书主线相邻而非主线，故此处只点到为止。

核心主张：1:1 是教练的地基——但卡根判断你"很可能从没体验过做得好的版本"。它写给"带一线产品个体贡献者的经理"。

做好 1:1 的关键要素：① 目的——"首要是帮这个人发展和提升"，会顺带听更新、聊工作，但"一旦失了目的，这次谈话的真正价值就迅速流失"；② 关系——建立在信任上，"她若被提拔，是你做对了；她若达不到胜任，是你失败了"；③ 入职期——新人有 2–3 个月需密集监督，"在她够格之前，确保她不伤害团队、做出合理决策是你的责任"；④ 频率——他"强烈认为"1:1 不少于每周一次、每次至少 30 分钟，且这次谈话是神圣的，"可以偶尔改期，但别取消——想想取消传递了什么信号"；新人入职期可一周两三次甚至每天；⑤ 共享语境——给她公司使命与年度目标、产品愿景、产品战略、本团队目标（即下一章的"战略背景"）；⑥ 作业（Homework）——"没有任何东西能替代产品人做自己的功课"，你能指路、答疑，但花时间是她的事；⑦ 像产品人那样思考与行动——思考=聚焦结果、权衡四类风险、整体看业务、撬动工程/设计/数据；行动=倾听、协作、布道、把功劳给出去、把责任揽过来、承认自己不知道、建立跨公司关系、亲自认识客户、做领导；⑧ 整体视角（连点成线）；⑨ 给反馈——也叫"严厉的爱/坦率直言（radical candor）"，"反馈要频繁、尽可能及时（第一个能私下谈的机会）"，"逼自己每周都想出一些有帮助的建设性反馈"；⑩ 持续改进——"这是旅程不是终点，你有 25 年经验仍在学"。

最精彩的部分：本章后半的反模式清单极其锋利，几乎每条都对得上现实里失败的经理——"经理就是不在乎"（最大的元凶，把带人当次要任务，等于告诉员工"你自求多福"）、"经理退回去微观管理"（更省事，但不可规模化、培养不出我们需要的人）、"经理光说不听"（"这场谈话主要是为产品人，不是为你；很容易你一口气讲 30 分钟然后没时间了"）、"经理不给难听的反馈"（后果是绩效考核上员工被负面评价惊到——而卡根立下铁律："在绩效考核上，任何事都不该是惊讶；一切都应该早已深谈过、很可能谈了好几个月。"）、"经理自身不安全/不胜任"、"经理不肯止损"（最后手段：若三到六个月内仍带不到胜任，"你有责任帮这个人去找一份他能成功的工作"）。卡根用一句话收束全章给产品领导："对产品领导而言，产品团队就是我们的产品——这就是我们打磨好产品的方式。"

核心主张：这是卡根"最偏爱的、让产品人变卓越的教练工具"，却也是"所有技术里招致最多抵触的一个"（"我不止一次得几乎逼着人去用它"）——因为它常常很痛，而"最需要它的人往往最抗拒"。它不是 spec（spec 只描述要造什么，不为说服）；而是一份约六页、以叙述形式写清"你要解决什么问题、为何对客户和业务有价值、你解决它的策略"的文档——"若写得好，读者会既被激励、又被说服"。

最精彩的论据/案例：把这套写到极致、作为运作与创新核心的公司是亚马逊——"他们比我所知的任何公司都更彻底地拥抱了这一技术，我不认为他们能成为全球最持续创新的公司之一是巧合。"书里引前 Netscape 工程师、资深亚马逊人 Brad Porter 的话："速度与规模是武器，而亚马逊早已把它的秘密告诉了所有人……只要他们有纪律去落实它。" 与之对照的是熟悉的失败画面：在 kickoff 会上甩一份 PPT、挥挥手、抛几个数据点、显得热情自信，然后会议沦为"委员会式设计"，或更糟——大家一受挫就转头听屋里薪水最高的那个人。卡根一针见血：当这种事发生，说明"产品人没做功课、不真懂这个话题、论证很弱"——而书面叙述会把这一切暴露出来，"在它面前无法蒙混（no faking it）"。

关键结构与推演：叙述正文几页 + 一份 FAQ——预先设想关键高管和利益相关者会有的顾虑与反对，写好清晰答复并事先与持这些顾虑的人逐一过一遍；待高管真正读到叙述时，"她能看出你已预判了问题、想好了回应，知道你做足了功课"。这也解释了为何作者把 1:1 放在前面讲：很少有产品人有纪律独自完成书面叙述、独自直面论证里刺眼的漏洞，"但经理可以教练产品人走过这个过程"。作者现身说法：他自己每写一篇新主题演讲，都强迫自己先写一份完整叙述、反复打磨到逻辑通且有说服力、拿给会对他讲真话的人测试，然后才去做演示——"我从此成了它的信徒。"

核心主张：教练的另一面，是确保产品团队理解他们身处的更宏观的业务背景——卡根称之为"战略背景（strategic context）"。一句话逻辑贯穿全书：产品团队若要被授权去做决策，就必须拥有做这些决策所需的背景；这背景通常来自公司的产品领导，但必须被产品团队、尤其是 PM 深刻理解，通常作为任何新产品人入职的一部分。（他提醒：超大公司可能有多个业务单元各有不同的战略背景——例如谷歌的 YouTube 业务单元与 AdWords 业务单元就很不一样。）

最精彩的展开——六类战略背景层层向下：① 公司使命（Mission）——公司存在的"为什么"，简单且持久（常达十年以上），"若有员工不知道公司使命，那就是文化或领导出了严重问题的明显信号"；② 公司记分卡（Company Scorecard）——一组判断业务整体健康的关键 KPI（也叫 dashboard / health metrics），他用双边市场（two-sided marketplace）举例：一个招聘市场若每天涌入成千上万求职者却几乎没有职位，求职者就会受挫离开，所以要为求职者和雇主各设一个漏斗、各盯关键指标；③ 公司目标（Company Objectives）——由高层（常有董事会参与）选出的年度最重要焦点，"必须是结果（outcomes，业务结果），而不是产出（output，如交付某些项目）"，其关键结果几乎总是记分卡上的 KPI；④ 产品愿景与原则——使命给"为什么"，愿景（3–10 年）把它变得可触摸，也是"招募强产品人的最佳工具"，原则则照亮"做权衡时我们优先什么价值"；⑤ 团队拓扑——每支团队负责什么、在大图里坐在哪、与其他团队怎么关联；⑥ 产品战略——"事情开始变具体的地方"，它把"年度公司目标 + 多年产品愿景 + 多支各有专长的团队"连接起来，并最终驱动每支团队的目标。

关键收束：由公司使命、公司记分卡、公司目标、产品愿景与原则、产品战略构成的战略背景，意在适用于公司里所有产品团队；每个产品人、尤其每个 PM，不仅要理解它，还要"在自己的言论、行动和决策中展现出，她的团队是如何在为这些共同目标做贡献的"。

核心主张：从本章起，卡根从"教练能力（competence）"转向"教练行为与心态（behavior and mindset）"——强产品人不仅知识技能够格，还要有有效的产品心态、在决策与互动中持续展现好判断。本章的主题是"像主人那样思考" vs.「像雇员那样思考」。他坦承这话题敏感、易"变得个人化"（尤其对"在对工作及其在人生中角色持不同态度的国家长大的人"），并郑重声明：他分享的是最好的团队的最佳实践、以客观结果而非主观标准来判断"最好"，而非大多数公司的做法。

最精彩的论据：① 权威背书——引 杰夫·贝索斯 1997 年首封致股东信："我们将继续……把薪酬向股票期权而非现金倾斜……我们成功与否很大程度取决于吸引并留住一支有动力的员工队伍，他们每个人都必须像主人一样思考，因而必须真的成为主人（an owner）"，并指出贝索斯在最近的股东信里再次重申了这一点。② 一段作者亲历的"为什么"问答（从 tech lead 转任 PM 时别人对他讲的，他"重复过上千次"）——把"像主人那样思考"拆成一串"我被告知……为什么……"：要对客户/团队/利益相关者/投资人负有真实义务（因为团队会以 PM 的言行为准、并据此评判他）；要"做功课"（客户、数据、业务、行业，因为这是他对解题的直接贡献）；要"想方设法翻越必然出现的障碍"（他记得原话："永远会有许多不发布的好理由，而你的责任就是想办法翻过、绕过或穿过每一个障碍"）；绩效由结果衡量（"绝不能把产出 output 与结果 outcome 混为一谈，客户在乎的是结果，不是努力或活动"）；要担责于失败、归功于团队；要负责激励和布道团队（因为"我们要的是传教士不是雇佣兵"）；以及那条产品人耳熟能详的——"有确保成功的责任，却没有指挥人的权力"（因为创新依赖与设计、工程的真正协作，那是同侪关系而非汇报关系）。

关键提炼与推演：① 一句浓缩定义——"像主人而非雇员那样思考，主要是为结果负责，而不只是为活动负责。" 一个佐证：他常劝优秀设计师/工程师转 PM，最常听到的拒绝理由恰恰是不愿为结果担责（及其所含的压力）——他理解并尊重，但认同贝索斯这心态对 PM 尤其重要。② 一处微妙区分——"想主人"与"传教士"相似但不同："大多数主人都像传教士，但并非所有传教士都像主人"（容易为一个动人的愿景兴奋，却仍不像主人那样思考）。③ 股权的力量（The Power of Equity）——"像主人一样想"这整段都与股票薪酬直接相关，因为股权让你"字面意义上就是主人，而不只是像主人"；他不认为顶级产品公司用期权/授予来分散所有权是偶然，且这"适用于各种规模的公司"，并直言"在世界许多地方本地税法让授予股权很困难……我恰恰注意到，在这些公司里我听到那句可怕的'那不是我的工作（that's not my job）'要多得多"。替代方案有利润分享计划，但他主张"若 CEO 想让关键人像主人一样思考和行动，就该像对主人一样给他们报酬"，并要"常青化（evergreen）"股权——每年继续给强绩效者授予新股，让最好的人"始终觉得若在完全归属前离开，会留下一大笔报酬"，是个清清楚楚的双赢。

核心主张：产品经理要做好那项最关键的工作，每天需要约四个小时（four solid hours）的整块、高质量时间——专门用来"想出难题的解法"，也就是产品探索（product discovery）；而不是邮件、Slack 或会议。新任 PM 最常见也最重要的辅导主题之一，就是教她学会管理时间。

论据/案例：Cagan 辅导时间问题，第一步是看 PM 怎么花时间，绝大多数情况下他发现 PM 把一天大部分用在了项目管理（project management）而非产品管理（product management）上。原因有三：一是这些活确实得有人干（尤其紧急时），PM 觉得没别人能做；二是很多 PM 从没被训练过产品管理究竟是什么，误以为这就是工作本身；三是项目管理任务具体、直接，每天勾掉一堆清单"感觉很有成效"。但 PM 的最高阶贡献与责任，是确保"让工程师去造的东西值得造"——即与设计师、工程师一起找出有价值、可用、可行、对业务可存续（valuable, usable, feasible, viable）的解法。Cagan 最钟意的解法是让 PM 搭档一位交付经理（delivery manager）来接手项目管理。一旦清不出每天四小时，就只剩两条路：要么延长工作日（于是有了 PM 臭名昭著的 60 小时工作周），要么交付不出结果、把工作搞砸。

前提/推演：这只针对赋能产品团队（empowered product team）的 PM。若你是交付团队的产品负责人（product owner），或功能团队（feature team）的 PM——后者更准确地说是项目/交付经理——则不适用；真正的早期创业公司人少，项目管理负担也小，不构成问题。即便用最新技巧"更聪明地工作"（work smarter, not harder），你仍然需要那四小时。

核心主张：一个能干的产品人最重要的单项行为，是思考（think）的能力。人们常用"聪明（smart）"作简称，但这个词含混——它多指智力（intelligence），而智力与思考根本不是一回事；获取知识与运用知识也是两码事。

论据/案例：Cagan 见过无数显然聪明却"浪费天赋"的人，因为他们不知道（或不愿意）真正动脑去解决难题。Google 让获取知识比以往任何时候都容易，却几乎没帮人学会思考和运用知识。思考之所以关键，是因为产品团队的内核就是解决问题。他之所以爱与设计师、工程师共事、也爱把他们招进产品岗，正因思考是他们工作的核心：他们是创造者（makers），但要设计体验或实现方案，本质上必须是在多重约束下求解的问题解决者。PM 同样要解决问题——不是去设计用户体验或架构可扩展、容错的系统，而是围绕客户的业务、行业、尤其自家业务的约束求解：客户是否需要？是否显著优于替代方案？公司能否营销和销售、能否负担得起去造、能否服务支持、是否合规？技术驱动产品的特殊挑战在于必须同时为产品、设计、工程三类约束求解，因而需要真正的协作。判断一个人思考弱不难：Cagan 鼓励提问，但前提是这人已做足功课、真投入了智力去先想过；很多时候显然没有。好公司在面试中要看的不是候选人是否知道答案，而是当她不知道答案时她怎么做。

前提/推演：他最爱的思考训练工具是前文讲过的书面叙述（written narrative），对不习惯啃硬问题的人会"真的痛苦"，但这恰是最需要它的人；有些人会在此处显出不适合做产品。只要具备必要智力且愿投入智力努力，思考与解难的能力绝对可以被培养——但需要管理者与产品人双方主动辅导、真诚努力。

核心主张：在赋能、跨职能产品团队语境里，"协作（collaboration）"有非常具体的含义，且绝非多数 PM 惯常的工作方式。先讲清协作不是什么：不是共识（consensus）、不是交付物/文档（artifacts）、也不是妥协（compromise）。

论据/案例：Cagan 在《启示录》（INSPIRED）中提出强团队三大特征——尽早应对风险、协作式解决问题、对结果负责。就第二点而言，协作不再是瀑布式地由 PM 定需求、甩给设计师出设计、再甩给工程师实现。不是共识——一般情况下技术 Lead 认为某架构合适就听技术 Lead 的，设计师认为某体验合适就听设计师的，有冲突就跑测试解决。不是交付物——一旦 PM 宣布某事是"需求（requirement）"，对话基本就结束、讨论转入实现，设计师沦为确保设计符合风格指南、工程师沦为只管写代码，又退回瀑布。不是妥协——若团队最后得到平庸体验、慢且不可扩展、对客户价值存疑，那作为团队就是输。要找的是真正可行（works）的解法：有价值、可用、可行、对业务可存续。他最钟意的做法是全员围坐在一个原型（prototype，通常由设计师做）旁：设计师权衡体验的不同路径，工程师权衡不同做法的影响与使能技术（enabling technologies）的潜力，PM 权衡每个方向的后果（如是否侵犯隐私、是否适配销售渠道）。原型与故事地图（story maps）既促协作、又能作为留存学习与决策的交付物副产品——但关键不在原型本身，而在它所促成的协作性质。在健康团队里，每位成员都指望别人已做足功课、带着必要技能上桌；但这绝不等于"设计师只管可用性、工程师只管可行性"：设计师常基于对用户的深刻理解给出洞察、改变要解的问题或路径并大幅影响价值；强工程师对使能技术的深刻洞察，常引向比 PM、设计师乃至客户能想象的好得多的全新解法。Cagan 说他最爱真正协作的那一刻：当一群既有动力（motivated）又在各自学科熟练（skilled）的人围着原型、或看用户与原型互动时——工程师指出新可能、设计师指出不同体验、PM 权衡销售/财务/隐私影响，探索一堆路径后找到一个真正可行的方案，那是一种"魔法"。 协作最常出问题的两种情形：一是 PM 没做功课、不懂销售/营销/财务/法务/隐私等业务约束，团队拿不到求解所需信息（通常意味着退回照路线图实现功能）；二是傲慢（arrogance）——PM 笃信自己脑中已有的方案最佳（即便她真对），协作被扼杀，团队变成雇佣兵（mercenaries）而非传教士（missionaries）。

前提/推演：还有一种关键协作——尤其在有直销团队的公司——是与潜在客户接触判断产品能否满足其需求。客户会本能地口授功能需求，但 PM 的工作是理解其底层问题与约束，再协作判断是否存在能满足需求的通用解法，这正是客户探索计划（customer discovery program）技术的核心。远程员工会削弱协作，因此对远程同事的协作辅导要加码。

核心主张：与利益相关者（stakeholders）的健康关系同样建立在真正协作之上。PM 既不是去向利益相关者"收集需求（gather requirements）"，也不是去向他们"下达解法"，而是把每位利益相关者当作负责某项关键业务、能帮忙找到可行解法的关键伙伴（partner）。

论据/案例：功能团队模式下功能多来自利益相关者，于是利益相关者自视为"客户（client）"、视产品团队为"被雇来的 IT 资源"，本质是"服务业务（serve the business）"；而赋能团队的目的是"以客户喜爱、又对业务可行的方式服务客户"。一个清晰的例子：当所做之事涉及隐私或合规等法律影响时，法务利益相关者就是你理解约束、评估各方案适配度的伙伴。组织越往上，高管越是对一切都在意——客户、品牌、营收、合规——PM 做足功课就越发重要。

前提/推演——"建立信任的基础（Building the Foundation for Trust）"：现代产品工作全是关系，PM 内部要打交道的人极多（工程师、设计师、数据分析、用户研究、其他 PM，以及销售、营销、法务、风控、创始人、业务负责人等）。关键认知：信任最好在你需要它之前就建立（build it before you need it），这需要刻意努力。Cagan 给的练习：让 PM 写下经常协作及经常需要其输入的人，圈出对她成功最重要的 3–5 个名字，再圈出她最怵打交道的 1–2 个人——这就是她最该投入经营的关系清单。做法是先一对一地认识这些人（能面对面喝咖啡/午餐最好，否则视频通话），了解他们工作外的兴趣、在舒适时也分享自己的，要真诚；对特别重要的人可每一两周固定闲聊一次、不带工作议程，纯粹建立融洽与信任；跨城跨国时就在通话里多留非工作话题的时间。有了互信，分歧能职业化地表达而不被个人化看待。

核心主张：Cagan 对冒充者综合症持一个反主流的看法——它是一种健康且必要的情绪、是大脑发出的重要信号；但多数人误读了这个信号，以为只是人皆有之的恐惧与不安、需要克服并硬挺过去。他的解读完全不同：这是大脑在警告你，如果不做功课、不真正准备会有什么后果。

论据/案例（先做两点澄清：不是指患有致残性精神疾病的人——他们不会用"冒充者综合症"这种轻描淡写的词来形容那种严重焦虑；同时"冒充者（imposters）"也确实存在——产品与设计领域有不少社媒红人、文章书籍作者、大会讲者在他看来是在鼓吹胡话）。正是"怕显得一无所知（looking clueless）"的恐惧，让他熬夜准备、研究、思考、写作、排练、迭代，更关键的是促使他事先把文章/演讲拿给一些他高度尊敬、且确知会诚实指出他思路或表达不扎实的人去试讲——而这些人不止一次把他从自己手里救了出来。 他在大会上太常听到那些"若有冒充者综合症、显然没把警告当回事"的讲者；该为他们克服怯场上台而鼓掌吗？在他看来那就像"仅因孩子来打球就发奖杯"。每当看到产品人对高管或大会做了场平庸演讲，他的不满不在那个产品人，而在其管理者：为什么没确保产品人准备好？有没有给出相关、可执行、诚实的反馈？有没有坚持先审一遍草稿或彩排？若主题不在管理者专长内，有没有为产品人找到能给出有用诚实反馈的人？产品人怯场就给渐进的公开演讲机会或安排演讲训练。

前提/推演：赋能团队以信任为前提，尤其是 PM 须赢得高管信任；当 PM 在高管面前显得没准备或天真，信任受损、且要很久才能挽回。因此他常对产品负责人说："你只和你最弱的员工一样强。"无论你是产品人还是产品负责人，都没理由做冒充者：听从大脑对"不准备之后果"的警告，找你信任的人给出诚实而专业的反馈，迭代到他们确信你确实在创造价值为止。

核心主张：要培养"客户中心"这一关键特质。几乎人人嘴上都说在乎客户，但真正走进公司、看他们如何处理宕机（outage）、产品变更引发客户困惑/挫败、以及他们多久才真正坐下来与真实用户客户相处，就能轻易分辨出"声称在乎"与"每天用行动证明在乎"的人。

论据/案例：此特质与公司文化高度相关，深受领导者言行影响——Cagan 见过的每一个真正在乎客户的公司，无不源自最高层；若领导者不真心在乎客户，在产品人身上几乎无法培养。第一要务是对"客户（customer）"一词非常具体且有保护性：常见毛病是产品人以为自己有许多"客户"——把每个利益相关者、客服团队、CEO 都当客户，这是技术"服务业务"旧角色的残余，且严重稀释了真正客户（true customer）的分量。面向客户产品的用户才是真客户；面向内部的赋能型产品的用户、用平台服务的开发者也重要，但都没有真客户的分量。消费互联网公司常把广告合作伙伴当客户，但他们不是——若真客户不喜欢产品、不参与，公司失败、广告伙伴也失败。他用讲故事来落地"在乎客户"的真义，最爱的几个：早期 FedEx 婚纱裙故事、电影《Wild（涉足荒野）》里描述的 REI 登山靴更换故事、以及《Delivering Happiness（三双鞋）》里早期 Zappos 的诸多故事。 他还建议每周至少 3 次、每次 1 小时、持续不断地与客户互动，并在每周 1:1 上追问产品人学到了什么、鼓励她把见闻在公司广为分享——目的是确立这位产品人"对用户客户有深入而亲身了解"的声誉。客户中心的真正试金石是产品人如何处理艰难或高压决策：当客户因产品问题陷入停摆（showstopper），她是照常办公，还是营造一种紧迫感（不是恐慌）、以身作则拿出有效解法？

前提/推演：真正客户中心的公司里，领导者常主动联系产品团队提供帮助，无需微观管理就传递了重视；但反过来，若产品团队对解决客户问题的优先级不如高管高，高管会失去信心并介入——若逼他们在"赋能团队"与"照顾客户"之间二选一，结果你多半不会喜欢。最后，要确保产品人真心喜欢并尊重客户，但不能让她以为工作是"问客户该造什么"——工作是代表客户去创新（innovate on behalf of customers），这与焦点小组（focus groups）的做法不同。这种真诚一致的客户中心通常要一年或更久才能在新产品人身上养成，途中会有判断失误，但靠主动而建设性的辅导可以帮她习得。

核心主张：正直（integrity）对赋能团队 PM 而言不是高悬的理想，而是必需。赋能团队以信任（trust）为前提，信任基于能力（competence）与品格（character），而正直是必要品格的核心；它也是赋能团队良好决策的基础（故先讲正直，下一章讲决策）。

论据/案例：发展、展示并守护正直绝不容易，各种力量持续在挑战它。Cagan 列了几个典型两难：刚被 CEO 强调某事必须紧急交付、团队却说绝对需要更多时间；坐在因产品货不对板而又恼又怒的客户面前；某利益相关者向你吐露因得不到产品技术组织足够支持、想离职；某业务拓展伙伴正大举投入、而你知道产品多半给不了他们指望的价值。经验丰富的管理者能辅导产品人穿过这些雷区。他辅导正直时聚焦三种核心行为：可靠（Dependability）、公司最佳利益（The Company's Best Interests）、当责（Accountability）。

• 可靠：正直始于让产品人重视自己的话语与承诺——哪怕出于好意误导高管/客户/利益相关者，也可能永久损害声誉。核心是高度正直的承诺（high-integrity commitment）（详见第七部分）：一要确保承诺基于知情判断（informed judgment），二要竭尽所能兑现；这意味着在团队对价值/可用/可行/可存续四类风险做过充分探索前不轻许承诺，且要倚重设计师与工程师的专长。更难的是，光按期交付还不够——交付的东西必须真能解决客户和/或业务的问题。
• 公司最佳利益：PM 须被视为始终为公司整体利益行事，而非只护自己或团队。大公司里人们常被疑有私人议程或"领地（fiefdoms）"。展示途径很多：帮另一团队达成关键目标、为客户或利益相关者多走一步、公开把功劳归于他人，以及最常见的——做出或支持一个对自己团队未必最优、却明显更利于客户或业务的决定。（一个重要旁注：这正是股权激励之所以有效的重要原因——没有人能赢，除非公司赢。）项目经理常诉诸强加截止日期，但要一支传教士团队，PM 须转而分享工作的整体目的（purpose）。
• 当责：赋能团队签下的是达成结果，随之而来的是对结果负责。但当责在实践中通常并不意味着结果没出来就被解雇，而是指愿为错误承担责任——即便过错可能在他人，她也总问自己本可以做什么来更好地管理风险或取得更好结果。有句老话："产品团队成功，是因为每个人都做了该做的；但产品团队失败，那是 PM 的责任。" 有人当玩笑，其实不然：工程师交付远超预期地慢——PM 是否充分认识到可行性风险？是否征询并倾听了工程师的顾虑？一个快速可行性原型很可能在探索阶段就揭示真实代价。又如出现严重法律障碍危及产品——法律考量是业务可存续的核心，本应在探索阶段被 PM 探查并处理。

前提/推演：辅导赋能团队 PM 与辅导功能团队 PM 不同——后者本质上是信使（messenger），向团队传达需求/约束/日期、向上反馈顾虑/状态/坏消息；而赋能团队 PM 被期望去想出对客户和业务都可行的解法，须具备必要的业务知识与创造性解题能力。正直不等于完美（perfection），错误难免；只要总体上承诺可靠、始终为公司最佳利益行事、并为错误负责，PM 的职业生涯就能挺过这些错误。

核心主张：功能团队里大多数有意义的决策已由高管和利益相关者在上游做掉了；而赋能团队的核心正是把决策下推到团队层级。"好决策（good decisions）"不仅指合乎逻辑、有数据支撑的业务决策，更指团队、高管、利益相关者、客户都能支持和理解（即使不同意）的决策。决策"怎么做"，往往才是高下之分。

论据/案例：好决策建立在正直的地基上（被视为承诺可靠、为公司利益行事、愿对结果当责）；并须始终牢记追求的结果——既要决策成功（及时且利于好结果），也要领导者与利益相关者理解并尊重你的理由（即便他们会选别的），还要各方真正感到被倾听被尊重（即便决策没顺他们的意）。Cagan 据此辅导五种关键行为：

• 匹配决策分析的规模（Right-Size Decision Analysis）：并非所有决策同等重要。要权衡风险与对应的后果（consequence）——出错了多大事？有的几小时就能恢复，有的可能危及产品乃至公司未来。据此决定是必须先收集关键信息，还是可基于今天的不完美信息就拍板；并考虑受影响的人（营收、销售、法务），需要谁支持就去征询其顾虑约束、把他们一起带上。他举的例子：新手 PM 常严重高估或低估风险，在无关紧要的事上花太多探索时间，反而没时间留给真正要紧的风险。
• 基于协作的决策（Collaboration-Based Decision Making）：几乎每个他辅导过的产品人都纠结于哪些决策自己"拥有"、哪些别人"拥有"，他得费力扭转这种心态。好决策不是让所有人同意（共识模型），不是取悦最多人（投票模型），也不是由一人拍板（仁慈独裁者模型）。若决策主要关乎使能技术，尽可能听技术 Lead；主要关乎用户/客户体验，尽可能听设计师；主要关乎业务可存续，则靠 PM 与相关利益相关者协作。最难的决策通常围绕价值，因为价值是整体的函数（value is a function of the whole）。
• 解决分歧（Resolving Disagreements）：在真正在乎工作与客户的强赋能团队里，分歧正常且健康，因信息常不完美、意见与判断必有其位。例：技术 Lead 觉得某设计实现起来不必要地难、设计师却认为该设计对体验必不可少——此时关键在于团队懂得何时、如何跑一个测试（run a test），通常是做某种特定原型、用它收集证据，必要时收集有统计显著性的结果或证明。若坚持基于协作决策、有分歧就跑测试，那么 PM 需要否决团队或把决策上升给高层的情形会非常少。
• 透明（Transparency）：要带着团队和领导者一起理解决策理由，就须在决策中保持透明，不让人觉得我们在做没根据的决定、忽视重要顾虑或夹带私心。小决策常只需一张便条把原因讲清；重大决策他极力推崇前文的书面叙述，尤其是其 FAQ 部分——把每一条预料中的反对或顾虑都写出来并逐一回应。许多产品人起初抵触书面叙述的繁琐，但对有重大后果的决策这正是所需。
• 不同意但执行（Disagree and Commit）：好组织里常会激烈分歧，哪怕已跑过测试收过证据——这恰是传教士的标志，不是坏事。但要强调：分歧与辩论必要且好，最终却可能需要"求同存异"；只要人们真感到被倾听、观点被考虑，多能接受——但这还不够：还要团队、尤其 PM 更进一步，承诺为最终决定全力以赴，即便她并不同意。 想想这有多毒：PM 对领导层说她听了技术 Lead 但自己不认同；或领导层做了她不认同的重大决定、她回头向团队抱怨。对照之下应是：PM 陈述被考虑过的各种观点，解释决策理由，并说明她打算如何让这个决定成功——她无需隐藏自己原本的个人意见，但必须展现她理解各选项与最终决定的理由、且能并会尽力让它成功。

前提/推演：决策是会随职业生涯持续发展的技能，PM 越往上、所负责的决策越难越重要越有后果，单这一主题就常能填满每周 1:1。收尾金句：前 Netscape CEO Jim Barksdale 的"决策三法则"——①见到蛇就杀掉（看到重要决策就识别并做掉）；②别玩死蛇（别反复回头重议已做的决策——死蛇也会咬人）；③一切机会起初看起来都像蛇（难题/难决策里常藏着机会）。

核心主张：Cagan 坦言从不喜欢会议（被无数准备拙劣、主持无能、拖沓低效的会永久带了偏见）。他辅导时对人们如何开会、乃至到底是否真需要开会都很较真——因为会议是其他高管对产品团队、尤其 PM 形成判断的极便捷途径。会议最大的痛点是它是同步（synchronous）的：每位参会者都得停下手头一切来开会。若能异步（asynchronously）达成目的（如状态更新、新发布的信息传达），通常是更好的路。

论据/案例（这里不指产品团队内部的站会/复盘/看原型等日常工作，而指超出产品团队、含利益相关者/高管/伙伴/他队的聚会）。产品组织里会议大致三类：沟通（Communication）——有重要或复杂到不宜异步发送的非琐碎信息（如全员会、领导讲产品战略）；决策（Decisions）——超出产品团队自身能定的决策（影响触及公司其他部分或风险大），此类他极力主张用书面叙述：开会先各自读叙述，再讨论并做出知情决策；问题解决（Problem Solving）——不知最佳方案（否则早写成叙述拿去做决策了），但相信把对的人聚到一起也许能解开特别难的问题，例如宕机后的复盘（postmortem），探讨今后如何避免此类问题。

前提/推演——组织有效会议五步：①目的（Purpose）：组织者先把会议目的弄得非常清楚；②参会者（Attendees）：列两份名单——绝对必需的（缺席就得改期的）与可选的；③准备（Preparation）：三类会都必备——沟通会要有内容清晰度/合适媒介/必要图像，决策会要有书面叙述且经懂行者审过，问题解决会要想好如何讲清情境/已收集相关数据/准备好答各种问题；④主持（Facilitation）：你不是去"维持秩序"，而是去确保达成必要的决策或解法；⑤跟进（Follow-up）：会议有结论后通常要通知相关方决策或后续步骤，把闭环闭上。底线两条：(a) 召集的会确实必要、值得占用所有人时间；(b) 做好准备使其高效有效、达成目的。

核心主张：每个产品团队要考虑的四大风险通常是价值、可用、可行、业务可存续（value/usability/feasibility/business viability）；伦理一般归在业务可存续里。但有两个问题让伦理常被忽视：一是业务可存续本身已含销售、营销、财务、法务、合规、隐私等太多方面，伦理易被淹没；二是不同于其他方面，很少有明确专责伦理的利益相关者。因此 Cagan 主张显式地加上第五种风险——伦理风险（Ethical risk）：我们"应该（should）"造它吗？

论据/案例：他举了一家确有专责伦理者的进步科技公司——Airbnb，其老友 Rob Chesnut 曾任首席伦理官（chief ethics officer，现为顾问）。Rob 律师出身、当过联邦检察官，早年加入年轻的 eBay 任法律顾问（Cagan 在此初识他）。Rob 的核心判断："领导者要认识到世界正发生巨变，公司及其领导者越来越会因伦理失败而被追责。" 他指出过去公司只有股东一个利益相关者——只做利于盈亏底线的事、只盯季度数字，这催生了大量被日益视为不道德、令越来越多人对公司失去信心的行为；如今要承认其他利益相关者：在 Airbnb，不只考虑投资者，还有员工、房客（guests）、房东（hosts）以及业务所在社区——若持续做出损害其中一方的决策，就是在背离使命、长期损害业务。Rob 给产品团队的"信号清单"：方案是否利于终端客户？是否以某种方式损害环境或社区第三方？若围绕该产品的所有邮件、文档、讨论被公开到网上，你会不会难堪？政府监管者若知道一切会作何反应？这产品会是你愿作为个人品牌一部分而自豪的吗？ 更要紧的是把话题摆上台面——"你要的是一个人人都愿意问出那些令人不适的问题的公司，这能保护公司免于灾难性的伦理失败。"

前提/推演：发现伦理问题怎么办？最好是探索出一个不含这些伦理顾虑的解法，但有时做不到或没时间。Rob 的建议是深思熟虑地发声、提出顾虑，但不要居高临下或指责，要让人清楚你是在乎保护公司最佳利益；Cagan 补充：必须深刻理解业务运作，免得被视为对经济一无所知的天真之人，此时也可能需要管理者帮忙。若身处一家根本不在乎伦理的公司怎么办？Cagan 极少劝人离职，但对那些明显无视伦理影响的公司，他过去并将继续鼓励人离开；Rob 的话是：若你不以工作处为荣、不以公司对世界的影响为荣，或认为领导层根本不在乎正直，那大概该开始另找工作了。所幸在他经验里绝大多数科技公司在乎伦理、真心想以某种有意义的方式改善世界，但即便好意也可能有意外后果。（他强烈推荐读 Rob Chesnut 的书《Intentional Integrity》。）

核心主张：这看似不是管理者该负责的事，但凡在科技业待过的人都知道，管理者很容易让一个产品人痛苦——"人加入公司，却因管理者离开"每天都在上演。Cagan 不常把它叫"辅导幸福感"，但强调管理者应至少每周关注每位产品人是否觉得在做有意义的工作、在职业上有进步、在与团队及高管建立起必要关系。

论据/案例：他在"人各不同、关键是管理者足够了解每个人"的大前提下，总结了几条近乎普适的真理：

• 有意义的工作（Meaningful Work）：除非管理者糟糕（那将压倒一切），否则这通常是幸福感最大的因素，甚至超过薪酬。但产品人未必清楚自己一个小团队如何/为何有意义，须明确而频繁地公开与私下反复讲清、强化。
• 个人关系（Personal Relationship）：Marty 承认一直希望下属喜欢自己——但要为特定理由：相信他致力于帮他们职业与个人成功、信任他从而能接受坦诚反馈、日后回望这段共事是职业生涯中最爱的时光之一。职业关系建立在个人关系之上：他谈自己的家人朋友与工作外兴趣并邀请对方同样分享，把对方当人去认识。
• 个人认可（Personal Recognition）：很多人说不需要认可，他很少相信——他们其实是不适应某些公开形式的认可，但几乎人人都想被自己尊重的人看重。除晋升、薪酬、股权外，他偏爱更频繁更个人化的认可（在了解其兴趣后）：一瓶好酒、一本他觉得对方会喜欢的书、一张行业大会门票、一张好餐厅礼券、两人周末出游。多数时候有预算覆盖，少数公司得他自掏腰包——但好管理者知道自己只与下属一样优秀，让人感到被重视也帮了自己。
• 工作习惯（Work Habits）：人有时疯狂加班，但要区分两种根本不同的原因——因为"想（want）"而非因为"不得不（have to）"。被迫疯狂加班的，多半是雇佣兵团队、根本不会在乎幸福感这事；他谈的是另一种：真正赋能、自觉在做有意义工作的团队太投入、抬头已是深夜，或一年飞逝竟没休假（他特别点名美国和中国尤甚）。好管理者会在 1:1 上谈起，讲清多容易倦怠、玩长期游戏的重要、以及这工作本质是创造性解题、需要时间充电。偶尔真有大事来临、团队大冲刺，只要动力源自团队内部，也可能成为人们最自豪的成就，不全是坏事——但管理者要确保这不是常态。
• 示范好行为（Modeling Good Behaviors）：很多管理者自己疯狂加班却叫下属不必——"照我说的做、别照我做的做"。但下属会感到压力去至少和管理者一样拼，陷入早到晚走、深夜回邮件的傻循环。你若真在乎下属幸福，就知道行动比言语响亮：管理者要刻意分享自己如何/何时充电、留意自己何时发邮件、如何管理时间。
• 职业规划（Career Planning）：有时为让产品人真正幸福，可能要帮她换岗甚至换行。若她做不了这份工作，虽尴尬但直接；但有时根本不是这个问题。Cagan 最难的一次经历：一位极强的 PM，聪明、极善与人相处、学得极快，他几乎确信她前程似锦；但她最终信任到向他坦白——她虽知道自己擅长且确有影响，却意识到这不是她想要的人生。失去这样的人才令他难受，他仍鼓励她去追自己的热爱（写小说），她做到了、并打破概率把它变成了职业。管理者拥有让员工生活痛苦、或助其达成职业与个人目标的力量。

前提/推演——"最伟大的教练（The Greatest Coach）"：Apple 的 Steve Jobs、Google 的 Larry 和 Sergey、Amazon 的 Jeff Bezos，在各自公司早期形成期都被同一个人辅导过——被称为"硅谷教练"的 Bill Campbell；他极力避开聚光灯，要把关注留给被他辅导的人（2007 年 Cagan 想写他、被他婉拒）。Bill 已于数年前过世，他辅导过的 Eric Schmidt（前 Google CEO）与 Jonathan Rosenberg（前 Google 产品 SVP）采访众人写成《Trillion Dollar Coach（万亿教练）》。Bill 衡量成功的独特标尺："我看所有为我工作过、或被我以某种方式帮过的人，数数其中如今有多少成了优秀的领导者——那就是我衡量成功的方式。" Cagan 自陈虽不敢与 Bill 同列，但当他教过/辅导过的人去创造伟大团队与产品时，也感到同样的骄傲；读这本书也让他谦卑地意识到，许多他最坚信的观点其实是被 Bill 辅导过的人灌输给他的——这一点想必会让"那位教练"格外开心。

通往领导之路（Path to Leadership）：Cagan 于 2010 年初识时任 Ask.com 工程副总裁的 Lisa。她在 UC Santa Barbara 学计算机，最初在 HP 当工程师，后加入年轻的 ask.com（即当年的"Ask Jeeves"）。其后 12 年，她从工程序列一路晋升，最终成为这家已是大型全球工程组织的 CTO。但真正定义 Lisa 的，始终是她对辅导（coaching）的热情、以及对持续改进自己与下属的执着；近几年她全心投入辅导他人，帮技术领导者成为公司所需的领导者。

领导力四项关键技能（Leadership in Action）——Lisa 的自述：不同领导者寻求辅导的动机各异（想大晋升、面临挡路的障碍、想与团队或同侪建立更好关系），但都渴望一个"感觉遥不可及"的结果；要蜕变为强大、自信、鼓舞人的领导者需付出努力与个人勇气。她总结出完成这一蜕变需要的四项关键技能：

• 自我觉察（Self-Awareness）：始于对自己诚实，弄清哪些行为或特质正挡了自己或团队的路——问自己：哪些行为在职业早期助你良多、如今却不再是优势？ 一个极常见的例子：技术高管以"绝对可靠的执行"建立声誉，一贯付出、兑现承诺，甚至常要"移山倒海"地交付——可靠执行成了其身份的一大部分；但当她被提拔到个人努力无法规模化的层级，团队却感到被微观管理。此处所需的自我觉察是认清——把你带到这一层级的技能，带不你到下一层级。
• 勇气（Courage）：当你用一套行为建立起职业与身份、却意识到必须改变（尤其是以现在要依赖他人的方式），这需要真正的勇气。给团队留出学习与犯错的空间需要勇气，给出有意义而诚实的反馈需要勇气，相信团队会比只相信自己带来更好结果这一信仰之跃需要勇气，放下战术技能走进战略世界需要勇气，展现脆弱（vulnerable）需要勇气。 例：一位技术高管因早年一个项目不顺、认定某同侪看不起她，便回避对方；但她知道需要这段关系，于是鼓起勇气主动找他做了一次极艰难的对话，坦白自己一直在回避、原因为何、以及她对今后合作的期望——这份勇敢与脆弱成了他们关系的转折点。勇敢的领导，是带着不适仍向前走。
• 交战规则（Rules of Engagement）：对许多领导者，学会信任团队需要很大的信仰之跃，因为他们知道自己终究仍对成功结果负责。交战规则就是与团队约定：领导者需要何种可见性，才能给团队留出工作空间——领导者需要哪些信息才能信任？团队需要理解哪些上下文才能成功？团队需要什么才能安全地尽早暴露风险与问题、或开口求助？这些规则会随信任与学习的积累而演进，但围绕"何时沟通哪些信息"先达成一些约定，能帮双方各自的需求得到满足。
• 自我颠覆（Disrupting Yourself）：即便领导者已有自我觉察、有改变的勇气、也约好了交战规则，长期养成的习惯仍极难打破——尤其是触及一个人身份与自我价值感内核的习惯。本质上我们是在要求领导者颠覆自己、承诺改变：承认会有错误与倒退，但每次发生都去识别触发点、寻找更好的回应方式；承认头几天几周最难，但日子越久、新行为越易调用。Lisa 的结论：每个领导者的旅程不同，但只要领导者真心想改进、并有勇气迈出"学会信任他人"的信仰之跃，他们确实能颠覆自己，成为公司所需、员工所应得的领导者。

核心主张：组建赋能团队，不要执迷于候选人毕业的大学、模糊的"文化契合度（cultural-fit）"、是不是所谓 10X 选手，或对你所在领域的深厚认知；真正该看的是两样——胜任力（competence）与品格（character）。作者借 Stephen Covey 的话点题：信任是这两者的函数，胜任力含能力、技能与履历，品格含正直、动机与待人意图，二者缺一不可。

论据/案例：最精彩的例子是体育史上最成功的特许经营球队——不是纽约扬基、芝加哥公牛或曼联，而是新西兰国家橄榄球队 All Blacks（百余年持续统治）。他们很早就懂"品格至关重要"，立下清晰的"不要混蛋规则（No Assholes Rule）"：无论球员或教练多有才华，只要是混蛋，就会对整队产生毒性。由此引出作者的招聘主张——别把巨大的人才池筛成"看着像文化契合"的那一小撮，而要保持池子很大，只把那极少数"混蛋"筛掉。胜任力方面，作者引老话"A 级招 A 级，B 级招 C 级"：经理自己若不是过硬的产品经理/设计师/工程师，既评不准候选人，也无法把人辅导到胜任。

前提/推演：胜任力是底线——没有胜任力，人和团队就无法赢得管理层信任，也就没有可持续的赋能。可以"基于潜力（potential）"招人，但前提是招聘经理愿意且有能力亲自把人辅导到胜任，若辅导失败则负责为其另寻岗位。文化契合是"招和我们长得像、想得像的人"的政治正确说法（在本行业往往意味着名校理工科男性）——而创新恰恰需要"想法和我们不同的人"，多元化能显著提高解决难题的概率。所以要刻意去找"明显和你们不一样的人"，且这样的优秀候选人常就藏在你自己公司里。

核心主张：多数人以为人员配置始于"猎源（sourcing，即 HR 开始递简历）"，但强公司里它始于主动"招募（recruiting）"——招聘经理先明确自己要什么，然后亲自出去把人招进来，就像大学或职业球队的教练主动拜访、结识、说服目标球员，而不是被动等"毛遂自荐者（walk-on）"投简历。招募（而非猎源）是作者所知改善多元化最快的方式。

论据/案例：最精彩的真实案例是 Chris 的亲身经历"让招募成为头等大事"。他在一家高速成长的创业公司当产品经理，忙到水深火热，终于获批再招一名 PM，却把流程甩给小小的 HR 团队、自己只是每周看看简历做做电话筛、十分被动。两周毫无进展后，在一次 1:1 里，他的经理拒绝让话题转移，斩钉截铁地说招到这名新 PM 是他"当下唯一最重要的任务"、是他的"正职"，并要求在岗位填满前至少投入 50% 的时间在此事上。两人随后一起把他手上的活逐项过一遍，决定哪些暂缓、哪些转给他人、哪些直接转给经理本人，腾出空间；接着经理又带他头脑风暴如何调动并发展个人人脉、主动搜寻候选人、重写职位描述、从"嵌进 HR 猎源流程"转为"主动驱动招募"。Chris 称这"是我职业生涯中最难忘的一次 1:1"——它彻底拓宽了他对自己工作的认知，也让他窥见了真正领导力的样子，本质是一次"心智框架的转变"。

前提/推演：人脉网络要持续经营，而非有空缺才临时抱佛脚——在行业会议、同行处、拜访伙伴客户时、经熟人引荐乃至社交场合结识人，约咖啡、做导师、时机成熟转为辅导关系。技巧还包括请业界讲者来办公室开讲、写一个展示产品匠心的公司博客（举 Etsy 的 Code as Craft 博客为例）。在大公司里，合适人才常在工程、财务、营销、销售、法务或业务方等"意想不到的角色"里"明摆着却没被看见"——要广撒网，但不是挖墙脚，而是让每个人都处在最能发挥才能的位置。招 PM 时作者偏爱有创业精神（entrepreneurial）的人，并告诉他们"产品管理被视为创业者或 CEO 的练兵场"。产品愿景（product vision）本身就是最有效的招募工具之一。外包（Outsourcing）：针对 PM、设计师、工程师、数据分析/科学家、用户研究员及其管理者这些核心角色，外包几乎必然葬送"传教士（missionaries）团队"、把你变成雇佣兵团队；自以为找低成本离岸团队能省钱，实则花得更多、得到更少，最大代价是丧失创新能力。只有测试自动化、大型迁移这类突发性大批量工作用外包不成问题。一句话锚点：更小的一群传教士永远胜过更大的一群雇佣兵。

核心主张：招聘经理必须对两件事负责——面试团队的"面试有效性"，以及候选人的"面试体验"。总目标是确保招到有胜任力与品格的人，且至少对 PM、产品设计师、技术负责人（tech lead）而言，每一次招聘都应"拉高平均水平（raise the average）"。

论据/案例：最有力的操作是作者"最爱的面试问题"。在面试后段，告诉候选人："你是产品人，我相信你这四项都强，但你不大可能自认四项同样出色，所以请你从最强到最弱排个序。"——四项属性是：执行（Execution，把事做成、不用催就做对的事、同时盯多个目标）、创意（Creativity，你多常是房间里点子最多或最好的人）、战略（Strategy，跳出手头工作、放进更大市场或愿景语境并讲清楚）、增长（Growth，多擅长用流程与团队管理把努力"乘数放大"）。这道题没有标准答案，意在卸下防备、引出关于"自评弱项"的诚实对话，本质是"说说你的缺点"那道老题更高效的版本。作者高度看重产品人的自我觉察与承认成长空间的能力，并对回避此对话、或自评与面试其他环节观察严重不符的候选人保持怀疑；对招聘经理而言，这题还能检查自身偏见、避免招出一堆"克隆人（通常是你自己的克隆）"。

前提/推演：三点须特别说明——①区分"为胜任力招"与"为潜力招"：通常找已证明能胜任的人，但有时（如校招）押注潜力，此时招聘经理必须向面试团队讲清楚，并亲自承诺投入辅导（往往不止每周 1:1，还要连续数月的每日辅导），若合理时间内仍达不到胜任，须负责纠正这次招聘失误；②时刻提醒面试团队"我们要的不是更多同类"，教育、人生阅历、文化或解题路径不同的候选人都极受欢迎；③别主要为"领域知识（domain knowledge）"招人——对的人能比"懂领域却缺产品技能的人"更快学会领域，且领域知识太多反而常是负债（误以为自己就是客户）。此外，由于一个产品团队工程师不止一名，工程师有经验梯度无妨；但 PM、设计师、技术负责人每队各一，必须高标准，这些"绝非初级岗位"。面试团队应由招聘经理精心策展、按胜任力与品格遴选（是强候选人乐于共事、也愿一起喝杯啤酒的人），常见错误是为求"包容"让所有想参与的人都来，这只会让平均能力持续缓慢下滑。整个面试日的目标是当天解决所有悬而未决的问题：每位面试官把未决问题传给下一位，由招聘经理或最后一位面试官按需延长时间收尾；若中途已明确不合适，提早结束也无妨。

核心主张：面试找到强候选人后要"备 offer、拿下候选人"。流程多由 HR 的合规与薪酬决定，但有几条对招聘经理至关重要的要点——核心是：录用人才是"个人化"的，是一位经理对一个人成长的私人承诺，与新人对公司愿景的私人承诺彼此交换。

论据/案例：最关键的操作清单——①速度：找到真正强的候选人就要快，争取 24–48 小时内发出 offer，否则不仅可能失人，还会让候选人觉得"公司决策困难"，观感很差；②背景调查（reference check）要认真、要亲自做、绝不假手他人，务必问对方"是否愿意再次雇用此人"——背调最重要目标之一是识别那些会因人格而变得有毒、能在面试中藏好问题面而前雇主却心知肚明的候选人；人们做背调时常不愿透露负面信息，故要给足机会、且邮件背调几乎无用，电话或喝咖啡当面谈更易得到真话；③超越背调：查候选人在社交媒体上的公开行为，看他与人互动是体贴尊重，还是不假思索地往最坏处揣测——若一贯当众无礼，很可能日后在职场也如此。无论 offer 由 HR 还是经理发出，最重要的是招聘经理亲自打电话，明确承诺"只要你加入并肯付出努力，我就承诺亲自投入辅导、帮你发挥潜力"——对多数候选人而言，"有个人坚定地站在你这边、主动为你的职业成长奔走"比任何其他因素都重要。若候选人特别优秀、可能拿到多个 offer，作者通常会请 CEO 或其他关键领导出面聊一聊，向候选人传递宝贵信号。

前提/推演：管理跨度（Span of Control）指一名经理带几个直接下属。每位带人经理的首要职责是辅导与发展下属，而所需辅导时间因人而异，决定合理跨度的主要因素有四：①运营责任的多寡（产品/设计/架构与技术债战略都很耗时）；②下属的经验水平（人才竞争激烈，很多公司只能基于潜力招人再辅导，但要求经理擅长辅导且跨度更小，如带 4–5 人而非 6–8 人）；③经理本人的经验（辅导技能可习得，经验丰富、以辅导为荣的经理会高效得多）；④组织复杂度（反直觉地，越大的组织里"连点成线""向上与横向管理"——即办公室政治——耗费越多）。比例上：跨度最小的通常是组产品经理（GPM，半带队半干活的 player-coach，至多带两三人）；最大的通常是工程经理（带 10–15 名不同层级的工程师不罕见）；多数落在 5–7 人。某些公司以极扁平、超大跨度自豪，但作者经验里这要么是在为有经验的人才（连个体贡献者层级都）付高额溢价，要么就是根本不在乎辅导与发展下属。

核心主张：作者长期推崇同地办公（co-located）团队的力量，但如今问题已变为"团队分布式、部分或全部远程时，如何仍给创新最好的机会"。结论：交付（delivery）远程通常没问题、偶尔更好；真正的挑战在探索（discovery）——并归出三类会实质损害创新的问题：制品、信任、时间。

论据/案例：最精彩的论据是借 Bezos 之口点明同地办公之于探索的"魔力"：亚马逊的产品团队要使命清晰、目标具体、跨职能、专属且同地办公——因为创意来自人们的互动，灵感来自高强度的专注，团队像创业公司一样挤在车库里实验、迭代、争辩、一次次重试；作者认为亚马逊成为本行业最持续创新的公司绝非偶然。三类问题展开：①制品（Artifacts）：一旦把 PM、设计师、技术负责人分开，就会出现一种近乎"引力般"的拉力——不再坐到一起谈"我们怎么解决这个问题"，而是开始互相生产制品（设计师要 PM 写 brief/需求/约束，技术负责人要设计师给线框图，PM 找工程师要估时），很快退回瀑布式的制品传递，讨论也从结果（outcome）滑回产出（output）；必须持续对抗这种倾向，探索期主要制品应是原型（prototypes）。②信任（Trust）：探索与创新依赖心理安全感（psychological safety，注脚指向 Google 的"成功团队五要素"研究）；隔着屏幕、不当面说话时，人的过滤和敏感会减弱，不少人因此"看到了同事不太好看的另一面"——这正是辅导的用武之地，且任何可能被解读为敏感的事都最好走视频（含表情、语气、肢体语言），一条措辞糟糕的邮件/Slack 若需数小时去补救，未必更高效。③时间（Time）：团队成员能拿出的连续优质时间不一，凑齐哪怕每天一小时大家都在线都可能很难；作者主张灵活——若设计师有幼儿、只能在清早或深夜挤出一小时，PM 与技术负责人能迁就就值得迁就。

前提/推演：远程做探索，方法机制与同地办公并无大不同（仍是多想法、快速做原型、在真实用户上定性或定量验证，定性测试用视频弥补不能面对面）；真正的差异落在 PM、设计师、技术负责人三方"协作发现一个值得做的方案"的动态上。若分布式团队产出不如以往，上述三处就是辅导该聚焦的地方。

核心主张：招到有胜任力与品格的人只是开始——新人头三个月"绝对关键"，几乎会定下其整个任期的基调；招聘经理要先确立胜任力，再把重心放在建立牢固关系上。一句锚点：作为领导，你的水平不会高过你最弱的员工——"这些人就是你的产品"。

论据/案例：最具操作性的内容是入职过程中的一串检查点：第一天结束时——她是否至少交到一个未来朋友？是否清楚对她的期望？第一周结束时——这周如何？是否已逐一认识本团队每位成员？拿到第一笔工资后——新人会下意识评估"加入的选择对不对"。第一个月后——她对公司及自身潜力已大致有数。头 60 天后——她是否拿下一次能确立自身价值的公开"胜仗（win）"？作者强调：许多第一印象会被各部门尤其资深领导形成，且对很多高管来说，纠正负面第一印象的机会寥寥。具体做法：先评估新人、据此制定辅导计划并亲自确保其达到胜任；超越胜任之外，重心是建立关系（先与你和其团队，很快再与高管、利益相关方）；对 PM 而言，地基是深入了解客户与业务——典型包括一系列客户拜访加详尽复盘（覆盖客户、销售与营销等 go-to-market 机制、客服如何处理），以及与财务团队共处、学习关键 KPI 的含义与算法；强烈建议让所有成员（含工程师）"深度接触真实用户与客户"作为地基。待新人学到必要内容，再一对一亲自把她引荐给关键领导与利益相关方，突出她做过的准备与做真正协作伙伴的意愿，并在此后数月持续与这些人对接、跟踪体验与待发展之处。作者还提醒先弄清新人对"被辅导"的开放度：多数人感激，但有人会觉得"需要被辅导＝我有问题、岗位已危"，对这类防御或不安的表现要正面化解——作者的做法是分享自己一路被人帮助的旅程。

前提/推演：APM 项目（APM Programs）——最佳的产品公司总在寻找更多过硬的 PM。最精彩的案例是 Google：其首位 PM Marissa Mayer 立下极高标准，并很早意识到强 PM 稀缺，遂设立 APM（associate product manager，副产品经理）项目；要注意此名易混淆——在硅谷外尤其功能团队公司，"APM"常指入门级初级 PM，而 Google 这个项目几乎相反。它从公司内外挑最聪明优秀的人，给入选者一个两年的辅导项目，把"有过或正在积累其他领域（业务或教育）业绩的高绩效/高潜力者"辅导成很强的 PM 乃至产品领袖；Marissa 投入了无数小时辅导，项目确实产出了一批日后撑起 Google 顶级产品、并走出去自己创业当领袖的人才。该理念已扩散到 Facebook、Twitter、LinkedIn、Uber、Salesforce、Atlassian 等（有的每年招一批新生，有的设轮岗）。作者给中大型公司的几条原则：①只有当你拥有既愿意又有能力高强度辅导的、经过验证的强产品领袖（哪怕是 VP 级，只要卓越且信奉育人，也要直接拉来辅导）才能办；没有就考虑外聘一位经验证的产品领袖、给至少一年见成效。②招生门槛极高，只收公认头脑最好、潜力最高、"为每场对话带来价值、驱动把事做成"的人。③对每人做彻底评估、识别技能发展点并全年更新。④落地一份个性化的一到两年辅导计划，每周至少与一位经验证领袖 1:1，并把人直接放进关键产品团队的"风暴中心"实战。作者偏爱低调推进、靠实力赢得同侪尊重；并发现这是改善产品组织多元化的极有效方式——因为入选不看经验、而看潜力。

核心主张（由 SVPG 合伙人 Christian Idiodi 现身说法）：产品人无论过去多成功，到了新公司并不会自带成功所需的一切；普通的"新人入职说明会（new-hire orientation）"在帮人融入上有用，却远不足以为产品人准备好做难决策、在同侪中赢得高信任这类更重要的能力。产品人的入职，会"设定她在岗位上贡献与成功的上限"。

论据/案例：最精彩的案例就是 Christian 十年前任产品负责人时亲手打造的"五天密集训练营"。缘起：他见过一连串"完全有能力却失败"的产品人，意识到他们的能力与在组织里的成功之间缺了一环。带着四个问题设计——决策如何做、过去怎么做？公司现在看重什么、在朝什么努力？我怎样让人信任我？此刻最该做的是什么？训练营结构：每天先做"个人成长"环节（沟通练习、性格测试、个人技能、为自己定职业成长路径），既向新人传递"公司在乎你这个人及你的成长"，也遵循"先戴好自己的氧气面罩再帮别人"的原则——把领导者训得健康，下属才更有机会。随后每天讲一个产品培训主题，统称"战略语境（Strategic Context）"：第一天讲"理解客户"，但会带新人走一遍公司自己的历史，把愿景、财务模型、客户探索、过去与未来想要的客户都讲透；后几天依次讲验证、构建与优先级排序、学习与度量、走向市场——全都贴合本组织目标与"把事做成"的方式。讲完战略语境，马上请一位公司里的产品人来就该主题讲自己的亲历故事，开始建立关系与信任。午饭后进入"产品工作坊（Product Workshop）"：把早上所学拿来像真在岗位上一样实操，并请来她将共事的团队成员，在领导指导下于安全空间里练习，把"摸清别人如何工作"的学习曲线提前缩短。

前提/推演：训练营强化"学习与成长"的文化——产品人离营时不再问"我今天该干嘛"，她已知道下一件正确的事、能快速决策，事先建立的关系也让她更快出结果。点睛句："我们不是招聪明的产品人来听我们指挥，而是招他们以客户喜爱、又对业务有效的方式解决难题。"所以要在产品人身上做的投入，远不止一份新人入职资料包——值得考虑用一个训练营让他们走向成功、并赋予工作以意义。

核心主张：作者直言若由他做主，年度绩效考核这套仪式会被彻底废掉；但多数公司里这关乎法律合规与薪酬管理，只能照做。关键纪律是：年度考核"绝不应是主要反馈工具"——若它是，作为经理你就彻底失败了。主要反馈工具是每周 1:1（乃至每日互动），且 1:1 的首要目的是为员工、不是为经理。

论据/案例：最典型的反面情形——一个怕冲突、回避给出必要建设性批评的经理，拖到最后才认定此人不够强，与 HR 一谈，HR 逼他把问题写进绩效考核，于是员工"惊讶又困惑地得知自己其实没达标"。这对员工不公平、且绝大多数情况下完全可以避免。作者表示：每当得知自己手下哪位经理出现这种事，他都视之为"那位经理"的严重绩效问题并据此处理——通常意味着他要看该经理今后每周 1:1 的准备笔记，且他本人也会直接与那位员工沟通绩效问题（确保反馈真的传到了员工那里）。

前提/推演：因此年度考核里"绝不应有任何与绩效相关的意外"，有意外即失败。这也说明并非人人适合当经理——胜任经理最基本的技能，就是愿意且能够给员工诚实、及时、建设性的反馈。还要记住有人不太会领会暗示：经理自以为给了负面反馈，员工却称没懂其严重性——所以经理本应把问题讲得"无可误解地清楚"，若每周都在谈，第一次漏掉、下一次也不该再漏。底线：合规该做的照做，但务必让每周 1:1 成为你的主要反馈机制。

核心主张：带人最不好玩的部分莫过于辞退。避免辞退的最好办法是练好招募、面试、录用、入职尤其是持续辅导的本领，但总有"就是不成"的情形。第一要意识到：不能只考虑那个出问题的员工，还要考虑被迫承担问题或重负的团队其余成员，以及"不纠正此问题"会向团队、更大产品组织、尤其领导与利益相关方传递的信号。在"做有同情心的雇主"与"负责任且果断行事"之间存在平衡，这部分取决于公司文化、部分取决于所在国的劳动法（HR 帮你理解并遵守合规责任）。

论据/案例：最有价值的是作者对两类"纠正招聘失误"情形的区分与处置——①第一类也是最常见：员工尽管经历认真的持续辅导，仍无法以必要的胜任水平履职。作者通常会真诚尽力三到六个月，期间在每周 1:1 中以"越来越强的紧迫感与清晰度"反复说明进展不足；若届时仍辅导不到胜任，他会向自己承认"不成了"。他总觉得这"部分是自己的错"（当初招了人、本应更准地判断其履职能力；若招聘经理是别人则是公司的错），故始终觉得有责任帮此人在本公司或别处另找更合适的岗位。②第二类也较少见：移除有毒（toxic）员工——即存在损害组织信任、让人感到被不尊重甚至更糟的严重行为问题。难点在于人人都有偶尔的糟糕一天或私生活的难处，故要判断这是暂时还是慢性、此人是否有意愿与能力控制自己的行为；但同样以三到六个月尝试纠正为常规，若问题持续，就该把焦点转向保护团队与组织其余成员的心理安全感。这一类作者不愿再帮其另找工作，但会诚实地告诉对方其行为及对团队信任与文化的影响。第二类尤其棘手之处在于：有毒行为往往伴随特别强的技能，组织会怕丢了这些技能、也确实会有一段别人补位的难期；但作者发现"每一次移除有毒的人都是对的"，其他人会挺身而出，更广的组织会为职场氛围的改善而感激。

前提/推演：作者坦言处理招聘失误从不好玩——回想被迫辞退某人时"胃里那种感觉"至今记得；但若你认真想打造强大的产品组织，这事真的不可或缺。

核心主张：若说辞退是人员配置里最不喜欢的部分，晋升毫无疑问是最喜欢的。作者初为带人经理时被教导："你作为经理最显眼、最实在的成功标志，就是你的人获得晋升。"一切始于了解员工的职业抱负——有人想以个体贡献者身份升到很资深、备受敬重的能力与责任层级，有人想走领导岗或终有一天自己创业，还有人尚不确定、想多接触不同选项。

论据/案例：最具操作性的是作者给晋升设计的"差距闭环"：先评估员工当前知识技能、对照新角色所需，生成一份差距清单，再一起讨论她如何学习并展示这些技能（也可让员工做自评、与经理评估比对）；一旦她证明已胜任新角色，作者就竭尽所能帮她拿到晋升。他会坦白告诉对方：晋升可能需别人批准、特定角色未必马上有空缺，但可以先把她准备好以便机会来临时抓住；也会解释"人越强对公司越有价值，所以让她晋升符合所有人最佳利益"。一个特别值得点出的情形：把个体贡献者晋升为带人经理——这不只是更资深的职位，而是一份"技能与才能要求根本不同的工作"，关键是此人要明白其要求、并为正确的理由想要这个角色；科技产品公司之所以设双轨职业阶梯（dual-track career ladders），正因为"钱"不是做这次转变的好理由。点睛引语（Tom Peters）："领导者不创造追随者，他们创造更多领导者。"

前提/推演：留存（Retention）——老话"人加入一家公司，却因经理而离开"，Marty 自陈深以为然（他本人就因糟糕的经理离过职，也无数次见此事发生在别人身上）。一定的流失正常甚至健康（配偶有重大职业机会、几年后离职去创业、退休等）；但若你真不想失去的人持续离开，这是管理可能出问题的真实信号。作者总会亲自给离职者做离职面谈（哪怕对方在组织里低自己好几层），既为自己判断他们为何离开，也为给那位经理收集可反馈的意见。而经验是：那些真正关心员工职业、不断辅导并努力帮他们拿到应得晋升的经理，几乎没有留存问题——相反，这些经理很快在公司里赢得口碑，问题反倒变成"人人都想调过来给他们干活"。

通往领导之路：April 主修信息系统与商科，以开发者起步；写了几年代码后加入 Travelocity 任软件工程师，一上来就被推到该公司与当时互联网巨头 Yahoo! 和 AOL 合作的第一线。通过工程工作，她开始在技术选择与业务战略之间建立连接，并发现产品管理正是能让二者对齐的角色。凭借不断表达想做 PM 的意愿、以及她作为"工程师与业务人之间翻译者"的专长（在 Travelocity 内部及与其伙伴间皆然），她于 2005 年拿到首个 PM 岗位。作者 2007 年初识她时，她已读完 MBA、在 Apple 实习过，正在 Google 一个面向伙伴的技术型组织里拓展领导经验。此后她加入 Twitter 任平台 PM，五年间见证公司从 150 人长到 4000 人，职能广度也从带 PM 团队扩展到业务拓展与产品营销团队——这段经历让她学会领导自身产品专长之外的团队，为更资深的领导岗做了准备。2015 年她加入 Slack 任平台负责人，迅速升任产品 VP、最终 CPO，在营收与人数双双超高速增长的近四年里，主管平台与 Slack 产品的方方面面，以及让 Slack 在企业软件同侪中脱颖而出的两项关键职能：设计与研究。如今她通过 2015 年与前 Twitter 同事共同创办的 #Angels 投资并辅导创业公司。

领导力要点：April 的生涯本身就说明"进入产品管理有许多条路，角色本身也有无数版本"。她以自身经历点出"球门一直在移动"的荒诞——职业早期（互联网泡沫余波、又远离硅谷）她脑中只有一种 PM 原型：远离技术与工程执行的"商科 MBA 型"；当她想转 PM，被告知需要 MBA，等她考上商学院、也如愿在 Travelocity 转岗，却在 2007 年毕业时撞上市场转向、转而强调 PM 要强技术；她以为当过工程师会占优，结果 2007 年加入 Google 时又被告知"因没有计算机科学学位而不能当 PM"（该政策后来已演变）。由此她总结出三条贯穿其 13 年产品领导生涯的规律：

①产品经理的原型随市场需求而演变——当创新与机会的核心驱动是技术时，更技术型的 PM 吃香；当移动崛起，有设计敏感度、能做出克服 App Store 低切换成本之 app 的 PM 受追捧；当创新前沿转向运营（交通、房产、酒旅、生鲜配送），又回到看重"PM 即总经理（general manager）"的业务取向。

②没有哪种 PM 模型绝对更好，但对某个具体岗位往往有一种更合适——在 Slack 把 PM 组织在五年内扩大五倍时，她刻意为每次招聘想清楚"什么最重要"：候选人作为 PM 的职能"风味"、从所做过产品中带来的领域专长、还是其经历过的公司成长阶段；强迫自己决定"最该把哪一点做对"，就能收窄候选人范围、为每个岗位招到对的那一类 PM。

③职能广度是从产品领导迈向公司领导的前提——最好的产品领袖不只擅长定义与构建产品，更懂得：产品再好也只值得上目标客户对"为何需要它"的理解；平台只有被用在能为开发者及其客户创造价值的方式上才有用；产品必须在维护业务健康的约束内构建。这些来自营销、伙伴关系、财务等众多职能的洞见，都是造产品的重要输入。她回顾自己一路戴过多种不同的"职能帽子"——有时是主动为学新技能，有时是因偏好的 PM"帽子"因外部原因够不着——如今作为产品高管再看，这些"侧步（sidesteps）"恰是她最宝贵的资产：帮她懂得如何招募与培养能胜任多种角色的领导者、在组织条线间搭桥，并始终牢记"产品永远服务于更宏大的公司使命，而非反过来"。

①核心主张。 一个强有力、令人信服的产品愿景具备五个特征：以客户为中心（customer-centric）、充当北极星、有足够大的范围与时间跨度、善用行业趋势、并由产品负责人牵头但让 CEO 真正拥有它。

②论据/案例。 以客户为中心：Cagan 说他数不清见过多少失败的产品——它们本可以给公司带来真实收益，唯独没能对真实客户产生价值。讲愿景的故事，必须从用户和客户的视角讲，要展示他们的生活将如何在某种有意义的层面上得到改善。他与公司做愿景时，第一件事就是找一位很强的产品设计师协作（可能是资深设计师或设计组织的领导者）；若公司尚无足够经验的人，这是他极少数会建议产品负责人去聘请外部专业设计公司来做愿景与"愿景原型"（visiontype）的情形之一。北极星：正如北极星能引导散落全球各地的人走向目的地，产品愿景为所有团队——无论身处组织何处、负责整体产品的哪一块——提供共同目标。书中举例："通过提供世界上第一款大众市场电动车来应对全球变暖。"每个团队都必须搞清两个关键问题：最终的终局（endgame）是什么？我团队的工作如何贡献于这个更大的整体？范围与时间跨度：很多公司犯的错是愿景不够宏大或有意义，读起来像一份功能路线图——这样的愿景几乎不可能被视为令人信服。愿景描述的是"你试图创造的未来"（the future you are trying to create），而非如何到达那里（那是产品策略与产品探索的事）。常规时间跨度是 3 到 10 年，极其复杂的产品和设备取上限。善用趋势：永远有新兴趋势（多由新技术驱动），也永远有炒作一阵就退潮的"风潮"（fads）；领导者要分辨哪些是趋势、哪些是风潮，更要判断哪些趋势真能帮你为客户交付创新方案。截至写作时的重大技术趋势示例：移动、云计算、大数据、机器学习、增强现实、物联网、边缘计算、企业消费化（consumerization of the enterprise）。趋势不限于技术，还包括用户群体行为的变化、购买模式的变化。Cagan 颇有把握地说：这份清单上的大多数甚至全部趋势在 5 到 10 年后仍将相关——真正的趋势不是转瞬即逝的。但要记住：客户不在乎我们的技术，他们在乎我们解决问题解决得多好。

③前提/推演。 谁拥有愿景？产品负责人（head of product）负责确保组织有一个令人信服的愿景以及能兑现它的产品策略，但现实更微妙。其一，要拿出好愿景，产品负责人必须与设计负责人、技术负责人紧密协作——愿景是客户体验、使能技术、业务需求三者的关键协作产物。其二，CEO（或大型组织中事业部的 GM）必须对愿景产生真实的主人翁感：很多创业公司里 CEO 就是事实上的产品负责人，自然成立；其他公司则需产品负责人让 CEO 充分参与。原因是 CEO 将不得不向投资人、媒体、其他商业领袖、无数潜在客户"推销"这个愿景成千上万次，每一次都是把自己的职位和声誉押上去（putting her job and reputation on the line）。这不意味着 CEO 要亲自创造愿景，但她必须被纳入、其顾虑必须被回应——优秀的产品领导者擅长让他人产生共同的主人翁感。

①核心主张。 令人信服的产品愿景是"不断馈赠的礼物"（the gift that keeps on giving）。它需要被精心传播、被有限度地验证，并被当作招募工具与布道工具反复使用；尤其重要的是——宁可分享愿景，也别分享路线图。

②论据/案例。 传播：值得投入真金白银的时间精力去想怎么传播愿景——愿景的目的是激励，而 PowerPoint 几乎从不能激励任何人。最低限度是做一个愿景原型（visiontype）：它是一种概念原型（conceptual prototype）、一个高保真用户原型，外观逼真但完全是"烟雾与镜子"（smoke and mirrors）的假象，正因如此极易制作，且最重要的是不受"我们当下知道怎么造"的约束。它与产品探索中用的高保真原型的区别在于覆盖范围：愿景原型描述愿景成真后的世界（也许 3 年也许 10 年后），探索原型描述未来几周就会构建的新功能。很多公司还会额外花点功夫,制作一段有脚本的视频来以最佳方式展示愿景原型——展示不同类型用户如何体验产品，并借助音乐和精心设计的脚本的情感力量来放大冲击。另一种有效方式是故事板（storyboarding），就像创作和分享一部电影的提纲——同样聚焦情感与客户体验而非细节。因为愿景要从用户视角讲述，产品设计师必须扮演关键角色。验证：一个常被问到的问题是——能用现代产品探索技术来验证产品愿景吗？答案既是又不是。我们能验证愿景的"需求"（demand）：假如愿景今天就可用,人们是否真有我们以为他们有的问题？问题是否足够严重、现有选项是否足够弱，以致他们愿意接受新方案？我们不能验证的是"解决方案"（solution）——因为我们还不知道方案是什么，最可能要花数年才能发现方案的各个组件。况且,知道在解决一个值得的问题还不够：只有当人们相信你把问题解决得足够好、好到值得他们切换时,他们才会买单。这就是为什么追求愿景在很大程度上是一次"信念的飞跃"（leap of faith）——我们是在赌自己,赌我们能发现兑现愿景承诺的方案。招募工具：强的产品人想做有意义、大于自身的事,想做传教士（missionaries）而非雇佣兵（mercenaries）；你可以谈福利、给他看桌上足球,但最优秀的产品人最在乎的是你的愿景。布道工具：要说服的不只是潜在员工——公司高管、投资人、利益相关者、销售市场、客服与客户成功人员、以及公司内外的关键影响者,都需要理解你试图创造的未来,因为他们都会在大大小小的方面提供帮助。一个关键点:布道永远不会结束(never finished),要计划对同一批人多次传递信息,并预期某人今天被说服不代表明天还信。

③前提/推演。 分享愿景 vs. 分享路线图——这是本章最尖锐的一节。在有直销团队、面向大型企业销售的公司里,销售常被要求向现有或潜在客户分享路线图。要理解这从何而来:这些客户在对你公司下重注,他们不只是买今天的产品,而是买未来许多年的产品,所以想确认你的方向和他们一致,这一点也不无理——而索要路线图往往是他们唯一的选项。问题在于,有经验的产品人都知道:我们以为会带来价值的具体功能,多数最终并没解决底层问题、因而没提供必要价值;花时间构建并发布一个解决不了问题的功能,正是我们竭力要避免的浪费。所以我们宁可分享愿景:客户虽不用这个术语,但他们真正渴望的通常就是愿景。从你的角度,宁可分享愿景也因为——基于你的所学,你几乎必然会频繁改动路线图;但若客户基于路线图里"承诺的功能"做了购买决策,改变战术就难得多。诚然有些公司视愿景为专有信息不愿分享,但 Cagan 更倾向分享愿景——这反而有助于验证愿景;也确实很多公司不被允许分享路线图,因为它会被解读为前瞻性陈述(forward-looking statement),不兑现承诺的功能可能有法律后果。会遇到具体问题,例如"我们这儿用 Salesforce.com,买之前能告诉我你的方案是否、何时与其平台集成吗?"——是否集成是一个战略产品决策,在你理解了集成的性质与目的、并判断它对你的通用产品(而非一次性特殊请求)是否重要后即可回答;时间问题若确需承诺,则作为"高诚信承诺"(high-integrity commitment,详见第七部分)处理。记住:在愿景上固执,在细节上灵活(stubborn on vision, but flexible on details)。分享愿景没问题,分享路线图非常危险。 愿景与架构:工程组织需要愿景,以确保其架构决策能服务于愿景的需要——但通常没必要、也不可取地一次性把愿景所需的完整架构全建出来;关键是工程师知道终局,从而沿途做出好选择,避免日后(甚至多次)返工重构。例如愿景可能暗示产品最终要能高度精确地预测如何个性化用户体验——即便机器学习能力当下还不急用,仅仅知道它要来,就会对工程团队如何架构产品产生真实影响。一个特别尖锐的痛点:Cagan 说最让他沮丧的莫过于——一个深陷严重技术债(technical debt)的组织,好不容易争取到领导支持和资金去做一次重大的重新平台化(re-platforming),却没有一个产品愿景作为新平台架构的依据,于是工程组织被迫猜测未来需要什么,或者干脆只建一个能支撑过去多年所建之物、而非支撑未来数年所需之物的新平台。

①核心主张。 产品原则（product principles）通过陈述"用以指引大量产品决策的价值观与信念"来补足产品愿景。当我们赋权团队、给他们问题去解决时,我们也要给他们做好决策所需的背景(context);愿景是其中一大部分,但探索与交付中总会冒出各种议题——少数重大到需要上报给更广的领导层与利益相关者,而对大多数日常产品决策,原则就是我们能提供给团队的关键信息。

②论据/案例。 大量决策都围绕权衡(trade-offs),而原则帮助照亮"做这些权衡时我们优先看重什么价值"。团队需要理解这些原则及其背后的推理。一个非常常见的例子:在多数产品里,易用性(ease of use)与安全性(security)之间常存在权衡——两者都是对用户重要的收益,且并非总是对立;但当它们对立时,原则就能帮上忙。这种冲突常在追求快速增长时显现:若公司聚焦增长,团队很可能重投易用性、为了去除摩擦而下调安全性的重要性。领导者不难预见许多团队会面临此类权衡——虽无法预见每一种情形,但并非无法事先考虑并陈述出重要原则。伦理(ethics)是另一个好例子:设想一个产品方案在按预期使用时能为一组用户带来真实价值,但团队意识到若被恶意使用,可能以某种方式伤害另一组用户——团队在防止非预期使用(unintended use)方面有何责任?Cagan 鼓励领导者在创造愿景的同时,也准备一套补足愿景的产品原则,并就伦理尽可能多地为团队提供指引。

③前提/推演。 产品团队常告诉 Cagan:原则是他们日常探索工作中最常用的那部分战略背景;随着新技术(尤其机器学习)的出现,这些原则、特别是伦理这一主题,正变得越来越重要。

通往领导力之路。 Cagan 1996 年在网景(Netscape)初识 Audrey,当时她已以"聪明且懂得把事情做成"著称;她大学念的是纯数学与戏剧(pure mathematics and theater)这一不寻常组合。她在互联网刚兴起时就工作在产品与设计的交汇处,有幸师从现代产品设计的先驱之一 Hugh Dubberly(此人当时执掌网景设计,更早曾执掌苹果设计)。离开网景后她加入 Hugh 的设计公司,得以近距离观摩业界最棘手的设计挑战。过去十年她是 DesignMap 设计公司的合伙人,雇用、辅导并共事过数百名产品设计师,参与设计了数以百计的各类应用,并著有《CEO 需要了解的设计》(What CEOs Need to Know about Design,2019)。

领导力要点(以她自己的话)。 她最早关于管理与被管理的经验来自戏剧,其管理风格大多生长于此——多数人 15 岁才能打暑期工,她约 10 岁就开始演戏,一路演到中学、高中、本科乃至毕业后数年,直到在网景遇见设计;舞台上、服装间、后台乃至当导演的无数时光,塑造了她的领导方式。她提炼出几条从戏剧迁移到职场的要义:其一,愿景——正因团队技能极其多元(演员之外还有灯光、布景、音效、服装、换装、舞台监督等等),导演的职责是设定共同目标和未来愿景;这种目标设定既有艺术抱负,也是战略和务实的(观众会响应什么?我们能负担怎样的服装布景?多少演员?什么样的制作能坐满剧场?);她也类似地设定愿景、把目标讲明,并在最终敲定前就目标进行协作。其二,"这不是关于你"(It's Not About You)——导演为某个角色选某位演员,是相信此人对该角色的诠释会很棒;导演界有一条非常古老、非常牢固的规矩:绝不"念台词示范"(no line readings)(即导演把台词念给演员、指望她模仿),这是天大的禁忌,暗示要么导演没本事引出想要的表演、要么演员能拿出的最好东西不过是模仿——想象若全体卡司都被"导演所能做到的最好"所限,那将是多弱的一台戏。卡司与剧组信任导演去把握整体并使之精彩;他们愿冒险信任导演,导演就必须在出岔子时承担责任,而谢幕时(通常)导演并不在台上——这种"揽责、让功"(take-the-blame, give-the-credit)的哲学,戏剧诠释得很漂亮。其三,"带出他们最好的"(Bring Their Best)——导演的最高职责是让每位成员最好的那部分为共同目标服务;导演极少是团队里任何一项工作的最高手,但必须懂行到能欣赏、支持、培养每个人——而她不是最好的,这在某种意义上正是要点。Audrey 说她确信团队每个人在许多事上都比她强,她不是要他们照她的方式做事,而是寻找他们热爱、擅长、尚未自知却极具天赋之处,再把"一团队的才华"组织起来服务于共同目标。她职业生涯最有成就感的经历,是在那些自己都没意识到的人身上识别出才能与天资,再说服他们相信自己很棒。她作为员工最受激励的,是为 Marty 和 Hugh Dubberly 这样的管理者工作——他们都以特定方式、以一种连她自己当时都不敢相信的程度相信她,虽有点令人生畏,却让她拼尽全力去不负所望。她还谈到批评(Critique)——导演会定期"给笔记"(give notes),节奏可能按小时、按场、按场次,给出建设性反馈("很好,多来点"或"完全没看懂你那个选择")是任何与导演的关系中理所当然之事:相互尊重与协作要求清晰、直接的反馈。以及庆祝(Celebration)——戏剧与电影里庆祝是内建的(首演夜、闭幕夜、杀青派对),每个人都会停下来回味共同的成就;她认为商业里庆祝得太少,会想方设法大大小小地表彰个人与团队。她总结:作为领导者,没什么比这更棒——召集一支有才华的卡司,给他们一个能为之兴奋的故事,辅导他们抵达潜能,然后看着他们共同创造出特别的东西。

①核心主张。 因为团队拓扑定义了团队之间的边界、确立了每支团队要考虑的问题范围,它是产品领导者面临的最重要决策之一。为赋权而优化,要求平衡三个相互关联的目标:所有权、自主权、对齐(ownership, autonomy, alignment)。

②论据/案例。 Cagan 警告:太多公司不给这个决策应有的思考,拓扑往往沿"阻力最小的路径"自发形成——照搬现有组织架构图、按工程技能分组、或跟着某个业务负责人的运营职责走;这些因素有时能合理地划界,但决策应在权衡多种因素后有意为之,绝不能仅因"它容易"就定。很多情形里拓扑是多年前定的,人们不愿改;曾经合理的分组如今正制造不必要的依赖与复杂性、反噬赋权,此时领导者可能必须做出重组的艰难决定。三目标拆解——所有权:它比团队目标更大,它设定每支团队在功能、体验、质量、性能、技术债等方面的完整职责范围,团队要在此范围内做必要权衡。当一支团队的职责范围很窄,成员很难保持动力,会觉得自己只是大轮子里的小齿轮(a small cog in a big wheel);反之,看到自己负责一个有意义问题的团队,会因与更大事业的连接而备受鼓舞,有更强的主人翁自豪感。多数情况下更大的范围更利于赋权,但若范围相对团队规模与技能过宽,赋权也会受损。Cagan 举例:一支拥有某产品体验、但连做基本改动都需要懂一两个复杂系统的技术知识的团队,会难以获得创新所需的理解深度——这种过高的认知负荷(cognitive load)反噬赋权。赋权不只取决于范围,还需要所有权的清晰度(clarity):当团队搞不清哪些工作归自己,赋权就被削弱;好的拓扑解决的所有权问题应多于它制造的问题。自主权:这个概念常被误解——它不意味着团队永远不该依赖其他团队,也不意味着团队可以爱干嘛干嘛;它意味着当我们给团队问题去解决时,他们有足够的控制权,能以他们认为最好的方式解决——而依赖过多的拓扑会让这变难。我们期望团队用产品探索的工具去探索不同选项后再定方案,并信任他们的决定,因为他们处在做决定的最佳位置。每种拓扑都需要某些团队间依赖,但赋能型拓扑会最小化这些依赖。Cagan 举反例:严格按技术子系统划分团队的拓扑,会让任何单一团队都难以拼出对真实客户问题的整体方案(holistic solution)。对齐:指团队边界与战略背景其他方面的契合程度;对齐高时,团队依赖更少、决策更快、与业务级成果(outcomes)更紧密——对齐高则赋权改善。对齐通常是拓扑中最复杂的方面,维度太多,最重要的两个是架构与业务。先看与架构的对齐:理想情况下架构基于产品愿景(架构的职责正是去使能愿景),那么与技术架构对齐的拓扑也会自然与愿景对齐,团队既能拥有有意义的范围、又能被授予做重大产品决策的自主权;但在背负大量技术债和/或遗留系统(legacy systems)的公司里,团队可能与架构不对齐,工作被依赖和复杂性堵塞,连简单任务都耗时漫长甚至根本不可行。与业务的对齐:涉及产品团队如何与组织关联——不同业务单元、不同的市场进入(go-to-market)策略、不同客户类型或市场细分。

③前提/推演。 永远不会有唯一"完美"的拓扑;有许多权衡要做,但总目标是为赋权而优化,而最好的途径就是驱动所有权、自主权与对齐。

①核心主张。 SVPG 观察并咨询过数百家科技公司的拓扑,提炼出两类最基本的产品团队:平台团队(platform teams)——管理服务以便其他团队轻松复用;体验团队(experience teams)——负责产品价值如何呈现给用户与客户。任何拓扑都必须同时考虑底层技术架构与更广的战略背景,因此产品与工程领导层必须一起确定拓扑。

②论据/案例。 平台团队提供"杠杆"(leverage),因为公共服务只实现一次却能在多处使用,例子包括:负责认证(authentication)或授权(authorization)等共享服务的平台团队;维护可复用界面组件库的平台团队;为开发者提供测试与发布自动化工具的平台团队。平台团队也用于管理复杂性,因为它们能封装产品中特别困难或专门的领域,例子包括:为与遗留系统集成创建抽象层的平台团队;管理支付处理(payment processing)的平台团队;管理高度专门的税费计算的平台团队。Cagan 强调:终端客户、甚至你的高管和利益相关者,可能对平台团队的工作毫无直接可见性,但别以为这些团队不重要——事实上在许多顶尖产品组织里,公司里最好的工程师正因杠杆与重要性而被请去做平台团队;小公司可能由单一平台团队提供平台,而许多大型顶尖科技公司里多达一半的产品团队是平台团队。更关键:平台为体验团队降低认知负荷——体验团队无需理解平台服务如何实现就能使用,从而把精力聚焦在要解决的客户或业务问题上。体验团队负责产品被用户以应用、UI、解决方案或旅程(journeys)的形式体验的方式。用户可能是购买产品的客户,也可能(在 B2B 产品里)是客户的员工:凡为"属于公司客户的任何人(含消费者)"做体验的团队,称为面向客户的体验团队(customer-facing experience team);用户也可能是公司自己的内部人员、但对交付必要客户体验至关重要(例如客服坐席或店内店员),为这类内部员工做体验的团队称为使能客户的体验团队(customer-enabling experience team)。无论面向还是使能,真正的体验团队若其产品宕机,会对客户产生直接影响——例如内部坐席因系统宕机而无法解决客户问题,我们就知道这是一个真正的产品体验。如同平台,一个产品体验可由单一团队或拆给多支团队(按用户类型、市场或细分、客户旅程的步骤等)。②最精彩之处在于对比:在太多公司里,拓扑被定义成每支体验团队只拥有端到端体验的极小一块——这种处境下,每支团队即便做小改动也得与其他每支团队协调,难有"我能产生影响"之感;相反,体验团队在被赋予尽可能多的端到端职责(end-to-end responsibility)时最被赋权,这样的团队有有意义的所有权感、更多自主权,也更容易看见自己对解决客户问题、达成业务结果的影响。

③前提/推演。 许多强公司发现:丰富的平台是为体验团队赋予更广(端到端)所有权的有力工具——平台降低了使用底层技术所需的负担,为体验团队腾出认知容量去拥有客户问题的更多方面。

①核心主张。 平台团队通过抽象掉服务与架构的底层复杂性,提升其他团队的赋权水平。但给平台团队本身赋权总有点棘手,因为体验团队的目的是为用户客户解决问题,而平台团队的目的其实是使能体验团队去更好地为其客户解决问题——所以平台团队的贡献是间接的(indirect)。

②论据/案例。 要理解这如何影响平台团队,需把所有产品团队(平台与体验皆然)必做的两类工作分开:一是推进团队目的的主体工作;二是某种程度的"保持灯亮"(keep-the-lights-on)义务——即维持业务运转的日常工作,如修复关键缺陷、处理性能问题、为合规等不可商量之事增加关键能力(有些公司称之为 BAU/"业务照旧",但 Cagan 从不喜欢这个词,因为太多公司以为这就是产品团队的全部)。平台团队往往比一般体验团队有更多"保持灯亮"事项,因其工作性质就是使能那些依赖它们的团队——这可能占平台团队工作的 10%,也可能接近一半。把"保持灯亮"剥离后,平台团队推进平台前进有两条主要途径:共享团队目标(shared team objectives)与平台即产品目标(platform-as-a-product objectives)。共享团队目标最常见:平台团队与一支或多支体验团队拥有同一目标,共同探索与开发方案;协作有时极深、几乎像一支团队那样紧密合作,有时则更分段。深度协作案例:设想一个内容管理系统(CMS)产品,有一支管理后端存储与内容 API 访问的平台团队,和一支管理面向用户的内容工作流的体验团队;原本系统只支持图片内容,但因新的市场扩张策略,现在需支持视频内容——两队可有一个"支持视频"的共享目标,必须紧密合作来确定恰当体验及其实现方式。分段协作案例:一家电商公司要新增一种支付类型——平台团队管理所有支付复杂性并以 API 形式暴露给体验团队(这个 API 充当两队之间的一种"契约"[contract]),负责结账体验的团队创建面向用户的流程,平台团队实现与后端支付流程的集成,两队在测试与交付时汇合。无论深度还是分段,关键是平台团队与体验团队共享同一战略背景与目标——他们在"为何这件事重要、它对业务意味着什么"上是连通的。平台即产品:有些公司的产品本身就是平台,卖的是让客户用户(通常是开发者)在其能力上构建的 API,称为外部平台(external platforms)——此时平台就是产品、被当作产品对待,用户虽是开发者而非消费者,但仍是真正的产品;一个新兴趋势是越来越多公司开始把内部平台也当外部平台产品那样去经营。这类平台产品的目标常看起来很像体验产品的目标——增长客户数、让客户采用能力、(外部平台情形下)更好地变现客户;若遇到重大质量/性能/开发者体验问题,与其只当作日常"保持灯亮",不如把它上升为一个团队目标。

③前提/推演。 底线:谈到给平台团队赋权时,只要你在心里把日常"保持灯亮"工作与推进平台前进的主体工作分开,那么平台团队的团队目标与赋权水平就与体验团队相当。

①核心主张。 体验团队在被赋予尽可能多的端到端职责时最被赋权;而这更可能发生在每支团队的所有权范围顺着业务的自然脉络(销售渠道、市场细分、用户类型)划分时——这通常意味着创建一个按客户对齐的拓扑(a topology that is aligned by customer)。

②论据/案例。 按客户对齐的例子:按用户类型或画像(如乘客团队、司机团队)、按市场细分(如电子产品团队、时尚团队)、按客户旅程(如新手引导团队、留存团队)、按销售渠道(如自助服务团队、直销团队)、按业务 KPI(如新用户增长团队、转化团队)、按地理(如北美团队、亚太团队)。这种对齐让体验团队的所有权范围匹配业务所需的成果,业务成果与产品工作之间几乎无需翻译,团队可被授予直接解决业务问题的自主权。Cagan 按产品类型给出多组对齐范式(声明非穷尽、也非唯一办法,而是被证明有效的常见模式):媒体产品——杂志、新闻站、视频点播可按内容板块或子刊物组织,所有内容管理与公共能力由平台团队提供通用服务(这些平台人员可能占产品人员多数),每支体验团队覆盖某一媒体类别(如体育、本地新闻、天气)或品牌的端到端需求,从而契合各类别常见的不同业务目标与市场进入策略。电商产品——可仿媒体模式,尤其当购物体验因品类差异显著时(如汽配 vs. 活动门票 vs. 珠宝);产品同样建在丰富的公共服务平台上(目录管理、计费、账户管理等),体验团队按品类对齐。企业产品——常须为不同客户细分做专门化:有时按客户的垂直行业(制造 vs. 金融服务 vs. 零售)、有时因市场进入策略大不同、有时因客户规模(中小企业 SMB 走自助门户,大客户需销售团队和供定制的 API);按对公司最相关的细分来组织体验团队即可。市场平台产品(Marketplace)——许多产品的目的是连接目标互补的不同群体(买家与卖家、司机与乘客、酒店与房客),多数是双边、也可更多边;由于各边个体的需求(及支撑各边的业务)往往迥异,常常按市场的"边"来组织体验团队会更赋权。使能客户的产品——为提供某关键客户体验环节的内部员工(如客服、店内员工)打造工具与系统,同样按不同类型内部用户的端到端需求来对齐。一个收尾要点:拓扑无需把所有体验团队都对齐到单一维度(如垂直行业或客户规模),有些拓扑在不同区域采用不同的对齐维度,当那样更合理时。

③前提/推演(拓扑与设计、拓扑与汇报结构)。 拓扑与设计:多数公司明白跨职能团队(至少体验团队)应含一名专属产品设计师,这是对设计之于强产品何等重要的承认;但偶有设计负责人偏好另一种模式——内部代理模式(internal agency model),即设计负责人手握一支服务型设计团队,产品团队需向其"提需求"来出设计。Cagan 公允地承认此法确有优点(尤其在确保设计的整体视角上),但借林-曼努尔·米兰达(经 Aaron Burr 之口)的话说——"身处事情发生的房间里"(in the room where it happens)至关重要;内部代理模式下设计师通常不在关键决策发生的房间里,于是设计师乃至我们的用户都得为此付出代价。设计太重要了,不能当作一项内部服务来运营,它必须是产品团队的一等成员(first-class member),如同产品经理和技术主管;设计经理可通过建立设计标准/规范/设计系统、评审设计师工作、开展设计策略与评审会来确保整体视角(对用功能团队[feature teams]的公司,这其实无关紧要,因为等设计师首次被咨询时关键决策早已做完)。拓扑与汇报结构:工程汇报结构常按特定技能分组(数据工程师、前端工程师、移动工程师各自汇报给不同经理),以便经理为每位工程师提供技能专项辅导——这本身不是问题,但技术领导若想让产品团队完全对齐这种汇报结构(如组建只含前端工程师的单一产品团队),则很少能产出被赋权的团队,因为团队除了技术技能外不与任何东西对齐、而技术技能很少与业务所需成果真正相关。Cagan 举例:把组织拆成 web 团队、iOS 团队、Android 团队、后端团队的拓扑,会让任何团队都极难拥有一个多渠道的客户体验。著名计算机科学家 Melvin Conway 提出的康威定律(Conway's Law)指出:任何设计系统的组织,都会产出一个结构镜像该组织结构的设计——换句话说,当心"把你的组织架构图给运出去了"(shipping your org chart)。跨职能团队最大的好处之一,就是成员可以按"什么对产品最好"来确定;底线是:汇报关系没有理由去决定团队拓扑。

①核心主张。 团队成员的物理位置是创建拓扑时另一个重要而实际的因素。即便在疫情前,因人才短缺与技术枢纽高昂的生活成本,就已有转向替代办公策略的趋势;选择从"全面拥抱远程"到"整体搬迁总部"形成一个光谱,而远程办公室(remote offices)是一个非常有效的中间地带。但贯穿全章的总原则是:作为一般原则,我们应为产品团队而优化(optimize for the product team),而非为经理、为接近客户或其他任何东西而优化。

②论据/案例。 光谱一端是全面拥抱远程员工(好处:几乎能从任何地方招人,人们可住在偏好之地);另一端是想让所有人在同一办公中心、却因本地缺人才与高生活成本而把总部搬到新地点;中间地带远程办公室则是在全球(尤其工程设计人才供给好的城市中心)开设办公室、在那里组建产品团队、必要时辅以远程员工——既接入本地人才,又保留办公室的好处,但也会给组织(尤其提供辅导与监督的经理)带来额外负担。Cagan 逐一拆解"就近"(proximity)的多种形态及其权衡:与团队成员的就近——团队是同址(co-located,都坐一起)、完全分布(fully distributed,各自在家)、还是混合(如产品经理/设计师/技术主管坐一起,其余工程师在家或在别的办公室);尤其对依赖真正创新的团队,同址是显著优势,因为产品探索的动态依赖产品管理、产品设计、工程之间的密集协作——远程并非不可能,但更难;若工程师在别处或远程,额外沟通的多数负担会落到技术主管身上。与客户的就近——若你为印度的消费者或企业建服务,落地印度有真实优势;但我们有不错的工具去远程连接全球用户客户,尤其当当地有人帮忙处理语言或文化问题时,可以靠产品经理与设计师的额外努力克服地理距离。与业务伙伴的就近(如运营团队、客户成功团队)——类似与客户就近,靠出差/电话视频/加强外联(主要是 PM 与设计师)可克服。与经理的就近——本地时经理更易评审工作、观察行为、提供辅导,但中大型组织里经理常被迫管理异地或在家的员工,可靠额外努力克服。与其他产品团队的就近——团队常彼此依赖、需协作解决大而复杂的问题,物理相近更易,但可靠额外努力(主要在工程师和 PM:加强外联沟通、出差,以及一种叫蜂拥[swarming]的技术)克服。与高级管理者的就近——视公司文化与高管强弱,高管可能真的需要靠近团队;团队在远程时,产品经理需额外努力维系与高管和利益相关者的关系,经理常需扮演更大角色。

③前提/推演。 Cagan 给出两个最常见的权衡情境来诠释"为产品团队而优化":其一,若要在"把 PM 和设计师放在总部(靠近他们的经理、高管、利益相关者)"与"把 PM 和设计师放在工程师身边"之间选,按此原则我们宁可让 PM 与工程师同址;其二,若要在"PM 和设计师靠近客户"与"靠近工程师"之间选,我们仍宁可与工程师同址。但他强调这些是一般原则,可能有需另作选择的情形——至少重要的是知道涉及的权衡,以及能做什么去缓解劣势。

①核心主张。 多数公司已有某种现存拓扑,但它总得有个起点;且无论你的初始拓扑多么赋能,它都不会自行保持那样——地面上的现实总在变,有时变到需要改动拓扑。无论何种原因重审拓扑,都应通过所有权、自主权、对齐这三个维度为团队赋权而优化。

②论据/案例。 拓扑的起点:对创业公司,通常发生在工程师数量增长到约 15 人以上时——公司意识到早期的赋权正在协调负担下受损、越来越难做决策和把简单的事做成,于是决定组建两三支跨职能产品团队来"分而治之",这些划分决定确立了拓扑;对并非生于产品团队模式的较大公司,起点通常是它们转向敏捷(Agile)、被要求围绕小而持久的团队来组织之时;还有些拓扑是为响应产品愿景和/或产品架构的重大变化而确立——若公司对其产品的战略背景做了剧烈改变,拓扑就可能需要重审。演进拓扑——几个可能需要改动的情形示例:一支团队为扩张到下一市场细分而需把工程资源翻倍;一项新策略包含让目前由数支团队维护的某产品退役(sunsetting);一项新策略要把某团队的核心能力通过内部平台开放给其他团队;一项新业务目标要为扩张市场开发产品;一次对架构的重大重构(refactoring)。拓扑预警信号(warning signs)——即便上述都未触发,好领导者也总在与团队和成员核对、并透过赋权透镜评估拓扑;几个可表明拓扑需要关注的信号:你频繁地在团队间调动开发者;你必须频繁介入去化解依赖冲突;开发者抱怨为发布简单东西而对其他团队有太多依赖;团队的所有权范围非常有限;开发者必须在太多领域应对太多复杂性。

③前提/推演。 一条贯穿的克制原则:应尽可能保持现有团队完整——整个组织已为建立利于良好协作的关系投入巨大,因此只要可能,宁可给现有团队一套新职责,也别拆散团队、把人重新分配到别的团队。确有需要更重大改动的时候,但要小心别改得太频繁:若你持续地一年多次对拓扑做重大改动,那是某处出问题的信号。 拓扑决定了人们每天与谁共事、做什么、互动的性质,改变它可能极具破坏性;即便只是为应对紧急优先级而临时把某人挪到另一团队,这种关照同样必要——挪动对被挪的人很难(要适应新团队新工作),对被留下的团队也很难(常被迫想办法填补空缺)。

通往领导力之路。 Cagan 在网景初识 Debby,当时她执掌负责网景浏览器(Netscape Browser)的工程组织;她是 1995 年随 Collabra 被收购而加入网景的——你也许没听过 Collabra,但那是一支拥有极强领导者的非凡团队,这些领导者很快成为网景空前增长的关键。Debby 来自中西部,在密歇根大学念数学与计算机科学,后移居硅谷、在斯坦福攻读计算机科学,成为软件工程师并很快在规模渐大的组织里成为工程领导者。在网景,她奠定了"业界顶尖工程领导者之一"的声誉;后来通过风险投资人与业界友人的网络,她成了"想要显著或紧急地提升你工程组织水准时该打电话找的那个人"。

领导力要点(以她自己的话)。 Debby 专门进入那些有大好商业机会、但工程要么需扩展到下一台阶、要么因种种原因难以有效执行交付产品的公司(多为创业公司),迄今已为 50 多家公司做过此事,其中许多今天非常成功。她到任时常发现一些沮丧的领导和不快的工程师、双方信任都在侵蚀,跑着功能团队和路线图;她必须赢得这些有才华的专业人士的信任、调动他们、把组织转型为高效、可扩展的产品团队——Cagan 见过前后对比,改变是戏剧性的(dramatic)。她的做法:每家公司都不同,她先与组织各处的人交谈、倾听他们怎么说、以及人们认为她能做什么来改善处境;同时观察组织会议中的互动、以及那些会议的系统与产物,以理解公司独特的人际动态与流程挑战。在这段"摸底期"(intake period)后,她通常发现需要聚焦同样四件根本而关键的事:①示范从顶层开始(The Example Starts at the Top)——若工程组织难以扩展或交付,问题很可能来自顶层;许多创业公司创始人或 CEO 从未与强工程组织共事过,常对技术的角色、对工程师作为产品管理与设计之伙伴的必要贡献有根本误解,且常不自知自己在工程组织的成败中扮演的角色——所以这里必须做"教育"。②聚焦与策略(Focus and Strategy)——建设和扩展成功公司极难,每家公司想做的工作都远多于做事的人,所以聚焦不可或缺,而产品策略正是让我们从有限资源与人力中获取最大产出的东西;细看之下,快速扩张或正陷困境的组织往往没有真正的聚焦、没有真正的产品策略,想一次做太多事会损害即便最好的工程组织;很多时候她的到来正是公司重建"聚焦"含义所需的契机——她通常不能替他们做选择,但能坚持要求领导者做出必要的艰难选择。③建立信任(Establish Trust)——人是任何公司的心脏与灵魂,信任能让人们有效协作、共同创造和成就远超各自单干所能想象的(这正是成功公司的魔法);各职能各有其独特专长,在最好的产品团队里工程的独特价值是持续用技术创新交付制胜产品,当工程组织被认为无法交付时就会有信任问题(高管不信任工程、工程不信任高管),缺乏信任引发各种坏行为与士气问题、通常导致向下螺旋;重建并维系信任需要在组织每个层级(自顶层始、也自工程师始)都下功夫(包括聚焦与策略)。④兑现承诺(Deliver on Promises)——她要让工程师明白:当他们做出承诺时,兑现很重要;这里有"为何/何时/如何"三个组成部分需要整个组织理解与支持,既要辅导高管"聪明地判断他们何时真的需要一个日期",也要辅导工程师"如何评估工作、如何严肃对待交付的义务"。具体有两个方面:第一,要替换掉他们当前为预测日期而玩的任何不可靠的估算游戏(estimation games),改为严谨地评估"把某物做到能用并交付究竟涉及什么"——这往往很难,常需新做法和大量练习,她笃信"爬、走、跑"(crawl, walk, run),这可能意味着造可行性原型(feasibility prototypes)、或让工程师花时间去学习或充实某物,无论何种途径,他们都要能在日期真正需要时以高置信度合理预测日期;第二,工程师一旦做出承诺,就要极其严肃地对待并交付——这种"说到做到"(do what you say you're going to do)的心态最好对公司里每个人每支团队都成立,无论如何,工程必须以"信守承诺、说到做到"著称。Debby 收尾:扩展工程组织绝非小事,但好消息是今天已有许多例子证明这种向前的推进与成功转型确实发生过,组织能够自豪地交付其公司与客户所依赖的产品。

核心主张：聚焦不只是"决定做什么、不做什么"，而是挑出少数几件真能产生影响的事。Jim Barksdale 的话被作者引为本章题眼——"要紧的事，就是让那件要紧的事始终是那件要紧的事"。几乎每家公司的领导都自认"我们在聚焦上做得不错"，但他们往往需要一次现实核对：他们以为本季度/本年度至关重要、非做不可的事，数量常常多出一个数量级——本该是 2–3 件真正要紧的事，他们却列了至少 20–30 件。领导者爱"多下注"而非"下最好的注"，源于错失恐惧、要回应每个竞争对手、每笔丢掉的单子、每条客户诉求——可以理解，但需要一次"干预与重置"。

最精彩的案例：音乐服务 Pandora 的"优先级流程"——让各利益相关方用预算去"买"功能团队的开发产能，买到额度用完为止。Cagan 一读就认出这是完全没有产品战略、尤其没有聚焦的典型，加上对功能团队的依赖、毫无真正产品管理的迹象，结局注定：功能造了一大堆，却鲜有成果或创新。后来几年果然如此——2011 年以每股 16 美元 IPO 的股价一路阴跌，到约 8 美元时被卖掉。这是"只排优先级、不聚焦（prioritizing but not focusing）"的活教材：产出工作很容易，产出成果却难。他引 Stephen Bungay：制造活动从不是问题、恰恰因为太容易反而让真正的难题更难解——难的是把对的事、有影响的事做成。作者还讲了亲历的小例子佐证"聚焦的威力"：他在 HP 应用研究实验室做新工程师时，资深同事教他用性能分析工具——整个代码库到处可优化，但绝大多数优化用户根本感知不到；时间几乎都耗在极少数几个点上，只有专攻那几处才有真实影响。多数公司却是"全员都做一点性能"，结果哪儿都没动针。

前提/推演：聚焦还有一个非常实际的理由——在制品上限（WIP limits）。这个在 Kanban 里常见的概念说：同时在做的事越少，吞吐（throughput）越高；不设限，工作就在瓶颈处堆积、不断切换上下文、出活反而更少。这一概念在单个团队层面有用，到了整个产品组织层面就变得绝对关键：当组织同时推 20、30 乃至 50 个"高优先级"目标，问题只会成倍恶化——每个团队都疲于应付，且每项高优先级工作对领导层都有真实成本（管理时间、决策、监控追踪、人员配置）。Rumelt 一锤定音：好战略靠把精力与资源集中到一个或极少数枢纽性目标上，其达成会引发一连串有利结果。领导者若不愿或不能做这些取舍，产品战略从一开始就注定失败。

核心主张：洞察是产品战略的地基，也是作者最爱、却最难的环节——你要去生成、识别并撬动那些能为战略奠基的洞察，而它们常常藏在你收集的成千上万个数据点之中。三条前置认知：其一，别指望"照着填空"的套路或框架——产品战略需要真实的思考与努力（Rumelt：好战略不会从某个管理工具/矩阵/图表里蹦出来，而是有才能的领导者识别出情境中那一两个关键议题——能成倍放大努力效果的支点——再把行动与资源集中其上）。其二，洞察从不会凭空降临：你可能在淋浴时灵光一现，但那是建立在你已花了数小时研究数据、客户、使能技术与所在行业之后；战略上下文（公司目标、公司记分卡/仪表盘、产品愿景）正是任何重大洞察的基础。其三，洞察可来自任何人、任何地方——行业分析、与销售的闲聊、一项新使能技术、客户一句看似随意的评论、甚至一篇学术论文；但没有准备，洞察摆在眼前你也认不出。

论据/案例：作者列出四个稳定有效的洞察来源，并给出反例校正。定量洞察（quantitative）——大量成功战略的根基来自产品数据分析（商业模式、获客漏斗、留存因子、销售执行数据等）；你常会先有一个关于数据的想法，再构造测试去取你需要的数据，组织越早擅长跑这类实时数据测试越好。定性洞察（qualitative）——用户研究的全部价值就在洞察，它多为定性、"不具统计显著性"，但往往最深刻、能改写公司走向；研究界把洞察分评估型（evaluative，测我们这个新点子行不行、为何不行）与生成型（generative，发现了本该追却没追的新机会）。这里有个常见混淆：产品探索里我们多在做评估型学习（已有要解的问题，找能真正奏效的方案），但每次与用户互动都有机会撞见更大的机会——哪怕用户喜欢你正在测的东西，你也可能意识到还有更大的机会，这就是生成型洞察。技术洞察（technology）——使能技术不断变化，偶尔一项新技术让长期难题以"刚刚才可能"的新方式得解；新技术常吓退领导者，或让其误以为必须找第三方，但若技术对你重要、公司就该自己学，而且越快越好——最好的组织里，往往是被赋能的工程师主动识别出这些技术、并以原型形式把可能性带给领导。行业洞察（industry）——不只看竞争格局，还看大行业趋势、其他行业可借鉴的洞察、其他地区相似市场的洞察。这里作者给出最精彩的反例：不少 CEO 把行业洞察外包给麦肯锡、贝恩、BCG 这类咨询公司，但他坦言对此感受复杂——它们有两大不利因素：其一，其专长几乎总在业务战略（business strategy）而非产品战略（甚至分不清两者区别）；其二，单次合作时长通常不足以让其对你的业务深入到做真正产品战略的程度，于是其洞察往往不被产品团队视为相关。他的解法：找一个愿做长期合作、能成为团队可信成员的小团队或个人；或干脆把这类顾问招进产品组织，他们常能被辅导成极强的产品经理与产品领导。

前提/推演：四类洞察必须被共享（shared learnings）。大组织里"半场仗"在于让对的洞察在对的时间进到对的人脑子里——团队在探索中学到很多，但学习极易只停留在本团队；最常见的分享方式是写进邮件/Slack/报告，但这"几乎从不奏效"。产品/设计负责人往往是第一个把不同团队的学习连点成线、看出真机会的人。作者一句点睛：领导者得到的是他们索取的数据，而非他们真正需要的数据——尤其在做有洞察力的战略决策时。这正是每周一对一（1:1）的重要价值，也再次印证"赋能团队不需要更少的管理，而需要更好的管理"。他长期倡导一个实践：产品负责人应汇总各团队的关键学习与洞察，在每周/双周全员会上择要分享——既帮全组织（含其他团队与利益相关方）理解每周产生的洞察，又逼负责人真正吃透洞察（而非邮件里转个状态），更因为很难预判关键洞察在何处影响最大，故须广泛传播、尤其横跨各团队。章末还补了一个重要概念——愿景转向（vision pivot）：理想顺序是愿景→战略→执行，但并非总线性；当战略或探索中撞见一个"改变一切"的洞察、指向更大或更好的机会，公司在与高层及董事会讨论后可决定调整产品愿景去撬动它——Slack、YouTube、Facebook、Netflix 都经历过。但作者一再谨慎提醒：行业的大问题恰恰是对产品愿景放弃得太早（引 Bezos："我们要对产品愿景固执"）；愿景转向只适用于"洞察指向更大机会"时，而非"发现问题比想象的更难"时（后者几乎永远成立）。

核心主张：到这一步，已聚焦于极少数关键难题、并做了苦功识别出能驱动战略的洞察，现在要把洞察转化为行动——而这里正是岔路口：把洞察变行动有两种方式，由此可看出一家公司是真心做赋能团队、还是仍沉迷功能团队。差别归根结底是一句话——你给团队的是要造的功能，还是要解的问题。多数时候差别很明显（"给在线帮助加视频" vs.“提升新用户上手成功率"），但有时很微妙（"我们需要一个 App" vs.“用户需要随时随地访问我们的服务"）。第一例里"加视频"只是提升上手的数百种可能改进之一；第二例里"做 App"很可能就是"随时随地访问"的主要方式，差别细微，但仍有多种达成方式，应尽量给团队最大回旋余地去想最优解。

论据/案例：若领导自认已知道执行战略所需的功能与项目，多半会把它们放上产品路线图（roadmap）、派给相关团队——这就是雇佣兵团队（team of mercenaries）；若领导希望团队对问题有主人翁感、为"发现并交付能产生必要成果的方案"负责，就会给团队尽可能多的自由度——这是传教士团队（team of missionaries）。作者旗帜鲜明站赋能模型一边。需注意：赋能不等于给团队一张空白支票——总有约束与上下文（如不得违反既有合同或合规约束）。管理"要解的问题"有多种技法，最流行的是 OKR（objectives and key results，目标与关键结果）：目标即需解决的客户或业务问题，关键结果即如何衡量进展。公司目标（company objectives）已作为战略上下文讨论过；要启动行动，则需给各产品团队具体的团队目标（team objectives），详见第七部分。

前提/推演：但作者特别点出——其实你根本不需要 OKR 或任何技法：所需的只是一位懂行的领导坐下来、向相关团队讲清战略上下文（含产品战略），告诉每个团队"你们要解哪些问题、应衡量哪些业务结果"；团队若有对的知识与技能，自会动手。OKR 只是把这些对话形式化的技法，且仅当你已按赋能团队配置人员、领导已尽责做出有效战略并愿意托付团队去解题时，它才有用。赋能也绝不意味着"撒手不管、听天由命"——要在战略上成功，仍需大量主动管理，这正是下一章主题。

核心主张：聚焦、洞察、把洞察转成各团队的目标——这些都是必要准备，但作者以经验断言：领导若到此为止，季度末必失望。原因是一句军事化的真理——没有任何产品战略能在与现实的首次交锋中幸存。无数问题与障碍会冒出来，团队多数能自行处理决断，但很多情况下需要你去移除障碍、提供协助；除非领导主动地识别、追踪、化解这些障碍，否则进展寥寥。

论据/案例：作者列举若干典型障碍——团队在规划时漏了一个依赖，如今依赖另一团队、而那团队正被自己的目标占满；探索中发现需用一项今天没有权限或不掌握的技术，需迅速获取并学习；突发重大客户问题，组织手忙脚乱要兼顾"照顾客户"与"推进目标"；某资深利益相关方提出影响关键目标的重大顾虑，团队需要快速决策。产品负责人主要的信息来源是与产品经理的每周 1:1（紧急事则教练 PM 立刻找你、别等下次 1:1）；会上你听取障碍、教练最佳处理方式，有时需要你亲自去和关键干系人谈、找一名额外工程师、或去和另一团队沟通协助需求。

前提/推演：作者反复划清边界——别把这与命令-控制式管理混为一谈：你不是接管控制、对团队发号施令，而是在回应他们的求助；更准确地说这是仆人式领导（servant leadership）——你被请去帮忙清除一个障碍。在公司日常的种种紧急与打断中，很容易半个季度过去目标却几无进展，所以每周追踪与教练才如此重要：你作为管理者既确保团队在推进，也确保重要的学习/洞察、重大问题被及时分享给你、得以汇总并扩散给相关团队。教练与战略管理与其说是两种不同职责，不如说是同一组对话的两面。再一次——赋能团队不需要更少的管理，而需要更好的管理。

领导之路：作者 2009 年初识 Shan-Lyn，当时她是纽约高速成长公司 Gilt Groupe 的唯一一名产品经理，潜力已一眼可见。她本科学市场与经济，斯坦福读完 MBA 后先在雅虎做了两年，再投身创业；在 Gilt 搭建产品团队四年后，她创办了自己的公司 Zola——一家在线婚礼登记与筹办公司，至今已成长七年，服务被各地准新人喜爱与依赖；Zola 被视为纽约最有前景的成长期公司之一、也是最佳科技雇主之一。

领导实践要点（Shan-Lyn 自述）：① 她最享受的是"造出世界没见过、但人们一见就觉得'以前没它怎么活'的东西"——带来真正喜悦的产品。② 与联合创始人 Nobu Nakaguchi 创办 Zola 时，他们不仅有帮助新人办婚礼的愿景，更有"想在什么样的公司工作"的愿景。③ 她讲了一个被反复引用的经历：前一份工作中，一位领导反馈她"不是好领导，因为工程师太喜欢她了"——若她称职，工程师本该抱怨她施加的压力；她试着改了一阵，很快意识到这条路只会损害协作、击碎信任、并很可能丢掉所依赖的创新。④ 她和 Nobu 都坚信创新来自被赋能、强大且处在可信环境中的人，并愿意"押上整个公司"去赌这一点。⑤ 文化外显：厨房里挂着 NO ASSHOLES（不要混蛋）的牌子，还有 NO POINTING FINGERS, NO POLITICS, NO GAMES（不甩锅、不搞政治、不耍手段）。⑥ 把多样性从一开始就设为每个空缺岗位的明确目标——不仅技能与才干多样，性别、取向、教育、解题方式皆然，因为用户（准新人）形形色色，多样性在每个层面都有助益。⑦ 重视协作与速度：看似反直觉，但他们发现"早协作"不仅带来更好的结果、更带来更快的结果——任何重大决策前都先征询并考量公司内其他人的意见；同时尽快把想法摆到客户面前，因为真正的学习正发生于此。⑧ 几年前一次严重车祸让她深受触动、学会更活在当下；做高速成长公司的 CEO 很苦、要求高且不断攀升，但她每天都在做热爱的事、与所爱之人共事，并为还活着再做一天而心怀感恩。

核心主张：团队目标的根本要义就是赋能——靠两件事实现：(a) 给团队一个要解的问题而非一个要造的功能；(b) 确保他们拥有必要的战略上下文以理解"为什么"、从而做出好决策。最该理解的一点是：团队目标首先是要给团队空间去为困难而重要的问题想出方案——这与典型路线图（给团队一份排好序的功能/项目清单）形成鲜明对比；若那些功能/项目没解决底层问题，那么即便我们交付了"被要求造的东西"，我们仍然失败了。行业学到的一条大教训是：工作如何被指派，至关重要（How work is assigned matters）——理由有四：最适合定方案的是离问题最近、且具备必要技能的人（即产品团队）；我们要团队为达成结果（outcome）负责；若我们指定要造的功能、而该功能没产生必要结果，就无法问责团队；给问题与解题空间，团队会对问题更有主人翁感，且第一版方案若没达成目标，他们知道必须持续迭代或尝试别的路径直到奏效。

前提/推演：关键结果（key results）——目标是"要解的问题"，关键结果定义何为成功，而成功必须以业务结果（aka outcome）而非活动/产出来定义。团队在此第二常见的出错是把活动或交付物列成关键结果——很容易交付了东西却没解决底层问题，那就退回路线图的老毛病。通常每个目标设 2–4 个关键结果：第一个一般是主度量，其余作为质量度量——即护栏/兜底关键结果（guardrail/backstop key results），确保主度量不会以损害别处为代价被"达成"。作者用前述"降低包裹送错地址频率"举例：主关键结果是错送百分比，但若靠加重下单与履约流程去压这个比例，可能同时大幅减少总配送量或抬高配送成本，二者都不算好方案——故关键结果应是"降低错送百分比 / 同时确保总配送量持续增长 / 同时确保配送成本不增长"。注意：这些关键结果虽暗含具体 KPI，但还没有预期数值与时间框架——那必须来自团队，否则团队不会对承诺有我们想要的主人翁感；有时最合适的度量/KPI 尚不清晰（尤其面对没做过的问题），团队需要时间摸清动态。更高阶的要点：最好的团队目标来自领导与团队的来回对话，领导有责任确保这种来回发生——别要一个被动团队，团队若不主动投入与辩论，就明确问他们"你们怎么想、为什么"。还要防"尾巴摇狗（let the tail wag the dog）"——别让团队用"容易衡量"的东西、而非"最有意义衡量"的东西来定关键结果。最后是共享战略上下文：要给团队解题空间，就必须给做好决策所需的上下文（尤其产品愿景与产品战略），四点理由——让团队深刻理解最终目标与"为何重要"；让团队开始思考各项洞察、考虑各自如何贡献；让团队提前想清后续工作的牵连（隐藏依赖、要补的技术或技能）；以及"我们很乐见团队对特定问题表达特别兴趣"（虽不能总满足，但乐意尽力）。

核心主张：直面又一个常见误读——决定"哪些问题交给哪些产品团队"是领导者的责任。很多公司以为应让团队自定目标，却又对"组织抱怨缺乏方向、几无成果"感到意外；作者强调这不是团队的错，而是领导层明摆着的失职。指派目标给团队的全部意义就是执行产品战略，而产品战略本就是在决定"该解哪些问题"。指派既是自上而下又是自下而上的过程，常需迭代：它是产品战略与团队拓扑（team topology，亦即团队范围划分）的函数——战略告诉我们要解哪些问题，拓扑则暗示哪些团队最适合攻哪个问题。

论据/案例：作者举了若干机制要点。其一，关键结果必须来自团队——团队被指派一个目标后，首先要想清合适的关键结果、以及自认能达成什么；若此前在该领域做过多半已有合理直觉，若是第一次则需时间学习、采集数据立基线、摸清可能性，此时鼓励团队"跳进去、别陷入分析瘫痪"，并坦承首季度信心水平自然偏低。其二，若团队被派两个目标、而管理层认为其拟达成的结果不足以撑起全年必要的业务结果，领导可改为只让其追一个目标，或请另一团队协作。其三，对齐（alignment）——领导与团队定好分工后，须确保团队与更广组织对齐：比如要把一个面向新客类型的重要新供给推向市场，就要确保必要的平台团队工作与体验团队对齐、销售与市场的努力也对齐（若销售市场还在追另一个市场、或没为新市场做准备，就是不对齐）。

前提/推演：两条重要补充。保持运转的工作（keep-the-lights-on work）——团队目标并非团队唯一的责任：永远有修关键问题、响应客户、协助他人、技术债等"保运转"工作；随时间团队会更清楚这块成本，某些情况下它会吞掉整个团队，那时领导要么扩编、要么别指望目标之外的产出、要么设法削减这份负担。更长周期的目标（longer-term objectives）——若战略基于聚焦与洞察、团队在攻"难但有意义"的问题，许多目标会跨多个季度，这常引发困惑；要先区分长期目标与长期关键结果：目标跨多季度毫不反常（如再平台化通常 1–3 年、降客流失或建 PMF 这类重大挑战），难的是关键结果——不能图省事把"本季度代码完成"这类活动列为关键结果（那是产出不是结果）；正确做法是把工作拆成中间的产品结果（product results）。他举例：目标是让六个可被引用的客户（referenceable customers）走上 PMF 之路（极强的未来销售先行指标），但这可能要两三个季度才能让产品部署、被使用并达到可引用程度——那第一季度如何知道在切实推进？可定"本季度先拿到两个引用"；若连这都不可达，就找先行指标——例如"让八个潜在客户签署无约束力的购买意向书（non-binding letter of intent to buy）"（此技法在 INSPIRED 中有述）：虽不如真实购买，却是有真实业务含义的强先行指标。

核心主张：已给每个团队派了要解的问题，但还差一项上下文——领导必须就团队在探索工作中应追求的雄心水平讲清楚：是聚焦低风险低回报的"稳妥事"，还是去搏更实质、更剧烈的改进？一种好用的视角是：领导在下一系列注——有的低风险、有的高风险、有的居间；主要押在人身上，也押在新使能技术、变化的市场与客户行为、以及战略背后洞察的强度上。若某事足够重要，领导甚至可让几支团队各以各的方式攻同一问题——有的搏低风险快赢、有的搏更激进但更高风险的路径。

论据/案例：作者用两组生动比喻定调。屋顶击（roof shot）vs. 登月击（moon shot）：roof shot 指请团队保守、追低风险但高度可能的有形成果（优化类工作很合适）；moon shot 指请团队非常进取，比如奔着 10 倍（10X）的改进去——预期高风险，但相信"并非不可能"且团队有条件认真一搏，高风险也意味着潜在高回报；moon shot 的意义是鼓励团队跳出又小又安全的优化、重新审视"今天这问题是怎么解的"以求突破。还有公司给目标附置信度，如"80% 概率达成 roof shot vs. 20% 概率达成 moon shot"。作者最精彩的比喻是拉斯维加斯的职业扑克手：想象只准她下 1 美元或 10000 美元两种注，会严重妨碍她——她需要按情形下一系列不同金额的注；同理，领导本质上在管理一组潜在风险与回报的组合（portfolio），雄心可以是两端之间的任何水平，甚至同一目标也可让某些团队比别的更进取。

前提/推演：三条务必厘清的边界。其一，别把雄心水平与努力程度/紧迫感混淆——工作伦理与紧迫感更多是文化（以及公司现金状况）的函数，不是本章所谈。其二，别把雄心与高诚信承诺混淆——二者相关，但承诺是自成一格、极其重要的概念（下一章谈）。其三，这一切本质上是风险管理：面对像"高到难以维持业务的流失率"这种又难又关键的问题，有经验的领导会从不同角度、不同风险水平去攻——可能几支团队摘低垂果实，但担心不够，于是再让几支团队搏更进取的路径。最后一句叮嘱：无论你的关键结果对应何种雄心水平，都要在全组织清晰沟通——尤其别让任何人误以为某个结果是"极高置信"而其实不是。

核心主张：多数目标是志向性（aspirational）的——不确定哪个会成、成到什么程度，且可调雄心；但总有某些情形，需要团队做出所谓的高诚信承诺（high-integrity commitment）。作者直言"很少有人爱听我接下来这句话"：在所有生意里，都偶有"某件重要的事必须在某个确定截止日交付"的情形——截止日可能由重大行业展会驱动、由合同带来的合作方驱动、由报税季/假日期等日历驱动、或由已购买的广告投放等营销驱动。他点破：领导之所以倾向命令-控制式管理（尤其旧式"功能/项目按日期交付"的路线图），恰恰是因为这种"需要知道重要的事何时发生"的需求；因此迈向赋能团队的一个关键条件，是团队在必要时能给出可信的日期与交付物——不是路线图时代那种低诚信日期（因为当时对承诺的内容其实知之甚少），而是领导可以指望的日期。

论据/案例：作者把"为何赋能团队反而能给硬日期"讲透——若你用传统敏捷流程，给出高置信日期极难甚至不可能；但若你用探索与交付并行的模型，给高置信日期并不难，只要公司愿意等到必要的产品探索做完再给日期（通常几天）。他也警示：若一家公司有太多日期驱动的承诺，往往是更严重问题的征兆；但他总向团队解释——经营生意，一定量的高诚信承诺是必要的。即便没有外部承诺，也会有依赖其他团队的情形（如依赖平台团队的新能力）——多数对平台团队的小依赖算"保运转"工作，偶有更重大者才当作高诚信承诺。交付物（deliverables）：这类情形要以极高置信判断团队能否兑现承诺，故需对该项做足够的产品探索，让团队（尤其 PM、产品设计师、技术负责人）判断方案是否有价值、可用、可行、可存续（valuable, usable, feasible, viable）——常需做个快速的可行性原型（feasibility prototype）让工程师摸清工作量；摸清后即可高置信估出交付所需时长，并确认方案对客户管用、对公司可存续。在"体验团队依赖平台团队承诺"的情形（平台团队需提供 API 或新服务供体验团队构建其上），平台团队可继承体验团队的目标与关键结果。最重要的是：高诚信承诺对应的实际交付物必须独立于关键结果被记录与追踪。

前提/推演：追踪高诚信承诺有特殊待遇——这里不谈雄心水平，它是二元的：团队要么按诺交付、要么没有；做了承诺的团队"绝对被期望兑现，或在第一个麻烦征兆出现时就尽早举旗求助"。通常显式追踪这些承诺，有些公司里CTO 须亲自批准每一项高诚信承诺，因为押上的是她的声誉。作者把全书主线收束于此：赋能团队以信任为前提，而高诚信承诺正是团队与领导建立信任的重要方式之一——故被要求给出承诺日期时，你和团队务必确信能且会兑现。一句压轴警告：高诚信承诺与交付物应是例外而非常态，否则就是滑坡，很快你的目标会沦为一串交付物与日期，那不过是换了格式的路线图。

核心主张：有几种协作形式既必要、又常让追求"团队自主与赋能"的组织感到困惑。本章聚焦两种：共享团队目标（shared team objectives）与共同目标（common objectives）——二者名近而实异，是理解"赋能并不排斥协作"的关键。作者最后定调：以自主或沟通为名而回避共享/共同目标的公司，往往限制了自己解决最难、最重要问题的能力。

论据/案例：共享团队目标——指多支团队共享同一个团队目标，对重要目标这很常见，尤其是需要多团队协助的大型公司级倡议。最直接的例子是体验产品团队与平台团队拥有同一目标（因平台团队需提供一个或多个新服务来使能体验团队）：此时两队通常以一份 API 形式立下简单"契约"，各自实现自己那侧，再就测试与交付协作。另一种形式是多队临时合并才智去攻一个特别难的问题——尤其是受益于多种技能的问题，把团队聚到一起常能带来所需的知识与协同；某些情形下团队会就地合署（co-locate）几天到一周，称为"蜂群（swarm）"——一种围绕探索与/或交付、极密集高协作的攻坚技法。共同目标——指多支团队被要求攻同一问题、但各以各的方式，理由是风险管理：战略再扎实也仍要执行、有时要解极难的问题，而难题往往难以预知哪种路径（若有）会奏效；于是请多队从不同角度去攻，盼至少一队产生必要影响（全都见效当然更好，但知道极不可能）。最好的例子仍是订阅流失（subscriber churn）：太多客户在流失，解法众多，让多队从多角度去攻常是好的风险缓释——各队基于本队独特视角、以及自己拥有的代码与技术去攻，故诸路径多半largely独立且可累加，只需相互沟通以免冲突。

前提/推演：作者点出一个随之而来的常见问题——多队并行改动时，如何把进展归因到某一支团队，这被称为产品归因问题（product attribution problem），有两种常见解法，留待第59章"问责"展开。更高阶的要点：让多支团队同时攻同一目标，是正常且常常明智的做法。章末脚注还补了一条实践指引：作者常鼓励团队对又难又关键的问题尝试多种路径，而 Teresa Torres 发明的"机会-解决方案树（Opportunity Solution Trees）"是识别与评估多种解题路径的有用技法。

核心主张：团队目标定下来不等于自动达成；季度内仍需团队自己持续追踪与管理进度——这与产品策略需要领导层持续追踪是同构的（产品策略由产品领导追踪，团队目标由产品团队追踪）。

论据 / 机制：

• "保持灯亮"工作（keep-the-lights-on）：团队目标不是团队的全部职责，还有日常运维工作（修关键 bug、处理客户状况等）。必须盯着它，因为一旦这类工作激增，团队就无法在团队目标上推进多少。
• 每周追踪（weekly tracking）：关键是确保团队主动管理进度，否则极容易"几周乃至几个月飞逝而进展寥寥"。底线做法是每周 check-in——讨论进展到哪、接下来做什么、哪里需要帮助；可以是独立会议，也可以并进每周一次的站会。
• 保持在轨（staying on track）的两个关键点：①产品经理必须把重要问题主动同步给自己的经理，让经理有机会提供援助；②团队每个成员都需要持续的辅导（coaching）来成长，其中一部分辅导就涉及团队目标相关的问题。经验不足的团队，经理要更主动地提问和辅导。
• 求助宜早：越早提出需要管理层协助，管理层就越可能及时有效地帮上忙。尤其当团队能否兑现高诚信承诺（high-integrity commitment）存疑时，有义务尽早预警。依赖关系（如依赖另一团队）也要小心管理追踪;反过来若自己是别人的依赖（无论是高诚信承诺还是日常运维），也要记着按时交付给依赖你的团队。

前提 / 推演：作者点出一条价值底色——"在科技公司里，要么我们全赢，要么全输（we either all succeed, or none of us succeed）"。所以你常会遇到这种处境：某件事不符合本团队的最佳利益，却符合客户与更广组织的最佳利益——这时要帮同事。授权不是各自为政。

核心主张：问责是授权的孪生体（companion to empowerment）。团队获得了自主解决问题的空间与时间，随之而来的就是责任与问责。问责的力度与雄心程度直接挂钩。

论据 / 机制：

• 雄心决定问责：若团队被要求极度雄心（登月 moon shot）却没拿到结果，这"大体在预期之内"；但若被要求保守（屋顶 roof shot），尤其是若做了高诚信承诺却没兑现——这才是问责真正登场之处。
• 像对待线上事故一样复盘：团队目标实质性失败时，作者建议把它当作"宕机"来处理——把团队和一组同侪（尤其是受其失败波及的其他团队）凑在一起，让团队讨论失败的根因、本可以也本应该怎么做得不同。是否在问题初现时就该上报管理层求助？依赖它的团队是否本可另作安排甚至自救？这些"团队目标事后复盘（team objective postmortems）"对团队不好受，却通常非常有建设性。向同侪承认失败会有些尴尬，但这正是持续学习成长所需的反馈。
• 教训也适用于经理：是否漏掉了信号？是否本可更早提供辅导？管理层是否有该问而没问的问题？

最精彩之处——产品归因问题（product attribution problem）：多个团队解决同一问题（目标）、共享一个或多个成功度量（关键结果）是很常见、甚至很强大的策略，但带来一个难题：每天那么多变化，怎么知道哪个团队的哪个改动有帮助、哪个有害、哪个没影响？两种常见解法——

• A/B 测试：依赖足够的流量，把某一团队的改动贡献从公司其他团队及别处（如市场营销活动）的影响中隔离出来。
• 切片（slicing）（OKR 教练 Felipe Castro 提出的术语）：按渠道或来源把对该关键结果的各项贡献切开归属。例：求职平台里三个团队都在提升求职申请数——移动团队归"来自移动通知的申请"、搜索团队归"来自搜索结果的申请"、推荐团队归"来自推荐的申请"。切片概念上更简单，团队也喜欢那种对更窄、更直接在自己影响范围内的目标的掌控感，但通常不如 A/B 严谨、预测性差（同一用户常跨多个渠道交互）。切片并非总可行（如订阅流失受众多因素影响）;A/B 则依赖足够流量才能在合理时间内出可靠结果。

核心主张：我们需要一种方式给产品团队分配与管理工作，并且要以"既赋能、又执行产品策略"的方式来做——这就是团队目标的全部用途。在已拥抱授权团队模型、且有能干领导者这两个大前提下，其实相当直接。

论据——高效团队目标的 10 把钥匙（提炼）：

1. 最重要的是赋能：给团队待解决的问题（problems to solve）并给空间，同时共享战略背景（尤其产品策略），团队才能做好决策。
2. 乐见团队自愿认领目标（撬动其动机与热情），但不能总迁就——必须覆盖所有该覆盖的。
3. 选哪些目标、最终派给哪个/哪些团队，是产品领导层明确的职责；但关键结果必须来自团队——这对授权至关重要。
4. 来回拉锯是正常的——不是领导质疑团队提的 KR，而是在判断哪些投入值得其努力与相应风险（如某团队对某重要 KPI 只能做极微小改进时，领导可考虑让其专注这一目标、或换/找别的团队帮忙）。
5. 同一目标派给多个团队没问题——各以自身视角与技能切入，对难题往往非常有效；难题上各团队进展不会一致，也无法预判各自深入产品探索后会学到什么。
6. 让多个团队协作同一目标也没问题——尤其问题需要不同技能组合时（常见的是平台团队 + 体验团队协作攻坚）。
7. 团队要能提出 KR，必须清楚你期望的雄心水平：何时要极雄心（登月）、何时要保守（屋顶）、何时需要高诚信承诺。
8. 团队只有在被授权找出可行方案、且 KR 由自己提出时，才能对结果负责。
9. 领导要记得：团队目标极重要，但不是团队工作的全部——人人都有"保持灯亮"活动。
10. 目标通常每季度创建或更新——给足时间出真进展，又不至于久到业务无法随变化调整;季度内变更应是例外而非常态。

前提 / 推演：把这一切拉回本质——说到底就是一位懂行的领导坐下来，向团队讲清战略背景、要解决的问题、以及成功如何衡量。是否用 OKR 这类正式技法反而次要;关键是把这场对话进行下去、领导提供必要辅导、并给团队空间用他们认为最好的方式去解决。

路径：Christina 在艺术学校学摄影，在早期互联网团队中学会产品设计;2002 年加入雅虎，是搜索团队的第一位设计师，先后在 LinkedIn、MySpace、Zynga 担任产品与设计领导岗。无论在哪，她都以辅导和培养下属著称。后加入斯坦福任教，讲授人机交互与产品设计;出版多本书，主题多围绕强大、被授权的产品团队，包括一本广受欢迎的 OKR 书（《Radical Focus》）和一本讲领导力与团队授权的书（《The Team That Managed Itself》）。

要点（她的自述）：

• 导师塑造：在雅虎师从 Irene Au（曾任网景产品设计师，后建雅虎、谷歌设计团队）。Irene 即便在她没有科技业管理经验（此前是餐厅经理）时也给了她第一批直接下属;真正的教导是"看她如何赋能并培养每一个下属"——树立了"既强大又始终善良"的榜样，教会她不必在共情与权威之间二选一。
• "被相信"的转折：Jeff Weiner（时任雅虎搜索业务负责人，后任 LinkedIn CEO 近 12 年）首先鼓励她走上领导岗，管理至少 20 人的搜索设计团队。她在餐厅里对 Jeff 说"你该找个更好的人"，Jeff 答："我知道你能做这份工作。"——他"如此用力地相信我，我不得不相信自己"。
• 从设计产品到设计"让好设计发生的地方"：随雅虎搜索高速增长，她最终成为"经理的经理"——80 人经由 9 名经理向她汇报。她意识到必须停止设计产品，转而设计一个能让好设计发生的场所，即设计能自我管理的团队;面对如此广的设计技能跨度，她不可能样样精通、也没时间事必躬亲——"若想再睡上觉，唯一成功之道是信任并依靠团队"。
• 权力从"我"转向"我们"的瞬间：第一次与下属经理们开会，有人问她某问题怎么处理，她反问"你觉得我们该怎么做"，对方提建议，她说"很好，就这么办"——那一刻权力从 me 转向了 we;此后会议成了任何人都能带任何问题、大家作为一个团队共同解决的地方。"团队能创造任何个人都做不到的奇迹。"
• 第三位影响者 Ken Norton（曾为 Jeff 管雅虎购物的产品，后在谷歌、Google Ventures 有长期成功的产品生涯）：在认识 Ken 之前，她以为产品经理不过是要从设计师身边赶走、好让大家干活的项目经理;Ken 让她第一次近距离见到真正的产品管理——产品与设计应当是伙伴，始于彼此及彼此学科的尊重，"我们在一起更强"。

演示了什么：在跑框架前，先把"业务现状"这个底座说清——这是后续所有决策的语境。

• 双边市场：一边是雇主（卖招聘职位发布），一边是求职者（聚焦主动找工作、主要是白领/专业岗，非时薪或临时工）。雇主侧从小企业的单个招聘经理到中型企业;开始看到有专门 HR 部门的大型企业的兴趣，但此时产品尚未为该市场设计或适配。
• 数字（务必留存）：公司5 岁，年营收约 $45MM（4500 万美元），年增速约 30%，接近盈利但选择聚焦增长。约 230 人——产品/工程 95、销售 45、市场 17、客户成功 33、IT 10、G&A 30。高管含 CEO、CFO、销售负责人（CRO）、市场负责人（CMO）、产品负责人（CPO）、技术负责人（CTO）。作者点明：在大型企业里，这差不多就是一个典型业务单元的规模——意味着该案例的方法对大厂内部一个 BU 同样适用。

演示了什么：链条最上游——董事会 + 高管层每年设定年度公司目标，这是经过对业务战略、竞争格局、投资力度的大量审议与辩论后得出的;并示范公司目标该聚焦少量有意义的目标、且以业务结果（business results）来衡量。

• 本年总基调：继续做大做强核心业务（不偏离"帮雇主填岗、帮求职者找工作、保持强劲增速"），同时本年决定追逐一个有前景的扩张机会——进军大型企业;为此加投：新增一个产品团队（+6 人）以及企业专属的销售/市场/客户成功人员（+11 人）。董事会说明：若初次试水顺利，次年将做更大投入。
• 公司目标（OKR 格式，重点在聚焦少数 + 以业务结果衡量）：
  • 目标 1：继续做大核心业务。KR1：核心业务营收增长至少 25%;KR2：年度雇主流失率从 6% 降到 5% 或更低;KR3：求职者成功率从 23% 提升到至少 27%。
  • 目标 2：把公司确立为面向企业级公司的可信供应商。KR1：通过培育不少于 6 家企业级参考客户来证明产品/市场契合（PMF）。

演示了什么：公司目标之下、产品策略之上的一层——一个强有力、令人信服的产品愿景与原则如何作为决策的价值底座。作者称该公司愿景很强，但不公开（否则会暴露公司真身）。

• 公司创立初衷：帮人找到力所能及的最好工作、帮雇主为空缺找到强候选人。
• 愿景与原则不是空话的证据：公司依赖雇主的复购;当面临"本公司短期利益 vs 客户长期利益"的取舍时，作者反复看到他们一致地倒向客户——他本人由此被说服这些价值观非空谈。
• 最关键：产品管理、工程、设计的领导们及产品团队成员，是带着产品愿景、产品原则、尤其是产品策略去决定并追求其团队目标的。

演示了什么：把"组织如何切分产品团队"这一全书重头概念在真实公司里铺开——并体现拓扑应对齐客户类型、以及平台层为体验层服务的设计逻辑。

• 季初规模：16 个产品团队，含 60 工程师、12 个产品经理（注意：12 个 PM 对 16 个团队——平台团队的 PM 角色多由技术负责人兼任，下章及结果章会解释）、10 产品设计师、2 用户研究员、3 数据分析师。组织上：2 名产品总监（雇主侧、求职者侧各一）+ 1 名用户体验设计总监（三人汇报 CPO）;3 名工程总监（雇主、求职者、平台各一，汇报 CTO）。
• 三大组织、对齐两类客户 + 一个内部平台（约 1/3 资源在平台）：
  • 雇主组织（freemium：首个职位免费，更多发布与精选职位等增值服务收费）——Employer Home（雇主仪表盘 + 发布职位 + 保证自然搜索可见性 SEO）、Recruiter Tools（为有 HR 部门者批量管理职位/申请/面试，并能主动搜索并触达求职者）、Premium Services（加快填岗/增加申请流的可选增值服务，如邮件含职位、精选职位）、Employer Communications（与雇主的事务性 + 营销性沟通，并负责雇主侧线上获客 SEO/SEM）、Enterprise Tools（新建团队，为进军大企业识别并交付企业专属能力，如与大规模 ATS 申请人追踪系统集成;后来在团队中全职嵌入了一名产品营销，事实证明对培育参考客户与 go-to-market 极重要）。
  • 求职者组织——Seeker Home（Web 与原生 App 的核心体验：在追踪的职位、申请状态、推荐）、Job Search（按职位属性搜索市场）、Job Recommendations（用搜索与档案数据生成推荐职位）、Job Applications（申请具体职位，复用已填信息 + 该职位所需的特定信息）、Seeker Communications（与求职者的事务性 + 营销性沟通，并负责求职者侧线上获客）、Mobile Apps（iOS/Android 原生体验，与 Seeker Home 紧密协作;作者注：当年因懂原生开发的工程师太少才设专门团队，一年左右后这块工作并入了其他求职者团队尤其 Seeker Home，"一般而言是好得多的方案"）。
  • 平台组织（存在意义是让雇主/求职者体验团队更高效，使其专注用户价值创新而无需操心底层服务）——Shared Services（把跨团队重复的工作收敛成单一方案，如认证、偏好管理等数十种能力）、Payments and Billing（所有财务交易/周期付款/折扣促销/各种支付方式，复杂度由这支小而极有经验的团队消化，别的团队无需理解此复杂度即可调用）、Data and Reporting（喂给雇主/求职者仪表盘的报表基础设施，并支撑公司其余部门自助报表）、Infrastructure（保障技术基础设施满足业务需要，牵头重大技术债与帮各产品团队工程师攻克规模/性能挑战）、Tools（给所有团队提供提效与更可靠系统的工具，如站点监控、测试发布自动化 DevOps、协作工具）。

演示了什么：在公司目标清晰、产品愿景就位后，产品领导（此处即 CPO、CTO 及其经理们）如何更新产品策略以交付公司目标——并完整走一遍产品策略四步：聚焦（focus）→ 洞察（insights）→ 化为行动（action）→ 追踪进度。同时演示一条诚实纪律：不保证能做到董事会全年所盼;若产品领导判断不可行，须把问题升回 CEO 去考虑增资或降预期、或两者混合——但在此之前要先与团队一起搞清"他们认为能做到什么"。还点明公司目标是年度的、团队目标是季度的，故可按进展/障碍/新洞察/新机会逐季调整航向。

• 聚焦：公司高层已帮了大忙——把公司目标收窄到仅两个（做大核心 + 探索扩张产品）。本年认真辩论过但未入选的有：地理扩张、给雇主的附加服务（背景核验、药检）。背景里还含一条约束：追逐新机会不得以牺牲核心业务为代价。
• 洞察——核心业务侧：盼 25% 增长，但领导清楚仅优化现有产品最多带来 5–10%;此空间仍有自然增长但新竞品涌现，不能指望。故必须比以往更好地照顾现有客户 + 出去赢得新客户。审阅市场健康 KPI 与用研后的关键洞察：雇主要快速填岗，但要合格候选人（qualified candidates）的选择;零申请令人失望、申请太少令人沮丧且决策慢——这早已知;不为人知的反直觉洞察（由数据观察驱动的用研得出）是——申请太多同样制造问题：雇主筛选耗时过长、决策变慢，且热门职位会让过多求职者失望。数据显示职位填得最快、招聘经理最满意的区间是收到不少于 8 份、不超过 25 份合格申请;据此，28% 的雇主职位申请太少、7% 太多（看似不糟实则更糟，因为最吸引人的职位申请严重过载、辜负太多求职者）。他们相信这与雇主流失（尤其申请太少者）、与求职者满意度（尤其那些为心仪职位投了却石沉大海的人）直接相关。→ 下一两个季度的战略焦点：让雇主团队想办法提升"拿到≥8 份合格申请的职位占比"、并减少超过 25 份的职位。
• 洞察——求职者侧：求职者主要是快速找到匹配（时钟在走）。数据：若求职者在使用平台的头 48 小时内未投出至少一份申请，则极难再回来;而注册者中仅 27% 真正投出过至少一份申请。又：下载了原生 App 的求职者成功率（32%）远高于不下载者（15%）。第一个洞察不意外（48 小时窗口），第二个是惊喜——注册已占投递工作量的一大部分，却那么多人完成注册而不投任何职位，令人费解。→ 第二个战略焦点：让求职者团队想办法帮更多求职者（尤其已注册者）在头 48 小时窗口内找到匹配并投出至少一份申请。
• 洞察——企业扩张：目标清晰但不易。核心业务的诸多假设对新产品未必成立（卖给企业 ≠ 直接卖给招聘经理），故先从找 PMF 入手，且不让新团队被别的事分心（新产品最易让团队超前冒进）。证明企业级 PMF 很可能跨越大半年、并需多个团队配合（很可能整个雇主组织、至少求职者侧的 Job Applications、以及大部分/全部平台团队），故要保证这些团队把"支持此工作"作为目标。
• 第三个目标——重构平台（re-platforming，来自产品领导而非董事会）：前几年高速增长积下巨额技术债;上一年工程组织提出两年计划，迁往更现代的、基于 AWS 的微服务实现，列出 20 个主要系统组件、每季按特定刻意顺序攻几个。工程团队认为若肯暂停其他工作可更快完成，但那会严重打断业务能力交付，风险过大;故选渐进式两年重建。本季是该计划的第三个季度。大部分（但绝非全部）此工作预计落在平台团队。
• 行动（化洞察为行动）：领导本可直接派活，但那会漏掉重要信息——他们懂问题与洞察，却无法知道每个团队手里可用的使能技术、以及团队自己的想法与热情。故下一步是把季度团队目标讨论向更广产品组织开放：产品负责人先更新公司目标、再讲产品策略并分享相关数据尤其是洞察;告诉团队"接下来几天会带着一两个重要问题来找你们"，同时请团队先思考自己能用什么想法与技术帮上忙。明确：不能人人都想做同一件事（必须覆盖全部三个目标），但若某团队对某问题特别乐观，会尽量迁就。这是自上而下 + 自下而上的必要结合：公司目标与产品策略自上而下给到，团队自下而上想能贡献什么;但 KR 永远自下而上来。

管理（季度内的障碍与化解，演示"积极管理"）：直接报最终结果会误导，得先说清落地过程中处理掉的障碍——

• 活儿过度堆在某一团队（此处 Employer Home）：两招——把部分活转给其他团队、或给该团队加工程师;最后两者都用了一点。
• 最常见障碍——依赖：一团队识别出依赖另一团队、需确认本季能否拿到所需（规划时与季度中多次发生，依赖多落在平台团队，但有时是雇主团队的改动需要求职者团队配合）。每次都需经理直接撮合双方;多数情况靠点"讨价还价（horse trading）"两边都能满足。（脚注补：少数情况平台团队无法足够早交付，体验团队的方案只能拖到下季度。）
• Employer Home 需要产品营销的重要 SEO 支援：经理把一名 SEO 人员嵌入该团队一季;他们相信据新求职者漏斗的数据，把 SEO 做好能吸引更多合格求职者、从而提升成功率。
• Infrastructure 的重构排期与 Enterprise Tools 的时机冲突：Enterprise Tools 发现某关键领域的时机不对，Infrastructure 遂调整本季计划的具体模块以避免无用功。
• Shared Services 的请求清单过长：来自各体验团队的需求堆成长单、需要帮忙排优先级。部分靠领导给优先级指引解决;某些情况下最优解是让体验团队自己写好所需软件、再把代码贡献回平台（待 Shared Services 批准）。

演示了什么：上章谈判的最终落点——年度公司目标如何分解到 16 个产品团队的季度目标;并示范若干关键概念在真实表格里的样子：问题非方案、共享目标（common/shared objective）、高诚信承诺、继承 KR、跨季目标、雄心水平。两条提醒：团队目标不覆盖团队全部工作（还有 keep-the-lights-on）;目标是待解决的问题而非方案，团队要在探索中试方案、有证据才推进——这就是"被授权团队"之义。多个团队被派同一问题，多为共享目标（因这些是最重要的问题，故让多团队各就其领域攻），合理但非必需;共享目标下各团队需密切沟通协调、管理层在持续辅导中帮"连点"。

• 公司仪表盘（与产品策略相关的 KPI 子集，留存数字）：雇主侧——当前雇主成功率 37%（60 天发布周期内成功填岗的职位占比）、申请<8 份的职位占 39%、>25 份占 7%、8–25 份占 54%、每账户平均发布 5.9、雇主年化流失率 6%;求职者侧——当前求职者成功率 23%（60 天求职期内成功找到工作占比）、注册者头 48 小时投≥1 份申请占 27%、App 用户成功率 32%、非 App 用户 15%、每次求职平均申请数 3.2。
• 雇主组织各团队目标：
  • Employer Home：相信已有足够历史发布与求职者数据，可在创建职位时向招聘经理智能推荐以显著提升成功概率。目标：经由推荐提升雇主成功率;KR：雇主成功率 37%→39%、8–25 份申请的职位占比 54%→58%。
  • Recruiter Tools：预计受企业目标显著影响，提议与新建的 Enterprise Tools 团队并肩、改造招聘工具以满足企业需要——这是与 Enterprise Tools 的共享团队目标（目标与 KR 均共享）。
  • Premium Services：有个有风险但潜在重大的理论——某些增值服务应对所有雇主职位开放（有证据表明这些特性带来更成功的发布、更少流失、总营收上升），拟通过一系列定向测试验证;预期流失率下降需时日，但雇主成功率提升应有预测性。目标：经由增值服务提升雇主成功率;KR：测试组雇主成功率 37%→40%、测试组挂牌营收影响中性或为正。
  • Employer Communications：相信可借新 CRM 最佳实践提升与招聘经理互动的效率、让其更快与候选人闭环。目标：经由沟通提升雇主成功率;KR：雇主成功率 37%→40%、8–25 份申请的职位占比 54%→56%。
  • Enterprise Tools（新团队）：领衔企业目标，拟立即对销售已识别的8 个潜在企业客户启动客户探索计划，用这些早期客户来发现并交付该新市场的 PMF。目标：证明企业级 PMF;KR：让至少 8 个客户探索计划的客户签署购买意向书（LOI）。（脚注：最终成功度量是培育至少 6 家参考客户，但预计需一到两个季度，故用"积极参与客户开发计划"作真进展的代理 KPI——若至少 8 家签了非约束性 LOI，合理预期产品就绪时会有若干真买。）
• 求职者组织各团队目标（多为共享同一问题、共享起点 23%→25%）：
  • Seeker Home：用历史数据为求职者首页引入智能个性化、引导到更合适的职位（与 Job Recommendations 共享目标）。KR：求职者成功率 23%→25%、头 48 小时首投 27%→30%。
  • Job Search：扩展搜索范式——求职者描述完期望岗位后，搜索能持续扫描新发布、一旦有新匹配立即通知。KR：成功率 23%→25%、来自搜索结果的申请占比 0%→3%。
  • Job Recommendations：提升推荐质量、帮求职者发现"自己没意识到自己够格"的职位（与 Seeker Home 共享目标）。KR：成功率 23%→25%、来自推荐的申请占比 3%→5%。
  • Job Applications：让申请流程显著更智能——投过一份后，从任何设备、任何时间投其他职位都更快更易。KR：成功率 23%→25%、平均提交申请数 3.2→4。
  • Seeker Communications：拥抱"头 48 小时"主题，设计一系列在此期间（至少到首份申请投出前）更丰富、更及时的体验实验。KR：成功率 23%→25%、头 48 小时首投 27%→30%。
  • Mobile Apps：聚焦实时通知以促互动（头 48 小时及后续新匹配出现时）。KR：App 用户成功率 32%→35%、首次求职者安装并使用 App 的占比 17%→20%、应用商店近 30 天评分 3.0→3.5。
• 平台组织各团队目标（因平台存在主要为助体验团队达标，故多为支持其他团队目标）：
  • Shared Services：多个团队都要做通知，遂承诺提供必要服务支撑。目标：提供支撑体验团队所需的技术;高诚信承诺：交付通知系统 1.0 版。（脚注：为何是高诚信承诺而非日常依赖或共享目标？高诚信承诺只用于重大交付物;且团队早已讨论确定需要通知服务，真正问题是"何时能开始用"。）
  • Payments and Billing：Enterprise Tools 请其支持以企业条款建月度结算账户而非仅交易付款（与 Enterprise Tools 共享目标，继承其 KR）。
  • Data and Reporting：Enterprise Tools 请其支持企业级报表、并为有多用户（多招聘经理、各自账户）的公司聚合报表（共享目标，继承其 KR）。
  • Infrastructure：正处两年重构中。企业项目的出现促其提议调整工作排序，确保 ATS 集成工作能落在新基座上（既更快、又省得日后重做）。目标：继续重大技术债重构;高诚信承诺：再迁移 4 个主要系统组件到新架构，同时确保所有团队在重构期间能持续推进。（脚注：这本可写成 KR，但软件中很难量化迁往现代平台带来的速度/可靠性/可扩展/性能/容错改进——这正是技术债工作难做高诚信商业论证之处，作者建议干脆别试，"想留在生意里（并保住饭碗）就把活干了"。这也是跨季、跨年的持续目标，但每季都要有有意义进展。）
  • Tools：被要求聚焦更灵活的实时监控以应对企业集成需要（共享目标，继承其 KR）。
• 雇心水平（Level of Ambition）：有了志向型 KR，必须清楚团队本季对 KR 的雄心程度——这往往是公司文化的体现处（有的鼓励登月、有的要屋顶、有的要求 KR 带某置信度如 70%）。本公司领导用主观措辞描述期望的雄心，总体希望团队相对雄心，因为他们不相信屋顶式目标能拿到所需结果。

演示了什么：把上面的"赌注组合"兑现成真实数字——季度结果 + 约一年后的观察，呈现"下注、只有部分会赢"的风险管理实况。

• 雇主侧（8–25 区间发力）确有回报：主要靠把原本浪费在已够申请的职位上的申请分摊开;季末"成功发布"KPI 从 37%→41%，更好的是持续增长、年末近 45%;雇主流失随之从 6% 降到 5.1%。
• 多角度进攻、押注哪个会成：影响最大的是 Job Recommendations 团队——给求职者看系统认为其够格、但本人没意识到的职位;不仅即时见效，还至少持续改善了两年多。
• 求职者侧：对"先注册再首投"的工作流做了相当根本的改造，把头 48 小时投出申请的比例从 27% 大幅提升到 42%，主要靠让首份申请提交更易、更与注册流程整合。原生 App 投资也证明有价值，后续季度更好地对齐产品营销以鼓励安装。
• 企业 PMF：最终花了两个完整季度才拿到 6 家参考客户，并促成公司搭建直销渠道;但从"线上直接卖给招聘经理"转向"通过直销队伍卖给 HR 组织"所需的变化远超预期，花了将近一年才把必要基础（安全与访问控制、数据与报表、支付与结算）搭到所需水平。
• 重构：最终用满两年，但结果是团队能显著更快且与其工作更好对齐——产品团队自己最得意的成果。
• 平台 PM 之坑兑现：多数平台团队的 PM 角色由技术负责人兼任;对 Infrastructure、Tools、甚至 Shared Services 不成问题，但对 Payments and Billing、Data and Reporting，业务复杂度与约束压垮了技术负责人，公司当年晚些时候给这两支团队补了平台产品经理（呼应第65章"12 PM 对 16 团队"的伏笔）。
• 总评 + 透明的红利：虽各团队成败不一，员工/领导/投资人都对进展相当满意，所需的创新水平被认可与庆祝。因领导自始对高管与利益相关者非常开放透明，几位高管告诉作者，他们对"技术产品如何被造出来、尤其解决难题所需的实验量"有了好得多的理解。

演示了什么：把整段案例提炼成可迁移的 10 条原则——既是案例小结，也是全书方法论的回炉。

1. 产品领导的关键角色：从拓扑、到产品策略、到团队目标、到季度中积极管理涌现的问题与障碍，全程不可缺位。
2. 基于聚焦与洞察的真产品策略：产品策略告诉我们要让每个团队解决哪些问题;这些领导围绕少数高影响洞察布局、再让大半组织去攻——结果好不过策略。
3. 对团队目标的积极管理（团队自身 + 产品领导双方）：团队不盯紧，生活就会插进来，很快季度过去而事没做够。
4. 赋能团队与传教士团队的价值：真正的创新无一不是"被授权、为能真正改变客户与公司的难题而兴奋"的团队的直接产物。
5. 能知与不能知的局限：领导知道无法预判哪些点子真能结果、哪些不能，并为这一现实做了规划。
6. 下一系列赌注、只有部分会赢的风险管理：押注依据是数据洞察多强、对具体人/团队多有信心、团队对自身影响力多自信。
7. 团队拓扑对"化洞察为行动"的影响：不同拓扑会导致不同分工、很可能很不同的结果（也许更好也许更差，但必然不同）;此拓扑有明显优点也有真实局限。
8. 领导与团队间必要的给予与索取（部分自上、部分自下）：领导没有因为邀请团队自愿认领就放弃自己的职责;而其迁就意愿极大地激励了团队。
9. 向所有团队共享更广战略背景的重要性：团队要做好决策就需要大图景，需要理解产品愿景与产品策略、尤其策略背后的洞察。
10. 不确定是混乱的、永无保证，但聪明的领导通常能让它行得通——因为他们信任团队、接受不确定、并恰当地管理风险。（并补一条：每家公司处境独特——市场地位、团队人才、使能技术、文化各异;对这家求职平台有效不代表对你有效，但本例能让你对"该考虑哪些、该提供何种领导"有好的感觉。）

路径：Judy 就读伦敦商学院，与作者在同一时期、同一家公司（惠普 HP）开启职业生涯（她在英国、作者在硅谷）。她在 PC 时代加入 HP 学产品管理与产品营销;后到苹果 7 年（产品开发、产品管理、技术布道），再到微软 10 年（建立并领导微软全球消费互联网业务 MSN）;之后做创业顾问与投资、并任多家"意识到需从最高层开始转型"的公司的董事与董事长。其履历几乎覆盖技术驱动业务的方方面面，也积累了领导多家高速增长业务的教训。

要点（她的自述）：

• HP 之道（The HP Way）：Bill Hewlett 与 Dave Packard 缔造了极强的价值观文化与运营原则——"最好的结果来自：招对的人、信任他们、给他们自由去找到达成目标的最佳路径、并让他们分享其工作带来的回报";衍生出"永远招比自己聪明的人""员工赋能""一切围绕客户"。HP 也是目标管理（management by objectives）的先驱——今日 OKR 的基础。每当她看到缺乏强价值观与协作/赋能文化的组织，便知它们将难以交付伟大的客户体验、因而难以交付业务价值;"技术让很多事成为可能，但若不满足客户需要，就不会满足业务需要"。
• 苹果：Steve Jobs 有力地示范了"清晰勾勒技术能成就什么的引人愿景、同时痴迷于客户体验"之重要与威力;苹果的产品团队更多元（含产品设计 + 产品经理 + 开发），能高效组合技能、以非凡方式创新。
• 微软 MSN：新平台（Web）+ 不断更新的内容 + 新商业模式，使团队进一步多元化（新闻记者、制作人、广告专业人士），但需要的东西不变——清晰愿景、对可能性的创造力、向客户学习、持续迭代。她强调：多元（diversity）在产品团队里最为重要——给有创造力、有热情的人自由去探索想法，伟大的事就会发生;创造力产出原创点子，点子需被批判、评估、阐发，要在聚焦于最有价值者之前探索许多可能——能组合并灵活切换这些行为的产品团队，最适应当今世界。
• Accel（风投）：她听了数百场创业路演，惊讶于那么多创始团队没有技术或产品领导;许多人说打算外包产品开发——这清楚暴露了对"伟大的技术驱动产品与业务如何被造出来"的深刻误解。
• 董事会十年与命题作答：数字化转型的产出必须是"为客户交付引人的数字体验"，而这需要被授权的产品团队。为创造这些条件，领导须：确立并传达清晰引人的目的与愿景;自上而下地痴迷客户（他们是谁、要什么、怎么行为）;组建由能干 PM 领导、被授权交付产品愿景的高度聚焦的跨职能团队——这意味着清晰目标、问责、持续互动、持续学习;领导要设定期望、建立"承认必要边界但移除进展障碍"的治理、用必要工具资源支持团队，然后让开（get out of the way）;高级领导层对这套工作方法、价值观与行为的采纳支持是关键。作者问她为何那么多公司仍偏好命令-控制式领导而非赋能，她答：很多时候那并非偏好、甚至非自觉，而只是领导唯一会的模式;改变它极难，只有靠强领导力与持续投入去打造正确文化与价值观、打破筒仓、支持有效的跨职能协作。作为董事，她努力向高级领导灌输这些原则与价值，并强调产品团队必须被授权——否则进展寥寥、挫败丛生，那些费大力气、高成本引进的数字人才终将走出大门，去寻找更值得待的地方。

核心主张：从从属的功能团队模型迁移到协作的赋能团队模型，始于信任（trust）——尤其是产品组织与其余业务领导之间的信任，而信任的钥匙握在产品领导、特别是产品负责人（head of product）手里。没有一位能赢得 CEO 与关键高管信任、令人有信心的强产品负责人，这条路会"漫长而艰难"。

论据/前提：书中点出一个未必在你公司成立的大前提——产品领导应与其他关键高管、利益相关者处于平级（peer level）。在科技驱动的产品公司里通常如此；但在一些更老、互联网之前的公司，产品领导被"埋"在 CIO/CTO 之下、或塞进各个业务单元里（这都是从属功能团队模型的明确信号），此时要让销售高级副总裁、CMO 或 CFO 与产品负责人建立协作关系，政治上要难得多。原因很直接：高管更容易信任一个平级的人，而非一个素不相识、又不相信其经验与知识的低层下属。

产品领导必须与 CEO（或大公司里的总经理）以及关键高管——通常是销售、市场、服务、财务、法务、业务拓展的负责人（各公司清单不一）——建立直接关系。关系的根基，是高管要相信产品领导深刻理解业务、并致力于确保所提供的解决方案对业务的各方面都行得通；这只是"入场筹码（table stakes）"。在此之上，产品领导会被三件事评判：

• 业务结果（Business Results）：真正能驱动一家公司改用赋能团队模型的，唯有结果——业务结果。公司当初踏上这段旅程，多半正因旧方式没能交付必要的结果，所以产品组织必须把结果做出来；为此需要一个有意图、聚焦的产品策略，并让团队被赋能、且对结果负责。
• 产品策略（Product Strategy）：功能团队时代其实没有产品策略，只有满足业务各部门需求的拼凑。如今公司有了产品策略，把它与高管共享至关重要——这能传达"为何聚焦、为何选择做什么"的理由。常见的是，最重要的洞察之一最初由某位高管或利益相关者发现，此时要慷慨地为洞察来源记功（be generous in crediting the source），以培育一种持续寻找并撬动洞察的文化。
• 产品团队（Product Teams）：在赋能模型里，真正的工作发生在团队中，解决难题的能力极度依赖团队里的人、尤其是产品经理。高管会评判产品经理、并间接评判产品领导。作者爱对产品领导说一句话："你只跟你最弱的那名产品经理一样强（only as strong as your weakest product manager）"。这也是为何新员工 onboarding 时，经理必须确保新人（尤其新产品经理）在与高管/利益相关者打交道之前已做足功课、真正理解客户与业务——没有这份对客户的深刻认识，就不会有信任。随后产品领导应亲自把新人引荐给关键高管，要意识到这等于以自己的声誉为其知识与能力背书。结论：一切都系于强产品领导身上，切勿把没装备好的人放进这个关键岗位；若不得已，务必请一位被验证过的产品领导给他做高管辅导。

核心主张：全书几乎不谈"利益相关者管理（stakeholder management）"这个词，因为它代表的是一种更属于功能团队的心态；赋能团队并非可以无视利益相关者，而是与他们建立一种根本不同、更具建设性、更利于创新的关系。

论据/推演：在功能团队里，团队是来"为业务服务"的，而"业务"通常由一个或多个利益相关者代表，必须被"管理"，以免团队被需求与请求淹没——对多数功能团队的产品经理而言，应付利益相关者是这份工作最令人畏惧的部分，他们觉得永远无法让各方都满意（时间不够、人不够，有时请求本身根本说不通）。而在赋能团队里，团队是来"为客户服务、做出客户爱用又对业务可行的产品"的，利益相关者是需要一起协作、共同找出可行方案的伙伴（partners）——可行意味着方案有价值、可用、可行、且在商业上可持续（valuable, usable, feasible, viable）。利益相关者尤其帮我们处理商业可持续性（viability）：比如和公司律师坐下来梳理法律约束及可能的应对方式——无论客户多爱某方案，若不合法就是非起点（nonstarter）。于是关系从"利益相关者是发号施令、需要被管理的'客户'"，变成"一个我们需要帮其理解约束、以便共同发现可行方案的伙伴"。

最精彩的案例——代理模式（The Agency Model）：设计代理或开发代理，本是来提供设计/开发服务的。作者点破：功能团队其实非常像代理模式，只不过功能团队是内包（insourced）、代理是外包（outsourced）。代理公司一般没有"产品经理"头衔，但有"客户关系经理（engagement managers）"专司"管理与客户的关系"（这里的"客户"往往正是功能团队要服务的同一批利益相关者）。难怪用代理做设计与开发的公司，遇到的问题与功能团队如出一辙——而且代理里的人不只是感觉像雇佣兵，他们字面意义上就是雇佣兵（literally are mercenaries）：若不想做"客户"让他们做的功能，客户转头就去找另一家肯做的代理。少数代理在试图为客户提供真正赋能团队的服务，作者为这股趋势鼓掌，但它取决于客户对该代理有异乎寻常的高度信任。一个延伸观察：常能从设计/开发代理里挖到极优秀的人，因为他们见过太多类型的产品；但要警惕——不少从代理来的人会带着导致功能团队失败的同款问题，有人甚至兴奋地说"现在轮到我当客户了！"，作者会提醒他们：这恰恰彻底没领会要点。

核心主张：赋能团队在解决难题时，发现（discovery）技术会非常频繁地产生洞察；这些学习与洞察应当开放而慷慨地、双向地（in both directions）与全公司的业务伙伴共享，从而"带着伙伴一起踏上旅程"。

论据/推演：团队为何不断产生洞察——每周（normally weekly）与用户/客户会面、测试产品想法、深挖他们的语境与需求；分析产品使用数据与想法的实时数据测试；持续考察新的使能技术（enabling technologies）看能否以更好的新方式解决问题；追踪行业数据与趋势；并不断从公司各处（产品市场、销售、财务、客户成功）寻求洞察。为何要共享，书中列了四条理由：①该洞察可能也帮到对方；②对方透过自己的视角看数据，可能产生额外洞察；③对方可能帮你解释动态、从而更好地撬动洞察；④让公司学会区分"原型在 discovery 阶段反响不佳"与"产品在市场上失败"——在 discovery 里"失败"并不算真失败，而是又快又便宜的学习；在市场上失败才是真失败，因为这类错误通常又慢又昂贵。我们仍无法完全避免市场失败，但能大幅降低其频率。

最精彩的案例：作者爱邀请关键业务领导参加部分用户/客户测试；他大力主张把关键学习——不只是成功的，也包括失败的想法——在全组织广泛共享。当某位关键领导或高管的洞察被证明对某项创新或重大进展至关重要时要慷慨记功：在一家公司，他甚至自制并颁发"副产品经理（DEPUTY PRODUCT MANAGER）"徽章，在全员大会上点名表彰他人的贡献。要点是确保洞察被致谢、并双向流动。

核心主张：尽管全书讲的是强团队如何解决难题，但每支团队都必须做一定量的"维持运转（keep-the-lights-on）"工作——为了活在生意里而不可谈判的那部分活儿。

论据/推演：常见例子包括：修复关键 bug；处理合规问题（如一条新的隐私法律）；为应对变化的报表需求做小改动；为采集使用分析而加埋点（instrumentation）。这些都不光鲜，但通常相对琐碎。它们可能出于自身目的（修 bug、加埋点），也可能来自法务（新合规）或财务伙伴（报表需求）的请求。产品经理通常负责理解这些维持运转项、收集必要数据、把活放进 backlog；一般不需要对它们做 product discovery——若需要，那就该当作更常规的产品工作。

它与业务协作的关系在于：这些维持运转项的来源，往往正是一个或多个业务伙伴——他们未必知道最佳满足方式，但通常敏锐地知道需求、并能提供必要语境；若产品团队接不住，业务伙伴就被卡住、关系会变紧张。两条警戒线：①若维持运转的量过高、妨碍了团队目标（team objectives）的推进，公司就有了需要上升到产品领导层（escalated）的严重问题；②业务领导有时会把"宠物功能（pet features）"包装成维持运转工作来塞给团队——若这种事发生太多，团队就无法追求关键产品工作，等于退回到"被利益相关者管理的功能团队"。这里也正是要不断提醒业务伙伴产品策略与聚焦的重要性、并对其布道之处：业务方常会发现新机会（新变现方式、新服务、新能力），多数并非坏机会，但会迅速稀释在最重要事项上做出差异的能力。

核心主张：强产品领导（尤其在中大型公司）的关键角色之一是布道（evangelism）——即"向你自己的组织做营销"（面向产品市场、市场、销售等）。这里不是劝人购买，而是说服他们：这件事会非常重要、值得他们在意并贡献力量去实现。

最精彩的内容——十大布道技巧（top-10 techniques）：

1. 用原型（Use prototypes）：对很多人，PPT 不顶用；给他们看一个（通常是高保真的）原型——看起来逼真却只是"海市蜃楼"。这大概是说服一个产品想法的单一最有效技巧。
2. 共享痛点（Share the pain）：展示你在解决的客户痛点，可用客户原话或剪一段视频集锦；这也是作者爱带工程师/高管去做用户测试的原因——很多人只有亲耳听到客户的话、亲眼见其痛，才能"get 到"。
3. 共享愿景（Share the vision）：人们不只想知道你今天在做什么，更想知道你要去哪——产品愿景展示 3–10 年后你希望抵达之处。
4. 共享学习（Share the learnings）：把每周 discovery 产生的学习与洞察共享出去，不只讲顺利的，也讲问题，给听众做出方案所需的信息。
5. 慷慨分功（Share credit generously）：让团队、高管、关键利益相关者都视产品为"他们的"产品，而非只是"你的"；而当事情不顺时，站出来为失误担责，让人看到你也在从错误中学习，他们会因此敬重你。
6. 学会做一场好 demo（Learn how to give a great demo）：对高管与利益相关者，目的不是教他们操作、也不是测他们会不会用，而是展示价值——demo 不是培训、也不是考试，它是一种销售（a form of sales），要练到好。
7. 做足功课（Do your homework）：人们更愿意追随一个看上去懂行的人——成为你的用户、数据、业务、市场的专家。
8. 发自内心地激动（Be genuinely excited）：若你对自己的产品都不激动，要么换做的事、要么换角色。
9. 学会展现热情（Learn to show some enthusiasm）：很多产品领导明明真激动，却拙于或不自在于表达——这很重要，要真诚但让人看见你的兴奋，因为热情会传染（enthusiasm is contagious）。
10. 花时间和产品团队在一起（Spend time with the product teams）：若不与每位产品经理、设计师、工程师面对面，他们就看不到你眼里的热情；与团队里每一个人花上几分钟，对其动力的回报巨大，值得你花这时间。

前提/推演：布道永不能停——一停，事情就开始走偏：高管会临阵退缩、工程师会开始声称不知道自己为何在做某事，而且若你以为"大家都听过了、不再需要"，这种走偏会快得惊人。有经验的产品领导明白"布道永不嫌多（never evangelize too much）"——可以变换技巧、轮换引用的客户案例、不断更新原型，但布道本身必须是常态。

通往领导之路（Path to Leadership）：作者 2001 年在 eBay 管产品时初识 Avid——一位在 Netscape 共事过的朋友打来电话，只说"信我、雇了她，她一定会成为出色的产品人"，作者照办，结果朋友是对的。Avid 学的是工程、却想学产品；在 eBay 产品组织里一路晋升后，去哈佛读了 MBA，此后在风投世界（主要在 Google Ventures）与领导科技产品公司之间来回（最近在 Kobalt Music）。一路上她投资并顾问了多家强产品公司，并曾是 Code.org（帮助女性与少数族裔学编程的组织）的领导者；因对科技及其他领域的贡献，她近期获颁大英帝国勋章（OBE）。

核心主张——领导哲学三支柱（以下为 Avid 自述）：在创新驱动的语境里，她的领导哲学可简化为三大组件：(1) 信任与安全（trust and safety）；(2) 自由与自主（freedom and autonomy）；(3) 文化与目的（culture and purpose）。

• 信任与安全：领导不该拥有所有答案，而该提出对的问题、更重要的是营造一个能让对的问题浮现的环境。为此领导要让团队感到安全——在这种环境里没有谁比所有人更聪明，信任得以建立，协作自然发生，冲突的想法频繁且坦然，因为坦诚是安全的。团队必须能安心地与同侪、与领导意见相左；这是一个人们不惧失败的环境，因为失败是迭代过程的一部分——好想法正是这样变成伟大想法的。它颂扬成长型心态（growth mindset）而非某一时点的成功，鼓励持续学习、拒绝"万事通（know-it-alls）"；"激发队友最好的一面，你便在自己身上找到最好的一面"。
• 自由与自主：在创新为王、数据内外自由流动、变化恒常的数字世界里，工作日益复杂、多变、非正式。因此组织需摆脱传统层级（层级主要促成人与本部门内部的互动），转向一个鼓励跨职能、并与外部伙伴和客户协作的系统。领导要把强人聚到一起、给他们更大的自由去产生并执行想法。一句要点：领导应阐明"做什么、为什么"，然后让团队自己决定"怎么做"——她让事情启动、引导团队、在团队陷入麻烦时清除障碍。这与产品经理的角色相似：跨职能地与队友和利益相关者协作，去领导、影响、激励、信任他们，而从不命令任何人做任何事；确保他们有动力、知道自己的目的，在安全环境里辅导他们成长，并对内对外"连点成线"，用更多信息、更好工具与效率去赋能团队，确保他们有快速实验迭代所需的数据与基于学习做明智决策的自主权。
• 文化与目的：好领导聚焦文化与目的，因为文化驱动创新与绩效，组织最大的资本是人（people）。要创新，人需要自主与意义；领导务必定义清楚"目的"，让组织内外（含客户与伙伴）都知道大家在为推进什么而工作；这一目的需被清晰且一致地传达，并一致地体现在公司日常运转的方方面面——从招什么样的人、到所用的流程、乃至办公空间的设计。

最精彩的推演——成熟公司的创新（Innovation in Established Companies）：Avid 在初创与成熟公司都应用过这些原则，后者难得多，因为它们往往不再是创新者：受困于遗留技术与复杂流程，又因长期占据领先地位而自满、高估自己的创新速度。除非高级领导真正理解威胁的本质与紧迫性，否则他们不愿让组织承受变革之苦——尤其若变革会短期冲击盈利——因为成熟公司的持续创新需要在团队工作方式、所用技术、所需技能、公司文化、乃至领导心态上做激进改变；要从信任做起：一旦团队信任领导，就更愿意做改变，因为不再惧怕"第一次没做对"的后果，而这种信任必须双向，领导也要赋能团队自主——因为多数创新来自一线、而非高管或董事会；并且团队必须明白"为何要经历变革的剧变、为了什么目的"，被某种比自身更大的东西所激励。当一家成熟公司意识到未来取决于持续而重大的创新、却自认今天没这"肌肉"时，就只有两条路：要么靠收购创新（innovate through acquisition），要么学会靠自己的人创新（innovate through its own people）。靠自己的人需要前述对技能、文化、方法、领导力的改变——这很难、耗时、需巨额投入与专注承诺；因此许多遗留公司常以为靠收购更容易。可挑战在于：要兑现收购的收益，往往需把被收购方深度整合进母公司的运转，而若母公司不做出同样的领导、文化、技能与赋能改变，被收购的创新团队会出走、创新产品衰退、原本满意的客户不再满意，公司又回到起点。这正是 Avid 投入大量精力帮助公司领导认识到自身在领导变革中角色的原因。

核心主张：当你意识到"像最好的公司那样工作"所需的范围与规模，就会问：如何从今天的工作方式变成你认为明天该有的方式——这本质是个转型（transformation）问题。

前提/推演：转型的前提，是让高级领导（通常从 CEO 开始）理解技术作为业务关键使能器（key enabler）的角色，而非只是做生意的一项必要成本；没有这一理解，成功的几率很低。在此前提成立、且领导愿采取必要行动后，最高层面有三大步骤，且一般需按序发生：第一，确保到位强产品领导——否则你无法招募并辅导团队所需人员、没有扎实的产品策略、也赢不到领导与利益相关者的信任，这是最关键的第一步，也是全书主题；第二，给强产品领导招募并培养赋能团队所需人员的能力——这几乎总意味着抬高产品经理的标准（raising the bar），可能还不止于此，且不必一次性升级所有团队，只需在赋能某支团队之前确保其配齐了能胜任的人；第三，对已准备好按赋能模型运作的团队，重新定义与业务的关系——从功能团队模型里"利益相关者基本掌控、团队从属于业务"，转为与业务做真正的伙伴（true partners）、协作产出客户爱用又对业务可行的方案。要记住这是与组织领导的"give and take"：你在请他们做一次相当大的"信念之跃（leap of faith）"，而对他们的回报是——旧方式从来不太有效，所以多数人愿意至少一试。（对更大组织，转型还会冲击财务、HR、销售、市场等几乎每个方面，但那是另一本书的主题。）

最精彩的论据——转型的成本（The Cost of Transformation）：这整个话题的一大反讽是——给赋能团队配人和拨款，通常显著比给功能团队拨款更便宜。作者称从未见过比"跑功能团队的大公司"更大的浪费，尤其当其把大量工程外包给大厂时：常能见到这类又大又老的公司，用数千名外包工程师、以每年数千万美元（tens of millions of dollars）的合同供养——这是雇佣兵团队（mercenary teams）的字面定义。公司常以为省了钱（只看单个工程师的全负荷成本），却没意识到自己需要多得多的工程师、以及管理这庞大队伍的众多人手；而一支小得多的真正传教士（missionaries）团队，通常会大幅跑赢这种又大又贵的方式。何况外包模式里几乎从不发生创新，而公司的未来恰恰取决于创新。诚然赋能团队所需的高水平人才单价更高，但人数会少得多、管理开销也会大幅下降。对持怀疑态度的 CFO，作者只建议他们做个实验：挑一块业务，在接下来几个季度里，把赋能团队模型的成本与业务结果，与现行模型做对比。

核心主张：本章用 SVPG 合伙人 Jon Moore 在伦敦《卫报（Guardian）》的亲历，展示一个完成转型的强产品组织长什么样——这是作者见证过"最令人印象深刻的转型之一"。

最精彩的真实案例——《卫报》的两次 iOS 突围：2007 年 6 月，乔布斯发布 iPhone，对所有生意都是革命性时刻，对当时全球数字野心最大的报纸《卫报》（时任总编 Alan Rusbridger）尤甚——它近 200 年来第一次前途未卜：广告断崖式下滑、几乎所有营收来源都在被数字优先的新对手取代。当各国报纸纷纷转向在线订阅时，《卫报》选了一条另类、雄心勃勃却潜藏凶险的策略——保持在线免费，口号是"筑墙（付费墙）从无好下场"，逻辑是其进步主义内容在付费墙后会枯萎，宁可缩短"现金跑道"也要"先要触达、后谈营收（Reach first, revenue later）"。Jon Moore 加入了这支传统媒体中罕见的强产品与技术组织——许多同事来自雄心勃勃的初创、Google 或微软——但技术人才的涌入也带来文化混乱：报纸的长期身份认同受威胁，许多资深记者与编辑对新同事感到不确定、其动机常被质疑。

Jon 受命制定并执行即时的移动战略。他主导了《卫报》第一款 iPhone app，与 Apple 紧密合作，并从一开始就格外重视摄影；其创新之处在于 app 一打开就在无需请求的情况下下载最重要、最热门的内容——他要让 app 即使在信号差或无信号时（2007 年常如此）也始终有用，仅此一项就让许多人惊艳。从上架那刻起便大获成功：数周内数十万次下载、之后数百万计，相当比例来自被 Apple 全球生态吸引的国际新客户；应用质量叠加《卫报》世界级新闻，使 Apple 乐于在本地与全球营销中反复重点推荐它。当多数竞品的 app 本质只是"高级 RSS 阅读器"时，他们努力拥抱触屏的全新可能——因为对 Apple 而言，"光参与还不够，他们真正寻找的是那些足够珍视其工具、能把客户体验向前推的伙伴"。作为主 PM，Jon 清楚要真正成功，得弥合编辑团队与技术团队日益扩大的裂痕——在与资深编辑管理者的无数会议与展示中，他反复传达自己的信念："若成功，我的角色本质是为你们了不起的内容创造更多眼球、也为我们创造更多可变现的眼球"——而当你的正直与动机受质疑时，布道（evangelizing）从未如此重要。

2010 年 1 月底乔布斯宣布 iPad。次日 Jon 接到 Cupertino 的电话："Steve 很喜欢你们 iPhone 上做的，想让你们在 iPad 上复刻，而且他打算在公开发布会上展示他最爱的 app。"——但随即抛来变化球："app 必须在 3 月最后一周提交。"这只给了七周多。问题严重：他们的 iPhone 产品功能远多于多数对手、且自底向上设计（bottom up），并非都可移植到 iPad；最大风险是可行性（feasibility）。一两天高强度 discovery 后，结论是同等卓越已不可能、时间不够，而质量神圣不可侵犯——于是需要"另一个产品，且要快"。Jon 知道去哪找：他当初把摄影放在 iPhone 发布的核心，定性定量数据都证明这决定正确——摄影内容一直最受欢迎、驱动高频次、收获持续正面反馈；而这些触屏设备显然也是"世上最惊艳（也最贵）的数码相框"。没有更多时间收集证据，新产品就专注新闻摄影，并因时间紧而"薄切（thin slice）"范围。团队是一支五人的小型赋能团队（产品、设计、三名工程师），必须聚焦于"能最快被造出来的东西"，再靠快速迭代把它做到尽可能好。

概念几天内从白板走到客户原型：每天交付一张精选照片，传达一桩重要世界事件，只附少量细节——照片背后的故事与拍摄方式（后者还为他们赢得一笔可观赞助，早早证明能带来营收）；这些照片会随时间累积成"世上最摄人心魄的照片库"，目标是做出世上第一也最好的数字"咖啡桌（coffee table）"app。Jon 去结交《卫报》摄影团队（由出色的工匠 Roger Tooth 带领，后者极有耐心、愿为一个成功机会渺茫的项目投入时间与资源）。由于缺真机（只见过 iPad、无上手机会，要到 Cupertino 才有，而那又需先基本码完），团队还用纸板与笔记本屏幕创意地"软硬件齐做原型"，简陋却让迭代飞快。当价值、可行性、可用性都开始就位，剩下最令他担忧的一项是商业可持续性（business viability）：此前他刻意不让多数资深利益相关者看到工作——他已与技术总监及 Alan 达成一致：要抓住这机会必须异常快速推进，"事后再道歉（seek apology later）"。等产品进入后期构建、他愈发有信心时，道歉时刻到了——Alan 几乎确定地担忧他没让更多资深编辑参与，但一看到原型就毫不动摇地支持。Jon 在摄影团队也有强力拥护者（他甚至把 Roger 谈论其艺术的短视频烤进了 app）。Alan 这位技术信徒认为是时候在最高层面充分展示，邀他向集团董事会汇报——在座皆英国媒体与科技界要人，其中有一张特别友善的面孔：前 Apple 与微软高管 Judy Gibbons（Jon 的外部导师）。展示一结束，她当即定调："真出色，看着惊艳，你们怎么做到这么快的？"——此话一出，其余会议顺利通过，次日提交审核。

如预期般 Apple 那边杳无音讯（"和他们对话常像对着黑巷子喊"）。两周后乔布斯登台，快速点到他最爱的 iPad app，跳过许多知名美国品牌："我们有很多新闻 app"——《纽约时报》《时代》周刊、《华尔街日报》《今日美国》——随后他停顿、后退一步、转身看向台上 Guardian Eyewitness 的巨幅画面："这是个很酷的 app，Guardian Eyewitness。它不给你文字，而是用图片呈现一天，真的很棒（really nice）。"几乎所有在意科技的人都在看那场直播。随之而来的使用量走出与 iPhone 发布相似的轨迹——因基础硬件销量较少而规模偏小，但许多方面更佳：由于内容性质（惊艳、合家欢的照片），他们无意中造出了堪称"展示 iPad 革命性屏幕技术的完美 app"，Apple 更卖力地在几乎所有早期 iPad 营销中使用它——有近一年时间，iPad 独立销量与 Eyewitness 独立使用量几乎呈 1:1 关系。他们证明了优质摄影新闻叠加创新沉浸式数字体验能带来数百万《卫报》新读者；但更重要的是，证明了《卫报》能引领世界——不只在编辑上、也在数字上。如今《卫报》已接近持续实现营收为正，为这个全球进步主义之声多代延续奠定关键一步。

核心主张：本章由 SVPG 合伙人 Lea Hickman 介绍她在 SVPG 系列中的新书《TRANSFORMED》，处理"非常困难却至关重要"的转型主题——为何这本书与众不同、为何读后你更可能成功。

论据/推演：市面上关于数字转型的书很多，尝试转型却失败的组织更多。Lea 基于与众多公司合作、以及在 Adobe 亲历科技史上最受瞩目、财务最成功的转型之一的经验指出：多数公司并未全心投入转型，多数不愿做必要的改变。多数组织把转型狭隘地聚焦于"如何开发产品"，而非宽广地聚焦于"如何为客户生产并交付价值"——他们以为能切出一个"数字转型"小组、或让开发者采用敏捷方法就够了。她加入 SVPG（此前已造产品逾 25 年）后大开眼界：有些组织有世界级产品领导，懂得让产品组织以能出真实结果的方式运转、能领导/管理/辅导团队并与跨部门同事有效协作；而另一些组织的产品领导也许懂产品机制，却没能力组建所需团队、也无法影响组织其余部分，他们主要被当成"技术团队"、被视为一笔必要（有时被认为不必要）的开支。最难的是 Lea 能预测结局：这些组织会渐进改善，但全部潜力无法兑现，它们需要更根本的改变。

最精彩的论点：若公司想为产品组织抬高标准，就得对产品有不同的思考——不要把产品只看作技术组织（更糟的是 IT 组织）的一部分，而要把产品当作"那个组织（the organization）"：不是指权力结构或组织架构，而是指产品需成为组织的价值驱动者（value driver），而非只是为组织其余部分服务的"功能工厂（feature factory）"。另一课是：若高管团队不认同这套产品运营模型（product operating model），成功转型的几率很低——高管团队必须理解、并拥有能与产品组织对话的"语言"；而且某些高管有驱动必要变革的技能与性格、某些则没有，"领导者的行为能成就或毁掉一个组织向真正产品文化的转型"。Lea 强调 SVPG 让她最自豪的，是它们"在真实世界里运作"——所讲非学术、非理论，而是它们知道有效之事（皆有数十年造产品、既当过个体贡献者也当过资深领导、都经历过她将谈的重大转型）。她的书直白坦率："你也许不爱听我说的，但我会诚实告诉你我认为你需要听的"——这是 Marty Cagan 早年教她的，他也在 Adobe 转型时给过她"难以入耳"却为转型奠基的反馈。

核心主张：若必须从全书挑出一个最希望读者铭记的概念，那就是被赋能的工程师（empowered engineer）——开篇引 Bill Campbell 之言："被赋能的工程师，是你能在一家公司里拥有的单一最重要的东西。"作者不认为这是全部所需（非凡产品来自产品团队），但认为这是单一最重要的成分，他甚至本可以围绕"被赋能的工程师"来组织整本书。

论据/推演：为何是工程师——创新的最佳单一来源是你的工程师（他们每天与使能技术打交道，最有位置看到"刚刚成为可能"之事）；产品愿景意在吸引并启示这些工程师；产品策略意在确保他们做最重要的问题；团队目标给他们清晰的"待解问题与要达成的结果"；产品经理与设计师分别提供关于商业可持续性与客户体验的关键约束；用户研究与数据科学为他们提供关键洞察。作者特别澄清赋能的真义：只让工程师决定"怎么写代码"不是赋能（他们当然要决定如何实现）；只让他们决定架构也不是赋能（他们当然也要能决定架构）；赋能一名工程师，意味着你给他"待解的问题"与"战略语境"，由他撬动技术去找出问题的最佳解。

最精彩的论据/检验法：一个判断你是否有被赋能工程师的简易方法——若工程师第一次看到产品想法是在 sprint planning，那你显然是功能团队，工程师在任何有意义的层面都未被赋能。"若你只用工程师来写代码，你只拿到了他们一半的价值。"强科技产品公司绝不会外包工程师，正如不会外包 CEO；最好的科技公司都因此设双轨职业阶梯（dual-track career ladders），其顶尖工程师通常拿到副总裁级别的薪酬。工程师也是判断公司拥有"传教士还是雇佣兵"团队的最简单标志。作者提醒别把工程师捧上神坛（他们和我们一样是普通人），但要把他们当作产品团队的一等成员（first-class members）来对待——你每天爱用的那些突破式创新，很可能正源自一支赋能团队里的一名被赋能工程师。

对常见借口的拆解：很多产品经理会抵触这点，常说"我的工程师除了写代码什么都不感兴趣"——这是不懂赋能团队者最常见的借口。每当听到，作者坚持直接找工程师聊，结果多半相反：工程师最常见的抱怨恰恰是"被卷进来时已太晚、被迫收拾后果"；通常真相是产品经理（其思维更像项目经理而非产品经理）不愿让工程师参与、宁可他们把时间花在写代码上，于是要么"只听自己想听的"、要么压根懒得问。偶尔工程师确实说不在乎 discovery、只想写代码、"造啥都行"——这时作者会问他们上次亲自拜访客户是什么时候，答案通常在"很久以前"到"从来没有"之间。而若没有一个工程师愿做写代码之外的事，讨论就转向工程负责人：作者会指出她手下是雇佣兵而非传教士、并说明她为何需要抬高工程师招聘标准——至少每支产品团队要有一名真正的技术负责人（tech lead），而 discovery 正是技术负责人的重大职责之一。结论：作为产品领导，哪怕你别的什么都不做、只做好这一件，你就已在"善用技术、迈向赋能团队、给自己一个持续创新的真实机会"上实质性地向前迈进了。

核心主张：全书开篇描述了作者在各公司常遇到的处境（一份清单），本章逐项重访这份清单，这次写的是"我希望你的转型把你带到的地方"——也即赋能产品组织的终点画像。

逐项终点画像（最精彩的收束）：

• 技术的角色：公司理解技术在使能业务、塑造客户体验中的关键且本质的角色；一旦出现你认为可能相关的新技术，立即指派若干工程师去学它、去思考它能如何以"刚刚成为可能"的方式为客户解决问题——这远超用技术做运营提效，而是用技术重新设想现有业务的每个方面；你视产品经理、设计师、工程师、数据科学家为业务绝对核心，绝不会考虑外包他们，正如不会外包高管。
• 辅导（Coaching）：你已发展并拥抱辅导文化，产品团队每一名成员都至少有一位致力于帮其发挥潜力的经理；你已赢得"普通而有能力、有品格的人能在此成长为非凡产品团队一员"的声誉。
• 配员（Staffing）：招聘经理知道自己个人负责招募候选人、确保强力的面试与录用流程、并 onboard 新人确保其成功——强配员已成为经理的核心能力。
• 产品愿景：你有一个鼓舞人心、引人入胜的产品愿景，把各团队团结在对客户有意义的共同目的下；它可能要 3–10 年才完全实现，但你季度复季度地持续推进。
• 团队拓扑（Team Topology）：你的团队拓扑被设计为优化赋能与自主；团队成员对"更大整体中的一块有意义的部分"有真正的主人翁感，并懂得何时、如何与其他团队协作解决更大问题。
• 产品策略：你在执行一个聚焦最重要目标、由数据与持续客户互动产生的洞察所驱动的产品策略，结果是你清楚知道最需要团队解决的最具影响力的问题。
• 团队目标（Team Objectives）：这些"待解问题"以团队目标的形式分配给特定团队，团队再用 discovery 技术找出真正能解决问题的战术、用 delivery 把方案造出来推向市场。
• 与业务的关系：今天产品团队与业务领导、利益相关者之间是相互尊重、真正协作的关系——团队与利益相关者紧密合作，共同产出客户爱用又对业务可行的方案，且双方都理解并拥抱这一点。
• 赋能团队：最重要的是，产品团队被赋能去为"被要求解决的问题"想出最佳方案，并对结果负责：工程师不断寻求以新方式应用新技术更好地解决客户问题，设计师持续提供必要的用户体验，产品经理为方案的价值与可持续性负责；团队因与有技能的同事在有意义的问题上协作而受到启示、引以为傲，有强烈的主人翁感，并以"对客户与公司持续的贡献"来定义自己的成功。

前提/收束：作者坦言这一状态仍不轻松——你永远会有觊觎你客户的强劲对手——但现在你已装备好，不只能反击，还能靠持续为客户创新去成长与繁荣。终篇心愿：那些从未幸运受过认真辅导的产品领导，如今有了一份能帮他们提升、进而提升其下属水平的资源；尤其希望下一代领导读到后明白要做什么、才能成为其团队与公司值得拥有的领导；希望读者都去成为出色的产品领导、能在懂得善用其才华的公司工作，并最终把才华与精力用于善（use your talents and your energies for good）。