顧客のニーズを「探求」するための3つのアクション
このnoteは、2022年9月20日に開催されたFlyle主催のウェビナーでの登壇内容を書き起こしたものです。
イベントタイトルは「深いドメイン知識が求められる製品で、PMは顧客ニーズの発見にどう向き合ったか？」。ドメインエキスパートと協力しながらどのようにプロダクトディスカバリーを実践したか？自身が利用者になり得ない中、どのようにその壁を乗り越えたか？というテーマでした。
そして私からは「顧客のニーズを『探求』するための 3つのアクション」というタイトルでお話をしました。
お話ししたこと
0.はじめに
現在私はファーストアカウンティングというスタートアップで、UIデザイナー兼プロダクトマネージャーという役割で働いています。社内でPMは1人という体制でした（2ヶ月前からPMMの方が新たにジョインしてくれ、現在は2名体制です）。
プロダクトの顧客は「エンタープライズ企業の経理部門」になりますが、私は経理の経験・知識を持っていません。そして私たちが提供しているのは2021年6月にローンチされたまだ“1歳ちょっと”のプロダクトです。
そんな中で、ドメインエキスパートの協力を得ながら、どうやって顧客のニーズを探求してきたか…というお話になります。
1.業界トレンドの把握
新しい法律の対応や、業界の新たな仕様の策定…どんな業界でもトレンドとなるトピックスはあると思います。当然顧客の関心も高く、そのトレンドに対応したいというニーズがあります。一方で顧客自身も何をするべきか悩んでいることも多いのではないでしょうか？
「（法的な）要件を理解する」だけではなく「顧客が何に悩んでいるか？」を、ドメインエキスパートと連携し理解していくことがPMに求められていると考えます。
そのとき特に大事になってくるのは、特に次の2つを先回りして考えることです。
想定されるユースケース
課題となりそうなこと
新しい法律や仕様が始まることで、どのようなオペレーションが増え、何が課題となるのかを先回りして考える。このことで、これらを解決する要件をプロダクトへ盛り込むことができ、より便利に・より良い世界へ導けるプロダクトの実現に結びつきます。
そのためには、（私の場合は）法務や経理の方と話して「想定されるユースケース」を理解したり、CSや営業と連携し「課題となりそうなこと」を把握すること、そこから要件に導いていくことがプロダクトディスカバリーへの第一歩になっていくのです。
2.ユーザビリティテストの実施
toBプロダクトにおけるユーザビリティテストには以下の2つのメリットがあります。
エンドユーザーとの接点ができる
エンドユーザー自身が気づかない課題・ニーズがわかる
私たちプロダクト提供者が、顧客とのMTGなどでコミュニケーションを取るのは「カスタマー」であることが多いです。なのでユーザビリティテストは、実際にプロダクトを触る「エンドユーザー」との貴重な接点になります。
またユーザビリティテストを実施することで、エンドユーザー自身が気づかない課題・ニーズがわかることもあります。課題・ニーズも、顕在的なもの・潜在的なものがあると考えます。
顕在的な課題：ユーザー自身が把握しているプロダクトの課題。例えばユーザビリティ的に課題のあるもの。
潜在的な課題：ユーザー自身は課題だと感じていない・当たり前だと思ってしまっているが、第三者が客観的に見ると手間だと感じるもの。
顕在的なニーズ：ユーザーから「〇〇という機能が欲しい」と言われるもの。
潜在的なニーズ：顕在的なニーズを踏まえ、なぜそれが必要なのか？どんな業務の中で必要なのか？を考え導き出すもの。
顕在的な課題・ニーズを解決していくことも大事です。さらに一歩高みを目指すのであれば、潜在的な課題・ニーズを解決していくことが大切になってきます。
P.S. 「カスタマー」「エンドユーザー」の定義については、私の別のnoteにまとめているので、こちらもあわせてご覧ください↓
3.ユーザーストーリーマップの作成
私たちには以下のような課題が存在しました。
メンバーそれぞれの解釈で、顧客の業務フローを把握していた（認識がビミョーにバラバラだった）
いろいろなニーズがある中で、顧客の業務フローの中での各ニーズの立ち位置が分かりにくかった
これらを解消するべく、ユーザーストーリーマップを作成することになりました。
（なお上図は、オリジナルのユーザーストーリーマップから少し改変しているものです）
まずペルソナを洗い出し、そのペルソナごとにマップのシートを作っていきます。
次に上部にユーザーの行動（アクション）を時系列に並べます。
その行動に紐づく現在提供できている機能を並べ、最後に顧客のニーズを優先度順に並べていきます。
このことによって、
ニーズと業務フローがマッチすることで、ニーズの解像度が上がる
可視化されるので、業務フローや優先度への社内の共通認識が持てる
という効果が期待できます。
※ユーザーストーリーマップは現在まさに策定中なので、実際に運用してみた後の話は後日別のnoteとして紹介できればと思います。
4.まとめ
私たちが能動的に顧客のニーズを「探求」してきたアクションを紹介しました。一方で実際の案件は「顧客からの要望対応」も数多くあります。
「この機能がないと契約できません」
みたいなやつです。ただしこれが「悪」というわけではなく、むしろローンチしてから1年ちょっとのプロダクトが生きていくためには、大切な要望になります。
なので「要望」も「ニーズ」もあわせて、正しくプロダクトの価値に繋げていくことが重要になります。
さらに、特に私のように社内にPMが1名という体制の場合、ひとりでできることは限られてきます。目の前の案件の要件定義で精一杯…なんてこともしばしばです。
なので「チームでプロダクトマネジメントをやる！」ということが重要になってくると考えます。
ちょっとした裏話
8月にFlyleさんからイベント登壇のオファーをいただいたとき、実は2つの想いで揺れ動いていました。
「イベントに登壇して、PMとして活動している証を残したい」
「顧客ニーズの探索ができているのか？話すことなんてないのではないか」
プロダクトがローンチしてから1年ちょっと。プロダクトマネジメントをしている…と言っても「顧客からの要求案件」を多く対応していた印象が強くあり、能動的なニーズの探索という活動ができていないと感じていました。
しかし「イベントで喋りたい」という想いと、「きっと神様的な方が『ちょっと挑戦してみなさい』と言っているんだ」というセルフ暗示から、オファーを引き受けました。
そして登壇のコンテンツを考えるなかで、上述した3つのアクションとして紹介してきた活動を振り返ることができました。
「あっ、意外といろいろやってきたじゃん！」
という想いになりました（笑）
今までのキャリアの中でイベントへの登壇はすべてオンサイトでしたが、今回はじめてウェビナーへの登壇となりました。視聴してくださった方にとって何か一つでも持ち帰るものがあると嬉しいなと思います。
このような登壇の機会を与えてくださったFlyleの皆様にはとても感謝しています。ありがとうございました！
最後に、弊社ファーストアカウンティングに興味を持っていただけた方、私のような「デザイナー 兼 PM」「デザイナー出身のPM」の方、ぜひお話をさせてください。Meetyでお待ちしています。
いいなと思ったら応援しよう！
