epic-hypothesis

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Purpose

目的

Frame epics as testable hypotheses using an if/then structure that articulates the action or solution, the target beneficiary, the expected outcome, and how you'll validate success. Use this to manage uncertainty in product development by making assumptions explicit, defining lightweight experiments ("tiny acts of discovery"), and establishing measurable success criteria before committing to full build-out.

This is not a requirements spec—it's a hypothesis you're testing, not a feature you're committed to shipping.

将Epics转化为可测试的假设，采用IF/THEN结构，明确行动或解决方案、目标受益用户、预期成果以及成功验证方式。通过明确假设、定义轻量实验（“微小探索行动”）、在全面开发前设定可衡量的成功标准，以此管理产品开发中的不确定性。

这不是需求规格说明书——这是你要测试的假设，而非承诺要交付的功能。

Key Concepts

核心概念

The Epic Hypothesis Framework

Epic假设框架

Inspired by Tim Herbig's Lean UX hypothesis format, the structure is:

If/Then Hypothesis:

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

Tiny Acts of Discovery Experiments:

We will test our assumption by:
- [Experiment 1]
- [Experiment 2]
- [Add more as necessary]

Validation Measures:

We know our hypothesis is valid if within [timeframe]
we observe:
- [Quantitative measurable outcome]
- [Qualitative measurable outcome]
- [Add more as necessary]

灵感来源于Tim Herbig的精益UX假设格式，结构如下：

IF/THEN假设：

如果我们 [为目标用户角色（Persona）采取的行动或解决方案]
面向 [目标用户角色（Persona）]
那么我们将 [实现或达成理想成果或用户待办任务（Job-to-be-Done）]

微小探索行动实验：

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

验证指标：

若在 [时间范围] 内观察到以下情况，则说明假设成立：
- [可量化的可衡量成果]
- [可定性的可衡量成果]
- [按需添加更多]

Why This Structure Works

该结构为何有效

Hypothesis-driven: Forces you to state what you believe (and could be wrong about)
Outcome-focused: "Then we will" emphasizes user benefit, not feature output
Experiment-first: Encourages lightweight validation before full build
Falsifiable: Clear success criteria make it possible to kill bad ideas early
Risk management: Treats epics as bets, not commitments

假设驱动： 迫使你明确自己的信念（以及可能出错的地方）
成果导向： “那么我们将”强调用户收益，而非功能输出
实验优先： 鼓励在全面开发前进行轻量验证
可证伪： 清晰的成功标准让你能尽早终止糟糕的想法
风险管理： 将Epics视为赌注，而非承诺

Anti-Patterns (What This Is NOT)

反模式（本框架不适用的情况）

Not a feature spec: "Build a dashboard with 5 charts" is a feature, not a hypothesis
Not a guaranteed commitment: Hypotheses can (and should) be invalidated
Not output-focused: "Ship feature X by Q2" misses the point—did it achieve the outcome?
Not experiment-free: If you skip experiments and go straight to build, you're not testing a hypothesis

不是功能规格： “构建包含5个图表的仪表盘”是功能，而非假设
不是必然承诺： 假设可以（且应该）被证伪
不是输出导向： “在Q2前交付功能X”偏离核心——它是否达成了预期成果？
不能跳过实验： 若跳过实验直接开发，你就不是在测试假设

When to Use This

适用场景

Early-stage feature exploration (before committing to full roadmap)
Validating product-market fit for new capabilities
Prioritizing backlog (epics with validated hypotheses get higher priority)
Managing stakeholder expectations (frame work as experiments, not promises)

早期功能探索（在纳入完整路线图前）
验证新功能的产品市场契合度
待办事项优先级排序（已验证假设的Epics优先级更高）
管理利益相关者期望（将工作描述为实验，而非承诺）

When NOT to Use This

不适用场景

