产品假设未经验证，先别急着把它写进排期。更稳妥的做法是先判断自己面对的是哪种“未验证”：完全没有证据、证据零散矛盾，还是验证条件暂时不具备。分清症状后，再把假设改写成可检验的表述，用访谈、行为数据、原型或小范围灰度取得证据，并按事先约定的阈值决定继续、修正还是放弃。本文按这条诊断与处置路径展开，涉及验证任务与结论在团队内登记、交接时，可借助 ONES 承接这类管理动作。
要点总览（TL;DR）
- 先分清“未经验证”属于哪一类：完全没有证据、证据零散矛盾，还是验证条件不具备，三类症状的处置优先级不同。
- 把模糊假设改写成“对象+行为+可观察指标+判定阈值”的可检验表述，验证方案才有设计依据。
- 按假设类型选择成本最低、能回答关键问题的验证方式，并事先设定验证周期、样本范围和停止点。
- 结果解读回到预设阈值，区分“证据不支持假设”与“验证设计有问题”，部分成立时收窄或拆分假设再验证。
- 把假设、证据、结论和决策留档，在需求进入开发前设置验证状态检查点，定期回看未验证假设清单。
“未经验证”通常卡在哪：先分清症状
“未经验证”描述的是证据状态，不同状态对应的处置优先级差别很大。把“还没做过验证”和“验证过但结果不支持”混在一起讨论，团队容易在错误的层面上争论：前者需要安排验证动作，后者需要重新审视假设本身。先定位症状，才能决定下一步是补证据、查设计，还是调整验证条件。
常见的有三类症状。第一类是完全没有证据，假设只停留在会议讨论、竞品观察或个人判断上，没有任何用户侧材料支撑。第二类是证据零散且相互矛盾，比如几场访谈说法不一、数据指标方向不一致，团队各取所需。第三类是验证条件不具备，样本量不够、目标用户触达不到、验证周期与决策时点冲突，导致验证迟迟无法启动或无法得出结论。
| 症状类型 | 典型表现 | 处置优先级 |
|---|---|---|
| 完全没有证据 | 假设只出现在文档和讨论中，无访谈记录、无行为数据、无原型反馈 | 最高。先补最小可行证据，再谈投入 |
| 证据零散且矛盾 | 访谈结论不一致、数据口径不统一、不同角色各持一套说法 | 次高。先统一证据口径和判断标准，再补充关键缺口 |
| 验证条件不具备 | 目标用户难触达、样本不足、验证周期长于决策窗口 | 视决策紧迫度。可先降级验证或明确标注为待验证后再决策 |
可以用下面这组自查问题快速定位：这个假设最近一次接触真实用户或真实行为数据是什么时候？现有证据是来自用户行为，还是主要来自内部讨论？如果现在就要做决策，缺的是证据本身，还是缺取得证据的条件？团队对“什么结果算验证通过”是否有共同说法？四个问题里，前两个指向证据有无，后两个指向证据质量和验证设计。
原因假设与排除证据：为什么假设一直没被验证
假设长期悬空，通常有可排查的原因。把这些原因当作假设来对待，逐条找证据确认或排除，比笼统归因于“大家太忙”更有用。需要强调的是，在证据到位之前，任何原因都只能标注为待验证，不能写成已确认结论。
| 原因假设 | 需要的排除或确认证据 | 排查顺序 |
|---|---|---|
| 假设表述模糊，无法检验 | 检查假设是否包含对象、行为、指标和判定阈值；模糊表述通常无法设计验证方案 | 第一步，先看假设本身 |
| 缺少验证责任人与时点 | 查任务记录中是否有明确负责人、截止时间和交付物；无人认领的假设往往长期搁置 | 第二步，看组织安排 |
| 把内部意见当作用户证据 | 核对证据来源：是用户原话、行为数据，还是内部评审结论；来源为内部的不能算用户验证 | 第三步，查证据来源 |
| 验证成本被高估而拖延 | 对比一次访谈、一轮原型测试的实际投入与继续开发的投入；成本判断是否有依据 | 第四步，算成本账 |
| 决策层直接跳过验证 | 查决策记录中是否写明假设状态；跳过验证是显式决定还是默认发生 | 第五步，看决策过程 |
排查顺序建议从假设本身开始，因为表述模糊会让后面所有排查失去基准；再看责任与时点，确认是否有人真正推进；然后核对证据来源，排除内部意见冒充用户证据的情况；最后才讨论成本与决策层因素。每排除一条原因，都要留下对应的证据，比如假设改写前后的对照、任务记录截图、证据来源清单。证据不足时，结论栏写“待验证”，并注明还缺什么证据、由谁在什么时点补齐。
按请求处置：把假设转成可执行的验证动作
处置的第一步是把假设改写为可检验的表述，推荐结构是“对象+行为+可观察指标+判定阈值”。例如把“用户需要更快的报表导出”改写成“运营岗用户在有导出需求时，会在现有入口完成导出，且单次导出耗时超过30秒的比例低于两成”。改写后，验证对象、观察什么、什么算通过都清楚了，验证方案才有设计依据。
第二步按假设类型选择验证方式。用户访谈适合探索动机和场景，回答“用户为什么在意”；行为数据分析适合检验已有功能的使用模式，回答“用户实际怎么做”；可点击原型适合检验交互方案的理解与接受度；落地页测试适合检验需求强度和转化意愿；小范围灰度发布适合在真实环境中检验行为变化。选择时优先用成本最低、能回答当前关键问题的方式，不必一次上全套。
- 把假设改写为可检验表述，并写明判定阈值。
- 选定验证方式，说明它能回答哪个关键问题、不能回答什么。
- 设定验证周期、样本范围和停止点，例如“两周内完成8场访谈，若连续5场未出现预期行为则提前停止”。
- 识别有破坏风险的动作，如灰度发布、数据回滚、面向真实用户改配置，先备份或限定影响范围。
- 指定责任人与交付物，交付物至少包含原始证据、分析结论和建议决策。
风险边界要在执行前写清楚。涉及线上环境、真实用户或生产数据的验证，先确认影响范围、回退方式和停止条件；涉及用户访谈的，提前说明用途并保护个人信息。验证周期和样本范围一旦设定，中途调整要记录原因，避免结果出来后才发现口径已经变了。
验证任务、证据材料和结论需要在产品、设计、研发之间交接时，可以在 ONES 中登记假设与验证任务，把证据和结论随任务留档，供后续评审引用。这样做的价值在于让“这个假设验证到哪一步”成为团队可查的状态，而不是散落在个人记录里。
验证结果怎么读：通过、修正还是放弃
结果解读要回到验证前设定的阈值，避免证据出来后凭印象重新解释。通常分三种结果：达到预设阈值，判为通过，可以进入下一步投入；部分指标达到、部分未达到，判为部分成立，需要收窄或拆分假设；关键指标明显低于阈值，判为不成立，应停止或转向。
| 结果 | 判断依据 | 建议动作 |
|---|---|---|
| 通过 | 关键指标达到或超过预设阈值，证据来源可靠 | 进入方案设计或开发排期，保留证据备查 |
| 部分成立 | 部分指标达标，或仅在特定人群、场景下成立 | 收窄假设范围或拆分为更小的假设，再验证一轮 |
| 不成立 | 关键指标明显低于阈值，且验证设计无明显缺陷 | 停止当前方向，记录结论，转向替代假设 |
需要区分“证据不支持假设”和“验证设计有问题”。如果样本严重偏离目标用户、访谈问题带有引导性、指标口径中途变更，结果本身的可信度就存疑，此时应先修正验证设计再重跑，而不是直接判定假设不成立。判断方法是在结果评审时同步检查验证记录：样本是否符合设定、问题是否中立、数据口径是否一致。部分成立时，优先做的是拆分，比如把“所有用户都需要该功能”收窄为“某类高频用户在特定场景下需要”，再针对收窄后的假设设计一轮更聚焦的验证。
验证与复发预防：让结论可追溯、下次不再悬空
单次验证结束后，把假设、验证方式、证据、结论和决策记录在一起，形成可检索的验证记录。记录至少包含：假设原文与改写后的可检验表述、验证方式和样本范围、原始证据位置、结果判定、最终决策和决策人。这样后续复盘或人员变动时，能直接查到某个方向为什么被推进或放弃，而不必重新争论。
在需求进入开发前设置验证状态检查点：需求评审时同步确认相关假设的验证状态，标注为已验证、待验证或明确接受风险后推进。对标注为待验证的，写明补齐时点和负责人。检查点的作用是让“跳过验证”成为一个显式决定，而不是默认发生。
定期回看未验证假设清单，比如每两周或每个迭代周期一次，逐条确认是关闭、继续验证还是放弃。清单按假设提出时间排序，超过约定周期仍未启动验证的，要么安排资源，要么明确关闭。配合验证记录模板使用，团队可以逐步减少假设长期悬空的情况，也让每一次投入决策都有据可查。需求验收与闭环管理的具体流程、研发效能度量属于相邻主题，本文不展开，可在相关流程中衔接验证状态的检查。
常见问题
假设已经排进开发计划，才发现没验证，应该停下来吗？
先判断这个假设对方案成败的影响程度，再决定是否暂停。如果它决定核心用户是否使用、关键流程是否成立，建议在开发启动前补一轮最小可行验证，比如几场目标用户访谈或一轮可点击原型测试，用较低成本换取方向确认。如果它只影响局部实现细节，可以带着“待验证”标注推进，同时约定补齐时点和负责人，把风险显式记录下来。关键是让“继续推进”成为一个有记录的决定，而不是默认发生。
样本量很小，验证结果还能用吗？
小样本适合发现方向和明显问题，不适合做精确的比例推断。定性访谈通常几场到十几场就能暴露主要模式，但结论应表述为“观察到某类行为”，而不是“某比例用户会如何”。如果决策依赖比例或转化率，需要扩大样本或改用行为数据。无论样本大小，都要在记录中写明样本范围、招募方式和验证周期，让后续读者知道结论的适用边界。
验证结果和决策层判断相反，怎么处理？
先把分歧落到具体问题上：是证据本身可信度存疑，还是对阈值的设定有不同看法。如果是验证设计问题，比如样本偏离目标用户或问题带有引导性，可以修正设计后重跑一轮；如果证据可靠但决策层基于其他信息（如战略布局、资源约束）选择推进，建议把这个决定和理由写入验证记录，标注为“接受风险后推进”。这样既保留了证据，也让后续复盘有据可查。
哪些验证动作有风险，需要提前设边界？
涉及线上环境、真实用户和生产数据的动作风险较高，包括小范围灰度发布、面向真实用户修改配置、调整线上数据等。执行前应确认影响范围、回退方式和停止条件，必要时先备份。用户访谈涉及个人信息，需提前说明用途并做好保护。风险边界写在验证计划里，中途调整要记录原因，避免结果出来后口径已经变化。
团队假设很多，怎么排验证顺序？
按“影响决策的程度”和“验证成本”两个维度排序。优先验证那些一旦不成立就会推翻当前方案的关键假设，以及用低成本方式就能取得证据的假设。可以把假设列成清单，标注每条假设支撑哪个决策、当前证据状态、计划验证方式和负责人，定期回看。对长期未启动验证的条目，要么安排资源，要么明确关闭，避免清单越积越长却无人推进。
