← エピソード一覧に戻る Episode 135 Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
0:00 / 0:00
スクリプト
Chapter 1 オープニング ― ベータは宣伝ではなく実地演習
タカシ
皆さんこんにちは、タカシです。今日は SaaS 立ち上げで軽く見られがちなのに、実は公開前の勝敗を大きく分けるテーマ、ベータ導入を扱います。ベータは先行公開イベントではなく、顧客成功の詰まりを洗い出す経営の実地演習なんです。
ミカ
ミカです。ベータ版って、つい『とりあえず何人かに触ってもらう段階』くらいに思っていました。でもそれだと、感想は集まっても経営判断に使える学びは薄そうですね。何を見れば、良いベータ導入と言えるんでしょうか。
タカシ
最初に見るべきは登録数ではありません。誰が使い続けたか、初回価値に何日で到達したか、どこで設定や運用が止まったかです。つまりプロダクトの完成度だけでなく、オンボーディング、サポート、導入条件まで含めて検証するのがベータ導入なんですね。
ミカ
なるほど。未完成の機能を試す場というより、顧客が本当に前に進めるかを確かめる場なんですね。たくさん集めるより、正しい人に限定して、どこでこけるかを見るほうが大事だ、と。
タカシ
その通りです。今日は、ベータ導入で何を学ぶべきか、Linear と Superhuman の良い例、Braze の前身 Appboy の失敗例、そして明日から使える設計ポイントまで順番に見ていきます。自社なら何を卒業条件にするか、考えながら聞いてみてください。
Chapter 2 基本 ― ベータで検証するのは顧客成功の流れ
タカシ
ベータ導入で最初に固定すべきなのは、『いつ公開するか』ではなく『この限定導入で何を学ぶか』です。たとえば理想顧客は誰か、初回価値到達までどれだけかかるか、どの設定や権限で止まるか。ここが曖昧だと、ただの先行利用キャンペーンになります。
ミカ
確かに、『使ってみてどうでした？』だけだと、便利でしたとか、ここが気になるとか、感想で終わりがちですもんね。本当は、導入して成果が出るまでの流れが成立したかを見ないと、公開してから事故りそうです。
タカシ
まさにそこです。OpenView は、平均的な SaaS で 40〜60%超の新規ユーザーが初日の後に戻ってこないと指摘しています。だからベータでは、初日に何を完了させれば価値が伝わるのかを決め、その到達率を追う必要がある。見るべきは sign-up ではなく activation と time to value です。
ミカ
登録者が増えても、最初の一歩で消えていたら危ないわけですね。しかも B2B SaaS だと、画面の使いにくさだけじゃなくて、データ準備とか権限設定とか、現場運用との噛み合わせでも止まりそうです。
タカシ
その通りです。SaaStock も、オンボーディングでは機能説明より早い価値実感が重要で、追うべき指標は activation rate、time to value、early churn だと整理しています。つまりベータ導入は、製品テストと同時に、導入設計と支援設計を磨く場なんです。
Chapter 3 事例 ― Linear は人数より学習密度を選んだ
タカシ
良い例としてわかりやすいのが Linear です。2019 年の invite-only beta では待機リストに約 10,000 件のメールが集まっても、最初の 1 年で実際に利用したのはその約 10% にとどめ、毎週 10 人前後ずつ丁寧に招待していました。
ミカ
えっ、そんなに待っている人がいるのに、毎週 10 人前後ですか。それはかなり我慢が必要ですね。でも逆に言うと、勢いで広く開けずに、誰を入れるかをかなり厳しく見ていたわけですね。
タカシ
そうです。申し込み時の survey で、なぜ使いたいのか、今どんな課題があるのかを聞き、ICP に合う人を選んでいました。しかも early user とは毎週メールでやり取りし、フィードバックを追っていた。人数より、解像度の高い学習を優先したんですね。
ミカ
ここで大事なのは、好意的な人を増やすことより、正しい人から正しい摩擦を集めることなんですね。たくさん来ても、ターゲット外の人が一日で去ってしまったら、プロダクトが悪いのか、相手が違うのか見えなくなりますし。
タカシ
その通りです。Linear はこの過程で、Google 認証しかないことが導入 blocker だと発見しました。ベータ導入の価値はここです。機能要望を増やすことではなく、理想顧客が前に進めない原因を特定し、一般公開前に潰すこと。しかも public launch は retention が高い状態まで待っていました。
Chapter 4 深掘り ― Superhuman は人手で最初の詰まりを掘り当てた
タカシ
もう一つの好例が Superhuman です。初期の onboarding は 1 回最大 90 分で、毎回 10 ページ分のメモ、5〜10 件の feature request、5〜10 件の bug が見つかったといいます。当初は 30 分の human onboarding を必須にして、最初の離脱を放置しませんでした。
ミカ
90 分はかなり濃いですね。でも、そこで実際の仕事の流れを横で見れば、分析ツールだけでは拾えない詰まりが大量に見えそうです。『人手は非効率』と切ってしまうのは、初期にはもったいないのかもしれません。
タカシ
まさにその通りです。しかも後に self-serve へ寄せるときも、最初の体験を作り直した結果、主要ショートカットの利用は 50% 増え、activation rate は 40% から 50% に上がりました。つまり人手は、その後の自動化を正しく設計するための観測装置だったんです。
ミカ
なるほど。初期のベータで人が伴走するのは、そのまま続けるためじゃなくて、どこまでを将来セルフサーブ化できるかを見極めるためでもあるんですね。最初から全部自動にしようとすると、肝心の学びが飛びそうです。
タカシ
その理解で合っています。特に複雑な B2B SaaS は、導入手順、データ移行、権限設定、社内合意といった周辺要素まで含めて価値提供です。ベータ導入では、手で支えてでも『どこを支えたのか』を記録することが、次の仕組み化の材料になります。
Chapter 5 失敗パターンとクロージング ― 派手な反応より卒業条件
タカシ
失敗例も見ておきましょう。Braze の前身 Appboy は public launch 後 2 週間で 1,000 件の beta signup を集めましたが、後になってその初期登録者から残った顧客はほぼいなかったと振り返っています。多くが趣味的な開発者で、払う顧客ではなかったからです。
ミカ
これは怖いですね。見た目の数字だけなら大成功に見えるのに、実際にはターゲット理解をむしろ曇らせてしまう。ベータ導入で誰でも受け入れるのは、優しいようでかなり危険な判断なんですね。
タカシ
はい。よくある失敗は三つあります。第一に、ベータを宣伝イベントにしてしまうこと。第二に、受け入れ条件を決めず誰でも入れること。第三に、問い合わせや詰まりを CS の問題として片づけてしまうことです。本当はそこに product と onboarding の欠陥が出ています。
ミカ
明日からやるなら、申し込み数を見る前に、誰を受け入れるか、最初の価値を何に置くか、公開の卒業条件を何にするかを決めるべきですね。activation、time to value、継続利用、紹介意向あたりが見えてくると、次に進みやすそうです。
タカシ
その通りです。ベータ導入は『どれだけ注目されたか』を見る時間ではなく、『どの顧客が、どんな条件なら成功できるか』を言語化する時間です。広く開く前に詰めるべきなのは機能より学習設計。皆さんも公開前の実地演習として、ベータを設計してみてください。