プロダクトディスカバリー入門 —— 開発した機能が使われない・伸びないを防ぐための打率思考
6 min
プロダクト開発
仮説検証
プロダクトマネジメント

プロダクト開発の現場では、限られた時間や人手の中で、顧客価値や売上を生み出すことが求められます。
スピーディな検証はもちろん重要ですが、なんでもかんでも「出してみて検証」のスタンスでは、リソースが足りない場面も多くあるでしょう。
そんな中で「打率を高めるためにはどうするべきか?」というプロダクトディスカバリーの考え方は、非常に重要です。
本ドキュメントでは、「うまくいくと思ってリリースしたのに、なぜか使われていない / 数字が伸びない」という状況を抱えるプロダクトチームのための処方箋を提供します。
まずは、打率を重視しないチームが失うものについて見ていきましょう。
プロダクトマネージャーや事業責任者が「とにかくリリースしよう」とスタイルを示すことは、スピード感が求められる現場ではよくあることかもしれません。
一方で、この一見勇敢なように見える「とにかくたくさん出す(ことでうまくいくだろう)」考え方には、2つのリスクがあることを認識する必要があります。
無駄なコスト(時間・カネ)が発生するリスク
チームが疲弊するリスク
機能開発にかかるコストを分解すると、大きく「かかる時間」「関わる人数」「1人あたりの報酬や給与」の3つに分けられます。

機能の大小やチーム規模など、さまざまな要素がある中で、あえて単純化して考えてみます。
1つの機能開発をするのにPMやデザイナー、エンジニアの合計5人が2ヶ月間取り組んだとします。計算しやすいように1人あたり月に50万円ほどの給与だと想定しましょう。
すると、1つの機能開発にあたって500万円ほどのコストがかかります。この機能が使われなかった場合は「500万円の勉強代を支払った」ということになります。

検証したい仮説の大きさや、検証方法によって500万円かどうかは変わるかもしれません。
一方で、「プロダクトの検証にはお金も時間もかかる」ということは間違いない事実です。
「とにかくリリースしよう」の影で、500万円の勉強代を払いつづけている可能性があることをまずは認識する必要があります。
また「とにかく出そう」をスローガンに、使われない機能を量産してしまうことには、チームに対して想像以上に負荷をかけます。

開発スピードの低下
プロダクトの複雑化
優先度のつけづらさ、共通認識のつくりづらさ
顧客への説明コスト
これらの負荷は、チームを疲弊させ、場合によっては離職や空中分解を誘発します。
チームの疲弊を招く原因は、プロダクトマネージャーや事業責任者が「プロダクト判断の遠心力を把握していない」可能性が挙げられます。
「ある機能をつくろう!」と考えるとき、特にデザイナーやエンジニアなど、リリースに近い人ほど、必要な判断の数は増えます。

機能のレイヤーでは1つの判断だったものが、要件になり、UI設計・仕様決定、実装...と進むにつれて「この場合の表示はどうすべきか?」「今回のスコープに入れるべきか?」など、多くの判断が求められるようになります。
つまり、1つの機能に関する判断をすると、無数の判断があとからついてくるという、「プロダクト判断の遠心力」を把握していないと、現場は振り回されているように感じ、中途半端なリリースが積み上がっていくのです。

では、プロダクト開発において打率を高めるために必要なこととは何なのでしょうか?
顧客へのインタビューやインサイトマネジメント、市場の理解などはもちろん重要であるものの、これらは手段にすぎません。
打率を圧倒的に高めるには、ある問いを、頻繁に、チーム全員で問いかけ合う必要があります。
その問いこそ「それ、本当?」という問いです。

プロダクトの判断は、リリースに近づくにつれて増えていきます。
どんなタイミングでも「この仕様や要件を入れるべきか?」などを考えるにあたって、「どこまでが求められているか?」「どう使われるだろうか?」などの議論が必ず発生します。
このような議論のあらゆるタイミングで、意識的に(そしてあくまで建設的に)「それって、本当に起こっている行動?」「それって本当に、ユーザーがやりたいこと?」と、事実を問うようにしてみましょう。思い込みや想像の場合は、実は多くあります。

実際のところ「ユーザーはおそらくこう動いて〜」と解像度が高い"風"に、うまく説明することは、ある程度の伝える力があれば可能です。
しかし、このような「それらしい説」を鵜呑みにしては、結局のところ打率アップにはつながりません。また、エンジニアやデザイナーなどが自律的な判断をすることも難しくなるでしょう。
伝える力はもちろん重要ですが、打率を高めるためには「それ本当?」を、議論し合える状況をつくることが必要なのです。
打率を高めるために必要な問いとして「それ本当?」を、あらゆるタイミングで議論するためには、常にこの問いに対して打ち返せる「顧客の事実」(ユーザーインサイト)が必要です。

本当かと問われるたびにインタビューや顧客訪問に行っていては、間に合いません。
しかし、本当かを確かめないまま思い込みで出すことは、上述した通りコストのリスクとチームのリスクの2つを負うことになり、持続的ではありません。
このトレードオフを超えるためには「いつでも打ち返せるような、顧客の事実がたまったハコ」を用意する必要があります。

インサイトマネジメントを実践することによって、このハコを用意することが可能になります。
参考 : インサイトマネジメントとは
このハコは、SSoT(Single Source of Truthの略)とも呼ばれ、「顧客の事実に関するデータベース」として、チームの自律的な意思決定を支えてくれるでしょう。
そして、このハコは、単なる議事録のまとめでも、ペルソナのシートの羅列でもありません。顧客のコンテキストや行動、思考、課題など、さまざまな「顧客の事実」を集めて、まとめ、チームの進む先を示してくれる、いわば顧客視点の羅針盤なのです。
先進的な実践例として、急成長スタートアップ「カミナシ」によるプロダクトディスカバリーの例もぜひご覧ください。
参考 : カミナシPdMに聞く、BtoBプロダクト開発でのインサイトマネジメント実践 (イベント動画)
プロダクト開発において「とりあえずリリース」には限界があり、多くのリスクがあること、そしてその対処法をご紹介しました。


そして、打率を圧倒的に高めるためには、手法よりも先に「それ本当?」という1つの問いが重要であり、この問いを繰り返しあらゆるタイミングでチーム内で議論すべき点について解説しました。


「それ本当?」に常にクリアに答えられるようにするためには、「顧客の事実のハコ」を用意することが必要です。

ハコがあることで、各職種は、自身の専門性をいかんなく発揮し、異なる専門性が1つの大きな顧客価値を生むようになるでしょう。
インサイトマネジメントによって、「顧客の事実のハコ」を用意することは、打率を圧倒的に高めるだけでなく、チームが自律的な判断をするための強固な基盤となります。
Centouでは、プロダクトディスカバリーをより効果的に行えるような、インサイト管理プロセスを提供しています。
打率を飛躍的に高めたい、リソースが少ない中で成果を出したい、スピーディだけど納得感を持った開発をしたい、そんなチームの味方がCentouです。
ご興味のある方は、期間限定の1on1フォームや、こちらのお問い合わせフォームより、お気軽にご相談ください。
Centouと一緒に
顧客理解のチーム化に
一緒に取り組みませんか?
インサイトマネジメントは、ユーザー理解から事業を伸ばしたいあなたの味方です。
「顧客の声は聞いているのに成果が出ない」「チームの認識がズレる、スピードが遅い」
そんなお悩みから解放され、顧客に向き合うほど事業が伸びるしくみを実現しましょう。

インサイトマネジメントについて
Centouについて
Copyright©alma, inc. All Rights Reserved.