精益产品开发手册 The Lean Product Playbook: How to Innovate with Minimum Viable Products and Rapid Customer Feedback

• 最好的比喻：很多人听完精益创业（Lean Startup）的理念热血沸腾，然后卡在"具体该干什么"。Olsen 把这比作下决心健身的人——办了卡、买了运动服、雄赳赳走进健身房，然后站在器械中间发懵：我该做哪个动作？该用哪台机器？动机满格，知识为零。这本书就是为了填这个知识缺口而写。
• 核心论断：分析产品失败的根因，反复出现同一个模式——产品没有以优于其他替代方案的方式满足客户需求。Olsen 与 Marc Andreessen 一致：创业公司失败是因为从未抵达 PMF。
• 本书的定位：不是又一本讲理念的书，而是一本"How-to 手册"（playbook）——用他在 Intuit 带 Quicken、在 Friendster 管产品、以及给 Facebook / Box / 微软 / Medallia / Financial Engines 等做咨询的实操经验，提炼出一套可重复的流程。
• 作者履历里值得注意的一条：他学的是电子工程，第一份工作是设计核动力潜艇，晚上读弗吉尼亚理工的工业工程硕士，正是在那里学的精益制造原理——也就是精益创业的思想源头。这解释了本书为什么比同类书更"工程化"：处处是公式、矩阵、可量化的定义。

第 1 章 · 用精益产品流程达成产品市场契合

• 最好的案例——Quicken：从第 47 名到第 1 名。Intuit 的 Scott Cook 和 Tom Proulx 推出 Quicken 时，市场上已经有 46 款个人财务软件。但他们做完客户研究后判断：这 46 款没有一款达成了 PMF——都没满足需求，而且都难用。他们的假设是"用支票簿做界面隐喻会成"，因为当时人人都在写支票。假设成立，Quicken 迅速成为品类第一。两位创始人后来开玩笑说自己占了"第 47 位进入者优势"。
• Quicken 为什么算"精益"（在精益创业这个词出现之前）：公司开创了用客户研究和可用性测试来指导软件开发的做法；每个版本发布前例行做可用性测试；在这套东西成为主流之前很多年就组织公开 beta；还发明了 "follow me home"（跟我回家）——员工守在零售店，等到有人买了 Quicken，就请求跟他回家，看他怎么装、怎么用。
• PMF 的定义之争，以及 Olsen 为什么选窄的那个：有人把 PMF 扩展到"包含被验证的收入模式"甚至"包含低成本获客模型"——这等于把 PMF 等同于"一门赚钱的生意"。Olsen 明确拒绝：商业上"创造价值"和"捕获价值"是两件事，你必须先创造才能捕获。把 PMF 当"盈利"的同义词，会掩盖掉这个概念本身最核心的部分。所以本书用窄定义：你造出了一个创造显著客户价值的产品。
• PMF 金字塔的内部逻辑：市场 = 目标客户 + 他们的需求（需求层在客户层之上，因为真正与 PMF 相关的是需求）。产品 = 价值主张 + 功能集 + UX（UX 在最上层，因为对软件来说，代码是看不见的，UX 才是客户真正接触到的产品化身）。而价值主张这一层最特殊——它是"你打算满足哪些需求"的宣言，既是问题空间的最上层，又是与解决方案空间的接口。
• 为什么"未被满足"是关键词：你不会想进入一个"客户对现有方案极其满意"的市场。客户是相对于替代方案来评判你的，所以你要瞄准的是那些没被充分满足的需求。
• 六步流程的本质是一张检查清单：Olsen 说得很直白——"如果你没有显式地做这些假设和决策，那你就是在隐式地做。" 流程的作用是把脑子里的假设逼出来写在纸上（之后随时可以改）。跳过这些思考步骤，等于把"目标客户是谁""产品战略是什么"这类关键要素交给运气。
• 精益制造的血统——返工（rework）：精益制造的核心概念之一是"返工"，即花时间修补第一次没做对的东西；最小化返工是消除浪费的关键手段。六步流程不只帮你达成 PMF，还通过减少返工让你更快达成。
• 同时 Olsen 很诚实：这个流程本身也会产生返工——它是迭代的，你会不断修改假设、设计和产品，这些都可以算返工。目标不是零返工，是尽快达成 PMF。
• 不是每次都要走全六步：v1 产品要全走；上线后加功能，通常只需循环后三步（定功能 → 做出来 → 测）。若不是在造整个产品，可以把它理解成"最小可行功能"。
• 收尾的态度：Olsen 把这套流程比作空手道的套路——练到黑带之后，你就该混合、改造、创造自己的风格。他引李小龙："遵循原则，但不被原则束缚"、"吸收有用的，摒弃无用的，加上你自己独有的"。

本次通读原文后需要校正一处：Olsen 在本章明确反对把盈利纳入 PMF 定义（理由见上：创造价值 ≠ 捕获价值，混在一起会掩盖核心）。所以你这条不是原书观点，是你自己的扩展——但它扩展的方向恰好是原书主动划到界外的部分（商业模式、定价、获客各有专书）。保留它，但要标清出处：Olsen 的 PMF 是"分子"，你的公式是"分子 × 分母"。你那句"套利 vs 自嗨"对做一人公司比原书定义更实用——原书假设你背后有公司和资金，你没有。

第 2 章 · 问题空间 vs 解决方案空间

• 最好的故事——太空笔：NASA 准备送宇航员上天时知道圆珠笔不行（靠重力供墨）。承包商 Fisher Pen 决定研发零重力可用的笔，创始人 Paul Fisher 自掏 100 万美元，1965 年造出了太空笔。而苏联给宇航员发铅笔（你现在还能买到"俄罗斯太空笔"——一支包装精美的红铅笔）。
• 这个故事的真正用法（Olsen 讲得比流行版本细致得多）：重点不是嘲笑 NASA，而是演示问题陈述的粒度如何决定解空间的大小。他现场做了三次重写：
  • "一支在零重力下能用的笔" → 锁死在笔上。
  • "一件在零重力下能用的书写工具" → 允许铅笔了，但仍锁在"书写"上。
  • "一种在零重力下记录笔记、便于日后查阅、且易用的方式" → 现在录音也进入了候选。
  • 再往下推：录音需要电源、回放不如扫读方便——于是问题定义可以进一步精炼成"在零重力下记录笔记、便于日后查阅、易用、便宜、且不需外部电源"。即便那些天马行空的方案不可行，把它们想一遍本身就能帮你把问题定义得更准。
• 而且 Olsen 特意补上了事实层面的诚实：铅笔在太空其实有真问题——笔芯断了会飘进眼睛或造成电路短路；1967 年阿波罗 1 号火灾后 NASA 要求舱内所有物品不可燃。所以太空笔确实是有用的创新，苏联后来也采用了。 关于"是谁出的研发钱"的常见争论，答案是 Fisher 自己出的，不是 NASA。
• 第二个案例——TurboTax 最大的竞争对手是谁：Intuit 创始人 Scott Cook 问一屋子产品经理这个问题。有人自信地答"TaxCut"（当时另一款主要报税软件）。Scott 说：最大的竞争对手其实是纸和笔——当时用国税局表格手工报税的美国人，比所有报税软件加起来还多。
  • 这个案例的教学价值：在场的人都在解决方案空间里想问题（"报税软件"市场，由两款软件定义）；Scott 在问题空间里想（"报税"市场，还包括你委托的会计师）。市场是一组相关的客户需求，它坐落在问题空间，不绑定任何具体方案——这正是"市场颠覆"发生的机理：一类新方案（解决方案空间）更好地满足了市场需求（问题空间）。VoIP 就是例子：早期通话质量不如传统电话线，但成本低到足以对大部分电话市场构成更优解。
• "What" 与 "How"：Olsen 在 Intuit 被训练写停留在问题空间的产品需求文档。"What" = 产品要为用户完成什么（问题空间）；"How" = 产品如何实现（设计与技术，解决方案空间）。
• 由内而外 vs 由外而内："由内而外"（inside-out）的团队，产品创意源于某个员工觉得该造什么，不拿去和客户验证。解药是 Steve Blank 那句 "走出大楼"（GOOB）。"由外而内"则从理解客户的问题空间开始——这就是精益的本质，也是用户中心设计的老主张。
• 该不该听客户的？——本章最见功力的一段：批评者爱引福特那句"如果我问人们想要什么，他们会说要一匹更快的马"，再举苹果为例。Olsen 的拆解：
  • 客户确实不太可能替你发明品类里的下一个突破性方案——但谁会指望他们呢？他们不是产品设计师、产品经理或技术专家。
  • 谬误发生在有人用这一点来论证"所以不必和客户谈、不必理解他们的需求"。大多数这样论证的人，只是在为"我们什么都懂"的由内而外哲学找借口——他们不理解问题空间和解决方案空间的区别。
  • 苹果自己的说法恰恰相反。1997 年 WWDC 上乔布斯说：你必须从客户体验出发，反推到技术，而不能从技术出发再去找市场；苹果的战略与愿景是从"我们能给客户什么难以置信的好处"开始的。
• 两个苹果功能的对照实验（本章最漂亮的论证结构）：
  • Touch ID（成功）：传感器仅 170 微米厚、500 dpi，蓝宝石按键既保护传感器又充当透镜。没有哪个 iPhone 用户能想出这个方案，苹果多半也没拿它给很多客户测过。 但 Olsen 认为团队对问题空间理解极深：认证这件事上客户在乎的是便捷与安全，而这两者通常互相冲突（越便捷越不安全）。四位密码被猜中的概率是 1/10000，苹果称两枚指纹被 Touch ID 判为相同的概率是 1/50000（而且试不同手指远比试不同数字麻烦）。又快、又省心、又更安全——三个维度全面优于旧方案，所以即便不做客户验证也能有信心。
  • 2013 款 MacBook Pro 电源键（翻车）：旧款电源键远离键盘、更小、颜色不同、还是内嵌的，很难误按，按下去还会弹窗给你"重启/睡眠/关机/取消"四个选项。2013 款把它做成和其他键一样的样子、并入键盘（右上角原来 eject 键的位置），紧挨着高频使用的 delete 键和音量增大键。结果用户开始频繁误按。雪上加霜的是随后的 OS X Mavericks 改了行为：按下电源键不再弹窗，直接睡眠。两个改动叠加 = 笔记本莫名其妙突然睡着。
  • 对照结论：Touch ID 有清晰的客户收益且没出现意外副作用；电源键的改动意图中的客户收益是什么？不清楚——也许是内部的美学或成本目标。而这类可用性问题，做客户测试哪怕只测几个人也能立刻发现。Olsen 给了本书最好的一个比喻：客户反馈就像夜里的手电筒——它不会带你到应许之地，但能防止你在摸索的路上掉下悬崖。
• 反向操作：用解决方案空间去发现问题空间。客户不会把问题空间用银盘端给你——抽象地谈收益、谈各项收益的相对重要性，对他们很难，硬谈还常常谈得不准。但客户极擅长针对具体方案给反馈：给他看一个新产品或设计，他能告诉你喜欢什么、不喜欢什么、和别的方案比优劣在哪。你在解决方案空间收集到的反馈，恰恰是用来检验和改进你的问题空间假设的。 最好的问题空间洞察，往往来自客户对你做出来的解决方案物件的反馈。
• 两个空间在金字塔上的位置：功能集和 UX 活在解决方案空间（客户看得见、能反应）；另外三层活在问题空间。关键的接口就在价值主张与功能集之间。而价值主张是问题空间里你控制力最强的一层——客户和他们的需求你只能瞄准、不能改变，价值主张你可以选。
• 本章以 Dave McClure（500 Startups）的话收尾：客户不关心你的解决方案，他们关心自己的问题。

第 3 章 · 确定目标客户（步骤 1）

• 最好的比喻——钓鱼：产品是你放出去的饵，钓上来的鱼就是你的目标客户。你可以先建立假设，但在把钩子甩进水里、看什么鱼上钩之前，你并不真知道客户是谁。
• 配套的真实案例（同一个比喻的实证）：Quicken 设计给个人管家庭财务用，但因为太好用，小企业主开始拿它管公司账。团队通过客户研究发现，将近三分之一的 Quicken 用户在用它记企业的账——同一个饵钓上了第二种鱼。于是 Intuit 做了 Quicken Home and Business 版本，并最终推出了专为企业财务设计的 QuickBooks。（一个产品发现，长出了一条产品线。）
• 四种细分方式：
  • 人口统计（demographic）：年龄、性别、婚姻、收入、教育。To B 对应企业统计（firmographics）：公司规模、行业（SIC / NAICS 编码）。
  • 心理统计（psychographic）：态度、观点、价值观、兴趣。Olsen 强调心理属性通常比人口属性更有用——人口属性往往只是附带结果：你的目标是"想分享宝宝照片的妈妈"，"女性"是因为"妈妈"，"20–40 岁"是因为生育年龄的统计分布。
  • 行为（behavioral）：是否做某个动作、做的频率。如"每周在社交媒体上分享 3 张以上宝宝照片的妈妈"、"每周下 10 单以上的股票投资者"。
  • 基于需求（needs-based）：本节最有价值的一种。案例是 Dropcam：Olsen 自己用它看熟睡的孩子（在手机上看和听，不用进房间）；有人拿它当家庭安防摄像头；养宠物的人用它看宠物；商家用它做店铺安防（关门时防盗、开门时防内盗）。这四类客户你找不出一个整齐的人口或心理描述能同时覆盖，但用需求视角看，他们是统一的一群：需要方便地远程捕捉并查看视频。而 Dropcam 也确实按这个来运营——官网"用途"下分"家庭安防/婴儿监控/宠物/商用"四个页面，并按细分提供不同功能（云端录像回放对 Olsen 无用，对安防客户是刚需，且他们愿意在硬件之外每月付订阅费）。
• 用户 vs 买方：尤其在 B2B，用的人和掏钱的人不是同一个。Salesforce 由销售人员使用，但买方常常是销售副总——在某些公司又可能是 CTO 拍板。一次采购可能牵涉 CFO、事业部总经理、总法律顾问、首席安全官等多个利益相关者。要区分"经济买方"（控预算、签支票的那个人）与其他利益相关者——后者常常是潜在的阻挠者（blocker），只要他们的要求没被满足就能一票否决。买方的需求常与终端用户不同，必要时你要在目标客户之外单独定义目标买方。
• 技术采纳生命周期（引 Geoffrey Moore《跨越鸿沟》）：创新者（技术爱好者，享受折腾，容忍不完美，接受很多产品最终会失败）→ 早期采用者（有远见者，图的是相对现状取得优势，不是爱技术本身）→ 早期大众（实用主义者，对技术本身无兴趣，要看到被验证的价值记录，倾向从品类领先者处购买）→ 后期大众（保守派，怀疑创新能否兑现价值，被迫才采用）→ 落后者（怀疑论者，讨厌变化，主流化后仍会批评）。鸿沟在早期采用者与早期大众之间。 实用含义：新市场可以先打创新者（愿付溢价、能容忍核心创新之外的缺陷），但要拿下后面的人群，你必须改产品——他们要的是更易用、更可靠、更便宜。
• 人物角色（persona）：引 Alan Cooper《The Inmates are Running the Asylum》——人物角色是"对我们的用户及其想要完成之事的精确定义"，是"真实用户的假设性原型"，不是真人。Olsen 主张比设计阶段更早就开始做，因为它是承载"目标客户假设"的好载体。
  • 一页纸应包含：姓名、代表性照片、一句体现其最在乎之事的引语、职位、人口属性、需求/目标、动机与态度、相关任务与行为、对现有方案的挫败点、专业/知识水平、使用场景与环境（如"嘈杂办公室里的笔记本"vs"沙发上的平板"）、所处技术采纳阶段。
  • 最让人记住的两样是照片和引语——团队成员在不看文档时，记得的通常就是名字、照片和那句话。
  • 一条重要的统计学纪律：用调研数据时绝不能用平均值填人物角色。引 Cooper 的例子——"我社区里的人平均有 2.3 个孩子，但没有任何一个人正好有 2.3 个孩子"。应该指定 2 个或 3 个。
  • 人物角色的四种翻车方式：信息缺关键项 / 写得差 / 纯靠臆想而非真实客户数据 / 塞满不产生价值的琐碎细节。另外三种组织性失败：做完就不再和客户聊了（公司逐渐与客户脱节，尤其新人加入后）；团队根本不用它；花过多时间雕琢初版（它应该是会随迭代修订的初稿）。
• 收尾的一条实操建议：你的客户里总有一部分比其他人更爱你的产品——他们用得更频繁、会推荐给别人（社交媒体上看得见）。和这些狂热客户聊，特别能磨利你对目标市场的假设，也能看清你到底为他们满足了什么未被满足的需求。

第 4 章 · 找出未被满足的客户需求（步骤 2）

• 先统一术语（这一节比看上去重要）：Olsen 用"需求"指客户想要或看重的东西，并与"客户收益（customer benefits）"互换使用。需求不必是用户嘴上说出的"我需要 X"——存在未表达的需求（有但访谈中不说）和未知的需求（客户自己都没意识到看重它，直到你访谈他或让他见到某个突破性产品）。而"用户目标""用户故事""痛点"全都归在需求这把伞下——痛点就是没被充分满足、因而造成不满的需求。他也解释了为什么不区分"需要/想要/渴望"：这种按重要程度分的术语区分不产生价值、反而制造混乱——因为他接下来就要给出量化重要性的框架。
• 最好的案例——TurboTax 的需求剥洋葱：客户需求像洋葱，一层下面还有一层。"帮我报税"这个粒度远不足以描述 TurboTax 的问题空间。把它剥开：
  1. 帮我准备报税表 2. 检查报税表的准确性 3. 降低我被稽查的风险 4. 减少我录入税务信息的时间 5. 减少我提交报税的时间 6. 让我的抵扣最大化
  • 写法本身就是教学：Olsen 指出，最容易看出一个团队从解决方案空间起步的信号，就是他们列的是功能而不是客户收益。好的收益陈述要 ① 从客户视角写（用"我""我的"）② 以动词开头（帮、检查、降低、最大化）③ 尽量表述为"增加某个想要的东西"或"减少某个不想要的东西"——这样既清晰，又常常让你能客观度量产品带来的改进幅度。
• 客户探索访谈的标准问法（可直接抄的脚本）：对每一条收益假设问——"这句话对你意味着什么？"（检验理解）"它可能怎么帮到你？""如果有个产品能提供这个收益，对你价值有多大？"（无价值/低/中/高/非常高）；答高或非常高 → 追问"为什么对你有价值？"；答低或无 → 追问"为什么没价值？"。追问出来的"为什么"才是你要挖的金块——它让你理解客户怎么想、什么对他们重要。
• 收益阶梯（laddering）：不断问"这为什么对你重要"，直到问不出新答案，就把讨论从细粒度收益抬升到高层收益。SUV vs 面包车的例子：受访者说更喜欢 SUV 因为不喜欢滑门 → 为什么？因为偏好有型的设计 → 为什么？因为想显得时髦 → 为什么？最终动机是想被同伴接纳。
  • 用到 TurboTax 的六条收益上，会收敛成三条阶梯：1/2/3 → "感到有信心"；4/5 → "省时间"；6 → "省钱"。
  • Olsen 指出这与 Eric Ries 推广的五个为什么（源自丰田）是同类技术。
• 需求的层级（hierarchy）：需求之间存在依赖——满足需求 B 所创造的价值，取决于比它更基础的需求 A 被满足了多少。
  • 马斯洛五层（生理/安全/爱与归属/尊重/自我实现）的含义是：下层没满足，上层就不重要。
  • Olsen 自己的"网页用户需求层级"（本章最有原创性的部分，也是他的亲身教训）：他在 Friendster 管产品时"用惨痛方式"学到这一课——Friendster 是第一个火起来的社交网站，用户增长快到服务器扛不住。很多用户爱这个产品，但网站加载慢或干脆打不开时他们不爱了。于是他向马斯洛致敬做了一个五层金字塔（自下而上）：可用性/在线（产品得在）→ 性能/响应速度（够快）→ 质量（没 bug、按预期工作）→ 功能集 → UX 设计。
  • 这个金字塔的杀伤力在于它指向了产品团队的系统性偏好：创业者、PM、开发、设计师都爱把时间花在想酷点子和做体验上——而这两件事恰好在金字塔最顶上两层。
  • 而且它是动态的：假设你此刻拥有一个高可用、快、无 bug 的产品，然后你上了个新功能——它大概率带 bug（质量下降），可能给数据库更大压力（性能下降），或者太受欢迎导致流量激增压垮服务器。所以做功能和 UX 时要始终记着这个层级，并在下层出现缺陷时主动"向下探"去修它。
• 重要性 vs 满意度框架（全书最重要的分析工具之一）：
  • 来历：Olsen 在 Intuit 带 Quicken 时，每年要出新版本，必须决定下一版做什么。Intuit 极擅长客户研究，他因此得以同时设计定量和定性研究，并据此创造了这个框架。用它做出的那一版 Quicken 创下了销量、收入和利润的新纪录。
  • 两个轴的定义：重要性是问题空间概念，与任何具体方案无关；同一需求对不同客户重要性不同，同一客户对不同需求重要性也不同（他举了朋友里有人极重隐私因而不用社交媒体）。满意度是对某个具体方案满足该需求的程度的度量——不同产品对同一客户满意度不同，同一产品对不同客户满意度也不同。
  • 四象限：下面两格（低重要性）无论满意度高低都不值得追——创造不出足够的客户价值。右上（高重要 + 高满意）是成熟饱和市场，Excel 是典型（维基百科称其为"电子表格的行业标准"，功能与界面多年前就稳定了，桌面端很久没有竞品，主要威胁来自云端应用）；但右上角不一定只能有一个统治性产品——一体式打印机就是高重要高满意但 HP/爱普生/佳能/兄弟/利盟都有可比机型。若用它评估自家功能，右上角代表这个功能干得很好（他举过一个真实数据：某功能重要性 100%、满意度 98%）。左上（高重要 + 低满意）= 未被满足 = 最佳机会。
  • Uber 案例（左上象限的教科书）：被开车从 A 到 B 是重要需求，出租车是传统方案，但很少有乘客说自己对体验非常满意——车脏、司机粗鲁、沟通困难、担心开车不安全、不知道要花多少钱、支付和小费麻烦，还有迟到和放鸽子。这些抱怨揭示了一批围绕安全、舒适、便利、可负担、可靠的重要而未被满足的需求。 高重要性 + 低满意度 + 大量有此需求的人 = 巨大市场机会。Uber 的做法逐条对应：地图显示附近车辆；匹配后展示司机姓名、照片、评分、车型、车牌；显示预计到达时间和实时位置（大幅降低"能不能准时到"的焦虑）；强制评分体系（既让乘客知情，也让 Uber 筛掉不合格司机）；行前可看预估车费（避免结束时的意外）；存信用卡自动支付（对比传统出租车结束时刷卡、打小票的等待，以及只收现金的窘境）——下车走人即可。数据佐证：2013 年 12 月泄露的财务数据显示 Uber 有超 40 万活跃客户、每周超 80 万次行程，毛收入年化超 10 亿美元（Uber 抽 20%）；2014 年 12 月以 400 亿美元估值融资 12 亿。
  • 颠覆式 vs 渐进式创新：渐进式是每版小幅改进（提高既有收益的满意度，或多满足几条收益）。颠覆式创新常常从左上象限长出来，而且它会重新定义满意度这把尺子——把原本待在右上角的领先产品整体往左推。人们说的"10 倍改进"就是这个意思：好到让人无法想象回到旧方式。
  • "路上听音乐"的四波颠覆（用来演示"尺子会移动"）：1950 年代晶体管收音机（此前收音机用真空管，大、耗电、易碎，无法便携）→ 但你不能选歌。1979 年索尼 Walkman（第一台便携磁带机），你终于能听自己想听的，这是颠覆式创新，把便携收音机从右上角推到了左边。→ 之后索尼 Discman（第一台便携 CD 机）音质更好、能快速跳曲（不用快进倒带），但 Olsen 判定它是渐进式创新：对某些客户它只是略微靠右，没有改变满意度刻度（早期还有颠簸跳音的毛病）。→ 1998 年 MP3 播放器问世，早期容量小；2001 年苹果 iPod 入场，起初不算爆款，但后续机型大幅改进，大容量 + 直觉界面 + iTunes 软件与音乐商店的整合让它拿下 70% 以上份额，又一次重新定义了刻度。→ 最后的转折：iPod 自己也在衰落，吃掉它午餐的是 iPhone 等智能手机——"路上听音乐"这个需求从一个独立收益，被吸收进了"人在路上时的一整组相关需求"（打电话、发短信、上网、玩游戏、用 App），由单一方案统一满足。
  • 反思出的结论：满意度轴的刻度由市场上现有方案的"高水位线"定义，出现更好方案时右端被重新定义，一切左移；而重要性轴稳定得多——"路上听音乐"这个需求跨越 50 年、四波技术基本没变（可能随社会趋势缓慢上升，因为在路上的人更多了，但远不如满意度那么剧烈）。
  • 怎么测量：给出了可直接抄的量表设计。重要性用5 点单极量表（完全不重要 / 略重要 / 中等重要 / 很重要 / 极其重要）；满意度用 7 点双极量表（完全不满意 …… 既不满意也不不满意 …… 完全满意）。为什么不一样：双极量表从负到正，满意度可以是负的所以适合双极；重要性只是程度问题、没有负值，适合单极。研究普遍认为单极用 5 点、双极用 7 点最佳；超过 11 个选项会压垮客户，少于 5 个粒度不够；双极量表建议用奇数选项以保留中立项。可自由映射到 0–100 便于计算（5 点 → 0/25/50/75/100；7 点 → 0/16.7/33.3/50/66.7/83.3/100）。给客户用的量表要以他们易懂为准，不要索取超出他们能提供精度的答案。
  • 一组真实数据：某产品调研 13 个关键功能的重要性与满意度并作图。右上角那个是 100% 重要性 / 98% 满意度的功能——Olsen 作为 PM 很高兴，但决定不再往上投入任何资源。他选的是最靠近左上角的那个：82% 重要性、55% 满意度。图上还有个满意度更低的（41%），但它重要性只有 53%，所以不选它。
  • 样本量为零也没关系（本章最反直觉、也最实用的一段）：常有人说自己没有客户基数、达不到统计显著。Olsen 的两级回应：
    • 第一级：假设你一对一访谈 25 个常坐出租车的人，问重要性和满意度。你觉得其中有几个会说自己对打车体验"完全满意"？大概率很少甚至没有。 25 人也能浮现有意义的模式——如果你访谈的人里有很大比例给某项打了极高或极低分，很可能你已经发现了一个后续数据会证实的东西。他管这叫"在定性数据上做定量（doing quant on qual）"，一个被低估但需谨慎使用的工具。他直言：太多产品人说服自己"凡事必须证明到毫无疑问"——这不是事实，而且在 v1 早期根本不可能。统计显著在你有样本量时很棒，但它不是全有或全无。
    • 第二级（更狠）：在你和第一个客户说话之前，你就可以用这个框架——样本量为零也能推进。 怎么做？用它来形成并厘清你的假设：先假设哪些需求对目标客户最重要、他们对现有方案喜欢什么不喜欢什么、满意度大概多少，把每条假设摆到四象限上（数字化的或用便利贴），随着学习不断挪动、修改、增补。
• 相关框架（Olsen 主动做的学术诚实）：他说明自己是在 Intuit 独立想出这个框架之后，才兴奋地发现别人也有基于重要性与满意度的框架。
  • 差距分析（gap analysis）：差距 = 重要性 − 满意度。优点是单一数字、极易计算；缺点是把同样大小的差距一视同仁——重要性 10 / 满意度 5 得差距 5，重要性 6 / 满意度 1 也是 5，但直觉上前者更该做。
  • 待办任务（Jobs to be Done）与 Anthony Ulwick 的机会评分：机会分 = 重要性 + max(重要性 − 满意度, 0)。不允许差值为负；把重要性再加回去当同分时的决胜项。0–10 量表下分数区间 0–20，Ulwick 认为 >15 很有吸引力、<10 没吸引力。用前面两个例子算：第一条 10 + max(10−5,0) = 15；第二条 6 + max(6−1,0) = 11——差距相同，但重要性高的那条机会分更高，修好了差距分析的缺陷。
  • Olsen 与 Ulwick 的一处分歧值得记：Ulwick 认为"结果（outcomes）"优于"需求/收益"，理由是后者通常表述不精确，并警告过度依赖"客户之声"的做法（客户语言常含糊）。Olsen 部分同意但把责任归位："我同意需求和收益应该被精确定义——而定义它们是产品团队的活，不是客户的活。" 他引 Ulwick 那句"大多数任务，哪怕看似琐碎的，通常都有 50 到 150 个甚至更多的期望结果——不是区区几个"，说这与他自己的信念强烈共鸣：产品团队完全可能、而且这对成功创新是必需的——把问题空间定义得又细又准。他接着引乔布斯："一开始想到的解决方案都很复杂，大多数人到此为止；但如果你继续，与问题共处、再多剥几层洋葱，往往能抵达非常优雅而简单的解法。大多数人只是没有投入那个时间和精力。"
• 可视化客户价值（Olsen 自己的量化版本，比 Ulwick 的更直观）：把两轴都改成 0–100%，则图上一点与原点围成的矩形面积 = 该产品/功能交付的客户价值：
  • 客户价值 = 重要性 × 满意度（例：0.7 × 0.7 = 0.49）
  • 增值机会 = 重要性 × (1 − 满意度)——即该点右侧那块矩形的面积（例：机会 A = 0.7 × 0.3 = 0.21；机会 B = 0.9 × 0.7 = 0.63，B 的潜在价值是 A 的三倍）
  • 改进创造的价值 = 重要性 × (满意度后 − 满意度前)（例：0.7 × (0.9 − 0.7) = 0.14）
  • 回到那组真实数据：Feature X（82% / 55%）的机会分 = 0.82 × 0.45 = 0.37，而它右边全部 11 个功能的机会分都 < 0.25；那个 53% / 41% 的功能机会分 0.32，看起来在左下角只是因为坐标轴没画到零点，画到零它其实在图中央。
  • 一条重要推论：产品交付的价值随满意度变化（矩形的宽），但它能交付的最大价值由需求的重要性决定（矩形的高）。所以另一种等价表述是 机会 = 重要性 − 当前交付的价值。这从数学上重新论证了"为什么要盯高重要性的需求"。
• Kano 模型（Olsen 在工业工程研究生阶段学的，本章的第二个支柱框架）：横轴"某需求被满足的程度"（完全不满足 → 完全满足），纵轴"由此产生的客户满意度"（完全不满 → 完全满意，双极）。三类需求：
  • 性能型（performance）：越多越好，满足越充分满意度越高。例：两款车其他都一样，A 的油耗效率是 B 的两倍，你会偏好 A。
  • 必备型（must-have）：满足了不产生满意，不满足产生不满——是"入场券""赌桌底注"。例：安全带。你看中一辆车却发现没安全带，你不会买。但A 车有 5 条安全带、B 车有 100 条，你不会说 B 好 20 倍——每位乘客一条，这个必备需求就满足了。
  • 惊喜型（delighter）：提供意料之外、超出预期的收益，带来很高满意度；缺失不产生不满，因为客户本就没期待。例：1990 年代中期最早搭载 GPS 导航的车型（不用再从电脑打印路线、不会迷路，根本改变了人们从 A 开到 B 的方式）；再往前，克莱斯勒 1980 年代初推出的面包车在仪表台塑料上嵌了两个杯架，司机终于不用担心饮料洒了。
  • 需求会随时间迁移（Kano 模型最重要的动态含义）：昨天的惊喜变成今天的性能、明天的必备。杯架现在无处不在，GPS 导航也越来越成为标配。日益增长的客户期待与竞争持续抬高门槛——这与"重要性 vs 满意度"里"满意度刻度右端被重新定义、旧方案整体左移"是同一件事的两种说法。
  • Kano 也有层级：有惊喜型但缺必备型没有意义——一辆没有安全带的车装导航是荒唐的。你必须先满足基本需求才能因性能型得分，必须在性能型上有竞争力惊喜型才开始起作用。 可以想成三层金字塔：必备在底、性能居中、惊喜在顶。
  • 实操：把你品类里相关的客户收益逐条分类到三类中；评估竞品和读产品评论能帮你建立这张表。

第 5 章 · 定义你的价值主张（步骤 3）

• 开篇的比喻——瑞士军刀：瑞士军刀确实有用，一个小包里塞进一堆工具解决各种需求。但工具加到某个点之后，它就变得更宽、更重、更难用、也更没价值。 定义新产品时，专注是关键。
• 另一条动机：初始范围铺太大会浪费资源，而你对那些客户需求并没有完美信息——你的假设和"你以为你知道的"都有相当的不确定性。而且所有关于需求的假设都挂在一个更底层的假设上：目标客户是谁。如果测完 MVP 发现客户假设错了，你得回头重做需求假设。Olsen 还补了一句很清醒的话：你永远不会有"完美信息"，只会有"没那么不完美"的信息，而且这个信息在每次迭代后才逐步变得更可信。
• 战略就是说"不"：定下你要满足哪些需求，同时就是在决定不满足哪些。有些人很难说出"不，我们的产品不解决那个问题"——但这正是战略的本质。Olsen 引一个他听过的最好的战略定义："决定你不做什么。" 并引乔布斯：人们以为专注意味着对你要专注的事说"是"，其实完全不是——它意味着对另外一百个同样很好的点子说"不"。"我为我们没做的事感到自豪，不亚于为做过的事。创新就是对一千件事说不。"
• 用 Kano 组织价值主张：把需求按必备/性能/惊喜分类，并且要在竞争语境下分类——因为竞品通常在同一品类，必备型多半一样，性能型也会大量重叠，惊喜型才可能各不相同。
  • 关键取舍：必备型必须列出来（它们是硬要求），但因为品类里所有产品都有，它们不是你价值主张的核心部分。核心是你选择去竞争的性能型收益 + 你打算提供的独有惊喜型。
