Epic Hypothesis - 把 Epic 变成可验证产品假设的技能

技能概述

Epic Hypothesis 是一个产品管理技能，用 If/Then 假设结构把史诗级需求（Epic）转化为可证伪的产品赌注：写清为谁做什么、期望达成什么结果、用什么实验验证成败，在投入开发前先管理不确定性。

适用场景

1. 领导层批准了一个大型项目，但没人说得清什么结果能证明它错了——用假设框架补上可证伪的成功标准，让团队有一个共同下注的"赌注"而非模糊的交付范围
2. 需要在正式排入路线图之前，把 Epic 框定为带真实验证方法的"产品赌注"，而不是一份直接开工的交付计划
3. 需求优先级排序时，用假设验证结果决定哪些 Epic 值得投入、哪些应该砍掉或转向

核心功能

1. If/Then 假设框架：按"如果我们为[目标人群]做[具体方案]，那么我们将[达成可衡量的结果]"的结构化模板起草假设，内置质量检查（"如果我们"要具体、"为"要指向清晰画像、"那么"必须是结果而非功能），避免写成空泛的功能描述
2. 轻量发现实验设计（Tiny Acts of Discovery）：提供原型测试、绿手套（Concierge）测试、落地页测试、魔法师学徒（Wizard of Oz）测试、A/B 测试等低成本验证手段，用几天到几周的时间代替整仓开发去检验假设
3. 验证指标与决策点：在现实的时间窗口内（通常 2-4 周）设定量化和质化成功标准，并明确三种走向——验证通过则拆解为用户故事进入路线图、不通过则砍掉 Epic 或转向、结果不明确则收紧指标追加实验

常见问题

Epic 假设和需求文档有什么区别？

需求文档描述"要做什么功能"，Epic 假设描述"我们相信什么、以及什么结果能证明我们错了"。假设是待检验的赌注，允许被推翻；需求文档默认功能一定会做。这个技能产出的不是规格说明，而是一份先验证、再投入的实验计划。

什么是 Tiny Acts of Discovery（轻量发现实验）？

指在正式开发前用来检验假设的低成本实验，例如用 Figma 原型找 5 个用户测试、人工替 10 个用户手动执行功能（绿手套测试）、上架落地页统计注册意愿等。特点是快（几天到几周）、便宜（不需要真实工程量）、可证伪——设计目标就是有可能证明你是错的。

假设验证不通过怎么办？

这正是这个技能的价值所在：假设被推翻时，砍掉或转向这个 Epic，避免把资源浪费在未经验证的功能上；结果不明确时，收紧验证指标或追加实验。前提是在向利益相关方承诺交付之前就完成假设框架——如果已经答应"一定上线"，实验就容易流于形式。

什么情况下不适合用？

该技能面向尚不确定、需要验证的重大举措。已经验证过需求的功能可以直接拆用户故事；小调整不值得过度设计；极少数必须先承诺后验证的场景也不适用。完整梳理一个 Epic 约需 15-20 分钟。