競争の激しいSaaS市場で4年間事業を運営して学んだこと

 (maxrozen.com)
74 ポイント 投稿者 xguru 2025-04-14 | 4件のコメント | WhatsAppで共有
  • Max Rozenが創業したOnlineOrNotは、すでに200以上の競合製品が存在する市場でスタートした
  • 当初は使いにくい製品が多く、その後も多くの競合製品が登場しては急速に姿を消していった
  • 一部の競合製品はVC資金を受けて大企業に買収され、ユーザー体験が次第に悪化する方向へ進んでいった
  • OnlineOrNotは自己資金で運営する長期的に持続可能な事業を目指している
  • 著者は今でもフルタイムの仕事を続けながら、着実にSaaSを開発している
  • 毎年ふりかえり記事を書いているが、過去に学んだ教訓の一部は時間が経つにつれて誤りだったと分かった

変わらない原則

数年にわたる事業運営を通じて多くを学んだが、それでも変わらず守り続けている中核的な原則がある

毎営業日に2時間を投資する

  • OnlineOrNotを始める前から、毎朝出勤前の2時間を個人プロジェクトに集中して使っていた
  • この時間を使って、何百本もの記事、1冊の本、複数のソフトウェアプロジェクトを完成させた
  • 1日にどれだけ投資するかよりも、毎日継続して努力すること自体のほうが重要だ
  • この時間を確保するために、2時間早く起きるようにして生活リズムを調整した

他のサイドプロジェクトには手を出さない

  • 「二兎を追う者は一兎をも得ず」という言葉の通り、1つに集中している
  • 例外的に複数のプロジェクトを成功させる人もいるが、自分はそうではないと認めている
  • $0から$500 MRRまで持っていく過程が最も難しく、これを何度も繰り返す必要はないと判断している
  • すでに機能しているモデルに集中し、マーケティング手法も同じ観点で選んでいる

顧客の痛みを解決することを最優先にする

  • ユーザーが登録すると、自動メールで「なぜ登録したのですか？」という質問を送る
  • メールはすべて読み、直接返信しており、これが製品改善の重要なインサイトになっている
  • ユーザーが不便に感じている点を把握し、実際にそれを解決する

しつこく繰り返して改善する

  • どんな作業でも2時間以内にデプロイできないなら、スコープを縮めて先に出す
  • 常に理想通りきっちり2時間には収まらないが、初期バージョンを素早くリリースして機能を広げていくやり方を好む
  • すべての機能を作り切ってから出そうとすると、かえってモチベーションが下がり集中力も薄れる
  • 機能フラグの裏で段階的に機能を仕上げるやり方のほうがはるかに効果的だ

学んだ教訓

本を数冊だけ読んで、すぐ作ってみる

  • 始めた当初は失敗を減らすために何十冊ものビジネス書を読んだ
  • しかし結局、自分で失敗しながら学ぶのが最も効果的だと気づいた
  • 例: Hacker Newsのトップに載って6000人が訪れたが、実際にアプリまで到達したユーザーは1桁しかいなかった
  • 登録フォームの時点で75%が離脱 → OAuthログインオプションを1つ追加しただけで離脱率は50%まで改善
  • もしもう一度やり直すなら、次の3冊だけ読んですぐ始めていただろう
    • The Mom Test (Rob Fitzpatrick)
    • Deploy Empathy (Michele Hansen)
    • Badass: Making Users Awesome (Kathy Sierra)
    • SaaS運営の実践的なディテールが必要なら The SaaS Playbook (Rob Walling) も追加で勧めたい

サブスクリプションを売る前に、まず問題を解決する

  • SaaSの目的はサブスクリプションを売ることではなく、顧客の痛みを解決することだ
  • 「機能を作り続ければいつか使ってもらえるだろう」から、「ユーザーの業務における苛立たしい問題を解決しよう」へと発想を切り替える必要がある
  • SaaSは問題解決の1つの手段にすぎず、そのほかにもscreencast、ドキュメント、記事執筆、本、ワークショップ、コードサンプルなど多様なアプローチが可能だ

小さく作って、頻繁にリリースする

  • ユーザーは機能アイデアを提案するが、実際にはほとんど使わない
  • 初めてSaaSを始めた人は、誰かと会話できただけでうれしくなり、勢いで機能を作ってしまいやすい
  • その機能をどう使うのかを尋ね、他のユーザーがその問題をどう解決しているかも調べたうえで、
    • 最小限の機能でまず実装して反応を確認すべきだ
  • 1人しか使わない「スノーフレーク機能」を作るより、多くの人が使う機能を作るための戦略的なアプローチが重要だ
  • 数時間かけた機能を削除するのもつらいが、数か月かけた機能を削除するのははるかに苦痛だ

