こんにちは！
最近はプロダクトマネジメントの領域に興味があり、Melissa Perriさんのブログを読んでいました。

エピソードの中では営業プロセスで機能の提供を約束して未検証機能のロードマップが作られて、検証後効果がないことがわかっても計画を変えられず機能を作る体験が紹介されています。
このエピソードにすごく共感しました。僕の体験でも検証不足の機能のロードマップが戦略ではなく計画に基づいて作られていました。
戦略に基づくと「何を作るべきか」という問いに用意するオプションはいつでも変わります。
ですが、僕のエピソードを思い出すと営業チームが顧客に機能の約束をしていることはなかったと思います。様々な書籍でも営業チームが顧客に機能の約束をするエピソードは登場しますが、遭遇していません。
ところが、このエピソードと同じように未検証機能のロードマップが生まれています。途中でロードマップの機能が変更されることは少なく計画に基づいたロードマップとして機能しています。
なので、今回は未検証機能のロードマップが生まれる過程を自分の経験を元に整理することにしました。

未検証機能のロードマップが生まれるシナリオ

Melissa Perriさんのブログを読むと企業が成長する過程で未検証機能のロードマップが生まれるのはごく自然なことだとわかります。ですが、企業の成長の途中で契約のためにつくりたい機能が増えてくると、プロダクトの探索の余裕を減らすため、作った機能で契約を増やす成長モデルになり、成長が線形でもっと機能を作りたい動機から人を増やしたくなります。確かに契約は増えていきますが、探索不足によって成長を緩やかにする機能が増えるため、プロダクトの維持の負担も増えます。そのため、費用対効果の高いプロダクトを望む場合、どこかで契約だけに頼る成長からプロダクト主導の成長に変わることを勧めています。

なので、成長中の企業では、成長の過程で未検証機能のロードマップが作られることがあります。今回は僕のBtoBのプロダクトの経験を元にそのようなロードマップが作られるシナリオを整理して、プロダクト主導に変わる支援として何ができるのかを検討する準備をします。

• この機能があれば契約する

• 競合の機能マップにはある

• 多くの顧客が言っている

• この顧客は大切だから

この機能があれば契約する

もし企業がまだ最初の顧客を探しているなら、こういうシーンでは契約を目指して機能を追加します。プロダクトはまだシンプルでスクラップ・アンド・ビルドを繰り返して、最初の価値を探索している途中かもしれません。

企業がより成長を目指して新たな市場や新たなニーズを開拓するときや新たな顧客を探すときに、顧客から機能の追加を条件に契約するシナリオがあります。たとえば、エンタープライズ企業の契約でセキュリティレベルに合わせて機能を追加したり、管理者がユーザー管理をできるように機能を追加します。

競合の機能マップにはある

もし市場に多くの競合がひしめいているなら、契約のプロセスで機能マップを比べるかもしれません。一般的な機能が備わってないと顧客に相手にしてもらえないと考えると機能の追加をロードマップに検討し始めるでしょう。

多くの顧客が言っている

「顧客の困っていることは明らかで、顧客がほしいものを追加するものでしょ？」

このようなニュアンスを言われたことがあります。顧客のフィードバックから学び、ソリューションを提供するために機能の追加をロードマップに検討するのは自然に感じます。営業チームが届けてくれる顧客のフィードバックは貴重な情報ですが、表面的な課題以外を検討せずにソリューションを提供すると、のちのち顧客の数だけ発見される表面的な課題の違いに対応するためプロダクトの規模が大きくなります。なぜなら、作った機能で契約を増やしたいからです。

この顧客は大切だから

一度契約できた顧客から、新たな機能のリクエストが届くことがあります。たとえば、チャットツールと連携したいからAPIを公開してほしいといった感じです。プロダクトに対する顧客のコミットメントレベルは異なっており、また、企業の戦略上の重要な影響力を持つ顧客が存在します。たとえば、ネームバリューの高い顧客、新規市場で影響力を持つ顧客や規模の大きな企業の場合、顧客のコミットメントレベルが低ければ低いほどリクエストには契約を停止される不安がつきまといます。その場合、リクエストの優先順位は上がり、ロードマップに検討されます。

自律的に足並みを揃えるロードマップ

未検証機能がロードマップに検討されるシナリオを紹介しました。
顧客のフィードバックなどから分かる情報に合わせて、前提を見直しながらロードマップが現実に合わせて変化していけると効果のない計画を見直すことができます。

アウトプットを小さく効果を最大化する上で、ロードマップは足並みを揃えるガイドラインになります。
そのために、ロードマップでいくらかのオプションやプランBの分岐を検討して、時が来たら探索の結果から分岐の条件をできるだけ満たすように選んでいきます。
なので、ロードマップに書かれた機能は提供されないこともあります。
このように現実に基づいたロードマップは顧客のフィードバックや既知の知識に対応していて、なぜそのオプションを選んだのかをわかりやすくします。
そうすることで優れた選択肢を選べるように営業チームもプロダクトチームも関係なく情報を集める自律的な行動を促すことができます。
そのためには、営業で機能を約束するのではなく「あなたの欲しい機能は私達のプロダクトにありませんが、あなたの悩みを解決することはできます」という姿勢でコミュニケーションをすることが顧客からヒアリングするうえで大切になります。