Prototype、MVP 和正式产品承担不同任务

产品范围和交付规格写清以后，还要回答一个实际问题：首版应该先让用户经历什么？

功能列表可以继续缩减，用户获得价值的链路却不能断。一个只有登录、设置和空白工作台的产品，即使代码完整，也没有完成验证。相反，一项只支持一种输入、一个核心动作和一种输出的工具，只要真实用户能用它解决问题并愿意承担价格或使用成本，就已经提供了更强证据。

MVP 的重点是用最小范围完成一次价值交付。它需要让目标用户从入口走到核心结果，也需要处理这条路径上最基本的失败。界面可以粗糙，功能可以有限，产品承诺不能停在半路。

这三个阶段经常混在一起。

Prototype 用来表达机制。它可以是一张原型、一个可点击演示、视频或手工模拟，帮助团队和用户理解产品会怎样工作。它不一定处理真实数据，也不一定稳定交付。

MVP 用来验证价值。目标用户可以提供真实输入，完成主要任务，获得可使用的结果。部分步骤可以由人工完成，支持范围也可以很窄，但用户需要知道实际能力和限制。

正式产品 需要在更大范围内稳定交付，包括性能、权限、数据、支持、维护和规模条件。它通常会覆盖更多用户状态，也会降低后台人工比例。

三者不按视觉精致度区分。高保真 Prototype 仍可能没有真实交付，一页简陋工具也可能已经完成一次真实任务。判断时可以检查：

• 用户是否提供真实输入；
• 输出是否进入后续工作；
• 结果是否达到可用标准；
• 失败和限制是否清楚；
• 用户是否付出时间、数据、信任或费用；
• 团队是否获得了可以改变决定的新证据。

MVP 不需要假装成成熟产品。手工步骤、有限格式和等待时间都可以如实说明。隐藏后台人工或夸大自动化，只会让后续付款和留存失去解释力。

从产品承诺反推第一份结果

最短价值路径不能从现有页面开始画，应从产品承诺向前倒推。

假设产品承诺「帮助每周发布新品的小团队，把商品原图处理成可以直接上架的图片」，第一份核心结果应当是一组符合商城规格、可以下载并进入上架流程的图片。注册账号、选择主题和观看教程只是中间步骤。

倒推时可以依次回答：

1. 用户第一次确认产品有用时，手里多了什么结果；
2. 为得到这个结果，最后一个必要动作是什么；
3. 这个动作需要哪些最低输入；
4. 输入由用户提供，还是可以使用示例；
5. 哪些身份、配置和教学必须发生在前面；
6. 哪些信息可以等用户获得价值以后再收集；
7. 入口怎样让用户理解结果和下一步。

由此可以得到一条路径：

理解产品承诺
→ 提供最低必要输入
→ 完成一个核心动作
→ 看见并确认结果
→ 把结果带入下一步工作

每增加一步，都要问它是否为了完成本次结果。如果只是方便团队收集资料、推广其他功能或提前配置未来能力，可以考虑延后。

最小范围仍然需要质量底线

MVP 经常用「以后再完善」解释当前缺口。真正可以延后的内容，是不会破坏本次价值结果的扩展；直接决定结果能否使用的质量不能一起延后。

可以把首版内容分成三类：

结果必需

没有它，用户无法完成任务。例如文件工具的格式校验、处理、预览和下载；线索产品的来源、基本相关性和可进入跟进的联系信息。

安全必需

发生问题会造成付款、数据、隐私或不可逆损失。例如重复扣费保护、删除确认、权限检查、失败说明和必要的数据隔离。它们可能不会出现在宣传页面，却属于首版底线。

扩展体验

用户已经能得到结果，增加后会更高效或覆盖更多场景。例如批量操作、更多模板、高级设置、多人协作和第三方集成。这类能力适合在真实反馈以后排序。

首版的质量门槛还与承诺有关。页面若只承诺处理一种文件，就应把支持范围和输出质量做好；若承诺「一站式处理所有资料」，范围和验收会迅速扩大。MVP 需要通过缩小承诺控制工作量，不能通过降低已承诺结果的可靠性控制工作量。

已知限制应放在用户做决定的地方。输入格式、等待时间、人工审核、语言质量和数据保存条件，都不宜等失败以后才出现。

先定义「价值事件」，再定义 Aha Moment

Aha Moment 通常指用户第一次真切感到产品能够帮助自己的时刻。它带有主观体验，产品分析仍需要找到一个可以观察的行为作为近似。

