精益产品手册

BOOK NOTES

精益产品手册

Dan Olsen

Dan Olsen 在 Intuit 带领 Quicken 团队创下销售纪录，后来做了多年产品顾问，客户包括 Facebook、Box、Friendster 等。他写这本书的起因是：看到许多团队理解精益创业的高层概念，却不知道具体该做什么。书的目标是给出一套可操作的、从零到上线的产品开发流程，同时覆盖 UX 设计、敏捷开发和产品分析三个与流程配套的领域。

书的主干是一个叫"产品-市场匹配金字塔"的模型，以及在此基础上设计的六步"精益产品流程"。其余内容——UX 设计原则、敏捷开发实践、分析框架——都是对这个流程的支撑和延伸。

产品-市场匹配金字塔

产品失败的根本原因，是没能比现有替代方案更好地满足用户需求。Marc Andreessen 把这个能力称为 product-market fit（产品-市场匹配）。Olsen 把它拆解成五个层次，形成一个金字塔结构：

市场侧（下两层）

  1. 目标用户：产品面向谁
  2. 未被满足的需求：这些用户有哪些重要但现有方案没有满足好的需求

产品侧（上三层） 3. 价值主张：产品计划满足哪些需求，在哪些维度比竞争对手更好 4. 功能集：哪些功能交付这个价值主张 5. 用户体验（UX）：功能以什么形式呈现给用户

金字塔的层次关系是依赖关系：上层建立在下层之上。如果目标用户假设错了，重新设计 UX 没有任何意义。这个层次关系决定了测试和迭代时应该优先检查哪一层的假设。

Quicken 的案例说明了这个金字塔的实际含义。1983 年 Intuit 推出 Quicken 时，市场上已有 46 款个人财务软件，但 Scott Cook 和 Tom Proulx 通过用户研究发现没有一款真正实现了产品-市场匹配——功能不够、难以使用。他们的核心假设是：以支票簿作为概念设计，会让当时熟悉写支票的用户觉得直观。这个假设被验证了，Quicken 迅速成为市场第一，创始人把它叫做"第 47 名优势"。

问题空间与解决方案空间

这是全书最基础的一对概念。

解决方案空间：任何实际存在或被设计出来的产品、原型、线框图。它是具体实现，有明确形态。

问题空间：用户的需求、痛点、待完成的任务。它不预设任何具体实现。

Olsen 用"太空钢笔"故事说明两者混淆的风险：NASA 委托 Fisher 公司花费一百万美元研发能在零重力下使用的钢笔。苏联用了铅笔。如果问题被定义为"能在零重力下书写的方式，使用方便、成本低、不需要外部电源"，那么铅笔和录音设备都是候选方案，思维空间更大。如果直接定义成"能在太空中使用的钢笔"，就已经把解决方案嵌入了问题定义。

另一个例子来自 Scott Cook。他问一组产品经理：TurboTax 最大的竞争对手是谁？大家都说 TaxCut（H&R Block 旗下的软件）。Cook 说答案是纸和笔——当时仍有更多美国人用手工方式填税表，而不是所有税务软件加起来。把市场定义成"税务软件市场"是解决方案空间的思维；定义成"税务准备市场"才是问题空间的思维，它包含了会计师服务和手工填写这些替代方案。

产品开发的方向有两种：

  • 由内而外（inside-out）：从公司内部的想法出发，不经过用户验证就构建
  • 由外而内（outside-in）：先理解用户的问题空间，再进入解决方案空间

精益产品流程是由外而内的。但 Olsen 也指出，用户不能给你发明突破性解决方案——Henry Ford "如果问用户想要什么，他们会说一匹更快的马"这个论断说的是用户无法设计解决方案，而不是说不需要理解他们的需求。苹果 Touch ID 的案例说明：即使没有明确测试，如果产品团队对问题空间（认证的便捷性和安全性之间的张力）有深刻理解，也能自信地推出用户会接受的功能。但同一款 MacBook Pro 上把电源键改到键盘区域导致用户误触的问题，正是缺乏对问题空间思考的代价。

精益产品流程六步

第一步：确定目标用户

产品是鱼饵，目标用户是鱼。投放之前需要有假设，但真正的目标用户往往要等产品上线之后才能确认。Quicken 原本面向个人家庭用户，后来发现约三分之一的用户是用它管理小企业财务的。

