7. 通过模拟发现你的产品

你必须从客户体验出发，再反推技术。你不能从技术出发，再去想你要把它卖到哪里。

— 史蒂夫·乔布斯

在第 6 章中，我们找到了自己的客户。我们想弄清楚客户是谁、他们的问题是什么。通过这个过程，我们打磨出了一份产品论题（product thesis）：即我们对“什么才是这群人眼中的优秀产品”的高层主张。

但我们暂时按住了对解决方案的深入思考。

在这一章，我们将打开闸门，把注意力转向产品发现（product discovery）。

也就是说，在构成用户场景的角色与模拟中，目前我们只有角色。现在该写模拟了。

但你想构建的这个产品或功能，还不存在。没人讲过关于它的故事。如果我们想第一次就尽量做对，就必须先讲一些微型科幻故事，预测用户将如何驾驭我们赋予他们的新能力。

于是，一场从产品之地走向系统之地的伟大旅程开始了。

从愿景到需求

软件开发里一个老大难问题是后期才冒出的产品需求：我们前面没看到它们。有时它们来自用户反馈，有时是我们在设计和实现时才意识到更多细节。这会拖慢路线图、扩大范围。而这种不受欢迎惊喜的一大原因，就是前期发现工作不够。

为了减少惊喜，这里有一份我在中大型项目中验证过有效的行程。每个团队工作方式都不同，所以我不打算规定某个流程或文档模板，而是突出我认为你应该关注的关键点。

• 用用户场景补完产品愿景，这些场景叫北极星场景（north star scenarios）。
• 把这些北极星场景切分重组，整理成需求，形式是用例汇编（use case compendium）。
• 制作路线图，聚焦第一个里程碑，覆盖最关键的需求。
• 提出你要在第一个里程碑交付什么。把细节故事写出来，称为用户流程（user flows）；如果展示用户界面，也可称为分镜图（storyboards）。
• 为你选中的每个用例补充详细系统需求，并在必要时回流到原始需求。
• 基于用户流程与系统需求，整理一份待完成工作（jobs to be done）清单。

到这一步，你已经从发现过渡到定义。定义通常包含更详细的设计，我们会在后续章节里讲。

没有任何流程能让你无所不知，在周期后段学到意外信息是自然的。但这些意外的规模应该小很多，并且最好不至于威胁产品生死。

图 7-1 展示了一个围绕产品发现构建流程的例子，它拆成三份文档：

• 产品简报（Product brief）：一份愿景文档，用于让所有人对目标达成一致。有时也叫“问题简报（problem brief）”或“一页纸（one-pager）”。最少应包含：产品论题/反命题与目标受众（第 6 章）、要追踪的目标或产品指标（第 5 章），以及稍后会定义的北极星场景。在双钻模型（Double Diamond）术语里，它的目标是打通发现阶段。
• 产品需求文档（Product requirements document）：展开产品应该具备的属性，不仅面向长期，也提出首个可交付物或里程碑，同时尽量减少对实现方式的过度规定。目标是打通定义阶段。
• 产品规格（Product specification）：展示产品应如何设计。目标是打通开发阶段。

图 7-1. 一个产品发现流程示例

我并不是来推销某个特定流程的，而且我接触的大多数团队并不会把这三步都正式化。不过在本章里，我会用这个流程演示如何系统地从愿景走向可执行设计。即使你只把它用于个人工作流，我也希望它有价值。

无论你的团队如何运作，这里有三个关键属性值得追求。

第一，正式或非正式地把工作拆成多个阶段：为什么（why）、做什么（what）、怎么做（how），都从用户视角出发。粗略地说，阶段 1 聚焦用户为什么希望我们采取行动，阶段 2 聚焦用户在要求什么，阶段 3 聚焦用户将如何达成目标。每个阶段都要警惕过早陷入你现在还不必思考的细节泥潭。

第二，在每个阶段都用场景模拟来确保团队对齐并解决完整问题，这种做法叫场景驱动发现（scenario-driven discovery）。后面我会展开讲。

最后，要允许向前一阶段反馈。负责产品规格的工程师和设计师，需要和负责产品简报的工程师与 PM 紧密协作，让团队持续学习。没有这种反馈，你得到的就是“瀑布式”做法。鉴于软件开发的混沌本质，瀑布法已经逐渐失宠。它往往会导致：因为后面难改，所以前面过度思考；同时又无法适应信息变化。

这一章里，我会逐步走完整个产品发现流程。

过程中，我会重点讲一些与发现和优先级相关的重要概念：

• 如何把用例组织清楚
• 如何从产品思维过渡到系统思维
• 如何批判性地思考产品给用户带来的价值，包括四条“残酷真相”
• 如何整体评估构建与维护软件的投入规模
• 如何用用户流程识别你的待完成工作（jobs to be done）

作为开场，我先给出一个关于构建 AI 代理的案例研究。

案例研究导入

当我写下这些内容时，时间是 2025 年，也就是所谓的“代理之年（year of the agent）”，所以如果不放一个 AI 助手或代理的案例会有点说不过去。这个案例是虚构的，但它融合了真实公司正在尝试的产品特征——目前谁也不确定最终会怎样。未来的读者：欢迎告诉我结果如何。

假设我们在 Kabletown（一家互联网和有线电视服务商）的支持工程团队。我们的团队使命是让支持服务运转顺畅。现有一套遗留自动化系统会先和客户聊天、尽量先帮忙再转人工，但它使用的是大语言模型（LLM）之前的技术，对于客户多样化需求过于僵硬。客户说他们讨厌 Kabletown 的支持体验，觉得自己被困住了。与此同时，人工客服被压垮，用户的邮件和聊天回复要等好几天。

我们注意到，前七类账户操作占了支持请求量的 65%，但当前方案实际自动化有效覆盖只有大约 15%。

先给出几个你需要知道的 AI 相关定义。

• Assistant（助手）：一种 AI，能在与用户的一次交互中回答问题、做分析并执行任务。
• Agent（代理）：也能做到上述能力，但还能围绕目标自主规划并行动。
• Tool（工具）：带有描述信息的函数，用于告诉助手或代理应如何调用它。

由于 Kabletown 还不确定自己需要 agent 还是 assistant，所以在不需要精确区分的地方，我会交替使用这两个词。

