第2章 需求与假设定义方法
需求与假设定义是数据产品迭代的起点。本章提供一套从用户痛点拆解到可验证假设归档的完整SOP，确保每次迭代都基于可被证伪的清晰假设，而非模糊直觉。
核心原则：一个可验证假设 = 明确的目标用户 + 可观察的行为变化 + 可量化的成功指标。无法被证伪的假设不是好假设。
1. 适用场景
- 数据产品进入新功能探索阶段，需定义最小可行假设。
- 已有用户反馈或行为数据，但尚未提炼为结构化验证任务。
- 需要统一团队对“验证什么、如何验证”的认知，避免资源浪费。
- 产品迭代进入快速实验周期，每个实验需前置假设定义。
2. 前置条件
- 已完成用户反馈收集或数据分析看板搭建（至少有一手数据来源）。
- 产品经理与数据工程师已对齐本次迭代的业务目标。
- 团队已选定统一的假设记录工具（如Airtable、飞书多维表格、Notion）。
- 至少有一名具备用户研究或数据分析能力的成员参与。
3. 操作步骤
步骤3.1：用户痛点拆解
从原始反馈或行为数据中提取真实痛点，避免将“解决方案”误当成“问题”。使用“5 Whys”追问法剥离表层需求。
| 痛点来源 | 原始表述 | 深层痛点（拆解后） |
|---|---|---|
| 用户访谈 | “报表加载太慢了” | 用户在做日报时等待时间超过15秒，打断工作流专注度 |
| 客服工单 | “不知道筛选条件是否生效” | 筛选后无即时反馈，用户对数据范围缺乏掌控感 |
| 行为数据 | 导出功能点击率低 | 导出格式不匹配下游系统，用户需二次加工 |
拆解技巧：每次追问“这个痛点背后用户真正想完成的任务是什么？”直到答案指向一个不可再分的行为障碍。
步骤3.2：可验证假设撰写
将拆解后的痛点转化为“如果…那么…”结构的可验证语句。每一条假设必须包含：目标用户、干预手段、预期行为变化、衡量指标。
标准假设模板：
如果 [目标用户] 在 [场景] 中获得了 [干预手段]，
那么 [可观察的行为变化]，
因为 [底层原因/驱动逻辑]。
示例：
如果“日报制作者”在“加载报表页”时看到“进度分步提示”，
那么“等待焦虑工单量”将下降 30%，
因为用户对系统状态有了明确预期。步骤3.3：假设优先级排序
使用 ICE 或 RICE 框架对假设进行评估，避免在低价值假设上浪费验证资源。
| 评分维度 | ICE 释义 | RICE 释义 | 评分范围 |
|---|---|---|---|
| I / R | Impact 影响程度 | Reach 触达用户数 | 1–5 |
| C / I | Confidence 信心指数 | Impact 影响程度 | 1–5 |
| E / C | Ease 实现难度 | Confidence 信心指数 | 1–5 |
| — / E | — | Effort 开发工作量 | 1–5 |
排序规则：ICE 总分 = (I + C + E) / 3；RICE 总分 = (R × I × C) / E。取总分降序排列，优先验证 TOP 3 假设。
避坑说明：信心指数（Confidence）不能仅凭“感觉”打分，必须基于过往数据或类似实验结论。当 Confidence < 3 时，建议先做定性探索，不要直接进入定量验证。
步骤3.4：假设记录模板使用
每条假设必须按照统一模板归档，形成可追溯的假设库。字段定义如下：
假设 ID | HYP-2025-0021
假设标题 | 报表进度提示降低等待焦虑
痛点来源 | 客服工单 + 用户访谈（2025-03-12）
目标用户 | 日报制作者（每日使用报表 ≥1次）
干预手段 | 加载时显示分步进度条
预期行为变化 | 等待焦虑工单量下降 30%
衡量指标 | 工单量 / 周；加载页跳出率
ICE 评分 | I:4 C:3 E:4 → 总分:3.67
优先级排名 | 第2优先
验证方法 | A/B 实验，实验组 vs 对照组
预期验证周期 | 2 周
创建人 | 张XX
创建日期 | 2025-03-14
状态 | 待验证4. 输入输出物
| 类型 | 名称 | 格式/来源 | 负责人 |
|---|---|---|---|
| 输入 | 原始用户反馈列表 | 访谈记录 / 客服工单 / 行为日志 | 产品经理 |
| 输入 | 当前业务目标文档 | OKR / KPI 看板 | 产品负责人 |
| 输出 | 可验证假设清单 | 多维表格（含 ICE/RICE 评分） | 产品经理 + 数据分析师 |
| 输出 | 假设优先级排期表 | 看板 / 迭代计划 | 迭代经理 |
5. 责任边界
| 角色 | 职责 | 不承担的职责 |
|---|---|---|
| 产品经理 | 主导痛点拆解与假设撰写，组织优先级排序会 | 不负责具体实验代码实现 |
| 数据分析师 | 提供数据依据，审核假设的可衡量性 | 不负责用户招募 |
| 开发工程师 | 评估实现难度（Ease / Effort 评分） | 不负责假设有效性判断 |
| 迭代经理 | 将高优先级假设排入迭代看板 | 不参与评分维度设计 |
6. 记录材料
- 假设记录表：包含本章步骤3.4模板的完整字段，每条假设一条记录。
- 优先级评分会议纪要：记录各维度评分依据、争议点及最终排名。
- 痛点溯源图：从原始反馈到根因的拆解链路（可用Mermaid或XMind导出）。
7. 异常处理
| 异常场景 | 处理措施 | 触发条件 |
|---|---|---|
| 痛点描述模糊，无法形成假设 | 回退到用户访谈或可用性测试，补充定性数据 | 连续3次拆解后仍无法定位根因 |
| ICE 评分高度同分 | 引入“验证周期”作为第二排序维度，周期短的优先 | TOP 3 假设总分差值 ≤ 0.2 |
| Confidence 评分普遍偏低（全部 <3） | 停止批量假设定义，先投入探索性研究 | 所有假设的 Confidence 均 <3 |
| 假设与当前迭代目标冲突 | 暂缓假设，放入“Backlog”由产品负责人重新定级 | 假设目标与 OKR 对齐度 < 50% |
8. 验收标准
- 已输出至少 5 条完整格式的可验证假设，每条均包含目标用户、干预手段、预期变化和衡量指标。
- 每条假设均已通过 ICE 或 RICE 评分，并按总分降序排列。
- 优先级 TOP 3 的假设已被排入下一迭代看板，并指定了验证负责人。
- 所有假设记录已归档至团队共享表格，字段完整度 ≥ 95%。
- 痛点拆解过程有书面记录（溯源图或5 Whys文档），可供回溯审计。
本章关联工具：推荐使用“Airtable 假设记录模板”或“飞书多维表格 - 假设看板”作为落地载体，字段与步骤3.4模板完全对齐。
本章所有步骤均需在迭代启动前完成，假设记录表作为迭代计划会议的入场材料。未通过验收标准的假设不得进入开发排期。