マーケットプレイスの作り方（8）：もう一度やり直すとしたらどうする？

自己紹介

こんにちは、宮武（@tmiyatake1）です。普段は、LAにあるスタートアップでCOOをしています。今回も引き続き、Lenny Rachitsky（@lennysan）さんから許可を頂き、翻訳した「How to Kickstart and Scale a Marketplace Business」のパート8をお送りします。前回を読まれていない方はこちらから読めます。

本シリーズは、大きく3つのフェーズに分けて構成しています。

1) フェーズ1：ニワトリとタマゴ問題について
　・マーケットプレイスを拘束・制限すること
　・サプライ側かデマンド側、どちらにまず集中するべきか？
　・初期サプライの伸ばし方
　・エンドユーザーの伸ばし方
2) フェーズ2：マーケットプレイスのスケールの仕方
　・サプライ側とデマンド側のどちらが伸び悩んでいるかをどう判断するべき？
　・スケール時のグロース戦略
　・クオリティー担保戦略
　・もう一度やり直せるとしたらどうする？←今回
3) フェーズ3：マーケットプレイスの進化させる方法
　・「Managed（管理された）」マーケットプレイスへの進化する方法とは？
　・新規事業の追加方法

今回は、フェーズ2の最終回になる。もし過去に戻れるとしたら、何をやり直すか、何を公開したかのまとめだ。よりフォーカスする、より構造化されたデータに整理するべきだったなど、様々な学びがあった。

1：もっとフォーカスする

事例1：Breather
「一つのユースケースに特化するべきだった。95%のユースケースが会議室用ともっと早く気付くべきだった。」— Julien Smith氏

事例2：Eventbrite
「全員サプライ側の獲得にフォーカスしていた。後々サプライ側だけのフォーカスしたグロースチームを立ち上げて、それを後ほどデマンド側とサプライ側のグロースチーム二つに分けた。やり直せればもっと前にデマンド側の獲得チームを作っていた。」— Brian Rothenberg氏

事例3：TaskRabbit
「量と幅広さを強調しすぎた。私たちの一つのアハ体験はユーザーは30個の提案を見たくなく、トップ2ぐらいしか見たくなかった。これはユーザーテスティングをして分かった。」— Jamie Viggiano氏

2：もっとアグレッシブに行くべきだった

事例1：GrubHub
「レストラン側の獲得にもっとお金を投資するべきだった。」— Casey Winters氏

事例2：Uber
「トラビスに聞けば、もっと早く中国展開をしていたと言うだろう。Uberが中国に入った時にはすでにDidiがデカかった。」— Andrew Chen氏

事例3：Zillow
「SEOやメールチャネルをもっと前に活用していた。後、よりユニークでクラウドソースされたコンテンツのサイトを勉強していた。どうやってプラットフォームでコンテンツを作る、キュレーションする、管理するかを学んでいれば初期のミスを減らせたかもしれない。」— Nate Moch氏

3：長期的に考える

事例1：OpenTable
「後ほど大変になる大きな判断をしてしまった。我々のサイトに載るには我々のシステムを全て（内部予約システムも、オンライン予約システム）使わなければいけなかった。そのおかげで全レストランを載せるコンテンツサイト（Yelpなど）が出てきてしまった。」— Mike Xenakis氏

4：スケールする前にPMF達成をすること

事例1：TaskRabbit
「TaskRabbitではPMF達成前にスケールした。もっと「Fill Rate」、すなわち投稿されたタスクの何%が実際に完了されたのかを見るべきだった。100%よりかなり低く、マッチしなかったユーザーは戻ってこなかった。会社としてトップラインの成長にフォーカスしすぎて、スケールする前にここによりフォーカスを当てるべきだった。」— Brian Rothenberg氏

5：データ活用をもっと早めに活用すべきだった

事例1：Etsy
「劇的なグロースは時間とともに減って問題になった。その時には定量的な広告、A/Bテスト、良い分析チームはいたが、会社のフォーカスではなかった。例えば2012年に1日合計700商品しか売れなかったページに何百人の従業員のリソースを当ててた。逆に10万商品が売れる検索には3〜4人しかフォーカスしてなかった。これが毎年のように繰り返してしまった。この失敗はスケールするとともに大きくなった。悪化しすぎて前CEOがクビになる年には全インフラを変更する必要があった。我々はCEO交代を何度か行なったが、毎回ダメだったのはほとんどのチームがやっていたことがグロースと関係なかったことに気づかなかったことだった。」— Dan McKinley氏

6：プロダクトありきの成長をもっと早めに

事例1：GrubHub
「CAC、LTV、リテンションの数字のトラッキングは念入りにやっていたが、プロダクトありきのグロースへの移行は遅すぎた。最終的にコンテンツドリブンなグロースループを作った。初期はかなりリソース不足だった。競合のEat24は我々のサイトを完コピしてSEOにかなり投資した時に我々の検索ランキングを上回り始めた。それを乗り越えるリソースがなかった。やり直すとしたら、ブランディング用のマーケティング施策を減らしていた。最終的にオフラインマーケティングやテレビ広告でパフォーマンスマーケティングした。」— Casey Winters氏

