mcpField
P
product-methodology

product-methodology

github.com/magnus919生产力15366 次安装今天更新
代码仓库

关于 product-methodology

product-methodology 是面向产品团队的主机无关技能,适用于已有经验证据的工作阶段。它引导团队进行优先级排序、记录决策、编写规格,并按受众调整沟通方式,提供 RICE 和 MoSCoW 等参考方法。

主要功能

  1. 01使用 RICE 和 MoSCoW 排优先级
  2. 02将机会关联到解决方案
  3. 03记录决策及其理由
  4. 04编写结构化产品规格
  5. 05按受众调整沟通内容

适用场景

  1. 01为功能提案或计划排定优先级
  2. 02确定限时版本的交付范围
  3. 03记录决策及其权衡
  4. 04准备功能规格或利益相关方沟通材料

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/magnus919/agent-skills --skill product-methodology

安装后在 Claude Code 中输入/product-methodology确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

README.md
evals/
evals.json
references/
decision-log.md
moscow-prioritization.md
opportunity-solution-trees.md
rice-framework.md
source-index.md
spec-template.md
stakeholder-communication.md
templates/
DECISION_LOG.md
SPEC.md

详细介绍

产品方法论

当探索阶段结束后,即可开始使用此技能。若你已通过利益相关方访谈、竞争研究或使用数据获得经过验证的证据,此技能将指导你完成优先级排序、决策、规格制定和沟通。

流程

VALIDATED EVIDENCE → [PRIORITIZE] → [DECIDE] → [SPECIFY] → [COMMUNICATE]
                         |              |           |              |
                    RICE + MoSCoW   Decision log   Spec        Stakeholder
                                     template    template       briefs

参考指南

仅加载与当前任务相关的参考资料:

参考资料加载时机
RICE 评分需要通过覆盖面 × 影响力 × 置信度 / 投入,对彼此无关的功能提案进行比较时
MoSCoW 优先级排序时间限定的版本发布范围紧张,需要明确划分 Must/Should/Could/Won't 时
机会解决方案树问题空间错综复杂,需要将客户需求与构建决策关联起来,同时避免直接跳到解决方案时
决策日志已做出一项存在权衡、以后可能会受到质疑的决策,需要记录背景和预期结果时
规格模板需要一份工程师、设计师和利益相关方都能使用的需求文档时
利益相关方沟通正在为高管、工程师、设计师或客户准备消息时——每类受众需要不同的格式
来源索引审查来源、移植范围和权威来源链接时

模板

模板加载时机
决策日志模板需要一个带有 frontmatter、可填写的决策日志条目时
规格模板需要一份包含此方法论所列章节、可填写的规格文档时

触发条件

在以下情况下加载此技能:

  • 为待办列表中的功能提案或计划排定优先级
  • 做出需要记录理由的产品决策
  • 为功能或集成编写规格说明
  • 向不同受众(高管、工程师、设计师、客户)传达产品决策
  • 将客户机会映射到潜在解决方案
  • 为时间限定的版本发布划定明确范围
  • 利益相关方询问“我们为什么这么决定?”,但没有记录可查

不适用情况

  • 利益相关方探索和访谈——请先加载 product-discovery。此技能从经过验证的证据出发,而不是从原始的利益相关方访谈出发。
  • 将无边界的想法塑造成一项押注(投入意愿、提案、断路器)——在应用优先级排序框架之前,请加载 product-shaping;此技能处理的是已经通过的押注,不负责创造押注。
  • 交互设计、任务流程、状态/恢复模型或可用性研究规划——此技能选定范围后,请使用 product-design-and-ux。此技能决定构建什么以及为什么;design-and-ux 则定义面向用户的行为。

工作方法

  1. 确认你已有经过验证的证据(访谈笔记、使用数据、竞争分析)。如果没有,请转至 product-discovery。如果经过验证的问题尚无投入意愿或明确范围的解决方案,请先通过 product-shaping 塑造它——押注尚未确定时,不要预先把提案拆解成任务。
  2. 比较彼此无关的提案时,使用 RICE 排定优先级;规划时间限定的交付范围时,使用 MoSCoW。
  3. 将决策记录为结构化条目,涵盖背景、选项、理由和预期结果。
  4. 编写规格说明,明确问题、成功指标、范围边界、待解问题和边缘情况。
  5. 按照不同受众所需的形式传达决策——面向高管时先给出建议,面向工程师时先交代背景,面向客户时先倾听。

路由边界

对于 CPO 层面的愿景、定位、市场战略和产品组合方向,请使用 product-strategy。战略方向和经过验证的证据明确后,再将战术优先级排序、规格说明、决策记录和待办事项排序交由此处处理;不要在此技能中做出产品组合战略决策。

可移植性

此技能有意保持与宿主环境无关。它不需要配置文件系统、输出格式、脚本或外部服务。直接按路径加载参考资料——使用宿主 Agent 的常规文件加载机制。

来源

框架来源资料
RICEIntercom(Sean McBride,2016)intercom.com/blog/rice-simple-prioritization-for-product-managers
MoSCoWDai Clegg,Oracle UK(1994);后由 DSDM 采用Agile Business Consortium:MoSCoW 优先级排序
机会解决方案树Teresa Torres(Product Talk)producttalk.org/opportunity-solution-tree
决策记录综合 ADR 实践和产品管理惯例—
规格说明模板综合常见 PRD 实践—
利益相关者沟通综合产品管理沟通实践—

此技能从 magnus919/hermes-profiles 移植而来,移植时的提交为 867a555。有关可移植性边界,请参阅 references/source-index.md。

评论

支持 Markdown