现在我们来填写产品简报的几个部分。

AI 助手产品简报

我们的自动化支持代理 Helpy McHelpface，将彻底改变 Kabletown 的技术支持与账户支持体验。

产品论题

我们提出两个基本主张：

• 降低用户挫败感：用户对当前助手很不满意，它在大多数请求上表现糟糕，甚至连何时该转人工都判断不准，这项判断 80% 的时候都错。Helpy McHelpface 会比旧技术更好地处理与客户的直接沟通，因为它更能理解用户意图，从而降低用户挫败感。
• 降低支持事务性负担：当前助手一旦要做变更就必须拉人类介入。如果给 Helpy 配置可操作账户变更、创建预约、下发寄送订单等工具，我们就有机会把剩余未自动化支持量中的一半以上也自动化。通过加速这些例行但耗人的工作，我们可以显著缩短等待时间、提升用户满意度，同时减轻支持代表积压。

反命题/风险

哪些因素可能导致结果不如预期？

• Helpy 可能会执行它不该执行的动作，导致用户产生糟糕的意外体验。
• 我们可能无法仅靠 assistant 达成目标，而需要一个自主规划 agent，从而抬高构建和运行成本。
• 我们的知识库可能不足以提供 Helpy 所需上下文。

目标受众

我们有两个目标人物画像，不过可能会先做其中一个：

• 账户支持用户：Tinker Tia 是 Kabletown 的长期互联网和有线电视客户，她想修改自己的账户，比如升级/降级服务，或新增/升级硬件。
• 技术支持用户：Sad Lisa 是新加入的 Kabletown 宽带客户，遇到问题无法正常使用，希望尽快修好。

产品目标

我们的首要目标是提升用户满意度，并在不大量扩招的情况下改善支持积压。我们认为这两个目标可以同时达成。短期内我们不以提升利润为目标。

• 采用指标（Adoption metric）：把完全自动化支持交互比例从 15% 提升到 65%。
• 价值指标（Value metric）：把助手与人工支持后的客户满意度评分从 2.1 提升到 3.5（满分 5 分）。
• KPI：利润中性。虽然我们希望长期降低人工支持成本，但也可能因为更容易降级套餐等因素压低收入。我们会跟踪降级行为以理解收入影响。

北极星场景

这一节我们稍后会回到。

用北极星场景补完你的产品愿景

在我写北极星场景前，先解释一下场景驱动发现，然后再讲如何为产品简报做场景头脑风暴、筛选与打磨。

场景驱动发现

场景驱动发现（SDD）是指在整个发现流程中持续使用场景。我在发明这个术语，但不是在发明这件事本身——业界最接近的概念是“场景化设计（scenario-based design）”，只是它并不算广为人知。我希望有一个更直接表达“我们如何用场景去挖需求和待完成工作”的词。

你可以依靠场景来确保最终交付给用户的是完整而有用的产品，原因如下：

• 通过突出角色需求，它能把为什么讲清楚，确保需求与原始意图一致。
• 它能照亮完整故事，因此我们更可能发现重要功能或边缘情况。
• 相比抽象需求清单，故事更不容易被误读。一套共享故事更容易让团队对齐。
• 在场景里找情节漏洞，比在需求列表里“调 bug”更容易。

产品简报里的场景通常被称为北极星场景。

在产品需求文档中，场景会被切成细粒度“需求”，或者在敏捷术语里叫“故事”。

在产品规格中，场景通常称为用户流程或分镜图。

本节里，我会以补完 Helpy McHelpface 产品简报为目标，演示北极星场景的准备过程。

以团队方式头脑风暴场景

并不是每位工程师都喜欢写完整用户故事。有人觉得陌生所以畏难；也有人天生更擅长挑故事毛病，而不是从零创作。弥补这些差距的一个好办法是结对或组队。协作写故事非常有趣。某个场景可以先由一个同事写出内核，再由其他人补步骤。最后每个人都会有共同所有权和共同打磨作品的成就感。

和任何头脑风暴一样，协作构思用户故事需要接纳每个人的想法，并在他人的想法上继续搭建。但在压力和紧迫截止日期下，如何保持冷静与包容？

这些年我学到的关键一点是：做发现工作时，不同人（通常是下意识地）心里装着不同时间尺度。有人看长期，有人看未来几周。有人角色更偏前瞻，有人更偏战术。

在头脑风暴时，要允许大家面向未来做梦。先和团队约定：某个故事里出现了“构建成本很高的功能”，不代表它马上就要做。这能消除那种紧张感——有些人会担心你打算把所有功能都塞进首个版本。

并且在你制定第一个里程碑前，都要保持这种心态。你的目标是先有足够多想法，避免错过最优方案；同时形成一份面向未来的路线图，让每个里程碑都在服务长期愿景。

头脑风暴应该是有趣的！敏捷方法里著名的“便利贴”练习，就是大家把小故事写在彩色便利贴上，再按主题分类、筛选优先。你们团队怎么顺手就怎么来，但最好最终沉淀成一份共享文档，包含几条北极星场景。

选择并打磨北极星场景

选出那些最重要、最能说明问题、也最可能进入路线图的场景。后面你还会继续做优先级，但第一步先把最关键想法挑出来，并把最能照亮这些想法的故事补完整。

如第 1 章所述，团队应该通过寻找情节漏洞来给选中的故事“调试”。有些故事是不是跳过了用户旅程中的关键步骤？是不是对用户做了英雄式假设？是不是忽略了关键细节？团队中有些工程师也许不擅长从零写故事，但他们在这一步可能非常强，这同样很有价值。

就我个人经验，用打字评论而不是口头争辩来做这种调试，既高效又和气。这有助于让头脑风暴保持“增量、积极”的氛围。

记住这些是高层故事；这个阶段追求的是“准确”，而不是“精确到细节”。等到有人写用户流程时，细节会下钻得非常深。

有了完整且有驱动力的故事，我们后面就更容易看见所有需求。

以下是 Kabletown 的第一条北极星场景：

