- Y Combinatorは創業初期に**「スケールしないこと」**を積極的に行うべきだと助言している
- Stripe、Airbnbなどの成功したスタートアップは、初期ユーザー獲得において直接的かつ積極的なアプローチを選んだ
- ほとんどのスタートアップは初期には非常にもろいため、創業者が自ら走り回る手間が成長の鍵になる
- 初期ユーザーに卓越した体験と満足感を提供することが、長期的な成長に重要である
- 開始段階では、自動化より手作業、ニッチ市場の攻略、直接的なコンサルティングなどが効果的である
序論: スタートアップ成長の実態
- 多くの起業志望者はスタートアップが自然に成長すると考えるが、実際には創業者が自ら前に出て成長の火種を起こさなければならない
- 昔の自動車の始動ハンドルのように、初期には労働集約的なプロセスが不可欠である
ユーザーを自ら獲得する（Recruit）
- ほとんどのスタートアップは、受け身でユーザーが来るのを待つのではなく、自ら探しに行く努力が必要である
- Stripeも初期には「Collison installation」という形で、ベータ版の紹介を受けた相手のノートパソコンを直接受け取ってインストールするという積極的なユーザー獲得戦略を使った
- 創業者がこうしたことを嫌がる理由は、拒絶への恐れ、羞恥心、少ないユーザー数の過小評価にある
- 実際には複利成長の効果により、週10%の成長を維持するだけでも2年後には数百万人のユーザーになりうる
- Airbnbもニューヨークで直接ホストを訪ね、登録を手伝うほど積極的だった
初期スタートアップのもろさ（Fragile）
- ほぼすべてのスタートアップは初期には非常に不安定であり、短期間の直接的な努力によって成功と失敗が分かれる
- 外部の評論家や投資家の無関心よりも、自分自身が自社の価値を過小評価することのほうが危険である
- 初期には「この会社は世界を変えるか？」ではなく、**「正しい努力をしたとき、どこまで大きくなれるか？」**を自分に問うべきである
- MicrosoftやAirbnbの創業初期も見た目にはごく小さかったが、それでも最善の道だった
- 適切なユーザーは自分と似た人たちから始めるか、初期ユーザーのうち最も熱心な層を見極めて、その集団を集中的に攻略すべきである
ユーザーの喜びを最大化する（Delight）
- ユーザー獲得だけでなく、既存ユーザーに極めて高い満足を与える並外れた努力も必要である
- Wufooは新規登録者ごとに手書きの感謝状を送るほど徹底した対応で初期の信頼を築いた
- 大企業のカスタマーサービスの常識に縛られず、創業初期だからこそ提供できるパーソナライズされた体験を強調すべきである
- 初期ユーザーを喜ばせる仕事が多すぎて手に負えないほどなら、それはむしろ望ましい成長のシグナルである
- 初期創業者のカスタマーサービス経験の不足は、小さな会社ならではの競争優位を十分に生かせない理由の一つでもある
ユーザー体験への執着（Experience）
- Steve Jobsの言う**「Insanely great」**のように、初期にはユーザー体験に執着する必要がある
- 初期製品の完成形よりも、不完全でもユーザーとの相互作用を通じた改善のほうが重要である
- ユーザーと直接向き合って得るフィードバックが成長に最も大きな影響を与える
市場を絞って始める（Fire）
- FacebookやAirbnbのように、**最初は意図的に非常に小さな市場（例: ハーバードの学生）**から始め、その集団の中で臨界量を達成する戦略を使う
- 最も反応の速いアーリーアダプター層を見つけることが、初期にはより効果的である
- YCのようなアクセラレータープログラムは、他のスタートアップを顧客にする市場アプローチにも有利に働く
ハードウェアスタートアップの特殊な戦略（Meraki）
- ハードウェアスタートアップは初期の量産コストが大きいため、MerakiやPebbleのように創業者が自ら製品を組み立てる
- 実際に自分で作ることで、設計の最適化や部品調達の方法など、経験的な学習が起こる
コンサルティング型の極端なユーザー接近（Consult）
- B2B製品では、特定の一社の顧客のためにコンサルティングするようにカスタムメイドし、その後で隣接市場へ拡張する
- 顧客が実際に必要としている問題に完全に合わせ込むプロセスの中で、成長の糸口が見えてくる
- 初期には顧客の代わりに自分たちでソフトウェアを使ってあげる、あるいは必要な機能をすぐ反映する方法もある
完全手作業戦略（Manual）
- ユーザー数が少ないうちは、手作業で業務を処理でき、その後段階的に自動化へ移行すればよい
- Stripeは初期に**「即時アカウント開設」を手作業**で処理し、ユーザー体験を実現した
- 最初から自動化に執着するのではなく、手作業を通じて製品と顧客の実際の課題を把握することが優先である
「大型ローンチ」の非効率（Big）
- 一度に大々的にローンチしたり、大企業との提携に成長を委ねる戦略はたいてい失敗する
- 初期は少数のユーザー確保に集中すべきであり、強い努力と直接的な方法のほうが重要である
- ユーザーの関心はゆっくりと、直接的な管理と満足の提供を通じて成長していく
スタートアップアイデアの二次元的アプローチ（Vector）
- 成功するスタートアップは、**製品（何を作るか）+ 非スケーラブルな戦略（最初に何を自分でやるか）**というベクトルで考える必要がある
- このような初期の直接行動は、製品のDNAに前向きな影響を残す
- 初期の直接的な努力は、時間がたつにつれて製品や組織文化へと転化され、持続的成長の原動力になる
1件のコメント
Hacker Newsのコメント
最近聞いたポッドキャストで本当に共感した話があった。スタートアップ最大の問題は慣性だという点だ。世の中は私たちのことをそれほど好んでもいないし、必要だとも感じていない……それをひっくり返さなければならない。完全にゼロからモメンタムを作る必要があり、創業者がやるべき本当に重要な仕事は、この慣性を逆転させる行動だ。これは物理的にも実際に起きていることだ。世界は止まった状態にあり、私たちは最初の始動のようにモメンタムを自力で生み出さなければならない。そう考えると、最初はスケールしない仕事をしていても不思議ではない。すでに動いている機械を最適化するのではなく、エンジンがきちんと回り始めるよう一つひとつ手で回してみる段階なのだ。Paul Grahamのポイントは、スケーラブルな成長や自動化はその次の問題だということだ。手作業でユーザー一人ひとりに会ってこそ、本当に何が効くのかを学べる。ユーザーが自分を必要な存在だと感じている証拠を積み上げながら、何がスケールに値するのかを証明していく過程だ
私が思うに、手作業の本当の価値は自分で直接学べることだ。ある顧客は、毎週重要な金融・証券ニュースを自ら選別して、キュレーションしたリストとして提供していた。小さなニッチの中のさらに小さなニッチだったが、ユーザーは本当に気に入っていた。ところがある時点ですべてを自動化しようとして、コンテンツは選別性のない大量配信になり、スパム的な情報も増えて価値が失われ、結局プロダクト自体も同じ道をたどった。より多くのニュースを載せるようになったが、直接選別・編集しなくなったことで、シグナルとノイズの比率は悪化した。実際には、手作業のほうが範囲は限られていてもずっと価値が高かった。多くの会社はそれを理解せず、早すぎる段階で自動化に執着してしまう。別の例として、競合の価格を手作業でチェックしていたクライアントがいた。自動化を望んでいたので、Excelベースの簡単なスクレイパーを作った。最初は満足していたが、競合サイトを自分で見て回ることで新製品やカタログのトレンドを学ぶ機会を逃していることに後から気づいた。結局また手作業で巡回するようになり、スクレイパーは単純な価格分析にだけ使われるようになった。しかし私の他の顧客の多くは、プロダクトや問題の本質よりも自動化ばかりを気にして、重要な学びの機会を逃し続けている
だからこそ「人々が欲しがるものを作れ」がスタートアップ業界の名言なのだ
「慣性を逆転させる仕事」という表現は本当に気に入ったが、このアプローチがすべてのスタートアップに当てはまるわけではない。SequoiaのArcフレームワークによれば、やり方は3つある。Hair on Fire（差し迫った痛みがあり、モメンタムが重要）、Hard Fact（痛みはあるが習慣を変えなければならない場合）、Future Vision（人々がまだそれが可能だと信じておらず、まず信頼を築く必要がある場合）だ。スケールしないことを自分でやって成果を出すのはHair on Fire分野では必須だが、残りは現実そのものを再構成したり、まず権威や信頼性を築いたりする必要がある
私の理論では3段階に分けられる。Not Scaling（スケール前）、Scaling（スケール）、そしてAntiscaling（嫌われる段階）だ。Not Scalingは市場で自分だけのmoatを築く段階だ。Scalingはプロダクトが十分に人気を得て、顧客が新たな顧客を呼び込み、あとはサーバーやDBの分割で増える需要を処理すればよい時点だ。Antiscalingは、現代のWebの問題点となった企業のように変質するときだ。情報機関がテロリスト利用の問題で連絡してきたり、市や政府がライセンスや規制法を新たに作って直接ターゲットにしてきたりする段階だ。創業者が有名になってミーム化され、位置追跡までされる状況でもある。世界を支配する必要はなく、金を稼げばいい。世界を変えると息巻く人ほど実際に良い結果を出すことは少ないので、ただ使えるものを作るのが大事だ
「ただ金を稼げばいい」という言い方は、ある指標（たとえば収益）が目標になると、その指標は良い測定値ではなくなるというGoodhart’s Lawを思い出させる
この見方は偏りすぎているように感じる。誰も望まないものを作ったときの極度の無関心はここでは扱われていない。そして実際にもっとよくあるのは、ごく普通に少しだけ成功したケースだ。誰にも嫌われないが、熱狂的に愛されることもない。やや好意的ではあるが、ハイプも独占的な競争力もなく、誰も特に気にかけないケースが一番多い
関連事例をもっと集めたくて、以下にリンクを置いておく
Ask HN: PG's 'Do Things That Don't Scale' manual examples? - 2023年10月（コメント316件）
Do Things that Don't Scale (2013) - 2021年2月（コメント31件）
PG: “Do Things that Don't Scale” – What are some examples? - 2021年1月（コメント2件）
Ask HN: How did you 'do things that don't scale' for your B2B startup? - 2017年9月（コメント9件）
Do Things That Don’t Scale (2013) - 2017年8月（コメント37件）
Do Things that Don't Scale - 2013年7月（コメント207件）
Show HN: A directory of startups that did things that don't scale - 2024年9月（コメント12件）、Ask HN: What are some hacks of real founders who did things that don't scale? - 2018年11月（コメント267件）、Why we're doing things that don't scale - 2013年7月（コメント34件）
Scalability is overrated - 2023年2月（コメント232件）
すべての初期創業者と、初期メンバーとして参加した社員の両方に勧めたい内容を共有する。私たちは15人を超える規模になった今でも、新規登録者ごとに毎回直接電話をかけている。理由は、1) どうやって私たちを知ったのか、2) 初回利用に助けが必要か、3) （暗黙に）私たちのチームが直接気にかけていることを伝えるためだ。私たちのサービスはB2Bプラットフォームなのでよりうまく機能している気もするし、相手は開発者なのだが、実際に電話してみると「いえ、営業電話をしようとしているわけではありません」という点さえ越えれば、本当に率直で良い話がたくさん聞ける
Paul Grahamを批判する声は多いが、この文章自体は要するにpremature optimization（早すぎる最適化）をするな、という話に要約できる。つまり、大企業のように振る舞うなという意味だ。創業者が自ら実務をやれば、非効率であっても実戦経験とフィードバックを積めるし、スケーラブルなソリューションを最初から早々に導入しないことで、むしろ早くフィードバックを得られることもある。そして自分なりの差別化を作るのにも有効だ。「スケールしないことをやれ」という言葉は文字どおり頭に刻んでおくといいと思う
過度の人気や需要によってサービスが耐えられず崩壊するのではと心配して、実際にはまったく必要のない段階から過剰にスケーラブルなシステムを作ってしまうことが多い。だが私は、垂直スケーリング（単にリソースを足す方式）がひどく過小評価されていると感じる。既存のモノリシックなバックエンドに資源を追加するだけでも、サービスをきちんと理解する時間は稼げる。何より、実際にユーザーが私たちのプロダクトで好んでいる「核となる価値」が何なのかを考え直すきっかけになる。また、ユーザーが本当に自分たちのプロダクトを愛していれば、初期は多少性能が足りなくても理解してくれる。Twitter初期には「fail whale」が頻繁に出ていたが、欲しい機能さえしっかりしていたので爆発的に成長した。初期段階では、素早いフィードバックと反復、そして顧客満足がすべてだ。スケールよりも、実験、ユーザーとの対話、観察が先だ。これはまさに勘が働いたときに初めてスケールを考えるべきで、そのタイミングは予測できない。技術はただの道具でしかなく、高級なバイオリンがあっても、何より先に「良い音楽」を作らなければならない
すべての成功したビジネスが数百万、数十億ユーザーを対象にしているわけではないことを忘れてはならない。私は内部ツールを作る仕事をしているが、私たちの環境の規模はすでに決まっており、パフォーマンスにもそれほど敏感ではなく、不規則なトラフィックもない。それなのに、チームの一人に、ほんの数ミリ秒縮めるためだけに、自分しか分からない言語で全コードを書き直すことに執着した人がいた。誰も気にしておらず、彼が作ったものには保守上のリスクしか残らなかった。彼が退職すると管理者の判断で全面的に廃棄されたが、もっと単純で遅い設計だったなら、他の人でも引き継ぎははるかに容易だったはずだ
「premature optimization」と「Do Things That Don’t Scale」は微妙に違う。前者はスケーラブルなバージョンが「最適」であることを前提にしているが、後者はスケールしないやり方のほうがむしろ最良かもしれないことを示唆している。たとえば、CEOが自ら窓口になるやり方は、すべてをさばく共有受信箱よりはるかに良いことがある。スケールするやり方（問い合わせフォーム）は、最初から最適化されたものではなく、実際にはプロセス品質の低下なのだ。スケーリング自体が悪というわけではないが、避けがたく伴う複雑さと、顧客との距離の広がりがある。状況によってはプロセスが悪化しうることを認識すべきだ。私の考えでは、「premature process degradationを防げ」というメッセージに近い
結局のところ「まだ存在しない問題を先回りして解こうとするな」に要約できる
「大企業のように振る舞うな」という助言は、正直どんな規模の組織にも当てはまる。私はコンサルタントとして、スタートアップや中小企業が法人だからというだけで、大組織向けのルールやポリシーを導入しようとするたびに、それを止めるのに多くの時間を使っている。そうしたポリシーは数百人規模で初めて必要になるもので、小さな組織ではむしろ足かせになる。たとえばk8s、nosql、必要以上に厳しいセキュリティポリシーなどだ。Netflixの社内カルチャーガイドもこのことをよく示している。小さな組織なら、採用をきちんとしたことを前提に、本当の意味で権限委譲を行い、チームメンバーそれぞれが判断できるようにすべきだ。問題やリスクが実際に大きくなるまでは、あえてすべてを規則で縛る必要はない
StripeはYCポートフォリオの中でも最も成功した会社の一つだが、Stripeが解決した問題は本当に切実で緊急性の高いものだった。誰もがユーザーを待つ側に回りそうな状況で、Stripeはむしろ非常に攻撃的なユーザー獲得で知られていた。当時は12年前で、ここまで大きく成長するとは思っていなかった。あのとき投資できていたら本当によかっただろう
もちろんsurvivor biasがあるのは事実だ。だが、自分で実際にやってみて、自動化しない時期そのものが重要だという点には完全に同意する。そうしてこそ、プロセス全体やシステムをより精密に頭に刻み込めるのであって、これは単なるスライドや文書では不可能だ。そして今の言い方をすれば、「テイスト」を身につける過程とも呼べる。何が良いのか、なぜ良いのかという感覚が自分の中に生まれ、他の人なら考えもしない意思決定の分岐点で、はっきりした視点を持てるようになる時期だ。最近はAIがあるので、あまりにも早く自動化へ飛びつこうとするところが多いが、http://socratify.comでもコンテンツは手作業で作っている。みんなAIで作るべきだと言うが、私たちの主目的は文脈と品質をきちんとキュレーションすることにある。検証プロセスは将来的にある程度自動化できるかもしれないが、人間の頭脳と洞察を完全に置き換えるのは無理だということを、実際に間接的に何度も体験している/
YCがシード資金調達をはるかに容易にしたおかげで、ゲームのルールが変わった。Paul Graham、Jessica Livingston、そしてYCチームが既存システムの問題を正しく見抜き、それを修正したと私は確信している。YC以前はシード調達はほとんど不可能に近かった。不平等で、まるで古びた銀行のオフィスで怒ったパートナー8人を相手にプレゼンするようなものだった。功績があるなら正当に認めるべきで、この市場を是正したのは彼らだ
OpenAIのような大企業が「Do Things That Don’t Scale」を真剣に読んで、実際に参考にしていてほしかった。あれほどの資本があるなら、必要なデータライセンスを正当に購入することもできたはずだ。だが彼らはスケールするやり方、つまり scraping や stealing だけを選び、少し多めに奪って使っても結局はバレないか、問題提起が来るとしても後からだろうと期待していたように見える。今のコンテンツ制作者たちが、自分たちの作品がAI学習データとして使われていることすら知らず、その対価を一銭も受け取れない状況が、そのままやり過ごされることを願っていたわけだ
この文章はHacker Newsで最初に読んだ記事だった。ときどき再浮上するたびに昔の記憶がよみがえる