デフォルトで生き残るか、デフォルトで死ぬか？
2015年10月
8〜9ヶ月以上運営しているスタートアップと話す時、私がまず知りたいことはほぼ同じです。彼らの経費が一定で、収益成長がここ数ヶ月と同じだと仮定すると、彼らは残っている資金で利益を出すことができるのか？あるいは、もっと劇的に言えば、デフォルトで彼らは生き残るか、死ぬか？
驚くべきことは、創業者自身が知らないことがどれほど多いかです。私が話す創業者の半数は、自分たちがデフォルトで生き残るのか、死ぬのかを知りません。
もしあなたがその中の一人なら、Trevor Blackwellが便利な計算機を作っています。
私がまずスタートアップがデフォルトで生き残るか、死ぬかを知りたい理由は、その後の会話が答えに依存するからです。もし会社がデフォルトで生き残るなら、彼らができる野心的な新しいことについて話すことができます。もしデフォルトで死ぬなら、おそらくそれをどう救うかについて話す必要があります。現在の軌道が悪い結果で終わることを知っています。彼らはどうやってその軌道から外れることができるでしょうか？
なぜこれほど少ない創業者しか自分たちがデフォルトで生き残るか、死ぬかを知らないのでしょうか？主に、彼らがそれを問うことに慣れていないからだと思います。それは初期には意味をなさない質問で、3歳の子供に自分をどう支えるつもりかと尋ねるのと同じくらい意味がありません。しかし、会社が成長するにつれて、その質問は無意味から重要に変わります。その種の変化はしばしば人々を驚かせます。
私は次の解決策を提案します：デフォルトで生き残るか、死ぬかを問い始めるのが遅すぎるのではなく、早すぎるくらいに始めてください。質問が極性を変える正確な時期を言うのは難しいです。しかし、デフォルトで死ぬことを心配し始めるのが早すぎるのはおそらくそれほど危険ではありませんが、心配し始めるのが遅すぎるのは非常に危険です。
その理由は、私が以前に書いた現象です：致命的なピンチ。致命的なピンチは、デフォルトで死ぬ + 成長が遅い + それを修正する時間が十分にないことです。そして、創業者がそれに陥るのは、自分たちがどこに向かっているのかを認識していないからです。
創業者が自分たちがデフォルトで生き残るか、死ぬかを自問しないもう一つの理由は、もっと簡単にお金を調達できると仮定しているからです。しかし、その仮定はしばしば誤りであり、さらに悪いことに、それに依存すればするほど、それはより誤りになります。
事実と希望を分離することが助けになるかもしれません。漠然とした楽観主義で未来を考えるのではなく、明示的にコンポーネントを分離してください。「私たちはデフォルトで死ぬが、投資家に救われることを期待している」と言ってください。そう言うとき、それが私の頭の中で鳴るのと同じ警報をあなたの頭でも鳴らすかもしれません。そして、警報を十分に早く鳴らせば、致命的なピンチを避けることができるかもしれません。
投資家があなたを救うことを期待できるなら、デフォルトで死ぬのは安全でしょう。原則として、彼らの興味は成長の関数です。もしあなたが急激な収益成長を持っているなら、たとえば年間5倍以上なら、利益が出ていなくても投資家が興味を持つことを期待し始めることができます。[1]しかし、投資家は非常に気まぐれなので、彼らを期待し始める以上のことはできません。時には、あなたのビジネスについて何かが投資家を怖がらせることもあります、たとえあなたの成長が素晴らしくても。だから、あなたの成長がどれほど良くても、資金調達を計画A以上に安全に扱うことはできません。あなたは常に計画Bも持っているべきです：もしもっとお金を調達できなかった場合に生き残るために正確に何をする必要があるか、そして計画Aがうまくいかない場合にいつ計画Bに切り替える必要があるかを（書き留めるように）知っているべきです。
いずれにせよ、急速に成長することと安く運営することは、多くの創業者が仮定するような鋭い二分法からは程遠いです。実際には、スタートアップがどれだけ支出するかとどれだけ急速に成長するかの間には驚くほどつながりがありません。スタートアップが急速に成長するとき、それは通常、製品が何かの大きな需要に直接当たったためです。スタートアップが多くを支出するとき、それは通常、製品の開発や販売が高価であるか、単に彼らが無駄遣いをしているためです。
注意を払っているなら、この時点で致命的なピンチをどう避けるかだけでなく、どうやってデフォルトで死ぬことを避けるかを尋ねているでしょう。それは簡単です：採用を急ぎすぎないでください。採用を急ぎすぎることは、資金を調達したスタートアップの最大の殺し屋です。[2]
創業者は、成長するために採用が必要だと自分に言い聞かせます。しかし、ほとんどの人はこの必要性を過小評価するよりも過大評価する側に誤ります。なぜ？一部にはやるべきことがたくさんあるからです。ナイーブな創業者は、十分な人を雇えば、すべてが終わると考えます。一部には、成功したスタートアップには多くの従業員がいるので、成功するためにそうするのが当然のように思えるからです。実際、成功したスタートアップの大規模なスタッフは、おそらく成長の原因というよりも結果です。そして一部には、創業者が成長が遅いとき、通常の本当の理由に向き合いたくないからです：製品が十分に魅力的ではない。
さらに、資金を調達したばかりの創業者は、彼らに資金を提供したVCによって採用を急ぎすぎるように励まされることがよくあります。殺すか治すかの戦略は、ポートフォリオ効果によって保護されているため、VCにとって最適です。VCは、ある意味であなたを爆破したいと思っています。しかし、創業者としてのあなたのインセンティブは異なります。あなたは何よりも生き残りたいと思っています。[3]
スタートアップが死ぬ一般的な方法は次のとおりです。彼らは中程度に魅力的なものを作り、最初はまともな成長を遂げます。彼らは最初のラウンドをかなり簡単に調達します、なぜなら創業者は賢そうで、アイデアはもっともらしく聞こえるからです。しかし、製品が中程度に魅力的であるため、成長はまあまあですが、素晴らしくはありません。創業者は、多くの人を雇うことが成長を促進する方法だと自分たちを納得させます。彼らの投資家も同意します。しかし（製品が中程度に魅力的であるため）成長は決して来ません。今、彼らは急速に滑走路を走り尽くしています。彼らはさらなる投資が彼らを救うことを望みます。しかし、彼らは高い支出と遅い成長を持っているので、今では投資家にとって魅力的ではありません。彼らはもっと調達することができず、会社は死にます。
会社がすべきだったことは、根本的な問題に対処することです：製品が中程度に魅力的であること。人を雇うことはそれを修正する方法ではありません。多くの場合、それはそれをより難しくします。この初期段階では、製品は「構築される」よりも進化する必要があり、それは通常、少ない人々の方が簡単です。[4]
自分がデフォルトで生き残るか、死ぬかを尋ねることは、これからあなたを救うかもしれません。おそらくそれが鳴らす警報は、あなたを採用急ぎに押しやる力に対抗するでしょう。代わりに、あなたは他の方法で成長を求めることを強いられるでしょう。例えば、スケールしないことをすることによって、または創業者だけができる方法で製品を再設計することによって。そして、多くの、もしなくてもほとんどのスタートアップにとって、これらの成長への道は実際に機能するものです。
Airbnbは、Y Combinatorの終わりに資金を調達した後、最初の従業員を雇うまで4ヶ月待ちました。その間、創業者はひどく過労でした。しかし、彼らはAirbnbを現在の驚くほど成功した組織に進化させるために過労していました。
注記
[1] 急激な使用成長も投資家の興味を引きます。収益は最終的には使用の一定の倍数になるので、x％の使用成長はx％の収益成長を予測します。しかし、実際には投資家は単に予測された収益を割り引くので、使用を測定している場合は、投資家に印象づけるためにより高い成長率が必要です。
[2] 資金を調達しないスタートアップは、採用を急ぎすぎることから救われます、なぜなら彼らはそれをする余裕がないからです。しかし、それはこの問題を避けるために資金調達を避けるべきだという意味ではありません、アルコール依存症になるのを避ける唯一の方法が完全な禁酒であるというのと同じくらいではありません。
[3] VCが創業者に採用を急ぎすぎるように促す傾向が、彼ら自身の利益にさえならないことに私は驚かないでしょう。彼らは、過剰支出によって殺される会社のどれだけが、生き残っていたらうまくいったかもしれないかを知りません。私の推測では、かなりの数です。
[4] 草案を読んだ後、Sam Altmanは書きました：
「私はあなたが採用のポイントをもっと強くするべきだと思います。YCの最も成功した会社は決して最も早く採用したことがなく、偉大な創業者の印の一つはこの衝動に抵抗できることだと、ほぼ正しく言えると思います。」
Paul Buchheitは追加します：
「私がよく見る関連する問題は、時期尚早なスケーリングです—創業者は、本当に機能していない小さなビジネス（通常は悪い単位経済）を取り、それから印象的な成長数を得たいためにそれをスケールアップします。これは採用急ぎと似ていて、一度大きくなるとビジネスを修正するのがはるかに難しくなり、さらに彼らは非常に速く現金を失います。」
感謝 Sam Altman、Paul Buchheit、Joe Gebbia、Jessica Livingston、そしてGeoff Ralstonに、この草案を読んでくれたことに感謝します。