7：スケールしないことをより長いことやる

事例1：Lyft
「よくやったと思うが、イノベーティブな考え方とマインドセットを早く失いすぎた気がする。ユーザー数が少ない時でもテストの数が足りなかった気がする。毎週1〜2個のテストで学び続けていた。毎週金曜日、仕事時間の後にOptimizelyでLPのコアの部分を変更していた。たまにどう言うメッセージングがドライバーにより響くかなど面白いインサイトが学べた。こう言う学びのおかげで次の大きな変更点を見つけることができた。少ない量の仕事で大きな影響を与えられるものだった。各変更点は1時間以下の仕事量だった。これをメール、サイト、アプリで行なった。最終的にはテスティング頻度のスイートスポットが見つけられなかった。」— Benjamin Lauzier氏

8：スケールする解決法をより早くテストする

事例1：Caviar
「もっと早めにスケール出来るレストランのオンボーディング戦術をテストしたかった。」— Gokul Rajaram氏

9：サプライ側の共感

事例1：Lyft
「ドライバー側とユーザーの共感を作るのが時間かかった。場合によっては我々が強すぎたり、厳しすぎた。よりユーザーの体験をドライバーに伝えるべきだったかも。例えば7分待ち続けているユーザーがいれば、ドライバーにキャンセルするなと伝えるべきだった。ユーザーとドライバーの繋がりを作るのが時間が掛かった。短期的に物事を見ていた。」— Benjamin Lauzier氏

10：他の事業展開を早めにする

事例1：Rover
「犬の散歩や他のサービスへの事業展開するのが遅すぎた。それを証明するのはWagがまだ存在していること。ほとんど同じ需要者。犬の面倒を見てもらう人はほぼ必ず犬の散歩をしてもらう人が必要。当たり前の機会だったし、より良いユニットエコノミクスだった。でもフォーカスも必要で、DogVacayと必死にシェアを取り合っていたのでその余裕もなかった。ただ、アドバイスとすると新しい機会に確信していて、組織として対応できそうであればすぐにやること。シードステージで新規事業を走らせるのは間違えだと思うが、それを超えてPMFがあると思ったらすぐに進めるべき。」— David Rosenthal氏

11：革新的なアイデアを早めにテストする

事例1：Lyft
「ギグエコノミーではギャランティーが必要になってくる中で、期待値設定が難しい。我々がコミットしたのは毎週20時間運転すれば、毎週$2,000の売上をギャランティーした。これでドライバーに現実味を与えて、成功に導くことができる。昔は$1,000の登録ボーナスなどを与えてたが、それは運転してくれる習慣につながらない。ギャランティーをすることによってユーザーがLyftがどう自分の人生にフィットするかがわかり、よりLyftを使いたいユーザーを獲得できる。」— Benjamin Lauzier氏

12：構造化されたデータを取得する

事例1：Eventbrite
「サプライ側の周りの構造化されたデータで失敗した。初期はイベント名、日付、場所、そしてイベント概要のフリーフォームだけだった。それだけだとサプライ側の在庫を理解しぬかった。でもそれはデマンド側のマッチングでは必要不可欠。初期はサプライ側の獲得にフォーカスしていたので、これがプライオリティーとして上がらなかった。そのせいで数回サプライ側の分類方法など構造化されたデータへの変更をしてしまった。」— Tamara Mendelsohn氏

13：クオリティーのフォーカスする

事例1：Etsy
「より早めにクオリティーにフォーカスしていれば後々楽になってた。リスティングのクオリティーが低かったせいで買手側の検索が長い間悪かった。売手が商品を載せると検索にヒットするための機能があまりなかった。売手側はバズるキーワードをタイトルやタグに加えて正しい検索結果ではなくより多くの検索結果に出るようにしていた。検索エンジニアチームが売手側にとってまぁまぁな体験を作るにもかなり苦労した。」— Nickey Skarstad氏

14：競合を避ける

事例1：Rover
「もっと前に競合を倒しに行くべき。そうしないと後々値段戦争などの殴り合いになるだけ。ただ、競合がいたおかげでより強くなり、よりフォーカスするようになったのも事実。」— David Rosenthal氏

今回の翻訳シリーズは、原文のフェーズ3がまだ公開されていないので一旦終わりとなります。もし、公開されたら引き続き読みたいという方がいらっしゃいましたらnoteやTwitterでコメント頂けると嬉しいです。

ポッドキャストもやってます！

Off Topicでは、米国を中心に最新テックニュースやスタートアップ、ビジネス情報をゆるーく深堀りしながらご紹介する番組です。

‎Off Topic // オフトピック on Apple Podcasts

Spotifyからも聞くことができます。

Written by Lenny Rachitsky (@lennysan) | Translated by Tetsuro (@tmiyatake1) | Edited by Miki (@mikirepo)