• 最好的案例——早期搜索引擎的价值主张之战：早年搜索引擎很多，各家押注不同的性能型收益：有的主打索引页面数最多（一次搜索返回结果最多），有的主打索引的新鲜度（多快收录新页、多快更新旧页），有的主打结果相关性。市场早期，这三条收益的相对重要性并不清楚，于是不同公司选了不同的价值主张。
  • 结局：随着时间推移，大多数引擎都索引了大量页面，于是"结果数量"变得不重要（用户喜欢知道结果很多，但通常不会翻过前几页）；同样，大多数引擎最终都能较快收录新页，新鲜度也拉平了。于是相关性成了最重要、也最有差异化空间的那条收益。Google 凭 PageRank 算法在相关性上远超同行——在最重要的那条收益上做到最好，同时在其他维度上不落下风，于是赢下了搜索引擎大战。
  • 这个案例的方法论价值：它演示了性能型收益的相对重要性会随市场成熟而变化——你押注的那条，可能几年后变成人人都有的必备型。
  • Google 的惊喜型：Google Suggest（自动补全查询）——用户不必打完"how many inches are in a yard"，敲几个字就能从建议列表里点选，短语越长省的时间越多；对不确定该怎么搜的人，看到相关热门短语还能更快到达更相关的结果。Google Instant（边打字边出结果，不等回车）——Google 观察到人们读结果比打字快得多：击键间隔通常 300 毫秒，而扫一眼结果只要 30 毫秒；Google 把 Instant 的收益量化为每次搜索省 2–5 秒。
  • Olsen 在这里插了一个容易被忽略的写作纪律：Google Suggest 和 Instant 是功能，不是收益。所以在价值主张表里，左侧收益列写的是"省下输入查询的时间""省下浏览结果的时间"，功能名只写在 Google 那一列。
  • Bing 的惊喜型：每日一图——每天访问 Bing 首页背景都是一张不同的精美照片，配上关于图中事物或地点的花絮/提示，用户可以猜猜是哪儿。它不会让搜索更快、结果更准，但它每天给用户一个有趣、愉悦的意外。
• 最好的反面案例——Cuil（发音同 "cool"）：2008 年上线。此时搜索市场已处于重要性 vs 满意度的右上象限：搜索很重要，但用户对现有引擎相当满意，Google 份额超 60%。在这种情况下，任何新进入者都必须有清晰的价值主张说明自己如何更好、更不同。
  • Cuil 的押注：最大索引（宣称 1200 亿网页，估计是 Google 的三倍）、杂志式多图的结果展现、隐私（承诺不保留搜索历史）。
  • 结果：评论者抱怨响应慢、结果相关性低。Search Engine Watch 的搜索专家 Danny Sullivan 批评 Cuil 专注于索引规模而非相关性。上线两年后关停。
  • Olsen 的复盘极其克制且到位：要有机会击败在位领导者，你的价值主张至少要在"相关性"和"响应时间"这两条重要的性能型收益上打平。"我相信 Cuil 团队并没打算让相关性和响应时间更差——那只是用户实际用起来时遇到的情况。"而且即便打平了，他们仍然需要一个被客户认可的差异化点——"更大的索引"和"更强的隐私"到底对客户有多值，并不清楚。
  • 由此引出一条通用律：改变客户行为总是很难，尤其在右上象限——你需要创造出足够的超额价值，才能让客户从一个日常在用的产品切换过来。"10 倍更好"这个说法又一次浮现。
• 价值主张模板（可直接抄的表）：第一列按类型分组列收益（必备/性能/惊喜），然后每个相关竞品一列 + 你的产品一列。
  • "竞品"不只是直接竞品：万一你真没有直接竞品，客户现在也一定在用某种替代方案满足需求（记得 TurboTax 的竞品是纸笔）。
  • 打分规则：必备型填"是"；性能型用"高/中/低"通常就够，能量化的就填数值（他举例：餐厅订位应用如 OpenTable，"系统内餐厅数量"和"完成一次订位所需时间"就可以填具体数值）；惊喜型一般各家独有，一行一个，适用处标"是"。
  • 填完之后你得到的是什么：那一列就是你的产品价值主张——你明确了在哪些方面进攻、在哪些方面愿意让出。你的关键差异化点 = 你打算超越竞品的性能型收益 + 你独有的惊喜型。而且这些差异化点理想情况下应该对应到第 4 章里高重要性、低满意度的未被满足收益。
  • Olsen 给了一句很有说服力的推销词：很少有产品团队真的完成过这个练习——所以光是做了这件事，你就已经走在大多数公司前面。清晰的价值主张能降低你做出"me too"产品的概率、把资源聚焦到最重要的事情上。
• 滑向冰球将到之处：以上都是静态快照。要有战略性，你得向前投影，预判市场的重要趋势和竞品可能的动作——这在变化很快的高科技市场尤其重要。引韦恩·格雷茨基："我滑向冰球将要到达的地方，而不是它已经到过的地方。"
• 配套案例——Flip 便携摄像机：Pure Digital 2006 年以"傻瓜式录像机"推出 Flip，很多客户觉得它优于传统摄像机——更易用、更小巧、更便宜。凭此成功，思科 2009 年以 5.9 亿美元收购 Pure Digital。
  • 然后：两年后思科宣布退出包括 Flip 在内的部分消费业务。发生了什么？ Flip 确实达成过几年的 PMF，但竞争格局变得太快：2009 年苹果推出 iPhone 3GS——第一款内置视频录制的 iPhone。相比 Flip，智能手机更便携（不用带第二个设备），而且无线连接让你不用同步到电脑就能即刻发布视频。抛开思科的公司战略不谈，"智能手机将是便捷便携录像的未来"这件事随时间推移变得显而易见。
• 用价值主张表预测未来：给每个竞品和你自己的产品各开"现在"和"一年后"两列（"以后"取对你的产品战略最有意义的时间跨度）。
  • Olsen 给的示例读法：竞品 A 现在在性能收益 1 上最好，你现在在性能收益 3 上最好。你预判竞品 A 会投入改进性能收益 3 但追不上你；你也预判它会加码扩大在性能收益 2 上的领先。你判断性能收益 2 对你的目标市场不那么重要，于是不在那里投入，而是确保自己在性能收益 3 上保持最好、同时在性能收益 1 上追平差距。惊喜型上，你们各有一个；往前看，你预期对手会推出惊喜 3，你计划推出惊喜 4。
  • 这么分析的价值：确保你不是只在为当前市场条件求解，降低"你走的这条路在未来变成次优"的风险。

第 6 章 · 确定你的 MVP 功能集（步骤 4）

• 为什么叫"MVP 候选"而不是 MVP：因为它建立在你的假设上——你还没有和客户验证过他们同意这确实是一个"可行"的产品。
• 从问题空间跨到解决方案空间的那一刻：对价值主张里的每条收益，团队头脑风暴尽可能多的功能创意。此时应遵守头脑风暴规则、实践发散思维——尽量多产生想法，不做任何评判或评估；收敛思维（评估、挑选）留到后面。团队应互相接话、互相推着想出更有创意甚至更离谱的点子。
  • 风暴完成后按收益归类所有点子，再对每条收益下的功能创意列表评审并排序，用预期客户价值给每个创意打分得到第一轮优先级。目标是为每条收益找出前 3–5 个功能。再往下看没什么意义——因为给客户看完原型之后，事情会变很多。
• 用户故事：带收益的功能：模板 "作为［某类用户］，我想要［做某事］，以便我可以［获得某收益］"。示例："作为一名职业摄影师，我想要方便地把照片从相机传到我的网站，以便快速给客户看他们的照片。"
  • 引 Bill Wake 的 INVEST 六条：独立（故事之间不重叠、可任意顺序实现）、可协商（不是功能的明文合同，如何交付该收益应可讨论）、有价值（对客户有价值）、可估算（范围能被合理估计）、小（大故事不确定性大，要拆）、可测试（信息足以说清怎样算"完成"——即验收标准）。
• 拆功能（chunking，本章的核心手艺）：为高层用户故事找出拆成更小功能片的方法。目标是缩小范围、只做每个功能里最有价值的部分。 Olsen 特意用"功能块（feature chunk）"而不是"功能"，就是为了提醒读者不要拿大范围的东西当工作单元。
  • 示例："作为用户，我想方便地和朋友分享照片，以便他们能欣赏。" 一种拆法是按分享渠道：Facebook、Twitter、Pinterest、邮件、短信……每个都是一个独立的功能块。MVP 未必要全建。即使你决定全建，拆开也有三个好处：产品定义更具体、开发估算更准、能显式地排列建造顺序。还可以从别的维度限范围：MVP 只允许分享照片本身、不带别的；"给每张照片加一段可选留言""在照片里标记用户"各自是后续的独立功能块。
• 小批量更好（把精益制造原理迁移到软件）：批量 = 同时在处理的产品数量；软件里对应待编码的功能/用户故事的大小。小批量提升速度，因为它带来更快的反馈，从而降低风险和浪费。
  • 具体机理：如果一个开发者埋头做一个月再拿给 PM 和设计师看，出现认知错位的概率更大，反馈会要求大幅返工；如果她每一两天就给他们看一次，大错位就不会发生，反馈和纠偏的幅度都小得多、也更可控，浪费更少、生产率更高。
  • 这条同样适用于 PM 和设计师（用户故事、线框图也要频繁给队友看），也适用于客户反馈——你不拿给客户看的时间越长，日后发生重大错位并被迫大规模返工的风险越大。
• 用故事点定范围：敏捷里常用故事点作为"估算相对大小的货币"（很小 = 1 点，中等 = 3 点，大 = 8 点）。一条好的操作原则：估算点数超过某个阈值的故事，必须拆成一组低于阈值的小故事。功能块 ≈ 点数低于你的最大阈值的用户故事。
• 用投资回报率（ROI）做第二轮排序：到这里你只按"客户价值"排过序，还没考虑造它要多少资源。分块完成后，做一次同时考虑价值与工作量的第二轮排序。
  • 公式 ROI = (最终价值 − 投资) / 投资 = 回报 / 投资。产品语境下两个数通常都不是钱：投资一般是开发资源的时间（单位如"开发者-周"），回报一般是你预期该功能能创造的客户价值的相对度量。
  • 一条容易被忽略的数学要求：你用的必须是比率量表（ratio scale）——分数要与价值成正比。如果你用 0–10 打分，一个功能块 10 分、另一个 5 分，那就应该意味着前者创造的客户价值是后者的两倍。
  • 可视化 ROI：纵轴回报（创造的客户价值），横轴投资（开发工作量）。
    • 创意 A 与 B 都产生 6 单位价值，但 B 要 4 个开发者-周、A 只要 2 个 → ROI 3 vs 1.5，A 优先。
    • 创意 C（4 价值 / 4 周）与 D（8 价值 / 8 周）ROI 都是 1 → 优先小的那个，因为实现更快、价值更早交付、也更早拿到客户对它的反馈。
    • 也有烂点子，如创意 F：2 单位价值 / 8 周，ROI 0.25。Olsen 在这里给了一条极其锋利的观察：低 ROI 点子的"大工作量"通常在实现过程中就被团队察觉了，但"低客户价值"这一半，他们往往要到上线之后才意识到。Google Buzz 和 Google Wave 就是例子——都耗费了大量开发工时，上线不久后因客户反应表明它们没创造足够价值而关停。
    • 好团队追求创意 G 那种：高价值、低工作量。而伟大的团队能把这类点子再拆块、削掉价值较低的部分、找到用更少工作量交付同样客户价值的创造性做法——在图上就是把 G 往左推。
  • 对精度的清醒态度：有人纠结估不准客户价值。Olsen 说不必太担心——这不是要精确到小数点；工作量估算同样不会很准，因为你还没把功能设计完，你不能指望开发者基于一句高层描述给出准确估算。估算的准确度应当与产品定义的保真度成正比。 这些计算的重点不在于算出真实 ROI 值，而在于它们彼此之间的比较——聚焦最高 ROI 的功能、避开低 ROI 的功能。
  • 近似版 ROI（估不出数时的退路）：把每个功能创意在客户价值和工作量上各打"高/中/低"，形成 3×3 九宫格，九个格子按 ROI 排序（高价值低工作量 = 1 号格，优先级最高）。卡住就先凭最佳猜测把每个功能丢进某一格——这些只是你的起始假设，随学习和迭代会改。
  • ROI 里的"回报"也可以是商业价值：这时你往往有可估的美元金额（预期收入增长或成本下降）。例：你有个上线产品，想提高免费转付费的转化率——给定转化率的提升幅度，你应能估出预期收入提升，从而给每个改进点子挂一个美元值。
• 决定 MVP 候选：做一张表——行是价值主张里的收益，每行列出该收益下拆好块并排好序的顶部功能（优先级高的在左）。然后看最左那一列，决定哪些必须进 MVP 候选：
  • 首先，MVP 候选必须包含你识别出的全部必备型。
  • 其次，聚焦你打算用来击败竞争的那条主要性能型收益，选出你认为足以让客户看出差异的那组功能块。
  • 惊喜型也是差异化的一部分——应把你的头号惊喜型放进 MVP 候选；除非你在某条性能型收益上优势极大，才可能不必。目标是确保你的 MVP 候选里有客户认为优于其他产品、且最好是独有的东西。
  • 留在最左列的标为 "v1"，其余推到右边——顺着这个过程给未来版本各开一列，你就得到了一份初步的产品路线图。
  • 但 Olsen 立刻踩刹车：不建议一开始就规划超过一两个小版本——第一次把 MVP 候选拿给客户看时，很多事情都会变。你会发现某些假设不对、会产生新假设、可能改变对"哪条收益最重要"的判断、也可能想出满足同样收益的新功能。所以如果你做了 MVP 之外的暂定计划，你必须准备好把它们扔出窗外，根据学到的东西重新规划。
• 本章收尾的清单（Olsen 让你回头看走到这一步做了什么）：形成了目标客户假设、形成了未被满足需求的假设、明确了让产品更好且不同的价值主张、找出了顶部功能创意并拆成小块、按 ROI 排了序、选出了一组功能块作为 MVP 候选。"你做了大量严谨的思考，但你的 MVP 仍然只是个候选，是一捆彼此关联的假设。"

第 7 章 · 做出你的 MVP 原型（步骤 5）

• "MVP 是什么、不是什么"——一场口水仗的化解：有人坚持落地页就是有效的 MVP，有人坚决反对、认为 MVP 必须是真能跑的产品或至少是交互原型。Olsen 的解法很漂亮：认识到这些全都是用来检验 MVP 背后假设的方法。用"MVP 测试（MVP tests）"这个词代替"MVP"，争论就消失了——同时把"MVP"这个词保留给真实产品，术语反而更精确。
• 对 minimum 的误读（本节最重要的一条纪律）：很多人把重心放在"最小"上，用它给"功能少到客户根本不认为可行"的半成品背书；还有人用"最小"来合理化糟糕的用户体验或一堆 bug。Olsen 明确否定：MVP 相对于你的完整价值主张确实范围有限，但你交付给客户的东西必须高于某条线，才能为他们创造价值。
  • 配套的那张图（改编自 Volkside 的 Jussi Pasanen）把产品属性分成四层金字塔：功能性、可靠性、可用性、令人愉悦。错误版本：MVP 就是功能少的产品，可靠、可用、愉悦都可以忽略。正确版本：MVP 功能有限，但在那三个更高层属性上应当是"完整"的。（Olsen 特意点出它与他自己第 4 章那个"网页用户需求层级"的同构性。）
• MVP 测试的两个分类维度：
  • 产品 vs 营销：测落地页上"注册"按钮点击率的，是营销测试——没有任何产品功能可供客户真正使用，你只是在描述功能、看描述有多打动人。产品测试则要给潜在客户看功能并索取反馈（可以是能跑的 beta，也可以是低保真线框图）。两者你都在乎"客户觉得你给他看的东西有多吸引人"，但学习目标不同。 而且营销测试提供有价值的学习，但它不是一个创造客户价值的真实产品——某个时点你必须测 MVP 候选的原型。
  • 定性 vs 定量：定性是直接和客户对话，数量通常小到不具统计显著性，你在乎的是每次测试里学到的细节；定量是大规模跑测试，你不那么在乎单个结果，而是看聚合结果。
  • 两者的分工：定量擅长回答"是什么"和"多少"（客户采取了什么行动、多少人点了注册），但它不会告诉你为什么；定性擅长回答"为什么"。
  • Olsen 观察到的常见病：很多团队过度依赖其中一种，通常是定量。一般原则：刚开始做产品或营销材料时，先做定性测试建立初步理解——如果你不做任何定性就直接跳进定量，效果通常不好；而且即使效果好，你也不知道为什么好。 成熟团队常在两者之间交替循环。
• MVP 测试 2×2 矩阵（本章的骨架，可直接当清单用）：
  • 定性营销：统称"营销材料"测试——把落地页、视频、广告、邮件等任何你想放到客户面前的东西给他看，理解他觉得有多打动人、以及为什么。可以把竞品的营销材料也给他看，学他们讲清楚了什么、没讲清楚什么，并检验你的差异化。具体技法：五秒测试——只给客户看 5 秒首页/落地页，然后问他记得什么、喜欢什么。因为客户本来就一直在对产品做瞬时判断，这能很好地检验你的信息传达。
  • 定量营销：
    • 落地页 / 烟雾测试（smoke test）：做一个真实网页并导流量进去，页面描述你打算做的产品，请客户表达某种程度的兴趣（通常是"注册"按钮或"套餐与定价"链接）。叫烟雾测试是因为还没有真产品可用，点完通常是"即将推出"页并索取邮箱。核心指标是转化率。转化率受你选的收益、以及你描述收益和产品的水平影响；即便收益选对了，好的视觉设计和文案对落地页成功也很重要。工具：Optimizely、Unbounce。
    • 落地页 MVP 案例——Buffer（本章最好的案例）：Buffer 帮你把要发的推文排到预设时间发送。创始人兼 CEO Joel Gascoigne 写博客复盘他这次和上一家创业公司的不同做法："上家公司我在验证商业可行性之前就开始写 Buffer 的代码。等我意识到这点，我停下来，深吸一口气，告诉自己：这次要用正确的方式做。是时候检验人们到底想不想要这个产品了。"
      • 第一步（要不要）：首页用一个标题 + 三个要点描述价值主张，唯一可点的是"套餐与定价"按钮，点进去是一页"你来得比我们准备好还早"，然后可以留邮箱等上线通知。Gascoigne 的说法："这个两页 MVP 的目的，是检验人们是否会考虑用这个 App。我只是发了条推、问大家怎么看。几个人留了邮箱、我也通过邮件和推特收到一些有用反馈，我就认为它被验证了。"
      • 第二步（愿不愿付钱）：他在邮箱表单之前插了一页，描述三档产品：免费、每月 5 美元、每月 20 美元。这样他既能看到每档收到多少点击，也能看到多少人最终提交了邮箱。 结果是正向的：尽管多了一次点击，人们仍然走到了邮箱表单并留下邮箱，而且有人点了付费档。
      • Olsen 特意点明的一件事：此时还没有任何人真的付过钱（因为他们还付不了）。但 Gascoigne 认为这两个简单测试已给了他足够的 PMF 验证，可以有信心推进。
    • 解释视频（explainer video）：落地页测试的变体，用视频解释产品，以它驱动的转化率判断效果。特别适合难以用文字讲清的产品。经典案例 Dropbox：创始人 Drew Houston 发现，当他试图解释自家独特的文件同步方式与市面上其他云存储产品有何不同时，人们就是听不懂。于是他做了一个视频演示 Dropbox 如何工作。视频击中了客户在多设备间管理和分享文件的真实痛点，为私有 beta 等待列表带来大量注册。
    • 广告投放：为了给落地页导流，可以投广告。用 Google AdWords 试不同搜索词和广告文案，通过点击率定量地知道客户觉得哪些词句最打动人；展示广告可测不同信息和图像；Facebook 广告能按人口属性定向，因而是检验目标市场假设的好办法。但 Olsen 明确指出局限：广告通常很小，装不下完整价值主张，只能放一句标语——所以这类测试最适合优化获客，而不适合验证 PMF。（示例：招聘网站可跑三条标语——"我们为你匹配理想工作""我们的职位列表全网最多""我们提供扫描职位最快的方式"，比点击率。）
    • 营销 A/B 测试：同时跑两个（或更多）版本比较关键指标。真正的 A/B 测试必须并行（50/50 分流），顺序测试（先全量 A 一段时间、再全量 B）不理想——会被季节性、推广力度等外部因素污染。多轮优化后表现最好的叫冠军（champion），之后不时挑战它。统计显著性由"表现差异大小"和"样本量"共同决定：差异越大、样本越大，显著性越高；两个表现很接近的版本，可能需要极大样本才能分出统计显著的差别。多变量测试则是测页面元素的组合（3 个标题 × 3 张主图 = 9 种组合）。
    • 众筹：Kickstarter / Indiegogo 是检验人们是否愿意为你的产品付钱、并量化需求的好办法。客户在你开始造之前就先付钱，这非常符合精益原则——它消除了"到底有没有人愿意付钱"的不确定性。
      • Pebble 手表：创始人 Eric Migicovsky 从 Y Combinator 出来后没能从风投拿到足够的钱。他发起 Kickstarter，初始目标 10 万美元，客户可以用 115 美元预订（正式价 150 美元）。两小时达成初始目标，一个多月后结束时超过 68000 人认捐了逾 1000 万美元。
      • Oculus Rift：2012 年 8 月初始目标 25 万美元，一个月内筹到近 250 万美元，接近目标的 10 倍；不到两年后被 Facebook 以 20 亿美元收购。
      • 两条实用建议：有正职但想做创业点子的人，可以用众筹在"跳船"之前先降低风险；因为没有实物可试，你必须提供对产品和收益的丰富描述（很多项目有高质量视频和详尽 FAQ），并要通过社交媒体等方式让潜在客户知道你的项目。众筹页面成功后会变成创业公司与客户之间活跃的沟通枢纽，也是接触早期采用者、获取改进创意的好渠道。
  • 定性产品测试：产品测试确保客户在你真实的产品里看到价值。有两个根本不同的时点：造之前和造之后，两者都有价值。
    • 造之前：典型交付物是线框图、视觉稿、交互原型——都是产品的表征而非产品本身。你要在写代码之前验证设计以减少浪费，因为改设计通常比改代码快得多、便宜得多。
    • 造之后：优点是保真度 100%，因此可能学到低保真测试观察不到的东西。举例：你能从视觉稿上得到"信息布局如何、文案是否清楚、视觉是否吸引人"的反馈，但你不会发现"这个网页加载很慢"或"它在某个浏览器里不工作"。Olsen 的判断：真实产品测试没有内在的坏处，但如果你等到产品上线才测，你就在不必要地冒大风险。
    • 设计物的二维分类（保真度 × 交互性）：
      • 手绘草图（最低保真、最低交互）：可视化想法、与队友和内部干系人讨论的绝佳方式，白板或纸上快速迭代。Olsen 说自己是白板的铁杆粉丝，"白板很可能是终极的精益工具，因为它让团队能极快地迭代想法"。但它太低保真，不适合拿给客户要反馈（所以它不出现在 MVP 测试矩阵里）。
      • 线框图（wireframe）：低到中保真，体现组件构成与排布，不追求像素级精确，通常灰度、图片用占位符，以免评审者被视觉元素分心。Olsen 的一条主张：文案从一开始就用真实文案（哪怕只是草稿），以便及早发现潜在的排版问题，而不是用 lorem ipsum。工具：Illustrator、Sketch（设计师向），OmniGraffle、Visio（通用），Balsamiq、Axure、UXPin（专用）；移动端 Flinto、Marvel（设计师向），POP、Dapp（非设计师向）。
        • "该换工具了"的自检信号（很实用的一张清单）：你在用形状和线条从零画基础页面元素而不是用预置控件库；你做的线框图不可点/不可轻触；很难分享给别人；用非移动优化的工具画移动端；画得比你希望的慢；你根本没在画线框图。
        • Olsen 顺带说了句对工具惰性的批评：他见过太多设计师和 PM 因为死抱着自己熟练的旧工具而错过下一个大工具——生产力当然重要、换工具确实有时间投入，但新工具带来的新能力和掌握后的更高产出往往值得。
        • 注释（annotation）：线框图上加说明可以承载大量产品规格（下拉菜单该有哪些选项、某个表单域最多允许输入多少字符、某条错误提示的具体措辞）。显然，给用户看的版本不该显示这些注释。
        • 可点击线框图已经取代静态线框图成为常态：静态版要求用户说"我会点这个按钮"、然后你手动换下一张；可点击版让用户能独立探索和导航，体验更沉浸，而且因为通常在产品实际会被使用的那类设备上测试（电脑/平板/手机），感觉更真实。你通常只让与本次测试相关的控件可点，这条路径叫"快乐路径（happy path）"。
      • 视觉稿（mockup）：更高保真，体现颜色、字体、图像等视觉设计细节，有的追求像素级精确。也叫 comps，通常用 Illustrator / Photoshop / Sketch 做，输出静态图片；用 InVision（或 Balsamiq）设置"热区"把多张串成可点击的用户流。因为可点击视觉稿看起来和感觉起来都非常接近真实应用，它们能带来非常有价值的用户反馈。 有些擅长做可点击视觉稿的团队直接从这里开始做用户测试——他们仍会先做线框图，但不拿线框图去要用户反馈。
      • 交互原型：比可点击视觉稿更进一步的交互层次，可包含真正工作的下拉菜单、悬停效果、输入表单、音视频播放器。通常用 HTML/CSS/JavaScript（常配 jQuery、Bootstrap）构建，也可用 Ruby on Rails 等做轻量服务端功能；Axure 这类工具能在不写代码的情况下导出 HTML/CSS/JS。
      • 绿野仙踪 MVP 与管家式 MVP（"手工黑客"MVP）：这两者是真实可用的产品或服务，只是用人工变通来实现。Olsen 管它们叫"手工黑客 MVP"——低效、不为长期设计。
        • 管家式（concierge）MVP 的思路是深度介入少量早期客户，真正理解目标市场、他们的需求与偏好、以及如何为他们定制产品；最适合服务类，尤其是需要与客户大量交互和输入的流程。
        • 案例——Airbnb：产品总监 Joe Zadeh 在 SXSW 讲过，团队假设带专业照片的房源会有更多生意。于是他们手动招募房东提供专业摄影服务、手动招募摄影师与房东配对；约好拍摄、拍完后摄影师把照片传到 Dropbox，Airbnb 员工再手动上传到对应房源，然后 Airbnb 付钱给摄影师。结果验证了假设：带专业照片的房源预订量是市场平均的 2–3 倍。 验证之后，Airbnb 才把大部分手工步骤替换为自动化——系统自动邀请房东使用专业摄影、自动分派摄影师、自动更新房源照片。Airbnb 通过"先验证假设、再投入资源建自动化方案"降低了风险和潜在浪费。
        • 绿野仙踪 MVP 与管家式类似，都是短期人工执行某些步骤；区别在于客户并不知道这些步骤是人工的——就像电影里那样藏在幕布后面。它在用户看来就是真实上线的产品。 目的是在投入建自动化方案之前，先验证那些必需的步骤。
      • 真实产品：理想情况下建 MVP 之前你已经用逐级提高保真度的物件验证过设计。即使一路测过设计物，产品造好后再测一次仍是好主意——设计与开发之间常有偏差，而且真实产品是最高保真，你可能学到低保真测不出来的东西（如网页在不同屏幕尺寸和浏览器下的表现）。可以有主持（moderated）或无主持（unmoderated）；有主持可当面或用 Skype/WebEx/join.me 远程。
  • 定量产品测试：有了真实产品和一定量的使用后才能做。
    • 假门 / 404 测试（fake door）：为一个你在考虑要不要做的新功能加一个入口（链接或按钮），看多大比例的客户会点，从而在投入资源之前判断客户是否真的想要。因为功能还没做，点进去通常是一页"感谢你的兴趣，此功能尚未上线"，还可以加个表单问客户为什么觉得这个功能有价值。极端做法是连落地页都不做——技术上你光靠点击就能统计，链接直接指向站点的通用 404 页。
      • 案例——Zynga：这家以定量产品测试著称的游戏公司常用假按钮。联合创始人 Mark Pincus 在斯坦福科技创业项目的一次演讲中描述：团队会给每个新游戏创意想一个五个词的推销语，然后把它作为推广链接短时间发布在他们正在运营的游戏里，看能引发多少客户兴趣。
      • Olsen 的注意事项：要留心假门测试跑多久、跑多频繁，别惹恼客户。最好只跑到拿够所需样本量就撤掉，而不是长期挂着。
    • 产品分析与 A/B 测试：分析本身不算测试，但能让你看到客户实际怎么用产品（哪些功能用得最多、时间花在哪）；产品变更上线后看关键指标的变化，就是在检验你的假设。分析也是 A/B 测试的基础（结果要靠它算）。工具：Google Analytics、KISSmetrics、Mixpanel、Flurry。
      • 一条实操差异很值得记：营销 A/B 测试大多数公司用第三方工具；产品 A/B 测试则很多公司最终选择自建，以便与代码更紧密集成、获得更多灵活性。主要原因是大多数 A/B 工具走 JavaScript 方案——测前端（客户端）变体没问题，但要测复杂的后端（服务端）变体时帮助有限。
      • 流量不必均分，只要样本较少的那个变体有足够数据点算统计显著就行。Olsen 补了一句有画面感的话：很多公司一直在做实验，把小部分用户暴露给几十上百个替代功能或设计——你偶尔在 Google、亚马逊等大站上看到一个新按钮、新功能或新设计，如果你和另一个用户看到的不一样，你们中的一个多半正是 A/B 测试的实验对象。
      • 收尾判断：熟练掌握分析与 A/B 测试能实现快速迭代，这是伟大产品团队与其他团队的分水岭。

第 8 章 · 运用优秀 UX 设计的原则

• 这一章的定位（Olsen 特意说明）：它不是六步流程里的一步，而是服务于第 5 步"做出 MVP 原型"的。整章献给 UX，是因为它对达成 PMF 太关键。这章不会把你变成世界级设计师，但会给你 UX 设计的全景与关键概念——对 PM、开发和其他与设计师紧密协作的人尤其有用，让你能和设计师有更丰富的讨论、对设计过程有更多贡献。
• 什么造就好 UX：坏 UX 的症状——不直观、难用、找不到你要的、不清楚下一步做什么、走进死胡同、收到晦涩的错误信息、文字难读、设计不美观。好 UX 则毫不费力，你甚至注意不到界面本身，能专注于手头任务；产品甚至可能有趣，并传递信心、安心这类情感收益。优秀设计可能带你进入心理学家所说的"心流"状态。
  • 但 Olsen 立刻把它拉回金字塔：无论多易用多漂亮，如果客户不看重产品提供的收益，它就无法交付好体验——收益活在价值主张层，比 UX 层低两级。所以评价 UX 的一个角度是：它在多大程度上帮助（或妨碍）功能传递出预期的客户收益。坏 UX 挡路，好 UX 让用户轻松拿到功能提供的收益。
• 可用性（第一支柱）：关注用户的目标和为达成目标要执行的任务——多大比例的用户能成功完成每个任务？多大比例虽然完成但中途遇到问题？ 通过可用性测试（请用户完成关键任务并观察）得到答案。
  • 还包括效率：能搞明白但步数太多、耗时太长，也是差可用性。效率容易度量——数点击/轻触/击键等动作次数，或计时。
  • 除了物理努力，还有感知努力：要留意 UX 给用户施加的认知负荷——信息给太多、选项给太多会压垮他们，也会消耗他们的知识或记忆。好 UX 避免要求用户付出大量体力或脑力。
  • Olsen 可用性定律（他自己命名的原创）：一个动作要求的用户努力越多，会去做它的用户比例越低；要求的努力越少，会去做的比例越高。 Olsen 说他在评估无数用户体验时一次次看到它成立。它的价值不止于可用性——还直接用于提升对你生意成败至关重要的用户行为的转化率（如提交注册表单、走完支付流程）。
  • 主观感知也重要：可以用 7 点双极量表问"这个产品用起来有多难/多容易"。测试结束还可以问"产品多好地满足了你的需求""你对产品有多满意"。但要清醒：他们的回答不会基于你意图中的价值主张或功能集（他们多半根本不知道），而只基于他们实际的使用体验。Olsen 那句话很扎心："如果用户找不到你那个有价值的功能、或者搞不懂怎么用，你不会因为拥有它而得到任何分数。"
  • 可用性是相对某个用户画像而言的：目标客户的知识/技能水平不同，技术娴熟度和领域知识不同。面向受过高度训练的高级用户的产品，其可用性预期与面向大众消费市场的产品完全不同——你的人物角色应当为此提供依据。
  • 易学性：用户从"完全不懂你的产品怎么用"到"有可用的知识"再到"精通"，需要多少时间和努力？这对新用户尤其重要——他们会很快判断这个产品适不适合自己。很多体验好的产品用新手引导（onboarding）的教程和指南来解决这个问题，这些引导之后会消失或可被用户关掉。
• 愉悦（第二支柱）：强可用性帮你避免差 UX，但不足以交付好 UX。可用性回答"客户能用你的产品吗"，愉悦回答"客户享受用你的产品吗"。 愉悦超越"避免让用户挫败"，指的是唤起正面情绪。
  • 美观：客户在开始用之前先看到你的产品，视觉吸引力帮助建立正面第一印象；宜人的设计能传达高品质感、让产品显得更可信、让用户放松。
  • 简洁：UX 里常常少即是多——去掉视觉杂乱能降低认知负荷，帮用户聚焦重要的东西。想想 Google 首页那种极简设计，除了搜索框几乎什么都没有。
  • "能读心"的体验：替用户选好智能默认值、或主动回应他最想问的问题，会让用户觉得产品懂他、有同理心。（第 5 章的 Google Suggest 就是例子。）
  • 个性：通常通过语言的语气传达；幽默（文字和有趣的图片）也是制造愉悦的好办法。
  • 动态响应：一个绝佳例子是 iOS 里滚动超过文档或网页末端时的"橡皮筋"回弹效果——太有意思了，很多人不管有没有意识到，都忍不住去拨弄它。动画和音效也能贡献愉悦：很多 Quicken 用户喜欢录入一笔交易后听到的收银机"叮当"声；苹果 Mac 的开机提示音同样能唤起许多用户的正面情绪。
  • 意外：Twitter 早期服务中断时，用户看到的不是普通的错误页，而是那只著名的 "fail whale"（失败鲸） 图。
  • Olsen 自己最难忘的一次（本章最生动的段落）：他用邮件营销服务 MailChimp 时，写完要发的营销邮件后可以预览它在不同屏幕宽度下的样子。当你改变预览宽度时，界面上 MailChimp 的猩猩吉祥物会伸长手臂指着标尺上的像素数；说明里警告邮件宽度不应超过某个值。当你把宽度加大到某个点，猩猩脸上的表情会从开心变成痛苦，并冒出"太宽了！""停下！"之类的文字警告；如果你继续加宽超过推荐最大值，猩猩的手臂真的会断掉，还有一个 "POP!" 的图形。 Olsen 说他觉得这个体验太聪明、太好笑、太出人意料，以至于多年后依然记忆犹新。
