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