デジタルプロダクトの世界では、プロダクトディスカバリーがトレンドトピックになりつつあります。それはなぜでしょうか？そもそもそれは何なのでしょうか？そして、それについて知っておく必要があるのでしょうか？この記事では、プロダクトディスカバリーの基本から応用まで、幅広くご紹介したいと思います。
プロダクトディスカバリーとは何か？
プロダクトディスカバリーは、しばしばプロダクトデリバリーと比較して定義されます。
プロダクトディスカバリーは、何を作るかを決定するために行う作業を表し、プロダクトデリバリーは、生産品質のプロダクトを作り、ユーザーへ届け、メンテナンスするために行う作業を表します。
良いプロダクトディスカバリーは、意思決定プロセス全体を通じて顧客を巻き込みます。顧客インタビュー、ユーザビリティテスト、A／Bテスト、デマンドテスト、仮説テスト、カスタマージャーニーマッピング、エクスペリエンスマッピング、ストーリーマッピング、仮説マッピング、OKR、機会解決ツリー、インパクトマッピング、ジョブ理論、エスノグラフィ調査、顧客訪問など、私たちにはプロダクトディスカバリーに関連した数多くの戦術やフレームワークを持っています。
これだけ多いと、手法の量に圧倒されがちです。しかし、いずれにしても根本的な原理は単純です。プロダクトディスカバリーは意思決定のプロセスで、優れたプロダクトディスカバリーとは、そのプロセス全体を通じて顧客を巻き込むことなのです。
プロジェクトベースのディスカバリーを理解する
私たちの多くは、プロジェクトの世界で育ってきました。企業は、その年のプロジェクトやイニシアチブを調達するために、毎年予算編成のルーチンを行っています。これらのプロジェクトのほとんどは、「この機能を構築する」または「このプログラムを開始する」という形で、ソリューション領域で組み立てられています。
プロジェクトには、始まり、中間、終わりがあります。通常、本番環境にコードをリリースしたら、プロジェクトは終了となります。多くの場合、プロジェクトはビジネス上の利害関係者や顧客、場合によっては実装しているプロジェクトチームによって提供されます。
運が良ければ、プロジェクト開始時に顧客調査を行うこともあります。その場合は、通常、プロジェクトベースのリサーチという形で行います。半ダースから1ダースの顧客にインタビューし、学んだことをまとめ、リサーチデッキにまとめて発表します。プロジェクト中は、（覚えていれば）そのデッキを頼りにします。プロジェクトの終わりには、ユーザビリティテストによるデザインの有効性検証や、A／Bテストによる最終的なデリバリーの検証を行うこともあります。
もちろん、プロジェクトの成功を評価することも忘れてはなりません。しかし、ソリューション領域でプロジェクトを始めてしまったら、成功がどのようなものかを常に知っているわけではなくなってしまいます。私たちは往々にして、ソリューションが解決しようとする問題やビジネスに与える影響を定義するために、前もって時間をかけることはほとんどありません。そのため、成功の定義を「動作するソフトウェアをデリバリーすること」とすることが多いのです。
プロジェクトの世界では、プロダクトディスカバリーの決定のほとんどは、毎年の予算編成の過程でビジネス関係者によって行われ、私たちのプロダクトディスカバリー活動は、プロジェクトベースのインタビュー（専用フェーズで行うインタビュー）と検証調査（ユーザビリティテストやA/Bテスト）に限定されています。
継続的ディスカバリーの必要性
しかし、優れたチームは、デジタルプロダクトに完成はないことを認識しています。常に反復し、改善することができるのです。FacebookやNetflixは、決して完成されたプロジェクトではありません。もし、彼らが反復と開発をやめたら、競合他社が追いついてくるでしょう。例えば、Netflixは、DVDの郵送サービスから始まり、映画のストリーミング配信へと変化し、今では独自の番組を制作しています。また、数え切れないほどの新機能をリリースし、レコメンデーションエンジンを改善し、ユーザーインターフェイスを向上させてきました。
優れたプロダクト・チームは、常に顧客のためにより多くの価値を創造し、ひいてはビジネスの価値も創造できることを知っているのです。このような考え方の転換は、しばしば「プロダクト思考」あるいは「プロダクトマインドセット」と呼ばれます。
プロジェクトベースのリサーチが本質的に間違っているとまでは言いませんが、顧客に継続的に価値を提供するチームにとっては、それだけでは十分ではありません。重要な考え方は、次のように単純なものです。「何を作るかを継続的に決定するのであれば、顧客と継続的につながり、プロダクトディスカバリーの決定が顧客のために機能することを確認する必要がある」ということです。
デジタルプロダクトを作るとき、私たちはプロダクトに関する専門知識を身につけます。プロダクトの機能、インターフェイスの位置、動作など、すべて自分たちが決めたことだからです。しかし、顧客はこのような専門知識を共有していません。
プロダクト担当者は、"知識の呪い"と呼ばれるバイアスに悩まされています。プロダクトに関する専門的な知識を身につけると、その知識を身につける前がどうだったかを忘れてしまうのです。そして、その知識を持たない顧客がどのような状況にあるのかを想像することができないのです。
このことは、顧客からのインプットを得ずに日々のプロダクトディスカバリーの決定をする際に、大きな問題となります。私たちは、専門家の視点から決断を下し、必ずしも顧客のためにならない決断を下してしまうのです。
しかし、このような事態を避ける、簡単な方法があるのです。
顧客と関わるたびに、私たちがプロダクトについて考えていることと、顧客がプロダクトについて考えていることの間にあるギャップが見えてくるのです。ほとんどのチームは、このギャップに直面すると、それを克服するために懸命に努力します。優れたプロダクト開発チームは、少なくとも毎週一回は顧客と関わり、顧客の意見なしに行う意思決定の数を最小限に抑えるのです。
なお、プロダクトディスカバリーの進化については、こちらで詳しく解説しています。
プロダクトディスカバリーの基本的な構造
デジタルプロダクトに終わりがないことを認めることから始めて、自分たちの仕事を再定義しなければなりません。こうなるともはや、プロジェクトはただ単にデリバリーすればよいというような単純なものではなくなるのです。プロジェクトマインドセットからプロダクトマインドセットへ移行するためには、単にアウトプットを提供することだけに集中してはいけないのです。そのアウトプットがどのようなインパクトをもたらしたのか、という観点を忘れないことが重要です。このとき、インパクトの大きさは、成果で測ります。
優れたプロダクト開発は、明確な成果の定義から始まります。
ビジネスリーダーは通常、チームにビジネス上の成果を出すよう求めます。ビジネス上の成果とは、ビジネスの健全性を測るもので、通常は財務指標（顧客獲得数の増加、解約率の低下など）や戦略的イニシアティブ（マーケットシェアの拡大、サービス提供国の拡大など）に対する進捗を測定するものです。
これらの成果を、プロダクトチームがプロダクト上の成果へと変換する必要があります。ついで、プロダクトの成果を、プロダクトがどの程度、特定のビジネス成果をサポートしているかという観点で測定します。それは、プロダクトで発生する顧客の行動を測定するもので、チームはそのプロダクト成果がビジネス成果の先行指標であるかどうかについては半信半疑の状態です。プロダクト成果の測定によって、プロダクトチームがどのようにビジネス価値を創造できるかを可視化しましょう。
追うべきプロダクト成果が一度選択されると、プロダクトチームは機会空間をディスカバリーする必要があります。機会とは、顧客のニーズ、ペインポイント、および願望を表しています。機会空間は無限です。チームの目標は、プロダクト成果を推進する可能性のある機会を発見することです。機会は、チームがどのように顧客価値を創造できるかを表しています。
そして最後に、チームはその機会に対応するソリューションも発見する必要があります。ソリューション空間もまた無限大です。
優れたプロダクト開発には、シンプルな基本構造があります。成果から始まり、機会を発見し、解決策を発見しましょう。
しかし、シンプルだからといって、簡単だというわけではありません。プロダクトチームは、反復して学習しながらプロダクトディスカバリーの基本構造を見失わないようにするために、機会解決ツリーを使用することを推奨します。
週次プロダクト・ディスカバリー
優れたプロダクトディスカバリーチームは、「顧客へのインタビュー」と「仮説検証」という2つの重要な活動を毎週行っています。インタビューは機会を発見するのに役立ち、仮説検証は解決策を発見するのに役立つのです。
顧客へのインタビューでは、顧客のニーズ、ペインポイント、欲求（これらを総称して「機会」と呼ぶ）をディスカバリーし、それらに対処すれば成果を上げることができることを目指します。機会は、顧客のストーリーから生まれます。
ただし、顧客に何が必要なのか、何が欲しいのかを単純に尋ねることはできません。認知バイアスが、顧客がこれらの質問に確実に答えることを妨げてしまうからです。その代わりに、具体的なストーリーの中でニーズ、ペインポイント、要望を聞き出すことが必要です。
また、機会空間は常に進化しています。新しい競合他社が市場に参入してきます。新しいテクノロジーが破壊的な可能性もあります。私たち自身のコードのリリースでさえも、機会空間の変化を引き起こします。優れたプロダクトディスカバリーチームは、このような絶え間ない変化を把握するために、インタビューを毎週行います。
ソリューションのディスカバリーに関しては、多くのチームがプロジェクトリサーチに頼っています。彼らは、完全な形のソリューションプロトタイプテストを行うか、A／Bテストを実施して影響を把握します。前者の完全なソリューションを用いたプロトタイプテストでは、正しいプロダクトを設計しているかどうかを知る前に、すべての設計作業を前もって行う必要があります。対して、A/Bテストでは、ソリューション全体を構築してから、構築するプロダクトが正しいかどうかを判断する必要があります。私たちは、自分たちが正しい道を歩んでいるという証拠を得る前に、このような作業をすべて行うことはしたくありません。
そうではなく、どのソリューションが有望かを素早く理解するために、簡易な仮説テストを使用することができます。このときの「仮説」は、望ましい、実行可能、実現可能、使用可能、倫理的の5つのカテゴリに分類されます。優れたプロダクト開発チームは、ストーリーマップを使用して、隠れた仮説を素早く発見することを実現させています。ストーリーマップは、顧客がソリューションから価値を得るために何をする必要があるかを示しています。そして、プロダクトチームは、各ステップについて、"顧客がこのステップを実行するためには、何が真実である必要がありますか？"と尋ねながら、マップの中を歩くことができます。この演習は、5つのカテゴリーすべてにわたる仮説を生成するのに役立ちます。
特定の瞬間を仮説したプロトタイプテスト、一問一答式アンケート、データマイニング、リサーチスパイクなどを用いて、仮説を迅速に検証することができます。それぞれのタイプの仮説テストについては、拙著『継続的発見の習慣』で詳しく解説しています。
また、仮説テストを行うことで、異なるソリューションを互いに比較対照するために必要なデータを収集することができます。
誰がプロダクトディスカバリーを行うのか？
プロダクト・トリオは、典型的にはプロダクト・マネージャー、デザイナー、ソフトウェア・エンジニアで構成され、プロダクト・ディスカバリーをリードします。しかし、だからといって、他のメンバーがこれに貢献しないわけではありません。プロダクトチームは、意思決定の種類に応じて、さまざまなメンバーを引き込む必要もあるのです。
プロダクトトリオは、顧客に共同でインタビューする必要があります。仮説検証を共同で行い、実行するのです。これらは、良いプロダクトディスカバリーのための重要なインプットです。
プロダクトトリオがどのように連携してプロダクト開発をリードするかについては、このビデオシリーズをご覧ください。
「体験とデザイン、スタートアップについて」の更新情報は、ぜひこちらのアカウント（@hrism2）をフォローしてください！
— 石丸治樹 (@hrism2) May 30, 2022