• UX 设计冰山（本章的核心框架）：像真正的冰山一样，只有一小部分 UX 设计是可见的、立刻能察觉的，水面之下还有多得多的东西。自下而上四层：
  • ① 概念设计（conceptual design）：你用来设计产品的核心概念。理想情况下你的概念模型应当与目标客户的思考方式产生共鸣——基于好概念设计的产品会让人觉得直观、易用。这一层往往是产品创新最大的贡献来源。 Olsen 特意指出：把 UX 冰山放在 PMF 金字塔顶端 UX 层的位置上，你会发现概念设计层恰好紧挨着功能集层之上——概念设计正是给功能注入生命、赋予它们形态的东西（不是外观细节，而是"它们如何运作以为用户创造价值"的本质）。
    • 例子一（回扣第 1 章）：Quicken 之所以比 46 个竞品好用得多，很大程度上归功于它把支票簿当作隐喻的概念设计。
    • 例子二——Uber 的概念设计：Uber App 用的是以地图为中心的设计。地图型设计本身并不罕见，Uber 概念设计的创新在于实时展示附近车辆的位置——包括你下单前可供叫车的那些，以及你下单后被派给你的那一辆。值得指出的是，实现这个设计需要技术创新（实时追踪司机位置）。Uber 知道出租车客户最恼火的就是迟到和放鸽子，所以把"让用户清楚知道车什么时候到"定为价值主张的关键。这个设计让 App 的价值主张对第一次使用的用户立刻变得显而易见，并瞬间传达出这个服务与"招手打车或电话预约出租车"有何根本不同。
  • 用户研究（贯穿各层的支撑）：好的概念设计来自对目标客户及其需求的深刻理解。UX 里那个常被忽视的字母是 "U"——用户。 用户研究者用探索访谈、可用性测试、调研等一系列技法来了解客户；用户研究为冰山的所有层级提供信息。当客户对你的 UX 给出反馈时，把反馈解析并映射到冰山对应的层级上会很有帮助。
    • 一条重要的组织纪律：必须确保不是只有 UX 研究员一个人获得了大部分学习。产品团队成员应尽可能多地亲自观摩用户研究——亲历用户研究比读研究报告的冲击力大得多，就像"在前排现场看一场比赛"与"第二天读一篇报道"的差别。 研究结束后应尽快开团队复盘，各自分享和讨论观察；同时把结果摘要与关键结论写下来以固化学习并让其他人可及。
  • 人物角色在 UX 语境下的额外用途：除了用户目标，还有两点与 UX 设计特别相关。① 用户的技术娴熟度：不擅长技术的用户需要非常简单、聚焦最重要任务的界面加上清晰说明和好的帮助系统；技术高手不太在乎这些，反而偏好更强大、更灵活、更高效的工具。要在同一个产品里同时照顾两类用户，UX 设计上常有张力。 ② 使用场景：如果用户时间紧迫，关键信息和高频功能必须唾手可得；如果是"靠着看"的场景，界面控件应当不那么显眼、退到背景里，让内容居于中心；如果产品在嘈杂环境中使用，你多半不该依赖语音命令。
    • 命名为什么关键：团队在不同设计方案间纠结时，可以问自己"哪个最能满足 Nancy 的需求？"很多团队甚至做人物角色的纸板真人立牌放在工作区，提醒自己在为谁设计。
  • ② 信息架构（IA）：定义软件产品的信息与功能应当如何组织。产品通常由多页面/多屏构成，组织方式有很多种。客户通过导航系统访问产品各部分；找某个页面时，客户依赖导航标签来推断产品是怎么组织的、并猜测目标页在哪。卡片分类（card sorting）是用来了解客户如何看待产品各部分及其关系、从而找出他们偏好的组织方案的研究技法。好 IA 让产品的组织方式对用户直观、标签易懂，从而带来好的可用性与可发现性。
    • 可发现性（findability） 的度量：让一组测试用户去找某个页面，看多大比例成功；也可以从分析工具看导航路径——用户是走最短路径到达每个页面，还是迷路走了更长的路、或频繁点浏览器返回键。
    • IA 处理的是高层次的功能集：功能是什么、如何组织、如何命名。此时你还不该考虑用户流、页面布局或视觉风格。
    • 主要交付物是站点地图（sitemap）：虽然名字来自 "site"，但它是用来给任何软件产品（包括移动 App）定义结构的设计交付物。它展示所有页面/屏、如何组织成区块、提供哪些高层导航模式，还规定页面标题和用于标记各区块的词。你应该拿站点地图去测用户——确保你的标签传达了预期含义，并且在被要求找不同功能对应的页面时，他们能用你提出的结构轻松找到。（书中示例是一个视频广告投放 web 应用的站点地图：方框代表页面，连线代表导航路径，单向导航用箭头标出；全局导航项——从任何页面都能到达的页面——被清晰标识出来，对应你在网站顶部看到的主要链接；每个区块的子页面以清晰的层级展示；地图还标出哪些页面行为异常，比如以弹窗打开或在新标签页打开。）
  • ③ 交互设计：决定产品与用户如何互动。它规定用户流——每一步用户能做什么动作、产品如何响应；也管用户如何录入信息（如表单）。任何用户可交互的界面控件或链接（点击、悬停、拖动、输入、轻触、滑动等）都属于交互设计。
    • 例：注册表单里"问用户要哪些信息、表单域如何设计、什么算有效/无效输入"都属交互设计，"用户点了注册按钮之后发生什么"也是。任何由多个页面或步骤组成的用户任务都需要交互设计。
    • 操作模式与状态：如果产品除正常操作外还提供编辑模式、预览模式等"操作模式"，它们属于交互设计；不同状态（电商产品可以是有货/无货/在购物车里/已下单）以及状态之间被允许的流转（必须有货才能加购物车，必须在购物车里才能下单）也是。好的设计会在整个流程中让用户清楚这些状态。 Olsen 特别指出：对交互设计重要的状态，往往与概念设计（最底层）紧密相连——上例中的概念设计就是"虚拟购物车"，类比现实中的购物车；Uber App 的概念设计与用户行程状态之间也有根本联系：下单前显示所有附近车辆，下单后只显示那一辆。
    • 反馈：系统如何响应用户动作。错误信息属于这一类——应写得清楚，解释为什么出错以及用户可以怎么修复。响应时间是反馈的另一面：用户点了按钮却没有任何"正在发生什么"的提示，他们会以为点击没生效或产品坏了。慢性能就是差的交互设计。 即使系统的最终响应无法很快完成，只要用户会感知到延迟，就应给出确认他们点击的反馈——旋转动画是常见解法，也可以显示一条说明产品在做什么的信息（如"正在搜索数千个航班，为你的请求匹配最佳结果"）。若任务耗时较长，要给用户进度感和剩余时间感——进度条就是好工具；对多页向导这类长流程，给用户一个"总共几步"的高层认知加上"你在这里"的进度指示会很有帮助。
    • 最好的案例——TurboTax 的交互设计：报税是极其复杂的过程，跨很多表单、有数不清的问题要回答。TurboTax 团队却创造出了一个能一步步引导新手走完全程的体验，这非常不简单。
      • 模式一 "EasyStep"：概念设计是一场结构化访谈，一次只问一两个问题引导用户；产品根据用户之前的回答动态决定下一个该问什么。这个设计让用户一次只需专注一件事，同时把其余所有问题以及问题之间复杂的依赖关系全部隐藏起来。 主要交互就是回答眼前的问题（向导式界面）然后点"继续"。EasyStep 的交互设计还允许有经验的高级用户跳步、在访谈里跳转、按自己的意愿填写信息。
      • 模式二 "forms"：直接看到真实的税表和工作表，数值已由 EasyStep 访谈填好，可以直接编辑。TurboTax 用户可以完全不进 forms 模式就完成报税，也可以在两个模式间轻松切换；很多用户从没见过背后的表单（它们主要给高级用户用）。通过这两个模式，TurboTax 用同一个产品有效地同时照顾了新手和专家的需求。
    • 流程图（flowchart）：把复杂流程或任务变简单的主要设计物。它规定 UX 里关键任务的可能流向，展示用户和产品双方能采取的动作与做出的判断——动作用矩形块，判断点用菱形块（也叫条件），块之间用箭头连接表示允许的流向。（书中示例是 UX 设计师 Christine Liu 为 CarMax 移动应用做的流程图：App 用客户的 Facebook 数据推荐可能喜欢的车，用户可以浏览推荐车辆、查看每辆车的详细信息，直到找到中意的，然后通过邮件、聊天或电话联系 CarMax 经销商预约看车。注意流程图在高层定义 UX，不涉及任何单屏的设计细节。）
      • 一条现实的取舍：简单流程下，很多团队跳过正式流程图，直接做可点击线框图——因为线框图更可视化、更交互，在传达交互设计意图上往往更有效，能很好地说明"快乐路径"的流转与交互，再用注释补充错误状态和其他要点。但如果用户流分支很多、要规定的状态很多，流程图能更好地捕捉和传达这份复杂性。 此外流程图还能让团队所有人（尤其是负责实现和测试的成员）理解端到端的用户体验。
    • 线框图在流程中的位置（一个重要的门槛）：通常在你清楚了用户流之后才做线框图。Olsen 说线框图代表精益产品流程里的一个重要阈值——在此之前你花了大量时间思考客户、需求、价值主张、功能集、IA 和用户流，而现在，你第一次真正规定"客户使用产品时会看到什么"。
      • 此时不必操心像素级精度或颜色，你要确定的是每页/每屏的布局：该有哪些组件、如何排布。你问的是"这页该是一栏还是两栏？""这页图片放左边表单放右边，还是反过来？"
      • 一条重要的方法论提醒：任何非平凡产品的线框图不可能一次坐下就画完，它需要迭代，而且没有"正确答案"。你知道问题空间的目标，正在寻找满足这些目标的不同解决方案空间备选。不要固着在你想到的第一个设计方向上，要刻意实践发散思维，尽可能多地想出不同的设计方向——就像头脑风暴：此刻只管产生、不管评估，之后有的是时间毙掉坏点子。但如果过早收窄，你就有只探索了解空间一小部分、最终停在局部最优的风险——而更好的解法其实还没被发现。
      • 模板化：好设计师不会每页从零开始画，而是跨产品识别出应当相似的页面组，每组共享一个定义布局的模板（比如所有两栏页共用一个模板），并把出现在多个页面上的组件标准化——这有助于保证设计一致。
  • ④ 视觉设计（冰山露出水面的部分）：也叫图形设计、外观风格、"镀铬层"。就像汽车上的镀铬件，它不决定产品做什么、也不决定你怎么用，但它决定产品看起来怎么样。 除了美观，好的视觉设计还强化视觉层级、贡献易用性，并能传达品牌个性、制造愉悦、让产品与众不同。三大组件：
    • 色彩：其他各层的设计物都可以用黑白做且完全够用，只有做高保真视觉稿规定视觉设计时才必须定颜色。色彩贡献美感，也用来让某些元素比其他更突出，还能传达特定属性或情绪：暖色（红橙黄）更有能量、更热烈；冷色（绿蓝紫）更平静、更内敛。很多应用和网站用蓝色系，因为它传达可信赖与平静；绿色关联自然、成长与金钱；紫色暗示奢华与创造力；红色关联侵略性、激情、力量与危险；橙色有活力；黄色传达快乐与阳光；棕色关联温暖与大地；黑色暗示精致、优雅与神秘；白色关联纯净、洁净与简约。Olsen 加了一条重要的限定：这些是常见概括，颜色的含义在世界各地会有差异——如果你的目标客户属于某个特定文化，设计时要留意他们如何感知颜色。
      • 调色板：不要随手用色，好的视觉设计有刻意的调色板——挑一组互相搭配的颜色，并且只用这些。一致地用色有助于形成有凝聚力的视觉设计。 调色板通常有一到两个主色、一到两个背景色，可以再有一两个强调色来衬托主色；完整调色板还包括由主色派生的额外颜色（通常是同色相更浅或更低饱和度的版本）。
      • 色彩直接影响可读性与可用性：文字与背景之间必须有强对比——黑字白底是高对比，浅蓝字配浅灰底则低对比、几乎看不见。关键控件（按钮、主导航）的用色应让它们清晰突出——黑底上的橙色按钮会跳出来，稍深蓝底上的蓝色按钮不会。
    • 字体排印（typography）：早期网页浏览器只支持少数几种字体（Arial、Georgia、Verdana），CSS3 网络字体普及后选择大大增加。不同字体传达不同属性：正式 vs 非正式、经典 vs 现代、轻盈 vs 戏剧化。衬线 vs 无衬线是关键区分——传统建议是衬线适合高分辨率的印刷品、无衬线适合低分辨率的网页；但随着网络字体普及，线上衬线字体的使用增多。小字号时衬线体在屏幕上难读，但常用于标题等大字号元素。比颜色更需要克制：常见做法是选两种字体，一种用于正文、一种用于标题等大字；网站和 App 常见的组合是正文无衬线 + 标题用互补的衬线。字号方面正文要足够大到可读、标题更大，同样要避免用太多不同字号并保持全产品一致；字体还有粗细和样式变化（粗体、斜体、下划线）。排印通常在建立视觉层级中扮演重要角色——你应刻意设计文字元素的颜色、相对大小、粗细和位置来营造想要的视觉层级。
    • 图形：照片和插图。对电商这类品类，用好图片至关重要——以 Airbnb 为例，客户要感到放心才会租住一个地方，他们需要看到照片（第 7 章说过 Airbnb 用更高质量照片让预订量翻了不止一倍）。图片也常用于落地页和其他营销页面，主视觉图（hero image）很常见——一张大而显眼的照片展示你的产品、典型客户或某个有艺术感/激励性的场景（Netflix 常用大幅"客户正在享受节目"的照片）。插图常用来解释产品如何工作；还可以用线条、形状、纹理、渐变、阴影等图形元素，这些小处理能通过增加结构、深度和亮点帮你达成想要的外观风格。
      • 图标：代表对象或概念的小符号，最常用于按钮或其他界面控件，尤其在空间紧张时。很多应用里图标就是使用产品的主要方式——浏览器的前进/后退/刷新按钮、Photoshop 那条塞满图标的工具栏、Office 那条图标"功能区"。图标学是视觉设计里的专门领域，图标设计师要逐像素手工调整才能造出这些微型杰作。 随着移动设备使用增加，好图标设计的重要性上升——小屏幕让空间极其宝贵，所以移动应用里很多控件是图标。
      • 一条极实用的建议：客户必须看一眼图标就懂它的意思，但因为图标很小、又只是没有文字的符号，传达预期含义可能很有挑战。如果你的设计里某个图标已有标准化符号，强烈建议直接用它，不要试图发明新符号——做音频播放应用时给播放和暂停按钮设计图标，放着人人都认识的"右向三角形=播放""两条竖线=暂停"不用而另造一套，是很傻的。多图标的应用还要注意图标集内部的设计一致性：每个图标当然要有独特符号，但整体形状、颜色和风格应当与整套保持一致。
    • 样式指南（style guide）：为达成一致外观风格的视觉设计交付物，对页面/屏幕很多的产品尤其重要。它规定常用元素的视觉细节——颜色、尺寸度量、字体、图形。样式指南有助于保持一致性（尤其当多位设计师同时在做同一个产品时），也能减少 UI 开发者的工作量。
    • 布局网格（layout grid）：帮你确保每页/每屏设计元素对齐一致的设计工具。网格在印刷设计里历史悠久，用在网页和移动设计里能带来更好的 UX。网格由若干等宽列构成，列间以"沟槽"或边距分隔。
      • 书中示例：12 列、每列 94 像素宽、沟槽 18 像素宽，总宽 1326 像素——为 1366 像素宽的屏幕优化，使用户不必横向滚动；这个宽度为垂直滚动条以及浏览器或操作系统的其他视觉元素留出了最多 40 像素。
      • 用法：布局时把所有页面/屏幕元素对齐到网格上（元素可以是一段文字、一张图或一个按钮），元素可以跨多列，关键是元素的左右水平边缘要起止于网格线上。为什么选 12 列：它能被 2、3、4、6 整除，允许很宽的元素宽度组合。
      • 一条现实约束：示例中的网格只做水平划分（列）。印刷设计里的网格常常也规定垂直划分（行），但垂直定位的网格线在网页上一直不太有用，因为屏幕高度差异极大；而且浏览器会根据屏宽动态渲染内容，很难精确控制元素的垂直位置。因此数字网格倾向于只关注水平划分。（不过随着响应式设计出现，设计师对网页元素垂直位置的控制力增强了。）
      • 网格的过渡价值：线框图阶段的布局通常只描述元素的大致位置和相对大小；网格通过实现精确的、像素级的布局，帮你完成从低保真线框图到高保真视觉稿的过渡。
• 设计原则（第二部分）：Olsen 说设计是精益产品流程里神奇的部分——关于收益和功能的无形想法在这里被转化成真实的用户体验。设计在很多方面更像艺术而非科学，但有几条原则能帮你做出更好的体验。
  • 格式塔原则（Gestalt）：描述人类如何在视觉上感知对象的一组理论。gestalt 一词意为"一个被感知为大于其各部分之和的有组织整体"——这正是我们的视觉处理系统试图对所见之物做的事。Olsen 聚焦两条：
    • 邻近性：大脑把靠得近的对象感知为比离得远的对象更相关。因此设计中应把相关对象放得近。这条在你确定线框图布局时就要应用，内容和界面控件都适用——比如示例线框图里所有主导航链接放在一起；如果界面给用户三个前进选项，那三个按钮或链接就该放在一起。同时要避免把不相关的东西放得太近，否则用户会推断它们相关——例如把某个功能的取消按钮放得离同页另一个功能太近，会让用户困惑这个取消按钮到底影响哪个功能。
    • 相似性：大脑把共享相似特征的对象感知为比不共享的对象更相关。因此设计中相似或相关的对象应当看起来相似（相同形状、大小或颜色），并避免让不相关的对象看起来像。这条应用在你确定视觉设计时——例如规定所有超链接都是蓝色带下划线，或所有动作按钮都用同样的圆角矩形。
  • 视觉层级：决定用户认为设计中哪些元素最重要——这种重要性驱动用户的注意力，影响他们观看各元素的顺序。
    • 尺寸和颜色是创造视觉层级的两个主要属性：大脑假定更大的对象更重要、更小的更不重要；也假定高对比（颜色让它跳出来）的元素更重要。突出的图片有同样效果，而且我们的眼睛天然被人的照片、尤其是脸吸引。
    • 位置也影响视觉层级，因为用户从页面顶部开始读；在英语等从左到右的语言里从左侧开始读。因此在其他条件相同时，人们会先看屏幕左上角附近的元素。
    • 一个很好用的小技巧：想快速判断一个页面的视觉层级，眯起眼睛——你看不清文字和细节，但能注意到主要设计元素的位置、大小和颜色。也可以截图后用图形软件把它模糊化，效果一样。 在视觉层级强的产品上做这个测试，你能识别出最重要的设计元素。
    • 正确做法：先确定页面上各组件的相对重要性，再设计它们的位置、大小和颜色来强化这个排序。视觉层级好的页面会把用户的眼睛吸引到最重要的元素上，然后按优先级顺序把视线从一个元素引到下一个，通常沿着直观的从上到下、从左到右路径。这帮助用户找到他们要找的东西并成功完成任务，也带来关键用户动作更高的转化率。
  • 构图原则（评估设计时的四问）：统一性——页面感觉像一个统一整体还是一堆不相干的元素？对比——颜色、大小、排布等有足够变化来创造视觉趣味吗？平衡——你是否均匀分布了元素的视觉重量（位置、大小、颜色等）？空间使用——设计感觉多拥挤或多稀疏？确保设计有足够留白（页面上你没有使用的空间）对于避免让用户感到拥挤很重要。
  • 响应式设计：规定元素排布时你必须对"画布"尺寸做假设（显式或隐式的）。印刷设计里你确切知道纸张的宽高，数字世界没这么简单——客户会在各种屏幕尺寸的设备上使用你的产品。
    • Olsen 列举了碎片化的现实：智能手机屏幕比笔记本和台式显示器小得多（初代 iPhone 是 360×480），如今手机尺寸的跨度前所未有；平板填补了手机与显示器之间的空白；平板手机（phablet）又填补了手机与平板之间的空白；高端则是大分辨率台式显示器；可穿戴设备（如 Apple Watch）及其极小的屏幕让分辨率范围进一步扩大。
    • 响应式设计的机制：不是用一个设计去迁就所有人，而是让不同屏幕尺寸的用户看到不同版本的界面——设计响应用户的屏幕尺寸（通常是宽度）。做法是先确定你要用的宽度"断点"，再对每个宽度应用想要的样式差异。常见是电脑屏一个大宽度版本、手机屏一个小宽度版本，很多产品还为平板加一个中间断点。屏宽从宽变窄时，一些页面元素开始"换行"（被推到下一行），一些元素变小或干脆消失。响应式设计让这些动态 UX 变化不需要大量额外编码工作或复杂度。
    • 该从大屏还是小屏开始设计？（一个真问题）：如果你先为大屏设计，再改成小屏会很有挑战——同样多的内容装不下，很难决定去掉什么；导航多半要改；太宽的内容要重新构思和替换。这类团队常常最后做出第二个独立产品、用另一套代码库——这并不理想：两处代码要改动和新增导致低效并增加出错概率；而且因为移动版和非移动版不是一起设计的，它们常常看起来和用起来差异很大，造成不一致的体验、让客户困惑。
    • 因此很多团队采用"移动优先"：先为最小屏设计，因为这会迫使他们优先考虑什么最重要；移动设计推进到一定程度后再做更大尺寸，大屏往往能轻松容纳额外的内容和功能。
    • Olsen 在这里加了一条极重要的澄清：意图不是让两个设计按先后顺序或彼此分离地完成，它们应当并行进行，只是由移动设计来引领这个过程。 而且移动版常常不只是全尺寸产品的缩小版，而是与网页版扮演互补角色——它可能有网页版没有的独特功能（如利用地理定位或其他传感器），或者提供全功能的一个更聚焦的子集。并行设计有助于确保两者协同交付一个达成 PMF 的用户体验。
  • 文案也是 UX 设计的一部分（常被忽视的一节）：客户看到的文字，无论在营销页还是产品里。营销页文案质量能造成转化率的重大差异；而产品内的文案——标签、说明、描述、错误信息——会真正影响可用性。
    • 用户往往只有很少的文字作为指引，所以按钮和链接上的标签必须清晰易懂。用户想执行一个重要动作却不确定该用哪个按钮，这是重大可用性问题。
    • 功能描述和说明应用简单的、用户能懂的词写，不要用内部或行业黑话；错误信息应当有帮助、能解释，而不是晦涩难懂。
    • 好消息是识别和修复问题文案相对容易——你只需要做产品的可用性测试。Olsen 给了一个很实用的技巧：测试中如果用户对某个词或短语感到困难，你应该问他们会怎么称呼它——他们常常给出很好的建议。
  • A 队（The A-Team）：UX 设计横跨好几种不同技能，很多公司存在"设计缺口"——创造优秀 UX 所需的全部技能并不齐备。很多团队根本没有设计师；即使有，那个人多半也不是各项 UX 技能都强。一个设计师有可能在多项技能上都强，但更常见的是他要么偏视觉设计（产品看起来如何）、要么偏交互设计（产品如何工作）。要做出优秀 UX，你的团队在这两方面都需要有人才；此外还需要一位能娴熟实现设计的前端开发，以及一位强产品经理。Olsen 把具备这四项核心技能——产品管理、交互设计、视觉设计、前端开发——的团队称为 "A 队"（取自 1980 年代那部流行美剧）。他补充说其他角色当然重要（后端、QA、DevOps 等），但就创造优秀 UX 而言，有一支 A 队是关键；而且除了各人具备所需技能之外，这些成员能否有效协作同样至关重要。
  • UX 好不好由旁观者说了算：最终你的客户才是你 UX 好坏的裁判，而这影响你的 PMF。回到第 3 章的技术采纳生命周期：创新者可能愿意为提供尖端收益的突破性产品容忍不合格的 UX；但当你试图沿生命周期推进、渗透更多细分人群时，他们不会那么宽容，UX 对 PMF 就变得更重要。Olsen 收尾说得很硬气：尽管好设计需要大量技能和工作，但"拥有糟糕用户体验"这件事真的没有借口——你本该把设计拿给客户看，去发现并解决问题。

第 9 章 · 用客户测试你的 MVP（步骤 6）

• 开场的一个关键概念——产品盲区（product blindness）：当你离产品太近时，你极难、往往根本不可能像新客户那样看它——你对自己的产品的熟悉程度超过任何新用户可能达到的程度。结果就是你对"新用户几分钟内就会撞上的问题"存在盲点。用户测试是产品盲区的解药。
  • 配套的亲身经历：Olsen 为云协作创业公司 Box 做第一批用户反馈会时，对团队来说是一次大开眼界的体验——他们学到太多新东西，当场就看到了用户测试的价值并想做更多。
• 一次测几个人？：推荐一次一人效果最好。
  • 为什么不做焦点小组：焦点小组一次 6–12 人，负面群体动力学明显——有些人怕被评判或批评而不敢说真心话；一两个健谈的人常主导讨论、淹没其他声音；还常出现群体思维，全组或大部分人人为地收敛到同一意见，导致数据不准确。
  • 一对一则没有这些问题，能有更丰富、更深入的对话，客户更可能开口说真实感受，尤其当主持人是房间里唯一的另一个人时。Olsen 的观察：观察者越多，有些客户越担心被评判。
  • 关于记录员：很多主持人喜欢带一个记录员以便专注主持，这没问题；Olsen 个人偏好自己记笔记——这样能确保自己的洞察被捕捉到，而且是真正的一对一访谈。若想让观察者实时观看，用摄像头把画面投到另一个房间的显示器是好办法；远程测试则观察者可以加入屏幕共享。
  • 他也诚实地讲了自己破例的一次：曾一次同时测两三个客户，效果还行——因为是对着打印出来的视觉稿给反馈，大家围坐一张桌子，都能看到并指向桌上的纸。如果每个客户各看各的笔记本电脑，多半就不行了。 他这么做是因为客户想很快拿到研究结果，这样能一天谈更多人；另一个附带好处是：研究对象放鸽子是用户研究的常态，一场排两三个人，万一有人没来他也不至于干坐着。
  • 每波测几人：太少有漏掉问题、以及把不具代表性的意见当真的风险；太多则耗时耗资源，会越过收益递减点——你只是不断听到同样的反馈、学不到新东西。Olsen 的经验值：每波 5–8 人是很好的平衡——足以发现主要问题并识别跨用户的模式。每波之后你会根据学到的修改产品或设计物，再拿给新一波客户测，直到验证达成 PMF。
  • 放鸽子率：典型约 10%。实操建议——比你想要的样本量多约一个（想谈 7 个人就约 8 个）。
• 当面 / 远程 / 无主持三选一：
  • 首选当面。坐在用户旁边能收集到比屏幕共享丰富得多的数据：你能同时看到用户的屏幕和脸，能捕捉叹气、面部表情等细微线索，能看到用户的眼睛在看哪里；而且当面更容易建立融洽关系，客户感觉更自在因而给出更好的数据。
  • 远程有主持：找不到附近的目标客户时的好办法，虽不如当面但仍能拿到有价值信息。屏幕共享用 GoToMeeting、WebEx、Skype、Screenleap、join.me。Olsen 明确提醒要为技术故障做准备：常见的是客户没装屏幕共享所需软件、或需要帮助才能跑起来；共享程序本身也可能碍事（造成用户困惑、或把你要展示的设计物缩小）；客户动作与你屏幕上看到的之间常有延迟；防火墙也会带来问题。
  • 远程无主持：用 UserTesting、Validately 这类服务。优点：结果更快（通常不必花时间招募和排期，多个用户可同时测试，不受主持人档期约束）。缺点：你不在场引导，用户跟着书面说明走，所以你必须在测试流程结构和指令措辞上投入更多思考；最好先找一两个人试跑再大规模招募；而且你无法随机追问（比如"你为什么点那个按钮？"）——所有想让用户回答的问题必须事先给出，因此措辞要比有主持时更细致。
    • 工具选择的一条具体建议：大多数无主持工具聚焦录制用户屏幕上的操作、鼠标移动和点击。看到屏幕有帮助，但听到用户的语音价值更大；有些工具还录用户的脸。另有一些工具不录用户也不录屏，只统计点击和点击率——这类定量信息在你规模化上线后有用，而且你的分析工具就能给你；但当你想用无主持测试来检验 PMF 时，最好同时有屏幕录制和用户音频（主流工具都提供）。
    • 无主持相对有主持的一个真实优势：没有主持人影响结果的风险。现实中客户是自己一个人评估、注册和使用你的产品，这让无主持测试更接近用户的真实处境——大多数和主持人坐在一起的客户会比独自使用时更专注、更努力。
  • 怎么选：定义和验证 MVP 的早期用有主持，以确保能提问、拿到丰富反馈；当面最理想，除非目标用户难找、远程更可行。等你走得更远、对 MVP 更有信心时，无主持可以作为有主持的补充——省时省钱；资源不足做不了有主持时，无主持也是好选择。
• 如何招募目标市场里的客户：
  • 筛选问卷（screener）：一组像调研一样的问题，用来确保受访者在你的目标市场里——否则他们的反馈会把你的迭代带偏方向。为每个问题设计选项，并决定哪些答案合格、哪些淘汰。
  • 行为属性通常非常有用：目标是硬核游戏玩家，就先问"你玩电子游戏吗"淘汰答"否"的；再问答"是"的人"典型的一周你玩多少小时"，给出"少于 5 / 5–10 / 10–20 / 20–30 / 30 以上"，你可以决定每周 20 小时以上才算目标市场。
  • 心理属性也可用于筛选："你认为自己是硬核玩家吗""你有多享受玩电子游戏"（给量表）。
  • 筛选问卷本身也是假设、也要迭代：如果你在跑初期测试时发现第一版筛选问卷没招到对的人，下一轮就要改。
  • 一个很好的实例：假设你有个面向投资者的投资组合管理应用。第一版筛选问卷问交易频率和组合规模。第一批用户测试后你发现投资者其实分两类：喜欢自己做投资决策的，和更愿意把决策委托给专业顾问的。你的价值主张对第一类有共鸣，对第二类毫无吸引力。于是后续测试要在筛选问卷里加一道题，定向 DIY 投资者、过滤掉委托型的，并相应更新人物角色。
  • 招募渠道：改进现有产品可以直接找现有客户；否则要去找。① 在 Craigslist、TaskRabbit 等网站发帖招本地参与者，最佳实践是在帖子里附一个 SurveyMonkey / Google Forms 的在线问卷链接放筛选题；回应量因发布地点、措辞和激励金额差异很大。② 响应率低就改用远程测试，把范围从本地扩展到全网；有些公司用 Amazon Mechanical Turk 作为低成本招募源（还有若干基于 MTurk 的服务让这更容易）；很多远程测试服务自带用户面板——但要注意各家给你的筛选题控制权差异很大，有的只让你用预设属性（性别、年龄、就业状态），有的允许自定义问题。选服务时务必确认你对筛选题有所需的控制力——从非目标市场的客户那里拿反馈是浪费时间和金钱，还会把你带错方向。
  • 非消费者目标客户更难找（比如营销高管或医生）：一个有创意的办法是去他们聚集的会议、聚会等场合做游击式实地测试。
    • 配套案例：Olsen 的一位客户想做碳补偿购买相关的产品，原计划做一个网页应用——那会花很多时间和钱。Olsen 建议改做 Kickstarter MVP，因为这能在花钱写代码之前先验证价值主张，客户同意了。他盯上了一场本地的替代能源会议、带着 iPad 去，边和与会者聊天边判断谁属于目标市场，然后给他们看 Kickstarter 页面——在很短时间里拿到了大量有价值的反馈。
    • 但 Olsen 也点出局限：这类活动能拿到集中反馈，可惜相关活动多半不会在你附近频繁举办，支撑不了快速测试和迭代；带面板的远程测试服务在"频繁、短通知招人"上是更好的选择。
  • 客户研究公司：很多研究公司有本地参与者面板，常提供含测试场地和主持人的端到端服务，但你通常也可以只花钱请他们帮你招人。每人价格通常在 75–150 美元之间；如果目标客户稀缺且时间很贵（比如心脏外科医生或 CEO），可能贵得多，或干脆招不到。Olsen 的评价：研究公司是招募本地当面测试参与者的好办法，主要缺点是成本；但只要你的筛选问卷做得好、测试跑得好，通常能拿回超过你所付的价值。
  • 如何避开"排期陷阱"（本章最实用的一条运营建议）：Olsen 描述了一个他反复见到的恶性循环——产品团队大部分时间埋头做事（定义价值主张、写用户故事、画线框图）；等线框图准备好要测了，才抬起头手忙脚乱地赶紧招人，以免耽误时间。临时抱佛脚地招人非常难；而且那时大多数团队还没想过筛选问卷或测试脚本。如果团队没有资源帮忙招人，这活通常落到 PM 或设计师头上，而他们本就满负荷。结果是第一场用户测试要一两周甚至更久才排上；到那时团队多半已承受了往前推进的压力并屈服了，进入了高保真设计甚至已经在写代码；等他们消化完这一波用户反馈，已经来不及影响产品。于是完成一两轮开发后，这个令人沮丧的循环重演，导致很多团队降低用户测试频率甚至彻底停掉。
    • 解药——盲排期（blindly schedule）：固定按周期排人，比如每周二下午来三个用户，或每隔一周的周三来五个。用"盲"这个词，是因为排期时你多半还不知道具体要拿什么给他们测。 不要等产品或设计物就绪才去排人，团队只需笃定：到了那个固定时间就有用户在。这切断了"测试就绪"与"排期"之间的依赖，让你能以少得多的工作量实现高得多的测试频率。 Olsen 还建议找个资源专门帮忙招募和排期——初级员工或实习生是好人选，兼职合同工也行，他们主要只需要一份写得好的筛选问卷就能干这活。
  • 星巴克式用户测试（游击战术）：泡在咖啡馆里当场招人测。优点是成本低、即时；缺点是无法严格控制你谈话的客户类型。如果你有 Google、Facebook 那样的大众消费产品，在咖啡馆里找到目标市场里的人是可行的；但如果你的目标客户非常具体，这招多半不管用。你可以试着从外表做视觉筛选（性别、年龄、穿着等）。要有被拒的心理准备——很多人不喜欢被陌生人搭讪或者太忙。Olsen 个人发现商场比咖啡馆更好，因为那里的人似乎没那么忙、更开放。开场白对成功率至关重要——要迅速讲清你要他做什么、以及你拿什么换他的时间，例如："先生您好，您有 10 分钟时间对一个新网站给点反馈吗？我们会送您一张 25 美元的星巴克卡。"
  • 补偿客户：典型区间每小时 75–125 美元，但取决于目标客户和他们时间的价值——和心脏外科医生谈会贵得多，和高中生谈会便宜得多。很多机敏的创业公司能不花钱招到测试者——找到对该产品品类有足够兴趣的人；Olsen 用过"独家私有 beta 的准入资格"当胡萝卜，其他公司也这么干；如果公司有不错的周边（T 恤、连帽衫、运动外套）也管用。支付方式：礼品卡对双方都方便（通用卡如 Visa、MasterCard 比专用卡更有吸引力）；星巴克测试就用星巴克卡；现金可以但从公司账户取现麻烦；有些公司出于财务考虑更愿意开支票（本票是好选择，因为受访者不用担心跳票）。如果测的是现有客户，可以给服务额度或未来购买的抵扣来替代现金。
