把模糊的产品想法写成可验证假设，关键在四段：假设陈述写清谁在什么场景下因什么障碍需要什么方案；验证对象写明找哪类用户、样本多少、从哪里接触；验证信号选用户可观察的行为或明确表态；判定条件给出指标口径、阈值和观察时间窗。判定条件要在验证开始前锁定，并同时写明推翻条件，避免事后解释数据。
要点总览（TL;DR）
- 把模糊想法写成四段假设陈述：目标用户与场景、障碍或动机、拟提供的方案、预期用户价值；一条假设只承载一个待验证判断。
- 验证对象要写明人群特征、使用场景、当前替代做法、样本数量和招募渠道，并标注本次不覆盖的人群，避免只找内部同事或熟识用户。
- 验证信号按可信度分层：口头表态、承诺性动作、真实使用行为、付费或替换现有方案；优先采用与假设最贴近的行为信号，同时预设挑战性信号。
- 判定条件在验证开始前锁定，包含指标口径、支持阈值、推翻阈值和观察时间窗，并设证据不足档，变更需记录原因。
- 假设卡、证据与结论统一归档并与对应需求记录关联，交付前按检查清单逐项核对，结论无论支持、推翻还是证据不足都写回同一张卡。
一条可验证的产品假设包含哪四段
产品假设是一句可以被证据支持或推翻的判断。它和需求描述的区别在于：需求描述说明要做什么，假设则说明做了之后预期谁会因此改变什么行为。写成四段结构，可以让这句话具备被检验的条件。
四段分别是：目标用户与场景（谁、在什么情况下）、障碍或动机（当前卡在哪里、为什么想改变）、拟提供的方案（打算用什么方式解决）、预期产生的用户价值（用户会做出什么可观察的行为变化）。四段缺一段，假设就容易变成愿望。例如“用户会喜欢更简洁的界面”缺少具体人群、场景和可观察结果，无法验证；“新入职的销售在第一次录入客户信息时，因字段过多而放弃保存，若把必填字段压缩到五项，其首次保存完成率会上升”则四段齐全，可以设计验证。
写假设陈述时，每一段都要落到可观察对象上。目标用户写成“使用某功能超过三个月的运营人员”，比“运营人员”更可检验；障碍写成“每次导出报表要手动整理三个表格”，比“操作繁琐”更具体；预期价值写成“一周内主动导出两次以上”，比“体验更好”更容易采集。表述越具体，后续验证对象和信号的选择就越有依据。
一条假设只承载一个待验证判断。如果想法里同时包含“用户需要这个功能”和“用户愿意为此付费”，应拆成两条假设，分别设计验证。拆分的标准是：两个判断能否被同一组证据同时支持或推翻。不能的话就分开写，否则结论出现分歧时无法判断是哪一部分不成立。
需要说明边界：本文讨论的是产品是否产生用户价值这一层判断。需求验收关注交付物是否按约定完成，研发效能管理关注团队交付过程的效率，两者与产品假设验证相邻但问题不同，本文不展开。
假设陈述模板
可以按下面的句式填写，括号内为填写要求：
- 我们相信【目标用户，写明角色与使用场景】在【具体情境】下，因为【障碍或动机，写到可观察的行为或事件】，需要【拟提供的方案】。
- 如果这个判断成立，他们会出现【预期行为变化，写明动作和频次或比例】。
填写完成后做一次自检：把“目标用户”换成另一类人，这句话是否仍然成立？如果成立，说明人群写得太宽；把“预期行为”删掉，剩下部分是否还能被验证？如果不能，说明价值段还停留在感受层面。
验证对象怎么选：人群、样本与接触渠道
验证对象回答的是“找谁来看这件事是否成立”。写成“用户”没有操作意义，需要拆成可执行的字段。建议每张假设卡都填下面这张表：
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 人群特征 | 角色、使用年限、使用频率、所在业务环节 | 使用该功能每周三次以上的客服主管 |
| 使用场景 | 具体任务、发生时机、所处环境 | 月末处理批量退款时 |
| 当前替代做法 | 现在用什么方式解决，包括手工方式 | 导出表格后人工核对 |
| 样本数量 | 计划接触多少人、有效样本多少 | 接触12人，有效访谈8人 |
| 招募渠道 | 从哪来、由谁邀约、是否有激励 | 客服负责人推荐加产品内邀请 |
样本要覆盖真实使用场景中的关键角色。只找内部同事或熟识用户，容易得到配合度高但代表性弱的反馈：他们了解产品背景，会替方案补全缺失信息，也会因为关系而给出正面评价。更稳妥的做法是从真实使用路径中招募，并至少包含一类“当前替代做法不同”的用户，用来观察方案是否真的改变了行为。
样本规模决定结论强度。小样本定性验证适合判断方向是否存在、障碍描述是否准确，能支持“值得继续投入”的判断，难以支持比例类结论。较大样本的定量验证适合估计行为发生率和转化水平，但需要明确的指标口径和足够的观察时间。假设卡里应写明本次验证属于哪一类，以及结论将被用在什么决策上，避免用几次访谈的结论去支撑需要比例判断的投入决策。
验证对象写错，常见偏差有三类：一是只接触活跃用户，忽略流失或从未使用的用户，导致障碍被低估；二是只找决策者，忽略实际执行者，导致方案在落地环节受阻；三是样本全部来自同一渠道，渠道本身的偏好被误当成用户共性。填写时可以在表下加一行“本次样本不覆盖谁”，把已知的局限写出来，结论使用时就有边界。
验证信号怎么写：从表态到可观察行为
验证信号是用户做出的、可以被记录的动作或明确表态。信号的可信度差别很大，建议按下面的层次选择，并优先采用与假设最贴近的那一层。
| 信号层级 | 典型形式 | 采集方式 | 可信度说明 |
|---|---|---|---|
| 口头表态 | 说“这个有用”“我会用” | 访谈记录、问卷开放题 | 受提问方式和关系影响，适合发现障碍，单独不足以支持投入判断 |
| 承诺性动作 | 留下联系方式、预约试用、邀请同事参与 | 报名表、预约记录 | 付出少量成本，比口头表态更强，但仍可能不转化为使用 |
| 真实使用行为 | 完成关键任务、重复使用、按预期路径操作 | 产品埋点、任务观察记录 | 与假设最贴近，需要明确任务定义和记录位置 |
| 付费或替换现有方案 | 付费、续费、停用原工具 | 订单记录、迁移记录 | 成本最高，信号最强，观察周期也最长 |
写信号时要落到具体动作和记录位置。例如“用户认可新流程”应改为“用户在引导后独立完成一次完整流程，且七天内再次使用不少于两次，记录在任务完成日志中”。这样在判定阶段可以直接核对，不依赖回忆或印象。
信号清单要同时包含支持性和挑战性两类。只收集支持假设的信号，等于把验证变成寻找理由。可以在假设卡中固定写一栏“什么现象会让我怀疑这个假设”，例如目标用户完成任务的比例低于预期、用户仍回到原有替代做法、承诺试用后未实际使用。这类信号往往比正面反馈更有决策价值。
判定条件怎么写：阈值、时间窗与推翻条件
判定条件决定验证结束后如何下结论。它由三要素组成：指标口径（统计什么、怎么算）、阈值（达到多少算支持或推翻）、观察时间窗（从何时到何时、多长周期）。三者缺一，结论就容易在讨论中被重新解释。
判定条件应写成三档，而不是只有“成功”和“失败”：
| 档位 | 写法 | 对应动作 |
|---|---|---|
| 支持 | 指标达到或超过支持阈值，且时间窗内样本量满足要求 | 进入方案设计或扩大验证 |
| 推翻 | 指标低于推翻阈值，或出现预设的挑战性信号 | 停止当前方案，回到障碍判断重新假设 |
| 证据不足 | 指标落在两档之间，或样本量、观察周期未达要求 | 补充样本或延长观察，不直接下结论 |
阈值设定要有依据。常见来源包括：现有流程的基线数据（如当前完成率）、历史同类功能的参照、业务上可接受的最低水平。没有基线时，可以先做小范围测量取得基线，再设定阈值；也可以在假设卡中写明“本次阈值为初始估计，依据是某次观察”，把依据和不确定性一起记录下来，避免把估计值当成确定标准。
判定条件必须在验证开始前锁定。锁定后如需变更，要记录变更原因、变更人和时间，并与原条件并列保留。这样在复盘时能区分“假设不成立”和“标准被调整过”两种情况。判定会议应逐条对照原条件宣读结论，而不是先看数据再讨论标准。
角色分工与交付物：谁写、谁执行、谁判定
假设卡要能交接，就需要明确每个角色输入什么、输出什么。下表给出一种常见分工，团队可按规模调整，但每项交付物都应有明确负责人。
| 角色 | 输入 | 输出物 |
|---|---|---|
| 产品负责人 | 业务目标、用户反馈、现有数据 | 假设陈述、判定条件初稿、下一步动作预案 |
| 用户研究或设计 | 假设陈述、验证对象要求 | 招募说明、访谈或任务脚本、原始记录 |
| 数据或分析角色 | 指标口径、埋点或统计需求 | 指标定义、数据提取结果、口径说明 |
| 业务或销售侧 | 真实用户名单、场景信息 | 样本推荐、场景确认、一线反馈 |
判定会议建议由产品负责人主持，用户研究、数据角色和业务侧参与，逐条对照判定条件给出结论，并记录三档结论中的哪一档、依据哪份证据、下一步动作是什么。结论记录应包含假设编号、验证时间窗、实际样本量、指标结果和结论档位，便于后续复盘时追溯。
假设卡、证据材料和判定结论应归档在同一位置，并与对应的需求或方案记录关联。这样当方案推进到设计或开发阶段时，团队能回看当初的判断依据；当结论被推翻时，也能找到是哪条证据触发的。对于需要多人协作的团队，可以把假设卡作为工作项或文档管理：假设陈述、验证对象和判定条件写在卡片字段中，访谈记录、数据结果作为附件或关联记录，判定结论通过评审流程确认后更新状态。ONES 的工作项与文档能力可以承载这类记录与流转，具体字段和流程按团队现有配置设置。
完整示例：一个模糊想法如何写成假设卡
以下为演示情景，用于说明填写方式，不代表真实项目数据。
原始模糊想法：“做一个更智能的报表功能，让用户少花时间。”这句话包含多个判断，无法直接验证。先拆成一条最核心的假设：用户在当前报表流程中卡在整理环节，而不是缺少分析能力。
改写后的假设陈述：我们相信，每周需要向管理层提交周报的运营专员，在汇总多个渠道数据时，因为需要手动合并三张表格并核对口径，需要一键生成口径统一的汇总报表；如果判断成立，他们会在首次使用后一周内重复使用该功能两次以上，并减少手动导出次数。
验证对象：运营专员，负责周报，使用该流程三个月以上；当前替代做法为手动导出加表格合并；计划接触10人，有效样本6人；渠道为业务负责人推荐加产品内邀请；本次样本不覆盖管理层和财务审核角色。
验证信号：访谈中描述合并表格的具体耗时（口头表态，用于确认障碍）；预约试用并提交一份真实数据（承诺性动作）；试用后一周内重复使用次数和手动导出次数变化（真实使用行为，作为主要判定信号）；是否停用手动合并流程（替换现有方案，作为长期观察信号）。
判定条件：指标口径为“试用后七天内重复使用次数”和“手动导出次数相对基线变化”；支持条件为6名有效样本中至少4人重复使用两次以上且手动导出次数下降；推翻条件为超过半数样本仍按原方式合并表格，或明确表示不会改变现有流程；证据不足为样本不足6人或观察期未满七天。观察时间窗为试用开始后七天。判定条件在试用开始前锁定。
结果对应：若达到支持条件，进入方案细化并扩大样本；若触发推翻条件，回到障碍判断，重新确认用户卡点是否在合并环节；若证据不足，补充样本或延长观察，不直接进入开发。结论记录中写明假设编号、实际样本量、指标结果和下一步动作，与原假设卡一并归档。
完成检查：假设卡交付前的核对项
一张假设卡在进入验证前，可以按下面清单逐项核对。任一项不满足，先补充再启动验证。
- 假设陈述只包含一个待验证判断，四段齐全，目标用户、场景、障碍和预期行为都能被观察。
- 表述中没有“用户会喜欢”“体验更好”这类无法采集的判断，预期价值写成了具体动作或频次。
- 验证对象写明了人群特征、使用场景、当前替代做法、样本数量和招募渠道，并标注了本次不覆盖的人群。
- 验证类型（定性或定量）与结论要支撑的决策相匹配，样本规模与结论强度一致。
- 信号清单包含行为层信号，而不只有口头表态；每条信号写明了采集方式和记录位置。
- 信号清单中写有挑战性信号，即什么现象会让人怀疑假设。
- 判定条件包含指标口径、支持阈值、推翻阈值和观察时间窗，并设有证据不足档。
- 阈值写明了设定依据，没有依据的部分标注为初始估计。
- 判定条件在验证开始前锁定，变更记录包含原因、变更人和时间。
- 角色分工明确到人，假设卡、证据和结论有统一归档位置，并与对应需求记录关联。
核对完成后，假设卡即可交付执行。验证结束后，无论结论是支持、推翻还是证据不足，都应把结论和下一步动作写回同一张卡，形成可追溯的记录。
常见问题
验证做到一半发现判定条件设得不合理，可以改吗？
可以改，但要留下记录。判定条件在验证开始前锁定的目的，是防止看到数据后再调整标准。如果执行中发现阈值明显脱离实际，例如基线数据与预估差距很大，应记录变更原因、变更人和时间，并把原条件与新条件并列保留。复盘时据此区分“假设不成立”和“标准被调整过”两种情况。
更稳妥的做法是在验证前先做小范围基线测量，把阈值建立在已有数据上，减少中途变更的需要。
只有几次用户访谈，结论能直接支撑开发投入吗？
小样本定性访谈适合判断方向是否存在、障碍描述是否准确，可以支持“值得继续投入验证”的判断，难以支撑比例类结论。如果决策需要估计行为发生率或转化水平，应补充较大样本的定量验证，并明确指标口径和观察时间窗。
在假设卡中写明本次验证类型和结论将用于什么决策，可以避免用几次访谈的结论去支撑需要比例判断的投入决策。
用户口头说“会用”，但实际没用，这种情况怎么处理？
口头表态受提问方式和关系影响，单独不足以支持投入判断。可以在信号清单中把口头表态用于确认障碍，把真实使用行为作为主要判定信号，例如首次使用后一周内的重复使用次数、关键任务完成情况。承诺性动作如预约试用、提交真实数据，比口头表态更强，但仍需观察后续是否转化为使用。
同时预设挑战性信号，例如承诺试用后未实际使用、用户仍回到原有替代做法，这类现象往往比正面反馈更有决策价值。
验证对象只找活跃用户可以吗？
只找活跃用户会低估障碍，因为流失用户和从未使用的用户往往卡在更早的环节。验证对象建议至少包含一类“当前替代做法不同”的用户，用来观察方案是否真的改变了行为。如果受条件限制只能接触活跃用户，应在假设卡中写明“本次样本不覆盖谁”，结论使用时保留相应边界。
同样需要留意只找决策者而忽略实际执行者的情况，方案在落地环节受阻时往往与此有关。
假设卡和验证结论应该放在哪里，方便后续回看？
假设卡、证据材料和判定结论应归档在同一位置，并与对应的需求或方案记录关联。这样方案推进到设计或开发阶段时，团队能回看当初的判断依据；结论被推翻时，也能找到是哪条证据触发的。
多人协作的团队可以把假设卡作为工作项或文档管理：假设陈述、验证对象和判定条件写在卡片字段中，访谈记录、数据结果作为附件或关联记录，判定结论通过评审流程确认后更新状态。ONES 的工作项与文档能力可以承载这类记录与流转，具体字段和流程按团队现有配置设置。
