epic-hypothesis

目的

使用 if/then 结构将史诗（epic）构建为可测试的假设，明确说明行动或解决方案、目标受益者、预期结果，以及如何验证成功。通过明确假设、定义轻量级实验（“微型探索行动”），并在决定全面开发之前设定可衡量的成功标准，借此管理产品开发中的不确定性。

这不是需求规格说明——这是一个待验证的假设，而不是你承诺要交付的功能。

输入

最适用的内容： 计划或史诗的构想，无论目前是什么形式——一句话就够。 也有帮助的内容： 目标用户、预期结果，以及你可能采用的衡量方式（此技能会帮助你完善这三项）。

随调用一同提供的任何内容——技能名称之后的文本、粘贴的上下文，或附加的 ARGUMENTS: 行——都视为已提供的答案。请使用这些内容，并跳过其中已涵盖的问题；不要重复询问。

空手而来？也没关系。 此技能会询问计划是什么、面向谁，然后与你一起构建 if/then 假设。

调用示例： Frame as an epic hypothesis: adding usage-based alerts so account admins catch overages before invoice shock.

核心概念

史诗假设框架

该结构受 Tim Herbig 的 Lean UX 假设格式启发：

If/Then 假设：

• 如果我们 [代表目标角色采取行动或提供解决方案]
• 为 [目标角色]
• 那么我们将 [实现或达成理想结果或待完成的工作]

微型探索行动实验：

• 我们将通过以下方式验证假设：
  • [实验 1]
  • [实验 2]
  • [根据需要添加更多实验]

验证指标：

• 如果在 [时间范围] 内
• 我们观察到以下情况，就可以确认假设成立：
  • [可量化的定量结果]
  • [可衡量的定性结果]
  • [根据需要添加更多结果]

这种结构为何有效

• 以假设为驱动： 迫使你明确陈述自己的信念（以及可能出错的地方）
• 以结果为重点： “那么我们将”强调用户受益，而不是功能产出
• 实验优先： 鼓励在全面开发之前进行轻量级验证
• 可证伪： 明确的成功标准有助于尽早淘汰糟糕的想法
• 风险管理： 将史诗视为押注，而不是承诺

反模式（这不是什么）

• 不是功能规格： “构建一个包含 5 张图表的仪表板”是功能，而不是假设
• 不是必然兑现的承诺： 假设可以（也应该）被证伪
• 不是关注产出： “在 Q2 前发布功能 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 Hypothesis

**If we** [action or solution on behalf of the target persona]
**for** [target persona]
**Then we will** [attain or achieve a desirable outcome or job-to-be-done for the persona]

质量检查：

• “If we”要具体： 不要写“改进产品”，而要写“添加任务分配时的一键 Slack 通知”
• “For”要明确描述用户画像： 不要写“用户”，而要写“需要同时管理 3 个以上分布式团队的远程项目经理”（参见 skills/proto-persona/SKILL.md）
• “Then we will”要描述结果： 不要写“用户会收到通知”，而要写“用户响应任务分配的速度将提高 50%”

示例：

• ✅ “如果我们为试用用户添加一键 Google Calendar 集成，那么我们将在 30 天内将激活率提高 20%”
• ✅ “如果我们为管理 1000 个以上项目的高级用户提供批量删除功能，那么我们将减少 70% 的清理任务耗时”
• ❌ “如果我们构建一个仪表板，那么用户就会使用它”（含糊，无法衡量）

---

步骤 3：设计轻量级探索实验

在构建完整史诗级需求之前，先设计轻量级实验来验证假设：

### Tiny Acts of Discovery Experiments

**We will test our assumption by:**
- [Experiment 1: low-cost, fast test]
- [Experiment 2: another low-cost, fast test]
- [Add more as necessary]

实验类型：

• 原型 + 用户测试： 用可点击原型模拟功能，并邀请 5-10 位用户进行测试
• 礼宾式测试： 为少数用户手动提供该功能，观察他们是否认为它有价值
• 落地页测试： 介绍该功能，并衡量注册量或用户兴趣
• 绿野仙踪测试： 将该功能呈现为自动化功能，实际在幕后手动完成
• A/B 测试（如果可行）： 测试轻量版与对照组

质量检查：

• 快速： 实验应耗时数天或数周，而非数月
• 低成本： 避免完整的工程实现——使用原型、手动流程或现有工具
• 可证伪： 设计能够证明你 错了 的实验

示例：

• “制作批量删除流程的 Figma 原型，并邀请 5 位高级用户进行测试”
• “手动向 10 位试用用户发送 Slack 通知，并跟踪响应时间”
• “在 UI 中添加‘申请此功能’按钮，并衡量点击率”

---

步骤 4：定义验证指标

明确成功的标准和评估时间范围：

### Validation Measures

**We know our hypothesis is valid if within** [timeframe in days or weeks]
**we observe:**
- [Desirable quantitative, measurable outcome]
- [Desirable qualitative, measurable outcome]
- [Add more as necessary]

质量检查：

• 时间范围合理： 不要写“6 个月内”（太慢），也不要写“3 天内”（太快）
• 定量指标具体： 不要写“更多用户”，而要写“激活率提高 20%”
• 定性指标可观察： 不要写“用户喜欢”，而要写“10 位用户中有 8 位表示愿意为此功能付费”

示例：

• ✅ “在 4 周内，我们观察到：”
  • “激活率从 40% 提高到 50%（定量）”
  • “75% 的受访试用用户表示，该集成为他们节省了时间（定性）”
• ❌ “在 1 年内，我们观察到：”
  • “收入增长”（过于含糊，耗时过长）

---

步骤 5：运行实验并评估

• 执行实验： 构建原型、开展测试、收集数据
• 衡量结果： 是否达到验证指标？
• 决策点：
  • ✅ 假设得到验证： 开始编写用户故事并纳入路线图
  • ❌ 假设未获验证： 取消该史诗级需求，或转向其他假设
  • ⚠️ 结论不明： 开展更多实验，或收紧验证指标

---

步骤 6：转化为用户故事（验证通过后）

假设得到验证后，将史诗级需求拆分为用户故事：

### Epic: [Epic Name]

**Stories:**
1. [User Story 1 - reference `skills/user-story/SKILL.md`]
2. [User Story 2]
3. [User Story 3]

---

示例

完整的史诗级需求假设示例请参见 examples/sample.md。

简短示例摘录：

**If we** provide one-click Google Calendar integration
**for** trial users managing multiple meetings
**Then we will** increase activation rate from 40% to 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 Hypothesis Statement》——“如果/那么”假设格式的来源
• Jeff Gothelf 和 Josh Seiden，《Lean UX》（2013）——以假设为驱动的产品开发
• Alberto Savoia，《Pretotype It》（2011）——用于验证想法的轻量级实验
• Eric Ries，《The Lean Startup》（2011）——构建-衡量-学习循环

Dean 的作品

• Backlog Epic Hypothesis Prompt（受 Tim Herbig 的框架启发）

来源

• 改编自 https://github.com/deanpeters/product-manager-prompts 仓库中的 prompts/backlog-epic-hypothesis.md。

---

**技能类型：**组件 建议文件名：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