• Intuit 的用户测试（作者的师承）：Olsen 是在 Intuit 第一次接触用户测试的，这家公司是该领域的先驱。每个新版 Quicken 发布后，产品经理会做 "跟我回家（follow me home）"——守在卖 Quicken 的货架通道，看到有客户要买时，就问能不能跟他回家，然后在家里观察客户安装和使用产品。在真实环境中观察客户使用我们的产品，给了我们大量有价值的洞察。（他指出这与 UX 研究里的情境访谈、人种学研究是同类方法。）
  • Intuit 还建了一间最先进的可用性实验室，有多个测试房间。主持人是房间里唯一和客户在一起的人，但一面单向镜让其他人可以实时观看；实验室的摄像头同时捕捉电脑屏幕和客户的脸，把画面传到后面房间的显示器上。
• 泡面式用户测试（Ramen user testing，作者给创业公司的降级版）：离开 Intuit 后 Olsen 在很多创业公司工作，它们资源有限、必须更"抠"。这个技法去掉一切非本质的部分：不用专门场地，就用办公室的会议室；不请专职主持人，团队里的人（通常是 PM 或设计师）自己跑。
  • Olsen 的鼓励很实在：如果你从没跑过用户测试，建议试一次。 他发现很多一开始被"主持用户测试"吓到的人，只是需要一点鼓励——这不是造火箭，和生活里大多数事一样，练就会变好。 但因为同时主持和记笔记确实有挑战，他建议配一个专职记录员。
  • 设备：尽量让客户带自己的笔记本或设备来——这比让客户用不熟悉的设备好得多。他见过操作系统（Windows / Mac）、键盘、鼠标或浏览器的差异把用户搞懵、干扰测试。 观察客户在他们家里或工作中真实使用的设备上用你的产品是有好处的——你常会学到团队内部讨论和测试中没出现过的新东西。
  • 座位安排：让客户带着他的设备坐在桌前，主持人和记录员分坐两侧——这样你们和客户面朝同一方向、能看到屏幕，而且坐在旁边能注意到面部表情等细微线索。
  • 让团队来看（重要的组织收益）：多人同时观察同一份客户反馈时非常有力量。 在追求 PMF 的过程中问题空间和解决方案空间都有些模糊，这会导致团队成员抱有不同的假设和意见；一起看用户测试有助于团队达成共识理解。 但不要让房间里的人多到压垮客户——会议室里最多三个人（含客户）就够了；除主持人外所有人必须保持安静、不干扰测试。想看的人更多，就架一个摄像头传到另一个观看室；Olsen 也用过大房间里接投影仪的方案——把投影和观察者的椅子安排在客户视野之外、但近到能听见客户说话。
  • 一条反直觉但很有说服力的建议：有些团队成员会想录下当面测试、之后再看。Olsen 说他参与过大量测试，从没见过有人真的回去看录像。如果一个人没有动力来现场，他多半也没有动力看录像；而且很多客户不喜欢被录像。 如果你的团队真觉得有价值、真会去看，那就录（只要客户不反对）；否则跳过录像，专注于看现场。
• 怎么组织这场测试：
  • 先准备测试脚本：列出你打算给用户看什么、问什么，帮你提前规划以确保覆盖到位、流程合理、时间可控。脚本应明确你打算展示哪些设计物或产品的哪些部分、要请用户尝试完成哪些任务、要问哪些问题，以及顺序。
  • 可以先和团队成员做一次试跑，磨掉毛病、熟悉流程，如果你对主持紧张尤其应该这么做。把脚本（或简要提纲）打印出来放在手边随时参考也有帮助。
  • 时长与配比：测试通常一小时上下浮动 15 分钟，如果用户对产品很兴奋、反馈很多可能更长。Olsen 的分配：前 10–15 分钟暖场并做关于用户需求和现有方案的探索；约 40–45 分钟拿产品或设计物要反馈；最后 5–10 分钟收尾，回答用户的问题并问你自己的收尾问题。
  • 开场三件事：① 花一两分钟闲聊认识一下这个人——建立融洽关系、让他自在，通常会让他在测试中对你更诚实、给更多反馈。② 设定预期：大多数人都很友善、不愿说批评的话，尤其是当着你的面；他们知道你多半是设计或开发这个产品的团队成员，不想伤你的感情；为他们的时间付费还会造成正向偏差。为了对冲这些自然倾向，必须一开始就明确告诉用户你要的是诚实反馈、哪怕是负面的，让他们知道不会伤到任何人的感情；Olsen 喜欢补一句——他们的批评性反馈会让产品变得更好，这正是做这场测试的全部意义。③ 出声思考协议（think aloud protocol）：测试过程中用户必须把想法说出来你才听得到；有些人天然会这么做，有些人天生安静内敛。所以要明确鼓励用户在想法产生时就说出来（意识流）；如果给了指引后用户还是安静，可以再提醒一次。
  • 一条很诚实的期望管理：这些开场技巧提高你拿到有价值反馈的概率，但没有保证。无论如何总有些人不会说任何批评你产品的话，还有些人就是话不多。你可能会发现到场的用户里约 10% 是"哑弹"。但如果相当高比例的测试都拿不到好反馈，你就该重新审视你的筛选问卷、测试脚本或主持人了——这说明其中一项或多项需要改进。
• 怎么问出好问题（本章技术含量最高的一节）：
  • 探索性问题用于和客户一起探索问题空间与价值主张。从他们当前的行为和对你打算提供的关键收益的感受问起。 以 Uber 为例：先问他们多久坐一次出租车、用出租车做哪类出行、需要时怎么找到车；还可以请他们完整讲一遍最近一次坐出租车的端到端细节；再问他们喜欢什么、不喜欢什么、总体满意度如何。注意此时你还完全没提过 Uber——你只是在理解客户的需求、现有方案、对它的好恶和满意度，用来验证你关于目标客户和价值主张的假设。探索性问题同时还起到把用户暖场带入你的产品语境的作用。
  • 主持人败坏结果的头号方式是问引导性问题，例如"那个表单填起来很容易，对吧？"或者"那么，你觉得你会想点那个'购买'按钮吗？"Olsen 的评价很不客气：问这类反问句和引导性问题的主持人，在乎的是确认产品好，而不是拿到真实反馈。"做用户测试的目的不是让我们自我感觉良好，而是从真实客户那里拿到客观反馈。" 保证客观性是主持人的责任。他也承认这很难——测一个你辛苦做出来的产品还要把自己抽离、保持中立并不容易，但这正是你必须努力做到的。最好的主持人以尽可能少的干预让用户与产品互动，克制任何评论，主要是观察和提问。
  • 回声法（echoing back）：如果用户在原型上做了个动作却没说他做了什么或为什么，好的主持人会说："我看到你刚点了那个按钮，能告诉我为什么吗？" 注意这里主持人不是直接问"为什么"，而是先陈述他观察到的事实。 这是确保你理解用户、并进一步深挖的有力技巧。如果用户回答"我点那个按钮是因为我在找 ___"，主持人可以接着问"你为什么在找 ___？"——这与"五个为什么"技法相呼应。但 Olsen 提醒：连着问客户太多次"为什么"会让他们有防御心，所以要换着说法："能请你多说一点吗？""能帮我理解一下 ___ 吗？""你做 ___ 的时候脑子里在想什么？"
  • 柔道式回应：测试中用户常反过来问主持人问题，例如"那我应该点这里登录吗？"好的主持人不回答是或否，而是问"如果你点了那里，你期待会发生什么？"或者说"就按你自己一个人时会做的去做。" Olsen 把这叫做"用问题回答问题"的柔道招式。
  • 开放式 vs 封闭式问题：开放式给客户充分回答余地，通常以 why / how / what 开头；封闭式限制可能的回答（比如只能是/否），通常以 do / did / is / are / would 开头。例：问"你是根据价格来选订哪个航班的吗？"（封闭）不如问"你是怎么选订哪个航班的？"（开放）。
    • Olsen 的定性很准：开放还是封闭，与其说是主持人偏见问题，不如说是主持人技巧水平问题。日常对话里问封闭式问题完全没问题，但作为主持人你必须留意这一点。提前把打算问的问题写进测试脚本有帮助，但你也必须能临场（针对用户刚做或刚说的事）问出开放式问题。一个有用的技巧：养成在说出口之前先在脑子里过一遍下一个问题的习惯——这样如果它是封闭式的，你可以在抛给客户之前改成开放式。
  • 另一个要避免的错误：把偏好答案或可能答案嵌进问题里——这会把一个本来开放的问题变成封闭的。例："你希望应用怎么给你的交易排序？按日期吗？" 有时缺乏经验的主持人忍不住急着提供他认为可能的回答；即使这个提示并不是用户本来会告诉你的首选，他现在也可能因为你刚提了而说"是"。这有时是因为主持人不自在、想让用户"轻松点"。
    • 对沉默的态度：长时间的停顿会发生——用户需要时间处理你展示的东西并组织想法。这种沉默在正常对话里会尴尬，但在用户测试中完全没问题。 你应该避免提示答案，问完问题就闭嘴，保持开放性并给用户回答的余地。他们经常会用你不知道的东西给你惊喜。 Olsen 补了一句有趣的：猜猜客户会怎么回答是可以的（而且挺好玩），但把预测留在脑子里、别说出来。
  • 尽量少介入：你必须先把想要反馈的那部分产品或设计物展示给用户，但一旦展示完就应该退到背景里。用户可能看完第一页就问你"那我该干嘛？"——Olsen 喜欢这样回答："就当我不在这儿。就按'一个朋友让你去看看这个产品、而你此刻正独自在家用自己的电脑'那样去做。" 如果用户不说出想法，就征求反馈，例如"你对这一页的印象是什么？"
    • 他还给了一条流程上的偏好：他喜欢让用户自己自然发现并与产品各部分互动（同样不主持人干预）；但如果你想要反馈的某一部分用户一直没发现，你可以请他导航过去——之后再次退到背景里。
    • 该追问时追问：用户填完表单后评论"这个挺复杂的"，你应该跟进问"能请你说说为什么觉得复杂吗？"或者"再多讲讲。"
  • "我感受到你的痛苦"（本节最见纪律的一条）：如果用户在理解或使用你的产品时遇到困难，重要的是不要帮他——无论这有多难受。 你的目标是让测试尽可能真实：产品上线后你没法握着每一个客户的手，所以产品必须能自己立得住。 你应该表现得像墙上的一只苍蝇，在反馈环节不要出戏。用户抱怨或提问时，你不应该给他解释令人困惑的文案或界面、不应该告诉他该点什么、更不应该抓过他的鼠标替他操作（是的，Olsen 见过主持人这么干）。你可以告诉用户测试结束时会回答他的问题。
    • 一条重要的止损线：如果你的产品或设计物的质量或 UX 差到让用户无法自行有效地与之互动，那你应该停止做用户测试，先去解决这些问题。
    • 还有一条职业操守：虽然不常见，但 Olsen 见过主持人面对用户批评时变得有防御心、试图和用户的意见争辩，或者把测试不顺归咎于用户。这种行为既没有产出也不专业。 他的判词很硬："如果用户看不懂你的产品，那显然是你公司的错，不是用户的错。"
• 收尾环节怎么做：反馈部分结束后进入收尾。这是请用户回顾今天看到的一切、给出整体印象和反馈的好时机。
  • 可以请用户打分："0 到 10 分、10 分最好，你觉得这个产品有多有价值？""基于你今天看到的，你有多大可能会使用这个产品？""这个产品用起来有多容易？"可以口头问，也可以给客户一张简短表格填写（后者可能带来偏差更小的结果）。Olsen 把这叫做 "半定量（semi-quant）"——虽然你要的是数值评分，但数据受限于很小的样本量。随着你迭代和改进 MVP 候选，你应该看到评分一波比一波高。
  • 收尾也是回答测试中冒出来的问题、以及客户最后想问的问题的时候。如果用户因为已知 bug 或问题而遇到麻烦，你可以在这时解释。 这也是支付报酬并致谢的时候。
  • 一个非常聪明的收尾设计：Olsen 通常请用户签一张确认收款的表格，表格上常常留出让用户自愿填写邮箱和电话的位置；他还喜欢加两个是/否问题——"你是否愿意参与未来的研究？"和"你是否希望在这个产品上线时收到通知？" 这两个问题的用意是拿到一个更诚实的兴趣度量：如果一个用户测试全程只有正面反馈、给了高分，却没有在这两个问题上圈"是"，那他只是在说客气话。
  • 一次真实的意外之喜：他跑过一场测试，结尾没给用户任何表格。给完支票致谢后，很高比例的人主动问他产品什么时候上线，留下联系方式，请他上线时务必通知以便购买。 产品测试结果本来就不错，但这份额外的 PMF 证据是个可喜的惊喜。
• 如何捕捉和综合用户反馈：用户走完测试的过程中，你在寻找支持或反驳你那些通向 MVP 候选的假设的数据：目标客户、未被满足的需求、价值主张里的差异化点等等。
  • 反馈要分成三类归档：功能性（你的 MVP 是否覆盖了对的收益——用户可能抱怨缺了关键功能，或告诉你某个你做进去的功能对他不重要，这类反馈要绑回收益和你的价值主张）；UX（你可能功能集是对的、覆盖了对的收益，但糟糕的 UX 让用户无法充分利用它）；信息传达（messaging）（功能和 UX 都对，但你谈论功能、收益和差异点的方式没能引起客户共鸣）。Olsen 强调：把收到的批评性或正面反馈映射到这三个高层分类，测试后据此记录，能让你更清楚什么在起作用、什么没有。
  • 反馈汇总表的具体做法（可直接抄的表格结构）：每个用户一列，行按功能集 / UX 设计 / 信息传达分区，正面和负面反馈各占一行，某用户提了就标 "Y"——这样很容易一眼看出跨用户的模式；最右一列算总体结果（百分比、评分中位数）；表底放收尾问到的价值评分和易用性评分。Olsen 说明为求简洁，他不把提及率低于 40% 的反馈放进表里。
  • 书中那波 5 人测试的示例结果：正面——80% 认为功能 X 有价值且独特、40% 认为设计看起来专业、60% 喜欢首页的主视觉图；问题四条——80% 抱怨缺少功能 Y、60% 没看到"注册"链接、60% 注册流程遇到困难、40% 看不懂我们的标语；价值评分中位数 7、易用性中位数 5。
  • 迭代后该看到哪三种进步（本章最重要的方法论收尾）：① 更高比例的用户给出更多正面反馈，尤其是与价值主张相关的；② 不再听到早先各波里的负面反馈——Olsen 特意点破一个容易被忽略的事实：新一波的用户从没见过你产品的早期版本，所以没有任何新用户会告诉你"修得不错"。你只能通过"沉默"——那些先前听到的抱怨的缺席——来衡量这种进步。 ③ 关键评分上升（价值、易用性及其他关键指标）。
• 可用性 vs 产品市场契合（本章的压轴洞察）：做用户测试时必须区分"关于可用性的反馈"和"关于 PMF 的反馈"——前者关乎客户理解和使用你的产品有多容易，后者关乎他们觉得你的产品有多有价值。（这正是为什么示例表底部给这两个属性各留了一道评分题。）
  • 早期常见的情形：MVP 设计早期你会收到大量"UX 需要改进"的反馈；这种情况下糟糕的可用性常常挡住用户看到产品提供的全部价值；你还可能发现挡路的 bug；没有共鸣的信息传达同样会成为绊脚石。
  • 随着你消除这些不满因素，产品的价值才能更好地透出来，你才能更准确地读出 PMF。 但 Olsen 立刻给出关键警告：做完很多改进后，你可能到达"用户轻松通过测试、不再遇到任何可用性问题"的状态——但你不能据此推断你有了 PMF。你必须显式地评估 PMF，方法是问他们有多看重你的产品。
  • 最好的亲身案例：他做过一个根据用户兴趣提供实时新闻的产品。第一波在粗糙的真实产品 MVP 上测试，用户反馈了大量可用性问题，还发现了几个 bug 和一些不清晰的信息传达。修完后第二波问题数量减少，继续修。第三波用户测试开始变得非常顺利，大多数用户一路无障碍通过，这让他对进展感到兴奋。
    • 然后他开始在每场测试结尾问用户"你有多大可能会使用我们的产品"。即使测试进行得很顺利，仍然约有 20% 的用户说他们不会用。这个结果让他吃惊——因为测试很顺、也没收到多少负面反馈；而且大多数受测客户对个性化新闻产品都表达了一定兴趣，所以他觉得他们足够符合目标客户画像。
    • 他接着去问那 20% 为什么不会用，学到：有一部分用户对"以某种特定方式获取新闻"有强烈偏好。 这是一个很棒的、意料之外的洞察，促使他在访谈开头的探索性问题里加上"你更喜欢怎样获取新闻"。他发现人们偏好的获取新闻的方式有三种非常不同的类型，而他们的产品思路是最贴合其中一种的。 学到这一点帮助他们更好地理解了这个市场——在线新闻是有庞大受众的大众消费产品，所以市场里存在偏好不同的细分人群是很自然的。团队一致认为，试图同时照顾三种方式的设计会精神分裂、三类用户都讨好不了。于是他们用学到的东西refine 了目标客户定义。
  • 这个案例证明了三件事：可用性问题会妨碍你评估 PMF；优秀的可用性并不意味着你有强 PMF；用户测试能帮你验证并精炼假设（这次被精炼的是"目标客户是谁"）。
• 本章最后的警告：用户测试的有效性内在地建立在"你在和对的那类客户对话"这个前提上。你可以把价值主张和 MVP 功能集定义得很好、设计出一套惊艳的可点击线框图、把测试跑得完美无缺——但如果你在和错误类型的客户对话，你就拿不到需要的数据。 事实上你可能拿到很糟糕的数据，与你的目标客户本会告诉你的截然不同；基于错误客户类型的数据去迭代 MVP，会把你送上错误方向——不是驶向 PMF 的应许之地，而是冲下悬崖。
  • 因此：如果在解决完主要可用性问题之后测试仍显示你没有 PMF，你可能需要重新审视关于价值主张、MVP 或 UX 设计的假设；但也可能你需要重新审视关于目标客户的假设——请对这个可能性保持开放。

第 10 章 · 迭代与转向以改进产品市场契合

• 对 Eric Ries "构建-衡量-学习"环的三处修正（本章最有原创性的部分）：Olsen 说这个环帮很多人理解了迭代与验证式学习的重要性，但根据他观察到的人们谈论和应用它的方式，有些细微之处值得讨论：
  • ① "构建"不意味着你必须真的造出产品。 做一套可点击线框图拿去测用户完全可以接受。"构建"只是指有个东西能拿去测客户，可以是真实产品也可以是线框图、视觉稿这类设计物。"设计一个可供测试的东西"是更宽、更准确的描述，所以他更愿意把这一步叫"设计"。 目标是找出并创造那个能以最少资源消耗来检验你假设的东西。
  • ② "衡量"暗示数值数据——但它不必像听上去那么定量。 很多人偏好用定量数据证明事情；Olsen 同意能做到时很好，但 A/B 测试不是检验假设或获得学习的唯一方式。所有你通过观察客户获得的信息都属于"衡量"——即使不具统计显著性，定性测试的结果也算"衡量"。关键在于你在拿客户检验你的假设。因此"测试"是更宽、更准确的标签。
  • ③ "学习"这一步其实同时在发生两件事：一是从每次测试结果中学到新东西，二是用学到的去修改那些导致你跑这次测试的假设。把"学习"拆成"学习"和"提出假设"两个独立步骤会更清楚。 而且 Olsen 点破了一个逻辑漏洞：仔细想想，这个流程根本不是从"构建"开始的——它从某些初始假设开始的。否则你凭什么决定要构建什么？
• 假设-设计-测试-学习环（Hypothesize-Design-Test-Learn）：
  • 从"提出假设"开始，形成你的问题空间假设；"设计"步骤里你找出检验这些假设的最佳方式，基于假设创建设计物或产品，这一步把你从问题空间带到解决方案空间；"测试"步骤把产品或设计物暴露给客户并做出观察，由此得到验证式学习（"学习"步骤）；用这份验证式学习去修订和改进你的假设，从而闭环，修订后的假设指导你下一次绕环。
  • 一句概括：你通过在解决方案空间给客户看产品或设计物并征求反馈，来检验和改进你在问题空间的思考。
  • 一个漂亮的比喻：如果把这个环想成大富翁的棋盘，"学习"就是你每绕一圈都会经过的"起点（Go）"格。游戏里过"起点"能领 200 元；在精益产品流程里，你赚到的是验证式学习。
  • 一条关于速度的现实判断："学习"和"提出假设"这两步通常都相当快，所以你绕环的速度一般取决于你设计和测试的速度有多快。
• 把学到的映射回金字塔（本章最实用的诊断纪律）：验证或推翻假设、形成新假设时，你应该识别每条假设对应金字塔的哪一层。每一层都建立在下面那层假设之上。越靠近金字塔顶部越容易改，改靠近底部的假设则会对更高层产生重大连锁反应。
  • 具体例子：改一个页面的 UX 设计让它更好用，是相对小的事。但假如你的价值主张原本假定某项客户收益不重要，而你从用户那里学到它其实很重要——你现在必须修改价值主张，这会连带影响你的 MVP 功能集和你的 UX 设计。
  • 由此得出的操作顺序：这就是为什么在处理用户测试所学时，你要先聚焦解决最低层级的问题；验证这些问题消除之后，再聚焦下一个更高层级的问题。
• 迭代式用户测试的操作：每场测试后尽快与产品团队复盘，分享观察、综合学习。用第 9 章那种表格捕捉每一波的关键观察。每波结束时看所有用户里有多少人给出了相同反馈（正面或负面），用百分比表示。这些百分比帮你给"要对 MVP 做的改动"排序——全部或大多数用户提到的问题优先级更高；只有一两个用户提到的可以低一些。 你应当明确下一轮测试前打算解决哪些项。
• 四波迭代的完整推演（本章的教学核心，直接给出了"进步长什么样"的具体形态）：
  • 第 1 波（承接第 9 章）四个问题：80% 抱怨缺功能 Y、60% 没看到"注册"链接、60% 注册流程有困难、40% 看不懂标语。逐条归层并派给对的角色：
    • 缺功能 Y = MVP 功能集问题。内情是：他们其实考虑过功能 Y，也认为它有价值、计划以后再做，只是判断它对 MVP 不是关键。 现在从客户那里学到他们需要它，于是决定把它加进 MVP，设计师出设计、更新设计物。
    • 看不到"注册"链接 = 视觉设计问题。视觉设计师把链接放到更显眼的位置、加大、并做成一个用跳脱颜色渲染的按钮。
    • 注册流程有困难 = 交互设计问题。交互设计师针对用户遇到的问题重做注册流程。
    • 看不懂标语 = 信息传达问题。具体措辞没有传达出他们想表达的意思，导致标语没能有效传达他们视为差异化的客户收益。 团队头脑风暴备选标语、选出新的最爱、更新设计物。
  • 第 2 波（5 个新用户）：功能 Y 加了之后没有新用户抱怨它缺失（0%），这是进步；"注册"链接所有 5 个用户都看到了（0%），是大改善。
    • 但 40% 的用户仍抱怨注册流程难，尽管已经重做过。Olsen 说得很实在："这种事会发生。你第一次根据客户反馈修改产品，不一定一次就改对。" 第 2 波中用户不再遇到第 1 波的某些具体 UX 问题，但他们对其中一个先前 UX 问题的修法效果不如预期，而且新设计元素也带来了一些小问题。团队决定开一次跨职能会议分享仍在发生的问题、头脑风暴解法、挑最好的，做出新版流程并合入新版设计物。
    • 新标语没有第 1 波的问题（0%），令人振奋。Olsen 给出了判定准则："看到一个问题从上一波的高百分比变成下一波的零，通常意味着你已经充分解决了它，可以转去关注别的问题了。"
    • 但消除旧问题后会冒出新问题：第 2 波客户很高兴 MVP 有了功能 Y，但其中 80% 觉得这个功能很难用。团队讨论看到的具体可用性问题，做出改进设计。
    • 还有一个意外：80% 的客户表示希望功能 Y 能和功能 X 协同工作——而团队当初是把功能 Y 作为一个全新的独立功能加进去的。Olsen 的评语很坦白："事后看，我们从用户那里学到的'这两个功能该如何协同'很有道理，而且让两个功能都更有用了。" 团队修改两个功能的设计。
    • 该看到的整体形态：随着迭代，问题的量级和数量都该下降。 这一波：成功解决三个（功能 Y、注册链接、标语），尝试但未解决一个（注册流程），新发现两个（功能 Y 难用、功能 Y 该与 X 协同）。评分也该改善：价值评分从 7 升到 8（多半是因为加了功能 Y），易用性从 5 升到 6（多半来自改进的"注册"链接和对注册流程的部分改善）。
  • 第 3 波：功能 X 与 Y 不协同的抱怨归零，任务达成；第二次重做注册流程后，5 个用户全部顺利通过、没人抱怨困难，进步显著；虽然重做了功能 Y，仍有 40% 觉得难用——比 80% 降下来了，是好事，但因为它是个如此重要的功能，还有活要干。价值评分升到 9，易用性升到 7。
    • Olsen 在这里做了一个诚实的说明：他为保持示例简单只用了少量主要反馈项，真实测试中你还会收到大量次要反馈项，也应该纳入改进。
  • 第 4 波：进一步改进功能 Y 的设计后再测一波——没有人抱怨功能 Y 难用，也没发现新的重大问题。价值评分保持 9，易用性升到 9。
• 什么时候算"验证够了"：此时应该对 MVP 设计感觉足够好，可以进入下一步。
  • 分情况的路径：如果测的是高保真设计物（如 InVision 上的可点击视觉稿），就去构建 MVP；如果测的是低保真（如可点击线框图），可以推进到可点击视觉稿。某些情况下也可以跳过高保真设计直接写代码——如果你对设计非常有信心、认为跳过视觉设计后的用户测试风险不大。Olsen 给了具体的适用条件：给现有产品添加新功能、并且已经有一套现成的视觉样式指南可直接套用时。
  • Olsen 明确承认没有硬性规则："没有一条铁律能判定你何时算把 MVP 验证得'够了'。" 两端都有风险：继续测到超过有价值的那个点是有风险的，你要避免分析瘫痪；反过来，在验证足够之前就上线，可能导致设计和编码两条战线上痛苦的返工。所以要努力取得平衡。
  • 一个温柔但坚定的比喻："到某个时点，你的雏鸟需要离巢。" 也就是你需要停止测试设计物、开始构建 MVP。这是个令人兴奋的过渡——它让你离"用真实产品交付真实客户价值"更近一步，同时也开启了下一个层次的产品测试。
  • 为什么真实产品的测试更好：测设计物时，客户告诉你的是"如果产品是真的、他们会做什么"；而客户说他们会做什么和他们实际做什么可能相当不同——真实的客户行为任何时候都胜过客户的意见。 此外你的真实产品是最高保真，低保真设计物可能缺少最终产品里的一些细节，或者在构建过程中引入了对设计物的偏离。
  • 上线后的做法：产品造好后最好再做一波测试看看你处在什么位置。理想情况下你测到的 PMF 水平与上一波设计物测试相同或更高；如果不是，就带着真实产品继续绕假设-设计-测试-学习环，直到达到为止。 很多公司为此使用私有 beta，让产品在准备好面世之前只对有限数量的客户可见。
• 坚持还是转向（Persevere or Pivot）：
  • Olsen 先自我拆台："我描绘了一幅相当美好的图景。是的，需要几波迭代和辛苦工作，但你最终总会到达 PMF，对吧？很不幸，很多团队并没有这样的经历。" 他们测用户时得不到闪亮的反馈，试图迭代但在客户那里毫无进展，感觉像撞上了一堵砖墙。
  • 可能出错的地方有两类：你的一条或多条假设可能是错的；或者即使假设是对的，你在设计、构建或营销产品上的执行可能不到位。
  • 诊断流程：如果发现迭代没有进展，建议暂停、退后一步。和团队头脑风暴所有可能的问题，把每个问题映射回 PMF 金字塔对应的层。 你可能会发现你一直在比真正问题所在更高的层级上迭代。 例：如果你关于目标客户的假设是错的，迭代 UX 设计不会有什么用。 你要从金字塔底部开始向上排查，直到找出哪些假设是错的。
  • 转向的定义（一条重要的术语纪律）：当你改变一条主假设时，那就叫转向（pivot）。 它的量级大于你沿既定路径迭代时的常规改动，意味着方向的重大改变。换成一个完全不同的目标客户是转向；决定改变价值主张里的差异化点是转向；对 UX 设计做微调不是转向。
  • 两个成功转向的案例：
    • Flickr：起初是 "Game Neverending"——一个聚焦社交互动的网页版大型多人在线角色扮演游戏。公司加了一个让网页上分享照片变得容易的工具后，看到客户有多爱用它。于是转向，2004 年 2 月推出照片应用 Flickr，取得惊人增长，2005 年 3 月被雅虎收购。
    • Instagram：起初是 "Burbn"——一个 HTML5 社交应用，糅合了签到应用 Foursquare 和游戏 Mafia Wars 的元素。把 Burbn 重新实现为原生 iPhone 应用后，联合创始人觉得它被太多功能塞得杂乱。他们决定从零做一个新应用，砍掉除照片、评论和点赞之外的一切。 2010 年 10 月推出 Instagram，增长惊人，2012 年 4 月被 Facebook 以约 10 亿美元收购。
  • "停止"这个选项要先谈：你并没有无限的时间去达成 PMF——资源约束通常限制了你有多少时间。 创业公司在盈利之前依赖外部投资；如果你没达成 PMF、或没有朝那个目标取得显著进展，要拿下一轮投资会很有挑战。即使是成功公司内部的新产品项目，也有固定预算以及对取得进展的时间预期。
  • 两个极端都要避免（Olsen 的分寸感）：他见过一些创业公司好像永远在转向。你不该每次遇到点挫折就改变方向，也不该一有新鲜点子就丢下手头的事去追——这叫"闪亮物体综合征"。 他开了个很妙的玩笑："如果你已经转向三次，那你正朝着和出发时相反的方向前进。" 另一个极端是那些固执地一直拿脑袋撞墙、从不退后一步重新评估的人。
  • 判断准则（可操作的）：如果你银行里还有钱、时钟上还有时间，当你在几轮迭代之后仍然看不到 PMF 的增益时，就该考虑转向。如果尽了最大努力，目标客户对你的 MVP 仍然不冷不热，你应该考虑转向。 换个说法：如果你还没有识别出一个对你的 MVP 非常兴奋的客户原型，那你就该考虑转向。
  • 有时最好的转向方向会从测试里自己浮现：例如你可能发现价值主张中一个不那么核心的部分才是最能引起客户共鸣的——这时你应该砍掉其余部分、把力气聚焦到那一块。或者你可能发现目标市场由不同的子市场构成，而其中某个子市场真的很爱你价值主张的某个方面。
  • 爬山比喻（本章的收尾意象）：你从第一座山脚出发，这座山代表你基于目标市场和价值主张假设所追逐的市场机会。爬得越高，PMF 越强。 第一波测试后你学到很多、改进了产品；第二波看到 PMF 提升了；但再下一波增益小得多。产品比出发时好，但你没能到达足够高的 PMF 水平。接下来两波你试了不同的东西，却似乎无法取得任何进展。
    • 在用户测试的过程中，你发现了一个相邻的市场机会，就是第二座山。这第二座山比第一座更高，因为它可能创造的市场价值更大。 你决定修订假设、转向去追这个新机会；绕假设-设计-测试-学习环迭代，发现你能够改进 PMF，并到达高得多的高度。
    • 这个比喻提醒你要关注的三件事：迭代时留意你爬到了山的多高处（你的 PMF 水平）；每波用户测试后设法度量你的爬升速率（PMF 的改进幅度）。如果感觉进展不大，试着找上山的其他路径（重访并修订你的假设）。如果这么做之后仍然没有像样的进展，就停下来重新考虑你所在的这座山（你关于目标客户和价值主张的假设），并环顾四周看看有没有别的、可能更好爬的山。选一座新山（转向），然后试着爬上去（迭代以获得更高的 PMF）。

第 11 章 · 一个端到端的精益产品案例：MarketingReport.com

这是全书最有价值的一章——它不是教学示例，而是一个真实咨询项目的完整复盘，包含了"第一波测试全线失败"这种教科书通常会略去的部分。

• 背景：Olsen 的一位客户（一家有成功消费者网络服务的公司）请他帮忙定义和评估一个叫 MarketingReport.com 的新产品。他与两位公司高管和一位 UX 设计师紧密合作。
• 产品创意的来源：直邮广告有一个普遍的客户问题——很多收到直邮的人不觉得它有价值，反而视为麻烦。两位高管了解直邮行业，知道这些邮寄是基于给客户画像的营销数据库来做定向的：比如你会收到某连锁宠物店寄来的猫砂优惠券，是因为某处的营销数据库显示你（很可能）家里有猫。
  • 产品的构想：给客户看到营销方提供的关于他们的画像的透明度，并赋权让他们把画像修正得更准确。这样如果我没有猫而有狗，我就可以修正营销数据库，从而收到狗粮的优惠券而不是猫砂的。
  • 类比的来源（这个类比很重要，它是整个概念的支柱）：高管们看到了与征信行业的相似之处。每天有成千上万个信贷相关决策基于人们的信用分做出。在征信服务出现之前，消费者对自己为什么是这个分数没什么可见度——他们的信用状况基于"幕后"的信用历史数据。他们可能被拒贷却不知道确切原因；而关于过往还款的不准确数据（比如一笔其实已还的贷款被报为未还）可能对他们造成负面影响。 征信服务通过提供透明度，让客户看到信用评级背后的数据并纠正任何不准确之处。MarketingReport.com 要为个人营销数据做征信报告为个人信用数据做过的事。
  • 商业模式的初始设想：服务免费，通过将服务产生的营销数据变现来赚钱。通过让客户访问数据、纠正错误并补充额外信息，他们计划建立一批丰富而准确的画像。因此，定义一个客户愿意参与其中的服务就至关重要。
