UXデザイナーやPdMこそ実践して欲しい継続的プロダクトディスカバリー
こんにちは！GoodpatchでUXデザイナーをしています田口です。
この記事では主にUXデザイナーやPdMの方向けに、私の頭の整理もかねてプロダクトディスカバリーについて書こうと思います。先日の記事に書ききれなかった部分になります。ぜひ合わせてご覧ください。
この記事で伝えたいこと
（１）継続的に顧客を巻き込み、素早く仮説検証を行うプロダクトディスカバリーを推奨したい （２）プロジェクトベースのリサーチではなく、プロダクトベースのリサーチが望ましい （３）ユーザーの声をひろうことを、一大イベントにせず、小さくFit&Refineを繰り返す （４）上記により、リリースしたものの、売れないリスクが軽減でき、PMFの角度が高くなる
プロダクトディスカバリーとは
『INSPIRED』の著者であるMarty Cagan は、プロダクトディスカバリーについて、顧客を巻き込み、素早く仮説検証を行うことで、顧客について解像度高く学習し、ソリューションを発見すること・またそのプロセスと説明をしています。（https://www.svpg.com/discovery-vs-delivery/ より意訳）
また、プロダクトディスカバリーの目的について、次の重要なリスクに対処することとしています。
・【価値のリスク】顧客はこれを買ったり、これを使うことを選んでくれるだろうか？
・【ユーザビリティのリスク】ユーザーはこれの使い方がわかるだろうか？
・【実現可能性のリスク】私たちはこれを作れるだろうか？
・【事業実現性のリスク】このソリューションは私たちのビジネスに貢献するだろうか？
なお、プロダクトディスカバリーと合わせて、プロダクトデリバリーについてもよく話題に上がりますが、図の整理がわかりやすいです。
ここまで説明すると、「なんだそういうこと？ユーザーリサーチくらいやっているよ」という印象を持たれた方も多いのではないでしょうか。実際、顧客の声を一度も聞かずにプロダクト開発しているお客様は少なくなってきた印象です。
一方で、注意したいのがプロジェクトベースのリサーチのみ行っているケースです。プロジェクト初期に行ったリサーチ結果を元に、あとはずっと仮説で議論を進めてはいないでしょうか。私自身も何度も経験してしまったこのパターンについて解説をしていきます。
プロジェクトベースのディスカバリーとその課題
図のように、プロジェクト初期フェーズのみでリサーチを行うことがプロジェクトベースのリサーチです。名前はどうでも良いのですが、初期段階ではリサーチを通じて、市場やユーザーの実態、ユーザーの課題を確認し、そこからコンセプトやビジネスモデル、ペルソナをアウトプットすることが一般的です。（もしここでユーザーの声を聞かずにプロダクト開発を行っている場合は、地図を持たずに目的地へ向かうようなものなので、ぜひユーザーリサーチを行いましょう）
もしここでリサーチを終え、その後数ヶ月、場合によっては半年以上、顧客の声を再度確認せず、初期のリサーチをもとにソリューション・機能のデザインをしているようでしたら、立ち止まって考えてみて頂きたいです。
プロジェクトの初期に行うリサーチでは、主にプロダクトの大方針/コンセプトの確認を行うことが多いですが、ここでの粒度と、提供するいちソリューション・機能を作る粒度では求められるレベルが異なります。
例えば私がよく活用しているフリマアプリを例にみてみると想像ですが下記のように整理できます。
このように、初期リサーチではプロダクトの大方針/コンセプトに関わる部分がリサーチクエスチョン中心になることが多いですが、その後、例えば「出品」「商品検索」のソリューション・機能を作るとなった際は、上記コンセプト段階よりもはるかに細かいレベルで、ユーザーの利用実態や課題における解像度を上げる必要があります。プロジェクト初期のリサーチでは当然そこまでの粒度で行うことはありません。そのため、プロジェクト初期のリサーチで分かった気にならず、ファクトに基づいてユーザーのフローや課題、提供価値、を整理してからソリューション・機能に落とし込むことが重要です。
なお、いきなりソリューション・機能だしを行うことはこの後説明をしますが、往々にしてユーザーをおいてけぼりにするのでおすすめしません。図のように、①利用シーンを洗い出し、②そこにユーザーの課題を整理し、そこに対して、③提供価値を整理してから④ソリューション・機能のアイデアだしをするやり方が良いかと思います。
ユーザーのファクトとして大事なのは①の利用シーンや、②の課題・ニーズですが、このようにまとめることで、まず自分自身やプロジェクトメンバーがユーザーのことをどこまでわかっているのか、またどこからわかっていないのかがわかります。この段階で仮説ではなく、ファクトがつかめていないようであれば、顧客を巻き込み素早く確認すると良いでしょう。
また、上記の整理はステークホルダーとの会話にも効果的です。意思決定ラインに乗っている上司からの「こんな機能があったら良いんじゃない？」という根拠の薄い思いつきでありがたくも困ってしまうケースや、関係者とソリューション・機能の議論をする際に、意図せず枝葉すぎるフィードバックや好き嫌いといった感性でのフィードバックを頂き、どう対処すれば良いか困ってしまうケースはあるあるだと思います。しかし、そこでも、ソリューション・機能→提供価値→課題・ニーズといった形で論点を明確にし、なぜそう思われたのかを確認することで、議論がしやすくなります。
プロダクトディスカバリーを行うべきシーン
さて、ここまで（プロジェクト初期に戦略部分でのリサーチを行った前提で）ソリューション・機能開発を行う際の話をしてきましたが、どのくらいの頻度で顧客を巻き込むことが良いのでしょうか。
書籍等をみると、週に1回は顧客に接点を持つと良いとの記載も少なくありません。個人的には実現できるに越したことはないですが、そこまでのレベルは現実的には難しいのではないかと思っています。手段が目的化してしまっても本末転倒ですので、期間を決めるよりは、必要性が生じたタイミングで素早く実施できる状態になっていること、また、「この部分の解像度が低いのでユーザーリサーチしたいね」といった声が日常的に組織の中で出てくると良い状態だと感じます。
一方で、全部をリサーチで判断していたら、コストもかかるしスピードが遅くなってしまいます。わからないことは基本的にすべて検証・調査をしないと決めたくない・決められないというPdMともプロジェクトを行ったことがありますが、このように極端すぎると推進力に欠けてしまいます。ポイントを抑えつつ、バランス感覚を持って進めていくことが大事ではないでしょうか。ちなみに私は、図のような状態を、顧客を巻き込み素早く仮説検証を行う一つの判断基準としています。ソリューション・機能の規模感や自身の解像度のレベルによって柔軟に判断していけると良いでしょう。
プロダクトディスカバリーの環境作り
最後に「プロダクトディスカバリーはわかったけど、なかなかその環境を準備することって難しくない？」という疑問にお答えできればと思います。
そうなんです、完璧にやろうとすると中々難しく、やっぱり無理だ、となってしまうこともあると思います。なので、はじめから完璧にやろうと考えず、「この取り組みプロセスの有用性自体も合わせて確認」くらいの気持ちで進められると良いと思います。また、”顧客”や”ユーザー”と記載してきましたが、営業やCSなど、顧客に近い方を巻き込むのも大いに良いと思います。大事なのはユーザー目線を取り入れ、進めていくことなので、身近でコストを抑えられる選択肢から考えていきましょう。（ただし、取得した情報を鵜呑みにせず、見極めるスタンスでいることが大事です）
まとめ
いかがでしたでしょうか。
継続的なプロダクトディスカバリー（継続的に顧客を巻き込み、素早く仮説検証を行うことで、顧客について解像度高く学習し、ソリューションを開発すること）の大切さは、ここまで読んでくださった方は理解いただけたと思います。一方で、最初にやってみることの心理的な、もしくは社内調整といった手間的なハードルがあることも認識しています。
ですが、数ヶ月・半年とプロジェクトを進めた後で、顧客とのズレが出てくると、そのリカバリーに多くの時間を費やしてしまいます。リカバリーできればまだ良いですが、組織の中では「ここまでつくってしまったからこれをどうにか生かす形で…」という、本質的ではない条件が加わってしまうこともよくある話で、一番苦しい思いをするのはPdMやUXデザイナーだと思います。そんなことが起こらぬよう、まずは「試しに」くらいの気持ちで一歩踏み出し、小さくFit&Refineを繰り返してみてはいかがでしょうか。
この記事が気に入ったらサポートをしてみませんか？