名称: 史诗假设框架 描述: 使用if/then结构将史诗级功能框架化为可测试的假设，明确行动或解决方案、目标受益者、预期成果以及如何验证成功。使用此方法管理产品开发中的不确定性，通过使假设显式化、定义轻量级实验（“微小发现行为”）并在全面构建之前建立可衡量的成功标准。
这不是需求规格书——它是一个正在测试的假设，而不是承诺交付的功能。
核心概念
史诗假设框架
受Tim Herbig的Lean UX假设格式启发，结构如下：
If/Then假设：
- 如果我们 [代表目标用户角色的行动或解决方案]
- 为 [目标用户角色]
- 那么我们将 [实现或达成一个期望的成果或待完成任务]
微小发现行为实验：
- 我们将通过以下方式测试我们的假设：
- [实验1]
- [实验2]
- [根据需要添加更多]
验证指标：
- 我们知道我们的假设是有效的，如果在 [时间段]
- 我们观察到：
- [定量可衡量成果]
- [定性可衡量成果]
- [根据需要添加更多]
为什么这种结构有效
- 假设驱动： 强制陈述你的信念（可能出错）
- 成果导向： “那么我们将”强调用户利益，而不是功能输出
- 实验优先： 鼓励在全面构建前进行轻量级验证
- 可证伪： 明确的成功标准使得尽早淘汰不良想法成为可能
- 风险管理： 将史诗视为赌注，而非承诺
反模式（这不是什么）
- 不是功能规格书： “构建一个带5个图表的仪表板”是一个功能，不是假设
- 不是承诺： 假设可以被（并且应该被）证明无效
- 不是输出导向： “在第二季度前交付功能X”忽略了重点——它是否达成了成果？
- 不是无实验： 如果跳过实验直接构建，你就不是在测试假设
何时使用此框架
- 早期功能探索（在完全投入路线图之前）
- 验证新能力的市场契合度
- 优先排序积压工作（已验证的假设获得更高优先级）
- 管理利益相关者期望（将工作框架化为实验，而非承诺）
何时不使用此框架
- 对于已验证的功能（如果已证明需求，直接跳转用户故事）
- 对于微小功能（不要过度工程小调整）
- 当实验不可行时（罕见，但有时必须在测试前承诺）
应用
使用template.md获取完整的填写结构。
步骤1: 收集上下文
在起草史诗假设之前，确保拥有：
- 问题理解： 这解决了什么用户问题？（参考
skills/problem-statement/SKILL.md） - 目标用户角色： 谁受益？（参考
skills/proto-persona/SKILL.md） - 待完成任务： 他们试图达成什么成果？（参考
skills/jobs-to-be-done/SKILL.md） - 当前替代方案： 用户今天做什么？（竞争对手、变通办法、无所作为）
如果缺少上下文： 首先进行发现访谈或问题验证工作。
步骤2: 起草If/Then假设
填写模板：
### If/Then假设
**如果我们** [代表目标用户角色的行动或解决方案]
**为** [目标用户角色]
**那么我们将** [为用户角色实现或达成的期望成果或待完成任务]
质量检查：
- “如果我们”要具体： 不是“改进产品”而是“添加一键式Slack通知当任务被分配时”
- “为”是清晰的用户角色： 不是“用户”而是“远程项目经理管理3个以上分布式团队”（参考
skills/proto-persona/SKILL.md） - “那么我们将”是成果： 不是“用户将有通知”而是“用户响应任务分配的速度加快50%”
示例：
- ✅ “如果我们为试用用户添加一键Google Calendar集成，那么我们将在30天内将激活率提高20%”
- ✅ “如果我们为管理1000多个项目的强大用户提供批量删除功能，那么我们将减少清理任务的时间70%”
- ❌ “如果我们构建仪表板，那么用户将使用它”（模糊、不可衡量）
步骤3: 设计微小发现行为实验
在构建完整史诗之前，定义轻量级实验以测试假设：
### 微小发现行为实验
**我们将通过以下方式测试我们的假设：**
- [实验1: 低成本、快速测试]
- [实验2: 另一个低成本、快速测试]
- [根据需要添加更多]
实验类型：
- 原型 + 用户测试： 用可点击原型模拟功能，与5-10名用户测试
- 管家测试： 为少数用户手动执行功能，看他们是否重视
- 登录页测试： 描述功能，测量注册或兴趣
- Wizard of Oz测试： 呈现功能为自动化，但在幕后手动操作
- A/B测试（如果可行）： 测试轻量版本 vs 控制组
质量检查：
- 快速： 实验应持续几天/周，不是月
- 廉价： 避免全面工程构建——使用原型、手动过程或现有工具
- 可证伪： 设计可证明你错误的实验
示例：
- “创建批量删除流程的Figma原型，并与5名强大用户测试”
- “手动向10名试用用户发送Slack通知并跟踪响应时间”
- “向UI添加‘请求此功能’按钮并测量点击率”
步骤4: 定义验证指标
指定成功的样子和评估时间框架：
### 验证指标
**我们知道我们的假设是有效的，如果在** [天数或周数]
**我们观察到：**
- [期望的定量可衡量成果]
- [期望的定性可衡量成果]
- [根据需要添加更多]
质量检查：
- 时间框架现实： 不是“6个月内”（太慢）或“3天内”（太快）
- 定量指标具体： 不是“更多用户”而是“激活率提高20%”
- 定性指标可观察： 不是“用户喜欢它”而是“10名用户中有8名表示他们会为此功能付费”
示例：
- ✅ “4周内，我们观察到：”
- “激活率从40%提高到50%（定量）”
- “75%的调查试用用户说集成节省了时间（定性）”
- ❌ “1年内，我们观察到：”
- “收入增加”（太模糊、时间太长）
步骤5: 运行实验并评估
- 执行实验： 构建原型、运行测试、收集数据
- 测量结果： 是否达到验证指标？
- 决策点：
- ✅ 假设验证： 继续构建用户故事并添加到路线图
- ❌ 假设无效： 淘汰史诗或转向不同假设
- ⚠️ 无定论： 运行额外实验或收紧验证指标
步骤6: 转换为用户故事（如果验证）
一旦假设验证，将史诗分解为用户故事：
### 史诗: [史诗名称]
**故事：**
1. [用户故事1 - 参考`skills/user-story/SKILL.md`]
2. [用户故事2]
3. [用户故事3]
示例
查看examples/sample.md获取完整史诗假设示例。
迷你示例摘录：
**如果我们** 提供一键Google Calendar集成
**为** 管理多个会议的试用用户
**那么我们将** 将激活率从40%提高到50%
常见陷阱
陷阱1: 假设是功能，不是成果
症状： “如果我们构建仪表板，那么我们将有仪表板”
后果： 描述输出，不是成果。这不测试任何东西。
修复： 关注用户成果：“如果我们构建显示实时任务状态的仪表板，那么项目经理将花费50%更少时间询问状态更新。”
陷阱2: 跳过实验
症状： “我们将通过构建完整功能测试我们的假设”
后果： 在验证前承诺构建。不是假设——是功能承诺。
修复： 设计轻量级实验（原型、管家测试、登录页）需要几天/周，不是月。
陷阱3: 模糊验证指标
症状： “我们知道它有效如果用户开心”
后果： 成功标准主观且不可衡量。
修复： 定义具体、可证伪指标：“80%的调查用户给功能评分4+分（满分5）”或“响应时间下降50%。”
陷阱4: 不现实时间框架
症状： “我们知道它有效如果在6个月内收入增加”
后果： 太慢无法指导决策。那时你已经构建了。
修复： 目标2-4周验证周期。如果不能在那个时间框架衡量，选择领先指标（例如，激活率，不是年收入）。
陷阱5: 将史诗视为承诺
症状： “我们已经告诉CEO我们要交付这个，所以我们必须验证它”
后果： 实验是表演——无论结果如何都要构建。
修复： 在承诺前将史诗框架化为假设。如果利益相关者需要确定性，解释构建未验证功能的风险。
参考
相关技能
skills/problem-statement/SKILL.md— 假设应解决已验证问题skills/proto-persona/SKILL.md— 定义“为 [用户角色]”部分skills/jobs-to-be-done/SKILL.md— 告知“那么我们将”成果skills/user-story/SKILL.md— 验证的史诗分解为用户故事skills/user-story-splitting/SKILL.md— 如何将验证的史诗分解为故事
外部框架
- Tim Herbig, Lean UX假设声明 — If/then假设格式起源
- Jeff Gothelf & Josh Seiden, Lean UX (2013) — 假设驱动产品开发
- Alberto Savoia, Pretotype It (2011) — 轻量级实验验证想法
- Eric Ries, The Lean Startup (2011) — 构建-测量-学习循环
Dean的作品
- 积压史诗假设提示（受Tim Herbig框架启发）
来源
- 改编自
prompts/backlog-epic-hypothesis.md在https://github.com/deanpeters/product-manager-prompts仓库。
技能类型： 组件
建议文件名： epic-hypothesis.md
建议放置： /skills/components/
依赖项： 参考skills/problem-statement/SKILL.md, skills/proto-persona/SKILL.md, skills/jobs-to-be-done/SKILL.md
使用方： skills/user-story/SKILL.md, skills/user-story-splitting/SKILL.md