• 有线电视盒安装：Tinker Tia 想给卧室的第二台电视配一个新的有线电视盒。她在笔记本上访问 kabletown.com，找到了 Helpy。Helpy 同意帮忙，并询问她是否需要安装人员协助，她回答需要。Helpy 引导她完成套餐变更并获得确认，然后触发寄送订单。订单发货时，它会在聊天里提醒她，Tia 收到通知后可安排安装预约。Helpy 会与她确认时间约束，并把预约安排在货到之后。技术人员报告安装完成后，Helpy 还会回访并发起满意度调查。

我是怎么写出这个场景的？我的目标是把故事当作创意聚焦工具，避免漏掉重要需求。

• 我先从一个常见用户问题出发：“想安装一个新有线电视盒”。
• 我不断追问自己：“Tia 下一步需要发生什么？”“Kabletown 的流程必须怎样配合？”直到用户完整问题被解决。
• 我思考了如何跟踪价值指标，于是在结尾加了客户调研。
• 我主动找情节漏洞。当故事某部分过于模糊，或让我担心某种结果时，我会问自己：“这里有哪些关键细节会帮助我们指导需求？”
• 我回头检查自己是否对具体方案规定太多。我的重点应该是“做什么”和“为什么”，而不是“怎么做”。

头脑风暴后，团队注意到这个场景里 Helpy 需要走一条复杂工作流，于是开始讨论：Helpy 是否需要较高自主性，还是可以用硬编码工作流包裹一个 assistant。团队勾勒了这个场景的若干变体，展示 Helpy 将面对的广泛情形，并据此决定 Helpy 需要是一个 agent，而不仅是 assistant。随后他们回去更新了产品论题/反命题。

由于北极星场景要广泛传播，他们把这些变体从主列表里拿掉，以保证易读。他们另外做了一个“附录”，收纳与他们相关但不必向整个组织重点传播的额外场景。

团队又草拟了几条北极星场景，以覆盖更广需求范围，比如移动端与 PC、销售支持与技术支持（或两者兼有），以及在销售类中区分升级与降级。他们特别想突出降级，因为在产品简报里提到过它可能涉及收入上的争议。目标是在改动成本变高前，尽早暴露最大风险与认知不一致，并确保包括财务团队在内的相关方都感觉被代表。

• 降级：Tinker Tia 有两个有线电视盒，但从不使用卧室电视那个，她想降低月费。Helpy 搜索了一个与她现有方案接近但不含额外机顶盒的套餐，并告诉她可以节省多少费用。她同意该方案，Helpy 告知只要归还机顶盒就会处理降级。她确认后，Helpy 给她寄出回寄包装。她寄回设备后，Helpy 在签收后给她发满意度调查。
• 带账户变更诉求的愤怒用户：Tinker Tia 基本不用某个房间的机顶盒，想降月费。她查看账户时发现了 Helpy 链接并发起咨询。Helpy 注意到她处于促销价周期，于是告知没有能让她省钱的可切换方案。她很生气，要求找主管。人工客服从 Helpy 接管该聊天。双方最终协商为：只要她归还机顶盒，就给一次性小额折扣。她同意并收到满意度调查。
• 故障中断：Sad Lisa 的有线宽带断网了。她在手机上打开 Kabletown App（手机套餐仍可用），看到 Helpy 按钮并询问发生了什么。Helpy 将她地址与故障地图比对，发现确有中断并发送预计恢复时间。故障恢复后，Helpy 再次通知并附带满意度调查。
• 客户硬件问题：Sad Lisa 觉得网速慢，认为是 Kabletown 的问题。她在 kabletown.com 看见 Helpy 的“获取支持”按钮并点击。Helpy 询问她的设备与环境，发现她在无线网络下使用 PC 笔记本。它判断没有区域故障后，便引导她执行一系列诊断与建议，从历史最成功方案开始，包括重置无线路由器、运行 Windows 网络诊断等。重置 Kabletown 提供的无线路由器后问题解决。Helpy 告知她若问题反复出现可再次联系（例如路由器故障），随后发起调查，她给出了很高评分。

在写这些场景时：

• 我有意加入摩擦和失败情境，例如用户不喜欢机器人，以确保 Helpy 具备韧性。
• 当我想到不同需求时，我会写包含这些需求的故事。比如我通过“Lisa 家宽断网，只能转向蜂窝设备”来论证移动端支持必要性。故事本身就是这些功能的“销售提案”，后面做优先级时我们会逐一评估。

如果我做得还行，这些场景应该能让人清晰、直观地理解我们想达成什么。因为故事是人类从小就习得的通用沟通媒介。你对系统的心智模型也许和我不同，但我们大概率能在这些故事含义上达成一致。

把这些故事都实现出来可能并不容易。这反而是好事。请回忆序言里讲过的双钻模型：产品生命周期中的发现阶段本来就是发散、探索的。愿景应该把标准拉高，推动我们去做那些虽然困难但影响巨大的事情。即便后来发现，比如给 Tia 在订单发货时推送通知很难，我们也可以迭代，之后再写替代故事。或者通过分批发布逐步补全这些故事，只要每次增量发布本身都能提供真实价值。

同时要注意，这些场景现在还没有按“便于分工构建”的方式组织。下一步写 PRD 时就会处理这件事。

把北极星场景转换为需求

如果把用户故事放进一张数据库表，它会是按时间排序的一系列时刻，并关联到某个人物画像。这是理解用户如何穿过你产品的一种很好的方式。

但这并不是系统设计最有用的表示。系统设计更像图数据库——页面里有表单，表单里有按钮，点击按钮会连到服务外层的 API 网关，再通往存储系统。

如果我们的大脑里也有类似这些“数据库”，那么从发现阶段走向设计阶段的过程，就是一次从“时间/故事表示”到“图/系统表示”的大重索引（great reindexing）。图 7-2 与 图 7-3 展示了同一产品的两种表示：

图 7-2. 故事视图

图 7-3. 系统视图

最全能的工程师，往往能在脑中同时构建这两种索引。如果你只会第一种，你就像产品经理；如果你只会第二种，你就会彻底依赖产品经理，并在与其沟通时步履维艰。

这两种表示之间的翻译尤其关键，而误译到处都是，尤其当 PM 与工程师无法内化彼此的表示方式时。

大重索引通常从高层需求与设计原则开始。

高层需求

