- Nadia OdunayoがBrighton Rubyで発表した内容の要約
2020年1月1日に戻る
- 2024年6月時点から2020年1月1日を振り返り、Storygraphの初期の成果を回想
- 創業後1年間、毎日開発に打ち込み、ついに「ユーザー100人登録」という目標を達成
- 当時のStorygraphは、読者が次に読む本を選べるよう支援する「書籍推薦ツール」だった
- Webサイトは数千冊の本のリストを提供し、気分、ペース、ジャンル、本の長さなどでフィルタリング可能
- 初期ユーザー:
- Nadiaの友人たち、Instagramの読書コミュニティ（Bookstagram）でDM経由で流入した人たち
- ユーザーはその可能性を見出して知人に紹介し、徐々にユーザーベースが拡大
- 2020年の新年を記念してベータ版を再公開
- 新年を読書目標を立てる時期と考える読者たちへの動機づけ
- 小さなイベント効果で「160人のユーザー登録、100人の新規訪問者」を獲得
- 訪問者は平均「6分30秒」Webサイトを閲覧し、好意的な反応を示した
- 2019年の間は製品開発に集中し、人々が書籍推薦やGoodreadsの代替を探すときに勧められるような製品を作るために努力
- 「Goodreadsの代替」を目標にしていたわけではなかったが、特定のユーザー層にとってより良いサービスになり得る可能性を見いだした
- 2020年を迎え、新たな成果に後押しされて、さらに情熱的にプロジェクトを継続
パンデミックと初期成長
- パンデミックにより集中して開発する時間が確保され、読書率が上がるとともに新規登録者も増加
- しかし製品の完成度が低いと感じ、「公式に宣伝」することに不安があった
- 記事やユーザーの意見に対応せず、静かに開発に専念
- 2020年5月までStorygraphは依然として簡素な機能しか提供しておらず、1人で製品開発を進めていたため技術的な不足を感じ、不安と脆さを覚えていた
- 読書コミュニティで継続的に活動し、ユーザーが新たな代替を求めるトレンドを観察
- 既存の100人ユーザー達成で得た自信と勢いをもとに、サービスを本格的に広めることを決断
Twitterでの拡散とユーザー1,000人突破
- 2020年5月27日、TwitterでStorygraphに好意的な反応を示した約100人に返信またはDMで連絡
- ほとんどは反応しなかったが、一部はプロジェクトの可能性を理解して関心を示した
- 一部ユーザーはGoodreadsとの機能比較を行い、不足点を指摘
- 当時のStorygraphは機能が限定的で、Goodreadsと競争するのは難しい状況だった
- プロジェクトの価値を理解した少数のユーザーが読書コミュニティにStorygraphを紹介
- 2020年6月11日、Storygraphのユーザー数が「1,000人」を突破
- 広報開始からわずか2週間でユーザー数が2倍以上に増加
- Instagramストーリーでお祝いイベントを開催
Twitterでの爆発と急成長
- 2020年6月16日、Emma Barnes（Consonance Books運営）がツイート:
- 「出版業界のみんながStorygraphを知るべきだ。ここ数年で最高のイノベーション。巨大テック企業のひどいソフトウェアに頼るのはやめよう。」
- このツイートでアプリの活動はやや増えたが、大きな反響はなかった
- その後、Sam MissinghamがEmmaのツイートを引用し、さらに人気を高めた:
- 「Book Twitter、もうGoodreadsの代わりにこれを使おう。5分使っただけでもうずっといい。しかも黒人女性が創業し、Amazonが運営していない。」
- Samのツイート後、アクティビティが急速に増加
- ツイート内容が大きな反響を呼んだ理由:
- Book Twitterコミュニティの関心を引いた
- 人々が代替を求めていたGoodreadsを狙っていた
- Black Lives Matter運動の影響で、黒人クリエイターを支援しようという機運が高まっていた
- パンデミック下でAmazon独占への反感が強まっていた状況と重なった
- ツイートが急速に拡散し、Storygraphのユーザーが増加:
- 数十人から始まり、数百人、数千人へと拡大
- メール通知（「Goodreadsデータの取り込み開始」）が急増し、システムに負荷が発生
- ツイートが予想外の速さでバイラル化し、多数のユーザーが登録
- ユーザー数の急増により、技術的な問題と「過負荷状態」が発生
暗い日々
- Goodreadsデータ取り込み機能の遅延により、ユーザーの不満が増大
- 数千人のユーザーにデータ取り込み進行中のメールを送ったが、取り込み速度が非常に遅く、数か月かかる見込みだった
- 多数の問題を同時に解決しなければならず、極度のストレスを受けた
- Twitterユーザーへの返信
- 失敗するデータ取り込み処理への対応
- アプリのコードを書き直し、取り込み速度を数か月から「数日へ短縮」
- 2020年6月17日、別のバイラルツイートが拡散し、ユーザーが急増:
- 「1日使ってみたけど、良すぎて我を忘れる」というツイートが人気に
- 毎時間数百人から千人単位の新規登録が発生
- 結果としてシステムが過負荷に:
- Goodreads取り込み不可
- パーソナライズ推薦機能が動作しない
- バックグラウンドジョブが完全停止
- ユーザー数が1,000人を超えて「10,000人」に近づき、プレッシャーを感じ始めた
- 「私はB2Cビジネスを望んでいたわけではなかった」という思いとともに懐疑的になった
- 孤立感を覚え、「暗い浴室」に座って考え込んだ
- 「もう無理だ」と言いそうになるのをこらえたが、ほとんど口にしかけていた
創業ストーリー: 最初に戻る
- どうやったのか? ここで少し先から戻ってみる
- 個人的には学問志向の家庭で育ち、Oxfordで哲学・政治・経済を専攻
- 両親の勧めで、経済的安定のために投資銀行の道に進もうとした
- しかし投資銀行の仕事に疑問を感じ、卒業後にオファーを辞退
- ロンドンのMakers Academyソフトウェアブートキャンプでコーディングを学ぶことを決意
- 開発者と会話するための基本的なコーディングスキルを目標に参加
- 開発者への固定観念が崩れ、コーディングの価値に気づいて本格的に没頭
- Makers Academy卒業後、Pivotal Labsに就職
- 1年半にわたりCloud Foundryプラットフォームに従事
- その後、同僚のTheo ChristianとともにIgnition Worksというコンサルティング兼プロダクト開発会社を創業
- この時期に**FIREムーブメント（経済的自立と早期退職）**に関心を持つようになった
- 経済的自立を確保し、自分自身と創業活動に投資できる基盤を整えたいと考えた
- しかしIgnition Worksでの目標とパートナーシップが期待に届かず、退社
- 会社資金の半分を引き出し、5年間の資金的余裕を確保
- 友人のSaron YitbarekとともにCode Newbieプロジェクトに参加
- コーディングを学ぶ人のためのコミュニティをプロダクト企業へ転換しようとしたが失敗
- 2019年1月3日、机に1人で座り、創造的な方向性を模索
- 資金は2022年まで使える状態だったが、大きなアイデアはなかった
- 以前から考えていた2つのサイドプロジェクトに時間を投資することを決断:
- Runroot: ランニングルートを自動生成するアプリ
- ReadLists: カスタム読書リストを作成し、進捗を追跡できるダッシュボードアプリ
- StorygraphはReadListsのアイデアから生まれ、この決断へのアプローチがStorygraph成功の核心だった
3つの原則
- すべては、創業者がコントロールできる要素とそうでない要素を区別するアプローチから始まった
- コントロールできない要素: バイラルツイート、新たな競合など
- コントロールできる要素: 会社と製品をどう設計するか
- 成功のための3つの主要原則
- 技術をシンプルに保つ: 複雑な技術ではなく、安定して成熟したツールを活用
- 顧客と継続的に対話する: 顧客フィードバックを製品改善に反映
- コストを低く保つ: 効率的な運営で財務の安定性を確保
第1の原則: 技術の単純化
- 第1の原則である技術の単純化に従い、次のような方針を設定
- すでによく知っている技術を活用
- 必要以上の複雑さを避け、問題解決に必要な最小限の技術だけを使用
- 安定して成熟した「退屈な」ツールやプラットフォームを選択
- 個人的に最も適していた技術スタックはRailsだった
第2の原則: 顧客と継続的に対話する
- Railsでの開発を楽しみつつ、本に関するプロジェクトに没頭しようと決意
- 成功する製品開発のために、第2の原則である顧客と継続的に対話する方法を導入
- 顧客との対話の重要性
- 誰も望まない製品を作ることほど悪いことはない
- 顧客と話すべきだと誰もが知っているが、それを適切に実行する方法が重要
- スクリプトを準備し、オープンな質問を通じて探索に集中
- 確証バイアスを避け、本当の問題を発見することに焦点
- 初期に犯したミス
- あまりに早くデモを見せたため、具体的なフィードバックを得られなかった
- その代わりに、読書習慣や不便な点などに関するオープンな質問を使用
- インタビュー結果を5件ずつ見直して要約し、テーマを仮想ホワイトボードに整理
- アルファ版とベータ版の製品開発
- 初期フィードバックを通じて、有用な機能（パーソナライズ推薦サービス）のアイデアを導出
- 初期機能の多くは手作業で対応し、過剰な開発を回避
- 少人数グループでユーザーオンボーディングを進めながら、継続的に顧客フィードバックを収集
- アルファ版製品の限界に達すると、より完成度の高いベータ版製品を開発
第3の原則: コストを低く保ちながらベータを成長させる
- 2019年9月2日、ベータ版を公開し、ニュースレター購読者に共有を促した
- フィードバックが本格的に入り始め、書籍リクエストを手作業で処理するスタッフをパートタイムで雇用
- 依然としてコストを最小化し、自己資金で運営し、残り資金で持続可能性を確保
- 数か月後、Rob Freeloveがプロジェクトに関心を示し、機械学習面の支援を提供
- 彼の支援により技術開発を継続し、製品品質とユーザー体験を改善
急成長、再び訪れた暗い日々、そして拡張
- 3つの原則に忠実であり続け、ゆっくりではあるが着実にユーザーベースを広げながら段階的に成長
- 2020年6月17日、Twitterでのバイラル効果によりユーザーが急増
- 数千人がGoodreadsデータの取り込みを試み、システム過負荷が発生
- バックグラウンドジョブの失敗とサーバー拡張不能の状態に達した
- 状況は圧倒的で、諦めたくなる**「暗い瞬間」**を経験
- しかし、諦めることは選択肢ではなかった
- 2週間の「暗い日々」の間に、次のような主要問題を解決
- コードの書き直し
- サーバーとデータベースのアップグレード
- 新たな問題への対応
- 継続的成長と収益化の必要性を認識
- 危機を乗り越えた後、毎日数百人のユーザーが登録し、口コミで成長が継続
- 決定に迷うたびに顧客との対話を通じて方向性を見出した
- ユーザーベースが十分に大きくなるにつれ、収益化の方法を考え始めた
Storygraph Plus導入と収益化への道
- コスト削減だけでは限界があり、収益化の方法を模索
- 複数のビジネスモデルを検討した末、**顧客の直接課金によるプレミアムモデル（freemium）**の導入を決定
- Storygraph Plusの予約注文ページを制作
- Stripe決済を統合: 初期はサブスクリプションなしでUSD決済のみ対応
- 購入者をバックエンドで「Early Bird」と表示
- ニュースレターでStorygraph Plusを告知し、予約注文を開始
- 多くのユーザーが独立系のGoodreads代替を支援したいと考え、注文
- 初期数週間で数百件の予約注文を確保
- 顧客の反応を通じてPlusモデルの市場性を検証
- 2021年1月1日、Storygraphの正式リリースとともにドメインを変更
- ユーザー数が100,000人を突破し、大きな成果を達成
- Early Bird価格終了後も定価で支払う人がいるかを確認しながらPlus機能を開発
- 2021年2月28日（または一部地域では3月1日）、Storygraph Plusを正式リリース
- 1,400件の予約注文で約$50,000の収益を達成
- 実際にPlus機能の利用が始まった後も、顧客の関心と満足は継続
モバイルアプリ開発、Heroku移行、そして継続的成長
- 2021年5月、Storygraphの最大の課題はモバイルアプリの不在だった
- それまではPWA(Progressive Web App)を提供していたが、ユーザーはアプリストアからインストールできるネイティブアプリを望んでいた
- コスト削減と技術単純化の原則を維持しつつ、RailsとHotwire/Turboモバイルアダプターを活用
- 最小限のSwift/KotlinとRubyを組み合わせ、6週間でアプリを開発・リリース
- アプリ公開後、登録者数が増加
- HerokuからCloud 66への移行
- バイラルなTikTokとユーザー急増によりHeroku運用コストが上昇
- Herokuサーバー費用: ユーザー増加に伴い月$10,000まで上昇
- Robが数か月かけて代替プラットフォームを調査した末、Cloud 66への移行を決定
- 2022年1月22日、Cloud 66への移行を完了
- サーバー費用を80%削減し月$4,000に縮小、より高い容量を確保
- 移行過程で全ユーザーがログアウトされる問題が発生したが、迅速に解決
- 2022年6月26日、Storygraphのユーザーが100万人を突破
- 現在:
- 270万人の登録アカウント
- 約25%の月間アクティブユーザー
- 月700万人のユニーク訪問者
- 7,000万ページビューと1日1,100万リクエストを処理
- 2019年に始めたRailsリポジトリを基盤として、今もなお運営
- 収益とコストの状況:
- 月間コスト: 約$20,000
- 月間経常収益: 約$60,000
- 収益性が確保され、創業者であるRobとNadiaの両名が給与を受け取れるようになった
成功の理由
- 運もあったが、Storygraph成功の核心は次の3つの原則を一貫して維持したことにある
5件のコメント
RoRは他のフレームワークに比べて成功事例がかなり多い気がしますね。今から学んでも大丈夫でしょうか？
コミュニティの活性化がものすごく大きくなった感じですね。この発表は Rails SaaS Conference でも行われたようですが、「SaaS」カンファレンスが別にあるとは……
B2Cビジネスを望んでいなかったという話と、思ったより大きいサーバー費用が目を引きます。
RoR はかなり抽象化されているので、性能の問題からインスタンスを垂直スケーリングして使っていて、その結果サーバー費用もかなりかかっているのではないかと思います。
1か月前に1人開発チーム、200万人ユーザー達成 [ビデオ] という動画リンクが上がっていましたが、発表スクリプトはなかったので、Whisperを使って動画のスクリプトを起こして整理してみました。
その記事にあるコメントも参考にしてください。