とにかく出して、スケールは後で考える

  • OnlineOrNotの初期バージョンは、アーキテクチャ最適化なしで素早く公開された
  • 実際にはシステムが処理できるチェック数が約100件に制限されるバグがあり、
    • 問題が起きてもユーザーには単に「Error!」とだけ表示する、非常に未完成なUIだった
  • それでも著者は、不要な機能を作るより未完成なUIで批判されるほうを選んだ
  • 最初から何千人ものユーザーが来る保証はないのだから、素早く検証することのほうが重要だった
  • 一時的にデータベースを上位プランへアップグレードして、チェック受け入れ容量を増やした
  • その後数時間で、数百万件のチェックを処理できる構造へとリファクタリングし、エラー画面も改善した

アーリーアクセスプログラムを運営する

  • 製品開発の初期段階では、大半のユーザーは不完全な機能にある程度寛容だ
  • 時間がたつにつれて、より成熟した製品を期待するユーザーが増えていく
  • これに対応するため、各ユーザーアカウントに「アーリーアクセスプログラムに参加する」というチェックボックスを追加した
    • 参加者はまだ完成していない最新機能を先に試し、フィードバックを提供する
  • テストとフィードバックのバランスを取る方法として有効に機能した

無料トライアルはできるだけ早く導入する

  • 今では「無料プランは成立させるのが難しすぎるのでやらないほうがいい」という助言が一般的だ
  • しかし初期には、無料プランが口コミとユーザー流入に効果的だった
  • 欠点は、無料プランと有料機能の差が大きい場合、優れた機能を試す手段が必要になることだ
  • 開始から11か月後になってようやく、オンボーディング過程に「無料トライアルを開始しますか？」という質問を追加した
    • 実際の意味は次の通りだ
      > 「優れた機能を14日間試して判断しますか？ それとも数か月間、機能が制限されたまま使った末に結局失望しますか？」
  • その後、実験的にすべてのユーザーへデフォルトで無料トライアルを提供するようにしたところ、
    • この1つの実験だけで月間成長率が2倍以上に増えた
  • 結論:
    • 「これは有料サービスです。優れた機能を使い続けるには支払い情報が必要です」というメッセージのほうが、
    • 「これは無料サービスです。たくさん使うと有料かもしれません」よりビジネス的にはるかに効果的だ

ドキュメントそのものが製品である

  • 以前は「開発者はドキュメントを読まない」とよく言われていたが、完全に間違っている
  • 理想的な顧客の一部がOnlineOrNotのドキュメントを高く評価してくれたことをきっかけに、ドキュメントへ集中的に投資した
  • APIドキュメントも自前で構築し、ユーザー体験を完全にコントロールできるよう設計した
  • 製品分析ツールで観察した結果:
    1. ユーザーがUIで問題に直面しても、ドキュメントを確認して機能を見つけられれば使い続ける
    2. 欲しい情報が見つからなければ、チェックを作成せず離脱する
  • ドキュメントの品質はそのままユーザー維持率に直結する

モバイル環境を考慮して製品を設計する

  • 一般的なイメージとは異なり、B2B SaaSユーザーもスマートフォンで業務を始める
  • 実際、全ユーザーの約50%がモバイルで製品利用を開始していた
    • アカウントを作成し、いくつかのページを登録したあと、PCで再確認する流れだ
  • 最初の6か月はモバイル環境を考慮しておらず、モバイル登録者の大半は離脱していた
  • その後レスポンシブUIを導入した結果、モバイルユーザーの維持率が目に見えて向上した

ユーザーに流入経路を直接聞く

  • 1年目の半ばに導入した最も価値の高いコード変更の1つは、
    • **登録時に「どこでOnlineOrNotを知りましたか？」**という質問を追加したことだ
  • ユーザー流入チャネルを把握することは、マーケティング効率を最大化するうえで非常に重要だ
  • マーケティングチャネルは何十個もあるが、集中できるリソースは限られている
  • うまく機能するチャネルが分かったら、そのチャネルに集中投資し、反応が鈍るまで続ける

侵襲的な分析ツールは使わない

  • 最初は一般的なSaaS製品のようにセッショントラッキングやファネル分析ツールを導入したが、実効性は低かった
  • 大規模チームには有用かもしれないが、小規模サービスではランダムな結果を誤解する可能性が大きい
  • ソロ創業者として毎朝2時間しかない状況では、
    • 膨大なデータを分析するより、信頼するユーザーグループ（inner-circle）から直接意見をもらう方法のほうが効果的だった
  • 機能や問題点について感覚的なフィードバックを受け、感性に基づく判断で製品を改善した

機能がなくても見込み顧客と話す

  • ある日、CTOから特定機能に対応しているか問い合わせがあった
  • 本来なら「申し訳ありません、まだありません」で終えるつもりだったが、
    • 好奇心から、彼らが抱えている問題と達成したい目標を質問し、
    • inner-circleのユーザーにも同じ問題を抱えているか尋ね、
    • 機能をどう設計するかのアイデアを共有した
  • 結果としてそのCTOは翌日に有料登録者となり、今でも顧客であり続けている
  • その機能は他のユーザーにも広く活用されている

