プロダクトロードマップのテンプレート:コピーして埋める項目

プロダクトロードマップのテンプレートとは、1行が1項目で、どの列も「必ず埋め続ける」と約束した欄になっている短い表のことだ。小さなチームの多くにとってうまくいく版は6欄で、成果、誰が求めたか、ステータス、担当者、確度、レビュー日からなる。ダウンロード用のテンプレートによくあるスイムレーン、ストーリーポイント、四半期の列などは、すべて任意だ。ロードマップが更新されなくなる原因は、たいていそこにある。

プロダクトロードマップのテンプレートには何を入れるべきか

読む人が判断に使う欄だけを入れ、誰が読むのかを答えられる欄だけを足す。成果は、その行が存在する理由だ。根拠があるから、顧客は自分のリクエストを見つけられる。ステータスは作業が動いているかを示す。担当者は、聞くべき相手だ。確度は、見込みが約束として読まれるのを防ぎ、レビュー日は行が古くなるのを防ぐ。

チームから求められたら足してよい欄が二つある。一つは、表の横に置く「やらない」リストで、見送ると決めたことと理由を残しておけば、四半期ごとに同じ議論を繰り返さずに済む。もう一つは「最終更新」の列で、行を編集した日を記録しておけば、読む人は現役のロードマップと放置されたものを見分けられる。

最初の版では、レビュー日以外の日付、工数の見積もり、ストーリーポイント、売上予測は外す。それらは計画用のドキュメントに置くもので、誰かにコミットメントとして読まれることなく変更できる。

記入済みのプロダクトロードマップのテンプレートはどう見えるか

架空のタスク管理アプリを例に、表を埋めてみる。項目はすべて作り話で、ステータスは3値だけにしている。

この中の2行が要点を示している。「オフラインモード」は担当者がおらず確度も低いが、それは「考えている段階だ」と正直に言う方法だ。「期限日を一括編集」は、消さずにクローズしてあるので、求めた顧客はその行き先をまだ見つけられる。

プレーンテキストがよければ、同じ表をリポジトリのMarkdownファイルにできる。作業のすぐ隣でバージョン管理できる。

| Outcome | Source | Status | Owner | Confidence |
|---|---|---|---|---|
| Keep the last filter | 14 requests | Building | Dana | Committed |
| Company SSO sign-in | 9 requests | Planned | Marcus | Forecast |

テンプレートはどの形式にすべきか

項目が10個以下で、読む人が詳細を求めるなら表を使う。方向転換が多く、日付を守りたくないなら、Now、Next、Laterの3列にする。Now/Next/Laterの形は、タイムライン型やテーマ型とあわせてAtlassianのプロダクトロードマップのガイドで説明されている。

上の表と3列のボードは、同じデータを持っている。表はロードマップの中で作業する人向きで、ボードはちらっと見る人向きだ。プロダクトロードマップの例は、現実的な項目を使った6つの形式と、それぞれがどう失敗するかを示している。欄が決まってから、レイアウトを選べばいい。

当て推量にならずにテンプレートを埋めるには

すでにあるリクエストから始め、成果は最後に書く。未対応のリクエストを、それぞれが述べている問題でグループ化して数え、その数を根拠の欄に入れる。根拠のない行は意見だ。意見があってもいいが、意見だと分かる見た目にしておくべきだ。

次に、顧客に説明できる基準で行を並べる。機能リクエストの優先順位付けでは、採点方法と、投票数だけでは判断を誤る理由を扱っている。行の並びが「何が先か」への答えで、ステータスの欄が「今何が起きているか」への答えだ。

確度は正直に書く。コミットとは、この期間に出せなければチームが驚く、という意味だ。見込みは、何かが変わらない限りそれが計画だという意味だ。検討中は、約束がまったくないという意味で、検討中の行を顧客に見せるロードマップなら、その言葉が何を指すのかを併記したほうがいい。

テンプレートはどのくらいの頻度で更新すべきか

項目のステータスが変わるたびに更新し、すべての行をレビュー日に見直す。更新が別の雑務になると、ロードマップは古くなる。だから、作業がすでにある場所に置く。課題トラッカーが情報源なら、ラベルでステータスの欄を動かせるので、誰も打ち直さなくていい。Changeloopが使っている、列ごとにラベルを対応させる設定は、公開ロードマップを正直に保つ方法で紹介している。

行がリリースされたら、求めた人に知らせる。これはどのテンプレートの欄にもできないことで、根拠の欄を残す理由でもある。リクエストから告知までの全体の流れは、カスタマーフィードバックループで説明している。

テンプレートは公開すべきか

自分のリクエストが届いたと顧客に見せたいなら、簡略化した版を公開する。公開版は成果とステータスを残し、担当者、確度、レビュー日を外す。営業の場で自信を持って説明できないものも載せない。長いまま静かになるリストより、短くても最新のリストのほうが信頼を生む。ほかのベンダーの例としては、ProdPadのテンプレートのページが、構成の一例を示している。

FAQ

プロダクトロードマップのテンプレートとは何か? ロードマップの各項目に、成果、ステータス、担当者、確度などの固定の欄を持たせた、再利用できる表またはボードだ。コピーして、項目ごとに1行ずつ埋め、更新し続ける。

プロダクトロードマップにはどんな列が必要か? 最低限、成果、ステータス、担当者だ。項目が数個を超えたら、リクエストの根拠、確度、レビュー日を足す。

プロダクトロードマップに日付を入れるべきか? 多くのチームでは、レビュー日だけでいい。カレンダー上の日付は、営業や顧客に引用されるコミットメントになる。代わりに、確度のラベルと、Now、Next、Laterのような期間の区分を使う。

ロードマップをスプレッドシートやMarkdownファイルで管理してもよいか? よい。共同で編集するチームにはスプレッドシートが向き、バージョン管理したいチームにはリポジトリのMarkdownの表が向く。作業をすでに追跡している場所を選べば、更新が別の雑務にならない。

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

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