高层需求与设计原则是一份摘要，用来明确我们设计“要达成什么”。优先哪个人物画像？追求营收？还是易用性？它能与那些没法通读全部细节用例的人建立沟通与信任。

对 Kabletown 来说，可能会是这样：

• 根据产品简报，我们要在利润中性的前提下提升用户满意度并降低支持负担。
• 首个里程碑先聚焦技术支持类交互。
• 先瞄准最高频任务，例如慢网诊断。比如 Helpy 识别到超出其能力边界时，应转人工，而不是硬着头皮继续。
• 早期优先安全性，让 Helpy 处于清晰护栏内；即使这意味着它有时不够“尽可能有帮助”。

注意我在显式指出我们如何在冲突原则之间打破平局。把这些点亮出来往往既有争议也有价值，能激发高质量讨论。

如果把这段写在产品需求文档开头，读者会更容易理解后面的内容。

产品需求文档

PRD在不同公司里含义会略有不同。对某些团队，它甚至可能已经包含本章后文会讲到的产品规格。PRD 到底要放多少设计细节本就模糊，尤其是大项目，值得和团队明确。

在我们这里，PRD 的目标是为工程师与 UI 设计师解锁详细设计。后文的产品规格目标则是解锁实现。因此这里我们会重“做什么”，轻“怎么做”。我们会包含：

• 高层产品需求与设计原则。
• 细粒度产品需求——一份用例汇编（或故事汇编），记录用户想要的具体交互。
• 里程碑定义，用于选择首发要做哪些功能。
• 召集合适团队与相关方共同推进。（本书不展开。）

用例汇编

接下来我们进入产品需求本体。我称之为“用例汇编”，因为每条需求都从用户视角书写。常见模板有：

• “【用户】可以【动作】，从而【动机】。”
• “【产品】提供【功能】，从而让【用户】能够【获得价值】。”

每条需求都是我们某个场景的一段切片。以“客户硬件问题”场景为例——Sad Lisa 网速慢，需要重置无线路由器。

第一条需求是：当 Sad Lisa 寻求技术支持时，她无需先登录就能在首页轻松找到 Helpy。

需求写作的艺术在于：说清楚必须发生什么，但不要过度规定怎么做。以第一条需求为例，写它时我试图做到：

• 足够具体，表达清晰无歧义。比如明确“Helpy 在无需登录的首页可被找到”，而不是笼统写“Helpy 可发现”。
• 表达意图。我们不只是说“Helpy 在首页”，还要明确这件事是为了“可发现性”。如果放在首页做不到，工程师也能回到意图层面寻找备选方案。
• 仍给工程师留出设计空间。我们不规定 Helpy 必须在首页哪个位置或菜单，只规定它必须可发现且前登录可见。

有时很难既清晰又不规定过多，这时我会给一个示例，例如“在首页（例如右下角悬浮聊天按钮）”。

同一条北极星场景剩余需求如下：

• Helpy 能高效引导 Lisa 诊断慢网问题，原因覆盖软件、硬件与故障中断。
• Helpy 会向 Lisa 建议它从支持数据库学习到的最成功干预措施。
• Helpy 会询问 Lisa 哪些措施有效，以便在技术变化中持续学习。
• 当修复尝试结论不明确时，Helpy 能在结束聊天前建议后续跟进行动，避免 Lisa 放弃。
• 应向 Lisa 展示满意度调查，以便我们跟踪结果。
• Helpy 可以基于满意度调查进行训练，从而随时间提升效果。

其余北极星场景也可按同样方式拆分，逐步补全需求。随着思考与学习，我们也可以加入场景之外的新需求；如果漏了大项，还能补新的北极星；如果要降级优先级，也能删掉某些北极星。

我还从其他北极星中挑了几条，后面会讨论，它们与“责任委派”有关：

• Helpy 能以 95% 准确率判断请求属于支持还是销售。
• Helpy 检测用户沮丧情绪的能力至少达到人工坐席的 90%，并可转人工。
• 人工客服在接管对话时可咨询 Helpy，从而使人工支持效果至少不低于 Helpy 自己提供的水平。

这些百分比多少有些拍脑袋，我们现在也未必知道真实可达上限，但先给出粗量级。后续我们会通过一种叫evals的代理质量评测来约束自己。如果离这些数值差太多，我们会重新评估方案。

再补一条后面还会再提到的需求：

• Sad Lisa 可以在不使用家庭宽带的移动设备上使用 Helpy，以便在故障中断期间获得支持。

组织你的用例汇编

用例汇编通常会贯穿工程团队的优先级、设计与执行阶段。理想情况下我们会一次性前置挖完需求，但现实里随着迭代，常常还会新增。

这让用例汇编成为承重文档。对中大型项目来说，把它组织好、打好标签很值得。

如果你愿意，可以把每条需求转成规划系统里的工单——例如 Atlassian Jira 里的 Story 工单类型，每条就对应一条这种以用户为中心的需求。

也可以用电子表格，或像 Notion 这类带嵌入式数据库表格的应用，让汇编可排序、可筛选、可管理。它们也可以按原始产品愿景元素打标签。下面是一些建议标签或分栏：

• 人物画像（Persona）：本例中，按 Sad Lisa 的支持需求与 Tinker Tia 的销售需求分栏会更聚焦。你会看到，我们后面也会基于人物画像做优先级决策。
• 北极星场景（North star scenario）：便于查询“兑现某条场景承诺”所需的全部需求。
• 边缘情况（Edge case）：边缘需求很重要，但不需要所有人都读透。应允许筛掉。
• 里程碑（Milestone）：做优先级与路线图规划时会很有用。
• 状态（Status）：这张表甚至可直接用于项目追踪。
• 备注（Commentary）：按需补充信息。

表 7-1 展示了用例汇编。

表 7-1. Helpy 的用例汇编

我们已经在重索引之路上大步前进，不仅需求在重索引，我们的大脑也在重索引。你已经能开始看到如何把系统组件挂接到这些需求上，同时又不丢失最初“为什么要做”的理由。

但在开始详细设计前，我们还得先填上那列空白的优先级。

为首个里程碑做需求优先级

当我们与团队对长期需求达成一致后，下一步目标是制定路线图。也就是说，我们需要做优先级。

