プロダクトロードマップのアンチパターン2選（2）
アンチパターン2：「機能を書かない」ことに固執する
プロダクトマネジメントの書籍などでは、「プロダクトロードマップでは機能を書かず、アウトカムで記載する」というアドバイス がよく見られます。確かに、多くの場合これは正しい指針です。しかし、この原則に過度に固執してしまうことも、実はアンチパターンの一つです。
例えば、先ほど挙げた「セールス、CS責任者との今後3か月の市場投入計画の共有」のようなケースでは、アウトカムだけでは具体的な行動計画を立てるのに不十分な場合があります。ある程度「どの機能」が強化されていくのか、たとえ不確実でも理解する必要があります。
このような場面で「機能を書かない」ことに固執すると、「何となく分かるが具体的な行動に結びつかない」プロダクトロードマップになってしまい、結果として効果的なコミュニケーションツールとして機能しなくなってしまいます。
回避方法
このアンチパターンを回避するには、シンプルに「必要であれば機能を書いてもよい」という柔軟な姿勢を持つことが重要です。
ただし、機能をプロダクトロードマップに書く際には1つ重要なポイントがあります。それは、「機能を書くこと」の前提をプロダクトロードマップを見る人としっかりと共有しておくことです。
多くの場合、機能を書かないほうがよいとされる理由の一つは、「顧客の課題を解決するHow（機能開発）はギリギリまで変わる可能性がある」という原則があるからです。Howに縛られすぎると、いわゆる「ビルドトラップ」に陥る確率が高くなってしまいます。
この原則は基本的に変わらないため、プロダクトロードマップに機能を記載する場合は、「ここに書かれている機能は今後変更される可能性が高い」という前提を関係者全員が理解していることが重要です。
特にSaaS製品のセールスチームなどでは、顧客の期待を高めることで受注につなげようとする傾向があるため、この認識を正しく共有しないと顧客とのミスコミュニケーションを招く恐れがあります。しかし、うまく利用できれば、セールスチームもより深いプロダクト理解に基づいた先を見据えた提案ができるようになるなど、大きなメリットがあります。
私の経験では、「実現したい顧客アウトカムを今イメージできる機能に具現化させる」という文脈で、プロダクトロードマップ内に「機能開発例」という形で記載していました。これらは必ず開発されるわけではありませんが、大まかな機能のイメージをつかむためのものとして有効でした。
まとめ
本記事では、プロダクトロードマップ作成・運用における主要なアンチパターンとその回避方法について解説しました。
-
「万能なプロダクトロードマップを最初から作ろうとする」アンチパターン
- 回避方法：使用目的と対象を明確にし、それに特化したロードマップを作成する
-
「機能を書かない」ことに固執するアンチパターン
- 回避方法：必要に応じて機能を記載し、その前提（変更の可能性）を関係者と共有する
これらのアンチパターンを理解し回避することで、プロダクトロードマップは単なる計画書ではなく、チーム全体の方向性を統一し、ステークホルダー間のコミュニケーションを円滑にする強力なツールとなります。
現在、プロダクトマネジメントに関する書籍が多く出版されていますが、それらのアドバイスをそのまま適用するのではなく、自社の組織構造やプロダクトの特性に合わせてカスタマイズすることが重要です。正しい理解と適切な運用を通じて、より「使われる」プロダクトロードマップを構築し、組織やプロダクトの成功に貢献していきましょう。
次回は、プロダクトロードマップを実際に作る前、作成中、作成後のそれぞれのフェーズにおけるポイントを、具体例とともにご紹介する予定です。お楽しみに。
