Rettyにおけるプロダクトディスカバリーのプロセス
ディスカバリーする内容によって差異はありますが、Rettyにおけるプロダクトディスカバリーのプロセスは、おおよそ以下のイメージです。
①ディスカバリーの対象を決める
前段として、ディスカバリーの対象を決めます。決め方としては、事業計画やプロダクトビジョンをベースにプロダクトとして実現したいことを考え、それを踏まえてディスカバリーするテーマを決めていきます。ボトムアップで始まることもありますが、大枠の方向性やスコープ、制約条件はトップダウンで決まっているのが理想です。
②既知・未知や因果を整理する
ソリューションを提供すべき顧客についての既知・未知の情報を整理します。
- 既知の既知「事実」：自分たちが既に知っていること。データから読み取れる明らかな事実。顧客課題とそれに対する打ち手が明確である状態。
- 既知の未知「疑問」：検証事項や調査すべきポイントがわかっている問題。ソリューションはまだ不明確だが、検証すべき問いが明確である状態。
- 未知の既知「直感」：長年の経験による直感。ソリューションが頭に浮かんでいるが、検証が不十分な状態。検証に基づかないため、時に思い込みが混じる恐れも。
- 未知の未知「発見」：自分が知らないことを知らない状態。何を検証すべきかも明確でない。
チームとして何が既知で何が未知であるかを明確に合意することが重要です。プロダクトディスカバリーにおいては、特に既知の未知「疑問」の解像度をチームとして高めるべきでしょう。どこまでが既知の既知「事実」として、明らかになっている事柄なのか。既知の未知「疑問」として、検証すべき問いやそのための検証設計は何なのか。顧客課題の洗い出しやグルーピング、顧客のオペレーションフローやカスタマージャーニーを作って指差し確認をしてみるなど。チームとして既知の未知の「疑問」を整理して、擦り合わせることが大事です。
弊社では、MiroやFigmaで整理しながらディスカッションしているシーンによく遭遇します。
（※1） 書籍『プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける』を参考に作成。
③問いを立てる
イメージしやすいように、コスメサイトの場合を例として挙げます（専門家ではないので、問いの良しあしは分かりませんが……）。
- ターゲット：Z世代
- 問い：新しいコスメを買う時、信頼するインフルエンサーや友達から選ぶ
このフェイズでは②で整理したことが非常に重要になります。
まずターゲットは正しいか、セグメンテーションが間違っていないか、その上でターゲットの解像度が高いか。もしこの段階で不十分な場合は③〜⑤を繰り返すことで、解像度を高めていく必要があります。
次に既知・未知が正しく問いに反映されているか。
例として挙げた問いでは「Z世代は広告を警戒している」「Z世代は誰かしら信頼するインフルエンサーがいる」「Z世代はマスメディアの情報より友達の評価を気にする傾向がある」のような情報が明らかな「事実」であり、その上で掲げた問いが検証すべき「疑問」である場合、質の良い問いと言えます。しかしもしZ世代について知識やリサーチで分かった事実が何もないのであれば、アイデアベースで解像度が低い「直感」的な問いとなります。
たとえ解像度が低かったとしても、未知であり、検証すべき「疑問」を開発チームが合意できていれば問題ありません。アンチパターンなのは、①検証すべき「疑問」を「事実」と誤認すること、②検証に基づかない「直感」的なソリューションを検証済みの「事実」と誤認すること、③未知であることを既知だと錯覚しているケースです。この場合、検証結果が正しく得られず、ソリューションの確度も低いものとなるのでしょう。「リリースしたら検証と違って市場から良い反応が得られなかった」という残念な結果を引き起こすことになります。
④問いを検証する
問いを確かめるための検証を設計し、実行します。
ここでの検証方法として、弊社ではデータ分析、ユーザーインタビュー、ユーザーアンケート、プロトタイプ検証などを活用しています。
⑤検証して既知になったことを整理する
②の時と同様に既知になったことを整理します。ユーザーインタビューの場合、KA法やKJ法を活用し、カスタマージャーニーとして整理する場合もあります。
③〜⑤を繰り返すことで、ソリューションの確実性を上げていきます（これらのプロセスに関して、詳しくは以降の連載をご覧ください）。
⑥デリバリーへ
ディスカバリーにより検証できたものは、順次プロダクトバックログに積んで開発していきます。
ここで難しいのは、どれだけ検証されれば十分なのかということです。これは求められるスピードや、失敗がどの程度許容されるのか、リソースがどのくらいあるのかによります。ケースバイケースではありますが、あくまで「事業計画や開発リソース観点で失敗を許容できるのか、スピードが問題ないか」「経営陣と開発チーム、そして開発チーム内で合意できているか」が判断の目安です。
