roadmap-prioritization について
散在するバックログを、根拠に基づくロードマップにまとめるプロダクト計画スキルです。スコアリング、施策ポートフォリオの調整、文書化を支援し、計画プロセスを戦略上の仮説検証にも活用します。
主な機能
- 01バックログ案の監査と分類
- 02RICEまたはDRICEによる評価
- 03段階的改善と大きな賭けの配分
- 04固定の投資期間に合わせた範囲設定
- 05ロードマップのテーマと時期の作成
活用シーン
- 01膨らんだ製品バックログの優先順位付け
- 02根拠と見積もりに基づく案の比較
- 03規模の異なる施策への工数配分
- 04チーム合意に向けたロードマップ作成
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/roadmap-prioritizationを入力して読み込まれたか確認します。
同梱ファイルreferences/artifacts.mdreferences/guest-insights.md
詳細
ロードマップの優先順位付け
混沌としたバックログを、エビデンスと投資意欲に基づく高い ROI を生み出す戦略計画に変えます。
Lenny's Podcast と Newsletter における24人のゲストや投稿から得られた知見を活用し、ユーザーのロードマップの優先順位付けを支援します。
支援方法
- バックログを監査する - 解約データ、サポートチケット、戦略目標など、多様な情報源からアイデアを集め、分類できるよう支援します。
- スコアリングフレームワークを適用する - RICE や DRICE のスコアリングを通じて、直感的な判断から客観的な ROI の見積もりへ移行できるよう案内します。
- ポートフォリオのバランスを取る - 段階的な成果、大胆な賭け、基礎となる必須事項の間で、リソースを配分できるよう支援します。
- ロードマップ文書を作成する - 最終的な成果物をテーマとタイムラインに沿って構成し、会社の戦略のプロトタイプとして機能させます。
基本原則
エビデンスに導かれる直感
Itamar Gilad：「Amazon、Airbnbなど、成功しているプロダクト企業を見れば、どの企業も、少なくとも最も成功していた時期には、人間の判断とエビデンスのバランスを取る方法を見つけていました。人間の判断や意見を排除しようとはせず、エビデンスによってそれらを強化しようとしました。そして、実にさまざまなモデルが生まれました。」
優先順位付けは、厳密なエビデンスによって人間の直感を補強する協働プロセスであるべきです。これにより、リーダーシップからの指示を批判的に評価できます。
戦略のプロトタイプとしてのロードマップ
Janna Bastow：「ロードマップに価値があるのではありません。価値があるのはロードマップ作成のプロセスです。実際に行っているのは、解決しようとしている課題についての仮説を明らかにすることです。」
ロードマップは、固定された実行計画ではなく、戦略的な仮説を検証するためのツールとして捉えましょう。ロードマップがきっかけとなる対話を重視してください。
構造化された探索
Paige Costello：「広く検討し、絞り込み、また広く検討して、さらに絞り込むプロセスによって、人々は意見に偏った見方から抜け出せます。私たちは、自分たちが何をしているのか、なぜそうしているのかについて、定量的にも定性的にも好奇心を持ち、より体系的かつ厳密に取り組む必要があるからです。」
ダブルダイヤモンドのような体系的なプロセスを用いて、複数の選択肢を探索してから絞り込みましょう。そうすることで、意見に偏った意思決定を防げます。
見積もりよりも投資意欲を固定する
Ryan Singer：「大きな構想を持ち出して、『これにはどれくらいかかるでしょうか？』と尋ねることはしません。逆に、『何かを完成させるまでに、どれだけの時間をかける意思があるか？』と考えます。」
所要時間を尋ねるのではなく、事業として投資する意思のある時間を固定し、その期間に合うよう解決策を形作りましょう。
ユーザーを支援するための質問
- 「現在の計画における、段階的な改善とリスクの高い大胆な賭けの比率はどれくらいですか？」
- 「顧客から寄せられた定性的な要望のうち、優先度の高いものを、定量データや実験で検証しましたか？」
- 「この取り組みに投資する意思のある期間、つまり固定する投資枠はどれくらいですか？」
- 「主要ユーザーの日々のワークフローより、中間管理職のレポート作成ニーズを優先していませんか？」
- 「今四半期、チームの選択を導いている上位3〜4つの戦略テーマは何ですか？」
注意すべきよくある間違い
- ユーザーのフィードバックだけに反応する - よくある要望は、たいてい必須事項であり、持続的な差別化に必要な新しいイノベーションにつながることはほとんどありません。
- ユーザーに障害をもたらす機能を優先する - 経営管理のレポート作成向けに機能を構築すると、主要ユーザーの日々のワークフローに摩擦が生じ、機能が肥大化することがあります。
- ロードマップを分断したままにする - デザイン、プロダクト、エンジニアリングの文書を別々に管理すると、責任の所在が分断され、真の部門横断的な連携が妨げられます。
- 計画錯誤に陥る - エンジニアに所要時間の見積もりを求めると、スコープが過大になりがちです。投資意欲を固定し、それに合わせてスコープを縮小するほうが適切です。
Deep Dive
For all 50 sourced insights from 24 guests, see references/guest-insights.md
Related Skills
- Goal Setting Okrs
- Planning Cadence
- High Stakes Decisions
- Evaluating Trade Offs