なぜ「顧客フィードバックをストックすること」がプロダクト開発にとってプラスになるのか考えてみた
Flyleの荒井です。「フィードバックを一元化し、顧客ドリブンなプロダクト開発を実現する」というコンセプトで、プロダクトマネージャー（PM）やプロダクトマーケティングマネージャー（PMM）向けにFlyleというサービスを開発しています。
日々勉強中の身ですが、プロダクトづくりを通じて学んだこと・気づいたことアウトプットしていければと思います。今回は第一弾です！
この記事には「顧客フィードバックを価値ある状態でストックして、プロダクト開発に活用しようぜ」といった内容が書いてあります。
※ 全般的に BtoB SaaS をイメージして書いています
1. 顧客の声を聞く最大のメリットは「無駄な開発を避けられる」こと
2. 顧客フィードバックをストックし、課題の発見スピードを上げる
3. 顧客フィードバックをそのまま実現するのはリスクがある
4. フィードバックを集める際には、発言者は背景が重要である
顧客の声を聞くことで、無駄な開発を避ける
「プロダクト開発に顧客の声を活用すべきだ！」という声はあらゆるプロダクト開発の現場で耳にしますが、そもそもなぜ顧客の声を聞くことが重要なのでしょうか。様々な意見ががありますが、僕としては「無駄な物を作らないこと」が顧客の声をプロダクト開発に活かす最大のメリットだと考えます。
人や時間といったリソースが潤沢にある場合、「とにかく作ってリリース！→反応が悪ければその機能を捨てて新しく機能を作ってリリース！」とサイクルを繰り返すことで、いつかユーザーに刺さるプロダクトや機能にたどり着けるでしょう。
しかし実際の現場は、リソースは少なく、競合が日々プロダクトを進化させていくため時間的な余裕もありません。そのため、ユーザーにとって価値のあるプロダクト・機能をいかに無駄なく確実に届けられるかが重要です。
課題発見〜ソリューションを特定するまでの4プロセス
顧客に届けるべきソリューションを特定するまでには、大きく下記の4つのプロセスがあります。
①課題の仮説を立てる
②課題仮説を検証し、課題を特定する
③ソリューションの仮説を立てる
④ソリューション仮説を検証し、ソリューションを特定する
この中で「②課題を特定する」を間違ってしまうと、関連してその後のソリューションも間違ってしまうため、特に慎重に考える必要があります。
課題を特定するためには下図のようなサイクルを回していきます。
仮説が反証された場合、また新たに仮説を考える必要がある一方、質の良い仮説を立てることができれば、課題の特定までの時間を短縮することが可能となります。
ストックされた顧客フィードバックを活用し、課題発見の時間を短縮する
では、これらのプロセスにおいて顧客フィードバックがストックされている場合、何が嬉しいのでしょうか？
改めてになりますが、顧客フィードバックとしてには様々な内容があります。「毎回同じ検索条件を指定するので、検索条件を保存できるようにしてほしい」「ダッシュボードに表示できる項目をカスタマイズできるようにしたい」といった具体的な機能要望や、「表示までに時間がかかって使いにくい」「使い方がよくわからない」などの困り事がイメージしやすいのではないでしょうか。
先程の4つのプロセスの「①課題の仮説を立てる」において、以下に示す2つのアプローチを考えてみます。
①顧客起点の課題仮説：顧客要望をベースに、顧客が解決して欲しい課題の仮説を立てる
②戦略起点の課題仮説：ビジネス戦略をベースに、自分達が解決したい課題の仮説を立てる
「①顧客起点の課題仮説」において顧客フィードバックが有効であることは自明であり、顧客フィードバック収集を行っている組織の多くは「一定数要望があるから開発に踏み切ろう」という形で意思決定をサポートしているのではないでしょうか。
一方、「②戦略起点の課題仮説」を取る上でもストックされた顧客フィードバックをは貴重な情報となります。立てた課題仮説に対してどれだけの顧客がその課題を感じているのかを、過去のフィードバックを参照することで、ある程度課題の仮説を立証することができるためです。
仮に顧客フィードバックがない状態から「②戦略起点の課題仮説」の検証を行おうとすると、アンケート・ユーザーインタビューを実施したりとゼロから顧客の声を収集する必要があるため、課題特定までのリードタイムが長くなってしまいます。
顧客要望はそのまま実現せず、課題発見のヒントにする
注意しなければならないのは、具体的な要望をそのまま実現しないことです。よく言われていることですが、顧客が自分にとって本当に必要なものを理解し、言語化できるケースは多くありません（これに関しては様々な記事があるので深くは言及しません）。
実際には顧客のフィードバックをフックに、より詳細なヒアリングを実施することでより正しく課題を把握する必要があります。
顧客フィードバックを活用するために重要な情報
顧客フィードバックを収集する上で重要な情報があります。それは「①誰がフィードバックしたのか」、「②どのような背景でフィードバックしたのか」という情報です。
①誰がフィードバックしたのか
どの企業の誰が発言したのか、サービスを有料・無料で利用しているのか、組織でどのような役割を担っているのか、など、発言者の情報を付与することでフィードバックがどれくらい重要かを判断しやすくなります。例えば、ビジネス戦略が「エンタープライズ企業の満足度を向上させる」だった場合、「エンタープライズ企業からのフィードバック」は重要であると判断することができます。
一方、サービスを利用したことがない人から「こうしたほうがいいよ」とフィードバックされても何の参考にもなりません。誰が発言したか分からないフィードバックには注意が必要です。
②どのような背景でフィードバックしたのか
機能要望や困り事など、フィードバックにはその発言をするに至った背景が必ずあります。「どのようなシチュエーションでそう思ったのか」「1度だけなのか、何度も困っているのか」「あったら嬉しい程度の要望か or 無いと業務に支障が出るレベルの要望か」といった周辺情報を充実させることで、本当に顧客が課題に思っていることはXではなくYであることに気づくことができます。
また文脈から外れますが、誰かを経由したフィードバックを参照する場合には、実際の顧客の発言と聞き手の解釈を明確に分ける必要があります。「〇〇という顧客はXXという機能を欲しいと『と思う』」はあくまで聞き手の解釈なので、この情報を鵜呑みにして機能開発をするには大きなリスクがあります。
当たり前のように聞こえる内容ですが、ここまで意識してフィードバック管理ができている組織はあまりない印象です。
これらの2つの情報が満たされているフィードバックはプロダクトマネージャーが価値を感じられる「質の良いフィードバック」となります。
おわりに
「顧客フィードバックをストックすること」がプロダクト開発にもたらす価値についてお話させていただきました。実際に組織を巻き込んでこれらのプロセスを実践するのは簡単ではありませんが、一度回り始めると顧客が必要とする機能を継続的にデリバリーできるようになるはずです。
僕たち自身も、顧客の声をプロダクト開発に取り入れられるよう日々試行錯誤しています。また新たな学びがあれば今後も情報発信していければと思います。
最後は宣伝ですが、顧客フィードバックを有効活用するためのプロダクト「Flyle」を開発しておりますので、もし興味があればお問い合わせやトライアル利用をお待ちしております！
この記事が気に入ったらサポートをしてみませんか？