ジョー・ヴァン・オズ Joe Van Os
プロダクトマネージャーとは何かを常に探求し、その過程で学んだことを伝えている。
プロダクトコーリション（Product Coalition）
世界最大の独立系プロダクトマネジメントコミュニティ。100万人以上の読者、3,500以上の記事、7,000人以上のSlackメンバーがいる。members.productcoalition.com
今回は、製品ロードマップを戦略的に使うための考え方や方法について、セントラルスクェアのプロジェクトマネージャ、ジョー・ヴァン・オズ氏によるMediumdの記事をご紹介いたします。
Strategy, visualized. Crafted by design, engineered to keep customers close.
市場は常に変化しているため、製品を計画するのはたいへんです。想定していなかったことが起これば、いきなり修羅場をむかえることになります。
計画は常に変更されるので、ロードマップの効果に対して疑問が生まれ、ついにはロードマップは終わったと言われるようになったのだと考えます。しかし、「計画なくして成功なし」とも言われます。
多くの製品担当者にとって、ロードマップは初めて経験するビジネス戦略です。新人のプロダクトマネージャーが陥りがちな失敗がいくつかあります。
これらの問題は、ロードマップが製品チームの信念に基づいて内部に集中していることで起こります。しかし、価値はお客様の問題を解決することで生まれます。堅実な製品戦略において、価値を最大化し、リスクを最小化する最善の方法は、外部に焦点を当て、可能な限りの顧客の近くにいることだと理解されています。
優れた製品チームは、製品の価値は、ユーザーの問題を解決できたときに生まれると分かっています。しかし、製品チームがソリューションを構築するためには、まずユーザーが直面している問題を理解する必要があります。
エンドユーザーに焦点を当てれば、製品は自然とバリュー・ドリブンになります。そうすれば、プロダクトチームはユーザーの最大のペインポイントを理解し、新たな問題の発生に気づくことができます。
優れた戦略プランは、製品にフォーカスを与えます。製品がどのような市場の問題を解決するためにデザインされているかを具体的に示しています。製品の焦点がコアからずれるることは、典型的な失敗の原因になります。最近のベンチャーキャピタリストの調査では、スタートアップ企業が失敗する理由の第1位に「焦点が定まっていない」ことが挙げられています。
フォーカスは製品の深さを生み出し、製品の深さは常に製品の幅に勝ります。 深みのある製品が解決する問題は限られるかもしれませんが、それらの問題を解決するために優れた仕事をします。浅い製品は問題を「解決」するには不十分で、しばしばギャップや回避策で埋め尽くされてしまいます。
機能の数は一緒でも、深い製品はより多くの問題を解決する。
戦略的ロードマップは、製品が解決する問題に焦点を当て、そこに到達するためのハイレベルな目標を設定します。これにより、明確なビジョンと優先順位が生まれ、チームは自分たちの仕事をこれらの目標達成に結びつけることができるのです。
戦略的ロードマップなしでは、チームは無自覚なうちに、顧客や製品の価値にならない作業をしてしまうでしょう。
徹底した優先順位づけをして、なにが重要かを見つけ出し、それ以外にはノーと言うことです。
製品が解決すべき問題を選ぶには、市場やユーザー層についての十分な理解が必要です。それには、現在のユーザーもしくは潜在的なユーザーと会うことが一番の近道になります。
新製品では、製品-市場フィット（PMF）を探ります。この考え方により、成熟した製品では、機能-市場フィットの考え方が広まりました。製品-市場フィットでは、製品が解決すべき問題を定義し、機能-市場フィットでは、問題を解決するために必要な機能の深さを定義します。
デザイン思考は優れたフレームワークで、エンドユーザーが現在直面している問題を明らかにすることで、価値を発見することができます。
デザイン思考を表現するのに、次のようなフローが使われています。
個人的には、この直線的なダイアグラムはあまり好みではありません。それよりも、デザイン思考をリーンの延長で表現する方が好きです。
デザイン思考では、まず「測定」の要素に焦点を当て、顧客中心のアプローチをとります。顧客を巻き込んだインタラクティブなループは、最も重要な市場の問題（つまり価値）を浮き彫りにします。デザイン思考を取り入れると、様々なレベルでユーザー検証ができるので、リスクが管理しやすくなります。各レベルで検証することにより、間違ったものを作ってしまうリスクを減らすことができます。
ユーザーの問題を解決することにより価値が生まれます。ユーザーのフィードバックを通じて問題を検証するには、インタラクティブなループを測定（顧客フィードバック）の段階から始めるのがベストです。開発を始める前に目標を確認することができるため、チームの固有のバイアスで問題が歪められるリスクが低くなります。
ユーザーと話をして、一番のペインポイントは何かを知ります。ペインを取り除くことができる製品ほど、ユーザーにとって価値のあるものになります。お客様と一緒に問題を定義し、価値を定義することが、ユーザー検証の第一段階です。
問題点が出てきたところで、優先順位を決めて、重要度が高いものから取り組んでいきます。問題を解決することでユーザーにもたらされる価値と、それに伴うリスクで重要度は決まります。
リスクは、製品、市場、財務状況に大きく依存します。以下のことを検討するところから始めるといいでしょう。
プロダクトチームは、新しい目標や機能を吟味する際には、こうした難しい問題にも答えていく必要があります。
問題に対する解決策は、開発のできるだけ早い段階で決定する必要があります。最適な解決策は、時間の経過とともに変化する可能性があるからです。
顧客の問題に対する解決策には、包括的なチーム活動として取り組むべきです。そうすれば様々な視点を取り入れることができます。チームはより多くの視点を持てるので、提案されたソリューションにバイアスがかかる可能性をさらに減らすことができます。
最適なソリューションが決まったら、チームはプロトタイプを作成し、ユーザーと一緒にテストをして、第二段階のユーザー検証をしていきます。抽象的なアイデアはユーザーには分かりにくため、提案されたソリューションをより具体的に示すにはプロトタイプが有効です。
プロトタイプの正確性（詳細さ）のレベルは、リスクの度合いによって決まります。ソリューションのリスクが高ければ、レベルの高いプロトタイプと徹底したテストが必要になりますが、リスクが低ければ、ベーシックなプロトタイプと最小限のテストで十分です。
プロトタイプは捨る前提で作ります。顧客テストで効果を検証することが目的なので、プロトタイプ作りでは、時間をかけずに、必要最小限のバージョンを作ることが重要です。
ステップ4：ロードマップの作成
問題に対する価値とリスクが評価できたら、ROIに基づいて問題の優先順位をつけていきます。問題は、以下の4つのカテゴリーのいずれかに分類されます。
この段階では、価値のレベルは、顧客からのフィードバック主導で定義する必要があります。顧客にとっての問題が大きければ大きいほど、価値は高くなります。リスクは、全体のコストとなるフィージビリティによって決まります。
問題のカテゴリー分けをする際のガイドラインは以下の通りです。
ロードマップを作成する際に、考慮するべき点がいくつかあります。
ロードマップテンプレートのプロトタイプ
目標がロードマップから開発バックログに移る準備ができたら、要件をスコープする準備が整います。開発要件のスコープを実際の開発にできるだけ近づけることで、開発要件が現在市場で求められているものと一致していることを確認できます。
ロードマップのプロセスで、目標と機能が正しく検証されれば、製品チームと開発チームが協力して、問題を解決するために必要な要件について取り組むことができます。もし、ユーザーエクスペリエンスに関して新たな疑問が出てくれば、内向きになるのではなく、電話のユーザーの声を聞くようにします。
デザイン思考を用いることの素晴らしい点は、コードを1本も書かずに目標を検証できることが多いことです。これは、開発チームが取り組むすべてのことに価値があるということを意味します。さらに、標準的なリーンにはない検証レベルが追加され、製品を可能な限り顧客に近づけることができます。
この記事は、2018年10月に公開されました。英文はMediumで閲覧できます。
●The Art of the Strategic Product Roadmap
（DMN編集部）
DMNでは、他にも様々なブログを「DMN Insight Blog」にて配信しております。
定期的に記事をご覧になられたい方は、ぜひご登録をお願いいたします！
→「DMN Insight Blog」メールマガジン登録