「このサービスがこんな機能を出してるから、うちも出そう」 —— このような会話が社内で起こり、機能要件やUIデザインに落とし込まれる...。そういった場面に直面したことがある方は、多いのではないでしょうか？

市場が成熟してくるほど、類似のサービスやプロダクトは増え、競合企業への意識は高まります。

一方で、「競合企業がやっているから」はプロダクト計画に対して妥当な理由なのでしょうか？

「競合企業がやっているから」は根拠として弱い

プロダクトの計画やロードマップを引く際に、「類似の企業がやっているから」は十分な根拠にはなり得ません。

なぜなら、以下の可能性を考慮できていないためです：

1. ユーザーにとっての比較対象が、類似サービスとは限らないため

2. ユーザーが、類似サービスと比較していたとしても、該当機能があることが価値になるか不確実なため

どちらの点も、根本には「ユーザー (顧客) の比較軸を踏まえた意思決定ができているか？」という問いがあります。

競争優位性は、「他社と比べること」自体よりも、「他社と比べて、ユーザー (顧客) に選ばれる」ことの方が重要であるにも関わらず、比べることにばかりフォーカスされてしまいがちです。

「類似企業がやっているから」だけを根拠にロードマップや計画に落とし込むのは、「該当の機能や計画がユーザーにとって価値にならず、売り上げにもつながらない可能性」を無視してしまっているのです。

このような状態で立てられた計画に対して、機能や施策単位でユーザーヒアリングやインタビューを行ったところで、そもそも"負け試合"であるため、売上や事業成果につながる可能性は非常に低くなります。

ユーザーの比較軸を見つける重要性

では、「競合がやっているから」ではない、より良いプロダクト計画の根拠とは何なのでしょうか？

答えはユーザーの比較軸の把握にあります。

類似企業や競合といった「企業視点での比較軸」ではなく、ユーザーや顧客が自社と比較しているものを捉えていく「ユーザー/顧客にとっての比較軸」を見つけることが重要です。

そして、ユーザーや顧客にとっての比較軸は、いくつかのパターンに分けられます。

1. シーンでの比較

2. カテゴリーでの比較

3. 金額での比較

1. シーンでの比較

この比較軸は、「ある場面において、どんな選択肢をユーザー / 顧客が持っているか？」といった、シーンを起点に比較が行われる場合です。

たとえば、あなたが久しぶりに会う友人を誘って、ディナーの場所を考えているシーンを想像してみてください。

ディナーの選択肢として、何を思い浮かべるでしょうか？例として、以下のような選択肢が思い浮かんだと仮定します。

1. 久しぶりに会うんだし、奮発して高級イタリアンで食べる案

2. 積もる話もあるだろうし、あえてガヤガヤした居酒屋などを選ぶ案

3. おいしさ重視、お互いが好きな中華が食べられるお店にする案

ここで重要なのは、企業側（プロダクトを提供する側）は、この選択肢の中の、さらに1つのお店にすぎないということです。

あなたのプロダクトがイタリア料理店だとすると、ユーザーは他のイタリア料理店と比べているわけではなく、全く別の選択肢である、居酒屋と比べている場合があるということです。

その状態で「他のイタリア料理店には、ピザ窯がある。うちにはない機能である。つくるべきだ！」といったプロダクト計画が間違いであることは、火を見るよりも明らかです。

また、実際の例として野球球団「楽天イーグルス」の立ち上げも、シーンを起点に事業を立ち上げた素晴らしい事例です。ヤフーのCEOも歴任された小澤 隆生氏は、球団立ち上げ時に居酒屋の調査を徹底的に行ったそうです。

ナイターの19時〜21時の間は、ユーザーにとって「居酒屋・カラオケ」が有力な選択肢であると知り、居酒屋に行っている理由などを徹底的に調査したと言われています。結果として、通常の球場やスタジアムにはない「対面シート」を設け、多数の動員を実現、球団運営は初年度で黒字化するという、驚異的な実績を残しています。

シーン起点の比較は、決してC向けサービスだけでなく、BtoBのサービスやプロダクトにおいても、同様のことが起こります。「チャットを返そうとしたら、別の作業をしていた」などは、同じシーンにおいて複数の選択肢がある良い事例です。

2. カテゴリーでの比較

次の比較軸は、あるカテゴリー（市場）の中で比較されるパターンです。すでに成熟した市場に多くみられる比較軸になります。

例えば、あなたの会社で、新たに社員の採用を進めることになりました。その際に、あなたが検討する選択肢は何でしょうか？

1. とりあえず、採用募集を出してみる？

2. いやいや、狙い撃ちで最初からスカウト送る方がいいかも？

3. まずはコストかけずに、知人や友人に声をかけるリファラル採用では？

