mcpField
P
pm-roadmap

pm-roadmap

github.com/konglong87生産性8480 回インストール1 週間前に更新
リポジトリ

pm-roadmap について

pm-roadmapは、製品ロードマップを計画するプロダクトチーム向けのスキルです。製品ビジョンと期間を基に、段階ごとの目標、マイルストーン、指標、必要リソースを定め、依存関係とリスクを整理してロードマップ文書を作成します。

主な機能

  1. 01製品ビジョンと計画期間の設定
  2. 02ロードマップ各段階の目標設定
  3. 03マイルストーン・成果物・完了基準の計画
  4. 04目標指標と必要リソースの定義
  5. 05依存関係とリスクの特定
  6. 06製品ロードマップ文書の作成

活用シーン

  1. 01四半期から複数年の製品計画を策定
  2. 02製品目標を段階的なマイルストーンに分解
  3. 03ロードマップのリソースとリスクを評価

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/konglong87/superpm --skill pm-roadmap

インストール後、Claude Code で/pm-roadmapを入力して読み込まれたか確認します。

詳細

プロジェクトの README より

Preamble

echo "🗺️  产品路线图工具已启动"

# 检查前置文档
echo "📊 正在检查前置数据..."
if [ -f "docs/02-方案设计/PRD产品需求文档.md" ]; then
  echo "✅ PRD文档 - 已找到"
else
  echo "⏳ PRD文档 - 未找到"
fi

写入时边界

只讨论时不写文件,启动检查不创建目录。用户要求保存产物时,先确认当前产品、精确输出路径及已有文件的覆盖/追加选择;确认后仅在实际 Write 前创建该输出文件的父目录。完整安装可参见 skills/_shared/artifact-policy.md,单独安装本 skill 也按本段执行。


跨 Agent 交互规则

当流程要求与用户交互时:

  1. 如果当前环境支持 AskUserQuestion,使用 AskUserQuestion(最佳体验)。
  2. 如果当前环境不支持 AskUserQuestion,必须用普通聊天消息提出同样问题。
  3. 一次只问一个问题。
  4. 提问后必须停止当前回合,等待用户回答(STOP and WAIT)。
  5. 不得在用户回答前生成文档、写入 docs。
  6. 已有 docs 文件不能替代本轮用户回答。

执行流程

步骤 1: 明确产品愿景与战略目标

使用 AskUserQuestion 询问:

🎯 产品愿景与战略目标

产品愿景:产品最终要成为什么? 示例:成为XX领域最受信赖的平台

时间范围:您想规划多长时间的路线图?

A) 3个月(近期规划) B) 6个月(中期规划) C) 12个月(年度规划) D) 2-3年(长期规划) E) 其他(请手动输入)

💡 提示:首次规划建议从6个月开始

记录到变量 VISION 和 TIMEFRAME


步骤 2: 设定核心目标

🎯 各阶段核心目标:

将{TIMEFRAME}划分为2-4个阶段,每个阶段设定一个核心目标。

示例(电商产品6个月路线图):

阶段时间核心目标关键指标
阶段1第1-2月MVP上线验证DAU达到1万
阶段2第3-4月用户增长MAU达到10万
阶段3第5-6月商业变现GMV达到100万

您希望如何划分阶段?

A) 根据功能主题划分(基础设施→核心功能→增长→变现) B) 根据用户规模划分(冷启动→增长→规模化) C) 根据商业目标划分(验证→获客→变现) D) 自定义划分(请手动输入)


步骤 3: 规划各阶段里程碑

对每个阶段,详细规划里程碑:

📅 阶段1详细规划

阶段名称:{阶段名称} 时间范围:{起止时间} 核心目标:{目标描述}

关键里程碑:

里程碑时间交付物验收标准
M1第X周核心功能A上线完成XX功能,达标XX指标
M2第X周核心功能B上线完成XX功能,达标XX指标
M3第X周公测版本发布完成全流程验证

关键指标目标:

  • DAU目标:[X]万
  • 转化率目标:[X]%
  • NPS目标:[X]分

资源需求:

  • 前端:[X]人
  • 后端:[X]人
  • 设计:[X]人

是否调整阶段1的规划?

A) 阶段1规划合理,继续阶段2 B) 需要调整里程碑 C) 需要调整资源分配

逐个阶段确认。


步骤 4: 识别关键依赖与风险

