プロダクトロードマップ自戒チェックリスト

ロードマップ作る時に読み返す自戒チェックリスト。

▢ 不確実性の共通認識が取れているか？

ロードマップは生き物であり、コミットメントではない。
その前提がなくロードマップの議論を始めるとチームはウォーターフォールになり、仮説検証ができなくなる。
今作っているロードマップはガントチャートやWBSであるのか、それとも不確実性と向き合うための今後の計画表であるのかを明らかにし、チームで共通認識を持っておく。

※ 注意
以下、ガントチャートなどのプロジェクトマネジメント前提ではなく、不確実性と向き合うためのプロダクトロードマップを前提に記載する

▢ ビジョンがあり、細分化されているか？

思いついた機能をすべて並べたものをロードマップと呼ばない。
プロダクトとして目指す姿（ビジョン）があり、1年分のロードマップであれば1年後の成功が目指す姿（ビジョン）として具体的に設定されている。そして、それを達成するための道筋としてロードマップが記載されている。

▢ 競合と異なる戦略が反映されているか？

2つ同じ製品はいらない。競合と同じロードマップであれば、差別化できず価格競争などで戦うことになる。
プロダクトが目指す姿（ビジョン）に向けてどこでどんなリスクをとることで事業を成功させようとしているのか、どんな仕組みをつくり市場と向き合うのかなどの戦略があった上でのロードマップである。他の戦略ではなく、なぜそのロードマップを採択するのか理由を説明できるようにする。

▢  十分に高い目標を掲げているか？

自分たちが目指した成功を超える成功は実現しない。ロードマップを引いたときに想定していた成功が天井になる。
現状の延長にある成功ではなく、もっと大きな成功を目指せているか？「今の10倍に成長するためにはどうすればよいのか？」のようにIssueを大きく捉える。どの方向に向けて大きくするのかを定義し、十分に大きな目標を目指す。

▢ 意味のある見積もりか？

高い目標は必要だが、実際に手を動かす担当者の意見を聞かずに莫大なロードマップを投げつけてはならない。これは開発者に限らない。作り手だけではなく、営業やCSなどが事業目標等を達成できるかという見積もりも含む。
また、見積もりができないような抽象的な概念だけのロードマップは順次具体化が必要である。例えば、「プロダクトリリース」とだけ書かれていて機能概要も決まっていないものや、反対に機能だけが書かれていて事業見積もりが難しいものも優先順位の根拠に欠ける。

▢ 成功に向けて、不確実性の高いところから検証できているか？

誰にも使われないプロダクトを作る必要はない。
プロダクトの不確実性の高いところから検証できるロードマップとする。また、その検証をする相手を十分に集めるための施策を盛り込んでおく。

▢ 達成の可否を測る定量的な指標があるか？

現実に則さないロードマップは最初から失敗している。ロードマップの節目ごとに成功を定義し、その成功が達成可能か、その成功にワクワクすることができるか、ロードマップの開始前に確認をする。
ロードマップは戦略であり、あなたのコミットメントである。冒頭には「コミットメントではない」と書いたが、ロードマップに責任を持つ人はそのロードマップに書いた成功に向かうことコミットする。途中で方向が違うと気付いたときには方針転換をする。顧客に対するコミットメントではないが、あなたのコミットメントではある。
そして、その達成を測る指標があり、プロダクトが目指す成功に向けて進捗しているかを確認する。

がんばりましょう！