• 步骤 1：确定目标客户——在这个早期阶段各方一致同意这将是一个面向大众消费者的产品。Olsen 在这里说明了一个方法论上的细节：步骤 1（目标客户）和步骤 2（客户需求）密切相关，所以此时他们没有把目标市场假设进一步收窄。他们知道随着对"能交付什么客户收益"更清楚，会再来精炼目标客户假设。（这一点很重要：它示范了六步流程不是刻板的瀑布，前两步可以先粗后细。）
• 步骤 2：找出未被满足的需求——两位高管都同意服务的核心收益是赋权让客户搞清楚"他们"（那些直邮营销数据库）到底知道你什么。但除了这个核心收益之外，关于这个服务还应该做什么，有很多不同的想法。 于是他们头脑风暴了一长串潜在客户收益，其中包括这五条：
  1. 发现我感兴趣的省钱优惠 2. 减少我收到的无关垃圾邮件 3. 洞察我的消费行为 4. 认识并与购物偏好相似的人互动 5. 通过授权出售我的营销相关数据来赚钱
  • 筛选机制（一个很值得抄的评估矩阵）：为决定追哪些收益，他们定了一组评估标准，有正向的也有负向的：用户需求强度（+）、可获得的营销数据的价值（+）、竞争程度（−）、构建 v1 产品的工作量（−）、把这个概念规模化的工作量（−）、与公司品牌的契合度（+）、需要依赖合作伙伴的程度（−）。
  • 结果：按估计给每条收益在这些标准上打分，淘汰掉吸引力较弱的想法。上面列表里的收益 1 到 4 被认为值得进一步考虑（即第 5 条"出售数据赚钱"被淘汰）。
• 步骤 3：定义价值主张——Olsen 想确定哪些收益在范围内、哪些在范围外，以固化价值主张，于是带着两位高管做了一次问题空间的映射练习。
  • 映射结果——三个集群：中间是核心收益"搞清楚'他们'知道我什么"；顶部集群包括减少垃圾邮件和拯救树木（环保）；底部集群包括购物省钱、洞察我的消费、与相似购物者互动。
  • Olsen 的判断（本节的关键决策）：他觉得这三个集群放进单一产品里太多了；而且如果试图做一个服务覆盖所有这些收益，会显得不连贯——顶部集群和底部集群非常不同。另外，一位高管更喜欢顶部集群，另一位更喜欢底部集群。 他认为这些都是好想法，于是建议做两个不同的产品概念，各有自己的价值主张：
    • 概念一"Marketing Shield"（营销盾） = 顶部两个集群
    • 概念二"Marketing Saver"（营销省钱） = 底部两个集群
    • 这样每个概念都包含核心收益"搞清楚他们知道我什么"，但范围都不至于过宽。两位高管同意了。
  • 用 Kano 分类（把第 5 章的方法真正用上）：他们把"搞清楚'他们'知道你什么"视为惊喜型，因为这类服务当时并不存在；他们知道市场上有其他产品提供省钱优惠，所以把它视为性能型；社交网络产品虽然存在但不一定聚焦购物，所以也视为性能型；他们不知道有其他产品让你在财务上与他人比较，所以视为惊喜型；在 Shield 一侧，把减少垃圾邮件视为惊喜型；而环保有很多别的方式，所以"拯救树木"视为性能型。
• 步骤 4：确定 MVP 功能集——有了两个概念的价值主张后，他们开始谈解决方案空间，头脑风暴能交付这些收益的功能。
  • 核心功能——营销报告（Marketing Report）：一份随时间积累的、关于用户的营销相关信息集合。报告源自关于客户购买行为，以及他们对调查、邮寄和电话的回应的数据。目的是给客户提供对营销数据库中关于他们的数据的透明度。
  • 报告的两个关键组件：
    • 营销画像（Marketing Profile）：基于直邮公司使用的一套消费者细分聚类。每个聚类都有一个朗朗上口的描述性名字——如"年轻的数码达人（young digerati）""足球与 SUV（soccer and SUVs）""乡村退休者（rural retirees）"——基于年龄、婚姻状况、房产拥有、子女、邮编等关键人口数据。营销方用这些画像来投放相关优惠。
    • 营销分（Marketing Score）：他们从零发明的概念，意在类比信用分——一个代表你整体信用状况的单一数字。同理，营销分是一个代表你对营销方整体吸引力的单一数字。信用分越高，你拿到的利率越好；营销分越高，你会拿到更多更好的省钱优惠。 他们识别了若干决定营销分的因素。
  • 底部集群（Saver）的功能：主要收益是省钱优惠——客户指明自己对哪类产品和服务感兴趣，然后收到相关的省钱优惠。"我们基本上是在消费者和想推广产品的公司之间做媒人。" 功能包括一个供客户指定偏好的界面、一个供应商市场、匹配逻辑，以及通过网站和邮件投递优惠。第二个功能是与他人比较——客户可以把自己在餐饮、服装、娱乐等方面的消费模式与相似客户比较，看自己花得多还是少，从而按自己的意愿调整消费行为。第三个功能是与相似购物者互动——客户可能从相似购物者那里发现新产品或了解到好优惠；当时社交网络相对火热，他们想在与网购相关的社交功能上做点实验。
  • 顶部集群（Shield）的功能：一个屏蔽垃圾邮件的服务，同时满足"抑制垃圾邮件"和"拯救树木"两条收益。做法是先用"绿野仙踪"MVP——由人工代客户填写并提交"请勿邮寄"申请，如果情况需要，之后再过渡到更自动化的方案。（注意这里第 7 章的手工黑客 MVP 被真正用上了。）
• 步骤 5：做出 MVP 原型——他们知道要在写任何代码之前当面用设计物测客户，于是选择了中等保真度的视觉稿：有足够的视觉设计（配色、字体、图形、样式）来有效地把产品呈现给用户，但不追求像素级完美。
  • 先定 IA 和交互设计：客户会先收到一封描述该服务的邮件，邮件的行动号召是"看你的营销报告"，带一个指向落地页的链接；落地页进一步描述服务，并有一个标着"查看报告"的关键转化按钮。每位客户被分配了一个唯一码包含在邮件里。
  • 点击"查看报告"后进入"核对信息"页：这一页是一个表单，列出他们的姓名、地址、婚姻状况、家庭收入区间和其他关键人口信息。这一页把营销数据库中包含的信息展示给客户，并允许他们纠正任何不准确的信息。 点击"继续"后进入营销报告页。
  • 营销报告页是走完引导流程之后的主页面：它是一个模块化的仪表盘，这个设计让他们可以通过替换不同模块，为两个产品概念复用同一套总体设计。两个概念都包含营销画像和营销分模块（因为这是核心功能创意）；其余模块按概念不同——Shield 版有"屏蔽垃圾邮件"模块；Saver 版有省钱优惠、与他人比较、社交网络三个模块。
  • 营销报告页是客户导航的枢纽，可以点每个模块下钻到对应的专门页面。例如省钱优惠专页让客户选择自己感兴趣的产品和服务类型（度假、电子产品等）；"屏蔽垃圾邮件"专页展示不同类别的直邮，允许用户选择不再想收到哪些；该页还包含一个升级付费服务 "Marketing Shield Premium" 的推荐——这个付费服务会进一步减少你收到的垃圾邮件量、并为你的营销画像数据提供更强的隐私保护。除了这个升级项之外，Saver 和 Shield 服务都打算对客户免费。
• 步骤 6：用客户测试 MVP——视觉稿做完后开始测试。此时他们需要在开始招募前重访并精炼目标客户定义（这正是步骤 1 留的尾巴）。因为有两个不同的 MVP、各有自己的价值主张，所以要为每个定义目标客户：Shield 的目标客户仍是大众消费者，但精炼为"高度重视自己隐私的人"；Saver 的目标客户也仍是大众消费者，但精炼为"非常看重购物省钱和拿到好交易的人"。
  • 招募（这一段的筛选问卷设计是全书最好的实操样本）：他们决定用当面有主持的测试，Olsen 亲自主持。为了更快收集数据，他一次和两三个客户谈而不是一对一。他选了一家本地研究公司帮忙招募，用他创建的筛选问卷来甄别客户。
    • 通用筛选条件及其理由：要求全职就业（每周至少 30 小时）——理由是"很多失业或退休的人参与市场研究是因为他们有充裕的空闲时间，但他们不一定能代表我们的目标市场"；要求至少高中文凭，并招募教育水平的平衡组合，与大众受众一致；招募家庭收入的混合组合，最低 4 万美元；家里必须有电脑并且每周上网达到最低小时数（因为服务通过网络交付）；必须最近在网上买过东西（这样他们会习惯为服务在线付费）。Olsen 把所有这些要求视为"确保此人是网络服务目标市场里的大众上班族"。
    • 概念专属筛选（用过往行为作为契合指标，非常聪明）：
      • Saver 组（省钱）四问：过去三个月用过三张或以上优惠券吗？你是 Costco 会员吗？过去六个月在 eBay 上买过东西吗？购物时你通常或总是会花时间研究以确保找到最低价吗？每答一个"是"得一个 Saver 分，两分及以上算进入 Saver 目标市场。
      • Shield 组（隐私安全）四问：你曾要求把自己加入"请勿来电"名单吗？你有来电显示屏蔽吗？你家里有碎纸机吗？过去六个月你为杀毒软件付过费吗？每答一个"是"得一个 Shield 分，两分及以上算进入 Shield 目标市场。
      • 两组都不合格的受访者不选；少数人两组都合格，因为标准并不互斥（既在意省钱又在意隐私是可能的）。
    • 一个极其巧妙的操作——个性化视觉稿：受访者合格后，他们还要了地址、年龄、婚姻状况、子女数、房产拥有、家庭收入、教育水平、职业和族裔。他们用这些信息为每位客户定制了一份"核对信息"页的视觉稿，并把每位客户的营销画像匹配到对应的细分聚类。
      • 效果：这种对视觉稿的个性化让他们在测试中为客户营造出比"用通用页面并请客户自行想象"真实得多的体验。事实上，大多数客户第一次看到这一页时都表现出惊讶：他们会问"你们是怎么拿到所有这些信息的？" ——他们成功地在客户身上激发出了"'他们'（营销数据库）真的知道你很多事"的领悟，而这正是 MarketingReport.com 的核心价值主张。
    • 排期上的一条重要教训：因为谈的是全职工作的人，他们把研究时段安排在下班后（晚 6 点和 8 点）。Olsen 明确点出一个常见错误：公司为了自己方便而把研究时段强行安排在自己的工作时间内。 如果目标客户在那个时间没问题当然行，但对大多数上班族来说工作日白天不方便，结果会让来参加研究的客户类型发生偏斜，偏到不再真正代表你的目标客户。
      • 提效技巧：筛选时就问受访者所有他们能来的时段，拿到所有人的信息后，后续排满所有时间槽就很容易了。研究公司成功招满了所有时段。
  • 用户测试脚本（90 分钟，可直接抄的时间分配）：
    • 介绍与暖场（5 分钟）
    • 通用探索性问题（15 分钟）：直邮广告 / 公司掌握的关于你的数据 / 在财务上与他人比较
    • 概念专属问题（共 45 分钟）：与该概念主题相关的探索性问题（10 分钟）+ 对概念视觉稿的反馈（35 分钟）
    • 回顾：你最喜欢/最不喜欢今天看到的什么？（5 分钟）
    • 头脑风暴：什么能让这个产品更有用/更有价值？（10 分钟）
    • 对可能的产品名称的反馈（10 分钟）
    • 致谢与告别
    • 他先和公司里的一个人跑了一次试点测试来检验脚本和视觉稿，据此对问题和视觉稿做了一些调整，然后才正式开始。
  • 执行细节：连续三个晚上，每晚主持两场，每场排三位客户。一半场次给 Marketing Saver、一半给 Marketing Shield，所以每个概念各排了九位客户。最后有两人放鸽子，因此每个概念实际谈了八位客户。 因为视觉稿数据是为每位客户个性化的，又因为那时还没有可点击视觉稿的时代，他把每张视觉稿打印出来（一页一张），按客户会看到的顺序摞在每位客户面前，跟着脚本、随着客户在视觉稿间导航而翻页。
• 从客户那里学到了什么（这一节是本章的价值所在）：
  • 表面上很顺利：客户投入、表达清晰，反馈非常多——多到 Olsen 打了八页笔记来记录。
  • 但结论是残酷的："底线是，两个概念对客户的吸引力都不够。不过，确实有几缕阳光穿透了云层。"
  • 具体的失败诊断：
    • 两个概念共有的核心价值主张"搞清楚'他们'知道我什么"只有有限的吸引力。 客户觉得营销报告和营销画像有点意思，但不足以打动人。大多数人觉得营销分令人困惑，吸引力低。（注意：营销分正是他们从零发明、寄予厚望的那个惊喜型功能。）
    • Saver 概念里"与他人比较"和"社交网络"两个功能吸引力低。
    • 但客户确实喜欢省钱优惠（这是第一缕阳光）——这是 Saver 概念里最有吸引力的部分。
    • Shield 概念里"减少垃圾邮件"的想法吸引力强，"拯救树木"作为次要收益也有吸引力（第二缕阳光）。
    • Olsen 在这里做了一处非常诚实的限定："我要澄清一下，'吸引力强'距离十拿九稳还很远。客户对我们给他们看的东西有很多问题和顾虑。但我有信心可以用学到的东西避开那些顾虑、让下一版更强。我能感觉到那些收益上存在足够的潜在兴趣。"
  • 一个极其好用的可视化收口手法：研究之后，Olsen 拿出他们那张问题空间与解决方案空间的地图，把每个方框涂成绿色、黄色或红色，分别代表吸引力强、一般、低。看着结果，他看到了两座分开的绿色孤岛：Saver 目标客户喜欢省钱优惠，Shield 目标客户喜欢屏蔽垃圾邮件。前进的两个选项很清楚了——他们只需要选择往哪个方向转向。
• 转向的决策过程（Olsen 给出了完整的权衡账，这非常有教学价值）：虽然两个概念都有很强的潜在吸引力，但 Shield 的吸引力更强。理由逐条列出：
  • 对 Saver 不利的四条：① 已经有很多网站为 Saver 们提供省钱优惠（如 coupons.com），客户不清楚我们的产品差异化在哪；② 客户更不愿意为这个服务付费，并表示他们只愿意付一个低于它为他们省下的金额的价格；③ 要和那些提供优惠的公司签约需要大量工作；④ 这个服务与公司品牌的契合度不好。
  • 对 Shield 有利的三条：① 客户似乎更愿意为一个能减少他们垃圾邮件的服务付费——他们已经通过 "Marketing Shield Premium" 升级选项引入了付费概念；② 有些客户告诉他们，如果在初始免费试用期内服务真的如预期般有效，他们之后愿意付费（当被问到愿意为这样的服务付多少时，一些人表示金额不大，"但我们没有得到强烈的反馈"——Olsen 对这一点保持了诚实的保留）；③ 这个服务与公司品牌的契合度更好。
  • 转向的内容：基于学到的东西，他们决定放弃先前的核心价值主张"搞清楚'他们'知道我什么"，转向一个只处理屏蔽垃圾邮件的服务，暂定名 JunkmailFreeze。
    • 注意这个转向的量级：他们放弃的是整个产品最初的核心概念——那个征信类比、那个营销报告、那个从零发明的营销分。这正是第 10 章定义的"改变一条主假设"。
  • 接下来怎么走的三个选项（以及他们的选择）：① 做一套新视觉稿、测客户、然后造产品；② 用 HTML 和 CSS 写一个更高保真的原型来测客户、然后造产品；③ 直接设计并构建产品，不再事先测客户。
    • 他们选了第一个。理由：JunkmailFreeze 相对核心概念是相当大的一次转向，而且他们已经学到很多关于如何改进屏蔽垃圾邮件服务的东西；另外，生成一套新视觉稿并再招一批客户花不了多少时间。 这一轮他们决定谈更少的客户，以节省一些时间和金钱。
• 基于所学的迭代（这一节展示了"深入问题空间"的实际收益，是全书最能说明"和客户聊有什么用"的部分）：他们扔掉旧视觉稿、从头设计一个聚焦减少垃圾邮件、以拯救树木为次要收益的新产品。
  • 新 MVP 原型的用户体验：从一封朋友推荐 JunkmailFreeze 的邮件开始，链接到解释收益的首页，页面有一个大的"开始使用"转化按钮，还有一个"了解更多"链接。点"开始使用"进入简单的注册页（输入姓名、地址、邮箱、密码），点"注册"后进入"我的账户"页，在那里指定自己不想再收到哪些类型的垃圾邮件。在此之前的页面都在解释使用 JunkmailFreeze 的好处，而这一页是用户真正与产品交互以获得那些好处的关键页面。
  • 第一轮测试之前，他们对相关收益的认知只是"减少客户收到的垃圾邮件量"。和用户聊过之后，他们对问题空间的理解深了太多：
    • 发现一：几乎所有客户最痛恨的特定类型的垃圾邮件是"预批准的信用卡邀约"和"现金预支支票"。 原因是大多数客户没有带锁的安全信箱，所以他们担心有人可能从信箱里偷走预批准的信用卡邀约、用他们的名义开卡，或者偷走现金预支支票拿去用。→ 他们用这个认知在新设计里打磨了相关的信息传达。
    • 发现二：总体上金融类垃圾邮件是最大的顾虑区域——包括刚才提到的类型，以及贷款和保险。客户担心这些类型的垃圾邮件会增加身份盗用的风险。"我们谈过的每一位客户似乎都认识某个曾是身份盗用受害者的人。" → 于是他们把"降低身份盗用风险"这条收益加进了信息传达。
    • 发现三（最生动的一条）：很多注重隐私的客户会花大量时间粉碎他们的垃圾邮件。有几位告诉他们，下班回家后会把邮件从信箱里拿出来，站在碎纸机旁边一边翻看一边粉碎。对一些人来说，这个每晚的例行公事要花五分钟，日积月累是很可观的。 → 他们意识到减少垃圾邮件还附带一条"省时间"的收益，也加进了信息传达。
    • 发现四：客户认为目录（catalog）很烦，因为又大又笨重。 人们丢掉很多不想要的目录，觉得这是件麻烦事，也相当浪费纸。但他们同时也了解到：人们仍然想收到某些目录，而且不同的人想收到的目录类型不同。
    • 发现五：很多客户认为本地广告是个滋扰。 一种形式是本地优惠券包，很多人没拆就扔了；另一种是本地商家（如超市）的传单和广告页；人们还抱怨收到自己并没有订阅的免费本地报纸。
  • 这些发现如何改变了产品：Olsen 说这是"和客户交谈如何帮你深得多地理解问题空间的绝佳例子"——他们学到的东西多到让新的"我的账户"页面允许用户屏蔽七大类别下多达 31 种不同类型的垃圾邮件。 用户选完想屏蔽的类型后点"继续"完成注册。
  • 其他基于第一轮所学的设计改进：
    • "注册完成"页告诉用户接下来会发生什么：在接下来的几个月里，他们应该会看到所选类别的垃圾邮件量显著减少。第一轮测试他们学到客户预期这个服务需要一段时间才会"生效"，同时他们也知道从运营上讲，服务对每位客户生效确实需要一段时间。（即：把用户预期和运营现实对齐。）
    • 该页还说明用户可以随时回到 JunkmailFreeze 更改想要冻结的垃圾邮件类型。这是因为第一轮研究学到"能够更改设置"对客户很重要——有几位表达了担忧：屏蔽垃圾邮件可能会让他们无意中收不到某些其实想收的邮件。 因为这一页的信息传达符合客户预期，大多数人读到时都点头或者说"这听起来不错"。
    • 为还没准备好立即注册的客户提供了"了解更多"路径，解释 JunkmailFreeze 如何代表你联系直邮公司、把你从他们的邮寄名单上移除，并说明你仍然能收到对你重要的直邮。
    • 因为身份盗用是与垃圾邮件相关的一大顾虑，他们还专门做了一页解释两者的关联，其中包含一张一排脆弱信箱的照片，说明如何通过使用他们的服务降低身份盗用风险。
    • 因为第一轮用户测试中客户对"这个服务是谁提供的"有很多疑问，他们加了一个"关于我们"页面——客户想了解这家公司及其背景。
• 第 2 波：用同一份 Shield 筛选问卷（因为它效果很好）招募了新一组客户，这次排了三组、每组两人。Olsen 更新了研究脚本聚焦垃圾邮件。场次仍是 90 分钟，仍在晚 6 点和 8 点。因为第一波已经做了相当多的探索，这一波想聚焦把产品细节做对，所以在视觉稿上花的时间更多（45 分钟而不是 35 分钟）。
• 爬上产品市场契合之山（结果）：
  • Olsen 的原话很有画面感："第二波用户测试是我见过的最酷的事情之一——结果与第一次截然不同。" 没有一位客户对产品有重大顾虑或疑问。 相反，他们翻看视觉稿时不断点头，还有"哦，这个很棒"这样主动的评论。他们确实有一些小的意见、问题和建议。但因为第一轮已经搞清楚主要问题在哪、并在第二波的视觉稿里充分解决了，所以每个人都真的很喜欢这个产品。
  • 但视觉稿并没有"做完"：他们对客户在一个屏蔽垃圾邮件服务里想要什么有了更深的理解。例如他们学到，对信用卡和目录相关的垃圾邮件，类别级别的屏蔽控制是不够的——客户想要能在具体公司层面指定偏好（信用卡如 Chase 或富国，目录如 Nordstrom 或 L.L. Bean）。他们还收到了能进一步改进产品的信息传达和 UX 方面的反馈。
  • 关于定价的信号，以及 Olsen 的克制：这一次问客户愿意为这样的服务付多少时，他们看到了更强的付费意愿和更高的付费金额（相比第一波）。但 Olsen 立刻加了一句非常重要的保留："和客户讨论定价时你总要保持一点怀疑。同样，他们说会做什么和实际会做什么可能不同。在你有一个真实产品、他们必须用钱包投票之前，你并不真正知道他们愿意付多少。" 不过，对第 2 波产品的兴趣显然强得多。他有信心他们已经用视觉稿达到了足以往前推进的 PMF 水平。
  • 还有一个让他更有信心的理由（本章最漂亮的收尾证据）：每场测试结束后，他致谢并给客户报酬支票。收到支票后，每一位客户都问他这个服务现在上线了吗、他们能不能注册。当他解释说还没造出来时，他们都请他留下自己的邮箱、上线时务必通知。第一波中没有任何一位客户表现出这样的行为。 因为这是在用户测试范围之外发生的、真诚的正面客户兴趣，他把它当作 PMF 的又一个证据。
• Olsen 的反思（本章的方法论总结）：
  • 在这个项目之前，他做过各种类型的客户研究来征求对产品或产品概念的反馈，也待过实践用户中心设计的团队。但这个项目是他第一次以如此"精益"的方式创造并测试一个产品创意。
  • 四条具体收获：① 专注于视觉稿、不写任何代码，让他们能快速迭代；② 通过筛选问卷对目标客户保持严谨，让他们招募到了能给出优秀反馈的客户；③ 整个项目耗时不到两个月，且资源使用非常高效；④ 他为"在这么短时间里、仅用一轮迭代，一个小团队就把产品创意改进了这么多、达到了高水平的 PMF"感到兴奋。
  • 他分享这个案例的第二个理由，也是最重要的一句："我们并没有做任何特别或独特的事情。我们只是遵循了精益产品流程。没有理由别人不能复制我们取得的结果。" 按本书描述的流程，任何团队都应该能用自己的产品创意取得类似结果。
  • 但他同时给了非常诚实的限定：当然，具体到你的情况细节会有所不同——你可能需要更多轮次；你可能不需要转向，也可能需要转向不止一次；而且并不能保证你追求的每一个产品创意都能达成 PMF。但你应该能够检验你的假设，并有信心地评估你的 PMF 水平。
  • 最后一条建议：为了最小化风险、更快取得进展、避免浪费，他强烈建议在开始写代码之前先在设计物上获取反馈。这能让你在投入编码之前对假设更有信心。

第 12 章 · 用敏捷开发构建你的产品

• 本章的前提：到这里你已经验证了目标客户、未被满足的需求、价值主张、MVP 功能集和 UX，应该对自己开发出的这份"蓝图"感到有信心。用原型验证 PMF 极有价值，但现在到了把蓝图变成客户真正能用的产品的时候。
• 构建阶段的四类风险（Olsen 先把风险摆出来）：① 技术可行性问题——你设计的东西不可能实现，或者以你现有资源太难实现；② 范围过大——产品可行但相对你的资源范围太大，造起来太久。这里有一句很重要的话：好的市场机会只会存在一段时间，之后竞争就会把它们推到重要性 vs 满意度框架的右上象限。PMF 的一个重要组成部分是"在正确的时间拥有正确的产品"（呼应第 5 章的产品战略讨论）；③ 执行不力——即使范围合适，糟糕的执行也会让你的真实产品远远达不到原型的承诺。
• 瀑布 vs 敏捷：
  • 瀑布（waterfall）：顺序推进——先定义所有需求，然后设计产品，然后实现，然后测试验证。关键特征是：上一步 100% 完成之前不进入下一步。 换言之，所有需求定义完之前不做任何设计，整个产品设计完之前不写任何代码。也叫"大设计先行"（BDUF）。
  • 敏捷：把产品拆成更小的块，每块经历更短的"需求定义-设计-编码"周期。三个好处：① 因为你在以更小的增量做规划，能更快对市场变化或其他新信息做出反应；② 产品更早到达客户手里——这意味着你更早听到客户对你真实产品的反馈，从而指导后续开发；③ 通过更小的批量，团队能减少估算范围时的误差幅度。
  • 不确定性锥与"未知的未知"（本章最有原创性的一段分析）：
    • Steve McConnell 的"不确定性锥"刻画了软件项目生命周期中预期估算误差的范围：上下界是对称的曲线，项目开始时分别是 4× 和 0.25×，随项目推进逐渐收敛到零。 Olsen 说这在直觉上说得通、也符合经验——项目早期的估算误差比后期大。
    • 但 Olsen 提出了自己的修正："在实践中，我没有经历过估算误差是对称的。" 换句话说，他没有看到开发者提前完成任务的概率与延后完成的概率一样大。大多数时候，软件开发任务花的时间比估计的长。虽然确实有些任务会提前完成，但正面惊喜的量级往往远小于负面惊喜的量级。
    • 为什么？他引了 Donald Rumsfeld 那段著名的话：有已知的已知；有已知的未知（我们知道有些事我们不知道）；但还有未知的未知——那些我们不知道自己不知道的事。
    • 他的分析：开发者被要求估算任务工作量时会考虑"已知的已知"；熟练的估算者还会把"已知的未知"计入估算。诚然一部分估算误差来自对已知的已知或已知的未知理解不准，但他相信一次又一次估算中最大的变数是"未知的未知"，而它们正是让估算误差分布变得不对称的原因。
    • 一个很有说服力的量化直觉：假设我估计任务 A 要五分钟、任务 B 要五个月。两个任务都可能有未知的未知。但不确定性随范围增长是非线性的（正如不确定性锥的上界曲线所示）。五分钟的任务失控的概率很低。五个月的任务在范围上是它的三万倍以上，给未知的未知留下了多得多的藏身之处。
    • 由此得出关键结论：当开发者经历"把大任务拆成小任务"所需的思考和调查时，他们通过把未知的未知转化为已知的未知，从而减少了未知的未知。你无法完全逃脱未知的未知，但通过使用更小的批量，你可以把它们控制得更可管理，并更可预测地交付产品。相比之下，范围通常很大的瀑布项目，以远超原始估算而臭名昭著。
  • Olsen 对"敏捷狂热者"的批评（一段很有分寸的话）：除了延期之外，有些敏捷狂热者喜欢抨击瀑布，因为他们强烈反对"流程有依赖于前序步骤的顺序步骤"这个概念。他们表现得好像敏捷让"直接跳进去开始写代码"变得可以接受。但那种观点走得太远了。即使在敏捷里，你也应该先设计再编码——只是你在以小得多的增量这么做。
  • 瀑布更合适的场景（同样很有分寸）："值得指出的是，对某些项目来说瀑布是更好的方法。" 例如：我们不会想用一艘"最小可行飞船"把人送上太空。 Olsen 用自己的经历现身说法——他职业生涯是从设计核动力潜艇开始的，"在开始建造之前，我们绝对会多次检查需求、多次评审设计"。 理由：失败的风险太高了——也就是说，人可能会死。 而且不像网站代码可以随意快速更改，飞船或潜艇造好之后要改困难得多。结论：当失败的风险或做出更改的成本太高时，最好在开始实现之前花更多时间获得更高水平的信心。
• 敏捷宣言的核心主张：写于 2001 年。敏捷鼓励尽早并持续交付可工作的软件，其心态聚焦于为客户创造价值。敏捷的关键部分是用用户故事以客户为中心的方式定义你的产品（模板同第 6 章）。敏捷还提倡强有力的跨职能沟通与协作，业务人员与开发者每天一起工作，最好是面对面。敏捷不鼓励死守僵化计划，而是强调灵活性以快速响应变化——通过在短的迭代周期中完成小批量工作并伴随反馈和学习来实现，而不是试图预先规定全部详细需求。最后，敏捷强调通过反馈与实验持续改进你的产品开发流程。
• Scrum（最流行的敏捷框架）：
  • 易于采用，因为关于如何实践 Scrum 有大量规定性的指导。关键特征是团队以时间盒（time-boxed）增量工作——这段工作周期叫冲刺（sprint）或迭代，长度固定。两周冲刺非常常见，也能看到一周、三周、四周的。
  • 所有工作都来自用户故事的产品待办列表（product backlog）——待办列表是一份按优先级排序的待办事项清单。
  • 三个角色：
    • 产品负责人（PO）：负责利用来自客户和干系人的输入，创建按优先级排序的用户故事待办列表。团队里的产品经理通常担任 PO；有些公司在产品经理之外还有专职 PO，两人紧密协调；在没有专职产品经理的小型创业公司，通常由某位创始人戴这顶帽子。
    • 开发团队成员：Scrum 指南说团队应当是多学科的、具备完成工作所需的全部技能。Scrum 团队通常包括若干开发者（工作是估算故事大小和构建产品），另外三个重要角色是 UX 设计师、视觉设计师和 QA 测试人员。传统 Scrum 指南不区分团队成员，但 Olsen 认为在团队内部承认不同角色是可以的。 设计师通过设计交付物把用户故事变成现实；写得好的用户故事包含验收标准，用于确认故事何时完成并按预期工作；QA 测试人员帮助检查验收标准是否满足并确保产品质量。
    • Scrum Master：工作是帮助团队执行 Scrum 流程并随时间提升其生产力。大公司可能有专职 Scrum Master 服务一个或多个团队，但通常由开发主管或开发经理担任。Olsen 诚实地指出：虽然这不符合 Scrum 指南，但有时这个角色并没有由某个人明确担任——要么被忽略，要么职责被分散到团队各处。
  • 理想团队规模是 5 到 9 人。你可能听过"两个披萨规则"：如果两个披萨喂不饱你的团队，那它就太大了。 这个规模下既有足够的人每个冲刺完成有意义的工作量，团队又小到能感觉像一个内聚的单元，避免更大群体通常出现的沟通挑战。
  • 冲刺前的准备：PO 会梳理待办列表（backlog grooming / refinement），确保被考虑进入下个冲刺的故事写得好并被团队理解。PO 通常在梳理会上与开发主管或开发经理一起做这件事。
  • 冲刺规划会：决定这次迭代计划完成哪些故事，把它们从产品待办列表移到冲刺待办列表。过程中团队要用故事点估算每个故事的范围——故事点是一种相对的工作量度量。
    • Olsen 对点数估算的定性很实在："估点常常更像艺术而非科学。" 常见的点数体系：任意数字（1、2、3、4、5、6……）；斐波那契数列（1、2、3、5、8、13……）——好处是它强制估值之间有明确的差异；2 的幂（1、2、4、8、16……）——强制更大的差异；T 恤尺码（S、M、L、XL）。
    • 点数高端的故事范围大、不确定性高，应该拆成更小的故事（同第 6 章）。大到一个迭代内完不成的故事叫史诗（epic），必须先拆分才能被接受进冲刺。 很多敏捷跟踪工具支持用 epic 组织相关故事并跨多个迭代管理它们。
    • 速度（velocity）：如果故事点让你觉得有点抽象，那是因为它确实抽象——至少一开始是。 目标是通过跟踪团队每个迭代完成多少故事点来确定团队的工作容量，这就是速度。团队算出平均速度后，就能用这个点数来规划冲刺。 虽然故事点起初有点抽象，但它们提供了一把用于确定经验值的量尺。（注意：要计算速度，故事点估算必须有数值，所以用 T 恤尺码的团队必须把每个尺码映射到相对点数。）
    • 书中速度示例的读法：横轴是按时间顺序编号的迭代，纵轴是完成的故事点数。在这 12 次迭代中，团队速度是波动的（22 到 40 个故事点之间），这是正常的。尽管有波动，趋势线显示团队的速度一直在稳步提升。
    • 减少估算误差的技巧：团队常常一起讨论并估算故事点，而不是只让一个成员来定某个故事的大小；有些团队建立一组已知大小的参考用户故事，把故事与参考故事比较有助于更准确地估算范围。
    • 计划扑克（Planning Poker）：一种流行的、能快速产生可靠群体估算的技法。每个成员拿到一副牌，每张对应一个可能的点值（如 1、2、3、5、8）。团队讨论完一个故事后，每人私下选出自己估算的那张牌，然后所有人同时亮牌。如果团队有相对共识，就更有信心这个估算是准确的；如果估算有实质性分歧，就进一步讨论该故事以试图达成共识估算。
    • 任务拆分：团队常把每个故事拆成实现它所需的编码任务集合。这有助于确保他们认真考虑了故事所需的工作、不会遗漏什么；而且相比整个故事，估算这些更小任务的工作量通常更容易。 有些团队用点数估算任务，有些偏好用小时；有些团队识别任务但不估算，把估算保持在故事层面。
    • 规划完成时：团队应清楚这个冲刺计划完成哪些故事。他们应从产品待办列表中选取优先级最高的故事，且这些故事的总点数应与团队本次迭代的预期速度相匹配。 在开发者技能差异较大的团队里，还应确保每个故事都指派给了具体的开发者，以保证冲刺内团队负载均衡。
  • 每日 Scrum（站会）：冲刺期间每天举行，也叫站会，因为很多团队站着开以保持简短。通常一早举行以便团队讨论当天计划，一般时间盒定为 15 分钟。成员各自简要说明昨天做了什么、今天计划做什么、以及任何阻碍进展的事情。
  • 执行与跟踪：团队从冲刺待办列表顶部开始实现用户故事，按需协作。Scrum 工具：JIRA Agile、Rally、VersionOne、Pivotal Tracker，用于管理产品和冲刺待办列表及冲刺规划；成员用它们跟踪每个用户故事的状态，如"待开发"→"开发中"→"编码完成"→"完成"。
    • 燃尽图（burndown chart）：显示本次迭代还剩多少工作。可以按点数或小时显示，取决于团队跟踪所用的单位。示例读法：横轴是冲刺的日子，纵轴是冲刺剩余的故事点。从冲刺的"第零天"开始，标出待完成的点数（示例中是 45），图上显示 10 个工作日，对应两周冲刺（只显示工作日）。理想情况下团队在冲刺结束时剩余故事点为零。
  • QA 测试在冲刺期间进行：为达到更高速度，团队成员应在开发者完成故事时就测试它。如果故事满足验收标准就接受，否则拒绝并打回开发。团队还应在冲刺末尾预留一些时间，在开发完成后测试整个产品并修复发现的 bug。
  • 冲刺的目标是完成一个"增量"，为产品增加功能。Scrum 指南要求每个团队自己定义"完成"对他们意味着什么。对很多团队来说，"完成"意味着一个可以发布的产品，称为"可发布产品"或"潜在可发布产品"。很多团队以与迭代相同的频率发布新产品，在冲刺结束后不久就把冲刺产出发布给客户；另一些团队有独立的、周期更长的发布流程，把多个冲刺的工作合并成一次发布。无论你的部署流程如何，目标都是确保产品在冲刺结束时处于可发布状态。
  • 冲刺评审会（也叫演示会）：冲刺结束时举行，展示他们构建了什么。这有助于确保产品按预期工作，也让所有人看到团队的进展。理想情况下客户或干系人参加演示，提供可供未来冲刺考虑的反馈。
  • 回顾会（retrospective）：Scrum 同样关注随时间改进团队流程。 团队开回顾会专门反思上个冲刺进行得如何：讨论什么进行得好、什么不好、下个冲刺想做哪些改进。有些团队每个冲刺后都开，有些每两三个冲刺开一次。
