Two-Side Platformにおけるプロダクト戦略の地味ジレンマ
はじめまして！現在、BASE株式会社に入社して２年ほどPMをやっている @yusakuと申します。
この記事は、地味PM Advent Calendar 2022 9日目のエントリーです。
（2日も遅刻しましたごめんなさい）
（言い訳：自社のアドベントカレンダーで、↓記事を書いていたので許してください）
はじめに
はじめに簡単に自己紹介させていただきます。
新卒でリクルートに入社し、SUUMOというサービスでアプリやスマホサイトのプロダクト担当として7年ほどPMを経験しました。昨年BASEに転職し、現在ではネットショップ作成サービス「BASE」のプロダクトチームのマネージャーをしております。
アドベントカレンダーを書くにあたっていままでの経験を振り返ってみました。いままで関わったプロダクトはどちらもTwo-Side Platform の プロダクトであり、リクルートではToC、BASEではToBを経験しています。なので今回はその両方の観点で特徴や、いままでたくさん葛藤した地味なジレンマについて言語化してみようと思い、記事にしてみました。
PMの方はもちろん、プロダクトに関わっている方やプロダクト戦略について考えられている方に読んでいただき、少しでも参考になれば幸いです。
Two-Side Platformとはなにか
まず、冒頭でお話させていただいたTwo-Side Platformについて説明させていただきます。
Two-Side Platformとは、供給サイドと需要サイドの両方が伸びることでマッチングが生まれ、事業が伸びる構造のモデルのことです。いわゆるリボン図型のモデルのことですね。
イメージしやすいように、サービスの具体例をそれぞれあげてみます。
例：不動産情報サービスの場合
供給サイドは、不動産屋さんで、需要サイドは家を探す人です。家を探したい人は、不動産屋さんが供給してくれた物件のなかから、自分にあった家を探すことができます。どちらか一方が増えるだけではだめで、両方が伸びてマッチングの数が増えることで事業が成長していきます。
例：ネットショップ作成サービスの場合
自分が作った商品商品を売っていく市場では、供給サイドはWEBサービスを使って自分の商品を売りたい方々のことです。その商品を買いに来る購入者の方々が、需要サイドと言えます。フリマアプリやオークションサイトなど中古品CtoCプラットフォームもこのケースにあてはまるでしょう。こちらのケースも先程の例と同様に、どちらか一方が増えただけではマッチングは増えないため、両方が伸びることが重要になってきます。
Two-Side Platformにおける地味ジレンマ
さて、いままでTwo-Side PlatformにPMとして関わっていて特に難しくジレンマを感じたのは、両方をバランス良く伸ばさないといけないにも関わらず、需要サイドと供給サイドで性質が大きく違うため、戦略策定が難しいことです。
供給サイドと需要サイドの特徴を、とても大雑把ですがまとめてみます。
対象とアプローチ
供給サイドはToB、需要サイドはToCであることが多く、それぞれに対してプロダクトとしてのアプローチ方法も変わってきます。まず需要サイドは、一定規模のユーザーに素早くプロダクトをリリースしてFBを直接もらうことで、フィードバックループを高速に回していくことが重要です。たくさんのABテストを回し、学びを貯めていくアプローチを取ることが多いです。
一方、供給サイドは、開発する前にできるだけ正確にユーザーの要望や課題を特定し、いかに最小限の開発コストでユーザーへの価値提供をしていくかが重要です。供給サイドの性質上、プロダクトが業務プロセスに直接影響があることが多く、リリースを外したときのリスクが大きいため、調査・分析・企画検討の比重が大きくなる傾向があります。
プロダクトの成果
プロダクトとして寄与しやすい成果も、両者で異なります。需要サイドのユーザーを増やすことができれば、PVや有料会員数、トランザクションなどを短期成果として売上に貢献しやすいです。一方供給サイドでは、供給を増やしても短期での成果になりづらいですが、受け入れられる法人クライアントが増えたり、魅力的に思っていただけるクライアントが増えるなど、中長期の事業価値を高めていくアセットになります。
目標管理の難しさ
個人の感覚としては、供給サイドのプロダクト開発は地味で長い開発になりがちな印象です。そのため短期目標を追うために供給サイドの開発の優先度が低くなることも多いのではないでしょうか。
とはいえ、需要サイドだけにリソースを割いても、一定のラインでマッチングは伸び悩むため、供給サイドがないと後から困ることになります。この性質の異なる両サイドのバランスを取るために適切なリソースを配分していくことが重要であり、それが非常に難しいジレンマなのです。
Two-Sideをバランス良く伸ばすプロダクト戦略とは何か
日々プロダクト戦略を試行錯誤する中で、両サイドのバランスをとった戦略にするためのポイントを2つほど言語化してみました。それは
①プロダクトがレバレッジする課題にフォーカスする
②両サイドの組織・目標を分ける
の2点です。それぞれについて補足していきます。
①プロダクトがレバレッジする課題にフォーカスする
ビジネスモデルや事業の状況によって、プロダクトによって成果が出せるポイントは異なります。そのため、両サイドのバランスを考える際にどちらにリソースを書けることで事業がレバレッジするのかという観点をもって戦略に向き合うことが重要です。
例：需要サイドがレバレッジするケース
こちらのケースでは、供給サイド側の交渉力の強さがポイントになってきます。もし、既存ユーザーとの関係性が構築できており交渉力が強い場合、最もプロダクトで成果が出しやすいのは需要サイドです。
不動産情報サイトの例に当てはめて考えてみましょう。需要サイドにリソースを強め、プロダクトのUXが改善されるとユーザーがより自分にあった家を見つけやすくなり、より多くのマッチングが生まれます。そして、供給サイドである不動産屋から見えるプロダクトがより魅力的になるため、営業組織がさらに売り伸ばししやすくなるという、循環を生むことができます。そのため、すでに供給サイドへの交渉力がある場合は、まず需要サイドへのプロダクト開発のリソース配分の重要度が高くなります。
例：供給サイドがレバレッジするケース
ポイントとなってくるのはプロダクト以外の打ち手です。たとえば、需要サイドはマーケティング施策などのプロダクト以外の施策でも伸ばせるケースもあります。その場合、プロダクトとして供給サイドにコミットしていくことが重要になります。
ECなどのプラットフォームでこの例を当てはめてみると、プロダクトの機能が充実すると供給サイドのユーザーを多く獲得できるようになり、より魅力的な商品が多く並ぶことになります。そして、重要サイドである購入者から見たプロダクトがより魅力的になるため、より多くのマッチングが生まれやすくなります。この場合では、供給サイドにちゃんと投資し続け、ユーザーの課題に向き合いプロダクトで課題解決していく重要度が高くなります。
自社のビジネスモデルや事業の状況、プロダクト以外の打ち手など、プロダクトの外も視野にいれることで、プロダクトがもっともレバレッジする課題にフォーカスして、戦略を考えることが重要です。
②両サイドの組織・目標を分ける
前述したように、両サイドでは成果が出るまでの期間やユーザーの性質も異なってきます。もしこれらの組織が一緒で目標が２つあるような状態だと大変危険です。
例えば、期の始まりでは「供給サイドのための機能開発をしよう！」と目標を立てていたものの、期の終わりに近づくにつれて、KPIをもっと改善したくなり、気づいたら短期の売上を得るため「やっぱり需要サイドに向けた機能を急いでださないと！」などと急な方向転換が起こります。この例では、供給サイドから需要サイドへの方向転換でしたが、逆のケースも十分起こり得ます。
プロダクトでの急な方向転換はコストがかかるので、予め両サイドの組織や目標を分けておき、各組織のリソース配分で予め短期・中期などのバランスを調整するのが重要です。
終わりに
今回は、Two-Side Platformの特徴について取り上げ、戦略検討の難しさについて考えてみました。プロダクト戦略を考えるにあたって、プロダクト以外にも視野を広げることが重要だと思います。この記事が、プロダクトをより良くするための少しでも参考になれば幸いです。
とはいえ、言うのは簡単ですが、このジレンマぶち当たっている毎日です。。。
ぜひ、みなさんの戦略や考え方を教えていただければと思います。noteへのコメントやTwitter DMなど大歓迎です！
明日以降の記事も楽しみですね！
ありがとうございました！
この記事が気に入ったらサポートをしてみませんか？