优先级是我们工作中最难且影响最大的部分之一，最后常常会有点混乱。每个人都有自己的“重要性”判断，也很容易分心。看看表 7-1：这还不到我若把全部内容写全时的一半规模。再叠加多里程碑规划、组织约束和代码库约束，确实会令人不知所措。

更糟的是，我们通常要先完成很多事，才能拿出一个能给用户看的版本。原因是后面要讲的四条“残酷真相”告诉我们：做出真正让用户满意的东西有多难。

我们需要一套策略。

首先，我会指出在众多互相竞争的关注点里，我们真正该优化什么。

接着，我会给出场景驱动发现中常见的一种优先级策略：首个里程碑聚焦单条北极星场景。

我还会主张一次只规划一个里程碑。

最后，我会把这套策略应用到 Kabletown 案例。

优先级里真正重要的是什么？

优先级背后最根本的两个因素是：用户影响（impact）和投入（effort）。

这听起来简单到几乎不值一提，但说起来容易做起来难。实践中，保持聚焦像走迷宫。其他优先级会不断渗入：处理人际冲突与组织问题、维护面子、兑现对特定客户的承诺、不同岗位激励不一致，等等。所谓“冷酷聚焦”，就是持续盯住“单位投入换来的用户价值”。

而“bang”和“buck”本身也不易衡量。

我认识的大多数工程师往往对 buck 或 bang 其中一项过度敏感。夸张地说，有的人偏向更快交付、少写代码、保持代码库简单可维护，即使这会让用户更难用或拉低采用；另一些人追求完美产品，愿意为此在底层付出任何代价。真正的智慧在于平衡二者。

下面我会先分别看用户影响与投入，再把它们合并。

优化 buck（投入）

尽管我很想做个纯粹主义者，说“唯一重要的是用户影响”，但投入水平同样重要。如果你的团队花了一千小时只给人类节省五百小时，你大概率并没有让世界变得更好。

工程师作为人类，通常对投入很敏感，所以我不用说太多。但有两点我想强调。

第一，如果它能建立相对竞品的优势，或能让用户眼前一亮，有时值得投入比“严格必要”更多的成本。比如你已有相当规模用户群，花一点时间为他们整体节省大量时间，通常是划算的。

第二，考虑总体成本，而不只是工程成本。而且这个原则是双向的。

工程师（尤其初级工程师）估算实现成本时，常只看 happy path 上生产代码规模。但防御性处理边缘情况呢？场景测试呢？以及文档、内部试用（dogfooding）、部署、A/B 测试、营销这些非编码工作呢？即使你无法精确估算，也应把它们纳入权衡。

一方面，考虑总体成本有助于避免范围蔓延。如果你心里冒出“这个加起来很简单”，不妨听听你身边那位友好 PM 的看法。他可能会告诉你，公司为了把它推出去并让用户看到，背后还有多少工作。

另一方面，也要想想如果你不做，总体成本会怎样。比如你决定不给 Helpy 增加程序化护栏来避免它说出不该说的话，就可能把压力转嫁给用户支持、公关和法务团队，让他们准备 Helpy 失控时的应对策略。

优化 bang（影响）

如果你想数学化一点，用户影响等于覆盖规模（reach）与单用户价值（value per user）的乘积，再乘上你选定时间窗。

用户影响可以用效用函数（utility function）估算：它描述“产品包含哪些功能”与“用户获得多少价值”之间的关系。随着产品变好，效用函数应上升。

但典型效用函数的数学形态非常残酷，这意味着你必须先做很多事，才会产生显著影响。

关于为用户构建有价值产品的难度，有四条严酷教训，也就是“四条残酷真相”：

1. 规模很难。
2. 用户价值是后置兑现的。
3. 竞争差异化的后置性更强。
4. 价值的长期维持很难。

规模很难

做出高 Impact、高 Scale 的产品很难。做出一个对少数人深度有用的东西并不难；但要打动大量用户，就得同时做到可发现、有用、易用、营销到位、可规模化稳定运行等等。反过来，你可以轻松改首页字体，这种改动覆盖广，但价值不高。

用户价值是后置兑现的

产品不断加功能时，效用函数并非线性增长。很多产品在功能到达临界质量前几乎没用。自行车得同时有两个轮子、刹车、可转向车把和上坡换挡，才真正有用。

图 7-4 展示了自行车的效用函数：

图 7-4. 随功能增加而变化的自行车效用函数

这种“前期平坦、后期陡升”的模式是效用函数的典型特征。最初一些功能可能只是“打勾项（checkbox features）”，不必做得惊艳，但必须存在，否则多数用户根本用不了。除非你想冒生命危险，否则你需要刹车。除非你专门练独轮平衡，否则你需要第二个轮子。除非你在骑场地赛，否则你会希望能换挡。

竞争差异化的后置性更强

第三条真相是：竞争会施加额外压力。除非你在发明全新品类，否则进入一个市场时，通常要先攒到某个功能临界值，别人才会认真看你。然后你还得再提供额外优势，比如新功能或更低成本。有时你甚至是在重写自己的产品，与过去版本竞争。

我把它叫做替代产品之上价值（Value over Replacement Product, VORP）¹。计算 VORP 时，需要把市场上已有产品，或你正在构建产品的旧版本价值，从你的效用函数里扣掉。自行车案例的曲线大致如图 7-5。

如你所见，VORP 转正晚于简单用户价值。这要求我们做的不只是“有用”产品，而是“特别”的产品。对于 Helpy 而言，我们不仅在和现有自动化系统竞争，也在和真人客服竞争——这确实挑战很高。再往后，随着 AI 技术成熟，市场对助手表现的预期也会持续提高。

图 7-5. 随功能增加而变化的自行车“相对替代产品价值”函数

长期维持价值很难

第四条也是最后一条残酷真相与时间维度有关。持续提供长期用户价值，比获得短期胜利更难。做一辆便宜但容易坏的自行车，或一辆不够舒适、难以让用户持续使用的车，都比做一辆用户愿意骑很多年的车容易。同理，Helpy 若想持续有帮助，就必须持续摄入更新的支持数据，并被持续监控性能退化。

由于这四条残酷真相，大多数产品和功能之所以无法产生巨大影响，是因为“烤得不够熟”——要么缺了关键功能，要么没按可规模、可长期维护的标准工程化。