• 看板（Kanban）：
  • 来源：改编自丰田为改进造车方式而开发的系统。丰田生产系统聚焦准时化生产和消除浪费。 Olsen 说他在弗吉尼亚理工的研究生项目里学过原始看板系统和精益制造，而后者启发了精益软件开发运动。
  • 一个重要的失真说明：制造业工人用纸质看板卡来物理地发出"应该拉入更多工作"的信号。这些卡片在软件开发中被改编为虚拟卡片，每张代表一个工作项，但并不真的产生拉动信号——取而代之的是由团队成员主动把下一个工作项拉过来。
  • 核心原则是可视化工作：每张卡是一个用户故事或支持某用户故事的开发任务。卡片排布在看板板（kanban board）上，板由一组列构成，每列代表工作的一种状态，列按工作流动的顺序从左到右排列。示例板的列是：待办（backlog，可能要做的事项，按优先级排序）→ 就绪（ready，已从待办中选出、可以开发了）→ 开发中 → 开发完成（开发者已完成但尚未测试）→ 测试中 → 测试完成（已通过测试但尚未部署）→ 已部署。
    • 有些列代表正在进行的工作（如开发中、测试中），另一些代表等待被处理的事项（如就绪、开发完成）——后者是工作队列。当某个成员完成一项工作腾出容量时，他从相应队列中拉取最上面的一项开始做。
    • 随着工作项推进各阶段，其卡片从一列移到下一列。任何时点只要看板就能轻松可视化团队在做什么；也很容易看出瓶颈在哪——看哪些列积压的卡片最多。
    • 一个设计细节：示例板没有只用单一的"测试"状态，而是有"测试中"和"测试完成"两个状态；"开发"同样用了两个状态。这有助于更清晰地呈现团队工作的状态，也让瓶颈更容易识别。
  • 在制品限制（WIP limit）：在看板中，活跃工作的数量通过约束"在制品"数量来管理。 团队决定每列最多能容纳多少张卡片，这就是 WIP 限制。成员按顺序把工作项拉过各个工作状态，但只有当下一列还有余量时才能把工作项移过去。这条规则有助于平滑工作、实现稳定的流动。团队应随时间微调 WIP 限制以优化工作流。
    • WIP 限制显示在每列上方。团队常常用单一 WIP 限制来约束"进行中"和"完成"这两个相关状态的卡片总数（而不是各自设限）——例如"开发"卡片总数不能超过 3。这有助于鼓励卡片从完成状态向右流动。
    • 示例推演（很好地说明了拉动机制）：做卡片 D 的开发者完成后，把它从"开发中"移到"完成"。但他无法把卡片 F 从"就绪"拉过来，因为"开发"已达到 WIP 限制 3。 同样，QA 测完卡片 B 后把它移到"测试完成"，但无法把卡片 C 拉过来，因为"测试"已达到 WIP 限制 2。要让工作推进，必须先把某张"测试完成"的卡片部署掉。一旦部署，卡片 C 就能被拉到"测试中"，这又腾出"开发"的容量，于是卡片 F 能从"就绪"被拉到"开发中"。
  • 泳道（swimlane）：用水平线把卡片分成行，有多种分类用法——按优先级（行越高优先级越高）；给每个 epic 或每个用户故事各一行；每个团队成员一行以更清晰地展示各人的工作流；也可以把多个相关项目放在一块板上，每个项目占一行。
  • 看板的度量（与 Scrum 的关键差异）：看板关注的是工作的流动，没有 Scrum 那样的时间盒迭代。 工作项随着推进从左到右连续移动。用户故事的范围不一定被估算，所以 Scrum 的速度概念（每迭代交付的故事点）并不真正适用。
    • 吞吐量（throughput）：给定时间内完成的工作项数量（如每周 10 项）。如果你随时间跟踪吞吐量，它应该随着团队做出流程改进、变得更熟练而上升。
    • 周期时间（cycle time）：从开始处理某项工作到该项交付给客户的平均时长。前置时间（lead time）：从工作项被创建（如被客户请求）到交付的平均时长。Olsen 特别提醒：周期时间和前置时间不一定与工作量相关——某个工作项可能只要一小时就能完成，但如果它长时间无人处理，前置时间会长得多。
    • 累积流图（cumulative flow diagram）：一种堆叠面积图，显示每天结束时每个工作状态里有多少张卡片。书中示例为简化只用了三个状态（待办、已开始、已完成）：周期时间是"已开始"部分的水平宽度，前置时间是"待办"和"已开始"两部分合起来的水平宽度，WIP 是"已开始"部分的垂直高度。
  • 看板的心态聚焦持续改进——团队应定期识别并讨论如何工作得更好更快。理念是：随着团队做出流程改进、变得更熟练，前置时间和周期时间应该随时间下降。
  • 一条实用的适配建议：很多团队的待办列表在不断变化，曾被认为重要的事项随着新事项加入变得不那么重要。与 Scrum 中冲刺待办列表在迭代内通常被锁定不同，看板的待办列表任何时候都可以被团队成员更改。在这种快速变化的情形下，周期时间可能是更值得关注的指标。 但你仍应留意"把待办事项准备到可开发状态"要花多久，以确保它没有拉低团队吞吐量。
  • 另一条：如果工作项的范围差异很大，你会看到周期时间跨度很宽（小项周期短、大项周期长）。有些看板团队对工作项使用前面提到的 T 恤尺码法，以获得更精确的周期时间值——这样每个尺码都有各自的周期时间。
  • 看板不像 Scrum 那样有高度的流程规定，所以没有规定任何仪式；但很多实践看板的团队仍然开每日站会和定期回顾会。
  • 看板工具：很多小型产品团队直接用白板——给每个工作状态画一列，每个工作项用一张便利贴，这让移动事项很容易，工作区里任何人看一眼板就知道团队工作的状态。数字工具：Trello（流行的可视化看板应用，很多人还用它管理开发之外的工作，尤其受产品经理和设计师欢迎，他们可能维护自己的工作板并汇入开发板）；很多团队用 JIRA Agile 做看板；还有 SwiftKanban 和 LeanKit。
    • Pivotal Tracker（Olsen 单独推荐的一个）：虽然不是纯看板工具，但值得一看。他在与 Pivotal Labs 合作构建一个新产品时用过 Tracker，称那是段有收获的经历。 Tracker 使用可视化的列板，每列对应一个预定义的工作状态，支持看板与 Scrum 的有趣混合（他顺带提到确实存在一种叫 "Scrumban" 的敏捷方法论，如果这个想法吸引你可以去看看）。
    • Tracker 的机制很有意思：它让你在想估故事点、算速度时可以估；不估时它感觉更像看板，估了则更像 Scrum——只是当前冲刺的待办列表不是固定的，而是动态确定的。故事按优先级排列，并基于"预计能完成多少故事点"（用计算出的速度和冲刺剩余时间）自动移入或移出当前迭代。 如果你想让 Tracker 更像 Scrum，可以用"手动规划"模式（也叫"承诺"模式），锁定冲刺待办列表中的故事集合。
• 怎么选 Scrum 还是看板（Olsen 给了一个很好的比喻和一套具体建议）：
  • "我发现敏捷框架就像鞋子：你真得穿上试试才知道合不合脚。" 通常明智的做法是先挑一个听起来最合你意的方法论，试上几个月。很多团队先试 Scrum 或看板，合适就继续，不合适就换另一个。两双鞋都试过之后，团队应该能判断哪双更合脚。
  • 提高首次选对概率的具体建议：
    • 看板往往最适合较小的开发团队——更低的流程开销和没有预定迭代长度，能实现更快的产品交付。
    • 但当开发组织成长为多个团队时，看板会开始变得更有挑战。部分原因是工作缺乏确定的节奏，这会增加为保持所有人同步所需的沟通量。 协作能力强的团队能把看板扩展到更大规模。如果你的组织有多个需要协调工作的开发团队，Scrum 可预测的节奏会有好处。
    • 关于硬性发布日期（一段很实在的观察）："硬发布日期这个概念在任何敏捷方法论下都是站不住脚的。" 大多数瀑布式组织习惯有一个自上而下的路线图，规定每月或每季该发布什么功能——"尽管由于延期，那些截止日期往往是虚幻的"。这些组织转向敏捷时，很多人对产品待办列表仍抱着瀑布心态。Olsen 用了一个很妙的词："Agilefall"——用来形容那些处在从瀑布到敏捷的尴尬过渡期、两只脚各踩一边的公司。如果你的组织很难放下"硬截止日期"这条安全毯，那 Scrum 可能比看板更合适：至少用 Scrum 你知道每次迭代结束时会有工作完成，并且能对某个功能需要多少个冲刺做高层估算。大多数看板团队不花时间估算工作量或完成日期。（他补充：通过仔细跟踪周期时间并使用简单的统计技术，用看板做出置信度相对较高的预测是可能的，但很多团队达不到那种跟踪和精度水平。）
  • 工具选择上的建议：无论选哪种敏捷方法论，都强烈建议使用好的工具来管理工作。一个错误是使用通用工具而不是为你的开发方法论优化过的工具。 同样建议试用你认为最合适的工具，一两个月后不满意就换一个。
  • "隔壁草更绿"综合征（一条很好的团队诊断）：Olsen 遇到过很多不喜欢某个方法论或工具的开发团队，这是意料之中的。但他也见过有"隔壁草更绿"综合征的团队：试用很短时间就抨击当前方法论或工具，换到另一个用一个月又开始抱怨，然后循环往复。如果你的团队换了好几种方法论或工具、似乎都找不到一个足够好用的，你多半需要退后一步反思——这可能是个信号，说明团队缺乏必要的投入程度、或必要的培训，或者两者都缺。
  • 培训（一条常被忽略的建议）：让团队一起参加敏捷培训会很有帮助。 Olsen 见过很多团队在并非所有成员都有足够理解的情况下就采用新方法论，不出意料，很多这样的团队都很挣扎。采用新方法论之前，评估一下每个成员对它的了解程度是个好主意。即使有几位成员在之前的公司用过 Scrum 或看板，他们在那里的实践方式也很可能存在有意义的差异。如果你不设定新的预期，成员很可能会假定你们遵循的是他们所熟悉的那套做法。让团队所有人在同一时间听到关于产品开发流程应如何运作的同一套说法，是有重大价值的——这确保所有人有相同的预期、减少误解、并应能提升生产力。
• 敏捷成功的四条补充建议：
  • 跨职能协作：敏捷依赖强有力的跨职能协作。产品经理、设计师、开发者、QA 和其他成员之间应有自由而频繁的沟通，应每天交谈。 必须避免形成孤岛——每个职能把自己的工作产物"越墙扔"给工作流中的下一个职能。一定量的面对面实时沟通对最大化共同理解和团队速度至关重要。 高绩效团队还使用聊天工具、开发跟踪工具（如 JIRA Agile）和知识协作工具（如 wiki 或 Google Docs）。
    • 每个职能都应贯穿全程参与，尽管某个职能在某个阶段更投入、担任主导是自然的。简言之：产品经理写用户故事，然后设计师做设计物，然后开发者写代码，然后测试人员测试。但产品开发是一项团队运动。开发者和测试人员应该在开发流程早期就有所参与，以便理解产品决策、用户故事和 UX 设计背后的理由。团队应鼓励他们在所有阶段提问和贡献。同样，产品经理和设计师在开发和测试期间也应保持在环内，尤其因为那时常常冒出意料之外的问题。
    • Olsen 引了他在 Intuit 时的一句口头禅："好点子来自四面八方。" 并给了一条很妙的诊断指标："你可以通过团队成员多久用'我们'而不是'他们'来称呼彼此，判断出协作的水平。"
    • 有效协作的价值：帮助团队达成共同愿景、避免误解、让团队走得更快。每个成员每天都在对产品做出大量决策。如果团队有共同愿景、理解目标和理由，成员就更可能独立地做出支持该愿景的决策。
  • 无情的优先级排序：应维护一份最新的、已排序的待办列表。清楚下一批计划实现的用户故事是什么，能让你行动迅速。高科技产品团队通常在需求和优先级快速变化的动态环境中运作。
    • 一条很具体的批评："仅仅把事项标为高、中、低优先级是不够的。如果一个待办列表里有 15 个高优先级事项，那当一位开发者腾出时间时，就不清楚该先做其中哪一个。优先级层级有用但不充分；你还需要在每个层级内部对待办事项进行排序。" Olsen 自称是"无情优先级排序"的拥趸（"记录在案：它的反面是含糊其辞的优先级排序"）。把待办列表排好序能明确下一个该做什么，也让新需求出现时更容易判断它该放在待办列表的什么位置。
    • 水与冰的比喻（很实用）："诀窍是在优先级排序上既要刚性又要柔性。你必须在任何时点都清楚自己的排序优先级；但你也必须能够快速纳入新的或变化的需求。我用水和冰来类比：大多数时候，你的待办列表像冰——排序被冻结、固定。但当新需求进来或优先级变化时，你短暂地把冰融化成液态水，以便重新排列；排完序后再把它冻上。遵循这个方法意味着任何人在任何时候查看时，你的待办列表都是最新的。一位开发者可以可靠地从栈顶拉取事项开始工作，而不必去问任何人。"
  • 为开发者充分定义产品：重要的是给开发者提供构建预期产品所需的信息。一组写得好的用户故事，配上线框图或视觉稿，通常就能很好地做到这一点。
    • 具体的取舍规则：如果团队已有样式指南、且没有引入任何新的重要 UX 组件，线框图通常就够了；如果需要传达视觉设计细节，则应使用视觉稿；对于纯后端、没有 UX 组件的功能，线框图或视觉稿都不需要。
    • 团队应确保定义的不只是"快乐路径"（用户行为的预期路径），而要想清楚可能适用的各种条件和状态。
    • 但 Olsen 立刻给出平衡："这里有一个平衡动作。一方面，你希望提供足够的定义，让开发者能有信心地开始构建，不必担心你漏想了某个重要方面。另一方面，你不希望陷入分析瘫痪——花太多时间纠结每一个细节，导致实现被显著延迟。"
  • 跑在开发者前面（一条非常具体的运营纪律）：很多团队都苦于把 UX 设计整合进敏捷开发流程。Scrum 指南没有明确处理如何最好地做到这一点。"如果设计师在为某个用户故事画线框图的同时，开发者正试图编码实现它，那是行不通的。"
    • 具体的提前量要求：为了让敏捷团队达到最高速度，开发者在开始一个新用户故事时必须能立刻上手——这意味着团队必须事先敲定用户故事和设计物。因为你想实现稳定的工作流动，设计师需要至少领先当前冲刺一到两个冲刺。换句话说，到第 N 个冲刺结束时，他们应该已经敲定了第 N+1 或 N+2 个冲刺的设计物。当然，设计师需要扎实的用户故事作为设计依据——所以产品经理需要比设计师再领先一到两个冲刺。
    • 目标：确保你永远不会让开发者没活干，并且始终至少有一个冲刺量的、完全梳理好的待办列表随时可用。这需要一些平衡，因为你也不希望提前规定太多个冲刺——事情可能会变。
    • 这条同样适用于看板：基于设计师的周期时间，产品经理应确保"待设计"队列里有足够的卡片；同样，基于开发者的周期时间，设计师应确保"待开发"队列里有足够的卡片。
    • 最后一句很重要："产品经理和设计师都不应该在真空中做他们的工作。团队需要在当前冲刺中划出一定时间，来评审和讨论未来冲刺的用户故事与设计。"
  • 把故事拆小：敏捷要求以小块工作。 除了"用户故事不应超过某个合理的最大规模"之外，你还应努力把故事拆到尽可能小的尺寸。
    • 一个非常具体的操作示例："如果你有一个五点的故事，试着想办法把它拆成一个三点的和一个两点的。更好的是，试着把它拆成两个两点的和一个一点的。" 这一开始可能显得困难，但和大多数事情一样，练习会让你变好。如果实在无法再拆分故事，那么开发者应该尝试拆分实现该故事所需的任务；如果连这个都有困难，就先从列举他们计划采取的步骤开始。
    • 拆小的三重收益：范围更小的故事和任务带来更小的估算误差；把用户故事分成更小的块通常要求你更详细地思考它们，这也降低了不确定性和风险；而且当你拆分一个故事时，你可能会意识到其中某些要素比另一些更重要，这有助于你精炼优先级。 同样的建议也适用于看板，即使你不使用故事点——试着把每张较大范围的卡片拆成几张较小范围的卡片。
• 质量保证（QA）：
  • 前提：软件产品本质上是复杂的，它们很少能 100% 按预期工作，所以在发布给客户之前你需要有某种保证产品质量的计划。对产品质量没有很好的把控会带来一系列头疼事：愤怒的客户、损失的收入，以及对团队资源的破坏性消耗。
  • 尽早发现缺陷是一条减少浪费的精益原则。一个直到产品上线后才被发现的重大 bug，比在开发期间发现的代价高得多：① 它对客户产生负面影响；② 团队通常要花更多时间才能找出生产环境 bug 的根本原因并修复它，因为他们已经不在积极处理那段代码了；③ 因为缺陷是活的，客户的痛苦会一直持续到 bug 被修复且新代码部署给客户为止。
  • 除 QA 测试外提升质量的三种手段：
    • 编码规范：帮助团队里不同的开发者避免任意的风格差异、在编码方式上达成一致，有助于消除那些可能导致质量问题的不一致。编码规范还让一位开发者更容易理解和修改另一位开发者的代码，这使代码更易调试和维护，也提升了开发者的生产力。
    • 代码评审：一位开发者检查另一位的代码，能捕捉到原作者遗漏的错误；评审者往往还对如何改进代码有好想法。代码评审让缺陷能在测试之前被发现和修复，也是开发者之间互相学习的好方式。
    • 结对编程：比代码评审更进一步——两位开发者同时一起创建代码，并排坐在一台电脑和一副键盘前看同一块屏幕。处于"驾驶员"角色的开发者控制键盘写代码，第二位担任"观察者"角色，在搭档创建代码的同时进行评审。两人频繁交换角色。结对工作促进学习，通常能带来更好的产品设计和更高的质量。结对编程是极限编程（另一个知名敏捷方法论）的核心信条。
  • QA 测试的两种类型：
    • 手工测试：一个或多个人与产品交互以验证它按预期工作。也叫"黑盒"测试，因为测试者不需要了解产品是如何构建的或背后的技术。 很多公司有专职全职 QA 测试人员；没有配备 QA 的公司，测试负担落在其他成员（如开发者和产品经理）身上，这种情况下开发者常常在测试自己的代码。
      • 配备专职 QA 的三条好处（Olsen 讲得很具体）：① 他们比开发者检查自己的代码更可能发现意料之外的问题，因为他们以全新的视角来测试；② 有专职 QA 资源时测试通常更彻底——因为这是 QA 的主要工作，他们有更多时间测试；③ 优秀的 QA 人员会系统性地进行测试，这使得被检查的条件更多；④ 技术娴熟的 QA 人员有一种"找到方法把软件搞崩"的诀窍，并且熟悉常见问题。
    • 自动化测试：用软件对产品运行测试，并将实际结果与预测结果比较。一个人（通常是开发者或测试者）必须最初定义每个自动化测试用例，但一旦定义好，就可以随时运行。每次运行一组测试后，都会生成一份哪些通过、哪些失败的报告。
      • 好处：能节省大量手工测试工作，尤其是对那些被反复执行的测试。
      • 但 Olsen 给出了一个很重要的风险："它的好坏完全取决于团队编写的那组测试用例。如果团队没有为某些功能编写测试用例，那些功能就不会被测到。通过运用智慧和创造力，一位人类测试者对产品的反复敲打，常常会测到许多自动化测试用例里没有明确指出的条件和组合。手工测试中的这类发现，应当在产品发布前被用来补上缺失的自动化测试用例。此外，当团队更改功能或用户界面时，必须相应地修订相关的测试用例。"
  • 两种测试目的：
    • 验证测试（validation testing）：检查新的或改进的功能是否按预期工作——是否与相关的用户故事和设计物一致。Olsen 列出了几种偏离原因：产品的实现方式与设计不同，往往是由于错误或误解；开发者也可能是故意这么做的，因为按规格实现不可行，或者他/她选择了一个工作量更低的方案。即使在产品完全按规格实现的情况下，团队随后也可能意识到自己漏了什么或有什么没做对。所有这些问题都应在验证测试期间被检测出来。
    • 回归测试（regression testing）：确保在构建新的或改进的功能的过程中，没有无意中破坏其他现有功能。 换言之，你给产品加了功能 D，想确认功能 A、B、C 仍像加 D 之前那样工作。在这个语境下，"回归"一词意为"退回到更糟的状态"——即在原本没有 bug 的现有功能中引入了 bug。
  • 手工与自动化如何组合（一条很实用的分工原则）：很多公司使用手工与自动化测试的组合，这可以非常强大。
    • 手工测试对首次测试新功能（验证测试）很有价值，因为团队大概率还没想到所有相关的测试用例。一位手工测试者可以尝试不同的组合和条件，帮助识别边角情形。
    • 随着你构建更多功能、产品随时间成长，回归测试的负担也随之增长。产品规模小的时候你可以做手工回归测试，但通常不可能随着产品成长而相应地扩充 QA 团队。这就是为什么自动化测试非常适合回归测试——团队添加新功能时，只需添加新的测试用例并按需更新之前的测试用例。
  • 测试驱动开发（TDD）：开发者在写代码之前先写自动化测试。 在编写期望的新功能或改进之前，开发者先思考如何测试它并写一个新的测试用例。这个测试用例在开发者第一次运行时应当失败——因为代码还没改。如果初始测试没有失败，说明开发者没有正确地编写这个测试。 然后开发者写代码直到她认为完成了，再次运行测试；如果测试不通过，开发者继续工作直到通过。测试成功后，开发者通常会重构代码，以在不改变其行为的前提下改进其结构、可读性和可维护性（同时确保它仍然通过测试）。
    • TDD 的优点：① 通常带来更高的测试覆盖率（产品功能中被自动化测试覆盖的百分比）；② 因此你往往会漏掉更少的回归 bug；③ 增强团队修改现有代码时的信心（因为自动化测试让他们能轻松验证自己没有搞坏什么）。
    • Olsen 的诚实限定：TDD 确实需要一些开销来维护随产品变化的测试。但如果一个团队想让自动化回归测试随产品成长而扩展，那么无论他们是否决定实践 TDD，都需要在开发新功能时编写新的测试用例。
  • 持续集成（CI）：
    • 先解释开发者如何管理代码：开发团队使用版本控制系统跟踪对代码所做的每一次修订，这让查看和管理变更变得容易。版本控制还简化了把代码库恢复到任何先前状态的过程，因此不想要的更改可以被回退。 Olsen 指出在写作本书时，Git 可以说是敏捷开发中最流行的版本控制系统。
    • 流程：开发者修改或新增时，从当前稳定版本的代码库开始，这个版本叫主线（mainline）或主干（trunk）。版本控制让开发者可以从主干拉出各自独立的副本（叫分支 branch），在不影响主干的情况下修改。开发者完成新功能后，把更改提交到版本控制系统。提交之前，每位开发者都应对自己的代码进行单元测试——编写相关的测试用例并确保全部通过。一个开发团队并行工作，各自提交更改。在把新代码与主干合并并发布之前，所有更改会被合并或"集成"以构建整个产品的新版本，此时执行集成测试以确保新产品按预期工作。
    • 历史上集成通常是一个手工过程。持续集成使用自动化的构建流程，基于最新的代码提交创建产品的新版本。新构建会被自动测试，团队会收到哪些测试通过、哪些失败的通知。他们修复所有问题，一旦新代码通过所有测试，就放行部署。
    • 频率：不同团队以不同频率进行持续集成——有的每天一次，有的一天多次，有的在每次单独的代码提交之后。
    • 好处：持续集成帮助团队比原本更早地识别和解决产品开发问题，从而提升团队迭代的速度。这与"尽早发现缺陷以最小化浪费"的精益原则一致。与其让问题在不知不觉中累积成一团糟（在较不频繁的集成之间），持续集成让团队在每个问题出现时就处理它。另一个好处是你的代码始终处于可发布状态，让你在选择何时交付更新后的产品上有更大的灵活性。 你的测试覆盖率决定了持续集成的收益有多大：覆盖率越高越好。
  • 持续部署（CD）：很多实践持续集成的团队也实践持续部署——成功通过所有测试的代码会被自动部署。有些公司自动部署到预发布环境（客户无法访问的内部环境），另一些则直接部署到生产环境。这需要把你的部署流程自动化。
    • DevOps：运维任务自动化方面的进展正由新兴的 DevOps 领域推动，该领域聚焦于大规模构建和运营快速变化的、有韧性的系统。
    • 自动回滚（关键机制）：一个成功的持续部署系统的关键部分，是具备在检测到任何问题时快速回退到上一版本代码的能力，这叫自动回滚。跟踪产品健康状况的指标被用来触发自动回滚。
    • 书中的完整示例（很好地说明了机制）：一位开发者提交了实现网站新功能的新代码。提交的更改经过持续集成、通过所有测试、被自动部署到生产环境。新代码部署后，网站的页面加载时间立刻升高到不可接受的水平，导致客户体验到非常慢的性能。高页面加载时间触发了自动回滚，把线上产品的版本还原到上一版代码。
    • 持续部署对分析系统的要求（很重要的一条）：为了良好运作，持续部署需要一个健壮的分析系统。跟踪服务器健康和性能的技术指标是必需的，用于确保系统正常工作；跟踪产品使用情况的指标同样必需。系统需要能判断出一次新部署是否阻止了用户登录或使用某些其他关键功能。你还需要跟踪业务健康状况的分析。例如，如果你有一个电商网站，而部署新代码后客户下单数量突然大幅下降，你会希望这自动触发一次回滚。
• 本章收尾：Olsen 说本章涵盖了大量与产品开发相关的内容，他分享的很多主题都有整本专书。"这些在敏捷开发、QA 和 DevOps 领域的最佳实践，提升了行业的技术水平，让产品团队变得更有效率。贯穿这些理念的共同主题是：它们都帮助你以更少的风险、更快地构建出优秀的产品。"

第 13 章 · 度量你的关键指标

• 本章的前提与分工：做一个全新的 v1 产品时，上线前和上线后能用的客户研究方法是不同的。上线前你还没有客户群，只能重度依赖定性研究，从潜在客户那里拿对产品的直接反馈。上线后你当然还能继续做访谈，但学习的机会变多了——你有了活的产品和正在用它的客户群，于是可以动用额外的定量方法：分析（analytics）与 A/B 测试。本章讲怎么用分析来建模并度量你的产品与生意，下一章再讲怎么用分析驱动改进。

• 本章最好的框架——Christian Rohrer 的研究方法 2×2（图 13.1）。Olsen 借他同事、UX 研究高管 Rohrer 的框架把"你能从客户身上学到东西的所有方式"分了类：

  • 纵轴 = 你在收集哪一类信息：
    • 态度型（attitudinal）：客户说他的态度和意见。你给他看一张落地页视觉稿，他说他喜欢那套绿色配色、说他很可能会点那个大大的"购买"按钮——这两句都是态度信息。
    • 行为型（behavioral）：客户实际做了什么。你把那张落地页上线，做一对一用户测试看谁真的点了"购买"；或者用分析看访问落地页的用户里有百分之多少点了那个按钮——这两者给的都是行为信息。
  • 横轴 = 你用什么方式收集：
    • 定性（qualitative）：依赖对客户的直接观察。跟 10 位潜在客户做一对一访谈了解痛点与偏好，或者看着一位客户用你的网站，都是定性。
    • 定量（quantitative）：把很多客户的结果汇总起来产生信息。你不是在观察每一个个体，而是在看一大群人的统计结果——追踪"购买"按钮的转化率、或者给几千用户群发问卷问态度偏好，分析出来的都是定量结论。

• "Oprah vs Spock"（Olsen 给定性/定量起的绰号，全书最好记的一个标签）：

  • 定量能告诉你有多少客户在做（或没在做）某件事，但它不会告诉你为什么；定性能帮你挖到客户行为背后的原因，但它不会告诉你每种原因各占多少人。
  • 市场研究里非常常见的顺序是：先定性，搞清楚该问哪些问题、客户会给出哪些回答（"为什么"）；再定量，搞清楚每个答案各有多少客户选（"有多少"）。
  • Oprah（脱口秀主持人）是纯定性的——她一对一长谈，深挖对方是谁、怎么想；Spock（《星际迷航》里的逻辑人）是纯定量的——严格按客观数据和数字做决定。在验证 v1 产品的 PMF 时，Oprah 路数最重要；上线后 Oprah 仍然能用，但你同时可以开始用 Spock 路数来优化产品。

• 四个象限各是什么（逐格对号入座）：

  • 用户访谈（user interviews）= 定性 + 态度（左下）：你想理解用户的需求与偏好、他怎么思考这个问题、相关的情境是什么。你不是在观察任何行为。问开放式问题，但主要是在听他的想法和态度。
  • 可用性测试（usability testing）= 定性 + 行为（左上）：和访谈一样是定性的（你在留意每个用户说了什么），但它更关心行为——不是让用户告诉你他会不会在产品里做某个动作（态度），而是看他到底做不做（行为）。主要目标是通过观察客户使用你的原型或产品来获得行为层面的认知。Olsen 额外提醒：拿竞品做可用性测试同样能挖出有价值的洞察。
    • 一个必须在脑子里分清的东西：即使聚焦可用性，多数用户测试不可避免地会同时产出态度信息和行为信息（因为你往往还会顺带问一些探索性问题）。你要始终清楚自己想要的是哪一类信息、客户给你的又是哪一类。
  • 问卷（surveys）= 定量 + 态度（右下）：定量是因为目标是从大量用户拿结果看整体；态度是因为客户在告诉你他怎么想，你并没有捕捉他使用产品的行为数据。
  • 分析与 A/B 测试 = 定量 + 行为（右上）：分析度量的是真实客户行为，所以你不用担心"客户说的"和"客户做的"之间的脱节；又因为它汇总了大量客户的行为，你能得到统计上显著的结论。

• Olsen 对问卷的三条罕见批评（全书里他少有的"泼冷水"段落，很值钱）：他明说自己讲问卷讲得比其他研究方法少，是因为他见过太多滥用。设计良好的问卷能产出有用信息，但你必须知道它能干什么、并且不越界。

  • 第一，被访者常常根本没有足够的信息来回答你问的问题。 你问 1000 个人"用 1–10 分打分，你有多大可能会用我们打算做的一款全新的、易用的照片分享 App"——这就过头了。为什么？他们对你的产品几乎一无所知：你的产品描述只传达了极少的信息量，它不是一个活的 App，不是一组可点击线框图，也不是一张视觉稿，客户手里没什么可依据的东西，怎么可能准确预测自己会不会用。Olsen 说他一次又一次看到问卷设计者让被访者回答他们肯定没有足够信息去回答的问题。
  • 第二，问卷给的是态度数据，结果必须打折看。 人们对"你有多可能用一个新产品"会给出乐观或悲观的回答，但他们的意见常常和行为对不上。Olsen 的替代方案：他宁可给这个新产品做一个落地页烟雾测试，放一个"购买"按钮、或者请人留下邮箱进 beta 等候名单，然后观察转化率——这个行为数据能以更可靠的方式回答同一个问题。
  • 第三，问卷结果对措辞极度敏感。 问题怎么问、你允许被访者选哪些答案，都可能让结果大不相同。"如果你在靠问卷数据做一些重要决策，一想到换个问法就可能得到相当不同的结果，是有点吓人的。" 他补了一句冷幽默：市场研究这个领域有人读到博士学位，是有原因的。
  • 那问卷到底适合什么？ 适合关于被访者态度的简单问题，且他们手里有回答所需的信息——比如第 4 章那样用问卷量重要性与满意度；看人们对你的产品和品牌感觉如何；看客户如何相对于竞品感知你的产品。追踪型问卷（periodic tracking survey，定期问同一批问题）对识别随时间变化的趋势很有用。

• NPS（净推荐值）：基于单一问题——"你有多大可能把 X 推荐给朋友或同事？"0–10 分。9–10 分是推荐者（promoters），7–8 分是中立者（passives），0–6 分是贬损者（detractors）；NPS = 推荐者占比 − 贬损者占比，取值范围 −100 到 100。

  • NPS 是客户满意度的态度型度量，是 PMF 的一个代理指标——客户只会推荐让自己非常满意的产品。
  • 单次调研的平均分只是"有点用"，真正的价值来自定期调研、追踪 NPS 随时间的变化——PMF 改善时它应该上升，当然出问题时它也会下降。
  • 因为它衡量的是整体客户情绪，它能对产品之外的一大片区域（客服、支持）报警——这就是为什么问卷里一定要跟一个开放式问题："你为什么给这个分？" 你还可以把 NPS 与竞品分数、与品类基准做对比。

