『リーン顧客開発』を読んで感じたこと

f:id:ShowGoTagami:20210207175723j:plain

この記事は「リーン顧客開発」を読んで、いちプロダクト開発者として感じたことをメモします。

まずこの本はスタートアップ/大企業、新規顧客/既存顧客どちらにも対応

この本の中盤まではインタビューの方法や仮説の立て方などにフォーカスしています。実際にケースをもとに語られており、とても具体的かつ分かりやすい内容です。

ただ、ふと思ったのは「あれ?これはスタートアップが新サービスを作るときに読む本なのかな?」ということです。

しかし、第8章は「既存顧客がいる場合の顧客開発」というテーマでした。ここからはスタートアップに限らず、既存顧客がいる場合のサービスにおける、顧客開発の話になります。このことから、本著は新規/既存に限らず、またベンダーの規模もスタートアップ/大企業どちらでも対応しているメソッドなのだと気付きました。

「素晴らしい製品を売ること」と、「製品によって顧客を素晴らしい気持ちにさせること」は違う

プロダクト開発をしていると、素晴らしい機能や、綺麗なコード、イケてるデザインをプロダクトの売りにしてしまいがちです。もちろんそれもサービスの優位性かもしれませんが、顧客にとてt大事なのは、製品を使うことで得られる"価値"です。

ここで「プロダクトマネジメント」の内容とリンクします。それはつまり、プロダクトそのものには価値はなく、そこからユーザーが得られるアウトカム・価値によって、初めてプロダクトに価値が生まれるというものです。

f:id:ShowGoTagami:20210207175738j:plain

つまり、重点をおくべきは製品の素晴らしさではなく、顧客を素晴らしい気持ちにさせることである、と本著では述べています。全くその通りだなと思います。

さらに一歩踏み込んで、「誰を素晴らしい気持ちにさせるのか」という点も非常に重要であると感じました。例えばSaaSプロダクトの場合、そのプロダクトを購入する人・意思決定する人と、そのプロダクトを実際に使う人は異なる場合があります。この時にわたしたちは"誰の" "どんな" 体験・価値にフォーカスすればいいのでしょうか。

間違った顧客開発

本来推奨される顧客開発も、間違った方向にいく可能性もあると述べています。

とある仮説に基づいてモックベースで作られた機能Aを重要顧客Xに見せながら、インタビューをするようなケース。その機能Aが素晴らしいものであるとXは思い、またそれが近いうちにリリースされるものと勘違いさせてしまうようなこともある、とその危険性を説明しています。

確かにインタビューの目的やモックの意図を十分に説明しないと、それは期待値の調整を誤って、不要な軋轢をうむキッカケになりかねません。

十分に顧客開発の意図や手法を理解していないとこのようなことになりかねない、と学びました。むやみやたらに「顧客に話を聞こう!」となる前にこうした危険性についても理解しておく必要があると思い知りました。

「意見」ではなく「事実」にフォーカスしている

少なくともリーン顧客開発に関しては顧客の「意見」よりも「事実」に重きを置いています。

「意見」とは例えば、、 - こんな機能が欲しい!これがあれば毎日でも使うよ! - ここをこうしてくれるともっと使いやすいな - もしこの製品がこういう機能があったら買うよ

のようなものです。これら全てに価値がない、とは言っていません。ただ、これらをそのまま鵜呑みにすべきではないということを本著では説明しています。

それよりも顧客が置かれている状況、プロダクトを購入するかどうかの意思決定基準やフロー、プロダクトが解決すべき価値に対してどのように行動しているかなどの客観的事実や価値判断の基準に重きを置いています。

このことについて本著では以下のような例を用いて説明しています。

一部の顧客がYammer(SNSプロダクト)のトプックタグの機能強化を要求してきたが、実際にこの機能を使い込もうとしたことがあるユーザーはわずかだった

これはプロダクト開発あるあるだなと"耳痛"なケースでした。

このケースで説明していたのは「将来ではなく、現在に注目する」ということでした。例えば誰かに「あなたは将来Xをするつもりですか?」と尋ねても、返ってくる答えは正確ではありません。子役から正確な答えを得るのに良い方法は、特定のイベントや意思決定のシーンにフォーカスして、質問を組み立て、現在・過去に注目することだと説明しています。