問題解決よりプラットフォーム構築に多くの時間を使う

  • 過去4年間の開発時間の半分以上はSaaSプラットフォームの構築に使われた
    • 本来の目標である「Webサイトのダウン有無を確認して通知する」は、その一部分にすぎない
  • 実際に必要だった機能は次のようなものだった
    • 多様な認証方式とユーザー管理
    • トライアル、オンボーディング
    • 反復的なDB作業、チーム管理、請求書処理
    • ライフサイクルメールなど
  • 一部はStripeのようなサービスにアウトソースしたが、
    • 自分で扱う必要がある部分や個別対応が必要な部分も多く、結局自前で実装した

価格設定は本当に難しい

  • 価格が高すぎると期待値が上がるか、そもそも登録を避けられる
  • 価格が低すぎると、$9払ったユーザーがアプリ全体を自分好みに作り変えろと要求することもある
  • 解決策:
    • 厄介な顧客には返金して別れてもらう
    • 価格を上げる
    • そして次へ進む
    • とくに初期に機能を広げていくほど、継続的な価格実験は不可欠だ

MRRだけに執着しない

  • MRR(Monthly Recurring Revenue) は、事業成果を測るには不適切な指標になりうる
  • 数週間前あるいは数か月前に行ったことが現在のMRRに影響するため、リアルタイムでの効果測定が難しい
  • SaaS製品によっては、ユーザー登録から実際の支払いまで60日以上かかることもある
  • したがって、他の指標を通じて実際の利用や価値提供の有無を把握すべきだ
    • 例: 生成された画像数、送信されたフォーム数など、行動ベースの成功指標の利用を推奨する

「無制限提供」は絶対にするな

  • 常に**「無制限」を最大限に使い倒すユーザー（whale customer）**は存在する
  • 例: 月額$250しか払わないのに膨大なリソースを使う顧客
  • 無制限で提供する単位がコストの発生する項目であるなら、必ず損をする
  • この助言はライフタイムディールにも当てはまる
    • $100で生涯利用を約束すると、その後何年にもわたって機能追加を求められる可能性がある
    • サードパーティのマーケットプレイスを使っていたなら、実際の収益はそのうち30%しか受け取れないこともある
  • 結局、本当の顧客ではなく、短期的な得を求めて長く居座るユーザーを招き入れることになる

有料リソースには必ずrate limitを適用する

  • AI、SMS、メール送信などの有料APIを使う場合、利用制限は必須だ
  • 「有料顧客なのだから無制限に使えてもいいのでは？」→ 例外的なケースはあるかもしれないが、
    • ほとんどの場合、高額請求やベンダーからのスパム判定のリスクが発生する
  • 実例:
    • 数百のWordPressサイトがホストされたサーバーでRAM不足によるエラーが発生し、
    • その結果、数千件のSMS通知が自動送信されて大きなコストが発生した
  • 本当に大量利用が必要な顧客なら、向こうから直接連絡してくる

1ページで全部説明しようとするな

> 「すべての人にすべてを伝えようとすると、誰にも何も伝わらない」

トラフィックを増やすのは難しいが、コンバージョン率の改善は今すぐできる

  • インターネットで注目を集めるのは長期戦で非常に遅い
    • 継続的に質の高いコンテンツマーケティングをしても、1〜2人の訪問者が数百人に増えるまでには数か月から数年かかる
  • トラフィックそのものを増やすのは簡単ではない
  • 一方で、すでに来ているユーザーの行動はすぐ変えられる
    • 例: 登録フォームにOAuthログインオプションを追加するような、今日適用できる改善がコンバージョン率を高める

競合はそれほど重要ではない

  • この記事全体で競合の話がほとんど出てこない理由は、実際には大きな影響がないからだ
  • もちろん、顧客に比較対象として検討してもらうには基本的な機能は必要だが、
    • 本当の競争相手は、ユーザーがこの製品の存在自体を知らないことだ
  • 機能以上に、認知度とアクセスしやすさが重要な競争要因になる

関連記事

4件のコメント

 
thenewseason 2025-04-22

サービスを運営する立場として、多くの内容に共感します。
私も睡眠時間を削って開発していましたが、健康を損ねてしまいました。

似た経験をお持ちの方にお聞きしたいのは、こうした時間投資が子育てをしながら可能なのかという点です。
通勤時間や会社にいる時間、家で子どもたちと過ごす時間が一日のほとんどを占めるので、こうしたサービスを作って運営するには何か別のものを諦めなければならなくなりますが、それが家族や健康であってほしくはないです。
 
tsboard 2025-04-15

本当に学ぶことの多い文章ですね。朝に2時間ずつ活用して文章も書き、さまざまなプロジェクトまで完成させるなんて……！
 
ethanhur 2025-04-14

学ぶことの多い文章です。結局のところ、SaaSも顧客が問題を解決するために雇うプロダクトだという事実を忘れてはなりません。
 
xguru 2025-04-14

1人でSaaSを1年運営して学んだこと
もう3年も経ったんですね（笑）。変わった内容を比較しながらご覧ください！