For well-validated features (if you've already proven demand, skip straight to user stories)
For trivial features (don't over-engineer small tweaks)
When experiments aren't feasible (rare, but sometimes you must commit before testing)

已充分验证的功能（若已证明需求存在，可直接编写用户故事）
琐碎功能（无需为小调整过度设计）
无法开展实验的场景（罕见，但有时必须在测试前就投入开发）

Application

实践指南

Use

template.md

for the full fill-in structure.

使用

template.md

获取完整的填空式结构。

Step 1: Gather Context

步骤1：收集背景信息

Before drafting an epic hypothesis, ensure you have:

Problem understanding: What user problem does this address? (reference
```
skills/problem-statement/SKILL.md
```
)
Target persona: Who benefits? (reference
```
skills/proto-persona/SKILL.md
```
)
Jobs-to-be-Done: What outcome are they trying to achieve? (reference
```
skills/jobs-to-be-done/SKILL.md
```
)
Current alternatives: What do users do today? (competitors, workarounds, doing nothing)

If missing context: Run discovery interviews or problem validation work first.

在起草Epic假设前，确保你已掌握：

问题理解： 这解决了用户的什么问题？（参考
```
skills/problem-statement/SKILL.md
```
）
目标用户角色： 谁会从中受益？（参考
```
skills/proto-persona/SKILL.md
```
）
用户待办任务（Job-to-be-Done）： 他们想要达成什么成果？（参考
```
skills/jobs-to-be-done/SKILL.md
```
）
当前替代方案： 用户目前的做法是什么？（竞品、临时解决方案、或不采取任何行动）

若背景信息缺失： 先开展探索性访谈或问题验证工作。

Step 2: Draft the If/Then Hypothesis

步骤2：起草IF/THEN假设

Fill in the template:

markdown

undefined

填写以下模板：

markdown

undefined

If/Then Hypothesis

IF/THEN假设

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]


**Quality checks:**
- **"If we" is specific:** Not "improve the product" but "add one-click Slack notifications when tasks are assigned"
- **"For" is a clear persona:** Not "users" but "remote project managers juggling 3+ distributed teams" (reference `skills/proto-persona/SKILL.md`)
- **"Then we will" is an outcome:** Not "users will have notifications" but "users will respond to task assignments 50% faster"

**Examples:**
- ✅ "If we add one-click Google Calendar integration for trial users, then we will increase activation rates by 20% within 30 days"
- ✅ "If we provide bulk delete functionality for power users managing 1000+ items, then we will reduce time spent on cleanup tasks by 70%"
- ❌ "If we build a dashboard, then users will use it" (vague, not measurable)

---

如果我们 [为目标用户角色采取的行动或解决方案] 面向 [目标用户角色] 那么我们将 [为用户角色达成理想成果或用户待办任务]


**质量检查：**
- **“如果我们”部分需具体：** 不要写“改进产品”，而要写“当任务被分配时添加一键式Slack通知”
- **“面向”部分需明确用户角色：** 不要写“用户”，而要写“同时管理3个以上分布式团队的远程项目经理”（参考`skills/proto-persona/SKILL.md`）
- **“那么我们将”部分需聚焦成果：** 不要写“用户将收到通知”，而要写“用户响应任务分配的速度将提升50%”

**示例：**
- ✅ “如果我们为试用用户添加一键式Google Calendar集成，那么我们将在30天内将激活率提升20%”
- ✅ “如果我们为管理1000+条数据的核心用户提供批量删除功能，那么我们将把他们用于清理任务的时间减少70%”
- ❌ “如果我们构建一个仪表盘，那么用户会使用它”（模糊，无法衡量）

---

Step 3: Design Tiny Acts of Discovery Experiments

步骤3：设计微小探索行动实验

Before building the full epic, define lightweight experiments to test the hypothesis:

markdown

undefined

在全面开发Epic前，定义轻量实验来验证假设：

markdown

undefined

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]