市场细分的四种方式：

  • 人口统计（年龄、性别、收入）：常是其他细分的副产品，不一定是核心原因
  • 心理图谱（态度、价值观、兴趣）：比人口统计更直接地解释为何在目标市场
  • 行为特征（使用频率、具体行为）：对筛选用户测试对象特别有用
  • 需求细分：按需求将用户归类，适合像 Dropcam 这样同一款产品被婴儿监控、宠物看护、商业安保等不同需求群体使用的情况

B2B 产品需要区分使用者和购买决策者。Salesforce 的使用者是销售人员，购买决策者可能是销售副总裁，而 CTO、CFO、法务总监可能是否决者（blockers）。需要同时定义经济买家和终端用户。

技术采纳生命周期（Geoffrey Moore 的框架）将市场分为创新者、早期采用者、早期主流、晚期主流、保守者五段。"跨越鸿沟"指的是从早期采用者到早期主流的转变——两个群体的需求差异很大，前者容纳粗糙产品，后者要求稳定性、可参考案例、行业领导者地位。定义目标用户时要清楚自己处于哪个阶段，不同阶段的用户对 UX 粗糙程度、价格、可靠性的容忍度都不一样。

**用户画像（Persona）**是目标用户假设的载体。一张好的 persona 包括：有代表性的照片、能概括最核心诉求的引语、人口统计、需求/目标、相关行为和挫败感、技术熟悉程度、使用场景。画像在流程早期就应该创建，而不是等到设计阶段才用。团队共享同一套 persona 有助于在大量细小的产品决策上保持一致。

第二步：识别未被满足的需求

重要性与满意度框架

Olsen 在 Intuit 带 Quicken 时开发了这个框架。将用户需求按重要性（纵轴）和满意度（横轴）绘图，分成四个象限：

  • 高重要性 + 低满意度（左上）：机会最大，这里是 Uber 进入的位置。出租车市场需求明确、重要，但用户对安全性、准时性、支付便利、司机礼貌等维度的满意度普遍低。
  • 高重要性 + 高满意度（右上）：市场成熟，竞争产品已经满足得很好，进入壁垒高。Microsoft Excel 的例子——功能完备，用户满意，没有其他桌面电子表格产品能切入。
  • 低重要性的两个象限：不值得优先投入，无论满意度高低。

机会分数的计算：以 0-100% 为区间，机会 = 重要性 × (100% - 当前满意度)。重要性为 90%、满意度为 30% 的需求，机会分 = 0.9 × 0.7 = 0.63，远高于重要性 70%、满意度 70% 的需求（机会分 = 0.7 × 0.3 = 0.21）。这个计算让"追求哪个方向"的判断有了具体依据。

Anthony Ulwick 的"期望结果驱动创新"方法也基于重要性和满意度，他的机会公式是：重要性 + max(重要性 - 满意度, 0)，避免了纯差值法对高重要性需求低估的问题。Ulwick 强调一个产品通常有 50-150 个可操作的期望结果，而不是几条模糊的需求。

需求的层级结构

Maslow 的需求层次在产品中有对应物。Olsen 为 Friendster 创造了"网页用户需求层次"：

  1. 可用性（网站是否能访问）
  2. 响应速度
  3. 功能正确性
  4. 功能集
  5. UX 设计

这个层次告诉我们：在可用性或响应速度存在问题时，改进 UX 设计没有意义，因为更基础的需求还没被满足。Friendster 在病毒式增长期遭遇服务器性能瓶颈，用户投诉加剧，正是这个层次关系的体现。

需求的梯形结构（Benefit Ladders）

通过反复追问"为什么这对你重要"可以将具体需求提升到更高层次。TurboTax 的六项具体需求其实对应三个高层需求：对税表准确性的信心（feel confident）、节省时间（save time）、省钱（save money）。发现梯形顶端的高层需求，有助于寻找更多实现路径。

Kano 模型

Noriaki Kano 的模型把需求分三类，每类与满意度的关系不同：

  • 必须具备（Must-have）：缺失导致强烈不满，具备也不产生额外满意度。汽车的安全带。
  • 性能型需求（Performance）：越满足越好，满意度线性提升。汽车的油耗。
  • 兴奋型需求（Delighter）：超出预期带来惊喜，缺失不会不满。1990 年代汽车首次内置 GPS 导航。

