MVP、产品设计与落地
本章导读
上一讲结束时，研习团队写完了一页《产品定位与取舍》。定位很清楚：服务愿意记错题但嫌抄写费劲的重做题用户，在每天结束学习后的十五分钟内，把错题低成本归集、并自动进入复习计划。核心能力不在识别，而在「归集后进入复习计划」这条连接。
定位一清，团队松了一口气，也顺手做了一个看起来很顺的决定：既然方向对了，那就把完整功能一次全做完，尽快上线。这个决定，正是本讲要说的那一类坑——而且是最贵、最不容易察觉的一种。
这一讲就跟着他们把三个月走完。你会看到，一个方向正确的产品，怎么因为「一次全做完」而失败到无法解释；然后反过来学会：先写最危险的假设，再倒推一个只验证这一个假设的最小产品，把复杂业务拆成能讨论的东西，最后用阶段评审、决策记录和灰度回滚，把判断安全地交给团队。
最后落成的东西，是一页《MVP与交付方案》。下一讲《指标、实验与效果评估》会从灰度的监控指标接下去，把一组数据变成「继续、调整，还是停止」的判断。
说明：本讲的故事、角色和数字都是教学案例或教学假设，只用于演示推理。除来源一节列出的腾讯公开材料外，不指向任何真实产品或腾讯数据。
开篇：一次做完，失败无法解释
定位写清后的第二天，小林把团队拉到一起，说：「方向定了，我们把 V1.0 一次排出来。」
白板上很快排出了十一项功能：拍照识别、手动录入、自动归类、错题去重、复习计划联动、错题详情编辑、错题导出、学习提醒、统计看板、权限设置和数据导入。每一条都是前几轮会上提过的、看起来合理的需求。
大鹏扫了一眼，说：「三个月能做，但中间得砍需求。」老周没接话，已经在笔记本上列埋点方案。阿May更干脆，当天就把宣传文案的初稿写了出来，标题是「拍照记错题，复习不重复」。
三个月后，V1.0 灰度上线，覆盖约五千名用户。
结果不理想。老周把数据投到周会屏幕上：真正用过归集功能的只有约三百人，占百分之六；其中约七成只归集一次，之后就没有再回来（教学假设）。
会议室里又是一片安静。小林盯着那百分之六，说：「至少说明有人用吧？」老周摇头：「也可能说明，我们同时验证了十一件事，结果哪一件都没验清楚。」
确实，同样一组数据，至少能讲出四种完全不同的解释。
第一种，识别准确率不足，用户上传后发现还要手动改，就不再用。第二种，用户不信任自动归类，担心错题被分错科目，影响后续复习。第三种，复习计划联动没有价值，用户只想保存错题，不想要额外的排期和提醒。第四种，功能太多，核心入口被淹没，用户根本没找到归集该从哪里开始。
四种解释指向完全不同的修复方向。继续优化识别，只服务第一种解释；把统计看板藏起来，只服务第四种。团队缺的不是更多功能，而是没有在开发前，把最关键的那一个假设单独验证出来。
先看最省事的做法：一次把功能做完
团队最直觉的做法，就是把完整功能一次做完。这样做不是没有理由：一次性对接能减少反复沟通，界面看起来也完整，上线时更有底气。
这种做法在一种条件下有效：最关键假设已经被证明为真，剩下只是把已知正确的功能补齐。这时一次做完，能更快把整体跑起来。
但它在另一种条件下失效：最关键假设还没被验证，一次交付又叠加了多项新功能。这时一旦失败，就会有很多种解释，团队无法把结果归到任何一项假设上。研习正处在这种失效条件里。
一个产品如果只有一条新路径，上线后数据不好，你至少知道该怪谁。可当它同时包含识别、联动、导出、统计这么多新东西，数据不好时，你能怪的就太多了。怪得越多，越不知道该改哪一处，最后只好再开一次会，再列一份功能清单。完整，有时只是把「不知道问题在哪」这件事，包装得更体面了。
最危险的假设，比功能清单更重要
完整功能做不完不可怕，可怕的是做完了，却不知道哪个判断被数据反驳。因此开发前要先写最危险的假设。
对研习来说，最危险的假设不是「识别接口能否接入」，而是「重做题用户是否愿意为‘归集后自动进入复习计划’改变行为」。如果用户只保存错题、从不打开复习计划，后面所有联动功能都没有意义，识别做得再准也是白费。
最危险的假设通常有三个特征：如果它错了，整个方案就失去价值；它的结果能用一个可观察行为判断；它还没有被现有证据充分支持。
写这条假设，其实是在逼我们承认一件事：这个项目里，最该被先验证的，不是工程能不能做，而是用户愿不愿意为它改变。
把所有还没被证实的假设列出来，逐个问两个问题：如果它错了，方案还剩下多少价值；它的对错，能不能用一个看得见的用户行为来判断。剩下价值越少、行为越容易观察的那一条，就是最危险的假设。它通常不是技术问题，而是用户会不会真的改。
MVP 不是少做功能，是只验证一个假设
MVP（Minimum Viable Product，最小可行产品）的任务，是用尽量小的实现，区分几种可能解释。它和「功能少的完整产品」是两回事。
如果关键假设是「用户愿意把归集后的错题放进复习计划」，第一轮甚至不需要自动识别。我们可以让十位重做题用户上传错题图片，由人工和模型共同完成归类，用户确认一次后自动进入复习计划，再观察多少人愿意确认、次日是否回来复习、修改集中在哪里。这个版本不能规模化，却能验证产品最重要的价值判断。
MVP 需要回答四个问题：当前最危险的假设是什么；什么行为能够支持或反对它；最小实现需要保留哪些真实条件；哪些功能暂时不会影响判断。
对研习的 MVP，答案是：假设是用户愿意为归集后进入复习计划改变行为；支持行为是确认归类并次日打开复习计划；必须保留的真实条件是错题来自用户真实练习；暂时不做的是识别免确认、导出、统计看板和权限设置。
注意，这里「不做自动识别」不是因为它不重要，而是因为这一轮的关键判断不依赖它。把识别留到下一轮，失败时才不会把「识别不好」和「用户不愿改」混在一起。
把复杂业务拆成可讨论对象
腾讯大讲堂的 0 到 1 方法将产品工作整理为确定目标价值、抽象问题、拆解问题、归纳模块，再形成需求文档。这套方法的核心，是让团队能在同一个语言体系里讨论，而不是各说各话。
所谓抽象，就是先确认系统里有哪些对象和角色。研习的归集流程包含用户、练习、错题、归类、复习计划和提醒。
所谓拆解，就是说明对象怎样变化。练习提交后产生错题；错题被归类；归类经用户确认；确认后的错题进入复习计划；复习计划生成提醒。
所谓归纳，就是把重复能力合并成稳定模块。不同来源的错题都需要采集、归类、确认和进入计划，可以归入错题采集、归类确认、计划联动三个模块，而不是为每一项功能单独写一套。
对象拆解的价值，是让团队在讨论「识别出错怎么办」时，能精确指到「错题采集」这个对象，而不是笼统地说「功能有问题」。一旦问题能被指到一个对象上，修复范围就缩小了。
阶段评审关卡：进入更贵阶段前先看证据
《腾讯产品18讲》的产品落地部分提到分阶段关卡。公开笔记没有提供适用于所有腾讯业务的统一定义，因此本课程不照搬关卡名称，而保留其核心思想：每进入更昂贵的阶段之前，都要检查上一阶段的关键证据。
| 阶段 | 进入下一阶段前要看到什么 |
|---|---|
| 问题验证 | 用户问题、场景和替代方案证据 |
| 方案验证 | 原型任务能否完成，关键风险是否暴露 |
| 开发准备 | 主流程、异常、数据上报和验收标准 |
| 灰度发布 | 目标人群、放量规则、回滚条件和监控 |
| 正式发布 | 指标变化、用户反馈和下一轮决策 |
这张表是本课程基于腾讯公开流程材料所做的教学整理，不是腾讯内部制度的逐字转录。
研习的 MVP 在「方案验证」阶段可以先约定：十位用户中至少七成确认归类，且次日打开复习计划的比例不低于某个阈值（教学假设）。看不到这个证据，就不进入完整开发。真实项目需要根据历史基线、验证成本和可接受风险另行确定阈值。
关卡的作用，不是给流程增加仪式，而是在每一个「再投一笔就收不回」的节点前，逼我们停下来看一眼证据。
PRD 保存的是决策，不只是界面
一份可用于协作的需求文档至少包含：为什么做以及哪些证据支持；目标用户、场景和不做范围；核心路径与异常路径；关键假设和验证方法；指标定义、埋点与实验方案；依赖、风险、灰度和回滚条件；尚未解决的问题。
页面截图无法解释一个月前为什么做出取舍。决策记录才是产品文档能够长期复用的部分。
研习 PRD 里要写清一条决策：第一版保留人工确认这一步，暂不做识别免确认。理由是当前识别准确率假设未验证，人工确认能让用户纠正归类，同时把纠错数据记录下来，用于下一轮判断。这条决策背后有证据、有边界，也有重新考虑的条件。
写决策记录，不只是给现在的自己看，更是给三个月后已经忘掉上下文的新成员看。它回答的是「我们当时为什么选了 A 而不是 B」。
灰度和回滚，提前写死
灰度不是「先放一部分人看看」，而是提前写清目标人群、放量规则、回滚条件和监控。
研习的灰度可以这样定：先放给过去三十天手动记录过五次错题的重做题用户中的约一成，约四百人（教学假设），观察三天。监控指标是归集后的确认率和次日复习打开率。放量规则是确认率达到某个阈值后再扩大比例。回滚条件是确认率低于阈值，或用户纠错投诉比例超过某个比例，就回退到原手动错题本。
回滚条件必须在灰度前写死，不能等数据不好看时临时改定义。否则灰度就变成「上线了再说」。
如果你等到数据不好看，才去定义「什么叫不好看」，那你总能找到一个口径，让这次上线看起来「还行」。把回滚条件提前写死，就是为了在情绪上来之前，让数字替我们做决定。
压力测试：失败后能否缩小解释范围
我们做一个压力测试：如果这个 MVP 上线后数据仍然很差，团队能否明显缩小解释范围，并用额外证据区分剩下的解释。
如果 MVP 只包含「归集后进入复习计划」这一条新路径，自动识别、导出和统计就不再是主要干扰。此时仍然可能有几种解释：用户不愿意改变行为，操作过程太难，样本选错了，埋点漏报，或者服务在测试期间发生故障。团队还需要结合任务完成观察、分群、日志和访谈，把这些解释逐一排开。
如果 MVP 还叠加了自动识别、导出和统计，失败后又会回到四种解释并存的状态。因此判断一个 MVP 够不够小，标准不是功能多少，而是失败后还剩下几种解释。
这个压力测试，是 MVP 设计里最实用的一道尺子。MVP 不能保证失败只有一个原因，但应当主动减少无关变量，让剩余解释可以通过下一项小实验继续区分。
逐步执行：MVP 与交付流程
我们把前面的内容收成六步。每一步都配一句「研习是怎么做的」。
第一步，从定位里取最关键假设，写成一个可观察行为。研习的假设是「用户愿意为归集后进入复习计划改变行为」，可观察行为是「确认归类并次日打开复习计划」。
第二步，反推最小实现，列出必须保留的真实条件和可暂时删除的功能。研习保留真实练习来源的错题，删除识别免确认、导出、统计和权限设置。
第三步，拆解业务对象，写清对象、变化和可归纳的模块。研习抽象出用户、练习、错题、归类、复习计划和提醒，归纳为错题采集、归类确认、计划联动。
第四步，过一个阶段关卡，确认方案验证阶段已经看到关键证据。研习在方案验证阶段要看十位用户中至少七成确认归类。
第五步，写 PRD 决策记录，重点记录取舍背后的理由和重新考虑条件。研习记录了「暂不做识别免确认」这一条，以及什么证据出现时重新考虑。
第六步，定灰度与回滚，写死目标人群、放量规则、监控指标和回滚条件。研习写死了约四百人的灰度人群和确认率阈值。
可直接填写的模板
MVP与交付方案
最关键假设（可观察行为）：
支持/反对这一假设的行为：
MVP最小实现：
必须保留的真实条件：
暂时删除的功能（至少三项）：
业务对象与角色：
对象怎样变化：
可归纳的模块：
阶段关卡证据（问题/方案/开发准备/灰度/正式发布）：
当前关卡要看到什么证据：
PRD决策记录：
决策内容：
支持证据：
不做范围：
重新考虑条件：
灰度目标人群与放量规则：
监控指标：
回滚条件：
填完这张表，做一次自我检查：如果这个 MVP 上线后数据很差，你能不能列出两三种主要解释，并说明分别用什么证据区分。解释仍然多到无法检验时，就先继续缩小范围，而不是继续加功能。
常见误区及其可见后果
第一种误区，把 MVP 当成「少做几个功能」的完整产品。可见后果是失败后仍有多种解释，团队不知道该改哪一项。
第二种误区，把最容易做的功能先做。可见后果是最危险的假设始终没有被触碰，交付再多也证明不了价值。
第三种误区，只画界面不记录决策。可见后果是一个月后没人记得为什么删掉人工确认，新成员只能靠猜。
第四种误区，灰度和回滚写在文档里但不写死数字。可见后果是数据不理想时临时改口径，把失败解释成「还需要时间」。
第五种误区，把对象拆解当成画系统架构图。可见后果是讨论停留在模块命名，而不是对象变化和异常路径。
课堂练习
给出一份教学材料：团队准备验证「用户愿意为 AI 生成的读书笔记做手动修订」。
请在十分钟内完成四件事：
- 写出最关键假设和可观察行为；
- 列出 MVP 最小实现；
- 写出至少三项暂时删除的功能；
- 定一个灰度回滚条件。
写完后交换，检查对方的 MVP 是否已经排除大部分无关解释，以及剩下的解释能否继续用证据区分。
最终作业
回到上一课完成的定位，交付一份《MVP与交付方案》。
要求：最关键假设只有一个且可观察；MVP 最小实现能在两周内完成；至少明确删除三项看似合理但不影响关键验证的功能；业务对象至少写出五个及其变化；PRD 决策记录至少包含一条「不做」的决策及其理由；灰度和回滚写明具体数字，并注明数字属于教学假设还是项目实测。
评分标准
| 字段 | 评分要点 |
|---|---|
| 最关键假设 | 是否只有一个，是否写成可观察行为 |
| MVP最小实现 | 是否针对假设，是否保留真实条件 |
| 删除项 | 是否至少三项，且都不影响关键验证 |
| 业务对象 | 是否写清对象、变化与归纳模块 |
| 阶段关卡 | 是否写清当前关卡要看到什么证据 |
| PRD决策记录 | 是否保存取舍理由和重新考虑条件 |
| 灰度与回滚 | 是否写死目标人群、监控指标和回滚条件 |
| 失败解释 | 是否减少无关解释，并为剩余解释设计区分证据 |
| 数字来源 | 是否标明教学假设或来源事实 |
本课不能证明什么
MVP 不能证明产品最终会成功，也不能证明完整功能做完后会怎样。它只能证明，最关键假设在最小实现下是否被支持或推翻。
灰度也不能证明正式发布一定成立。小样本通过只说明这一群用户、这一个时间窗口内的行为，放量后的结果仍需要重新判断。
把这一点写清楚，是为了在下一次复盘时，不会反过来怪一个 MVP「做得太简陋所以失败」。MVP 本来就不负责成功，只负责在成本还小的时候，把最关键的那个判断验清楚。
与下一课的连接
MVP 上线、灰度跑完后，我们手里会有一组行为数据和一份被支持或被推翻的假设。下一课转向指标、实验与效果评估，教我们怎样把这些数据变成「继续、调整还是停止」的判断。
下一课会用到本课的监控指标和回滚条件，把它们升级为更完整的指标树与实验设计。