SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

ProductZine Day&オンラインセミナーは、プロダクト開発にフォーカスし、最新情報をお届けしているWebメディア「ProductZine(プロダクトジン)」が主催する読者向けイベントです。現場の最前線で活躍されているゲストの方をお招きし、日々のプロダクト開発のヒントとなるような内容を、講演とディスカッションを通してお伝えしていきます。

ProductZine Dayの第3回。オフラインとしては初開催です。

ProductZine Day 2024 Summer

ProductZine Day 2024 Summer

思い込みで創らない。アウトカムを生むプロダクトディスカバリーへの挑戦

組織で取り組むプロダクトディスカバリーのプロセス

思い込みで創らない。アウトカムを生むプロダクトディスカバリーへの挑戦 第2回

 前回は、Rettyがプロダクトディスカバリーに取り組む理由をアンチパターンとともにお伝えしました。では、具体的にはどのように進めているのか。この記事ではプロセスと組織体制、実際の事例をご紹介します。

Rettyにおけるプロダクトディスカバリーのプロセス

 ディスカバリーする内容によって差異はありますが、Rettyにおけるプロダクトディスカバリーのプロセスは、おおよそ以下のイメージです。

ディスカバリーの流れ
ディスカバリーの流れ

①ディスカバリーの対象を決める

 前段として、ディスカバリーの対象を決めます。決め方としては、事業計画やプロダクトビジョンをベースにプロダクトとして実現したいことを考え、それを踏まえてディスカバリーするテーマを決めていきます。ボトムアップで始まることもありますが、大枠の方向性やスコープ、制約条件はトップダウンで決まっているのが理想です。

②既知・未知や因果を整理する

プロダクトディスカバリーにおける既知と未知
プロダクトディスカバリーにおける既知と未知(※1)

 ソリューションを提供すべき顧客についての既知・未知の情報を整理します。

  • 既知の既知「事実」:自分たちが既に知っていること。データから読み取れる明らかな事実。顧客課題とそれに対する打ち手が明確である状態。
  • 既知の未知「疑問」:検証事項や調査すべきポイントがわかっている問題。ソリューションはまだ不明確だが、検証すべき問いが明確である状態。
  • 未知の既知「直感」:長年の経験による直感。ソリューションが頭に浮かんでいるが、検証が不十分な状態。検証に基づかないため、時に思い込みが混じる恐れも。
  • 未知の未知「発見」:自分が知らないことを知らない状態。何を検証すべきかも明確でない。

 チームとして何が既知で何が未知であるかを明確に合意することが重要です。プロダクトディスカバリーにおいては、特に既知の未知「疑問」の解像度をチームとして高めるべきでしょう。どこまでが既知の既知「事実」として、明らかになっている事柄なのか。既知の未知「疑問」として、検証すべき問いやそのための検証設計は何なのか。顧客課題の洗い出しやグルーピング、顧客のオペレーションフローやカスタマージャーニーを作って指差し確認をしてみるなど。チームとして既知の未知の「疑問」を整理して、擦り合わせることが大事です。

 弊社では、MiroやFigmaで整理しながらディスカッションしているシーンによく遭遇します。

(※1) 書籍『プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける』を参考に作成。

③問いを立てる

 イメージしやすいように、コスメサイトの場合を例として挙げます(専門家ではないので、問いの良しあしは分かりませんが……)。

  • ターゲット:Z世代
  • 問い:新しいコスメを買う時、信頼するインフルエンサーや友達から選ぶ

 このフェイズでは②で整理したことが非常に重要になります。

 まずターゲットは正しいか、セグメンテーションが間違っていないか、その上でターゲットの解像度が高いか。もしこの段階で不十分な場合は③〜⑤を繰り返すことで、解像度を高めていく必要があります。

 次に既知・未知が正しく問いに反映されているか。

 例として挙げた問いでは「Z世代は広告を警戒している」「Z世代は誰かしら信頼するインフルエンサーがいる」「Z世代はマスメディアの情報より友達の評価を気にする傾向がある」のような情報が明らかな「事実」であり、その上で掲げた問いが検証すべき「疑問」である場合、質の良い問いと言えます。しかしもしZ世代について知識やリサーチで分かった事実が何もないのであれば、アイデアベースで解像度が低い「直感」的な問いとなります。

 たとえ解像度が低かったとしても、未知であり、検証すべき「疑問」を開発チームが合意できていれば問題ありません。アンチパターンなのは、①検証すべき「疑問」を「事実」と誤認すること、②検証に基づかない「直感」的なソリューションを検証済みの「事実」と誤認すること、③未知であることを既知だと錯覚しているケースです。この場合、検証結果が正しく得られず、ソリューションの確度も低いものとなるのでしょう。「リリースしたら検証と違って市場から良い反応が得られなかった」という残念な結果を引き起こすことになります。

④問いを検証する

 問いを確かめるための検証を設計し、実行します。

 ここでの検証方法として、弊社ではデータ分析、ユーザーインタビュー、ユーザーアンケート、プロトタイプ検証などを活用しています。

⑤検証して既知になったことを整理する

 ②の時と同様に既知になったことを整理します。ユーザーインタビューの場合、KA法やKJ法を活用し、カスタマージャーニーとして整理する場合もあります。

 ③〜⑤を繰り返すことで、ソリューションの確実性を上げていきます(これらのプロセスに関して、詳しくは以降の連載をご覧ください)。

⑥デリバリーへ

 ディスカバリーにより検証できたものは、順次プロダクトバックログに積んで開発していきます。

 ここで難しいのは、どれだけ検証されれば十分なのかということです。これは求められるスピードや、失敗がどの程度許容されるのか、リソースがどのくらいあるのかによります。ケースバイケースではありますが、あくまで「事業計画や開発リソース観点で失敗を許容できるのか、スピードが問題ないか」「経営陣と開発チーム、そして開発チーム内で合意できているか」が判断の目安です。

次のページ
PM・デザイナー・アナリスト主導でディスカバリー

この記事は参考になりましたか?

思い込みで創らない。アウトカムを生むプロダクトディスカバリーへの挑戦連載記事一覧

もっと読む

この記事の著者

野口 大貴(Retty株式会社)(ノグチ ヒロキ)

Retty株式会社 プロダクト部門執行役員 VPoP。 京都大学文学部卒業後、株式会社SpeeeにてWebマーケティングの コンサルタントやグローバル・メディアのWebディレクターを担当。2015年Retty株式会社に入社後、新卒採用責任者やWeb・アプリチーム マネージャーとしてプロダクトグロー...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

ProductZine(プロダクトジン)
https://productzine.jp/article/detail/1142 2022/08/08 14:00

おすすめ

アクセスランキング

アクセスランキング

イベント

ProductZine Day&オンラインセミナーは、プロダクト開発にフォーカスし、最新情報をお届けしているWebメディア「ProductZine(プロダクトジン)」が主催する読者向けイベントです。現場の最前線で活躍されているゲストの方をお招きし、日々のプロダクト開発のヒントとなるような内容を、講演とディスカッションを通してお伝えしていきます。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング