把大型 initiative 或 epic…

当需要定义重大产品举措时，用 if/then 假设、轻量发现实验和可量化验证指标，先测试不确定性再决定是否投入完整构建。

适用场景

解决思路

1. 使用 template.md 作为完整填空结构，把 epic 写成可测试的假设，而不是需求规格；记住这是待验证的假设，不是已承诺要交付的功能。
2. 准备输入：最好已有 initiative 或 epic idea，一句话即可；也可补充目标用户、期望结果和可能衡量方式。
3. 如果调用技能时已提供文本、粘贴的上下文或附加的 ARGUMENTS: 行，把它们当作已回答内容，使用并跳过其覆盖的问题，不要重复询问。
4. 如果没有输入，直接询问 initiative 是什么、为谁做，然后与用户一起构建 if/then 假设。
5. 补齐上下文：确认问题理解（参考 skills/problem-statement/SKILL.md）、目标 persona（参考 skills/proto-persona/SKILL.md）、Jobs-to-be-Done（参考 skills/jobs-to-be-done/SKILL.md）、当前替代方案（竞品、变通办法、什么都不做）。
6. 如果缺少上述上下文，先运行 discovery 访谈或问题验证工作。
7. 起草 If/Then Hypothesis，按模板填写：**If we** [针对目标 persona 的行动或解决方案] **for** [目标 persona] **Then we will** [达成期望结果或 job-to-be-done]。
8. 质量检查 If we：必须具体；不要写「improve the product」，要写「add one-click Slack notifications when tasks are assigned」。
9. 质量检查 for：必须是清晰 persona；不要写「users」，要写「remote project managers juggling 3+ distributed teams」（参考 skills/proto-persona/SKILL.md）。
10. 质量检查 Then we will：必须是结果；不要写「users will have notifications」，要写「users will respond to task assignments 50% faster」。
11. 参考合格示例：If we add one-click Google Calendar integration for trial users, then we will increase activation rates by 20% within 30 days。
12. 参考合格示例：If we provide bulk delete functionality for power users managing 1000+ items, then we will reduce time spent on cleanup tasks by 70%。
13. 避免不合格示例：If we build a dashboard, then users will use it（模糊且不可衡量）。
14. 设计 Tiny Acts of Discovery Experiments，按模板填写：**We will test our assumption by:** [Experiment 1: low-cost, fast test] [Experiment 2: another low-cost, fast test] [按需增加]。
15. 从实验类型中选择：Prototype + user testing：用可点击原型伪造功能，找 5-10 个用户测试。
16. 从实验类型中选择：Concierge test：手动为少量用户执行该功能，观察他们是否重视。
17. 从实验类型中选择：Landing page test：描述该功能，衡量注册或兴趣。
18. 从实验类型中选择：Wizard of Oz test：把功能展示为自动化，但背后手动完成。
19. 从实验类型中选择：A/B test（如可行）：测试轻量版本 vs. 对照组。
20. 实验质量检查 Fast：实验应在数天/数周完成，而不是数月。
21. 实验质量检查 Cheap：避免完整工程构建，使用原型、手动流程或现有工具。
22. 实验质量检查 Falsifiable：设计能证明你错了的实验。
23. 参考实验示例：创建 bulk delete 流程的 Figma prototype，并与 5 个 power users 测试。
24. 参考实验示例：手动向 10 个 trial users 发送 Slack notifications，并跟踪响应时间。
25. 参考实验示例：在 UI 中添加「Request this feature」按钮，测量点击率。
26. 定义 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] [按需增加]。
27. 验证质量检查 Timeframe：要现实；不要「within 6 months」太慢，也不要「within 3 days」太快。
28. 验证质量检查 Quantitative：要具体；不要「more users」，要「20% increase in activation rate」。
29. 验证质量检查 Qualitative：要可观察；不要「users like it」，要「8 out of 10 users say they'd pay for this feature」。
30. 参考验证示例：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）。
31. 避免不合格验证示例：Within 1 year, we observe: Revenue goes up（太模糊、太久）。
32. 执行实验：构建原型、运行测试、收集数据。
33. 测量结果：对照 validation measures 判断是否命中。
34. 决策点：Hypothesis validated -> 继续写 user stories 并加入 roadmap。
35. 决策点：Hypothesis invalidated -> kill epic 或 pivot 到不同假设。
36. 决策点：Inconclusive -> 运行更多实验或收紧 validation measures。
37. 如果验证通过，把 epic 拆成 user stories，按模板：**Epic:** [Epic Name] **Stories:** 1. [User Story 1 - reference skills/user-story/SKILL.md] 2. [User Story 2] 3. [User Story 3]。
38. 参考 skills/user-story/SKILL.md 和 skills/user-story-splitting/SKILL.md 完成验证后 epic 到故事的分解。
39. 避免 Pitfall 1：不要把假设写成功能；症状是「If we build a dashboard, then we will have a dashboard」；修复是聚焦用户结果，例如「If we build a dashboard showing real-time task status, then PMs will spend 50% less time asking for status updates」。
40. 避免 Pitfall 2：不要跳过实验；症状是「We'll test our assumption by building the full feature」；修复是设计数天/数周的原型、Concierge tests、Landing pages。
41. 避免 Pitfall 3：不要模糊验证指标；症状是「We know it's valid if users are happy」；修复是定义具体可证伪指标，如「80% of surveyed users rate the feature 4+ out of 5」或「Response time drops by 50%」。
42. 避免 Pitfall 4：不要不现实时间框；症状是「We know it's valid if within 6 months revenue increases」；修复是目标 2-4 week validation cycles，若无法在该时间衡量，选择 leading indicator，如 activation rate 而非 annual revenue。
43. 避免 Pitfall 5：不要把 epics 当承诺；症状是「We already told the CEO we're shipping this, so we have to validate it」；修复是在做出承诺前把 epic 框为假设；如果 stakeholders 需要确定性，解释构建未验证功能的风险。

适用边界 · 注意事项

• 已经验证过需求、已证明用户需求的功能：跳过假设框定，直接拆成 user stories。
• 琐碎的小功能或小改动：不要用轻量实验过度设计。
• 实验不可行、必须在测试前承诺时（少见）：不适合用本方法；但仍需说明未验证风险。