自分をだまして、リリースを遅らせた話
多くのソフトウェア創業者が失敗する理由は、実に単純です。リリースが遅すぎるのです。何年も外部の反応を得ないまま製品を開発し続け、初めて本物の顧客が触れた瞬間に、製品が崩れ去るのです。
Indie Hackers podcastでは、そうした話が数多く紹介されています。この番組の掲げる使命は、スタートアップ創業者の失敗からリスナーが学べるようにすることです。ところが、ホストのCourtland Allenは、それが本当に可能なのかという実存的な苦悩を、たびたび口にします。
……どれだけ何度も、顔が青ざめるほど繰り返し人に言い聞かせられることでも、相手は聞く耳を持たなかったり、こちらの言っていることを本当の意味では理解しなかったりすることがあります。結局、自分で失敗して、苦労してその意味を思い知るまで、理解できないのです。
—Courtland Allen、Indie Hackers Podcast
私はいつもこう思っていました。「いや、Courtland。それは非効率でしょう。私は無料で得られる教訓をありがたくいただいて、お金のかかる失敗はしないことにしますよ」
この記事のタイトルを見れば、私の計画がうまくいかなかったことはおわかりでしょう。
製品のアイデア
そのアイデアを思いついたのは、自分史上最もひどいコードを眺めていたときでした。昨年作ったレシピ検索ツールのコードです。そのアプリは結局軌道に乗りませんでしたが、ときどき手を入れるのは楽しいものでした。コードベースの中には、いつも私を悩ませる部分が一つありました。材料のパースです。
"2 cups finely chopped red onions"のような文字列を受け取ったら、アプリは2が数量で、cupsが単位であることなどを判別しなければなりません。
材料を構成要素に分解する
最初のうちは単純だったパース処理も、新たなエッジケースが現れるたびに、壊れやすく複雑になっていきました。やがてロジックは、正規表現の悪夢のような迷宮へと変わっていきました。正規表現とは、テキストを処理するための指示であり、強力である一方、読むのが非常に難しいことで有名です。
私が書いた正規表現コードの一部
すべてを捨てて機械学習による解決策に置き換えたくもなりましたが、それには膨大な作業が必要です。収益を生んでいないウェブサイトの小さな機能に、何か月も開発期間を費やすわけにはいきませんでした。
そこで、ふと思いつきました。材料のパースそのものをビジネスにしたらどうだろう？ 私が困っているのなら、ほかの開発者もきっと同じことで苦労しているはずです。その中には、うまくいってお金を稼いでいる人もいるでしょう。私が問題を解決すれば、そのお金の一部を私に払ってくれるかもしれません。こうして、材料パースサービスZestfulのアイデアが生まれました。
Zestful、レシピ材料のパースサービス
そうならなかったMVP
リーンスタートアップの世界では、「MVP」、つまり実用最小限の製品という言葉が頻繁に登場します。MVPとは、アイデアを最も単純な形にしたものです。できるだけ早く作り、潜在顧客に使ってもらい、その反応から本当の問題を解決できているか判断することになっています。
よくある失敗談の一つに、自分のアイデアを確信するあまり、MVPを作らない創業者の話があります。その代わり、誰も欲しがらない完成版の製品に何か月、何年も費やしてしまうのです。
私はZestfulで、実際にMVPを作りました。終わりのない調整や改善の沼に消えてしまわないよう、受け入れ基準まで最初に定めました。
材料パーサーの受け入れ基準
約120時間の開発作業を終え、動作するプロトタイプは受け入れ基準を満たしました。
しかし、正式にローンチしたのは、それからさらに2か月後でした。その間、私はコードを書き続けていたのです。
営業のためのコードだから大丈夫
MVPが「完成」したあと、なぜそんなに長いあいだ空回りしていたのか、疑問に思うかもしれません。その2か月間、私がどんなことを考えていたのか、まとめるとこうなります。
1日目：受け入れ基準を達成
サービスは動く！ ただし、顧客が使うにはコマンドラインで複雑な式を書かなければならない。
Web 3.1の時代に、顧客に
curlコマンドを書かせる屈辱を味わわせていいのか？ シンプルなHTMLフロントエンドを追加すれば、顧客はブラウザから直接サービスを試せる。
5日後
基本的なフロントエンドは動くようになった。でも、何の説明もなくHTMLフォームだけがぽつんと置かれているのは変だ。
このフォームを中心にウェブサイトを作る必要がある。でも、実に単純なサイトだ。作業は1日で終わるだろう。
4日後
よし、すばらしい！ サービスにウェブサイトができた。
……でも、各フィールドを説明するドキュメントページがない。これは今日の午後に片づけられる。
2日後
ページが増えすぎて、モバイル端末ではナビゲーションバーから項目がはみ出している。
ナビゲーションバーをレスポンシブ対応にしよう。ウェブフレームワークのAngularを使えば、1時間もかからないはずだ。
まるでヒドラでした。「あと一つだけ簡単なもの」を追加し終えるたびに、その結果として必要になる別の作業が二つ現れるのです。結局、コードの完成を宣言してから2か月が過ぎていました。私は何もリリースできていないことに唖然としました。
重要だけれど、今すぐでなくてもいい
私はローンチしなければなりませんでした。しかし、重要な作業のリストはまだ終わっていません。完了まで5日かかると見積もっていました。
その後、面白いことに気づきました。一刻も早くリリースすると決めたことで、「あったほうが重要なもの」と「ローンチに必要なもの」は違うのだとわかったのです。
その一例が利用規約でした。利用規約なしでローンチして、数日後に書いたらどうなるでしょうか？ 最悪の場合、法的な争いが起きたときにこちらの立場が弱くなるでしょう。しかし、ローンチから数日以内に誰かが私を訴える可能性は、どれほどあるでしょうか？
黙ってローンチしろ
タスクリストの各項目について、私は自分にこう問いかけました。「これなしでローンチしたら、何が起きる？」利用規約のときと同じように、容赦なく疑ってかかることで、本当のローンチチェックリストができあがりました。それから24時間もたたないうちに、私はAPIマーケットプレイスのRapidAPIでZestfulを公開しました。サービスが稼働したのです！
RapidAPIマーケットプレイスのZestful掲載ページ
ここが正念場でした。私のサービスは、本物の顧客から料金を受け取れる状態になっていました。あとは、顧客を説得して買ってもらうだけです。
拒絶を避けるためにローンチを遅らせたのか？
「完成」してから「ローンチ」するまでの2か月間、友人に、顧客に製品を見せるのが怖いのではないかと聞かれました。作業を次々に追加してローンチを遅らせていたのは、拒絶を避けるためだったのでしょうか？
その可能性は頭をよぎりましたが、私はすぐに否定しました。以前は営業の仕事をしていて、顧客に電話をかけ、1日に40回「ノー」と言われていました。拒絶など怖くありません。
ローンチ当日、私は初めてのコールドピッチを書くために机に向かいました。相手は、私のことを知らないレシピアプリの開発者です。なぜその人が自分のアプリに私の材料サービスを組み込むべきなのか、説明しなければなりません。
私は30分間、何も書かれていない画面を見つめ、どうにか文章を書こうと苦戦していました。友人たちには自分のサービスを何十回も説明してきましたが、今回は違います。売り文句を一つ思いつくたびに、顧客からの手厳しい反論を想像してしまうのです。
それに、あなたの提示する価格を払う価値があるの？
それで私の利益がどう増えるの？
そもそも、なぜあなたが必要なの？
まずい。私は本当に拒絶を恐れていたのです。
別の種類の拒絶
これは、営業の仕事とはまったく違いました。その仕事では企業に光ファイバーのインターネットを売っていましたが、光ファイバーを敷設したりネットワークを設計したりするのは私ではありません。だから、拒絶されても気にせず受け流せました。
今度は、自分が作ったものを売っています。しかも、自分が作ったソフトウェアです。ソフトウェアを書くことは、私のアイデンティティの大きな部分を占めています。これほど得意で、これほど誇りを持っているものは、ほかにありません。自分の製品を顧客に見せたら、こう思われるかもしれない。「これはあまり良くない。あなたはこれを売ろうとしている。つまり、良いものだと思っているはずだ。ということは、あなたは大したことがない」
厳しい現実
何十件も売り込み、いくつか会話を重ねても、購入者は一人も現れませんでした。そのとき私は、顧客が欲しがらない製品に何か月も投資した、あの開発者になっていたのだと気づきました。
私のようなサービスを使える企業はありました。しかし、最も必要としていた企業は、すでに自前で同じものを作っていました。それ以外の企業も、便利なサービスだとは認めてくれましたが、月額20ドルにすぎないのに、その費用を正当化できませんでした。
そこで、私の戦略に致命的な欠陥があることがわかりました。顧客にとって最も大きなコストは、私が請求する月額料金ではありません。サービスを組み込むためにアプリを改修するコストだったのです。
そのうえ、外部依存を一つ増やすコストも考えなければなりません。私のサービスが停止したらどうなるのか？ 顧客のアプリも止まってしまうのか？ それとも、私のサービスが失敗したときに備えて、別の動作モードを丸ごと構築する必要があるのか？
順番を逆にしていた
振り返ってみると、私の進め方は逆でした。顧客へのコールドピッチを最後のステップにしていましたが、コードを1行書く前にやるべきだったのです。
当初、私は製品を先に作る判断を理屈で正当化していました。顧客はアイデアには賛成しても、製品を決して買わないかもしれません。私は「イエス」を、顧客がサービスを購入して同意を示す、本当の売上にしたかったのです。
その考え方自体は今でも正しいように感じます。しかし私は、「ノー」にも価値があることを考えていませんでした。コンセプト段階で顧客に拒絶されたなら、製品を作り上げたあとで気が変わることはありません。全員がノーと言うなら、おそらくその先に道はありません。
Samantha Mason編集。イラスト：Loraine Yow。