prioritizing-roadmap について
75人のプロダクトリーダーの知見をもとに、プロダクトマネージャーやチームのロードマップとバックログの優先順位付けを支援するスキルです。意思決定の背景を確認し、効果の比較や仮説の検証を通じて投資のバランスを検討します。
主な機能
- 01目標・制約・関係者の整理
- 02ポートフォリオのバランス評価
- 03優先順位付けフレームワークの提案
- 04事実と仮説の切り分け
- 05効果の低い優先項目の見直し
活用シーン
- 01四半期ロードマップの項目選定
- 02共通の効果指標によるチーム間比較
- 03大きな賭けと段階的改善の両立
- 04ロードマップの低価値機能の見直し
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/prioritizing-roadmapを入力して読み込まれたか確認します。
同梱ファイルreferences/guest-insights.md
詳細
ロードマップの優先順位付け
75 人のプロダクトリーダーのフレームワークを活用し、ユーザーがプロダクトのロードマップやバックログに優先順位を付けられるよう支援します。
支援の方法
ユーザーが優先順位付けについて支援を求めたときは、次の手順に従います。
- 意思決定の背景を把握する - 目標、制約、ステークホルダーの状況について尋ねます
- ポートフォリオを評価する - 段階的な改善と大きな賭け、またはコア事業と新規事業のバランスを取る必要があるかを判断します
- フレームワークを提示する - 状況に適した優先順位付けのアプローチを提案します
- 前提に異議を唱える - 現在の優先事項が本当に最も大きなインパクトをもたらすのか、考え直せるよう支援します
基本原則
事実と仮説を分ける
Alex Hardimen：「こうした突飛な情報をすべて取り込み、非常に構造化されたモデルを作って、『さて、何が事実なのか。何に確信があるのか。何について疑問があるのか』を判断できるようにする、という考え方です。」確信度と疑問の度合いに応じて情報を分類し、チームで共通認識を築きます。
変化の速い市場では「シーズン」で考える
Asha Sharma：「今はどんなシーズンなのか、と考えます。最初のシーズンは AI のプロトタイピングだったかもしれません。次にモデルや推論モデルが中心となり、今はエージェントの時代が始まっています。」急速に変化する環境では、硬直した長期ロードマップではなく、市場の長期的な変化を軸にチームの認識を揃えます。
比較のための共通の尺度を作る
Dan Hockenmaier：「こうした取り組みを行ううえで最も難しいのは、それぞれの取り組みを比較するための共通の尺度を作ることです……それを可能にする関数がグロースモデルです。」計画時に、グロースモデルを使って異なるチームの予測インパクトを比較できるようにします。
計画で大きな発想を促す
Eeke de Milliano：「各チームのチャーターの最後には、『もっと大きく考える』というセクションがあります。『時間が 20％多くあったら、今のリストにない何に取り組みますか？』」計画文書で大きなアイデアを明示的に尋ね、チームが段階的な改善だけに注力するのを防ぎます。
砲弾と鉛の弾丸のバランスを取る
Adriel Frederick：「砲弾のような大きな取り組みもいくつか行いますし、鉛の弾丸のような小さな取り組みもたくさん行います。労力の 80％を大きな砲弾に、20％を鉛の弾丸に充てる、といった具合です。」健全なロードマップでは、多額の投資が必要な「砲弾」と段階的な「鉛の弾丸」のバランスを取り、改善が小規模なものばかりになるのを防ぎます。
ロードマップは現実を確かめるためのもの
Jackie Bavaro：「戦略におけるロードマップは約束ではありません。計画に筋が通っているか、実現可能な範囲にあるかを再確認するためのものです。」ロードマップは、採用を増やす必要があるか、もっと大きな賭けに出る必要があるかを見極めるために使い、約束として扱わないようにします。
優先順位付けは、最も大きなレバレッジを生む PM スキル
Ian McAllister：「スキル、知性、リソースが同じであれば、生まれつき優先順位付けに優れたプロダクトマネージャーは、そのスキルがない人の 5 倍のインパクトを生み出します。」テーマに優先順位を付け、テーマ内のプロジェクトの順序を決め、個人の時間管理にも優先順位付けを活用します。
利用率の低い機能を廃止する
Gibson Biddle：「こうした、利用者が 2％しかいない機能は廃止します。何かをリリースしても利用者が 2％しかいないなら……なくしてしまえばいいのです。」ごく一部のユーザーしか使わず、不要な複雑さを生む機能を取り除き、プロダクトをシンプルに保ちます。
ユーザーへの質問
- 「今四半期にひとつだけリリースできるとしたら、何を選びますか？その理由は何ですか？」
- 「効果がないと内心思っているものが、ロードマップに含まれていませんか？」
- 「最も確信がある項目はどれですか？最も確信がない項目はどれですか？」
- 「リソースが 20％多ければ、何を変えますか？20％少なければどうしますか？」
- 「種類の異なる取り組みのインパクトを比較する際、どのような共通の尺度を使っていますか？」
- 「プロダクトに何かを追加するのではなく、何かを取り除いたのはいつですか？」
注意すべきよくある間違い
- 声の大きさで優先順位を決める - 根拠に基づく優先順位付けより、ステークホルダーからの圧力を優先する
- 小さな改善ばかりで、大きな賭けがない - 変革をもたらす機能ではなく、無難な最適化でロードマップを埋める
- ストーリーのない機能リスト - ロードマップを戦略的なストーリーではなく、単なるスプレッドシートとして扱う
- 決して断らない - 何も削除せずに追加し続け、プロダクトが肥大化する
- ROIだけで考える - 不確実性が高く、大きなリターンが見込める賭けを犠牲にして、短期的な成果を優先する
詳細
75人のゲストから得た91件すべての洞察については、references/guest-insights.md を参照してください。
関連スキル
- 不確実性の下での計画
- スコープ設定と削減
- 意思決定プロセスの運営
- 問題の定義