定义时可以分成两层：

用户价值描述

用自然语言说明用户意识到了什么。例如：

• 第一张漫画图片完成翻译，并保留气泡中的版式；
• 第一份真实文件处理完成，输出可以继续使用；
• 第一个候选人完成筛查，招聘方得到可判断的报告；
• 数据绑定到界面，用户在预览中看见自己的应用开始工作；
• 第一条合格线索被验证，并能进入销售跟进。

可观察的价值事件

将体验转成可以记录的动作与条件。例如：

用户上传真实文件
+ 处理成功
+ 打开或下载结果
+ 未在短时间内因质量问题重试

单个按钮点击通常太弱。点击只说明动作发生，无法证明结果可用。价值事件需要尽量接近产品承诺，同时保持可稳定记录。

首次价值也不一定只有一个事件。协作产品可能要等第二个角色加入并完成一次共同任务；市场产品可能要等供需双方完成交易；低频服务则可能以验收成功作为价值事件。不同产品不能套用同一个激活阈值。

从假设开始，不把团队定义当事实

Aha Moment 最初只能是一项假设。团队通常根据产品价值、早期访谈和使用观察选择一个候选事件，再检查它是否真的与用户体验和后续行为一致。^[1]

验证可以使用三类证据：

1. 访谈：用户第一次觉得产品有用发生在哪一步，为什么；
2. 行为：用户在路径中完成、重复、停留和离开的动作；
3. 后续结果：到达该事件的人是否更常继续使用、付费、复购或推荐。

三类证据需要相互解释。用户可能在访谈中喜欢一项功能，却没有在真实任务中使用；完成某事件的人留存更高，也可能因为他们本来就是需求更强、能力更高的用户。

Momen 的案例把「把数据绑定到 UI，并成功预览效果」作为 Aha Moment。某版引导中，完整走完的人相对跳过者留存天数高约 50%，团队因此继续缩短路径。^[1] 这是一个版本中的相关观察。完成引导的人可能原本投入更深，不能据此断言引导单独造成留存变化，也不能把 50% 当成其他产品的预期。

更稳妥的说法是：该事件与价值承诺接近，也与后续使用出现相关，因此值得继续测试。随后还要通过路径调整、分组比较和访谈检查因果解释。

排除几个常见的假 Aha Moment

团队容易选择最方便统计的事件，并给它加上激活名称。下面这些行为通常只能作为中间信号：

中间信号仍然有用。注册完成可以诊断入口，教程观看可以诊断教育，按钮点击可以诊断交互。问题在于不能用它们宣布价值已经发生。

候选事件还要排除团队强制制造的行为。如果 Onboarding 不完成就不能进入产品，完成率只说明用户通过了门槛。团队需要继续看之后是否成功，以及跳过或简化以后会发生什么。

入口本身属于价值路径

用户在进入产品以前，先要判断是否值得投入时间和资料。如果落地页没有说清结果，最短路径会在第一步中断。

入口至少需要回答：

• 产品帮助哪类人；
• 解决哪项具体问题；
• 用户会得到什么结果；
• 大致怎样工作；
• 为什么可以信任；
• 下一步应该做什么。

Landing Page 的首屏可以采用一个清楚价值主张、一句补充解释、一个主要 CTA 和第一组可信证明。^[2] 漫长功能清单无法代替结果说明。内容型旅游产品的现场诊断就显示，用户进入 Dashboard 以后才理解产品提供什么，首页没有先解释海外游客的信息缺口。^[2]

早期可以用软发布检查入口。页面在产品完成前接入 Waitlist、表单或手工服务，通过回放、访谈和 CTA 行为观察用户是否理解价值。^[2] 这一步验证的是表达和兴趣，仍不能代替真实产品使用与付款。

入口到价值事件之间还包含信任。需要上传敏感文件、学习复杂工具或接入业务账号时，用户会评估案例、隐私、团队、文档和可退出性。为了追求路径短而删掉必要说明，可能反而提高离开率。

画一张最短价值路径表

可以把当前路径拆成一张表：

表中的「团队要求」很重要。团队为了统计渠道、建立客户画像或完善账号资料，可能在价值前收集大量字段。用户却只想尽快完成任务。二者冲突时，优先保留完成和安全所需的最低信息。

每一行还可以记录事件、流失人数和对应访谈。这样产品改动能针对具体阻力，而非笼统地「优化 Onboarding」。