第3章 测试假设提炼

从用户痛点出发写出可验证假设，并基于结构化模板与优先级筛选标准锁定最高价值验证项。

3.1 适用场景

• 产品进入MVP验证阶段：需要将模糊的用户痛点转化为可执行的验证项，确定验证重点与顺序。
• 团队假设过多但资源有限：面对大量待验证想法，需通过统一模板和评分机制快速聚焦高价值项。
• 用户痛点已初步收集：已完成用户访谈、问卷或数据分析，但尚未形成可验证的假设语句。
• 跨团队对齐验证计划：需要让产品、设计、开发、测试等角色对验证目标达成一致理解。

3.2 前置条件

3.3 操作步骤

步骤一：从用户痛点出发，提炼核心表述

逐一审查痛点清单中的每条痛点，用一句话说清“用户在什么场景下遇到了什么具体问题”。去除模糊形容词，保留可观察、可测量的行为描述。

步骤二：应用“若[动作]则[结果]”结构化模板

将每条提炼后的痛点转化为可验证假设。模板强制要求写出“谁执行什么动作”以及“预期产生什么可测量结果”。

步骤三：假设优先级筛选——影响度 × 确定性矩阵

对每条假设进行双维度评分，计算优先级分数，按得分从高到低排序。

优先级分数 = 影响度得分 × 确定性得分（满分25分）。将所有假设填入评分表，计算并排序。

3.4 输入输出物

3.5 责任边界

3.6 记录材料

3.7 异常处理

3.8 验收标准

• 完整性：痛点清单中的每条痛点均已转化为至少一条“若[动作]则[结果]”格式的假设，无遗漏。
• 可验证性：每条假设的结果描述包含至少一个可量化指标（时间、比率、次数等），且指标可被后续测试直接观测。
• 评分一致性：所有假设均完成影响度与确定性双维度评分，且评分分歧已按异常处理流程解决。
• 排序可用性：输出优先级排序表，前3条假设被团队一致同意作为第一轮MVP验证候选。
• 文档可追溯：假设提炼工作坊记录、评分表、排序表均已归档，且标明版本号与参与人。