顧客の声からプロダクトロードマップを作る方法

プロダクトロードマップの作り方は、要点を言えばこうなる。顧客がすでに求めたことを集め、各リクエストの裏にある問題でグループ化し、説明できる基準で順位をつけ、それぞれにどのくらい自信があるかを決め、読む人に合った形式で公開する。順序が大事だ。先にレイアウトを決めてアイデアで埋めると、完成して見えるのに、根拠がないドキュメントになる。リクエストから始めたチームは、短いロードマップを手にし、どの行にも理由がある。

プロダクトロードマップを作るとき、どこから始めるか

白紙からではなく、すでに手元にある証拠から始める。未対応の機能リクエスト、同じ不満でタグ付けしたサポートの会話、営業の通話メモ、自社製品の利用データ、これらすべてが入力になる。1つのリストにまとめ、各項目がどこから来たかを書いておく。

リクエストが、そのまま使える形で届くことはまれだ。「Slack連携を追加して」と「タスクが変わったらチームに通知して」は、同じ要望かもしれない。だから次の手順がグループ化で、重複をまとめてくれるトラッカーを使う価値がある。その方法は重複する機能リクエストで扱っている。また、サポートチケットと機能リクエストは、それぞれ違う種類のシグナルを持つので、片方だけで作ったロードマップは偏ることを覚えておいてほしい。

リクエストをロードマップの項目にするには

リクエストを問題でグループ化し、各グループを成果として名づけ、件数を残す。リロードするとフィルターが消えることを述べた14件のリクエストは、「前回使ったフィルターが保持される」という1つの項目になる。件数は根拠の欄に入れるので、ロードマップを読む人は、その項目の重みを見られる。

成果は、顧客の言葉で書く。「保存ビューの永続化を実装する」は、エンジニアには何を作るかを伝えるが、顧客には何も伝えない。成果として書くと、役に立つ問いも生まれる。顧客にとって何が変わるのか言えないなら、それは別のリストに載せるべき社内のタスクかもしれない。

何を最初にやるかは、どう決めるか

採点基準を1つ選んで書き留め、すべての項目に当てはめる。最もよく使われるのはRICEで、リーチ、インパクト、確信度、工数で採点する。IntercomによるRICEの解説が原典だ。説明できるなら、もっと単純な基準でも同じように機能する。たとえば、リクエストの件数を、求めた人が有料のアクティブなアカウントかどうかで重みづけし、おおよその工数で割る、というものだ。

大事なのは、基準が明示されていることだ。自分のリクエストがなぜリストにないのかを最初に尋ねた顧客は、答えを求める。基準と自分の判断が食い違うなら、その行にそう書く。採点方法、収益による重みづけの問題、投票数から分かることと分からないことは、機能リクエストの優先順位付けで説明している。

各項目にどのくらい自信があるか

何かを公開する前に、すべての項目に確度のラベルをつける。3値の単純な尺度で足りる。コミットは、その期間にリリースできなければチームが驚くという意味、見込みは、何かが変わらない限りそれが計画だという意味、検討中は、約束がないという意味だ。

この欄が1つあるだけで、ロードマップの被害の大半を防げる。これがないと、顧客は検討中の項目をコミットメントとして読み、営業がそれを引用し、四半期後にはクレームになる。Marty Caganのロードマップの代替案という文章が、根本にある主張を述べている。日付つきの機能のリストは、計画の顔をした推測のリストであり、解決策は、自分が何を知っているかを明示することだ。

ロードマップはどの形式にすべきか

レイアウトは、読む人を基準に最後に選ぶ。自分の声が届いたかを知りたい顧客には、短い公開版が要る。なぜこの作業なのかを問う経営陣には、テーマや成果が要る。毎月方向を変えるチームには、日付のないNow、Next、Laterがよく合う。プロダクトロードマップの例は、現実的な項目を使った6つの形式と、それぞれがどう失敗するかを示している。形式を選んだら、コピーする欄はプロダクトロードマップのテンプレートにある。

たいていのチームは、2つのドキュメントを持つことになる。社内の読者向けの戦略ロードマップと、守ると約束できるものだけを載せた、簡略化した公開版だ。公開するなら、すでに追跡している課題のラベルでそれを動かす方法を公開ロードマップで説明している。

ロードマップを古くさせないためには

すべての行にレビュー日をつけ、作業がすでにある場所にロードマップを置く。別のツールで手作業で更新するロードマップは、誰の日常業務にも含まれないので古くなる。各列が課題のラベルに対応していれば、ラベルが変わるとロードマップも変わる。

項目がリリースされたら、ループを閉じる。求めた人は知らされるべきで、その場所は通常、チェンジログのエントリだ。全体の流れはカスタマーフィードバックループで説明している。何かを作らないと決めたなら、それも伝える。はっきりした「やらない」は、求めた人の役に立つ。その書き方は機能リクエストを断るで扱っている。

FAQ

プロダクトロードマップの作り方の手順は何か? リクエストとデータを集め、各リクエストの裏にある問題でグループ化し、書き留めた基準で順位をつけ、各項目にどのくらい自信があるかをラベルにし、読む人に合った形式を選び、見直す日を決める。証拠から始めることで、ロードマップは短く、説明できるものになる。

プロダクトロードマップは何を土台にすべきか? 顧客のリクエスト、サポートの傾向、利用データ、自社の戦略だ。この並びは、飛ばされやすい順でもある。行の裏に根拠がないロードマップは、ただの願望リストだ。

プロダクトロードマップはどのくらい先まで扱うべきか? 役に立つだけ長く、信じられるだけ短く。多くの小さなチームでは、今の四半期を詳しく、その先の1〜2四半期をテーマとして扱う。それより先は日付なしで「later」に置く。

プロダクトロードマップを作るとき、誰が関わるべきか? 決めるのはプロダクトオーナーで、エンジニアリングが実現性と工数を確認し、サポートと営業が耳にしたリクエストやテーマを提供する。顧客は公開版で結果を見るが、編集はしない。

この記事の技術的な記述は第三者による確認を受けていません。誤りがあればお知らせください。修正します。

changeloopの関連ページ： 開発者向けドキュメント, changelogの例