**Experiment types:**
- **Prototype + user testing:** Fake the feature with a clickable prototype, test with 5-10 users
- **Concierge test:** Manually perform the feature for a few users, see if they value it
- **Landing page test:** Describe the feature, measure sign-ups or interest
- **Wizard of Oz test:** Present the feature as if it's automated, but do it manually behind the scenes
- **A/B test (if feasible):** Test a lightweight version vs. control

**Quality checks:**
- **Fast:** Experiments should take days/weeks, not months
- **Cheap:** Avoid full engineering builds—use prototypes, manual processes, or existing tools
- **Falsifiable:** Design experiments that could prove you *wrong*

**Examples:**
- "Create a Figma prototype of the bulk delete flow and test with 5 power users"
- "Manually send Slack notifications to 10 trial users and track response time"
- "Add a 'Request this feature' button to the UI and measure click-through rate"

---

我们将通过以下方式验证假设：

[实验1：低成本、快速测试]
[实验2：另一项低成本、快速测试]
[按需添加更多]


**实验类型：**
- **原型+用户测试：** 用可点击原型模拟功能，邀请5-10名用户测试
- **礼宾式测试：** 为少量用户手动提供功能，观察他们是否认可其价值
- **着陆页测试：** 描述功能，衡量注册量或兴趣度
- **绿野仙踪测试：** 将功能呈现为自动化效果，但后台手动执行
- **A/B测试（若可行）：** 测试轻量版本与对照组

**质量检查：**
- **快速：** 实验应耗时几天/几周，而非数月
- **低成本：** 避免完整工程开发——使用原型、手动流程或现有工具
- **可证伪：** 设计的实验应能证明你的假设错误

**示例：**
- “创建批量删除流程的Figma原型，并邀请5名核心用户测试”
- “为10名试用用户手动发送Slack通知，并跟踪响应时间”
- “在UI中添加‘请求此功能’按钮，衡量点击率”

---

Step 4: Define Validation Measures

步骤4：定义验证指标

Specify what success looks like and the timeframe for evaluation:

markdown

undefined

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

markdown

undefined

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]


**Quality checks:**
- **Timeframe is realistic:** Not "within 6 months" (too slow) or "within 3 days" (too fast)
- **Quantitative measures are specific:** Not "more users" but "20% increase in activation rate"
- **Qualitative measures are observable:** Not "users like it" but "8 out of 10 users say they'd pay for this feature"

**Examples:**
- ✅ "Within 4 weeks, we observe:"
  - "Activation rate increases from 40% to 50% (quantitative)"
  - "75% of surveyed trial users say the integration saved them time (qualitative)"
- ❌ "Within 1 year, we observe:"
  - "Revenue goes up" (too vague, too long)

---

若在 [天数或周数的时间范围] 内观察到以下情况，则说明假设成立：

[理想的可量化成果]
[理想的可定性成果]
[按需添加更多]


**质量检查：**
- **时间范围合理：** 不要写“6个月内”（太慢）或“3天内”（太快）
- **量化指标具体：** 不要写“更多用户”，而要写“激活率提升20%”
- **定性指标可观察：** 不要写“用户喜欢它”，而要写“10名受访用户中有8名表示愿意为该功能付费”

**示例：**
- ✅ “在4周内，我们观察到：”
  - “激活率从40%提升至50%（量化指标）”
  - “75%的受访试用用户表示该集成节省了他们的时间（定性指标）”
- ❌ “在1年内，我们观察到：”
  - “收入增长”（过于模糊，时间太长）

---

Step 5: Run Experiments and Evaluate

步骤5：开展实验并评估

Execute experiments: Build prototypes, run tests, gather data
Measure results: Did you hit the validation measures?
Decision point:
- ✅ Hypothesis validated: Proceed to building user stories and adding to roadmap
- ❌ Hypothesis invalidated: Kill the epic or pivot to a different hypothesis
- ⚠️ Inconclusive: Run additional experiments or tighten validation measures

执行实验： 制作原型、开展测试、收集数据
衡量结果： 是否达到了验证指标？
决策节点：
- ✅ 假设成立： 继续编写用户故事并纳入路线图
- ❌ 假设不成立： 终止该Epic或转向其他假设
- ⚠️ 结论不明确： 开展更多实验或优化验证指标