残酷真相提醒我们不要“欠工程”，那“过工程”呢？同样要避免：过度打磨、一次追太多目标或选错目标、入场太慢、资金耗尽、或让自己长期缺乏用户反馈。

正如我在第 6 章提到的，我们可以找到被现有方案服务不足的目标受众，他们会为了“真正为自己而做”的东西容忍功能缺失。

另一条常见优解是迭代产品，正如第 5 章所讲。迭代时，我们会暂时忽略一两条残酷真相，但沿途仍在学习。

沿着这个思路，我们来讨论首个里程碑优先级。

合并 bang 与 buck

许多团队会从最小可行产品（MVP）开始。我将 MVP 定义为：效用函数明显转正的那个点，即便它可能只服务一个较小目标受众——先暂时忽略残酷真相 #1（规模）。

你也许听过最小可爱产品（MLP）这个词。它越来越流行，是对 MVP 常常“太糙”的一种反思。

在竞争环境里，把 MLP 理解为 VORP 明显转正的点会更有帮助。MLP 与 VORP 绑定，因为人们通常只会爱上并依赖高 VORP 产品。只有打勾项功能的自行车，除非那是你的第一辆，否则你不会爱上它。

用残酷真相来讲，MVP 聚焦 #2（用户价值），MLP 则对应 #3（差异化价值）。

下面我会展示如何用场景驱动发现来定位 MVP 或 MLP。

为首个里程碑定义目标北极星场景

在使用 SDD 时，你可以通过优先化“某一条北极星场景”或“最小必需场景集合”的需求，来定义你的最小可行/最小可爱产品。

聚焦北极星场景有不少好处：

• 因为北极星是完整故事，我们会交付正向效用。
• 因为它包含最佳产品愿景，我们会为某些人交付正向 VORP。
• 因为它只聚焦一个人物画像和一条故事，我们可以先去掉额外功能，把泛化推迟到后续。

我们还可以进一步收窄早期目标受众。最常见做法是限制为可参与内部试用（dogfooding）的员工（第 4 章），或愿意容忍早期版本以换取产品影响力/白手套支持的设计伙伴。另一个选择是限定单平台用户，比如 Android 而非 iOS，或者限定不太需要引导的高级用户。

在这些限制下，我们一开始甚至可以省略北极星场景的部分片段。比如目标是公司员工时，若故事里有“用户如何发现该功能”的步骤，我们可以先用发邮件请同事试用来替代。

最后，我们准备好给单条需求做优先级了。

对用例汇编做优先级

我们进入一场大型会议讨论优先级。也许技术负责人或 PM 已先给出一些初始草案。

好在我们已经按场景与人物画像给表格打了标签，判断哪些该进、哪些该出会相对直接。

按我的经验，只聚焦首个里程碑会高效得多。为了争论“某个不在 MLP 里的条目是 P2 还是 P3”而陷入细节，往往是一小时的纯浪费。

这里有个简单格式：

• P0：MVP 必须项。没有它就无法发布或获得用户反馈。
• P1：MLP 必须项。它们是极具吸引力的冲刺目标，通常在临近发版时执行。如果进度滑坡且又必须按时结束，你会不开心，但仍能发布一个可行版本。
• 空白：其他全部。规划下一里程碑时再排。

如果你们按里程碑推进，这里有个便于复用优先级汇编的方案：

• 0：纳入里程碑 0。
• 0.5：里程碑 0 的冲刺目标。

其余保持空白。等规划下一里程碑时，再分别加 1 和 1.5，对应里程碑 1。

这里我采用里程碑格式，因为它鼓励我们把产品路线图持续维护在一份易于查找的文档里。

我们的大多数员工家里都用 Kabletown，所以首个里程碑先限制在 Kabletown 员工，他们更宽容，也会给出更有质量的反馈（第 4 章）。这样我们可以先发布 Helpy 学习，再去做完整打磨。面向员工的首发因此是 MVP，而非 MLP。

该选哪条场景？这里有几个考虑：

• 我们应把 MVP 限制在“支持场景”或“销售场景”之一，这样能省掉给 AI 供训练数据以及为另一个方向做测试的大量工作。
• 若选常见或高影响场景，效用函数的跃升会更高。假设现有交互里多数来自技术支持，尤其是用户认为网络不通或变慢。
• 假设数据还显示，大多数技术支持流量来自桌面和笔记本，而非移动设备。（我并不知道现实中是否如此，但先这么设定。）

“客户硬件问题”场景符合以上条件。这是一个内容很扎实的支持问题，足以充分检验我们助手的 AI 能力，也能验证方向对不对。

因此我们更窄的目标人物画像是：“Sad Lisa，Kabletown 员工，拥有 PC。”这样的人不算多，但我们希望她会喜欢 Helpy 并提供高质量反馈。

不巧的是，Kabletown 正在做网站框架重构，这意味着若先做 PC，我们可能要多投入约一周工程时间。那要不要改做移动端？

从总体成本看，对 Kabletown 这种流程繁复的大公司来说，多一周工程可能不是大事。这仍只是发布总成本中的一小部分。

如果 PC 和移动端使用量大致相当，当然可以优先移动端。但若 80% 支持交互都来自 PC，恐怕还是应该接受多这一周工程工作。

我们每一步都聚焦价值。我们不希望假设自己一定能跑完整张路线图——Kabletown 的管理层很容易被其他事分散注意力，如果在交付高价值成果前团队就被抽走，那会非常糟。

表 7-2 展示了按优先级排序后的用例汇编，以及我为何做出某些看起来反直觉优先级的脚注说明：

表 7-2. Helpy 的优先级用例汇编

现在看看我们的北极星场景是否经受住了优先级筛选。下面我会划掉任何被降级或改成冲刺目标的部分：

• 客户硬件问题：Sad Lisa 的网络很慢，她认为是 Kabletown 的责任。她在 kabletown.com 看到了 Helpy 的“获取支持”按钮并点击。Helpy 询问她的设备环境，识别到她在无线网络下使用 PC 笔记本。它判断没有区域故障后，引导她执行一系列诊断与建议，从历史最成功方案开始，包括重置无线路由器、运行 Windows 网络诊断等。重置 Kabletown 提供的无线路由器后问题解决。Helpy 告知她若问题持续可再次联系（例如路由器硬件故障），随后发起满意度调查，她给出了高评分。