⚠️ 关键依赖与风险分析:

外部依赖:

  • 第三方服务(支付、短信、地图等)
  • 资质合规(牌照、备案等)
  • 合作伙伴对接

内部依赖:

  • 关键人员(核心开发、设计师)
  • 技术基建(数据库、服务器)
  • 数据基础设施

主要风险:

风险概率影响应对措施
开发延期高里程碑延迟预留20%缓冲时间
政策变化中产品方向调整关注政策动态
竞品先发中市场空间压缩快速验证,快速迭代

是否还有其他风险需要补充?


步骤 5: 输出产品路线图

使用 Write 工具创建 docs/03-增长迭代/产品路线图.md:

# {产品名称} 产品路线图

## 一、产品愿景

**愿景**:{VISION}

**规划周期**:{TIMEFRAME}

**战略目标**:
1. {目标1}
2. {目标2}
3. {目标3}

---

## 二、阶段规划总览

| 阶段 | 时间 | 核心目标 | 关键指标 | 里程碑数 |
|------|------|---------|---------|---------|
| 阶段1 | M1-M2 | {目标} | {指标} | 3 |
| 阶段2 | M3-M4 | {目标} | {指标} | 3 |
| 阶段3 | M5-M6 | {目标} | {指标} | 2 |

---

## 三、详细里程碑

### 阶段1: {名称}(M1-M2)

**核心目标**:{描述}

**里程碑**:
1. **M1**(第X周):{交付物}
   - 验收标准:{标准}
2. **M2**(第X周):{交付物}
   - 验收标准:{标准}
3. **M3**(第X周):{交付物}
   - 验收标准:{标准}

**所需资源**:前端X人,后端X人,设计X人

---

## 四、关键依赖

| 依赖项 | 类型 | 状态 | 负责人 |
|--------|------|------|--------|
| {依赖项} | 外部/内部 | 已确认/待确认 | {负责人} |

## 五、风险与应对

| 风险 | 概率 | 影响 | 应对措施 |
|------|------|------|---------|
| {风险} | 高/中/低 | 高/中/低 | {措施} |

## 六、路线图变更记录

| 版本 | 日期 | 变更内容 | 原因 |
|------|------|---------|------|
| v1.0 | {日期} | 初始版本 | - |

---

**文档状态**: 产品路线图规划完成
**生成时间**: {时间戳}
**生成工具**: super-pm

步骤 6: 完成提示

✅ 产品路线图完成!

📄 已生成:docs/03-增长迭代/产品路线图.md

🎯 建议下一步:

A) 执行 /pm-iteration - 制定近期迭代计划 B) 执行 /pm-risk - 风险管控方案 C) 执行 /pm-roadmap - 查看/更新路线图


兜底机制

场景: 已有路线图
if [ -f "docs/03-增长迭代/产品路线图.md" ]; then
  echo "⚠️ 检测到已有产品路线图"
fi

提供选项:查看/更新/重新规划。


注意事项

  1. 路线图应该聚焦于"为什么做"而非"怎么做"
  2. 每个里程碑必须可衡量
  3. 预留20%缓冲时间应对延期
  4. 路线图是动态文档,建议每月回顾更新

输出质量对比

✅ Good 示例:

- 有数据引用:「根据 Q4 数据,留存率从 35% 降至 28%」
- 有验证来源:「数据来源:Google Analytics, 2025-12-01」
- 有明确建议:「建议将新手引导步骤从 5 步减少至 3 步」

❌ Bad 示例:

- 模糊结论:「数据表明留存率有所下降」
- 无来源:「根据经验,这个功能很重要」
- 没有行动建议:「留存是个问题」

常见误区 / Red Flags — STOP

出现以下情况立即停止并回溯:

误区正确做法
使用"应该"、"大概"、"看起来"做结论必须基于实际数据和验证
未运行检查就声称已完成先验证,再陈述
因时间紧迫跳过关键步骤没有例外,时间紧更要严格
"这次应该没问题"的想法每次都要重新验证

产出质量检查 / Verification Checklist

  • 前置依赖已满足(输入文档/数据已收集)
  • 核心步骤已全部执行
  • 输出文档已生成到 docs/ 目录
  • 每个判断都有数据/证据支撑
  • 已推荐 2-3 个后续 skill

⚠️ 任何一项未通过 → 补全后再标记完成。


コメント