重要规则：需求随时间迁移。今天的 delighter 是明天的 performance needs，是后天的 must-have。GPS 导航和杯架都经历过这个过程。价值主张因此不能停在原地——竞争对手追平后，原有的差异化就消失了，必须持续寻找新的 delighter。

第三步：定义价值主张

价值主张回答：产品要在哪些需求维度上超越竞争对手，靠什么超越。

价值主张模板是一张表格：行是各类需求（must-have、性能型、delighter），列是竞争对手和自己的产品，格内填评分或高/中/低/Yes。

搜索引擎早期竞争史是一个好例子。不同引擎在三个性能维度（结果数量、新鲜度、相关性）上各有侧重，在竞争中相关性变成最重要的维度。Google 的 PageRank 在相关性上达到最高水准，同时在其他维度也不落后，赢得了搜索引擎战争。Google Suggest 和 Instant Search 是 delighter——节省用户输入查询词和查看结果的时间，其他搜索引擎没有。

Cuil 于 2008 年以"最大索引量（比 Google 多三倍）"为核心卖点进入已经在右上象限的搜索市场。上线后相关性和响应速度远低于 Google，两年后关闭。这个案例说明：在高满意度市场进入，必须在最重要的性能维度上至少持平，差异化必须是用户真正在意的。

预测未来：价值主张表格可以加上"一年后"列，同时预估竞争对手的动向。Flip 视频相机的教训——Cisco 以 5.9 亿美元收购后两年内关闭——是因为没有预料到 iPhone 3GS 会内置视频录制，而智能手机同时消除了"需要带第二个设备"和"不能即时分享"两个痛点。

第四步：确定 MVP 功能集

**用户故事（User Story）**是功能的基本单位，标准格式："作为一个[用户类型]，我希望[做某事]，以便[获得某个好处]"。Bill Wake 的 INVEST 原则概括了好的用户故事：独立、可协商、有价值、可估算、范围小、可测试。

**拆分（Chunking）**是把高层功能分解成更小的实现单元。对于"用户可以分享照片给朋友"这个功能，可以按分享渠道拆分（Facebook、Twitter、邮件、短信各一个 chunk），可以按附加元素拆分（仅照片 vs 带消息 vs 带标签）。Lean 制造中的小批量原则在这里适用：批量越小，反馈越快，浪费越少。开发者在估算小范围功能时，"未知的未知"（Rumsfeld 的表述）对估算误差的影响更小。

ROI 优先级：每个功能 chunk 的 ROI = 预期用户价值 / 预期开发工作量。高价值低投入优先，同等 ROI 时优先做小的（因为能更快得到反馈）。可以用 3×3 矩阵简化：按价值高/中/低和工作量高/中/低分 9 格，从格 1（高价值低工作量）向格 9 排序。

决定 MVP 候选：从价值主张出发，must-have 都要有，然后选择主要性能优势的顶级功能和一个核心 delighter。剩下的推到 v1.1、v1.2。Olsen 建议不要预先计划超过一两个版本——第一轮用户测试会推翻很多假设。

第五步：创建 MVP 原型

MVP 不等于"极简功能产品"。Olsen 用一个金字塔图说明这个误解：有人认为 MVP 只要有功能就够了，不考虑可靠性、可用性和愉悦感。正确的理解是：MVP 的功能集有限，但在已有的功能范围内，产品应该是"完整的"——功能可用、性能达标、UX 不造成阻碍。

MVP 测试矩阵按两个维度分类：

  • 营销测试 vs 产品测试：营销测试测的是对产品描述的反应（没有实际功能），产品测试测的是对功能本身的反应
  • 定量 vs 定性：定量测试规模大、统计显著，看"什么"和"多少"；定性测试规模小、一对一，看"为什么"
定性定量
营销营销材料反馈、5秒测试落地页/烟雾测试、A/B测试、广告投放、众筹
产品线框图/原型测试、Wizard of Oz、并发服务Fake door测试、产品分析、产品A/B测试

几个关键测试类型：

  • 落地页/烟雾测试：建一个描述产品的页面，有"注册"按钮，转化率是关键指标。Buffer 的 Joel Gascoigne 先用两页落地页（主页 + "稍后通知"页面）验证需求，再插入价格页面验证付费意愿，全程无须写任何产品代码。

  • Wizard of Oz MVP：向用户呈现一个看起来像真实产品的界面，后台由人工完成处理，用户不知道。用于在建立自动化系统之前验证假设。

  • Concierge MVP：有意让少量早期用户看到"幕布背后"的手工操作过程，同时深度了解他们的需求。Airbnb 发现带专业照片的房源预订量是平均水平的 2-3 倍，就先手工安排摄影师给房东拍照，验证假设后再建立自动化系统。

