AI 技能AI 插件【免费下载链接】Product-Manager-SkillsProduct Management skills framework built on battle-tested methods for Claude Code, Cowork, Codex, and AI agents.项目地址https://gitcode.com/gh_mirrors/pr/Product-Manager-Skills点击查看免费下载本篇技术指南围绕 Product-Manager-Skills 开源仓库中的 epic-hypothesis 模板 展开讲解如何把一个模糊的大需求epic改写为具备行动对象、目标人群、预期结果与验证方式的 If/Then 假设并配套轻量发现实验Tiny Acts of Discovery与验证指标Validation Measures两段式结构。读完本文你将掌握模板的逐字段填写方法、质量检查清单、五种典型反模式以及如何把验证后的 epic 拆解为用户故事直接可复制到实际产品工作中。模板速览三段落式可证伪假设skills/epic-hypothesis/template.md是技能epic-hypothesisSKILL.md要求使用的填充式结构。它把一次史诗级投入压缩成三块、总共可在一张卡片里写完的内容### If/Then Hypothesis **If we** [action or solution on behalf of the target persona] **for** [target persona] **Then we will** [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]模板的源头信息在文件尾部 Provenance 一节有明确标注改编自prompts/backlog-epic-hypothesis.md来自 deanpeters 的 product-manager-prompts 仓库If/Then 句式灵感来自 Tim Herbig 的 Lean UX hypothesis format。需要特别强调的是这个模板不是需求规格书而是一条你正在验证、而非承诺交付的假设——这是使用它的第一原则。核心框架拆解三段各解决什么问题根据 SKILL.md 的 Key Concepts 部分框架的每一段都对应一个关键的产品管理动作If/Then Hypothesis假设声明用一句话说清楚我们为谁做什么、期望得到什么结果。模板字段即If we [行动/方案]for [目标人群]Then we will [理想结果或待办任务]。Tiny Acts of Discovery Experiments轻量发现实验在正式开工前用低成本、快周期的手段去验证假设而不是直接进入完整构建。Validation Measures验证指标定义在多长时间内观察到什么量化/质性结果就算假设成立使整条假设可证伪falsifiable。这套结构之所以有效SKILL.md 归纳了五条理由假设驱动迫使你说出自己相信什么、可能错在哪、结果导向Then we will 强调用户收益而非功能产出、实验优先在完整构建前先做轻量验证、可证伪明确的成功标准让你能尽早杀掉坏主意、风险管理把 epic 当作下注而非承诺。六个步骤从上下文收集到用户故事拆解SKILL.md 给出了完整应用流程模板是其中第 2 至 4 步的直接载体。第 1 步收集上下文动笔前确认你拥有四类输入问题理解可参考 problem-statement/SKILL.md、目标人群参考 proto-persona/SKILL.md、待办任务参考 jobs-to-be-done/SKILL.md、以及用户当前替代方案竞品、变通做法、什么都不做。缺上下文时先跑发现访谈或问题验证工作再回来。这一点与仓库中的 discovery-process 技能直接衔接——该技能把epic-hypothesis列为发现通过GO后的组件并给出每条 epic 约 60 分钟的耗时预算discovery-process/SKILL.md。第 2 步起草 If/Then 假设直接按模板填充并对照三条质量检查If we 必须具体不是improve the product而是add one-click Slack notifications when tasks are assigned。For 必须是清晰的人群不是users而是remote project managers juggling 3 distributed teams人群定义可交给 proto-persona。Then we will 必须是结果不是users will have notifications而是users will respond to task assignments 50% faster。SKILL.md 给出的正反例对照✅ 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模糊、不可测量第 3 步设计轻量发现实验模板第二段要求列出多条低成本、快周期的实验。SKILL.md 推荐五种实验类型原型 用户测试用可点击原型伪装功能找 5–10 名用户测试礼宾测试Concierge test人工为少数用户手动执行该功能观察他们是否觉得有价值着陆页测试只描述功能测量注册或兴趣信号幕后操纵测试Wizard of Oz对外表现自动化后台仍由人工完成A/B 测试条件允许时轻量版本与对照组对比。三条质量检查快几天到几周而非数月、便宜用原型/人工流程/现有工具避免完整工程构建、可证伪实验要能证明你错。例如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。第 4 步定义验证指标模板第三段要求给出时间窗与可观察结果。质量检查包括时间窗要现实within 6 months 太慢、within 3 days 太快、量化指标要具体不是more users而是20% increase in activation rate、质性指标要可观察不是users like it而是8 out of 10 users say theyd pay for this feature。推荐 2–4 周的验证周期若周期内无法直接测量改用领先指标如激活率而非年度收入。第 5 步运行实验并评估执行实验、比对验证指标然后进入决策点假设成立✅则继续拆用户故事并入路线图假设不成立❌则杀掉 epic 或转向另一条假设结果不明确⚠️则补充实验或收紧指标。第 6 步验证通过后转为用户故事### Epic: [Epic Name] **Stories:** 1. [User Story 1 - reference skills/user-story/SKILL.md] 2. [User Story 2] 3. [User Story 3]这与 user-story 技能形成闭环epic 拆解为用户故事而 user-story-splitting 负责把大故事继续切小。实战示例好假设、坏假设与被杀死的好下注examples/sample.md 提供了三组完整示例可直接对照模板理解。示例 1好的 epic 假设Google Calendar 集成### Epic Hypothesis: Google Calendar Integration for Trial Users #### If/Then Hypothesis **If we** provide one-click Google Calendar integration during onboarding **for** trial users who manage multiple meetings and tasks daily **Then we will** increase activation rate (defined as completing setup creating first task) from 40% to 50% #### Tiny Acts of Discovery Experiments **We will test our assumption by:** 1. Creating a clickable Figma prototype of the integration flow and testing with 10 trial users 2. Adding a Connect Google Calendar CTA to the onboarding flow (but its non-functional) and measuring click-through rate 3. Manually syncing Google Calendar for 5 trial users and surveying them after 1 week on perceived value #### Validation Measures **We know our hypothesis is valid if within 4 weeks we observe:** - Click-through rate on the CTA is 60% (quantitative) - 8 out of 10 prototype testers say theyd use this feature regularly (qualitative) - Manually synced users report saving 10 minutes per day on task entry (qualitative)示例 2坏的 epic 假设模糊——Improve the dashboard / for users / make the product better实验写Building the dashboard验证写Users like it。失败原因逐条被点名行动不具体、人群不是 persona、结果不可测量、实验不是轻量测试、验证不可证伪。示例 3被证伪的假设过程正确——Slack 通知集成假设把任务响应时间从 4 小时降到 1 小时2 周实验后实际只降到 3.5 小时用户反馈我已有太多 Slack 通知大多数都被忽略结论是假设不成立转向应用内通知或邮件摘要。这个例子的价值在于假设被真正测试而非直接构建、实验够轻量人工发 Slack 消息、团队在浪费工程资源前杀掉了 epic。工业场景扩展硬件产品如何用同一模板examples/sample-industrial.md 展示了模板在工业硬件Northfield Automation 的 NFA-500 控制器上的应用其核心洞察是无法对控制面板做 A/B 测试、反馈回路以季度计时假设纪律反而更有价值——因为真实实验昂贵且缓慢发现实验就必须便宜且物理化。该示例中板载故障隔离假设把基准明确标注为未测量的 52 分钟并用四项轻量实验笔记本审计、纸质面板测试、手套与光照检查、停机归因拉取逐步验证更值得注意的是被杀死的好下注案例——预测性故障告警通过 3 周、近乎零工程成本的历史数据实验发现 50 例故障中仅 9 例有前兆模式随即杀掉 epic避免了两个季度构建一个 80% 概率错误的特性。五种常见陷阱与修复方法SKILL.md 的 Common Pitfalls 部分是自查清单假设写成功能而非结果症状是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.跳过实验症状是Well test our assumption by building the full feature修复为设计几天到几周的原型、礼宾测试、着陆页等轻量实验。验证指标模糊症状是We know its valid if users are happy修复为具体可证伪的指标如80% of surveyed users rate the feature 4 out of 5或Response time drops by 50%.时间窗不现实症状是within 6 months revenue increases修复为 2–4 周验证周期不可直接测量时改用领先指标。把 epic 当承诺症状是我们已告诉 CEO 要交付所以必须验证它修复为在做出承诺之前把 epic 框定为假设并向需要确定性的干系人解释未验证构建的风险。在技能库中的位置与使用方式从仓库的 skills-index.yaml 可以看到epic-hypothesis是 77 个技能之一类型为 component、主题归入 pm-artifacts推荐使用场景包括领导已批准大项目但没人能说出什么能证明它错了和需要把 epic 框定为带真实验证方法的下注而非交付计划预估耗时 15–20 分钟元数据中给出调用提示[initiative or epic idea]典型调用示例为Frame as an epic hypothesis: adding usage-based alerts so account admins catch overages before invoice shock.它在技能链中的位置明确上游依赖 problem-statement假设应对已验证的问题、proto-persona定义for [persona]段、jobs-to-be-done支撑then we will结果下游被 user-story 与 user-story-splitting 使用验证后的 epic 拆成故事。同时它还被 lean-ux-canvasBox 6 写可测试假设、opportunity-solution-tree把已验证方案变成可测试 epic、pol-probe测试前框定假设等技能引用并出现在 plan-roadmap 命令把 initiative 转为 epic-hypothesis 语句与 CHANGELOG把模糊 initiative 变成带成功指标的可测试假设中。使用限制与适用边界模板并非万能。SKILL.md 明确列出不适用的场景功能已被充分验证需求已被证明直接写用户故事、琐碎小功能避免过度设计、实验不可行少数情况必须在测试前投入。同时注意模板中的时间窗、基准值与指标都需结合你所在行业校准——工业示例中52 分钟基准被明确定义为尚未测量、需要实验确认这正是模板要求诚实排序的体现而软件领域推荐的 2–4 周验证周期在硬件场景下通常不成立应像工业示例那样按季度思维设计轻量发现实验。模板只定义结构与质量标准不替你做实验设计或指标决策。赞分享AI 技能AI 插件【免费下载链接】Product-Manager-SkillsProduct Management skills framework built on battle-tested methods for Claude Code, Cowork, Codex, and AI agents.项目地址https://gitcode.com/gh_mirrors/pr/Product-Manager-Skills点击查看免费下载相关推荐Product-Manager-Skills 史诗假设Epic Hypothesis实战指南用可证伪的 If/Then 框架给每个重大举措设定赌注与验证方法Product Manager Skills 史诗假设Epic Hypothesis实战指南用可证伪的 If/Then 框架给每个重大举措设定赌注与验证方AI 技能AI 插件Product Manager Skills 中 Epic Hypothesis 实战示例解析用可证伪假设框架管理产品赌注Product Manager Skills 中 Epic Hypothesis 实战示例解析用可证伪假设框架管理产品赌注 导读 本文以 Product MaAI 技能AI 插件Product-Manager-Skills 工业场景下的 Epic Hypothesis 实战指南以 NFA-500 故障诊断史诗为例Product Manager Skills 工业场景下的 Epic Hypothesis 实战指南以 NFA 500 故障诊断史诗为例 本文基于开源仓库 PAI 技能AI 插件上一篇FanControl V269终极指南Windows风扇智能温控与静音优化完整教程下一篇G-Helper终极指南轻量级华硕笔记本控制中心完全教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
AI 技能AI 插件【免费下载链接】Product-Manager-SkillsProduct Management skills framework built on battle-tested methods for Claude Code, Cowork, Codex, and AI agents.项目地址https://gitcode.com/gh_mirrors/pr/Product-Manager-Skills点击查看免费下载本篇技术指南围绕 Product-Manager-Skills 开源仓库中的 epic-hypothesis 模板 展开讲解如何把一个模糊的大需求epic改写为具备行动对象、目标人群、预期结果与验证方式的 If/Then 假设并配套轻量发现实验Tiny Acts of Discovery与验证指标Validation Measures两段式结构。读完本文你将掌握模板的逐字段填写方法、质量检查清单、五种典型反模式以及如何把验证后的 epic 拆解为用户故事直接可复制到实际产品工作中。模板速览三段落式可证伪假设skills/epic-hypothesis/template.md是技能epic-hypothesisSKILL.md要求使用的填充式结构。它把一次史诗级投入压缩成三块、总共可在一张卡片里写完的内容### If/Then Hypothesis **If we** [action or solution on behalf of the target persona] **for** [target persona] **Then we will** [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]模板的源头信息在文件尾部 Provenance 一节有明确标注改编自prompts/backlog-epic-hypothesis.md来自 deanpeters 的 product-manager-prompts 仓库If/Then 句式灵感来自 Tim Herbig 的 Lean UX hypothesis format。需要特别强调的是这个模板不是需求规格书而是一条你正在验证、而非承诺交付的假设——这是使用它的第一原则。核心框架拆解三段各解决什么问题根据 SKILL.md 的 Key Concepts 部分框架的每一段都对应一个关键的产品管理动作If/Then Hypothesis假设声明用一句话说清楚我们为谁做什么、期望得到什么结果。模板字段即If we [行动/方案]for [目标人群]Then we will [理想结果或待办任务]。Tiny Acts of Discovery Experiments轻量发现实验在正式开工前用低成本、快周期的手段去验证假设而不是直接进入完整构建。Validation Measures验证指标定义在多长时间内观察到什么量化/质性结果就算假设成立使整条假设可证伪falsifiable。这套结构之所以有效SKILL.md 归纳了五条理由假设驱动迫使你说出自己相信什么、可能错在哪、结果导向Then we will 强调用户收益而非功能产出、实验优先在完整构建前先做轻量验证、可证伪明确的成功标准让你能尽早杀掉坏主意、风险管理把 epic 当作下注而非承诺。六个步骤从上下文收集到用户故事拆解SKILL.md 给出了完整应用流程模板是其中第 2 至 4 步的直接载体。第 1 步收集上下文动笔前确认你拥有四类输入问题理解可参考 problem-statement/SKILL.md、目标人群参考 proto-persona/SKILL.md、待办任务参考 jobs-to-be-done/SKILL.md、以及用户当前替代方案竞品、变通做法、什么都不做。缺上下文时先跑发现访谈或问题验证工作再回来。这一点与仓库中的 discovery-process 技能直接衔接——该技能把epic-hypothesis列为发现通过GO后的组件并给出每条 epic 约 60 分钟的耗时预算discovery-process/SKILL.md。第 2 步起草 If/Then 假设直接按模板填充并对照三条质量检查If we 必须具体不是improve the product而是add one-click Slack notifications when tasks are assigned。For 必须是清晰的人群不是users而是remote project managers juggling 3 distributed teams人群定义可交给 proto-persona。Then we will 必须是结果不是users will have notifications而是users will respond to task assignments 50% faster。SKILL.md 给出的正反例对照✅ 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模糊、不可测量第 3 步设计轻量发现实验模板第二段要求列出多条低成本、快周期的实验。SKILL.md 推荐五种实验类型原型 用户测试用可点击原型伪装功能找 5–10 名用户测试礼宾测试Concierge test人工为少数用户手动执行该功能观察他们是否觉得有价值着陆页测试只描述功能测量注册或兴趣信号幕后操纵测试Wizard of Oz对外表现自动化后台仍由人工完成A/B 测试条件允许时轻量版本与对照组对比。三条质量检查快几天到几周而非数月、便宜用原型/人工流程/现有工具避免完整工程构建、可证伪实验要能证明你错。例如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。第 4 步定义验证指标模板第三段要求给出时间窗与可观察结果。质量检查包括时间窗要现实within 6 months 太慢、within 3 days 太快、量化指标要具体不是more users而是20% increase in activation rate、质性指标要可观察不是users like it而是8 out of 10 users say theyd pay for this feature。推荐 2–4 周的验证周期若周期内无法直接测量改用领先指标如激活率而非年度收入。第 5 步运行实验并评估执行实验、比对验证指标然后进入决策点假设成立✅则继续拆用户故事并入路线图假设不成立❌则杀掉 epic 或转向另一条假设结果不明确⚠️则补充实验或收紧指标。第 6 步验证通过后转为用户故事### Epic: [Epic Name] **Stories:** 1. [User Story 1 - reference skills/user-story/SKILL.md] 2. [User Story 2] 3. [User Story 3]这与 user-story 技能形成闭环epic 拆解为用户故事而 user-story-splitting 负责把大故事继续切小。实战示例好假设、坏假设与被杀死的好下注examples/sample.md 提供了三组完整示例可直接对照模板理解。示例 1好的 epic 假设Google Calendar 集成### Epic Hypothesis: Google Calendar Integration for Trial Users #### If/Then Hypothesis **If we** provide one-click Google Calendar integration during onboarding **for** trial users who manage multiple meetings and tasks daily **Then we will** increase activation rate (defined as completing setup creating first task) from 40% to 50% #### Tiny Acts of Discovery Experiments **We will test our assumption by:** 1. Creating a clickable Figma prototype of the integration flow and testing with 10 trial users 2. Adding a Connect Google Calendar CTA to the onboarding flow (but its non-functional) and measuring click-through rate 3. Manually syncing Google Calendar for 5 trial users and surveying them after 1 week on perceived value #### Validation Measures **We know our hypothesis is valid if within 4 weeks we observe:** - Click-through rate on the CTA is 60% (quantitative) - 8 out of 10 prototype testers say theyd use this feature regularly (qualitative) - Manually synced users report saving 10 minutes per day on task entry (qualitative)示例 2坏的 epic 假设模糊——Improve the dashboard / for users / make the product better实验写Building the dashboard验证写Users like it。失败原因逐条被点名行动不具体、人群不是 persona、结果不可测量、实验不是轻量测试、验证不可证伪。示例 3被证伪的假设过程正确——Slack 通知集成假设把任务响应时间从 4 小时降到 1 小时2 周实验后实际只降到 3.5 小时用户反馈我已有太多 Slack 通知大多数都被忽略结论是假设不成立转向应用内通知或邮件摘要。这个例子的价值在于假设被真正测试而非直接构建、实验够轻量人工发 Slack 消息、团队在浪费工程资源前杀掉了 epic。工业场景扩展硬件产品如何用同一模板examples/sample-industrial.md 展示了模板在工业硬件Northfield Automation 的 NFA-500 控制器上的应用其核心洞察是无法对控制面板做 A/B 测试、反馈回路以季度计时假设纪律反而更有价值——因为真实实验昂贵且缓慢发现实验就必须便宜且物理化。该示例中板载故障隔离假设把基准明确标注为未测量的 52 分钟并用四项轻量实验笔记本审计、纸质面板测试、手套与光照检查、停机归因拉取逐步验证更值得注意的是被杀死的好下注案例——预测性故障告警通过 3 周、近乎零工程成本的历史数据实验发现 50 例故障中仅 9 例有前兆模式随即杀掉 epic避免了两个季度构建一个 80% 概率错误的特性。五种常见陷阱与修复方法SKILL.md 的 Common Pitfalls 部分是自查清单假设写成功能而非结果症状是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.跳过实验症状是Well test our assumption by building the full feature修复为设计几天到几周的原型、礼宾测试、着陆页等轻量实验。验证指标模糊症状是We know its valid if users are happy修复为具体可证伪的指标如80% of surveyed users rate the feature 4 out of 5或Response time drops by 50%.时间窗不现实症状是within 6 months revenue increases修复为 2–4 周验证周期不可直接测量时改用领先指标。把 epic 当承诺症状是我们已告诉 CEO 要交付所以必须验证它修复为在做出承诺之前把 epic 框定为假设并向需要确定性的干系人解释未验证构建的风险。在技能库中的位置与使用方式从仓库的 skills-index.yaml 可以看到epic-hypothesis是 77 个技能之一类型为 component、主题归入 pm-artifacts推荐使用场景包括领导已批准大项目但没人能说出什么能证明它错了和需要把 epic 框定为带真实验证方法的下注而非交付计划预估耗时 15–20 分钟元数据中给出调用提示[initiative or epic idea]典型调用示例为Frame as an epic hypothesis: adding usage-based alerts so account admins catch overages before invoice shock.它在技能链中的位置明确上游依赖 problem-statement假设应对已验证的问题、proto-persona定义for [persona]段、jobs-to-be-done支撑then we will结果下游被 user-story 与 user-story-splitting 使用验证后的 epic 拆成故事。同时它还被 lean-ux-canvasBox 6 写可测试假设、opportunity-solution-tree把已验证方案变成可测试 epic、pol-probe测试前框定假设等技能引用并出现在 plan-roadmap 命令把 initiative 转为 epic-hypothesis 语句与 CHANGELOG把模糊 initiative 变成带成功指标的可测试假设中。使用限制与适用边界模板并非万能。SKILL.md 明确列出不适用的场景功能已被充分验证需求已被证明直接写用户故事、琐碎小功能避免过度设计、实验不可行少数情况必须在测试前投入。同时注意模板中的时间窗、基准值与指标都需结合你所在行业校准——工业示例中52 分钟基准被明确定义为尚未测量、需要实验确认这正是模板要求诚实排序的体现而软件领域推荐的 2–4 周验证周期在硬件场景下通常不成立应像工业示例那样按季度思维设计轻量发现实验。模板只定义结构与质量标准不替你做实验设计或指标决策。赞分享AI 技能AI 插件【免费下载链接】Product-Manager-SkillsProduct Management skills framework built on battle-tested methods for Claude Code, Cowork, Codex, and AI agents.项目地址https://gitcode.com/gh_mirrors/pr/Product-Manager-Skills点击查看免费下载相关推荐Product-Manager-Skills 史诗假设Epic Hypothesis实战指南用可证伪的 If/Then 框架给每个重大举措设定赌注与验证方法Product Manager Skills 史诗假设Epic Hypothesis实战指南用可证伪的 If/Then 框架给每个重大举措设定赌注与验证方AI 技能AI 插件Product Manager Skills 中 Epic Hypothesis 实战示例解析用可证伪假设框架管理产品赌注Product Manager Skills 中 Epic Hypothesis 实战示例解析用可证伪假设框架管理产品赌注 导读 本文以 Product MaAI 技能AI 插件Product-Manager-Skills 工业场景下的 Epic Hypothesis 实战指南以 NFA-500 故障诊断史诗为例Product Manager Skills 工业场景下的 Epic Hypothesis 实战指南以 NFA 500 故障诊断史诗为例 本文基于开源仓库 PAI 技能AI 插件上一篇FanControl V269终极指南Windows风扇智能温控与静音优化完整教程下一篇G-Helper终极指南轻量级华硕笔记本控制中心完全教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