还不错！改动都很小，调整后的故事依旧有说服力。

当我们结束发现、进入设计阶段前还有最后一步：写出详细用户流程。

为首个里程碑构建详细用户流程

我们前面讲的故事都比较高层，省略了大量细节，以至于可能漏掉关键问题。

我们也刻意确保故事更多在描述“做什么”而非“怎么做”。现在我们仍需要试演不同方案，看用户如何完成这些故事。比如 Helpy 可以替用户运行 Windows 诊断，也可以只告诉用户怎么做；它可以在对话里内联提问做调查，也可以给独立调查表链接，等等。

现在我们来细化用户流程。

本节我会演示如何创建用户流程，然后如何和用户做验证。

在做这件事时，我们会从发现逐步进入定义：一方面仍在这些练习中学习新需求，另一方面也开始定义产品本身。

在做 UI 设计时你可能听过用户流程，通常也叫“分镜图（storyboards）”。它可以是一组 UI mock，模拟用户点击过程。

如果我们的界面不是图形 UI 而是代码，那流程就会是代码清单与命令行的组合，中间穿插说明文字。

下面是一些关于编写流程的高层建议：

• 用户流程应足够细，以便我们围绕关键交互问题展开讨论（第 8 章），并从中提炼清晰系统规格（第 9 章）。
• 与选择北极星时一样，要比较不同方案。可以头脑风暴，也可以给出多个用户流程备选，让团队帮助你做选择。这是引入多元观点、并让大家知道你并未绑定单一路径的好方法。
• 把主要精力放在首个里程碑，以及那些虽未优先但你认为必须尽早搞懂、才能形成整体设计的事项。
• 和任何场景一样，用户流程应讲完整故事：从用户动机与其如何发现功能讲起。

我们来为 Kabletown 的一条需求写流程，即：“Helpy 可以从支持数据库学习最常见干预措施，并推荐给 Lisa。”

我们最初训练 Helpy 的效果并不理想。遗憾的是，遗留系统里我们从未给支持数据库做过标注，因此根本不知道技术支持问题中最常见有效修复是什么。最可能的办法是：回看成千上万条历史支持请求，并按“有效干预措施”或“结论不明确”进行分类。我们还希望标注支持人员当时的推理过程，让他们的经验能教会 Helpy。

下面是一个新人物画像 Support Rep Sam 的用户流程。我们要努力让他愿意做大量标注：

1. Support Rep Sam 收到老板邮件，要求他在下个月内给自己过往 50 条客户聊天做标注。
2. 他很忙，但老板提了，于是打开内部工具。工具先带他进入一条旧支持线程，让他回看并回忆当时是如何修好的。
3. 他看到一个标签下拉菜单，如“重置路由器”“扫描恶意软件”“重启机器”等。若没有匹配标签，他也可新增，之后其他支持同事也能看到该标签并使用。
4. Sam 还需要补充说明为何选择这组建议顺序。他输入：“我先重启路由器，因为用户有两台设备都离线，看起来不像是单设备问题。”
5. 他提交后，系统将他带到下一条聊天线程。
6. Sam 在回家前处理了十几条。几天后，他又收到催办邮件提醒继续标注，点开链接后又完成了几条。

我们也可以写一版 AI 辅助流程：

1. AI 扫描一千条聊天，提取它认为每条里的修复措施与推理过程。
2. Sam 收到老板邮件，要求他核对 AI 对其过往 50 条聊天的解读。
3. Sam 打开某条聊天后，系统直接问“AI 的判断是否正确”。他可以点击Yes，或直接在行内修改 AI 的结论与理由。
4. 他提交后，系统带他进入下一条聊天。
5. 与此同时，新选择会反馈给 AI。第二天夜里，AI 会基于这些反馈重训。
6. Sam 发现 AI 有四分之三时间是对的，因此他在半小时里轻松处理了 30 条。

我们会与团队讨论并确定方案。对方案有信心后，我们可以交付配套分镜图。也可以把这些流程拿给几位支持人员看，做个临时可用性研究：“你会愿意这样用吗？你还希望有什么功能？”

用户流程画出并验证后，发现阶段就告一段落，至少在我们学到新遗漏之前如此。

验证用户流程

对于关键界面，你会希望和真实用户做验证，确认其可发现、直观，并覆盖了最重要用户需求。

我会讲两种实践：征求意见稿（RFC）与可用性研究。

征求意见稿（RFC）

如果你的主要目标是确认功能在真实世界里做对了事，可以创建一份 RFC 文档，给潜在用户看分镜图，问这个场景是否有用，并请求他们对设计反馈。

考虑到我们在设计的是一个服务少量员工的短期内部工具，这大概就是我们会采取的方式。我们会把 RFC 发给几位支持坐席，让他们指出功能缺口、标出困惑点、补充我们可能漏掉的日常流程细节。早期咨询这些支持员工，也有助于我们提前评估：他们会不会对新增工作产生抵触。

但 RFC 的局限是：我们其实已经把“答案”给他们看了。如果不先给答案，我们往往能得到更多洞察。

可用性研究

可用性研究会让受访者基于可运行原型完成任务，从而暴露大量问题，如可发现性、易用性和功能缺口。

你可以安排几场访谈，通常通过视频进行，并准备一系列希望受访者完成的任务。

你的可运行原型应当看起来能完成这些任务目标，同时允许其他功能仍未实现。很多设计工具都能制作这种原型，甚至有些工具可基于现有应用或其截图，快速生成带新功能原型的改版。

访谈开始时：

• 先让受访者放松，并说明流程。
• 请他们在使用功能原型时“边操作边说出想法”。
• 告诉他们可以提问，但你可能不会立刻回答。

然后你给出任务，也就是关键用户流程中的“动机”部分。这里你可能会说：“你被要求给一条历史支持线程标注问题类型和有效修复措施。请共享屏幕，并用这个可点击原型尝试完成任务。”

除了呈现用例外，尽量不要给额外引导。如果确实需要回答问题，把问题记下来，后续用于调试流程。