设计产出的保真度（从低到高）：

手绘草图 → 线框图（低保真，无视觉设计） → 可点击线框图 → 高保真 Mockup（有颜色字体图片） → 可点击 Mockup → 交互原型 → 真实产品

每个层次都可以用于测试，保真度越高，测试结果越接近真实用户行为，但制作成本也越高。Olsen 的建议是：尽早开始测试，宁可用低保真设计稿测试，也不要等到代码写完后才发现方向错了。

第六步：测试 MVP

测试规模：每波测试 5-8 人，一对一进行，不要用焦点小组（群体动力学会导致趋同、强势者主导、参与者不说真心话）。

招募渠道：用筛选问卷过滤目标用户，可通过 Craigslist、研究公司、UserTesting 平台等方式招募。行为特征比人口统计更有用——"每周交易 10 次以上的投资者"比"30-45 岁男性投资者"更能精准筛出目标用户。

测试结构：

  • 前 10-15 分钟：暖场 + 发现性问题（了解用户现有行为和痛点，此时不展示产品）
  • 中间 40-45 分钟：展示原型，收集反馈
  • 最后 5-10 分钟：整体印象、价值评分、易用性评分、答疑

主持注意事项：

  • 不要提示性地回答用户的问题（"你会点这里吗？"→ 改为"你会做什么？"）
  • 用开放性问题（"怎么"、"为什么"、"什么"），避免"是/否"问题
  • 用"回声法"——重复用户说的话再追问，不要把自己的解释注入问题
  • 用户遇到困难时不要帮助他们，哪怕看起来很痛苦——真实产品上线后没有人在旁边帮忙

区分两类反馈：

  • 可用性反馈：产品难用、找不到功能、操作路径太长
  • 产品-市场匹配反馈：产品有没有价值、是否值得使用

良好的可用性不等于产品-市场匹配。Olsen 曾做个性化新闻产品，第三波测试时用户能顺畅地完成所有任务，但仍有 20% 说不会用——原因是他们获取新闻的偏好方式与产品设计不符。这个发现帮助团队重新定义了目标用户。

反馈整理表格：按用户列，按功能集/UX/信息传达分组记录每条反馈，加百分比统计。价值和易用性的 1-10 分评分在每波测试后应有上升趋势。多轮测试后，某个问题消失（百分比变 0）意味着修复成功；新问题的出现是正常现象。

迭代与转向

Hypothesize-Design-Test-Learn 循环

Olsen 对 Ries 的 Build-Measure-Learn 循环做了修订。"Build"不一定是代码，可以是任何可测试的设计产出；"Measure"不一定是统计数据，定性观察也算；"Learn"之后需要显式地"Hypothesize"，因为这个循环不是从 Build 开始，而是从假设开始。新循环：假设 → 设计 → 测试 → 学习 → 回到假设。

每次学习后，要把新信息对应到金字塔的哪一层，从最底层开始检查。UX 问题容易修，价值主张假设错了会影响上面所有层。

转向（Pivot）

当多轮迭代后产品-市场匹配程度没有实质性提升，需要考虑更大幅度的方向改变。Olsen 用爬山比喻说明：如果在一座山上爬了很久却到不了高处，可能需要换一座山（转向到更大的市场机会）。

典型转向案例：

  • Flickr 从大型网游"Game Neverending"中的照片分享工具独立成产品
  • Instagram 从"Burbn"（融合了 Foursquare 和 Mafia Wars 元素的 HTML5 社交应用）剥离出仅保留照片、评论、点赞的新产品

转向不等于每次遇到阻力就换方向（"追逐新事物综合征"），也不等于死守原路不调整。判断是否需要转向的信号：目标用户对 MVP 反应温和而非真正热情，问题不在于可用性而在于根本不觉得有价值。

MarketingReport.com 案例完整流程

这是书中最详细的端到端案例。

初始设想：给用户展示营销数据库对他们的了解情况（类似信用报告），让用户修正信息并获得相关优惠。

在问题空间分析阶段，团队把潜在价值分成两大方向：Marketing Shield（隐私保护 + 减少垃圾邮件）和 Marketing Saver（省钱优惠 + 消费洞察 + 社交）。

