【要約】Product Roadmaps Relaunched

Product Roadmaps Relaunched

Product Roadmaps Relaunchedを読んで、特に重要だと思ったポイントを要約しました。かなり意訳しているので、本来の意味からズレている可能性もありますが、ご了承ください。

TL;DR

タイトルの通り「従来のプロダクトロードマップは時代遅れになってしまったので、新しい時代に適した形に生まれ変わらせよう」というのが本書の主旨です。

重要なポイントは以下の3点です。
• 戦略のギャップを埋める
• アウトプットよりもアウトカム
• 戦略的意図や方向性を示すコミュニケーションツール

なぜプロダクトロードマップが必要なのか

「ロードマップ」という言葉が使われるようになったのは、1980年代のモトローラが始まりだと言われています。その後、MicrosoftやGoogleといったテック企業もロードマップを作るようになり、プロダクト開発の中長期的な見通しを示す方法として広く定着していきました。しかし、テクノロジーの進化スピードはどんどん上がっていき、ロードマップがプロダクト開発の実情にそぐわないものになってしまいました。今や技術トレンドはすぐに移り変わり、リリース直前に機能を削ったり、事業をピボットするのも日常茶飯事です。頑張ってロードマップを作っても、その通りにプロダクト開発が進まないのが当たり前になってしまったので、次第に人々はロードマップに対して失望するようになっていきました。

このような不確実性の高い時代の中で、リーンやアジャイルといった手法が浸透していきました。これらの手法は不確実性の高い状況に対処する上で非常に有効でしたが、一方でフォーカスしているのは数週間先程度までであり、中長期的な見通しは与えてくれません。どのようにプロダクトビジョンを実現していくのかという戦略的な意図は、プロダクトバックログだけでは分かりません。この戦略のギャップを埋めるために、新しく生まれ変わったロードマップが必要なのです。

何をプロダクトロードマップに書くべきか

従来のロードマップでは何がいけなかったのでしょうか。それは、いつまでに何を作るか、つまりアウトプットにフォーカスしていたことです。アウトプットは問題を解決するための手段であって目的ではありません。本来ロードマップでフォーカスすべきなのは、実現したい成果、すなわちアウトカムです。アウトプットにフォーカスしすぎると、本来実現したい成果を見失ってしまいます。そうすると、機能はたくさんリリースしているのにビジネスKPIが改善しない、顧客要望に応えているのに顧客満足度が上がらない、といった状況に陥ります。そうならないように、ロードマップをアウトカムにフォーカスさせるべきなのです。

それでは、具体的にどのような項目を書けばいいのでしょうか。決まりきったフォーマットやテンプレートはありませんが、以下の要素を含めるのがよいです。

プロダクトビジョンはロードマップの土台となる最重要項目です。なぜそのプロダクトは存在するのか、どのようなインパクトをもたらすのかを説明します。プロダクトの方向性を示す北極星のような役割を果たします。
ビジネス目標はプロダクトが実現しようとしているゴールであり、これがまさにアウトカムです。定量的なビジネス目標を設定することで、プロダクトの進捗が計測可能になります。指標として用いられるのは、売上や利益といった財務的なものが典型的ですが、組織の戦略やステージによってはMAUやNPSといった指標を用いることもあります。
いつ何を実現したいのか、タイムフレームで区切って記述することで、今注力すべきことが明確になり、過剰なコミットを避けられます。柔軟性を保つため、四半期であったり、Now, Next, Laterといった大まかな粒度で区切るとよいです。
プロダクトビジョンの実現、ビジネス目標の達成のために取り組むべきことがテーマになります。テーマには実装すべき機能ではなく、顧客の抱えているニーズもしくは問題について書くようにしましょう。これがプロダクトの達成すべき定性的なアウトカムです。
ロードマップが変更される可能性があるということを、免責事項として書いておきましょう。「ロードマップに書かれたことは約束事である」といった間違った期待を防ぐ意味があります。
これら5つの要素（プロダクトビジョン、ビジネス目標、時間軸、テーマ、免責事項）は欠かせません。

機能・ソリューションは、顧客のニーズや問題（＝テーマ）を解決するための成果物です。アウトカム志向の原理から考えると、機能（＝アウトプット）を書かない方がいいと思われるかもしれませんが、その機能の蓋然性が高い場合や、直接的に顧客ニーズに紐付かない技術的な課題、既に進行中のプロジェクトについては、書いてしまってもいいでしょう。
開発ステージは、ステークホルダーが現状認識するのに役立ちます。「発見」「設計」「試作」といったラベルがあれば、まだ開発の初期段階だとわかります。一方で「量産試作」「ベータ版」と書かれていれば、リリースが近いことがわかります。
各テーマを次のリリースまでにデリバリーできそうかどうかを自信度として表現することで、ステークホルダーの期待値コントロールとして使えます。
もしプロダクトに複数タイプの顧客がいて、それぞれのテーマごとにターゲット顧客が分かれているなら、それを明記しておくのもいいでしょう。
巨大で複雑なプロダクトについては、テーマや機能をプロダクト領域で区切るのが理にかなっています。その場合、それぞれのプロダクト領域ごとに、個別のビジネス目標を立てることになるでしょう。
これら5つの要素（機能・ソリューション、開発ステージ、自信度、ターゲット顧客、プロダクト領域）は、必要に応じて追加してください。

本書には、架空のホースメーカー「ウォンバット」のロードマップが例として載っています（図2-11）。

この例を見れば、ウォンバット社がどういう目標を掲げていて、それをどのように実現しようとしているのか一目瞭然です。作ろうとしている機能についての記述は最低限で、期限設定もざっくりなので、柔軟性もあります。このように、優れたプロダクトロードマップは、プロジェクトの計画というよりも、戦略的な意図や方向性を示すためのコミュニケーションツールだと言えるでしょう。

所感

プロダクトロードマップにフォーカスした日本語の書籍は見つからなかったので、本書はとても参考になりました。これまで読んできたプロダクトマネジメント関連の書籍でも、「アウトプットよりもアウトカム」という考え方を紹介している本は多かったと思います。本書も本質的には同じことを言っているので、全体的に違和感なくスッと腹落ちしました。

この要約では、なぜロードマップが必要なのか（Why）、何をロードマップに書くべきなのか（What）という説明に留まっていますが、本書ではどのように作っていくか、どのように運用していくか（How）についても説明されていますので、気になった方はぜひ手にとって読んでいただければと思います。