产品假设验证做不下去，常见原因不在数据不够，而在假设本身没法验证：表述像结论、验证对象混在一起、判定条件没写清。排查可以按三层依次走——先看假设能否被证伪，再确认验证对象是否唯一且可接触，最后补齐指标、基线、阈值、观察窗口和数据来源。三层中任一层缺失，结果都只能算一次观察，不足以支撑“成立”或“不成立”的结论。
要点总览（TL;DR）
- 排查按三层依次走：先看假设能否被证伪，再确认验证对象是否唯一且可接触，最后补齐指标、基线、阈值、观察窗口和数据来源。
- 三类典型症状分别是结论式表述、验证对象含糊、判定条件缺失；先归类再决定从哪一层入手，不必一次解决全部问题。
- 改写句式用“对象＋场景＋动作＋预期可观察结果＋判定条件”，一次验证只保留一个主要变量，并保留原假设与修改记录。
- 修正是否有效，看未参与改写的人能否仅凭假设文本复述验证方案；观察窗口结束后按事先写好的规则记录成立、不成立或证据不足。
- 把对象与判定条件检查项固化到假设评审或立项环节，缺项不进入验证排期，可减少同类问题重复出现。
先看症状：哪些表现说明假设已经无法验证
拿到一份产品假设，先别急着补数据或改方案，先判断它属于哪类问题。产品价值假设通常要回答“某类用户在某个场景下会不会因为某个改动获得可感知的价值”，如果文本读完后仍然说不清验证谁、看什么、达到什么算成立，问题就已经存在。下面三类症状可以对照自查。
| 症状类型 | 典型表现 | 对业务判断的影响 |
|---|---|---|
| 结论式表述 | 写成“提升用户体验”“优化下单流程”“用户会更愿意使用”，没有动作和可观察结果 | 验证结束后无法判断结果支持还是反驳假设，讨论容易回到主观意见 |
| 验证对象含糊 | 同时指向新用户和老用户、线上和线下、下单和售后，或只写“用户”不写角色 | 数据混在一起，某类用户有效、另一类无效时无法区分，结论无法指导下一步动作 |
| 判定条件缺失 | 只有指标名称，没有基线、阈值、观察窗口和数据来源 | 指标涨了说不清是否达标，跌了也说不清是否证伪，验证无法收口 |
这三类症状往往同时出现。比如“新功能能提升用户活跃度”这句话，对象是“用户”，结果是“活跃度”，既没有场景和动作，也没有判定口径，属于表述和判定两层都缺。排查时不必一次解决全部问题，先归类，再决定从哪一层入手。
需要界定范围：本文处理的是产品价值假设，即某个改动是否为目标用户带来可感知价值。需求验收标准是否写全、研发交付效率是否达标，属于需求验收与研发效能管理的流程，应放到对应管理环节处理，不混入假设验证的排查。
逐项定位原因：表述、对象、判定条件各查什么
症状归类之后，用提问和回读原文的方式确认问题出在哪一层。排查顺序建议从表述开始，因为表述不可证伪时，对象和判定条件往往也无从谈起。
表述层：能否读出动作和可观察结果
把假设原文读一遍，尝试回答三个问题：目标用户会做什么动作？这个动作发生在什么场景？动作之后能观察到什么变化？如果读完只能得到愿望或结论，说明表述层缺失。排除证据也很直接：请一位不参与该假设的同事只读原文，复述他要验证的动作和结果，复述不出来即确认表述不可证伪。
对象层：用户角色、场景、使用环节是否唯一
对象层要查的是验证范围是否收敛到一类可接触的人群和一个业务环节。检查点包括：用户角色是否具体到可识别（如首次注册未完成下单的用户）；场景是否限定在某个入口或某段时间；使用环节是否只覆盖一个关键动作。若一份假设同时包含多个角色或多个环节，就属于对象不清。排除证据是：能否列出这批对象的接触渠道和样本来源；列不出来，说明对象既不清楚也不可接触。
判定层：指标、基线、阈值、观察窗口、数据来源是否齐全
判定层逐项打勾：指标是什么、当前基线是多少、达到多少算成立、观察多长时间、数据从哪个系统或口径取。五项中缺任何一项，判定条件都不完整。常见情况是有指标没基线，或者有阈值没写观察窗口。排除证据是：让提出假设的人当场说出“看到什么数字、在什么时间点、就判定成立”，说不出来即确认判定条件缺失。
| 排查层 | 核心提问 | 确认缺失的证据 |
|---|---|---|
| 表述 | 谁在什么场景做什么动作，期望出现什么可观察结果 | 他人回读后无法复述验证动作与结果 |
| 对象 | 验证的是哪一类用户、哪一个业务环节 | 无法列出对象范围和样本接触渠道 |
| 判定 | 看哪个指标、对比什么基线、达到多少算成立、观察多久、数据从哪来 | 无法当场说出成立与不成立的判定口径 |
三层排查可以在一小时内完成，产出是一份带证据的排查清单。清单上每一层标注“通过”或“缺失”，并附上回读记录、对象范围和判定口径的原话，后续改写时直接引用。
修正与重写：把假设改成可验证的版本
定位到缺失层之后，按“对象＋场景＋动作＋预期可观察结果＋判定条件”的句式重写。改写不是把原句润色得更漂亮，而是把无法回答的问题逐个补上答案。
先拆分过宽的假设。一份假设只保留一个主要变量，比如只验证“简化注册步骤”对“首次注册用户完成首单”的影响，不同时验证价格策略和推荐算法。拆分后每个子假设单独走一遍三层检查，避免一次验证里多个变量互相干扰。
再补判定条件。有历史数据时，用最近一个完整周期的同口径数据作为基线；缺少历史数据时，先做小样本观察取得参照，再设定阈值，并在假设文档中写明取数口径、样本范围和观察窗口。阈值可以设成区间或方向性目标，但要写清判定规则，例如“观察两周，目标人群首单完成率相对基线提升不少于5个百分点，数据取自订单系统同一统计口径”。
| 改写前 | 问题 | 改写后 |
|---|---|---|
| 简化注册流程能提升转化 | 对象、场景、动作、判定条件均缺失 | 首次注册且未完成首单的用户，在移动端注册页由五步改为三步后，两周内首单完成率相对基线提升不少于5个百分点，数据取自订单系统同一口径 |
| 新功能会提升用户活跃度 | 对象含糊，指标无定义 | 使用协作功能满四周的团队管理员，在功能上线后八周内，周均活跃天数相对上线前八周基线不下降，数据取自产品埋点 |
改写过程中保留原假设和修改记录，注明修改人、修改时间和修改理由。这样后续判定结论时能追溯假设的演变，避免出现“结论对不上原假设”的争议。改写完成后，把新假设交给未参与改写的人复述验证方案，能复述清楚才算通过。
风险边界需要说明：小样本观察得到的基线只适用于相近人群和相近时间窗口，扩大适用范围前应重新取数；阈值设定过低会让验证失去区分力，过高则可能把有价值的改动误判为不成立，阈值调整应记录理由。
验证与复发预防：怎么确认改对了并避免再次出现
改写是否有效，用一个检查点确认：把新假设文本单独交给未参与改写的人，对方能否仅凭文本说出验证对象、观察指标、基线、阈值、观察窗口和数据来源，并复述出验证方案。能复述，说明假设已经具备可执行性；复述时出现分歧，回到对应层继续补。
观察窗口结束后，按事先写好的判定规则记录结论，写明“成立”“不成立”或“证据不足”，并附上实际数据与判定依据。证据不足也是一种有效结论，说明观察窗口或样本需要调整，不应直接改写成成立。判定记录与假设原文、修改记录放在一起归档，便于后续复盘和复用。
预防复发靠流程固化。在假设评审或立项环节加入固定检查项：表述是否包含动作与可观察结果、验证对象是否唯一且可接触、判定五要素是否齐全。评审时逐项打勾，缺项不进入验证排期。日常工作中，假设、验证记录和判定结论需要在工作项和文档中留痕，ONES 的工作项与文档管理可以承载这条链路：假设作为工作项记录对象与判定条件，验证过程在文档中沉淀数据与修改记录，结论归档后供后续评审引用。这样做的目的是让每次验证都能追溯到原始假设和判定依据，减少同类问题重复出现。
复发信号要提前识别：新提出的假设再次出现结论式表述、对象写成“用户”而不写角色、指标没有阈值或观察窗口，说明检查项没有真正执行。发现复发信号时，回到症状对照表重新归类，而不是在原有假设上继续打补丁。
常见问题
假设里同时涉及新用户和老用户，是拆成两份还是合并验证？
建议拆开。两类用户的接触渠道、行为基线和价值判断往往不同，合并验证会出现一类有效、另一类无效却无法区分的情况。拆分时保持场景和动作一致，只把用户角色作为变量，这样两份结果可以对照。如果资源只够先做一份，优先验证与当前业务目标更直接相关的那类用户，并在假设文档中写明另一类暂未覆盖。
缺少历史数据时，基线怎么定才不至于拍脑袋？
先做小样本观察取得参照，再设定阈值。具体做法是选一批与目标人群相近的对象，在相同口径下观察一个完整周期，把观察结果作为临时基线，并在假设文档中写明样本范围、取数口径和观察窗口。临时基线只适用于相近人群和相近时间窗口，扩大适用范围前应重新取数。阈值调整要记录理由，避免事后按结果倒推标准。
观察窗口结束后数据介于成立与不成立之间，结论怎么写？
按事先写好的判定规则记录，可以写“证据不足”，并附上实际数据与判定依据。证据不足说明观察窗口或样本需要调整，属于有效结论，不应直接改写成成立。记录时写清下一步动作，例如延长观察窗口、扩大样本或调整阈值，并把这次判定与假设原文、修改记录放在一起归档，便于后续复盘时对照。
假设评审会上怎么快速判断一份假设是否可验证？
用复述法最快：请未参与撰写的人只读假设文本，说出验证对象、观察指标、基线、阈值、观察窗口和数据来源。复述中出现分歧或说不出来，就回到对应层继续补。评审时按表述、对象、判定三层逐项打勾，缺项不进入验证排期。这个方法不依赖评审人的经验判断，能把讨论集中在缺失的具体要素上。
需求验收标准和产品假设判定条件是一回事吗？
两者关注点不同。产品假设判定条件回答的是“这个改动是否为目标用户带来可感知价值”，关注用户行为和业务结果；需求验收标准回答的是“交付的功能是否符合约定要求”，关注功能完整性和质量。验收通过不代表假设成立，假设成立也不代表验收标准写得完整。两类检查应放在各自的管理环节，不互相替代。