第一轮用户测试（各 8 人）：两个概念都缺乏足够吸引力。核心价值"了解'他们'对你的了解"只有有限吸引力；Marketing Score 令人困惑；比较消费和社交功能吸引力低。两个亮点是：Saver 用户对省钱优惠感兴趣，Shield 用户对屏蔽垃圾邮件兴趣更强。

转向：放弃"营销透明度"的核心定位，聚焦垃圾邮件屏蔽，新名称 JunkmailFreeze。重新设计产品：覆盖 7 大类 31 种垃圾邮件，核心登录流程从"查看你的营销报告"改为直接进入选择屏蔽类型的界面。新设计基于测试中学到的细节——用户最恨的是预先批准的信用卡申请和现金垫付支票（身份盗窃风险），其次是贷款和保险类邮件，还有大量邮购目录和本地广告。

第二轮用户测试（6 人）：效果截然不同。没有主要反对意见，大量点头，未经提示的积极评论。用户在测试结束后自发询问是否可以立即注册，并留下联系方式要求上线时通知。这种自发行为（而非测试环节内的评分）被 Olsen 视为产品-市场匹配的最有力证明。

UX 设计四层冰山

UX 设计的可见部分只是顶端，底下还有三层。从底到顶：

概念设计

产品基于什么核心比喻或模型。Quicken 的支票簿设计——用户熟悉写支票的体验，界面以支票形式呈现交易，直接降低了学习曲线。Uber 的地图中心设计——关键创新是实时显示附近司机位置和预计到达时间，直接解决了叫出租车最核心的焦虑（不确定是否会来、什么时候到）。

好的概念设计让产品的价值主张对第一次使用的用户立刻显现。

信息架构（IA）

产品的结构：有哪些页面/屏幕，如何组织，如何命名和导航。

核心交付物是站点地图（Sitemap）：每个方框是一个页面，连线表示导航路径，标注全局导航项（从任何页面都能访问的内容）。

**卡片分类（Card Sorting）**是测试 IA 的研究方法：让用户把代表内容/功能的卡片按他们认为的关系分组，从而发现用户的思维模型与产品结构是否一致。

**可查找性（Findability）**是关键指标：要求用户找到某个功能，看有多少人能成功找到，以及导航路径是否最优。

交互设计

用户做了什么，产品如何响应；多步骤流程如何设计；错误状态、空状态、加载状态如何处理。

TurboTax 的 EasyStep 模式是一个教科书级案例：用结构化访谈的概念设计，每次只显示一两个问题，根据之前答案动态决定下一个问题，让用户无需理解税法也能完成数十张表单。高级用户还可以切换到直接编辑税表的"Forms"模式。

流程图是交互设计的主要工具：矩形是操作，菱形是判断节点，箭头表示流向。对于分支多、状态复杂的流程，流程图比线框图更能捕捉完整逻辑。

可点击线框图已经取代静态线框图成为主流。用户可以实际点击穿越产品流程，体验更真实，测试结果更有效。

视觉设计

颜色、字体、图形、图标、间距——这些决定产品的外观感受。

几个可执行的设计规则：

  • 色彩：选定一套调色板（主色 + 背景色 + 强调色），只使用这些颜色，避免随意使用。冷色（蓝、绿）传达信任和冷静，暖色（红、橙）传达能量和紧迫。
  • 字体：通常只用两种字体，正文一种，标题一种。
  • 视觉层次：通过大小、对比度、位置引导用户视线。用"眯眼测试"——模糊截图，看能否识别出最重要的元素。
  • 格式塔原则：相近的元素感知为相关（接近原则），相似的元素感知为相关（相似原则）。将相关控件放在一起，不相关的控件分开。
  • 响应式设计：移动端优先（Mobile First）——先设计小屏幕版本，因为空间限制迫使你做出优先级决策，然后再扩展到大屏幕。

"A-Team"组合：产品经理 + 交互设计师 + 视觉设计师 + 前端开发者，这四个角色都强且能协作，才能做出好的 UX。

构建产品：敏捷开发

Scrum 与 Kanban

Scrum 的核心是时间盒（Sprint，通常两周）。每个 Sprint 开始时做规划会议，从产品 Backlog 中选取这个 Sprint 要完成的用户故事；结束时做展示会议（Sprint Review）和回顾会议（Retrospective）。开发团队每天站会（Daily Scrum）同步进度。