このような選択肢が思い浮かぶかもしれません。さらに議論が進むと「スカウトサービスの中で何を選ぼうか？」という話にもなるでしょう。

ここで重要なのは、対象ユーザー / 顧客の検討状況や、知識度合いによって「どんなカテゴリーで自社サービスを捉えているか？」は変わってくるということです。

あなたがスカウトサービスを運営しているとしたら、比較されているのは別のスカウトサービスだけでなく、他の採用のアプローチかもしれません。

自社視点でカテゴリーを説明するのではなく、ユーザー / 顧客の言葉でカテゴリーを説明できるようになることが、有効なプロダクト計画の第一歩です。

また、B向けサービスの例を取り上げましたが、日常生活においても「今週は仕事もがんばったし、ギルティなもの食べたいな〜」という際の「ギルティなもの」も立派なカテゴリーだと言えます。

3. 金額での比較

シーンやカテゴリーでの比較のほかに、金額で比較されるパターンも存在します。これはゲームや化粧品、嗜好品などの、可処分所得の使い道を考える際によく出てくる比較軸です。

例えば、あなたが漫画アプリを読んでいるユーザーだとします。おもしろい漫画を見つけて、続きが見たくなってきました。続きを見るためには、500円程度の課金が必要です。ここであなたの頭の中には、いくつかの選択肢が出てきます。

1. このまま課金して続きを読む

2. でもちょうど化粧水も切れるし、今度はちょっと良い化粧水を買いたい

このように、「漫画アプリの課金vs少し良い化粧水」の構図になっている場合もあります。この場合、ユーザーは同じ漫画アプリで比較して課金を決めているわけではないのです。

ユーザー / 顧客が何と比較してお得感があるかどうかを感じるか、に対してのインサイトを得ることで、適切なプライシングに反映できます。そして、プライシングに対して見合うプロダクト計画を引くことが可能になります。

選ばれ方の戦略 = プロダクトロードマップ

ここまでプロダクト計画を類似企業に基づいて決めてはいけない理由を挙げてきました。

• ユーザー / 顧客は、あなたが意識するライバル企業とあなたの企業を比べているとは限らない

• そのため、ユーザー / 顧客にとっての比較軸を把握する必要がある

そして、比較軸を把握した後、特定の比較軸の中での「選ばれる理由」（バリュープロポジション）に落とし込む必要があります。

どの点で選ばれるか、という選ばれ方の戦略こそが、骨太なプロダクト計画を作り上げます。

明日から使えるプロダクト計画シート

プロダクト計画やロードマップを作り上げていく上で、単なる機能案の羅列では説得力がありません。

ユーザー価値を生み、売上に大幅に上げるような骨太なプロダクト計画は、以下の3ステップで導くことが可能です。

1. 発散フェーズ : インサイトデータと施策案のリストを作成

2. 収束フェーズ① : 1で作成したリストを評価

3. 収束フェーズ② : 優先度や時期のめやすをつける

まず発散フェーズでは、顧客インサイトと施策案の組み合わせをリストアップします。

このフォーマットのポイントは、単なる機能案・施策案のリストではなく、「顧客インサイトデータと施策案のセットでリストにする」ことです。

インサイトデータに紐づいていない施策は、不確実さが高いかアイデアだけが先行している可能性があります。

次に、収束フェーズとして、各リストに対してインパクトを評価します。

インパクトは、さらに分解して「対象範囲の広さ」と「影響の深さ」などに分けても良いでしょう。また、この時点でコストなどを見積もっても良いかもしれません。

最後に、時期・担当者などを入れて計画として完成させましょう。

チームに伝わりやすく共有するためには、プロダクト計画の前段として「大きくどこに注力するか？そしてそれはなぜか？」などの方針と一緒にまとめることで、さらに伝わりやすくなります。

プロダクト計画こそ、インサイトドリブンに決める

ここまでで「競合がやっているから」は、プロダクト計画の根拠として弱いことや、代わりにユーザー / 顧客の比較軸を見つけることの重要性について整理しました。

プロダクト計画やロードマップなどの意思決定が、そもそもユーザー価値と事業価値を生むものになっていないと、どれだけ機能単位でユーザーヒアリング等を行っても、"負け試合"になってしまいます。

つまり、「ユーザー/顧客からの選ばれ方戦略」とも呼べるプロダクト計画にこそ、顧客インサイトデータをうまく活用することが重要なのです。

プロダクト計画やロードマップなどの意思決定に、顧客インサイトを活用するためには、単発の調査ではなく、これまでのインサイトデータを集約し、俯瞰すること（インサイトマネジメント）が必要になります。

インサイトマネジメントによって、骨太なプロダクト計画を実現しましょう。