← エピソード一覧に戻る Episode 154 Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
0:00 / 0:00
スクリプト
Chapter 1 オープニング ― 何を作るかより、何を後回しにするか
タカシ
皆さんこんにちは、タカシです。今日は SaaS プロダクトのロードマップ優先順位です。実は Pendo の調査では、平均的なソフトウェア製品の機能の 80 パーセントがほとんど使われていません。作る順番を誤ると、その瞬間から無駄が増えるんです。
ミカ
ミカです。80 パーセントですか。それは衝撃ですね。頑張って作った機能の大半が使われないなら、ロードマップって単なる予定表じゃなくて、かなり重たい経営判断に見えてきます。
タカシ
その通りです。SaaS のロードマップ優先順位は、機能一覧を上から並べる作業ではありません。限られた開発資源を、短期売上、解約防止、activation 改善、中長期の戦略投資にどう配るかという資源配分なんですね。
ミカ
今日はその配り方を知りたいです。大口案件を取るための要望もあるし、既存顧客の不満もあるし、未来への投資もある。全部大事そうに見える中で、何を先に作るかをどう決めるのかを聞いていきたいです。
Chapter 2 基本 ― 点数を付ける前に、今期の勝ち筋を決める
タカシ
まず重要なのは、個別機能のスコアリングから入らないことです。Productboard は、優先順位を revenue や churn のような遅行指標だけで決めると、戦略がぼやけやすいと整理しています。先に今期の成果テーマを決める必要があります。
ミカ
遅行指標だけだと弱い、というのはどういうことですか。売上を伸ばしたい、解約を減らしたい、は間違っていない気もしますけど、それだけだと何が足りないんでしょう。
タカシ
足りないのは、どの顧客に、どの行動を増やせば、その数字が動くのかという解像度です。たとえば今期は activation を立て直すのか、更新前の解約リスクを下げるのか、Enterprise 要件を詰めるのか。ここが曖昧だと、全部それっぽく見えてしまいます。
ミカ
なるほど。先にレーンを決める感じですね。解約対応、activation 改善、売上案件、戦略投資みたいに箱を分けてから、その中で優先順位を付ける。冷蔵庫の中身を全部一緒にしない、みたいな話に近いかもしれません。
タカシ
まさにそれです。Canny もチームや目的ごとに別 roadmap を持ち、重みづけを変える運用を勧めています。SaaS の product は、全社共通の一枚表より、何のための優先順位かを固定したほうが判断の精度が上がります。
Chapter 3 設計 ― 声の大きさではなく、事業インパクトで見る
タカシ
では、各候補を何で評価するか。実務では四つあると考えると分かりやすいです。対象セグメントと ARR、renewal risk、利用データ上の詰まり、そして effort と confidence。この四つを並べると、議論がかなり健全になります。
ミカ
でも現場では、結局 vote 数が多いものや、営業から強く言われたものが上がりがちですよね。みんなが欲しいって言ってるんだから作ろう、で流れてしまう感じ、すごくありそうです。
タカシ
そこが落とし穴です。Canny も votes は one signal にすぎないと明言しています。free user の多数票と、更新を控えた strategic account の少数票は同じではない。票数の前に、誰の課題で、どの売上や解約に効くかを見ないといけません。
ミカ
たしかに、Canny の customer requests report も、company spend、renewal risk、opportunity value をひも付けて見る前提でしたね。要望を feature 名で見るのではなく、顧客文脈ごとに見るから意味が出るわけだ。
タカシ
そうです。特に sales 起点の request は、金額の大きさだけでなく、自社の ICP と core workflow に合うかを必ず見る。ここを外すと、一件の受注のために product 全体が個社仕様へ引っ張られ、将来の開発速度を失います。
Chapter 4 具体例 ― 収益案件と activation 改善をどう見分けるか
タカシ
具体例でいきましょう。Canny の Paces は、以前は Slack や Linear に散らばった要望を雰囲気で判断していました。でも導入後は一般要望、quick win、data request に分け、毎週 upvote 数と revenue を見て優先順位を付ける形に変えました。
ミカ
しかも、スプレッドシート表示機能には 50 万ドル超の ARR がひも付いていると分かって、翌四半期に実装されたんですよね。これは、営業の声を聞いたというより、売上との接続を見える化したからこそ、納得感のある優先順位になった例ですね。
タカシ
一方で、収益案件ばかり追えばいいわけでもありません。Pendo の調査では、平均的な製品では全機能の 12 パーセントが日次利用の 80 パーセントを生み、残りの多くはほとんど使われません。だから core workflow の改善は、地味でも強いんです。
ミカ
OpenView の benchmark も、それを裏づけますよね。優れた PLG 企業の 87 パーセントは activation を追っていて、freemium signup の paid conversion は平均 5 パーセントしかない。入口と定着が弱いと、新機能だけ増やしても伸びにくいわけです。
タカシ
その通りです。もし activation や retention が弱いのに、新規機能の華やかさを優先したら、穴の空いたバケツに水を注ぐようなものです。SaaS の roadmap は、見た目の新しさより、価値到達と継続利用の詰まりを先に直せるかが勝負になります。
Chapter 5 クロージング ― 四半期テーマと更新リズムを持つ
タカシ
最後にまとめます。ロードマップ優先順位は、機能の人気投票ではなく、経営資源の配分です。四半期の最初に、何を勝ち筋として伸ばすかを決める。そして各候補に、顧客セグメント、事業影響、利用指標、effort、confidence を結び付ける。これが基本です。
ミカ
自社で始めるなら、まず roadmap を `解約防止 / activation / 売上案件 / 戦略投資` に分けて、Sales と CS と Product で隔週レビューするのがよさそうですね。同じ backlog を見ていても、同じ意味で見ていない問題が減りそうです。
タカシ
ええ。そして更新されない roadmap は、ないのとほぼ同じです。何を今期は後回しにするのかまで含めて、全社で共有すること。そこまでできて初めて、product は声の大きさではなく、勝ち筋で前に進めます。今日はロードマップ優先順位でした。ではまた次回。