关键度量是速率（Velocity）：每个 Sprint 完成的故事点数，用于规划未来 Sprint 的工作量。

规划扑克（Planning Poker）：所有开发者同时亮出估算卡片，分歧大时讨论直到达成共识。防止锚定效应和从众，提高估算准确性。

Kanban 不以时间盒为单位，以工作流可视化和限制在制品（WIP Limit）为核心。看板的列是工作状态（Backlog、Ready、In Development、Testing、Done 等），卡片从左向右流动。每列有 WIP 上限，达到上限时不能从左边拉入新卡片，迫使先清空瓶颈。度量指标是周期时间（Cycle Time）（从开始到交付）和前置时间（Lead Time）（从提出需求到交付）。

如何选择：Kanban 适合小团队、快速变化的需求；Scrum 适合需要跨团队协调、需要可预测节奏的情况。

质量保证

  • 验证测试（Validation Testing）：新功能是否按预期工作
  • 回归测试（Regression Testing）：新功能是否破坏了已有功能
  • 自动化测试适合回归，手工测试适合首次验证新功能
  • 测试驱动开发（TDD）：先写测试用例再写代码，测试通过后可安全重构

持续集成与持续部署

持续集成：代码频繁提交并自动构建、自动测试，快速发现集成问题。团队代码始终处于可发布状态。

持续部署：通过所有测试的代码自动发布到生产环境。需要自动回滚机制（通过监控关键指标触发）和完善的分析系统。

度量与分析

研究方法框架

按两个维度分类所有用户研究方法：

定性定量
态度用户访谈问卷调查
行为可用性测试产品分析 / A/B 测试

定量告诉你"发生了什么"和"发生了多少"，定性告诉你"为什么"。Olsen 用"Oprah vs Spock"来概括：Oprah 是纯定性（一对一深度访谈），Spock 是纯定量（只看数据）。验证产品-市场匹配阶段 Oprah 更重要，产品上线后优化阶段 Spock 才能发挥最大价值。

调查问卷的局限性：不适合询问用户"是否会用还不存在的产品"（信息太少），不适合预测行为（态度与行为不一致），对问题措辞高度敏感。适合用于：衡量重要性和满意度、追踪品牌认知、NPS 调查等有明确答案基础的问题。

Sean Ellis 的产品-市场匹配问题："如果无法再使用这个产品，你会有什么感受？"选项是"非常失望/有些失望/不失望/我已不再使用"。经验规律：回答"非常失望"超过 40% 的产品趋向于有产品-市场匹配。样本要求：使用过至少两次、最近有使用的用户。

AARRR 框架

Dave McClure 的"海盗指标"框架，五个宏观指标：

  1. Acquisition（获客）：如何让潜在用户知道产品
  2. Activation（激活）：潜在用户如何转化为用户
  3. Retention（留存）：多少用户持续使用
  4. Revenue（收入）：用户产生多少收入
  5. Referral（推荐）：用户如何帮助吸引新用户

优化顺序：通常先优化留存，再优化激活，最后优化获客。原因：如果留存差，说明还没实现产品-市场匹配，花钱拉来更多用户只是在加速浪费；留存好了再优化转化，因为提高转化率能让后续的获客投入价值更大。

留存率与留存曲线

留存率是衡量产品-市场匹配程度的最佳单项指标。

留存曲线的三个关键参数：

  1. 初始流失率：注册后第一天不再回来的用户比例（移动 App 通常很高，因为用户安装应用后容易遗忘）
  2. 衰减速率：此后曲线下降的速度
  3. 终值（Terminal Value）：曲线是否趋于稳定的某个值，还是归零

产品-市场匹配越强，初始流失率越低、衰减越慢、终值越高。终值是三者中最重要的——留存 50% vs 留存 1% 直接决定商业模式的可行性。

同期群分析（Cohort Analysis）：按注册时间段将用户分组，为每个同期群画留存曲线。如果产品持续改进，更新的同期群的留存曲线应该高于更早的同期群——这是产品-市场匹配随时间改善的直接证明。

商业方程

Olsen 主张把业务目标表达为可操作指标的等式，然后"剥洋葱"层层展开。

广告收入模型例子：

收入 = 访客数 × 平均每访客收入
     = 访客数 × 每访客页面浏览数 × 每页广告展示数 × 千次展示费用(CPM)