Step 6: Convert to User Stories (If Validated)

步骤6：转化为用户故事（若假设成立）

Once the hypothesis is validated, break the epic into user stories:

markdown

undefined

假设验证通过后，将Epic拆解为用户故事：

markdown

undefined

Epic: [Epic Name]

Epic: [Epic名称]

Stories:

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

---

用户故事：

[用户故事1 - 参考
```
skills/user-story/SKILL.md
```
]
[用户故事2]
[用户故事3]

---

Examples

示例

See

examples/sample.md

for full epic hypothesis examples.

Mini example excerpt:

markdown

**If we** provide one-click Google Calendar integration
**for** trial users managing multiple meetings
**Then we will** increase activation rate from 40% to 50%

查看

examples/sample.md

获取完整的Epic假设示例。

迷你示例节选：

markdown

**如果我们** 提供一键式Google Calendar集成
**面向** 管理多个会议的试用用户
**那么我们将** 把激活率从40%提升至50%

Common Pitfalls

常见陷阱

Pitfall 1: Hypothesis is a Feature, Not an Outcome

陷阱1：假设聚焦功能而非成果

Symptom: "If we build a dashboard, then we will have a dashboard"

Consequence: You're describing output, not outcome. This doesn't test anything.

Fix: Focus on the user outcome: "If we build a dashboard showing real-time task status, then PMs will spend 50% less time asking for status updates."

症状： “如果我们构建一个仪表盘，那么我们将拥有一个仪表盘”

后果： 你在描述输出，而非成果。这无法测试任何内容。

解决方法： 聚焦用户成果：“如果我们构建显示实时任务状态的仪表盘，那么项目经理将减少50%用于询问状态更新的时间。”

Pitfall 2: Skipping Experiments

陷阱2：跳过实验

Symptom: "We'll test our assumption by building the full feature"

Consequence: You've committed to building before validating. Not a hypothesis—it's a feature commitment.

Fix: Design lightweight experiments (prototypes, concierge tests, landing pages) that take days/weeks, not months.

症状： “我们将通过构建完整功能来验证假设”

后果： 你在验证前就承诺了开发。这不是假设——而是功能承诺。

解决方法： 设计轻量实验（原型、礼宾式测试、着陆页），耗时几天/几周而非数月。

Pitfall 3: Vague Validation Measures

陷阱3：验证指标模糊

Symptom: "We know it's valid if users are happy"

Consequence: Success criteria are subjective and unmeasurable.

Fix: Define specific, falsifiable metrics: "80% of surveyed users rate the feature 4+ out of 5" or "Response time drops by 50%."

症状： “如果用户满意，说明假设成立”

后果： 成功标准主观且无法衡量。

解决方法： 定义具体、可证伪的指标：“80%的受访用户为该功能评分4分及以上（满分5分）”或“响应时间减少50%”。

Pitfall 4: Unrealistic Timeframes

陷阱4：时间范围不切实际

Symptom: "We know it's valid if within 6 months revenue increases"

Consequence: Too slow to inform decisions. By then, you've already built it.

Fix: Aim for 2-4 week validation cycles. If you can't measure in that timeframe, choose a leading indicator (e.g., activation rate, not annual revenue).

症状： “如果在6个月内收入增长，说明假设成立”

后果： 决策反馈太慢。到那时你已经完成开发了。

解决方法： 目标是2-4周的验证周期。若无法在该时间范围内衡量，选择领先指标（例如激活率，而非年度收入）。

Pitfall 5: Treating Epics as Commitments

陷阱5：将Epics视为承诺

Symptom: "We already told the CEO we're shipping this, so we have to validate it"

Consequence: Experiments are theater—you're going to build it regardless of results.

Fix: Frame epics as hypotheses before making commitments. If stakeholders need certainty, explain the risk of building unvalidated features.