例えばあなたがTikTokのファンだとして、そのインタビューのなかで「将来、TikTokにこんな機能ができたら使いますか?」と尋ねられたとします。そのとき、(その機能があったら便利そうだな)とか(一回くらいは使ってみるかもな)という気持ちで「はい」と答えてしまうのではないでしょうか。少なくとも僕はそう答えると思います...。

このように、顧客の「意見」ではなくなるべく「事実」を掘り起こし、潜在・顕在ニーズを掘り起こすことが「顧客開発」の中心にある考え方だと感じました。

すでに「オフィスを飛び出している人」は誰か

まだ顧客開発を実施できておらず、その土壌を作る前の環境では、「継続的な顧客開発」が非常に有効な視点だと思いました。

具体的には、現在すでにオフィスを飛び出して顧客と接点を持っている人から始めるというものです。例えばカスタマーサポート、カスタマーサクセスまたやセールスメンバーなどです。

本著では顧客からの質問やバグ報告、また解約連絡などから顧客インサイトを得る方法を説明しています。

顧客X 「大勢の社員からあなたのプロダクトについての不満がでています。機能Yがないからです。」 CS 「ご迷惑をおかけし申し訳ありません。(あくまで顧客理解のためであることを丁寧に説明したうえで)その方々はなにができないことで不満を感じてられるのでしょうか?また、機能Yがあったらどのようにお使いになる予定でしょうか?」

このように顧客からの要望に対して、(丁寧に前置きをしたうえで)その背景にある事実を深堀します。

ただし、このときに注意しなければならないのは、問い合わせや営業の場に出てくる人の意見は、プロダクトを使う人のうち一握りである場合があるということです。そして、大抵は「サイレントマジョリティ(物言わぬ大多数)」であるということです。

もしも声の大きいマイノリティにばかり目を向けてプロダクト開発をしていると、わずか一部の人だけが満足するプロダクトになってしまい、残りの多くのユーザーは不満を抱えたまま静かにプロダクトを使わなくなります。こうしたバイアスが存在することを前提に、顧客と接している方は調査をすべきだと本著では説明しています。

明日から顧客開発をするならどうするか?

「リーン顧客開発」ではこれら以外にも具体的なインタビュー手法や、仮説の立て方など幅広いノウハウを説明してくれています。

では、明日からわたしたちが顧客開発を始める場合にどのようにこれらを進めていけばいいのでしょうか?(本著では残念ながらそのステップについては説明されていません...)

個人的にはいくつかのパターンがあると感じました。

(1) プロダクトや顧客基盤がない場合

この場合、「リーンスタートアップ」と合わせてプロダクトのニーズを探るところから始めるのが良いように感じました。そもそも課題があるのか?どんな課題があるのか?という仮説を顧客開発では必要としますが、その仮説を立てるための基盤は顧客開発とは異なります。

(2) すでにプロダクトがあり、顧客がいる場合

ゼロからこの本の内容を実践できる担当者(PMやPdMなど)がいる場合は、その方にまずは実践してもらうというのが良さそうだと感じました。プロダクトの方向性やプロダクトが解決する課題の仮説を持っている人が、それらを固めていくために顧客開発をステップ1とすべきだと思います。

もしもPMやPdMがこれらのタスクに取り組めない場合(本来的にはそれを説得すべきですが...)やあるいはその担当者がいない場合、まずは普段「オフィスを飛び出しているメンバー」と一緒にミニマム顧客開発を進めるのが好ましいでしょう。その後、数名のメンバーでインタビューの練習から実践を徐々に初めていき、チームとしての文化を作っていくと良いのかと思います。

セールス側としては顧客開発は一見デメリットの多いアクションに感じられるのかもしれません。なので、いきなりこれをえいや!で始めると反発が多く、また失敗の連発で本来目指していたこととは逆の方向性になりかねません。「プロダクトマネジメント」の中で語られている、セールス主導からプロダクト主導にするためにはこのような漸次的なステップが良さそうです。