プロダクトロードマップは、大抵の混乱が生じます。実際、 非常に経験豊富なプロダクトマネージャーでさえ、まだ完全には何が正解なのか分かりません。3年前、「製品ロードマップの再考」というブログを書きました。その中で、締め切りに合わせて機能を列挙するのではなく、顧客の問題解決に焦点を当てることを提唱しました。この記事には多くのフィードバックが寄せられ、多くは賞賛のコメントでしたが、中には批判的もコメントありました。最大の収穫は、「これは発見段階の新製品にはいいが、すでに検証済みで構築する必要のある製品の場合はどうするのか？」というコメントでした。
それ以来、実際の状況で何が最も効果的かを、お客様と一緒に考えてきました。そこで、見つけたフレームワークを皆さんと共有したいと思います。このフレームワークでは、発見とデリバリーのバランスをとることができ、辟易する機能のリストにかまうこともありません、一般的なロードマップと、それがいかに間違った方向に進んでしまったかについてお話します。
Googleマップが登場する前のロードマップは、小さな都市名と何千もの細い線で構成されていました。 一人で運転するには助手席に誰か必要で、非常に大きな地図を読んで、A地点からB地点への移動方法を指示する人が必要だったのです。
ロードマップの言葉の意味は、まさに、そこにあります。 ロードマップを使うと、自分がどこにいるのか、どこに行きたいのかを常に把握でき、さまざまなルートを選択できました。短いルートもあれば、長くても景色の良いルートもある。最適な道を選ぶのは、最終的には自分次第です。プロダクトのロードマップは、その名の通り、上記の本来の役割を果たすべきものですが、どこかで目的は失われてしまいました。最近では、ロードマップはガントチャートのような役割を果たしています。
ガントチャートは、スケジュールや期日を管理するためのプロジェクト管理ツールです。大規模な製造業のプロジェクトにはあっていますが、ソフトウェアの開発には不確実性が伴うため、ほとんどの場合、うまく機能しません。
どのようなソフトウェア製品を検討すべきかを最初に決める際には、ユーザーの求めているのものが何かわからないため、完成品がどのようになるのか正確にはわかりません。そのため、製品の開発期間を見積もることは、ほぼ不可能です。それでも、私たちはこのガントチャートモデルを使って作業計画を立て、自らを特定の日付までにソリューションを提供しなければならないようと袋小路に追い込んでいます。チームはこの計画に柔軟性がないことに不満を抱え、経営陣はチームが予定通りに納品されないことに怒ります。その結果、ユーザーのためにならない機能のリリースばかりになってしまいます。
それよりも、不確実性を考慮し、発見と納品の両方に柔軟性を持たせることができるモデルが必要です。そのためには、成果、テーマ、仮説で構成されるプロダクトロードマップを重視し、検証されていないソリューションや機能は除外しています。
私が作成した、あるチームのプロダクトロードマップの例を見てみましょう。プロダクトの例としてニューヨーク健康取引所（New York Health Exchange）のウェブサイトを使っていますが、これは修正すべき点を簡単に特定できるからです。ニューヨーク健康取引所と一緒に仕事をしたことはありませんし、彼らが内部でどのように機能しているかについての知識があるとは言えませんが、私はこのウェブサイトの顧客です。もし彼らと一緒に仕事をしていたら、プロダクトの改善にこのようにして取り組むでしょう。
ロードマップの一番上のセクションには、「ビジョン」「チャレンジ」「目標とする状態」の概要が記載されていますが、これは「プロダクト戦略」の記事で説明した目標を反映したものです。 プロダクトロードマップは、上記の目標に沿ったものでなければならず、目標達成のための戦術を伝えるのに役立ちます。
このロードマップによると、チームXは「NYS of Healthでアカウントを作成した人の99％に保険に加入してもらう」という包括的な目標（またはチャレンジ）に向けて取り組んでいます。
チャレンジの設定ができたところで、チームは目標達成を阻むお客様の問題を分析します。これは、最初のロードマップの記事で説明したのと同じプロセスです。例えば、ユーザー調査の結果、「NYS of Health」のウェブサイトのユーザーにとっての最大の問題は、理想的な健康保険プランを検索して見つけるまでに非常に長い時間がかかることだとわかったとします。混乱したプロセスで、非常にイライラします。それが原因で、人々は新規登録するのではなく、あきらめてしまうのです。
そこでチームXは、この問題に取り組むことを決め、成功したときにわかるように目標状態を設定します。「第2四半期に、健康保険を見つけて購入までの平均時間を3週間から2日に短縮する。」 ユーザーが健康保険に加入できるのは1年に1度だけだが、その加入期間が始まったら、プラン検索をより簡単にするために実施できる変更はたくさんあります。
そこから、チームXは、その目標状態に到達するために、第2四半期に探求したい、または実現したい上位の領域を把握します。これをテーマと呼びます。例えば、「検索機能の強化」というテーマには、健康保険の選択肢の検索を簡単にするために必要なすべてのUX作業が含まれます。
「なぜこのテーマを検討しているのか」の問いに答えるために、仮説や問題提起を記入します。プロダクトがまだ発見段階のときは、問題と解決策を検証している段階なので、「何がわかっていて、何がわかっていないのか」を記入したいです。仮説は、私たちのソリューションが最大の問題を解決すると確信していることを裏付けるものでなければなりません。
今回のテーマ「検索機能の強化」では、「健康保険を選ぶ際に買い物客が決める上位の要因を反映したフィルターオプションを強化することで、買い物客が選択肢を絞り込み、適切な健康保険を見つけることが容易になると確信している」という仮説を立てました。私たちは、人々が適切な医療保険を見つけるために選択肢を狭める問題を抱えていることをすでに検証しており、フィルターオプションにいくつかの機能強化を提供することで、その問題を解決できると考えています。
最後のテーマである「助成金コミュニケーション」は、まだディスカバリー・フェーズの初期段階にある問題の一例です。補助金の受給の資格保有者のコンバージョン率が非常に低いことがわかっていますが、その理由を調査したいと考えています。いくつかのアイデアがありますが、まだ検証していません。そこで、仮説を明確に伝える必要があります。わかっていること（「ほとんど無料で健康保険に加入できる人たちの転換率が非常に低い」）と、わかっていないこと（「補助金の資格があるかどうかを知る前に離脱してしまったのか、それとも補助金についての説明を理解できなかったのかはわからない」）を強調します。
仮説の後は、ロードマップの中で最も重要な「成果」の部分です。ここでは、この問題を解決したり、仮説を証明することで、何を達成したいのかを述べます。それぞれの成果は、何らかの形で「目標状態」に関連していなければなりません。私たちのやっている事はすべて「目標状態」に到達するためのものですから、各テーマのすべての成果がその目標の繰り返しでは、とてもつまらないロードマップになってしまいます。そうではなく、それぞれの変化や改善がどのように目標に向かっているかを考えてみましょう。
例えば、「検索機能の強化」では、「不満」という質的な要素と、「選択肢を見つけるまでの時間の短縮」という量的な要素の測定で、人々が検索しやすくなったかどうかを判断します。これらのセクションでは、ビジネス上の成果とユーザーの成果の両方をうまく組み合わせて、測定可能なものにすることが大切です。
最後の2つのセクションでは、ステータスとプライオリティを扱います。ステータスでは、ディスカバリーフェーズとデリバリーフェーズのどちらにいるのかを示す必要があります。ディスカバリーフェーズであれば、学習のために提供しているので、機能をリリースするよりも実験に焦点を当てています。 デリバリーフェーズでは、価値のある機能やソリューションをユーザーに提供します。チームと一緒に、この意味を社内で定義し、その定義を社内で共有して相互理解を深めましょう。
ここで、ロードマップには、これらの問題にどのように取り組むかという具体的な計画は含んでないことに注意してください。 これは、私たちがまだオプションを試している段階であり、一連の機能やソリューションコンポーネントを実装する計画を立てていないためです。
上記の例は、あるチームのロードマップに過ぎません。同じ課題に取り組んでいる他の多くのチームもあるかもしれませんが、それらはすべて異なる目標状態を持っています。これらのロードマップは、ポートフォリオ・ロードマップとしてまとめられ、ビジネスのさまざまなレベルにわたって伝達され、次のようになります。
まず最初に、ロードマップは、何よりもコミュニケーションツールであることを忘れてはいけません。ロードマップは、時間軸や目標を超えてチームを調整するものです。経営陣は6ヶ月から数年のタイムラインで目標とビジョンを設定し、チームは3ヶ月から6ヶ月までの小さなタイムラインを見るべきです。これらの目標が、会社がビジョンに到達するためにどのように役立つのかを説明する戦略文書が付随しているべきですが、ロードマップ自体はその目的を果たすものではありません。
ロードマップは生きたドキュメントです。テーマで検証できない場合は更新する。目標を変更したならば更新する。使いものにならないロードマップのために苦労する必要はありません。お客様とのコミュニケーションでは、機能をどのように提供するかではなく、お客様の問題をどのように解決するかに焦点を当てましょう。お客様は、何よりもまず、自分が受けている価値を気にしています。
引用元
Effective Product Roadmaps