• Sean Ellis 的 PMF 问题（一条极实用的判据）：Sean Ellis 是"growth hacker"这个词的发明者、growthhackers.com 的运营者、客户洞察公司 Qualaroo 的 CEO。他和 Olsen 一样主张：在达成 PMF 之前不要投钱去做增长。

  • 问法：问你产品的用户——"如果你再也不能用 X 了，你会有什么感觉？" 四个选项：非常失望 / 有点失望 / 不失望（它其实没那么有用）/ 不适用——我已经不用 X 了。
  • 经验阈值：在很多产品上做过之后，Ellis 发现回答"非常失望"的用户占比达到 40% 或以上的产品，往往是有 PMF 的。这个阈值会因品类而有一些浮动，但作为通用经验法则很好用。
  • 执行细节（容易被忽略）：为了读数准确，Ellis 建议把问卷发给"至少用过你产品两次、并且最近用过"的客户的随机样本；并且同样要跟一个开放式追问："请帮我们理解你为什么选这个答案。"

• 分析与 A/B 测试之间的关系（一个很干净的例子）：假设你的落地页转化率只有 5%，远低于你认为的应有水平，于是你设计了新版；做可用性测试，反馈普遍正面，10 个人里有 9 个表示他们会点"注册"。

  • 但上线前你其实没法估计新设计的影响——真实转化率几乎不可能是 90%，那个值因为有主持人的可用性测试的性质而被人为抬高了。你可以预期转化率会涨，但光靠可用性测试结果很难量化涨多少。
  • A/B 测试让你把一部分流量导到新版、其余导到旧版并分别追踪，于是你能知道转化率的差值；流量够大时你还能以很高的置信度量化这个差值。
  • Olsen 的总结：分析对任何产品团队理解客户如何使用产品都至关重要。分析给不了全貌，你还需要定性研究才能认识客户；但没有分析你就是在盲飞。 化用 Drucker：你无法管理你没有度量的东西。 而 A/B 测试建立在分析之上，让你有把握地知道自己所做改动的影响，它提供了一个实验平台，是让精益团队快速创新的强大工具。
  • 补充：Rohrer 的完整框架还有第三个维度——使用情境：自然使用（如分析）、脚本化使用（如可用性测试）、不使用产品（如探索性访谈）。完整版归类了 20 种 UX 研究方法，在 Nielsen Norman Group 网站上。

• 分析框架：为什么需要一个"整体框架"。任何生意都有数不清的指标可追踪，正因为可以改进的指标太多，你非常需要一个覆盖整个生意的整体分析框架——它让你清楚各个指标之间怎么拼在一起，并帮你识别该聚焦在哪。

• 案例一 · Intuit 的分析框架（定性定量如何配合的绝佳示范）：Olsen 在 Intuit 上线一个新的 web 产品后，建了一个覆盖生意四要素的框架：获客（Acquisition，营销带来多少新访客）、转化（Conversion，来到网站的潜在客户里有多少注册成客户）、留存（Retention，客户随时间还有多少活跃）、收入（Revenue，客户产生多少钱）。

  • 发生了什么：上线后客户在注册、也在产生收入，PMF 感觉不错。但他们发现有转化问题——注册的潜客占比低于预期。他们的产品性质决定了注册流程有好几页长。
  • 量化找位置：用分析测出潜客在注册流程的每一个环节各流失多少。
  • 定性找原因：针对流失最严重的那几个环节做可用性测试，发现了若干 UX 设计问题。
  • 改进与结果：用这些洞察做了有针对性的快速 UX 改进，上线后转化率提升了 40%。
  • 最有意思的一句：因为他们已经对不同使用场景和可用性问题建了如此细致的模型、又有如此准确的指标数据，他们对改进幅度的预测误差在几个百分点以内。
  • Olsen 的定性/定量分工总结：定量是那把"冒烟的枪"——它告诉我们有转化问题、并指出人们在哪儿掉得最多，但它说不出为什么；定性给了我们理解并解决问题所需的洞察；改进上线后，定量又让我们看到改动的影响。

• 案例二 · Friendster 的病毒循环框架：两年后 Olsen 加入社交网络先驱 Friendster。公司一致认为最重要的指标是用户数——社交产品受益于网络效应，价值随用户数指数增长，而且当时社交网络还在早期、市场领导地位仍未定。

  • 增长用户最好的办法是让现有客户尽可能多地邀请非客户加入。如果平均每个客户产生的潜客里，最终转化成活跃客户的多于一个，你就有了病毒式增长。
  • "现有客户产生一个新客户"的详细步骤链条，叫你的病毒循环（viral loop）。
  • 他为病毒循环建了分析框架来优化病毒性：包含病毒式获客（不含非病毒获客）、包含转化（潜客要走完注册流程才成为客户）、也包含留存（因为只有活跃客户才会邀请朋友）；不含收入（单独追踪）。 完整案例在第 14 章。

• Dave McClure 的"海盗指标"（Startup Metrics for Pirates）：2007 年 Olsen 见到 Dave McClure（500 Startups 创始合伙人，自称"极客、营销人、投资人、博主、麻烦制造者"），发现他的框架和自己在 Intuit 与 Friendster 各自搭的那两套非常相似，但 Dave 把它讲得简单有效得多。

  • 两处术语差异（Olsen 特意点出）：
    • Dave 用"激活（activation）"而不是"转化"——激活是一个略宽的词，包含转化，但也包含"潜客与你的产品发生了某种互动、但还没成为客户"的其他情形。比如潜客没注册服务，但留了邮箱以接收产品新闻——这不算转化成正式客户，但可以作为激活指标来度量。
    • Dave 用"推荐（referral）"这个绝佳的统称，来描述现有客户采取的、导致新潜客得知你产品的一切动作。
  • 名字的来历：五个指标——acquisition、activation、retention、revenue、referral——首字母连起来是 "AARRR!"（海盗的吼声，还特意加了个感叹号）。
  • Dave 的建议：五个要素每个追踪两到三个关键指标。这是个好主意，因为比如你的转化漏斗其实不止一个总指标，你可以也应该追踪更细的指标。于是可以区分宏观指标（macro-metrics）与微观指标（micro-metrics）；为某个宏观指标找到最好的微观指标，就是 Olsen 所说的"剥分析这颗洋葱"。

• MTMM：最重要的那个指标（the Metric That Matters Most）：在你生意的任一时点，AARRR 五个宏观指标里总有一个比其他更重要。

  • 定义：MTMM 是"此时此刻"改进你生意 ROI 最高的那个指标——"此时此刻"是关键限定。当你在 MTMM 上取得显著进展之后，它就不再是 MTMM 了，因为另一个指标此时提供了更高的 ROI 机会。
  • 例子：上线后你发现开始注册流程的客户里只有 10% 走完，于是把注册转化率定为当下的 MTMM；做用户测试发现若干可用性问题，还发现表单在某个浏览器上不工作、查服务器日志发现偶发错误导致表单异常；团队全部修完后转化率涨到 90%——此时注册转化率就不再是 MTMM 了。
  • 背后的机制是边际收益递减：你刚开始优化一个指标时会迅速找到低垂的果实——不费多大力气就能带来大幅改进的点子；摘完之后，下一批机会的 ROI 就更低，并且随着你继续推进而持续下降。
  • 新产品通常有一个自然的优化顺序：MTMM 常常从留存开始，然后变成转化，再然后是获客。

• 为什么"先优化留存"：做新产品时你首先要达成 PMF。在你知道客户觉得产品有价值之前，砸大量资源去获客毫无道理，优化转化也没道理——不但对生意影响更小，而且会把宝贵的时间从当下最重要的事情上抢走。如果客户在你的产品里找到了价值，他们会继续用；否则他们不会。留存是与 PMF 关系最紧密的宏观指标，所以它通常是新产品的第一个 MTMM。

• 为什么"转化优先于获客"：一旦你用健康的留存率确认了强 PMF，你就知道进了前门并用了产品的客户里有足够高的比例会留下来。此时最合理的下一步是确保出现在你门口的潜客里尽可能高的比例真的走进来——转化成了 MTMM。为什么不先做获客？ 那意味着把更多潜客送到门口，但如果你的转化率低于应有水平，其中很多人根本不会成为客户；先优化转化，等你真去做获客时投资回报会高得多。

• 获客怎么做，以及一个改变顺序的例外：优化完留存与转化后，通常该聚焦获客——探索新的获客渠道、目标市场里的细分、话术、定价、促销等等，通常用一系列小样本实验来逐个测试新点子，某个点子被实验证明有效后再放大铺开。

  • 付费获客 vs 免费获客：付费获客要花钱买潜客（如在 Google 或 Facebook 投广告）；病毒营销是免费的——你的用户的行为把别人带来试用，而你没付钱给他们；自然搜索也是免费渠道。
  • 这个区分为什么重要：它决定了你该先做获客还是先做收入。 如果你的获客基本免费或很便宜，你可以优化获客、把收入分开来考虑，因为你不靠收入来给获客供血；反过来，如果你的生意依赖昂贵的付费获客，你可能该先优化收入再优化获客以降低风险——一旦你知道每个客户会产生多少收入，你就能更有底气地花钱去获取更多客户。

• "如果只能追踪一个指标来衡量 PMF，你选哪个？" Olsen 说他在演讲和工作坊里常问这题，得到的答案五花八门：有人说收入是终极衡量，有人说客户群增长率最重要。这两个确实可能是某个生意的 MTMM，但他刻意在问题里加了"来衡量你的 PMF"这个限定——答案是：留存率（retention rate）是衡量 PMF 的唯一最佳指标。

• 留存率怎么算，以及它独有的一个复杂性：留存率度量的是你的客户里有多大比例在活跃使用你的产品，用活跃客户数除以客户总数。它有一个别的指标没有的麻烦：不同客户是在不同日期开始使用你产品的，所以你不能像别的指标那样按日历日期来想留存。 对留存最直觉的做法是按"相对天数"聚合数据——数每个用户注册之后过了多少天。

• 留存曲线（retention curve）的三个特征参数（本章最重要的一张图）：纵轴是回访用户百分比，横轴是首次使用之后的天数（或周/月）。留存曲线永远从第 0 天的 100% 开始，随时间下降。第 1 天（注册次日）常有一次很陡的下跌，所以图上通常不画第 0 天、从第 1 天开始画，这样更好读。

  • ① 初始流失率（initial drop-off rate）：书里那条曲线第 1 天的值大约是 20%——意味着大约 80% 用过这个产品的客户再也没回来。不同品类的初始流失率差别很大；这条曲线是移动 App 的，这个品类初始流失率非常高。
    • 为什么？ 人们一直在装新 App、用一次；用完第一次之后往往不会再回去用，因为它不在脑子的显眼位置——图标埋在手机上一片图标的海里。除非有某种触发提醒用户想起这个 App 的存在，他们很可能就把它忘了。这就是为什么通知对移动 App 如此重要——用来对抗"眼不见、心不想"的问题。
  • ② 下降速率（rate of descent）：有的曲线掉得很快，有的慢慢下降。曲线要么一路奔向零，要么最终变平成一条水平渐近线。 奔向零意味着你最终会失去这一组里所有客户；在某个值上变平，那个值就是你最终留住的客户百分比。
  • ③ 终值（terminal value）：变平的那个值。一个产品可能在 5% 变平，另一个在 20%。
  • 三个参数都是 PMF 的直接度量：PMF 越强 → 初始流失越低、下降越慢、终值越高；PMF 越弱则反之。
  • 终值是三者中最重要的，因为它回答的是——"试过你产品的客户里，长期继续用的占多少？" Olsen 举了个很有力的例子：如果我告诉你产品 A 的终值是 1%、产品 B 是 50%，你不需要知道这两个产品的任何其他信息，就能说出哪个 PMF 更好（B）。
  • Olsen 的评价：PMF 看起来是个模糊、难以度量的概念，所以"留存曲线能给你可以用来度量 PMF 的硬数字"这件事非常棒。

• 为什么是留存率而不是"活跃用户数"（一段很漂亮的纯度论证）：留存率的另一个好处是它是 PMF 的纯粹度量，不与宏观指标框架里的其他成分（如获客）混杂。

  • 反例：假设你用活跃用户数来衡量 PMF，而它正在一路向右上方走——这只可能发生在你不断加新用户（靠获客与转化）的前提下。这条上升趋势可能来自"温和的新增 + 还不错的留存"，但同样可能来自"极高的新增 + 极差的留存"。只看活跃用户数，你分不出这两种情形。
  • 所以追踪用户数时必须区分新用户与回访用户。新用户是在某时间段内首次使用你产品的客户；回访用户是在该时间段内使用、但首次成为用户是在该时间段之前的客户。追踪回访用户很有价值，你当然希望这条曲线以尽可能大的斜率向右上方走。
  • 但要留意：与留存率不同，回访用户不是留存的纯粹度量，它与获客和转化混杂在一起。回访用户数代表"你在某个时点已经抓到并设法留住的客户总数"；而留存率因为算法的缘故，回答的是"在我抓到的客户里，此刻还有多大比例是活跃的"。

• 同期群分析（cohort analysis）：同期群 = 共享某个共同特征的一组用户（比如同一个月注册的）。同期群分析——对不同同期群的指标随时间做分析——是一个强大的工具。

  • 书中三条同期群曲线的比较题：A 初始流失最低、衰减最快、终值最低；C 初始流失最高、衰减最慢、终值最高；B 介于两者之间。Olsen 会选 C——因为它终值最高；从第 3 周起 C 的活跃用户比例就高于另两条，这转化成更多收入。
  • 一条实用提醒：同一张图上超过 5 条同期群曲线就很难读了，尤其因为同期群数据可能有噪声、曲线会互相交叉。
  • 标准数据格式：每一行是一个同期群，第二列是该群的初始用户数，后续每一列是"注册后第 N 个月的活跃用户数"；同期群越老，那条曲线的数据点越多。

• 看着你的 PMF 变好：如果你的 PMF 在随时间改善，你的同期群留存曲线会一条比一条往上走，越新的同期群终值越高。书中的理想图景是：A 群是 24 个月前 MVP 上线时注册的，B 群 18 个月前，C 群 12 个月前——每一条后来的曲线都比前一条初始流失更低、衰减更慢、终值更高。

• "你生意的方程式"（the equation of your business）——本章后半部的核心工具：AARRR 在高层面适用于所有生意、帮你在正确的时间盯正确的指标，但到某个点你必须把自己特定的商业模式纳入进来才能进一步优化。Olsen 说他给电商、订阅、广告各类客户做咨询时用的都是同一件工具：把你的生意写成一个方程式。

  • 他的方法论自述："当我想优化某样东西时，我的工程和数学训练让我的第一反应是把它表达成一个方程式。" 学校里无数次地把 Y 表达成 X 的函数、求让 Y 最大的 X；现实商业世界可以用类似的技巧。
  • 起点（对每个生意都成立）：利润 = 收入 − 成本。可套用于任意时间段（日/周/月）。收入和成本这两个指标太高层、不可行动，但这是个好起点——你要把高层指标层层拆成更细指标的公式，这就是"剥分析这颗洋葱"。
  • 为什么高科技公司几乎只盯收入不盯成本：因为多数高科技产品的经济学是——随着销量变大，每多卖一单位带来的边际收入超过多生产一单位的边际成本，而且销量越大这个差距越大。
    • Facebook 的例子：十亿以上用户，及时提供网站和 App 确实需要大量服务器、存储、网络硬件和带宽。但每来一个新用户，Facebook 需要额外开发软件吗？需要加一台服务器吗？不需要。 真正的增量资源只有一丁点存储和一丁点带宽——实质上，一个新 Facebook 用户的边际成本是零。 Facebook 主要靠广告赚钱，那个新用户会带来一点点增量广告收入；接近零的边际成本 + 少量边际收入 = 少量边际利润。
  • 第一层拆解（按"每用户"拆通常最好用）：收入 = 用户数 × 每用户平均收入（ARPU）——增加收入基本只有两条路：增加用户数，或增加 ARPU。

• 广告收入模型的完整拆解（Olsen 给的示范）：

  • 广告产品里看广告的人不必是注册用户（想想 YouTube 或纽约时报网站），所以用访客（visitors）这个词；考虑到网页分析的追踪机制，用 独立访客（unique visitors） 更清楚——某时间段内每个访客只算一次。
  • 展示广告按广告展示量（impressions）卖——"展示"只意味着广告被投放在某人访问的页面上，并不一定意味着访客真的看见了它。 广告价格以 CPM（每千次展示成本，M 是罗马数字 1000） 计价：一个 10 美元 CPM 的 10 万次展示广告活动总价是 1000 美元。CPM 是把不同类型广告放在同一标尺上比较的好办法，所以你常听到"有效 CPM（effective CPM）"这个统称。
  • 每访客平均收入 = 每访客展示数 × 有效 CPM ÷ 1000。有效 CPM 没法再往下拆了——它是一个对收入有等比例影响的细指标，你把有效 CPM 翻一倍，收入就翻一倍。
  • 每访客展示数 = (访问次数/访客) × (页面浏览量/访问) × (广告展示数/页面)。这三个指标每一个都是你能控制或试图影响的变量，其中任一个的变化都会带来收入的等比例变化。
    • 可行动的杠杆：勤更新内容或发邮件把访客引回来 → 提高访问频次；把文章拆到多页、或加相关文章链接 → 提高每次访问的页面数；每页塞更多广告 → 但 Olsen 立刻加了限定：到某个点它很可能会伤害用户体验，进而影响你的留存指标。
  • 访客数的拆解：区分新访客与回访访客。新访客可以按渠道/来源拆（免费 vs 付费，如自然搜索 vs 点击付费广告）；如果你的产品有病毒循环，可以把新用户拆成病毒获取与非病毒获取，还能进一步把病毒新用户拆成一组病毒循环指标。
  • 回访访客 = 上一期访客数 × 回访率（return rate）。Olsen 特意区分：这个"回访率"与前面讲的留存率略有不同，它的语境只是"期到期"（比如上月到本月），而不是访客的整个生命周期，所以叫 return rate 以免混淆。
  • 哪些是"测出来的"、哪些是"要去改的"：回访访客和访客数只是你测量的值，你不会直接去影响它们；回访率才是你要努力改进的变量（比如加一封每周或每月的邮件、放热门或推荐文章链接把访客引回来），回访率是从另外两个数算出来的。
  • Olsen 的收口："我们从一个非常高层的方程式开始，一路把各项拆下去，直到得到可行动的指标——这就是我说的剥洋葱。我们碰巧是为一个广告生意做的，但你可以为任何生意这么做。"

• 订阅收入模型的拆解（第二个示范，展示这工具多通用）：

  • 收入 = 付费用户数 × 每付费用户平均收入——用"付费用户"而不是"用户"，是为了照顾"不是所有用户都是付费订阅者"的事实（比如有 30 天免费试用，或有免费/付费两档的 freemium 模型）。此例假设不是 freemium，但有免费试用。
  • 本期付费用户 = 本期新增付费用户 + 本期续费付费用户，其中 续费付费用户(T) = 付费用户(T−1) × (1 − 取消率)。取消率（cancellation rate）是"上一期到本期取消的付费用户百分比"，是订阅生意极其重要、必须追踪并努力改进的指标。
  • 新增付费用户 = 免费试用用户 × 试用转化率 + 直接付费注册数——有些潜客一来就订阅付费方案（直接付费注册），另一些先注册免费试用；只有一定比例的免费试用用户会转成付费订阅，由试用转化率度量。
  • 还能继续拆：免费试用用户数可以按获客渠道拆；拆解里还应包含"潜客→免费试用用户"的转化率，用来度量你营销工作（落地页、邮件活动等）的有效性。
  • Olsen 的建议：你应该和团队坐下来，确定你自己生意的方程式。目标是识别出你想度量并努力改进的关键指标。方程式帮你理解每个指标变化多少会怎样影响整体结果，从而给改进排优先级。

• 走向盈利：换成"每客户"的视角：前面的方程式是按时间段的；另一种用法是忽略时间、按每个客户来看。

  • 每客户利润 = 每客户收入 − 每客户成本。Olsen 强调这个视角在你还在找 PMF 时不太相关，但在你已经达成 PMF、正在冲盈利时非常有价值。
  • 一个极有洞察力的重排：每客户利润 = 客户生命周期价值（LTV） − 客户获取成本（CAC）。
    • 与前面的例子不同（前面完全聚焦收入），冲盈利时你必须看成本，但你该聚焦一类特定的成本：与"获取一个能产生收入的客户"相关的成本。把这块成本单独拎出来做一个指标，你才能追踪并改进它。
    • LTV 是一个客户为你产生的利润，不计获取该客户的成本；CAC 是你平均花多少钱得到一个新客户。当 LTV 大于 CAC 时，每个新客户都在给你的生意产生利润。
  • LTV = ARPU × 平均客户生命周期 × 毛利率。ARPU 就是前面那个每用户平均收入（按时间段）——如果所有订阅者每月付你 10 美元，ARPU 就是每月 10 美元；平均客户生命周期是你的平均客户在你这儿待多少个时间段。若平均生命周期是 10 个月，平均生命周期收入就是 10 × 10 = 100 美元。毛利率是一个百分比，用来计入向客户提供产品或服务的成本；很多高科技公司毛利率超过 80%，因此为简化会忽略这一项。
    • Olsen 的实用主义限定：存在更复杂的 LTV 模型（用资本成本折现率对现金流做折现），但你不需要那份额外的复杂度——目标不是得到最精确的 LTV，而是把它拆成你能追踪并改进的可行动指标。
  • 平均客户生命周期 = 1 ÷ 流失率（churn rate）——如果你的月流失率是 5%，客户生命周期就是 20 个月。（churn 是比 cancellation 更宽的说法，涵盖客户不直接付钱给你的收入模型；也可以理解为"1 减去期到期的留存率"。）
  • 降低流失率的三条抓手：提供更好的客服与支持、改进产品质量与可靠性、确保产品持续满足客户需求。
  • 把生命周期换成流失率后，LTV 变得极清楚：撇开毛利率不谈，提升 LTV 只有两条路——提高 ARPU、降低流失率。 提高 ARPU 的办法包括涨价、向现有客户卖更多、增加更高价位的新产品。
  • CAC 的两种算法：便捷算法是 CAC = 某期销售与营销成本 ÷ 该期新增客户数——方便但不可行动。可行动的拆法是 CAC = CPA ÷ 潜客转化率。
    • CPA（每次获取成本）是平均每获得一个潜客要花多少钱。若你在 Google AdWords 上投广告、每次点击成本（CPC）1 美元，你的 CPA 就是 1 美元，因为每个点了广告的人都会到你网站。
    • 降低 CPA 的办法：找成本更低的营销项目与渠道、找 CPC 更低的关键词、买便宜的广告库存；对按展示计价的广告（如展示广告），提高广告本身的有效性（即提高点击率）也能降低 CPA。
    • 潜客转化率是到达你落地页或首页的潜客里转成客户的百分比。改进办法是为转化优化落地页——包括改进话术与 UX 设计，A/B 测试是干这个的好工具。
  • 经验红线：要产生利润你要让 LTV 超过 CAC，差额越大利润越大。 有些生意更喜欢看比值——成功的 SaaS 生意的通用指导是 LTV/CAC 比值应大于 3。

另一处对上的是你 2026-07-16 记的 Claude Code 团队的发布门槛：「一个功能必须达到一定的活跃用户数和留存率才能对外发布」（v69-dogfooding-retention-release-gate）。Olsen 这一章正是那条门槛的理论依据——留存率是 PMF 的唯一最佳单一指标、且是不与获客混杂的纯粹度量，所以拿它当发布闸门在方法论上是站得住的；而 Cat Wu 那条实践又反过来补了 Olsen 没写的一层：把留存从"上线后的度量"提前成"上线前的准入"。

第 14 章 · 用分析优化你的产品与生意

• 本章的立论（Olsen 少见地放了一句狠话）：第 13 章讲怎么定义并度量关键指标，本章讲怎么用它们驱动改进。活产品的好处是分析让你清楚看到自己所做改动的结果；有一套好的 A/B 测试框架，你就能轻松做实验、快速改进。"把这件事做好的公司相对竞争对手有优势。你当前生意的体量变得不那么重要了；取而代之的是，你能多快从客户身上学习并迭代，成了竞争的基础。速度是一种武器——在今天这个快节奏的世界里，大卫可以一夜之间掀翻歌利亚。"

• 精益产品分析流程（Lean Product Analytics Process，图 14.1）——本章的骨架：

  1. 定义你生意的关键指标（第 13 章的内容）。
  2. 度量各指标的基线值（baseline），好知道自己今天站在哪。Olsen 特意警告这一步"听上去相对不起眼，但很多公司恰恰栽在这里"：给产品埋点（instrumenting）是有工作量的；初次搭好之后，通常还要额外花力气确保你收集的指标数据是准确的、并且和你想追踪的东西对得上。 第三方分析包（Google Analytics、KISSmetrics、Mixpanel、Flurry）能让这件事容易些，但很多关键指标的数据常在你自己产品的数据库里，所以很多公司是"第三方包 + 自研分析代码"的组合。目标是拥有一组分析看板，让你一眼能看出每个指标随时间的表现。
  3. 评估每个指标的上行潜力——用 ROI 的镜头去看每一个指标。
  4. 选出改进机会最有希望的那个指标（MTMM）。图 14.1 里这一步正是"从全局视角切换到只盯 MTMM"的分界点。
  5. 为这个指标尽可能多地头脑风暴改进点子，并估计每个点子能把指标提升多少——当你这么做的时候，你就是在形成假设，比如"做一个移动端优化版的注册页，会把转化率从 20% 提到 30%"。同时估计每个点子的工作量，以便评估 ROI（第 6 章的方法），然后挑 ROI 最高的那个去做。
  6. 设计并实现这个改进。理想情况下用 A/B 测试框架把改进推给一部分用户，这样能同时拿到两组指标结果做比较。如果你没有 A/B 框架、而且要改的指标此前数值相对稳定，你也可以直接全量上线做前后对比；但 A/B 更好，因为它降低了"其他未知因素造成差异"的风险。
  7. 进入迭代循环：当然你希望目标指标变好，但即使没变好你也有进展——因为你获得了宝贵的学习，可以用来在后续迭代中形成更好的假设。 回到点子清单挑下一个最好的，重复右侧的循环。
  8. 退出与切换：试了几个点子后你应该会看到目标指标改善；继续迭代改进它，并会经历边际收益递减。到某个点，另一个指标提供了更大的改进机会——这时你跳回全局视角、识别下一个 MTMM，再对它跑这个改进循环。
  • Olsen 对这套机器的总结（很关键的一句）：一旦你把关键要素都装到位——分析框架、看板、A/B 测试平台、以及一个持续改进流程——限制因素就只剩下"你能多快识别并实现好的、有创意的点子扔进这台机器"。

• ROI 曲线的三种形态（图 14.2，这个比喻很好用）：Olsen 建议把每个指标想成汽车仪表盘或打气筒上的一个表盘，指针当前指的那个值就是基线值；你要评估"把指针拨动一格"有多容易或多难。 三条曲线（纵轴 = 指标值，越高越好；横轴 = 投入水平）：

  • 指标 A：位于 ROI 曲线的底部、斜率仍然很陡——用相对少的努力就能带来有意义的改进。这往往意味着你还没在这个指标上下过功夫。
  • 指标 B：位于 ROI 曲线的顶部、斜率已经变平——即使投入很多也只能换来很小的提升。这往往意味着你已经在它上面花了很多力气。
  • 指标 C = "银弹（silver bullet）"：多数指标呈现 A、B 那样典型的边际收益递减曲线，但有些机会只需一点点努力就能带来指标值的巨大改进。这些是特例——一个微小但深刻的改变，让你产品或生意的某个方面比以前运转得好得多。你通常是通过细致的分析才发现这类银弹机会的。

• 要小心"局部最大值（local maximum）"（本章第二个关键概念）：在改进一个指标的过程中，你可能到达一个"似乎再也提不动"的点。有时候确实是你已经把它最大化了；但有时候你只是卡在了一个局部最大值上，而只要考虑一个完全不同的替代方案或路径，其实还能继续提升。

  • 最好的例子：如果你有一个落地页，你可以 A/B 测试主行动按钮的不同颜色看哪个转化率最高——Google 就出了名地为一个工具栏测过 41 种蓝色的深浅，看哪个点击率最高。但如果你找到最佳颜色之后就不迭代了，你多半会卡在一个局部最大值上。 你还应该去试不同的话术、图片、页面布局等等，看能不能拿到更高的转化率。
  • Olsen 的定性收口："你的改进速度取决于你能多快识别并实现好点子。A/B 测试让做实验变得容易，但要测哪些假设得靠你自己想。要避免卡在局部最大值，你要确保自己在想改进点子时撒了一张足够大的网。"

• 本章最好的案例 · Friendster：一周把一个关键指标翻了一倍多。这是 Olsen 亲手做的真实案例，用来把整个分析流程演一遍。

  • 背景与判断：他加入 Friendster 任产品负责人时，病毒式获客的重要性是明摆着的。他们有庞大用户群、也有一些广告收入，但每用户平均收入太低，不足以支撑花钱买客户（大规模消费级生意常见的处境）。幸运的是他们不需要——病毒营销让他们免费获客。 因为网络效应，Friendster 这类社交产品的价值随活跃用户数指数增长，所以快速扩大用户群是成功的关键，而病毒营销是最好的办法。于是他把改进病毒式增长定为首要目标之一。"公司里每个人都是这个看法，但没有人真的度量过我们的病毒式增长表现如何。" 于是他从流程第一步开始：定义关键指标。
  • 第 1 步 · 定义关键指标（先画病毒循环，图 14.3）：他们本来在追踪新用户数，也能区分哪些新用户是被邀请来的。但"来自邀请的新用户"虽是他们在意的高层指标，却不可行动，所以他用生意方程式的技巧把它拆细。
    • 病毒循环的链条：从当前用户出发 → 但不是所有用户都会通过病毒营销产生新客户，注册用户数更大，可只有活跃用户会邀请朋友（不活跃的不会），所以他把活跃用户单独拆了出来 → 活跃用户在产品里给还没用 Friendster 的朋友（潜在用户）发邮件邀请 → 潜在用户收到邀请后，要么点邮件里的链接去注册、要么不点 → 点了的人进入注册流程，有人走完、有人没走完 → 走完注册的受邀者成为用户，可以继续变成活跃用户、重启循环。
    • 一个关键的方法论选择：他不想追踪"原子型"指标（比如活跃用户数），因为这些值会随用户基数大小而波动；他要的是"归一化"的比率型指标，好做跨时间的同口径比较。
    • 他找出的五个比率指标（合起来完整覆盖病毒循环）：
      1. 活跃用户占比 = 活跃用户数 ÷ 注册用户总数。
      2. 发出邀请的用户占比 = 发过邀请的用户数 ÷ 活跃用户数（因为不是所有用户都发邀请，这个指标把这个因素隔离出来）。
      3. 每个发送者平均发出的邀请数 = 邀请总数 ÷ 发过邀请的用户数（用户发邀请时可以只邀一个朋友，也可以一次邀好几个）。
      4. 邀请点击率 = 点了邮件链接的潜在用户数 ÷ 被发送邀请的潜在用户数。
      5. 注册转化率 = 完成注册的潜在用户数 ÷ 到达注册页的潜在用户数。
    • 病毒系数（viral coefficient）：这五个因子相乘就是这个循环的病毒系数。系数大于 1 时你的产品才算正式"病毒式"——每个当前用户产生多于一个新用户，导致指数增长，像核反应堆超临界一样。
      • Olsen 的诚实限定（很重要）：产品不会长期保持病毒式（如果会，所有能上网的人都会成为用户）；当一个病毒式产品达到高市场渗透率，剩下可加入的潜在用户就没那么多了——Facebook 就处在这个令人羡慕的位置。
      • 但话说回来：一个小于 1 但仍然很高的病毒系数——比如 0.4——一点也不该被轻视：那意味着你每个时间段靠病毒营销免费把用户群增长 40%。
  • 第 2 步 · 度量基线值：当年没有今天这样的第三方分析包，他们自己写代码来追踪和计算这些指标——先捕获每个原子指标（注册用户、活跃用户、邮件点击等），再从原子指标算出五个比率指标。为讲述简洁，案例只用其中三个及其基线值：
    • 发出邀请的用户占比 = 15%
    • 每个发送者平均发出的邀请数 = 2.3
    • 注册转化率 = 85%
  • 第 3 步 · 评估各指标的 ROI 潜力——"上行潜力（upside potential）"这个 hack（本案例最值钱的一招）：Olsen 在这里直接把问题抛给读者："换你站在我的位置，这三个指标你先改哪个？怎么决定？"
    • 困境：你没有关于各指标可能有哪些改进点子的具体信息，因此很难用 ROI 视角估计每个指标现实中能提升多少。
    • 他的 hack：在信息不多时，看一个指标的"上行潜力"——即最大可能的改进幅度是多少。你用它的当前基线值和它理论上的最大可能值来估算。
    • 注册转化率：是百分比，范围 0–100%，当前 85%。无论怎么改，最多只能再涨 15 个百分点。 表达成百分比就是 15% ÷ 85% = 18%——上行潜力 18%。
    • 发出邀请的用户占比：范围也是 0–100%，当前 15%，理论上最多能涨 85 个百分点。85% ÷ 15% = 570%——明显比注册转化率大得多。
    • 每个发送者平均发出的邀请数：这个不是百分比，最小值 0，当前 2.3。最大可能值是多少？一时还真不好说，但为了算上行潜力必须至少有个估计。 会是无穷大吗？不会——世界上的人数是有限的。每个用户最多能邀请他所有的朋友，所以最大值就是一个 Friendster 用户平均有多少朋友。 那是多少？他不确切知道，但他认为 100 到 200 是个合理的估计区间。
      • 邓巴数（Dunbar's number）：1990 年代心理学家 Robin Dunbar 研究"一个人能维持稳定社会关系的人数上限"，结论是 150——正好落在他估计区间的中点。
      • 用 150 算：150 ÷ 2.3 = 6520% 的上行潜力。即使用更保守的 100，这个指标的上行潜力也远远超过另外两个。
    • 一个漂亮的呼应：Olsen 提醒读者回头看图 14.2 的三条 ROI 曲线——"发出邀请的用户占比"像指标 A（ROI 不错）；"注册转化率"像指标 B（ROI 很差）；"每个发送者平均发出的邀请数"可能像指标 C（银弹）——"我们要等到看见能把指针拨动多少、以及要花多少力气，才能确定。"
  • 第 4 步 · 选定要改的指标（他给了两条理由，第二条尤其值得学）：他选了每个发送者平均发出的邀请数。
    • 理由一：主要是因为它的上行潜力大得多。
    • 理由二（更微妙）：改进它不一定需要改变人的行为。已经有 15% 的用户在发邀请了，我们只是要让他们发得更多。 相比之下，试图提高"邀请朋友的用户占比"需要行为改变——不管出于什么原因，另外 85% 的用户在我们已尽最大努力的情况下仍然选择了不邀请朋友，很难想象我们能把那根指针拨动多少。
    • 理由三：他知道当时"邀请朋友"的用户体验需要太多手工操作，并且有信心能把这个体验改得更容易。
  • 第 5–6 步 · 指标优化循环与那个"最小可行"的实现决策：他和团队头脑风暴改进点子，逐个讨论"能把指标提多少 + 要花多少力气"，结论是 ROI 最高的点子是"通讯录导入器（address book importer）"。
    • 时代背景：通讯录导入器今天司空见惯，但当时还不是。 他们很多用户把朋友的邮箱存在 Gmail、Yahoo! Mail 之类的邮箱通讯录里；导入器让用户输入邮箱网站的凭据，把朋友的联系信息导进 Friendster，然后展示导入的联系人列表、让用户勾选想邀请的人。
    • 技术上的分块决策（回扣第 6 章的"功能分块"）：跨各家邮件服务商可以复用一部分初始开发工作，但每一家仍需要一定量的单独工作。 于是他意识到应该把这个功能拆成更小的块，每家邮件服务商一块。
    • 他做的选择：为了用最少的力气检验假设，他决定只做一个"只支持一家邮件服务的 MVP 版通讯录导入器"。分析用户信息后发现 Yahoo! Mail 是他们用户中最流行的邮箱服务，所以那一块 ROI 最高。
    • 成本：设计加实现大约花了一个产品经理和一个开发一周的时间。
  • 第 7 步 · 结果：真的是银弹（图 14.6）：
    • 读图的方法（一个实用细节）：和很多网站一样他们的使用有季节性，很多指标在工作日和周末之间波动很大，所以他们对多数指标追踪"七日均值"以便看清趋势——图上每天的数据点其实是过去七天的均值。
    • 数据：上线前有一个多月的基线数据，指标值相当稳定，在 2.2 到 2.4 之间。 曲线从平滑水平线开始向右上方蹿升的位置，正对应改进上线的日期。因为画的是七日均值，图表要过几天才追上新的平均值。 新值每天继续增长，最后稳定在 5.3 左右。"我欣喜若狂！"
    • 量级：5.3 ÷ 2.3 = 2.3 倍——一周的工作量把这个关键指标翻了一倍多。
    • 翻译回生意：回到生意方程式，这个指标 2.3 倍的改进直接翻译成"我们从病毒式增长中获取的新客户数量"的 2.3 倍改进。
    • 而且：他们当时只为一家邮件服务商做了导入器。 有了这份清晰的、验证了假设的定量证据，他们接着完成了增加其他邮件服务商的增量工作，又带来了这个关键指标的进一步收益。
    • 退出：他们又继续改进这个指标一段时间，直到把能识别出的高 ROI 改进点子全部用尽；那时就退出这个指标的改进循环，把焦点切换到病毒循环里另一个 ROI 更高的指标。
    • Olsen 的收口（和第 11 章末尾同一句调门）："就像第 11 章的 MarketingReport.com 案例一样，我并没有做任何非凡的事；我只是遵循了本书描述的流程和原则。"

