顧客フィードバックをプロダクト開発に活かす方法、あるいはPdMと仕事をする時のコツ
プロダクトを作るとき、セールスやCSの人間がお客様からのフィードバックを頂くことはとても大事です。ただ一方で、プロダクトマネージャーやエンジニアなど開発チームに伝える際に「何言ってんだこいつ…」的な会話になってしまうのはプロダクト開発あるあるです。
これはなぜ起きるのかと言うと、ひとえにプロダクトの見方が違うからです。仕事のプロトコル（様式）が違うからとも言えますが、いずれにしろ自分の仕事にもとづいた観点でしか話せないことが大きな原因です。
なので、どうすればお客様のフィードバックをもとに課題を解決する機能ができるのか？をプロダクトマネージャーでない人がプロダクトマネージャー・エンジニア・デザイナーに伝えるときに役立つテンプレートをまとめてみました。
セールス・CSが求める機能がなぜリリースされないのか？
お客様からフィードバックがあったから機能実装しました！となっても
「あれ、求めてたのコレジャナイ…」
という経験はありませんか？
なぜこういうことが起きるのか？おそらくプロダクトマネージメントの世界で最も有名なこちらのイラストを元に解説していきます。
一番左上：お客様からのフィードバック内容
一番右下：実際にお客様が求めていたもの
それ以外：各関係者がそれぞれイメージしたもの
このように、ユーザーが実際に言っている内容をそのまま伝えたとしても、ユーザーが「これじゃないんだよな…」となることすらありえます。なんて理不尽なんだ！と思いますか？僕もそう思います（笑）
しかし、これはプロダクトを作るうえで世界中でよくある日常です。お客様は自分の本当にほしいものは分かっていないのです。
フォード自動車の創業者であるヘンリー・フォード氏の有名すぎる名言もそれを裏付けています。
もし顧客に、彼らの望むものを聞いていたら、彼らは「もっと速い馬が欲しい」と答えていただろう。
事例：お客様の声を鵜呑みにして失敗した「サラダマック」
ここでITプロダクトではないですが、お客様の声を鵜呑みにして大失敗した、個人的に好きな事例をご紹介します。
今でこそ業績好調なマクドナルドですが、かつて業績低迷していた時の改善策として打ち出したのが「サラダマック」でした。当時マクドナルド社はお客様からの意見を集め、その結果ユーザーはこう言いました。
「身体にいいヘルシーなハンバーガーが食べたい！」
なるほど、世は空前のヘルシーブームなんだな！よしきた！当時の製品企画の担当者さんはこう思ったはずです。もっと低カロリーで野菜多めなハンバーガーを出せばきっと売れるはずだと。その結果出てきた新商品サラダマックがこちらです。
なんて健康そうなんでしょう！素敵！そう思うのも無理はありません。しかし結論から言うとサラダマックは全く売れませんでした。実際に売れたのはこちらです。
そう、世の人は実際言っていることと真逆の1つ700キロカロリーを超える「メガマック」が空前の大ヒットになったのです。発売された2007年2月の売り上げは前年比12%以上も増え、日本マクドナルドでは数度にわたって期間限定販売を実施したほどでした。
このことから分かるようにお客様は建前で本音じゃないことを平気で言うのです。おまけに、自分では本音じゃないことを自覚しないまま。これがセールス・CSの人間がお客様の求めるものを間違える理由です。誰もマクドナルドに健康なハンバーガーは求めていなかったのです（そのポジションはサブウエイやフレッシュネスバーガーがありますし）。
そういう意味では、お客様が本当に求めるものを追求するのがセールス・CSの腕の見せ所であり、プロダクトマネージャーにとっても「この機能で本当に良いのか？」と健全に疑うスキルは良いプロダクトを作るためには必ず必要になります。いかにお客様の声を鵜呑みにしてはいけないかお分かりいただけたでしょうか。
お客様が本当に求めているものを突き止める考え方
では、どのように考えれば良いのでしょう？例えば、Slackの中の人になってみて考えてみます。お客様から、
「通知をグルーピングする機能がほしい！通知が多くてうざい！」
というフィードバックをもらったとしましょう。この時に鵜呑みにして
「通知を減らせ！グルーピングすれば解決だ！」
となってはいけません。
お客様の本音の仮説としては、以下のように考えます。
通知が多くて困っている
参加するチャンネルが多すぎるのでは？
自分があまり投稿しないチャンネルは抜ける方が使いやすいのでは？
通知ではなく参加チャンネルを減らしてみよう
参加チャンネルから抜けるリマインド機能を作ってみよう
となり、出てくる新機能が
× 通知のグルーピング機能
◯ 使ってないチャンネルを減らすリマインド機能
となり全く異なる機能がリリースされます。
もちろんこれは仮説の上の仮説にすぎませんし、実際には通知のグルーピング機能もSlackにはあります。ただ実際にSlackには使っていないチャンネルをリマインドして抜けるように導線を用意しているので、あながちずれていないのではないかと思っています。
お客様へのフィードバックをプロダクトマネージャーに伝える方法（簡易PRDの書き方）
今回はプロダクトマネージャーが一般的に書くようなPRD（プロダクト要求仕様書）ではなく、お客様の課題が分かる書き方を解説していきます。プロダクトマネージャーが書く粒度でPRDを書けと言うのが無理な話なので、現実的に可能な範囲でこれくらい具体的に書いてもらえると、プロダクトマネージャーとしては非常にやりやすく、求めているものと実際にリリースされたものが全然違う問題が起こりにくくなるはずです。
PRDテンプレート
1. 解決したい課題（今の問題）
（例）通知が多くてうるさいとフィードバックがあった
2. 達成したい状態
（例）通知をうるさいと感じない形で届けたい
3. 検証したい仮説
（例）通知が多いかも？または関連してないものが通知されているかも？
4. 顧客フィードバックのスクショ、メモのURLなど
（例）Zoom、議事録などのURL
書き方のポイントとして、要するに
× 何を開発するべきか
◯ どういう課題が発生して、どういう状態にしたいと思っているか
を伝えるようにすることをおすすめします。実際に何をどういう仕様で開発するかは専門家であるプロダクトマネージャーの仕事ですので、今の状態を伝えるに留めておきましょう。
このように、お客様の声をプロダクト開発に関わるメンバーで議論し、何が必要か、プロダクトとして何を解決するべきかをしっかり話し合うことで、本来やるべきでない機能を開発してしまったり、機能リリースをしたけど全然使われなかったりという事態を避けやすくなります。実際にはこれはすべて仮説の議論なので誰でもハズレを引く可能性はあるのですが、打率は挙げられるはずです。
おわりに
プロダクト開発においてお客様が求めていないものを作ってしまうと誰も幸せになりません。お客様の声を聞き、かつ聞きすぎないように良いプロダクトを作っていってください！
記事の内容についてなどご意見あればTwitterでぜひツイートしてください。
この記事が気に入ったらサポートをしてみませんか？