症状： “我们已经告诉CEO要交付这个功能，所以必须验证它成立”

后果： 实验只是形式——无论结果如何你都会开发它。

解决方法： 在做出承诺前，将Epics定位为假设。若利益相关者需要确定性，解释开发未验证功能的风险。

References

参考资料

Related Skills

External Frameworks

外部框架

Tim Herbig, Lean UX Hypothesis Statement — Origin of if/then hypothesis format
Jeff Gothelf & Josh Seiden, Lean UX (2013) — Hypothesis-driven product development
Alberto Savoia, Pretotype It (2011) — Lightweight experiments to validate ideas
Eric Ries, The Lean Startup (2011) — Build-Measure-Learn cycle

Tim Herbig，Lean UX Hypothesis Statement — IF/THEN假设格式的起源
Jeff Gothelf & Josh Seiden，Lean UX (2013) — 假设驱动的产品开发
Alberto Savoia，Pretotype It (2011) — 用于验证想法的轻量实验
Eric Ries，The Lean Startup (2011) — 构建-衡量-学习循环

Dean's Work

Backlog Epic Hypothesis Prompt (inspired by Tim Herbig's framework)

Backlog Epic Hypothesis Prompt（灵感来源于Tim Herbig的框架）

Provenance

来源

Adapted from

prompts/backlog-epic-hypothesis.md

in the

https://github.com/deanpeters/product-manager-prompts

repo.

Skill type: Component Suggested filename:

epic-hypothesis.md

Suggested placement:

/skills/components/

Dependencies: References

skills/problem-statement/SKILL.md

skills/proto-persona/SKILL.md

skills/jobs-to-be-done/SKILL.md

Used by:

skills/user-story/SKILL.md

skills/user-story-splitting/SKILL.md

改编自

https://github.com/deanpeters/product-manager-prompts

仓库中的

prompts/backlog-epic-hypothesis.md

。

Skill type: Component Suggested filename:

epic-hypothesis.md

Suggested placement:

/skills/components/

Dependencies: References

skills/problem-statement/SKILL.md

skills/proto-persona/SKILL.md

skills/jobs-to-be-done/SKILL.md

Used by:

skills/user-story/SKILL.md

skills/user-story-splitting/SKILL.md

epic-hypothesis

Original

Translation

Purpose

目的

Key Concepts

核心概念

The Epic Hypothesis Framework

Epic假设框架

Why This Structure Works

该结构为何有效

Anti-Patterns (What This Is NOT)

反模式（本框架不适用的情况）

When to Use This

适用场景

When NOT to Use This

不适用场景

Application

实践指南

Step 1: Gather Context

步骤1：收集背景信息

Step 2: Draft the If/Then Hypothesis

步骤2：起草IF/THEN假设

If/Then Hypothesis

IF/THEN假设

Step 3: Design Tiny Acts of Discovery Experiments

步骤3：设计微小探索行动实验

Tiny Acts of Discovery Experiments

微小探索行动实验

Step 4: Define Validation Measures

步骤4：定义验证指标

Validation Measures

验证指标

Step 5: Run Experiments and Evaluate

步骤5：开展实验并评估

Step 6: Convert to User Stories (If Validated)

步骤6：转化为用户故事（若假设成立）

Epic: [Epic Name]

Epic: [Epic名称]

Examples

示例

Common Pitfalls

常见陷阱

Pitfall 1: Hypothesis is a Feature, Not an Outcome

陷阱1：假设聚焦功能而非成果

Pitfall 2: Skipping Experiments

陷阱2：跳过实验

Pitfall 3: Vague Validation Measures

陷阱3：验证指标模糊

Pitfall 4: Unrealistic Timeframes

陷阱4：时间范围不切实际

Pitfall 5: Treating Epics as Commitments

陷阱5：将Epics视为承诺

References

参考资料

Related Skills

相关技能

External Frameworks

外部框架

Dean's Work

Dean's Work

Provenance

来源