• A/B 测试的实操要点：

  • 统计显著性（statistical significance）：由表现差异的大小和样本量共同决定。有在线工具帮你算置信水平，所以你不必知道公式，但必须知道：差异越大、样本量越大，显著性越高。样本量太小就拿不到统计显著的结果；如果两个方案表现非常接近，可能需要极大的样本量才能分辨出统计上显著的差异。
  • 工具：Optimizely、Unbounce、KISSmetrics、Visual Website Optimizer、Google Content Experiments（Google Analytics 的一部分）等；很多公司也选择自建 A/B 平台。这些工具让你指定一个或多个变体、把流量随机分配，并追踪你在意的指标、给出基于样本量的统计置信度。
  • 节流发布（throttling）——一个很值得抄的发布纪律：很多公司把 A/B 测试并进了产品发布流程，尤其在做重大改动时。不是从旧版瞬间切到新版，而是让绝大多数用户继续用旧版，把新版"发布"给一小部分用户；然后比较新旧版本的关键指标。在扩大新版用户比例之前，产品团队要确认：目标改进的指标确实表现更好，而且其他关键指标没有实质性变差。 Olsen 的定性：这是"在你上线产品之后应用精益原则来降低风险"的极好办法。 如果指标看起来不错，最终 100% 用户切到新版，旧版退场。
  • Netflix 的例子：Netflix 以在营销和产品两端都做扎实的 A/B 测试闻名。被问到"除了会员注册，Netflix 还 A/B 测试什么类型的东西"时，其首席产品官 Neil Hunt 的短答案是"几乎一切"——界面变体、推荐算法、按钮位置与大小、页面加载时间、视频流编码的质量档位。Hunt 的收尾很值得记：他们为这种实证取向感到自豪，因为它让他们保持谦卑——他们意识到大多数时候，他们事先并不知道客户想要什么；测试的反馈能迅速纠正他们，帮助确保努力真正用在能改善客户体验的地方。

• "A/B 测试是不是就够了？"（本章、也是全书方法论上最重要的一次收口）：

  • 先承认它的强：A/B 测试是终极的证据驱动产品决策工具——数据来自大量用户的真实世界行为，所以不存在"用户说的"和"用户做的"之间脱节的风险；你也不在他们身边，所以没有你干扰结果的风险。
  • 但："一个产品团队不能只靠定量活着——别忘了 Oprah。" 总会有些时候，你需要用定性学习去补上行为背后的"为什么"。
  • 最危险的诱惑：有些人可能会想跳过所有定性测试与学习，直接上线一个 MVP 候选、试图用 A/B 测试"测"出 PMF。Olsen 的判断非常直白：那种做法几乎肯定会浪费资源并失败。在那种情形下，A/B 测试极可能把你引向一个较差的局部最大值，让你离 PMF 还很远。
  • 他给出的机制解释（全书最好的一个比喻，图 14.7 回到 PMF 金字塔）：你在某一层做的假设会影响它上面的所有层。UX 是最容易改的一层；功能集也能改，但要更多力气。而 PMF 的那些基础要素——你的目标客户、他们未被满足的收益、你的价值主张——一旦你已经把产品造出来，就很难改了。
    • "一旦你锁定了这几层的假设，它们就像一组互相咬合的板块。如果你在已经把产品造出来之后去移动其中一块，你造的产品有很大一部分就不再相关了——像一场地震把一栋楼变成瓦砾。"
    • 然后是人性那一刀：当这种事发生时，人的天性会让你想尽量抢救和复用自己已有的工作。但这么做会给你的解决方案空间加上沉重的约束——而当你正在改变问题空间的假设时，这是次优的。你更该做的是在新的地基上从头再造。
  • 为什么精益产品流程是那个顺序：它让你按"最能降低风险、最能提高达成 PMF 几率"的顺序来验证关键假设。问题空间不像解决方案空间那样适合 A/B 测试——PMF 金字塔下面三层需要定性研究，你才能创建、检验并改进这些假设。
  • 一句话总纲：上线之后存在一个从"更多定性学习"到"更多定量学习"的自然演进。一言以蔽之——定性帮你定义产品，定量帮你优化产品。要做出成功的产品，Oprah 和 Spock 你都需要。

能直接搬的两处：① 一人公司 / onehuman_company 的选题排序——你现在的痛点是"C/D 类选题供血不足、产能账三选一没答"，用上行潜力排序意味着别再优化已经 85 分的那件事（比如再打磨已经不错的封面模板），去动那个 15 分的（比如"验证体"存稿数从 1 篇到 4 篇，上行潜力 300%）。② Friendster 那条"理由二"对你更狠：优先选不需要改变人的行为的指标。你两个号最难的部分恰恰都是要改别人的行为（让读者关注、让读者留言）；而"让已经在做某事的人多做一点"（已看完的人多看一篇、已收藏的人再收藏一篇）成本低得多——这条选择原则比上行潜力本身更值钱，因为它是在告诉你上行潜力大但要靠行为改变实现的指标，其实是个陷阱。

第 15 章 · 结语与十条最佳实践

• Olsen 自己给全书做的一次收束（这段是全书最好的"一页复述"）：

  • 他的目标是帮你做出客户喜爱的产品。一切从 PMF 金字塔开始——一个可行动的模型，定义了 PMF 由哪些部件构成、以及它们如何连接。你的市场由目标客户和他们的需求构成；你的产品是价值主张、功能集和用户体验的组合。当你试图达成 PMF 时，你在这五层的每一层都做了关键假设。
  • 精益产品流程引导你形成并检验这些假设，六步是：① 确定目标客户 ② 找出未被满足的客户需求 ③ 定义价值主张 ④ 确定 MVP 功能集 ⑤ 做出 MVP 原型 ⑥ 拿客户测试 MVP。
  • 流程从问题空间开始、推进到解决方案空间：先用人物画像描述目标客户；用重要性 vs 满意度框架找出他们重要但未被满足的需求，以创造最大客户价值；用 Kano 模型定义一个差异化的价值主张，更好地满足这些需求；然后采取 MVP 取径，识别出交付价值主张关键部分所需的最小功能集合；再运用优秀 UX 设计的原则把 MVP 功能集变成一个可用且令人愉悦的原型。
  • 评估 PMF 的方式：拿目标客户测试 MVP 候选——他们在解决方案空间能给你比在问题空间更好的反馈；为省资源、快迭代，理想情况下你在真正构建产品之前，先用可点击/可轻触的视觉稿这类设计物来测。用学到的东西修订假设与 MVP 候选，继续在"假设-设计-测试-学习"环里迭代，做更多轮用户测试，希望达到越来越高的 PMF 水平。测试过程中你可能决定转向一个更有希望的机会——办法是改变一条或多条根本假设。
  • 验证 PMF 之后：该造 MVP 了。为降低风险、更快交付客户价值，你应该用敏捷开发以增量、迭代的方式构建产品；QA 与测试驱动开发帮你达到更高的产品质量；持续集成与持续部署帮你提升开发流程的速度。
  • 上线之后：用分析理解客户如何使用产品。留存率给你 PMF 的定量度量，同期群分析让你看到它随时间怎么变。留存好了之后，再去改进 AARRR 框架里的其他宏观指标。定义你生意的方程式帮你识别属于你这门生意的关键指标，而精益产品分析流程提供了一套系统化的优化办法，最终带来更高的收入与利润。

• 十条最佳实践（本章的落点，逐条抄录要义）：

  1. 有观点，但保持开放（Have a point of view but stay open-minded）。"造产品不是心脏脆弱的人干的活"——你不断要在不确定条件下做决策，所以必须有观点、要果断。但同时，你要识别出不确定性和风险最大的地方并想办法去测；测的时候要避免锚定在你最初的观点上，而要客观、以证据为准。以开放的心态倾听，你才能获得最多的学习，并用它来修订和改进自己的思考。
  2. 把你的假设讲清楚（Articulate your hypotheses）。"看待一个产品的一个有意思的角度，是把它视为'导致它成为今天这个样子的全部假设的集合'。" 你应该尽可能明确地表述自己在做的假设，把假设写下来极有帮助。他引 Hyman G. Rickover 上将（美国"核动力海军之父"，也正是 Olsen 早年所在 Naval Reactors 的塑造者）："没有什么比写下自己的论证更能磨利思考过程。" 你的队友也该这么做，并且你应该让团队的假设透明化——把它们贴在每个人都能看到的地方、公开讨论，它们只会变得更好。
  3. 无情地排优先级（Prioritize ruthlessly）。造产品时争夺资源的点子很多，取舍不可避免。对优先级含糊其辞通常导致低效和优柔寡断，所以他建议给 backlog 和所有待办清单做严格的排序（rank order）——清楚地标出什么最重要，帮助你把宝贵的资源和时间花在明智的地方。 引 Drucker："时间是最稀缺的资源；除非它被管理，否则其他什么都管理不了。"
  4. 把范围保持得小而聚焦（Keep your scope small but focused）。与排优先级相关的是刻意把范围做小。如第 6 章所述，更小的批量促进聚焦、完成得更快，从而带来更快的客户反馈。小心别咬下超过完成目标所需的量。 但这不意味着你该完全回避大任务——只是你该试着把它们拆成更小的项，以降低风险、更快迭代。
  5. 和客户对话（Talk to customers）。"你的客户是 PMF 的裁判"，他们帮你获得达成 PMF 所需的学习。越早、越频繁地和客户对话越好。 值得投入力气去建立那些让用户测试更容易排期和执行的系统，好让你随时间和更多用户对话。 别让距离上一次用户测试的时间过得太久——客户永远会用意料之外的学习给你惊喜。（呼应第 9 章的"盲排期"。）
  6. 先测试，再构建（Test before you build）。很多团队还没检验任何假设就急着造产品，但在验证 PMF 之前构建几乎肯定浪费资源。用设计物迭代比用真实产品迭代更快、成本更低。 而且——一旦团队造出了产品，他们会自然而然地对它产生感情，这会让他们变得不那么开放、不那么愿意做重大改动。
  7. 避免局部最大值（Avoid a local maximum）。局部最大值意味着你在自己考虑过的选项范围内已经拿到了最好的结果，但在那些选项之外还存在你没考虑过的更好的替代方案。 你怎么知道自己陷进去了？当你无法再推动 PMF 或关键指标的进一步改进时。 此时你需要换一个全新的视角才能继续前进——把当下的思考提升到更高的层次，用发散思维想出值得探索的新点子。
  8. 试用有前景的工具和技术（Try out promising tools and techniques）。团队成员往往只用自己以前用过的工具和方法，有些产品团队在这方面相当封闭，抱着已知的不放而不去寻找可能更好的方案。 相比之下，很多团队会在足够多的人认为某个新东西优于现状之后主动去调研它。你不需要追着最新潮流不停换，但和别人交流笔记、在这方面保持相对跟得上是有价值的；当某个有前景的新想法可能显著改进团队的工作方式时，你应该给它一次机会。
  9. 确保团队有对的技能（Ensure your team has the right skills）。从本书涵盖的话题之广就能看出，做出成功产品需要的技能范围很宽。 对软件产品来说这份清单包括：产品管理、用户研究、交互设计、视觉设计、文案、敏捷开发、前端、后端、QA、DevOps、分析。 不同团队在每项技能上的水平各不相同。你应该评估团队强在哪、弱在哪，识别出在你的处境下哪些技能的提升最能带来差别，并据此补强团队（招人、外包、顾问或培训）。
  10. 培育团队协作（Cultivate your team's collaboration）。"我喜欢说，造产品是一项团队运动。" 他用篮球队打比方：五个人各有角色，要协调传球才能得分。产品团队做一个新功能就像篮球队打进一球——产品经理写用户故事、排 backlog，把球运过半场；传给交互设计师，设计流程与线框；再传给视觉设计师，做出高保真视觉稿的观感；再传给开发，开发按用户故事和视觉稿实现产品，投篮得分。
      • 他的落点：光有强的个人技能不构成伟大的产品团队。团队成员必须各自理解自己的角色、别人的角色，以及团队如何协同达成目标。 你应该偶尔从工作中抽身，讨论一下"我们作为一个团队是怎么工作的、可以怎么做得更好"。在一个配合良好的团队里工作是件快乐的事，而强协作提升你造出成功产品的几率。

• 一处值得记的自述：致谢里 Olsen 提到自己在 Naval Reactors（美国海军核动力项目）学到的是"如何与跨职能团队一起设计并构建高度复杂的产品"，并称它是"一个为严谨思考设定了高标准的、独一无二的组织"——这解释了全书那种"什么都要能写成方程式和矩阵"的气质从哪来。他也在斯坦福商学院读过两年、在 Intuit 工作、后来创办 YourVersion 当过一次首次创业的 CEO。第 15 章那句"造产品不是心脏脆弱的人干的活"，配上"作为一个首次担任 CEO 的人，我从你们和我们共同的经历中学到了很多"，是全书为数不多能看到作者本人挫折的地方。

• 贯穿的元原则："如果你没有显式地做这些假设和决策，那你就是在隐式地做。" 六步的本质是一张逼你把脑子里的假设写到纸上的检查清单——写下来之后随时可以改，但不写就是把关键要素交给运气。

1. 列需求（在问题空间里列，不要列功能）。
2. 对每条需求，让目标客户打两个分：重要性（这件事对你多重要）与满意度（现有方案满足得多好）。
3. 画四象限，锁定左上角（高重要 + 低满意）。
4. 算三笔账：
   • 当前价值 = 重要性 × 满意度（市场现在被吃掉了多少）
   • 增值机会 = 重要性 × (1 − 满意度)（还剩多少可吃——这是你要排序的那个数）
   • 改进创造的价值 = 重要性 × (满意度后 − 满意度前)（你这次改动到底值多少——用来做事后复盘）
5. 两条校准：满意度刻度会被颠覆式创新整体左移（所以别拿五年前的满意度数据做决策）；重要性刻度相对稳定（所以它是更可靠的锚）。
6. 别忘了向下看：做新功能时要注意需求层次下方的层——如果产品当前可用性高、速度快、无 bug，新功能引入 bug 或拖慢性能就是在损害下层，必要时应主动"向下延伸"去修低层缺陷。

• 选型的唯一问题不是"这算不算 MVP"，而是"我此刻最需要学到什么"。
• 顺序纪律：先定性再定量。 直接冲定量通常效果差，而且即使效果好你也不知道为什么。产品团队常见的健康节奏是定性轮次与定量轮次交替。
• 保真度纪律：用刚好够检验这条假设的最低保真度——改设计稿远比改代码便宜，而且团队一旦把产品造出来就会对它产生感情，从而变得不愿大改。

• 招募：用筛选问卷按人物画像严格筛人（第 11 章 Olsen 把这条列为四条成功要因之一——"对目标客户保持严谨，让我们招到了能给出优秀反馈的客户"）。
• 排期：盲排期——固定每周某个下午排 5 个人，别等原型做好才开始约。
• 人数：一次一人；每波 5–8 人（第 11 章实际每个概念排 9 人、放鸽子 2 人、实到 8 人）。
• 开场：讲清"请说真话，不会伤谁的心"。
• 提问：开放式（why / how / what），不要把答案塞进问题里。
• 卡住时别帮——你上线后没法握着每个人的手。
• 先跑一次试点：第 11 章 Olsen 先和公司里的一个人跑了一次试点测试来检验脚本和视觉稿，据此调整问题与稿件，然后才正式开始。这一条极便宜，却几乎没人做。
• 一份可抄的 90 分钟脚本骨架（第 11 章原样）：介绍暖场 5′ → 通用探索性问题 15′ → 概念专属问题（相关探索 10′ + 对视觉稿的反馈 35′）→ 回顾"最喜欢/最不喜欢什么"5′ → 头脑风暴"什么能让它更有用"10′ → 对产品名的反馈 10′ → 致谢告别。
• 收口的可视化手法（强烈推荐）：测完之后，把你那张问题空间/解决方案空间地图上的每个方框涂成绿/黄/红（吸引力强/一般/低）。第 11 章 Olsen 正是这么看出了"两座分开的绿色孤岛"，从而让转向方向变得一目了然。
• 关键提醒：可用性好 ≠ 有 PMF。Olsen 亲历过用户一路顺畅通关、问"你会用吗"仍有 20% 说不会的情形。必须单独问"你觉得这个产品有多值"。
• 一个免费的强信号：第 11 章第二波测试结束、付完报酬之后，每一位客户都主动问服务上线没有、能不能注册，并留下邮箱要求上线通知；第一波一个人都没有。 Olsen 把这种发生在测试范围之外的真诚兴趣当作 PMF 的证据——这类"计划外行为"往往比问卷分数更可信。

• 一轮迭代要看三样进步：① 正面反馈比例上升 ② 上一波的负面反馈消失（进步靠"沉默"来衡量）③ 价值与易用性评分上升。
• 爬山比喻：连续几波爬不动 → 先换路径（改解决方案）；还爬不动 → 考虑换一座山（改问题空间假设，即转向）。
• 转向的量级判据：转向 = 改一条主假设，不是改 UX。第 11 章那次转向放弃的是整个产品最初的核心价值主张（连同那个从零发明的"营销分"）。
• 一份可抄的转向决策账（第 11 章原样结构）：逐条列"对 A 不利的理由"与"对 B 有利的理由"，每条都指向一个具体维度——差异化是否清晰、客户付费意愿、落地所需的工作量、与公司品牌的契合度。
• 诚实闸门：Olsen 在写"吸引力强"时立刻加限定——"这距离十拿九稳还很远"；在写付费意愿时也加了保留——在客户必须用钱包投票之前，你并不真正知道他们愿意付多少。 拆书稿里保留这些限定，比抄走结论更有价值。

① 定义关键指标  →  ② 度量基线值  →  ③ 评估各指标上行潜力/ROI  →  ④ 选出 MTMM
                                                                        ↓
   （MTMM 榨干后跳回 ③）  ←  ⑦ 看指标怎么变  ←  ⑥ 设计并实现（尽量 A/B）  ←  ⑤ 头脑风暴点子+估提升与工作量，挑 ROI 最高

• 第 ② 步是最多公司栽跟头的地方：埋点有工作量，搭好之后还要额外花力气确认数据准确、且和你想追踪的东西对得上。
• 第 ③ 步的两把尺：ROI 曲线位置（A 在陡峭段=好机会；B 在平坦段=别碰；C=银弹）+ 上行潜力 hack（信息不足时用 (最大值−当前值)÷当前值）。
• 第 ④ 步的隐藏判据（Friendster 案例里最值钱的一条）：优先选"不需要改变人的行为"就能改进的指标——让已经在做某事的人多做一点，比让不做的人开始做，容易得多。
• 第 ⑤ 步：估提升时你就是在写假设（"做 X 会把转化率从 20% 提到 30%"），同时估工作量才能算 ROI。
• 第 ⑦ 步的心态：指标没提升你也有进展——你拿到了能形成更好假设的学习。
• 全程要防的：局部最大值。判据是"再也推不动"，解法是把思考提到更高层次、撒更大的网。

利润 = 收入 − 成本
  └ 收入 = 用户数 × ARPU
      ├─【广告模型】
      │    每访客平均收入 = 每访客展示数 × 有效CPM ÷ 1000
      │    每访客展示数   = (访问/访客) × (页面浏览/访问) × (广告展示/页面)
      │    访客 = 新访客(按渠道拆：免费/付费/病毒) + 回访访客
      │    回访访客(T) = 访客(T−1) × 回访率
      └─【订阅模型】
           收入 = 付费用户 × 每付费用户平均收入
           付费用户(T) = 新增付费用户 + 付费用户(T−1) × (1 − 取消率)
           新增付费用户 = 免费试用用户 × 试用转化率 + 直接付费注册

【每客户视角 · 冲盈利时用】
利润/客户 = LTV − CAC
   LTV = ARPU × 平均客户生命周期 × 毛利率
       平均客户生命周期 = 1 ÷ 流失率
   CAC = CPA ÷ 潜客转化率
   经验红线：LTV / CAC > 3（SaaS）

• 用法：和团队坐下来把属于你这门生意的方程式写出来，目标是识别你要度量并改进的关键指标；方程式告诉你每个指标变化多少会怎样影响整体结果，从而给改进排优先级。
• 区分"测出来的"与"要去改的"：像"回访访客数"这种是你测量的值，回访率才是你去改进的变量。别在不可行动的指标上开会。

• "问题空间 vs 解决方案空间"这条纪律，是全书最抗时间的东西。 它不依赖任何工具、任何平台、任何组织形态，只依赖一个提问习惯：我现在讨论的是问题还是方案？我是不是被现有方案框住了？ 太空笔那个故事之所以好用，是因为它把"把需求窄化成一件具体产品"的失败方式一次讲清。AI 时代这条反而更值钱——当造东西的成本趋近于零，"造错东西"的相对代价就变成了几乎全部的代价。
• PMF 金字塔作为"诊断梯"，而不是作为"漂亮的图"。它真正的价值在那条使用规则：出了问题要从底往上排查，因为下层假设错了，上层怎么改都是白改。 大多数团队卡住时的本能是改 UX（最上层、最容易改），而金字塔告诉你这恰恰是最可能白费的动作。这条直接可用作复盘时的提问顺序。
• 改动代价的层级 + 第 14 章的"板块/地震"比喻，是"测试先于构建"最硬的论证。它不诉诸"精益很时髦"，而是给出机制：你改了下层，上面已造的东西就作废；而人性会让你舍不得丢，于是你把废料当约束继续用，结果更差。 这比"MVP 要小"这类口号有用得多。
• 重要性 × 满意度 + 三条公式依然是把"这个需求值不值得做"变成可算的面积题的最好工具之一。关键不在公式本身，而在它显式地把"客户的主观评价"作为变量——比"价值/成本矩阵"精确，因为后者的"价值"往往是团队自己拍的。
• 留存率是 PMF 的唯一最佳单一指标 + 那段"纯度"论证。"一条向右上方的活跃用户曲线，可能来自温和新增+不错留存，也可能来自极高新增+极差留存，只看它你分不出来"——这是全书最锋利的一段量化推理，十年后在增长圈里仍然是常识的源头之一。
• "定性帮你定义产品，定量帮你优化产品"这一句，加上"A/B 测试只擅长解决方案空间、金字塔下三层测不出来"的机制解释，至今仍在纠正大量团队的实际错误（用实验平台代替判断）。
• 十条最佳实践里的第 2 条（把假设写下来）和第 7 条（避免局部最大值）是可以直接贴在墙上的。前者的价值在"写"这个动作本身——"如果你没有显式地做这些假设，那你就是在隐式地做" 是全书复用率最高的一句。

• 全书的案例几乎全是 C 端：Quicken（消费级财务软件）、Intuit 的 web 产品、Friendster（社交网络）、MarketingReport.com / JunkmailFreeze（消费级邮件服务）、移动 App 的留存曲线、展示广告的 CPM 模型、Netflix、Google 的 41 种蓝色。书里最完整的两个端到端案例（第 11 章、第 14 章）都是纯 C 端。
• Olsen 本人是声明过适用范围的——他在导言里明说本书的指导"也适用于包括 B2C 和 B2B 在内的广泛商业情境"，并且在第 3 章专门写了一节 "用户 vs 买方（Users versus Buyers）"：B2B 里用你产品的人（用户）常常不是做采购决定的人（买方）；他区分了经济买方（economic buyer，控预算、签支票的那个人）与其他利益相关者（CFO、事业部总经理、法务总监、首席安全官等），并指出其他人往往是潜在的"阻挡者（blockers）"，有能力因为某项未被满足的要求而否决你的产品；他还建议在目标客户之外另外定义"目标买方"。
• 留存与单元经济学一章的 B2C 味道同样重：留存曲线的示例是移动 App（"图标埋在一片图标的海里"、靠推送对抗"眼不见心不想"）；广告模型拆得极细而企业销售的漏斗一句没提（没有 SQL/MQL、没有销售周期、没有客单价分层、没有 KA 与 SME 的分野）。唯一给 B2B 留的锚是那条 LTV/CAC > 3。
• 实用结论：把这本书当作"C 端方法论 + B2B 需自行补齐的适配层"来读。 它的问题空间纪律（前 11 章）是跨形态通用的；它的执行细节（招募节奏、样本量、留存曲线形状、渠道拆解）要按 B2B 重写。

• 所有主要案例都是 n = 1，且全部来自作者本人的职业经历或转述。 Quicken（Intuit 内部流传的故事）、Intuit 的转化率提升 40%、Friendster 的病毒指标翻 2.3 倍、MarketingReport.com 的两个月项目——没有一个有对照组，也没有一个是可独立复核的公开数据。 这不是本书特有的毛病（几乎所有产品方法论书都是如此），但读者要知道它们的功能是"演示方法怎么用"，不是"证明方法有效"。
• 最锋利的一处，是 Friendster 这个案例的选择本身。 Olsen 用它演示分析流程如何"一周把关键指标翻一倍多"——这是真的，也确实漂亮。但Friendster 这家公司最终输给了 MySpace 和 Facebook。书里从头到尾没有触碰这个事实。讽刺的是，这恰恰是 Olsen 自己第 14 章那段论证的完美注脚：A/B 与指标优化只擅长解决方案空间，救不了下三层的问题；你可以把病毒循环优化得极漂亮，同时在产品/市场的地基上被别人超过。 书里没把这层意思说破，而它本可以是全书最有力的一课。
• 第 11 章那个"最完整的端到端案例"，止步于设计阶段。 两个月、零代码、拿到"强得多的兴趣"和"客户主动留邮箱要求上线通知"——然后案例就结束了。我们始终不知道 JunkmailFreeze 有没有上线、上线后是不是真的成立。 Olsen 在方法论上是诚实的（他明说这是用视觉稿达到的 PMF 信心水平，并保留了对定价意愿的怀疑），但作为"证明流程有效"的证据，它缺了最关键的最后一环：真实市场的检验。
• Sean Ellis 的 40% 阈值是经验值，书里说的是他"在很多产品上做过之后凭经验发现"，没有给出样本、品类分布或方法说明。它是好用的启发式，不是被验证过的统计阈值——Olsen 自己也加了"会因品类浮动"的限定。用它做门槛可以，用它做结论不行。
• 一处内部张力：第 4 章用问卷量重要性与满意度，第 13 章却花了三段讲问卷有多不可靠。 两处都对，但书里没有把它们对上——如果问卷对措辞如此敏感、被访者常常没有足够信息作答，那么支撑整个"重要性 × 满意度"框架的数据来源本身就需要更严格的设计规范，而书里没给。
• 第二处内部张力：第 1 章刻意把 PMF 定义收窄（明确排除收入模式与获客模型），但第 13、14 章整整两章都在讲收入、LTV、CAC 与盈利。 这不是错误——它对应的是"验证 PMF 之后"的阶段——但全书的后三分之一实际上是在按它开篇拒绝的那个宽定义在运作，这个衔接书里没有交代清楚。
• 一处方法论缺口（对照后来的书就很明显）：第 11 章的定性判断没有事前标准。 他做完 8+8 位客户的访谈后判断"两个概念吸引力都不够""屏蔽垃圾邮件吸引力强"，依据是主持人的整体印象加事后给方框涂绿黄红。他很诚实地加了"这距离十拿九稳还很远"，但整个过程没有任何"测试前就定死的成功判据"——而这正是确认偏误最容易钻进来的地方。
• 时代印记要单独打折：第 12 章（敏捷/QA/CI/CD）与第 13、14 章的工具清单（KISSmetrics、Flurry、Optimizely、Google Content Experiments）已是 2015 年的快照；"当时 Git 可以说是最流行的版本控制系统"这类表述今天读起来是文物。框架活着，工具名死了。
• 一个必须点出的伦理/合规断层：全书最亮的那颗"银弹"——Friendster 的通讯录导入器——其做法是"让用户把自己邮箱网站的凭据输进 Friendster"。 这在今天是教科书级的钓鱼模式，被 OAuth、平台政策和隐私法规（GDPR/CCPA）整体封死。可迁移的是方法（找上行潜力最大、且不需要改变人的行为的指标；先只做一个服务商的 MVP 版本），不可迁移的是这个具体战术。书写于 2015，通篇没有隐私、数据合规或平台政策的位置——这是今天读它必须自己补上的一整个维度。

vs 《Continuous Discovery Habits》（Teresa Torres，同库 2026-06-06_continuous-discovery-habits.md）——最直接的一次代际升级

• 层级不同，正好互补：Olsen 写的是团队级操作手册（假设怎么写、原型做到什么保真度、访谈怎么问、指标怎么拆）；Perri 写的是组织级诊断（激励机制、预算方式、沟通节奏、战略四层部署）。Olsen 默认"你有权按这个流程做事"，Perri 直面"你的公司结构不让你这么做"。
• Perri 的 Kodak 案例正是 Olsen 方法论的边界：发现做对了，却败在组织——太晚、资源孤岛、要等半年的年度预算。Olsen 全书几乎不谈"没有资源/没有授权时怎么办"，这是本书作为"手册"最大的留白（他唯一沾边的是第 15 章第 9 条"确保团队有对的技能"，仍是团队内视角）。
• 两人对 MVP 的定义完全一致：为了学习的最小投入，不是第一版凑合品；Concierge（管家式）/ Wizard of Oz（绿野仙踪）/ 概念测试这三个术语两本书都用，含义一致——可以放心互相引用。
• Perri 的"PM 拥有 why，而不是 what（what 是全队共有的）"与 Olsen 的"问题空间优先于解决方案空间"是同一件事的两种说法；Perri 那句"我的角色不是好点子的生产者，而是坏点子的终结者"，可以当成 Olsen"战略即说不"的人格化版本。
• 一处真正的差异：Perri 反对把"交付了多少功能"当价值代理，因此她的度量重心在成果（outcome）；Olsen 的度量重心在留存与单元经济学。Olsen 更量化、更可算；但他缺 Perri 那层"指标本身可能被组织用错（拿来考核输出）"的警觉——Perri 的 Wells Fargo 式风险（只盯成果、丢了客户视角）在 Olsen 书里没有对应的防护。

vs 《High Output Management》（Grove，同库）——同一种工程师本能，但 Grove 多了一道保险

• 两人的底层动作是一样的：把管理/产品对象抽象成可度量的系统（Grove 的黑箱与领先指标 ↔ Olsen 的生意方程式与剥洋葱），然后围绕限制因素排优先级（Grove 的限制步骤 ↔ Olsen 的 MTMM）。读 Olsen 的第 13 章会有强烈的既视感。
• 但 Grove 有一件 Olsen 没有的东西：配对指标（paired indicators）——给每个"量"指标配一个"质"指标，防止单维过度优化（"骑车看哪儿就往哪儿拐"）。Olsen 的 MTMM 是单点聚焦的，天然有过度优化单一指标的风险；书里唯一隐含这层保险的是 throttling 那一段（放量前要确认"其他关键指标没有实质变差"）。把 Grove 的配对指标接到 Olsen 的 MTMM 上，是这两本书最值得做的一次缝合。

vs 《创新者的窘境》（同库 2026-06-07_innovators-dilemma.md）

• Olsen 那条"满意度刻度会被颠覆式创新整体左移，而重要性刻度相对稳定"，本质上是用消费者主观评价重新表述了颠覆理论（收音机→随身听→CD→iPod→智能手机）。它比克里斯坦森的版本更便于操作（你可以直接去问客户打分），但也丢掉了克里斯坦森最重要的那层机制解释：为什么在位者明知新技术存在却仍然做不出反应（资源分配流程与既有高毛利客户的引力）。Olsen 给的是标尺，克里斯坦森给的是病理。