我非常建议你抓住机会参与一次可用性研究。我第一次做这件事，是给我在微软写的一个 C# API 做研究，那次经历非常打脸。看着程序员在我以为“很好用”的地方频频受阻，让我真正意识到 API 设计这门学问有多深、多难。

把用户流程翻译成待完成工作

我们大重索引的最后一步，是写出需要构建的组件与功能。这些有时称为待完成工作（jobs to be done）。

用户流程可以被翻译成待完成工作，方式与北极星场景拆解成需求类似。

例如，如果我们决定让 Sam 手工标注他所有历史支持聊天，可能要构建以下组件：

• 用于标注聊天的内部工具
• 一张可编辑的标签数据库表
• 一张用于存储“标签 + 自由文本”标注结果的数据库表
• 让 Helpy 联合摄入“聊天历史 + 标注结果”的数据流水线
• 按员工追踪其是否完成 50 条标注目标的进度系统

到这里，大重索引完成！我们已成功把“以用户/时间线为中心”的产品视图，转换为“以系统/图结构为中心”的视图，至少在高层层面如此。

在第四部分中，我们会把注意力转向这些组件与系统的设计。

反哺需求文档

任何人都不该期待一条从发现到设计、单向流动的优雅瀑布。现实更像潮池，潮涨潮落，不同水体彼此混合。即便在为某些方案做设计，我们仍可能偶尔要补新的场景。

也就是说，北极星场景列表和用例汇编都应该是“活文档”，需要持续更新。

比如我们准备在技术支持能力之上，再给 Helpy 增加销售场景。这会拉伸它的能力边界，因为我们要给它更多知识并开放新工具。

我们的某条需求是：

• Helpy 能以 95% 准确率判断请求属于支持还是销售。

但我们真的想透了吗？

2025 年代理设计中的一个现实是：对于复杂代理，采用“多个专长代理混合”通常比“一个全能大代理”错误更少。在本例里，我们可以做一个技术支持 assistant 和一个销售 assistant，再由 Helpy 作为礼宾代理（concierge agent）负责对外沟通、规划，并把任务分派给各 assistant，如图 7-6所示。

图 7-6. 两个专长助手与一个代理的混合模式

现在我们要批判性审视这个设计，并构造可能把它“打爆”的故事。比如用户提出一个技术支持问题，而真正解决方案是升级设备。此时 Helpy 在一次会话里可能不该只委派给一个 assistant，而是需要同时咨询两边。

如果我们前期没意识到这一点，现在就是补写新用户故事并让它重新走一遍大重索引的时候。

本章小结

我们已经把“以场景表达的产品愿景”推进到了“接近传统实现需求”的形态。在场景驱动发现的指导下，我们对成功更有把握：

• 因为所有人都能读故事，沟通质量更高。
• 因为我们聚焦北极星场景要素，不会浪费时间。
• 借助人物画像和北极星场景，我们既保留长期愿景，又只执行一个增量里程碑。这让我们在更整体策略下保持聚焦优先级，知道自己正朝着一致目标构建。
• 我们依据成本与用户价值来选最高优先级，并清楚四条残酷真相——Helpy 需要在多个维度都足够强，才能给终端用户真正交付价值。
• 上线后，我们预计用户反馈不必触发大改版，因为团队在北极星场景与用户流程中主动找了情节漏洞，并通过 RFC 与可用性研究验证了用户流程。
• 当进入设计与实现，我们会在编写场景测试时回看用例汇编与用户流程，并把北极星场景做成演示。

如果你还没尝试过，我希望你试试 SDD。上手后，写故事会很有趣，尤其是团队一起写。而且它可能带来十倍回报：你会用更少尝试就交付到正确产品。

练习

1. 在 2010 年代到 2020 年代初，Visual Studio Code 通过优秀的扩展发现机制赢得了数百万开发者的心，例如 lint、语法高亮和测试框架扩展。请为这个主题写一条北极星场景，真正把“扩展发现”卖出去。如果你不熟悉 VS Code，可想象一个 IDE，提供“扩展市场（extensions marketplace）”以帮助你找到合适工具。
2. 把你的场景——或者如果你想对比答案，也可以用我在上一题给的场景——拆成高层产品需求。尽量不要对具体设计元素规定过多，以便后续写用户流程时有更大灵活性。
3. 指出几个边缘情况，补充到上述需求中，它们可能没有被北极星场景直接覆盖。同样，尽量保持高层表述。
4. 写一个用户流程，满足“发现高口碑扩展”的产品需求。

参考答案

1. 开发者 Deanna 打开某个 Python 仓库的 Visual Studio Code。她刚接触这个仓库，Python 经验也不多。好消息是，仓库维护者提交过一个代码格式化器推荐，所以她会收到一个弹窗建议安装。与此同时，由于源码主要是 Python 文件，系统向她推荐 Python 语言服务器和调试器扩展——这些扩展下载量高、星级高，她安装后立刻进入正确轨道。最后，她去扩展市场“逛店”，并配置了一个口碑不错的 AI 编码助手。
2. 用户可以编写并提交一份推荐语言扩展列表，帮助队友在 clone 仓库后快速进入状态。 应有一个扩展库或商店，按流行度与评分排序，帮助新接触某语言或仓库的用户找到最有效选项。 应主动向用户展示推荐扩展，让新用户即使此前不了解扩展也能快速上手。 用户可以按描述、关键词和名称搜索扩展市场，从而既能找自己偏好，也能发现尚未高排名的新扩展，例如新型编码助手。
3. 当队友更新推荐时，用户应主动看到新推荐提醒。 用户可以拒绝安装某些扩展，VS Code 应记住其偏好，避免重复提示已拒绝扩展。 用户可以配置“按仓库”扩展或“全局”扩展，以适配不同仓库可能存在的代码格式规范差异。
4. 开发者 Deanna 打开一个新仓库。VS Code 识别到这是她第一次接触该仓库，于是弹窗提示她查看扩展。她可以点 X 关闭，或点“前往扩展市场”。她点击按钮后，看到一组推荐扩展：按仓库语言适配过滤，并按流行度与评分综合排序。每个扩展都展示名称、简述、下载量、星级，以及两个按钮：install 与 learn more。她点击 Install 后，会弹出一个页面，展示作者提供的使用说明，并显示该扩展下载进度。