每一项都是可以测量和改进的变量。访客数可以进一步拆分为新访客（按渠道来源）和回访用户（上期用户数 × 回访率）。

客户生命周期价值（LTV）与获客成本（CAC）：

利润/客户 = LTV - CAC
LTV = 平均每用户收入(ARPU) × 平均存活时间 × 毛利率
平均存活时间 = 1 / 流失率
CAC = 每次获客成本(CPA) / 转化率

当 LTV > CAC 时，增长是正向循环。SaaS 行业的经验规律：LTV/CAC 比值应大于 3。

精益产品分析流程

Olsen 的系统化分析优化流程：

  1. 定义关键指标
  2. 为每个指标建立基准值
  3. 评估每个指标的 ROI 潜力（上升空间 = 当前值距最大可能值的比例）
  4. 选择 ROI 最高的指标作为"当前最重要指标"（MTMM）
  5. 针对这个指标头脑风暴改进想法，按 ROI 排序
  6. 实施最高 ROI 的改进（理想情况下用 A/B 测试）
  7. 观察指标变化
  8. 继续循环直到边际收益递减，再回到第 3 步选下一个 MTMM

Friendster 案例：Olsen 加入后发现没有人系统衡量病毒增长。他为病毒循环定义了 5 个归一化比率指标（活跃用户比例、发送邀请的用户比例、每发件人平均邀请数、邀请点击率、注册转化率）。评估上升空间后发现"每发件人平均邀请数"（当时 2.3）有极高的潜力（上限约 150）。最高 ROI 的改进想法是从 Yahoo Mail 导入通讯录，一周开发。上线后该指标从 2.3 上升到 5.3，病毒系数翻倍以上，新用户获取量随之增长同比例。

避免局部最优（Local Maximum）：在某个维度上 A/B 测试可能只能找到当前设计思路下的最优解，而不是所有可能方案中的最优解。当一个指标长期无法改善时，需要跳出当前思路，从更高层面重新审视假设。

十条最佳实践

书的最后一章给出 10 条跨越全流程的建议，可以当作检查清单：

  1. 有观点，但保持开放：在不确定中做决定需要立场，但要为最不确定的部分设计测试，用证据而不是坚持更新假设
  2. 明确写下假设：把假设透明化，让团队成员能看到、讨论和改进
  3. 无情地优先排序：Backlog 不只要分高中低，还要有明确的排序，"15 件高优先级事项"不是优先级
  4. 保持小范围但聚焦：小批量完成得更快，反馈来得更早，不代表只做小事，而是把大事切小
  5. 与用户对话：用户是产品-市场匹配的裁判。建立系统让用户测试成为常规，不要让招募成为阻碍
  6. 先测试再构建：设计稿的迭代速度远快于代码迭代，把验证提前到代码之前
  7. 避免局部最优：无法改善时不是到极限了，可能是被当前框架困住了，需要发散思维
  8. 尝试有前景的工具和方法：不要因为熟悉就一直用旧工具，定期评估是否有更好的选项
  9. 确保团队拥有正确技能：产品管理、用户研究、交互设计、视觉设计、文案、前后端开发、QA、DevOps、分析——评估哪些技能的缺口影响最大，有针对性地补齐
  10. 培养团队协作：产品团队像篮球队，每个人有自己的位置，但需要传球配合。定期讨论团队工作方式，而不只是工作内容

几个可直接迁移的操作

用于日常决策的检查清单：每次讨论新功能时，先问"这解决哪个用户的什么问题"，再问"这在重要性-满意度象限的哪个位置"，最后问"这属于 must-have、performance 还是 delighter"。

价值主张表格：任何新产品或功能立项前，用竞争对手比较表格说清楚在哪些维度要超越谁、在哪些维度可以接受落后。这张表格也是向团队对齐目标的工具。

测试节奏：提前排好每两周测试时间，不要等产品做好了再招人。招募和测试准备分开进行，避免"等测试者的时间里代码已经写完了"的陷阱。

同期群留存仪表板：上线后每月更新留存曲线，按注册月份分群，确认终值在上升，而不只是看总活跃用户数（后者混淆了获客和留存的贡献）。

Metric That Matters Most（MTMM）：任何时刻团队只专注改善一个最重要的指标，其他指标不恶化即可。MTMM 会随时间变化，但在某个时间点要明确。

产品管理精益创业