プロダクトロードマップが、機能追加リストになっていないか。
四半期のはじめに、ロードマップの資料が配られる。
並んでいるのは、機能の名前だ。検索機能の強化。管理画面のリニューアル。外部サービスとの連携追加。通知設定の拡充。それぞれに、リリース予定の月が振られている。
見た目は整っている。何をいつ作るのかが、一目で分かる。
支援の現場で、ロードマップがこの形になりかける場面を、何度も見てきた。そして、この形のロードマップが、事業を前に進めているとは限らない。
ロードマップに並べるべきは「作るもの」ではなく、「解く問題」と「動かす数字」だ。機能はその下に置く仮説であり、足すだけでなく、消すことも計画に載せる。
ロードマップが機能追加リストになっている、4つのサイン
見た目では、区別がつかない
機能リストになったロードマップは、見た目では普通のロードマップと区別がつかない。どちらも、項目と時期が並んだ表だからだ。
違いは、行の中身にある。4つのサインで見分けられる。
行が、機能の名前だけで書かれている。 「◯◯機能の追加」「◯◯画面の改修」。何を作るかは書いてあるが、それで何が変わるのかは書いていない。
完了が、リリース日で判定されている。 出した日が、終わった日になっている。出した後に何が起きたかは、ロードマップのどこにも出てこない。
なぜその機能なのかが、書かれていない。 誰のどんな困りごとを解くのか。どの数字を動かすのか。行を読んでも分からない。
項目が、増える一方で減らない。 追加はあるが、削除も中止もない。四半期ごとに行が伸びていく。
どれか一つでも当てはまるなら、そのロードマップは「何を作るか」の予定表になり始めている。
作ったものの多くは、ほとんど使われていない
12%の機能が、利用の80%を占めている
機能の予定表が問題になるのは、作ったものが使われるとは限らないからだ。
プロダクト分析ツールのPendoは2019年、自社ツールを1年以上使っている615社のデータを集計した。
3ヶ月間の利用を平均すると、機能の12%が日々の利用の80%を生み出し、機能の80%はほとんど、あるいは一度も使われていなかった。
ただし、「8割が無駄」ではない
この数字は、「機能の8割は無駄」という形で引かれることが多い。だが、私はそれは言い過ぎだと考えている。
Pendo自身が、報告書の中でこう問いかけている。頻度の低い機能は、本当に価値を生んでいないのか。それとも、単に見つけにくいだけなのか。
年に一度しか使わないが、その一度に欠かせない機能もある。見つけられていないだけで、便利な機能もある。使用頻度だけでは、価値は測れない。
だが、裏返せば、こうも言える。作ったかどうかでも、価値は測れない。
アイデアの少なくとも半分は、うまくいかない
プロダクトマネジメントの第一人者であるマーティ・ケーガンは、講演で「2つの不都合な真実」を挙げている。
ロードマップに載ったアイデアの少なくとも半分は、うまくいかない。うまくいく半分も、効果が出るまでに少なくとも3〜4回の改善が要る。
機能の名前を並べたロードマップは、この2つを前提にしていない。並んだ機能が、すべて効くかのように書かれている。
そして、1回出せば終わりであるかのように書かれている。
ロードマップが機能リストになる、3つの仕組み
担当者の能力の問題ではない
なぜ、ロードマップは機能リストになるのか。
これは、担当者の能力の問題ではない。組織の中に、そうなる仕組みが3つある。決め方、測り方、伝え方だ。
そして、この3つにはそれぞれ対応する処方がある。後半では、原因と処方を1対1で示していく。
決め方：機能の形で入ってくる
1つめは、ロードマップに何を入れるかの決め方だ。
ロードマップに入る項目の多くは、最初から解決策の形でやってくる。
顧客から「◯◯機能がほしい」と言われる。営業が「◯◯があれば受注できる」と持ち帰る。経営者が競合の新機能を見て「うちにも」と言う。どれも、はじめから機能の名前をしている。
メリッサ・ペリーは著書『Escaping the Build Trap』で、営業主導の会社では契約が製品の戦略を決めてしまい、ロードマップが顧客に約束したもので埋まっていくと書いている。
もう一つ、これは私の見立てだが、会議の性質もある。解決策のほうが、問題より合意しやすい。
「検索機能を強化する」には、誰も反対しない。だが、「初めて使う人が、目当てのデータに辿り着けずに離脱している」と書くと、原因や優先度をめぐって議論が始まる。議論を避けると、行は機能の名前になる。
測り方：出したら、完了になる
2つめは、何をもって成功とするかの測り方だ。
ペリーは、組織が成果（outcome）ではなく、出したもの（output）で成功を測る状態を「ビルドトラップ」と名づけた。
https://www.oreilly.com/library/view/escaping-the-build/9781491973783/
機能の数、リリースの回数、開発の速度。これらは数えやすい。だから、報告しやすい。
ペリー自身、プロダクトマネージャーとして何年も機能を作り続けたあと、それが本当に使われ、喜ばれているのか、確信が持てなかったと振り返っている。
ロードマップが機能リストだと、行を消化することが成果になる。出した後に確かめる理由が、どこにもない。
伝え方：書いた瞬間に、約束になる
3つめは、ロードマップが誰にどう読まれるかの伝え方だ。
ケーガンは著書『INSPIRED』で、「ロードマップ」という名前の資料にアイデアを並べると、どれだけ但し書きをつけても、社内の人はそれを約束として受け取ると指摘している。
前述の講演でも、多くの会社ではロードマップに載ったものが事業上の約束になる、と話している。
ここで、以前のnoteで書いた話とつながる。ジェフ・ベゾスは、決定を「戻せる決定（Type 2）」と「戻せない決定（Type 1）」に分けた。
機能のアイデアは、本来は戻せる決定だ。試して、効かなければやめればいい。
だが、ロードマップに載った瞬間、戻せない約束のように扱われる。半分はうまくいかないと分かっているものを、約束として並べていることになる。
3つが重なると、解決策だけが並ぶ
3つの仕組みは、同じ方向に働く。
機能は、決めやすい。出したことは、測りやすい。約束として、伝えやすい。
だから、放っておくとロードマップには解決策だけが並ぶ。解くべき問題は、議題に上がらないまま残る。
以前のnoteで、事業グロースの施策会議に出る案は、ほとんどが「導線」の話になると書いた。導線だけが、短期で動き、自部署で決められ、数字がすぐ出るからだ。
ロードマップでも、同じことが起きている。手を打てる範囲が、いつのまにか問題の範囲になっている。 施策会議では導線の施策が並び、ロードマップでは機能が並ぶ。どちらも、決めやすいものから埋まっていく。
決め方を変える：ロードマップの行を「解く問題」で書く
ロードマップは、戦略の説明である
ここから、3つの仕組みに対応する処方を示していく。まずは決め方だ。
ペリーは同書で、ロードマップを戦略と、プロダクトの現在地を説明するものと位置づけている。
作るものの一覧ではない。どこを目指していて、いまどこにいて、次に何を解こうとしているのか。その説明だ。
1行を、4つの要素で書く
そのために、ロードマップの1行を、次の4つの要素で書く。
解く問題：誰が、どこで、何に困っているか
対象：どの顧客の、どの場面か
動かす数字：何がどう変われば、解けたと言えるか
期間：いつまでに確かめるか
そして、機能はこの行の下に置く。問題を解くための、いまの時点での仮説として置く。
書き換えると、こうなる
たとえば、こういう書き換えになる。
書き換える前
検索機能の強化（6月リリース）
書き換えた後
初めて使う担当者が、目当てのデータに辿り着けずに離脱している。初回利用から7日以内の再訪率を、今期中に◯%から◯%へ上げる。
いまの仮説：検索の絞り込み条件を増やす／よく使う条件を保存できるようにする
こう書くと、機能は入れ替えられるようになる。検索を強化しても再訪率が動かなければ、別の仮説を試せばいい。
行は残り、手段だけが変わる。
既存のロードマップを、1行ずつ書き換える
ゼロから作り直す必要はない。
ケーガンが率いるSVPGは、機能のロードマップから成果のロードマップへの移り方について、既存の機能や案件ごとに、その下にある解くべき問題と、成功の測り方を書き出すのが、単純でまっすぐな方法だと書いている。
手元の機能リストの1行ずつに、2つの問いを当てる。
この機能で、誰のどんな困りごとを解くのか。
解けたかどうかを、どの数字で確かめるのか。
答えられない行が、必ず出てくる。それが、いちばん見直す価値のある行だ。
要望や営業案件は、問題に翻訳してから入れる
顧客の要望や、営業が持ち帰った案件も、そのまま行にしない。
「◯◯機能がほしい」と言われたら、その機能で何をしたいのかを聞く。そこで出てきた困りごとが、行に入る候補になる。
要望どおりの機能が、最善の解き方とは限らない。同じ困りごとに、もっと簡単な解き方があることも多い。
入口で問題に翻訳しておけば、ロードマップに機能の名前がそのまま並ぶことはなくなる。
測り方を変える：完了を数字で決め、効かないものは消す
完了は、リリース日ではなく、数字が動いた日
2つめの処方は、測り方だ。完了の定義を変える。
ケーガンは、成果を目標にして動くチームの利点として、頼まれた機能を出しただけでは、チームの仕事は終わらないことを挙げている。機能は、実際に効かなければならない。効かなければ、別の解き方を試す。
ロードマップ上の「完了」も、同じ定義にする。リリースした日ではなく、動かすと決めた数字が動いた日を完了とする。
リリースは、途中経過になる。出した後に数字を見る工程が、ロードマップの中に組み込まれる。
使われていない機能は、消す
数字を見ていると、もう一つのことが分かる。使われていない機能だ。
私自身、プロダクトの数値を見ながら、使われなかった機能を削除したことがある。
機能は、残しておくだけでコストがかかる。画面が複雑になり、利用者が覚えることが増え、改修のたびに影響範囲を確かめる必要が出てくる。
ただし、前述のとおり、使用頻度が低いことと、価値がないことは違う。消す前に、2つを確かめる。
もともと使う頻度が低い機能ではないか。 年に数回しか使わないが、その数回に欠かせない機能もある。
見つけられていないだけではないか。 置き場所や導線を変えれば、使われる機能もある。
どちらでもなければ、消す候補になる。
ロードマップに、「足す」以外の行を載せる
ここで、テーマの言葉に戻りたい。
問題は、ロードマップが機能「追加」のリストになっていることだった。載っているのが、足す判断だけなのだ。
だから、ロードマップに足す以外の行を載せる。
消す：使われていない機能を取り除く
やめる：数字が動かなかった仮説を打ち切る
確かめる：出した機能が効いたかを測る
私は、機能追加リストの反対は、機能を減らすことではないと考えている。足す以外の判断が、足す判断と同じ重さで載っていることだ。
伝え方を変える：見せる相手ごとに、書くことを分ける
同じ資料を全員に見せると、全員に同じ約束をする
3つめの処方は、伝え方だ。
私は、ロードマップを顧客に見せるとき、投資家に見せるとき、社内に見せるときで、書くことと書かないことを明確に分けている。
同じ資料を全員に見せると、全員に同じ約束をすることになる。仮説まで外に見せれば、外れるたびに約束を破ったことになる。
相手が、何を判断するのかで分ける
分け方の軸は、相手がロードマップを見て、何を判断するのかだと考えている。
顧客は、このプロダクトを導入するか、使い続けるかを判断する。知りたいのは、自分の困りごとが解かれる方向に進んでいるかどうかだ。
投資家や経営陣は、資金や人をどこに配分するかを判断する。知りたいのは、どの数字を、いつまでに、どこまで動かそうとしているかだ。
社内のチームは、次に何を試すかを判断する。知りたいのは、解く問題と、いまの仮説と、それが外れたときの次の手だ。
同じロードマップでも、相手が判断することが違えば、見せる中身は違ってくる。
約束は、例外として扱う
それでも、日付と機能を約束しなければならない場面はある。
大口顧客との契約。パートナー企業との連携。法規制への対応。マーケティングのローンチ。こうした場面では、「数字を動かします」では通らない。
ケーガンは、こうした場面のために「high-integrity commitments」という考え方を示している。日付や成果物を本当に約束する必要がある場面に限って、約束する。
約束は、例外として扱う。そして、例外として別に管理する。
SVPGは、こうした約束の一覧を「Plan of Record」と呼んで管理している会社があり、項目を追加できるのは通常、開発の責任者だけだと紹介している。
約束する層と、約束しない層を分ける
つまり、ロードマップを2つの層に分ける。
約束する層：日付と中身を守る項目。数を少なく保ち、追加できる人を限る。
約束しない層：解く問題と、動かす数字。手段は変わりうる。
多くの会社では、この2つが同じ表に混ざっている。その結果、仮説まで約束として読まれ、本当の約束まで仮説のように軽く扱われる。
層を分けると、どちらも正しい重さで扱えるようになる。
機能で書きたくなるときの、3つの反論
「成果で書くと、進捗が見えなくなる」
機能のロードマップは、進捗が分かりやすい。何本出たかを数えればいいからだ。
成果のロードマップでも、進捗は見える。動かすと決めた数字が、いまどこにあるかを見ればいい。数字が動いていないなら、何を試して、何が外れたかを報告する。
見えにくくなるのは、作業量のほうだ。だが、作業量は進捗ではない。
「成果で書くのは、約束から逃げているだけではないか」
「顧客体験を良くする」のような書き方なら、そのとおりだ。何も約束していない。
だから、1行に数字と期間を置く。「今期中に、再訪率を◯%から◯%へ」。
これは、機能の約束より厳しい約束になる。機能を出しても、数字が動かなければ終わらないからだ。
「機能で書かないと、開発の見積もりができない」
見積もりは、仮説の単位で行えばいい。
行の下に置いた仮説は、具体的な機能だ。その見積もりは、これまでどおりできる。
変わるのは、見積もった機能が、行そのものではなくなることだけだ。
会社の規模で、ロードマップの役割は変わる
スタートアップ：営業起点で始まるのは自然
ここまでの話は、会社の規模によって当てはまり方が違う。
創業初期の会社では、ロードマップは社長の頭の中にあることが多い。そして、目の前の顧客が求めるものを作る。
ペリーも同書で、多くの小さな会社は営業主導で始まり、それ自体は悪いことではないと書いている。最初の顧客の声は、解くべき問題を知るための、いちばん確かな手がかりだからだ。
問題は、切り替えが遅れることだと考えている。
顧客が増えても、声の大きい顧客の要望をそのまま作り続けると、ロードマップは約束の山になっていく。社長の頭の中で問題に翻訳されていたものが、組織が大きくなると、翻訳されないまま行になる。
大企業：伝える道具としての役割が大きい
一方、大企業では、ロードマップの役割が大きく変わる。
ケーガンはインタビューで、ロードマップはコミュニケーションの道具として有用であり、会社が大きくなるほど、伝えることの重要性が増すと話している。
部門をまたいだ依存関係がある。営業、マーケティング、サポートが、それぞれ準備を必要とする。だから、ロードマップをなくすことはできない。
大企業で必要なのは、ロードマップをやめることではない。約束する層と、約束しない層を分けることだ。
立場によって、変えられることが違う
経営者なら
「何を作るか」ではなく、「何の数字を動かすか」で承認する。
機能の一覧を見て承認すると、その一覧が約束になる。数字と期間を見て承認すれば、手段はチームに任せられる。
そして、ロードマップに「消す」「やめる」の行があるかを確かめる。 足す行しかないなら、判断が偏っている。
事業責任者・プロダクト責任者なら
既存のロードマップを、1行ずつ書き換える。
各行に「誰のどんな困りごとか」「どの数字で確かめるか」を書き足す。答えられない行から、優先して見直す。
そして、約束する層と、約束しない層を分けて管理する。 約束の層に項目を足すときは、本当に約束が必要な場面かを確かめる。
営業・カスタマーサクセスなら
顧客に約束する前に、約束が必要かを確かめる。
顧客が求めているのは、特定の機能なのか、困りごとの解消なのか。後者なら、機能の約束は要らないかもしれない。
そして、要望を持ち帰るときは、機能の名前ではなく、困りごとで伝える。 それだけで、ロードマップの入口が変わる。
ロードマップ点検シート
最初に確かめるなら、2つめだと思う。
動かす数字が書けない行は、何のために作るのかが決まっていない。
作らないものも、決める文書
ロードマップは、作るものを決める文書だと考えられている。
だが、私は同じくらい、作らないもの、やめるもの、消すものを決める文書だと考えている。
機能を足すことは、いつでも決めやすい。誰も反対しないし、出せば進んだように見える。だから、放っておくとロードマップは足し算だけになる。
足し算だけのロードマップは、何を作るかは教えてくれる。だが、事業がどこに向かっているのかは教えてくれない。
解く問題と、動かす数字が書かれていれば、機能は入れ替えられる。消すことも、やめることもできる。
「このロードマップが全部リリースされたら、何の数字が動くのか」
次にロードマップを見るとき、この問いを一度だけ置いてほしい。
答えが出るなら、それはロードマップだ。答えが出ないなら、それは機能の予定表かもしれない。
「作るもの」から「解く問題」へ、一緒に設計する
「ロードマップが、いつのまにか機能の予定表になっている」「リリースは続いているのに、事業の数字が動かない」「顧客や営業との約束で、ロードマップが埋まっていく」——そんなご相談を受けています。作るものを並べる計画から、解く問題と動かす数字を並べる計画へ。その設計を、意思決定の編集者として、経営者と並んで進めています。顧問・アドバイザリーとして請けているほか、noteとあわせて、毎週配信中のニュースレター（theLetter）では、こうした思考を継続的に届けています。
ニュースレターのご案内
経営やマーケティングの現場で見てきた「マーケティング」「ブランディング」「新規事業」「事業グロース」等の話を、構造化して書いていきます。
事業成長ノウハウとブランディング・マーケ・PRの事例や、世の中の最新トレンドもお届けしています。
「Business Growth Letter」
お知らせ
📝Business Growth Club
SNSに出せない経営・マーケティング・ブランディング・事業グロースの裏側、業界の構造、顧問・アドバイザリーとして見てきたリアル——を、毎週書いています。Business Growth Club に入れば、過去記事含めすべて読み放題です。メンバー限定のSlackにも参加可能です。
→ Business Growth Club に参加する
🏢 個別の壁打ちを求める経営者の方へ
法人向けに、個別の壁打ちや経営支援が必要な方はこちらプランへ。「ブランディング・マーケティングの判断・実行プロセスの改善」も含めて、現場で一緒に考えます。月1回のオンライン壁打ちの他、専用のSlackチャネルで随時チャットで日常相談も可能です。（有料の過去記事も読み放題→社内共有も可能）。
→ 法人向けグロース顧問支援プラン
📚 著書『設計と編集シリーズ』
──設計と編集シリーズ（全5作）。生成AI時代のマーケティングと、事業グロースの設計について書いた書籍シリーズです。
・PDF版無料配布中
・Kindle版99円で販売中
・POD（ペーパーブック）版1,980円で販売中
🚀 Marketing-OS
書籍『設計と編集』シリーズ連動の、マーケティングの意思決定を構造化するAI CMO搭載SaaS（BPOプランもあり）。
意思決定を最高到達点へ。
サイト・CRM・SFA・広告・SNSのデータを横断して観測・分析し、KPIや施策の矛盾を診断、判断を蓄積する。AI CMOを搭載した、マーケティング組織を強化するためのOSです。
その他、相談・依頼はこちら
まずは気軽に、HPやオフィシャルウェブサイトをご覧いただき ご連絡ください。各種SNSのフォローやDMも大歓迎です。
