MVP选择功能的核心依据是可证伪的核心假设，而非一份缩小版的产品需求清单。做法是先把要验证的假设写成“目标用户—场景—预期行为—预期结果”的表述，再逐条映射到能产生可观察证据的最小功能，按假设风险与验证成本排序裁剪，最后为每个功能设定指标、观察周期和放弃条件。本文给出这套流程的输入、动作、产出物与检查清单，并说明假设、功能条目和决策记录如何在同一处跟踪状态。
要点总览（TL;DR）
- MVP功能选择的起点是可证伪的核心假设：每条假设写清目标用户、场景、预期行为和预期结果，并标注风险等级与现有证据状态。
- 把假设逐条映射到能产生可观察证据的最小功能，只保留“去掉后假设无法验证”的功能，剔除内部效率、体验打磨和未来扩展类需求。
- 按假设风险从高到低、验证成本从低到高排序，设定范围上限并明确裁剪顺序，同时记录本期不做清单和重新评估条件。
- 每个保留功能在开发前写清观察指标、样本范围、观察周期，以及通过、失败、证据不足三种判定口径和放弃条件。
- 产出物包括假设清单、假设—功能映射表、MVP范围与不做清单、验证指标表；假设、功能条目和决策记录可在ONES中关联跟踪。
先写清要验证的核心假设
MVP的功能范围来自假设清单，而不是来自竞品功能对比或完整产品规划。假设写得越具体，后续筛选功能时争议越少。一个可用的假设句式是：“我们相信【目标用户】在【具体场景】下，会做出【可观察的行为】，从而带来【可衡量的结果】。”四个要素缺一项，这条假设就无法验证。
例如“用户会喜欢更快的审批”不是假设，因为它没有目标用户、场景和可观察行为。改成“我们相信20人以下团队的项目负责人在提交周报时，如果支持一键汇总任务进展，会有超过一半的人连续两周使用该功能并减少手工整理时间”，就具备了验证条件：对象、场景、行为、结果都在里面。
区分价值假设与增长假设
价值假设回答“用户是否真的需要并愿意使用这个解决方案”，增长假设回答“用户能否被获取、留存和传播”。MVP阶段优先验证价值假设：如果核心价值不成立，获客渠道和增长机制再精巧也没有意义。增长假设可以列出，但通常放到价值假设获得初步支持之后再验证。
为每条假设标注风险等级与证据状态
风险等级按“假设不成立时对项目的打击程度”判断，分为高、中、低三档。证据状态记录当前已有什么支撑：只有团队判断、有少量用户访谈、有行为数据、有付费意向等。高风险管理、低证据状态的假设，就是MVP必须优先覆盖的对象。
| 假设编号 | 假设表述（目标用户—场景—行为—结果） | 类型 | 风险等级 | 现有证据 |
|---|---|---|---|---|
| H1 | 项目负责人每周整理进展耗时超过1小时，愿意用自动汇总替代手工整理 | 价值假设 | 高 | 仅3次访谈，无行为数据 |
| H2 | 团队成员愿意每天更新任务状态，以保证汇总数据可用 | 价值假设 | 高 | 团队判断，无证据 |
| H3 | 负责人愿意把汇总结果直接用于向上汇报 | 价值假设 | 中 | 2位用户口头认可 |
| H4 | 新用户能通过邀请同事自然带入团队使用 | 增长假设 | 中 | 无 |
这张表就是后续所有筛选工作的输入。完成标志是：每条假设都能被一次具体的用户行为证伪，且风险等级和证据状态已填写。
把假设映射到最小功能集
映射的动作是逐条追问：要观察到这条假设对应的行为，最少需要产品提供什么？答案写进映射表，一个功能一行，注明它服务哪条假设、产生什么证据。没有对应假设的功能，不进入候选清单。
| 功能 | 服务的假设 | 产生的证据 | 是否验证必需 |
|---|---|---|---|
| 任务进展一键汇总 | H1 | 负责人每周使用次数、手工整理时间变化 | 是 |
| 任务状态快捷更新 | H2 | 成员日均更新率、连续更新天数 | 是 |
| 汇总结果导出为汇报格式 | H3 | 导出次数、是否用于实际汇报 | 是 |
| 自定义报表样式 | 无直接对应 | 无 | 否 |
| 团队邀请与权限配置 | H4 | 邀请转化率 | 本期暂缓 |
判断“验证必需”的三条标准
- 去掉该功能后，对应假设无法被观察或无法被证伪；
- 该功能产生的证据能直接影响“继续、调整、放弃”的决策；
- 实现成本在可接受范围内，或用人工、手动流程可以替代。
三条同时满足才保留。只满足一条的功能，先放入待定区，不进入MVP范围。
剔除三类功能
第一类是只服务内部效率的功能，例如后台批量配置、运营看板，它们让团队工作更顺，但不产生用户侧证据。第二类是体验打磨，例如动效、空状态插画、多主题，这些应在价值假设成立后再投入。第三类是未来扩展，例如多语言、开放接口、复杂权限模型，它们服务的是尚未验证的增长假设。剔除不等于否定，而是记录到“本期不做清单”，注明重新评估的触发条件。
一个功能服务多条假设时的取舍
优先保留服务高风险管理假设的功能。如果同一功能同时服务高低两类假设，在映射表中标注主假设，验证指标以主假设为准，避免指标过多导致结论模糊。若两条假设风险都高且方向冲突，拆成两个更小的功能分别验证，或先验证其中一条，把另一条列入下一轮。
按风险与验证成本排序取舍
初筛后的候选功能往往仍多于MVP能承载的范围，此时用两级排序确定最终范围：先按所服务假设的风险等级从高到低排，风险相同时再按验证成本从低到高排。风险优先保证MVP回答的是最关键的问题，成本次序保证在有限周期内能拿到结论。
可接受的替代验证手段
很多功能不必先写代码。人工代替是用运营或产品人员手动完成汇总、匹配、通知等动作，观察用户是否持续使用；手动流程是用表单、文档和固定会议模拟产品流程；现成工具是用已有的表格、问卷、协作工具搭出可用版本。替代手段的适用条件是：能产生与真实功能相近的可观察行为，且用户知道这是早期版本。替代手段不能验证的性能、稳定性类假设，仍需真实实现。
设定范围上限与裁剪顺序
范围上限按团队在验证周期内能完成并观察到结果的工作量设定，常用口径是“一个迭代周期内可交付的功能数”或“人天总量”。超出上限时，按以下顺序裁剪：先去掉服务中低风险假设的功能，再去掉可用人工替代的功能，最后合并证据来源重复的功能。裁剪后的每一条都要回到映射表确认：被裁掉的假设是否还有别的功能覆盖，若没有，该假设应明确转入下一轮。
记录本期不做清单
不做清单至少包含功能名称、原对应假设、暂缓原因、重新评估的触发条件。这份清单是后续范围讨论的依据，也能防止MVP在开发过程中被逐步加回完整产品。
| 顺序 | 功能 | 对应假设 | 风险 | 验证成本 | 结论 |
|---|---|---|---|---|---|
| 1 | 任务进展一键汇总 | H1 | 高 | 中 | 保留 |
| 2 | 任务状态快捷更新 | H2 | 高 | 低 | 保留 |
| 3 | 汇总结果导出 | H3 | 中 | 低 | 保留（可用手动导出替代） |
| 4 | 团队邀请与权限 | H4 | 中 | 中 | 转入下一轮 |
| 5 | 自定义报表样式 | 无 | — | 高 | 不做 |
为每个功能设定验证指标与放弃条件
功能上线不等于验证完成。每个保留功能都要在开发前写清观察指标、样本范围、观察周期和判定口径，否则上线后只能凭感觉争论。指标应尽量指向行为而非态度，例如使用频次、完成率、留存天数，而不是“用户反馈不错”。
| 功能 | 观察指标 | 样本范围 | 观察周期 | 通过 | 失败 | 证据不足 |
|---|---|---|---|---|---|---|
| 一键汇总 | 周活跃负责人中使用汇总的比例、手工整理时间自报变化 | 首批10个团队的项目负责人 | 2周 | ≥50%连续两周使用且时间下降 | <20%使用 | 20%–50%或样本不足 |
| 状态快捷更新 | 成员日均更新率、连续更新天数 | 同上10个团队全体成员 | 2周 | 日均更新率≥70% | <40% | 40%–70% |
| 汇总导出 | 导出次数、是否用于实际汇报 | 使用过汇总的负责人 | 2周 | ≥30%的汇总被导出并确认用于汇报 | 无人用于汇报 | 有导出但用途不明 |
三种结论的判定口径
通过表示假设获得初步支持，可以进入下一轮扩大样本或验证增长假设；失败表示假设被证伪，应停止在该方向追加投入，并记录原因；证据不足表示数据未达到判定阈值或样本偏差明显，处理方式是延长观察周期、扩大样本或改用访谈补充，不能直接当作通过。
预设放弃与转向条件
放弃条件在开发前写定，例如“连续两周使用率低于20%即停止该功能迭代”。转向条件描述假设部分成立时的调整方向，例如“汇总使用率高但导出率低，说明价值在内部查看而非向上汇报，下一轮转向团队内同步场景”。条件与指标绑定，避免上线后临时改口径。
数据采集与最小埋点
最小埋点只需覆盖三类事件：功能是否被打开、核心动作是否完成、是否重复使用。能用现成工具统计的，不额外开发；需要人工核对的，指定记录人和记录频率。埋点方案与指标表一起评审，确保每个指标都有对应的数据来源。
角色分工与交付物
这套流程要落地，需要明确谁写假设、谁做映射、谁定指标、谁看数据。角色可以一人多岗，但每项交付物要有唯一负责人。
| 角色 | 主要职责 | 产出 |
|---|---|---|
| 产品负责人 | 组织假设梳理，主持映射与排序评审，维护不做清单 | 假设清单、映射表、MVP范围 |
| 业务/用户研究 | 提供访谈与行为证据，校验假设表述是否可观察 | 证据状态记录、访谈结论 |
| 研发 | 评估实现成本，提出人工替代方案，落实埋点 | 成本估算、替代方案说明、埋点清单 |
| 数据 | 定义指标口径，搭建采集与统计，输出周期报告 | 验证指标表、周期数据报告 |
流转节点建议设三个评审：假设清单评审确认可证伪性；映射与排序评审确认MVP范围和不做清单；指标评审确认每个功能都有判定口径。每次评审形成决策记录，写明结论、依据和反对意见。假设、功能条目、验证指标和决策记录分散在多个文档里时，状态容易脱节；可以在ONES中把每条假设建成工作项，关联对应功能需求与验证文档，用状态字段标记“待验证、验证中、已通过、已放弃”，决策记录沉淀在ONES Wiki并保留版本，便于回溯每次范围调整的依据。
一个完整示例：从假设到MVP功能清单
以下为演示情景，用于说明方法，不代表真实项目数据。某协作工具团队怀疑“周报整理”是高频痛点，计划用MVP验证。
假设写法与风险标注
团队写出三条假设：H1，20人以下团队的项目负责人每周花超过1小时整理进展，愿意用自动汇总替代手工整理（价值假设，高风险，仅有5次访谈）；H2，团队成员愿意每天更新任务状态（价值假设，高风险，无证据）；H3，负责人会把汇总结果用于向上汇报（价值假设，中风险，2人表示会）。增长假设暂不列入本轮。
映射与排序过程
映射后得到五个候选功能：一键汇总、状态快捷更新、汇总导出、自定义报表、团队邀请。按三条标准初筛，自定义报表无对应假设被剔除；团队邀请服务增长假设，转入下一轮。剩余三个功能按风险排序：一键汇总与状态更新服务高风险假设，优先保留；汇总导出服务中风险假设，且可用手动导出替代，保留但降低实现投入。范围上限为一个迭代周期，三个功能均未超限。
最终功能清单与判定条件
| 功能 | 假设 | 指标 | 周期 | 放弃条件 |
|---|---|---|---|---|
| 一键汇总 | H1 | 负责人周使用率、整理时间变化 | 2周 | 使用率连续两周低于20% |
| 状态快捷更新 | H2 | 成员日均更新率 | 2周 | 更新率低于40%且访谈确认无意愿 |
| 汇总导出（手动替代） | H3 | 导出并用于汇报的比例 | 2周 | 无人用于实际汇报 |
本期不做清单记录：自定义报表（无对应假设）、团队邀请（增长假设，待价值假设通过后评估）、多语言（未来扩展）。
完成检查：MVP功能选择是否站得住
在开发启动前，用以下清单逐项核对。任何一项不满足，回到对应章节补齐，而不是直接进入开发。
- 每条核心假设都包含目标用户、场景、预期行为和预期结果，且能被一次具体行为证伪；
- 每条假设都标注了风险等级和现有证据状态，高风险管理假设已进入本轮范围；
- 每个保留功能都能在映射表中追溯到至少一条假设和一类证据；
- 被剔除的功能已记录原因，属于内部效率、体验打磨或未来扩展的已归入不做清单；
- MVP范围未超过设定的上限，超出部分已按裁剪顺序处理；
- 每个功能都有观察指标、样本范围、观察周期和通过、失败、证据不足三种判定口径；
- 每个功能都写明了放弃或转向条件，且条件与指标绑定；
- 指标都有对应的数据采集方式，埋点或人工记录责任到人；
- 假设清单、映射表、范围决策和指标表各有唯一负责人，评审记录完整；
- 不做清单包含重新评估的触发条件，变更留痕可查。
这份清单同时回答了“功能选择是否合理”：合理的MVP范围应当能用一句话说清本轮要验证哪几条假设、用什么证据判断、什么情况下停止。说不清，说明假设或指标还需要继续收敛。
常见问题
MVP阶段应该先验证价值假设还是增长假设？
优先验证价值假设。价值假设回答用户是否真的需要并愿意使用这个解决方案，增长假设回答用户能否被获取、留存和传播。核心价值不成立时，获客渠道和增长机制再精巧也无法支撑项目。增长假设可以列出来，但通常放到价值假设获得初步支持之后再验证。
如果团队已有明确的付费用户基础，或增长瓶颈已被反复验证，也可以把某条增长假设提前，但要在假设清单里注明理由和风险等级。
没有开发资源时，能否用人工或现成工具代替功能完成验证？
可以，前提是替代手段能产生与真实功能相近的可观察行为，且用户知道这是早期版本。常见做法包括由运营或产品人员手动完成汇总、匹配、通知，用表单和文档模拟产品流程，或用现成的表格、问卷、协作工具搭出可用版本。
替代手段适合验证用户是否愿意持续使用某类价值，不适合验证性能、稳定性等依赖真实实现的假设，这类假设仍需真实开发后再判断。
验证数据落在“证据不足”区间时该怎么处理？
证据不足表示数据未达到判定阈值或样本偏差明显，处理方式是延长观察周期、扩大样本，或改用访谈补充定性信息，不能直接当作通过。为避免反复出现这种情况，指标表应在开发前写清样本范围和最小样本量，并确认数据采集方式可用。
如果多次延长后仍无法得出结论，通常说明指标设计过粗或样本获取渠道有问题，应回到指标表调整口径，而不是继续等待数据。
MVP开发过程中业务方不断加需求，如何守住范围？
用不做清单和裁剪顺序来应对。每个被暂缓的功能都记录原对应假设、暂缓原因和重新评估的触发条件，新需求进入时先判断它服务哪条假设、是否已有功能覆盖，再决定放入本轮、下一轮还是不做。
范围变更应形成决策记录，写明结论、依据和影响，避免MVP在开发过程中逐步加回完整产品。假设、功能条目和决策记录分散时，可以在ONES中把假设建成工作项，关联对应需求与文档，用状态字段跟踪“待验证、验证中、已通过、已放弃”，决策记录沉淀在ONES Wiki并保留版本。
功能上线后假设被证伪，前期投入是否浪费？
证伪本身就是MVP的产出：它用较小成本排除了一个方向，避免团队在错误方向上继续追加投入。关键是把失败结论记录清楚，包括指标数据、样本范围、可能的干扰因素，以及该结论对后续假设的影响。
如果假设部分成立，例如汇总使用率高但导出率低，可以按预设的转向条件调整方向，把下一轮验证聚焦到真正被用户使用的场景上。
