第2章 假设定义SOP
假设定义是MVP验证循环的起点，它决定了“验证什么”和“验证优先级”。本章提供一套标准化操作程序，帮助团队从用户痛点、价值主张、技术可行性三个维度系统定义关键假设，并通过优先级排序聚焦核心风险，最终输出结构化的假设文档。
💡 核心原则：假设不是猜测，而是基于调研数据与业务逻辑的可验证命题。好的假设应该是“可证伪、可测量、可执行”的。
1. 适用场景
- 产品团队启动MVP验证前，需系统梳理核心业务假设
- 已有初步用户调研数据，但未形成结构化假设清单
- 多部门协作时，需要统一假设定义语言和优先级标准
- 产品方向存在多个可能性，需通过假设排序聚焦资源
2. 前置条件
- 已完成至少一轮目标用户访谈或问卷调研（样本量 ≥ 15 份）
- 已初步定义产品愿景与目标用户画像
- 团队核心角色（产品经理、技术负责人、业务负责人）已到位
- 已准备白板/在线协作工具（如 Miro、Figma）用于分组讨论
3. 操作步骤
-
3.1 定义用户痛点假设
基于用户调研数据，识别并描述目标用户在特定场景下遇到的真实问题。
- 输入：用户访谈记录、问卷数据、行为日志分析
- 格式：“作为 [用户角色]，在 [场景] 下，遇到了 [问题描述]”
- 示例：“作为小微企业主，在月底对账时，遇到了多个银行流水手动合并耗时且易出错的问题”
- 产出：用户痛点清单（每条痛点附原始数据引用）
-
3.2 定义价值主张假设
明确产品如何解决上述痛点，定义核心价值和差异化优势。
- 输入：用户痛点清单、竞品分析报告
- 格式：“我们的产品通过 [核心功能]，帮助 [用户角色] 实现 [价值]”
- 示例：“我们的产品通过自动聚合多银行流水功能，帮助小微企业主实现一键对账，节省 80% 对账时间”
- 产出：价值主张声明（每条痛点对应一条价值主张）
-
3.3 定义技术可行性假设
评估实现价值主张所需关键技术的可行性与风险。
- 输入：价值主张声明、技术预研报告
- 评估维度：技术成熟度、团队能力、第三方依赖、合规要求
- 格式：“采用 [技术方案]，成熟度 [高/中/低]，主要风险为 [风险描述]”
- 示例：“采用银行开放API直连方案，成熟度中，主要风险为部分银行接口稳定性不足”
- 产出：技术可行性评估表（含风险等级与备选方案）
-
3.4 假设优先级排序
使用“影响力-可行性”矩阵对假设进行排序，聚焦最高价值、最低风险的假设优先验证。
- 输入：用户痛点清单、价值主张声明、技术可行性评估表
- 方法：团队投票或加权评分，按影响力（1-5分）和可行性（1-5分）打分
- 分类规则：
- P0（核心假设）：影响力 ≥ 4 且 可行性 ≥ 4——必须优先验证
- P1（重要假设）：影响力 ≥ 3 且 可行性 ≥ 3——计划验证
- P2（次要假设）：其余假设——条件允许时验证
- 产出：优先级排序列表（P0/P1/P2 三级）
-
3.5 输出假设文档模板
将前四步结果按标准化模板归档，确保团队对假设的理解一致且可追溯。
- 输入：优先级排序列表、各步骤产出物
- 模板字段：假设ID、假设类型、假设描述、来源数据、优先级、验证方法、验收标准、责任人
- 产出：《项目假设文档 V1.0》（纳入版本管理）
4. 输入输出物
| 环节 | 输入物 | 输出物 |
|---|---|---|
| 用户痛点假设 | 用户访谈记录、问卷数据、行为日志 | 用户痛点清单（含数据引用） |
| 价值主张假设 | 用户痛点清单、竞品分析报告 | 价值主张声明表 |
| 技术可行性假设 | 价值主张声明、技术预研报告 | 技术可行性评估表（含风险等级） |
| 假设优先级排序 | 痛点清单 + 价值主张声明 + 技术评估表 | 优先级排序列表（P0/P1/P2） |
| 假设文档模板 | 以上所有产出物 | 《项目假设文档 V1.0》 |
5. 责任边界
- 产品经理：负责用户痛点假设、价值主张假设的定义与文档撰写，组织优先级排序会议
- 技术负责人：负责技术可行性假设的评估与风险标注
- 业务/运营负责人：提供用户数据与业务背景，参与优先级打分
- 决策委员会/产品总监：审批最终假设文档与优先级排序结果
6. 记录材料
假设文档是本章核心产出物，以下为标准化模板字段说明：
| 字段 | 说明 | 填写示例 |
|---|---|---|
| 假设ID | 唯一标识，按类型+序号编码 | H-PAIN-001 |
| 假设类型 | 痛点/价值/技术 | 用户痛点假设 |
| 假设描述 | 按照标准格式描述 | 作为小微企业主，月底对账时手动合并多银行流水耗时易错 |
| 来源数据 | 引用原始数据编号 | 用户访谈 #3、#7；问卷结果 Q5 |
| 优先级 | P0 / P1 / P2 | P0 |
| 验证方法 | 计划采用的验证方式 | MVP原型+5名用户可用性测试 |
| 验收标准 | 可量化的成功指标 | 80%的用户在 3 分钟内完成对账操作 |
| 责任人 | 验证执行人 | 张三（产品经理） |
📋 填表示例（完整一条假设）：
假设ID：H-PAIN-001
假设类型：用户痛点假设
假设描述：作为小微企业主，在月底对账时，遇到了多个银行流水手动合并耗时且易出错的问题
来源数据：用户访谈 #3、#7、#12；问卷调研 N=43，78% 表示对账耗时 > 2 小时
优先级：P0（影响力 5，可行性 4）
验证方法：开发单功能MVP（自动合并流水），邀请6位目标用户试用并记录完成时间
验收标准：平均对账时间从 2.5 小时降至 ≤ 30 分钟，用户满意度 ≥ 4/5
责任人：张三（产品经理）
假设ID：H-PAIN-001
假设类型：用户痛点假设
假设描述：作为小微企业主，在月底对账时，遇到了多个银行流水手动合并耗时且易出错的问题
来源数据：用户访谈 #3、#7、#12；问卷调研 N=43，78% 表示对账耗时 > 2 小时
优先级：P0（影响力 5，可行性 4）
验证方法：开发单功能MVP（自动合并流水），邀请6位目标用户试用并记录完成时间
验收标准：平均对账时间从 2.5 小时降至 ≤ 30 分钟，用户满意度 ≥ 4/5
责任人：张三（产品经理）
7. 异常处理
| 异常场景 | 应对措施 |
|---|---|
| 假设定义模糊、无法验证 | 组织专题讨论会，补充用户调研数据，强制使用“用户+场景+问题”格式改写 |
| 假设清单过长（>15 条） | 执行影响力-可行性矩阵强制过滤，P0 假设不超过 5 条，其余存入“待验证池” |
| 技术可行性无法判断 | 引入外部技术专家评审，或安排 1-2 天技术 Spike（原型验证） |
| 团队对优先级存在严重分歧 | 使用加权投票法（每人 5 分，投给认为最重要的假设），取平均分排序 |
| 关键利益相关者未参与讨论 | 将假设文档异步发送并收集书面反馈，在 48 小时内完成审批 |
⚠️ 常见陷阱：不要将“解决方案”与“假设”混为一谈。例如“用户需要AI助手”是解决方案，而非假设；正确的假设应是“用户在处理XX任务时，因信息过载导致决策效率低”。始终从问题出发，而非从方案出发。
8. 验收标准
- 假设文档已创建，包含全部 8 个必填字段
- 每条假设均附有原始数据引用（访谈编号/问卷结果）
- 优先级标签（P0/P1/P2）已明确标注，且 P0 假设 ≤ 5 条
- 技术可行性评估已覆盖所有关键风险，并标注了风险等级
- 团队已完成一轮正式评审并达成共识（留存会议纪要）
- 假设文档已上传至团队知识库或版本管理平台（如 Confluence、Notion）