コードを1行も書く前にSaaSのアイデアを検証する方法

人々があなたのソフトウェアを欲しがるかどうかを知る最も高くつく方法は、それを作ってしまうことです。ところが、初めての創業者の多くがまさにそれをやってしまいます。半年と貯金を費やしてアイデアをコードに変え、静寂の中でローンチし、そこでようやく「これを必要とした人はいたのか」と問い始めるのです。検証とは、その教訓の安価な版です。1年という人生ではなく、数週間の対話という対価で答えを買う方法なのです。

私は多くの賢い人々が同じ罠にはまるのを見てきました。彼らには本当に優れた観察があります。よく知る業界における本物の不満です。そして、観察と製品の間にある隔たりは単なる技術の問題だと思い込みます。しかし、そうではありません。その隔たりは答えのない問いで満ちています。他の誰かが、お金を払うほど強くこの痛みを感じているのか? 今やっていることから乗り換えてくれるのか? お金を燃やさずに彼らに届けられるのか? これらの問いはコードを書いても答えは出ません。人々と話し、彼らが実際に何をするかを観察することで答えが出るのです。

ですから、これは創業者が誰かを雇って何かを作らせる前に私が渡すガイドです。リーンスタートアップの芝居やキャンバスの記入の話ではありません。あなたのアイデアに脈があるかを教えてくれる、ひと握りの正直で安価な実験についての話です。そして、たとえ痛くても結果を信じる規律についての話です。

なぜ先に作ることが生産的に感じられ、たいていそうでないのか

作ることは魅力的です。目に見える前進のように感じられるからです。コーディングのセッションの終わりには、動く画面、何かをするボタン、パートナーに見せられる物があります。問題について見知らぬ人と話しても、形に残るものは何も生まれません。気まずく、遅く、終わってもメモしか残りません。だから創業者はキーボードに手を伸ばします。キーボードのほうが早く報いてくれるからです。

厄介なのは、動く画面はアイデアが正しいかどうかをほとんど何も教えてくれないことです。誰も抱えていない問題に向けて、美しくバグのない製品を作ることもできますが、それは醜い製品と同じくらい死んでいます。コードは「どうやって届けるか?」への答えであって、「これを欲しい人はいるのか?」への答えではありません。 2つ目に答える前に1つ目に何か月も費やすこと、それこそが優秀な技術者が架空の問題に対する優雅な解決策を作ってしまう道です。

検証は順序を逆にします。開発に踏み切る前に、数週間とごくわずかな費用で、アイデアの中で最もリスクの高い前提を証明、あるいは反証します。アイデアが強ければ、証拠とより明確な仕様、そして待ち構える最初のユーザーとともに開発に入れます。弱ければ、製品の対価ではなく、数杯のコーヒーとランディングページの対価でそれを知ることができます。

すべてを台無しにしかねない、たった1つの前提を見つける

あらゆるSaaSのアイデアは信念の積み重ねの上に成り立っており、それらは等しく危険なわけではありません。安全なものもあります。「人々はメールを使う」「小さな会社は書類仕事を嫌う」。一方で、事業全体が依存する賭けもあり、それが間違っていれば、ほかは何も意味を持ちません。検証の仕事はすべてを試すことではありません。最もリスクの高い前提を見つけ、まずそれを攻めることです。

それを見つけるには、アイデアを1つの文に書き出してください。「[この人たち]は[この問題]を、[今やっていること]の代わりに[この解決策]にお金を払うほど強く抱えている」。そして自分に容赦なく問います。この文の中のどの語が偽だと分かれば、アイデアは沈むのか? たいていそれは解決策ではありません。問題がお金を払うほど痛いのか、あるいはそもそも手の届く費用でその人たちに届けられるのか、という点です。

この順序づけが大切なのは、各段階で検証の費用が上がるからです。問題のインタビューは無料です。支払い意思のテストはランディングページ分の費用です。解決策のテストにはクリック可能な試作品が要るかもしれません。開発はすべての中で最も高くつくテストです。高く遅く失敗するのではなく、安く早く失敗したい――だからこそ、最も安く最も致命的なテストを前に置くのです。

人と話す――ただし正しいやり方で

あなたができる最も有用な一手は、その問題を抱えていると思える人々と話すことです。友人でも、ほかの創業者でもなく、これを使うであろう実在の人々です。そして、ほとんどの試みを台無しにする落とし穴がここにあります。人は礼儀正しいのです。「Xをするツールを使いますか?」と尋ねれば、ほぼ全員が「はい」と答えます。はいと言うのは無料で親切だからです。その「はい」は無価値です。どんな技術的失敗よりも多くのスタートアップを沈めてきました。

対処法は、未来について尋ねるのをやめ、過去について尋ね始めることです。未来は人が親切心で嘘をつく場所、過去は真実が宿る場所です。「これを使いますか?」ではなく、「この問題に最後に直面したときのことを聞かせてください」と尋ねます。何をしたか? どれくらい時間がかかったか? いくらかかったか? 解決策を探したか? お金を払ったか? 実際の行動は、毎回、仮定上の熱意に勝ります。

正直な答えを引き出す質問

• 「これが最後に起きたときのことを順を追って聞かせてください」――理想化されたものではなく、本物の作業の流れが浮かび上がります。
• 「それに対して何をしましたか?」――本当に気にしているのか、ただ受け流しているのかが見えてきます。
• 「それにどれだけの時間やお金がかかりましたか?」――漠然とした痛みを数字に変えます。
• 「以前これを直そうとしたことは? どうなりましたか?」――予算と意思があるかを教えてくれます。
• 「いま、これより面倒なことは何ですか?」――あなたの問題がそもそも上位5つに入るかを確かめます。

会話は何回必要でしょうか。思うより少なくて済みます。適切な人々と正直でうまく運んだインタビューを10回もすれば、たいていパターンは明らかになります。そのうち3、4人が目を輝かせ、痛みを生き生きと語り始めるか――あるいは全員が礼儀正しく生ぬるく、どんな巧みな開発もそれを直せないか、です。信頼できる判断を下すには、12回から15回もあれば十分です。

実際の需要を安く試す方法

会話は問題が本物かを教えてくれます。次の問いは、人々が行動するかどうかです。それを知る唯一の方法は、製品が存在する前に小さなコミットメントを求めることです。ここで検証は少し気まずくなり、同時に正直になります。話すのは安い。クリック、メールアドレス、あるいは内金はそうではありません。

これらのテストを行うのに何かを作る必要はありません。約束を明確に説明し、1つの具体的な行動を求める1枚のページがあればよいのです。その行動がデータです。人々があなたの売り込みを読んで何もしなければ、それが答えです。半年後に静寂に向けてローンチするより、はるかに安い答えです。

1. 1
   1ページの売り込みを掲げる

   問題とあなたの解決策を平易な言葉で説明し、明確な行動喚起を1つ添えます。シンプルなランディングページで十分です――まだ背後に製品はなくて構いません。
2. 2
   本物のシグナルを求める

   「いいね」ではありません。メールアドレスでの順番待ち登録、予約注文、または通話の予約を人々に求めます。はいと言うコストが高いほど、その「はい」の意味は大きくなります。
3. 3
   正直なトラフィックを少し流す

   あなたの本物の対象がすでにいる場所で共有します――関連するコミュニティ、小さな広告、いくつかのダイレクトメッセージ。応援してくれる人脈ではなく、見知らぬ人を求めましょう。
4. 4
   褒め言葉ではなく転換率を読む

   申し出を本当に理解した全員のうち、何人が行動したか? 適切な人々からのひと握りの本物の登録は、千の漠然とした激励に勝ります。

すべての中で最も強力な需要テストは、前払いを求めることです。先行販売、有料パイロット、早期アクセスへの内金――財布が開くものなら何でも。攻めているように感じられますが、自分自身のためにできる最も正直なことです。まだ存在しない製品にわずかな額でも手渡す人は、どんなアンケートにも語れないことを教えてくれます。そういう人を3、4人見つけられたら、もはやアイデアではありません。作られるのを待つ事業を手にしているのです。

作る前に売る

「人々は興味がある」と「人々は毎月お金を払う」の間には、それ自体に注目する価値のある一歩があります。自動化する前に、価値を手作業で届けることです。あなたのアイデアが、たとえば乱雑な仕入先メールをきれいな週次レポートに変えるツールなら、まず3、4社の顧客に対してそれを手でやってみてください。あなた自身がソフトウェアになるのです。遅く、規模化できません――それが狙いです。コードに固める前に、製品が実際に何をすべきかを学べるのです。

これは一度に2つのことをします。人々がアイデアそのものではなく成果にお金を払うことを証明します。そして本物の作業の流れを教えてくれます――端の事例、例外、インタビューでは決して推測できなかった、顧客が気にかける細部です。実際に作るころには、あなたは仕様を当て推量していません。すでに手でこなし、対価を得たプロセスを符号化しているのです。

シグナルを正直に読む

これらすべては、結果を信じる覚悟がある場合にのみ機能します。そしてそれは聞こえるより難しいのです。この時点で、あなたはもうアイデアに愛着を抱いているからです。危険なのは悪いデータではなく、あらゆるシグナルを励ましと解釈する創業者です。生ぬるい関心が熱意として記憶されます。礼儀正しい順番待ち登録が「強い需要」になります。ここでは自分自身の楽観と闘わなければなりません。

あらかじめ合格の姿を決めておくと役立ちます。テストを行う前に、続行させる結果と中止させる結果を書き留めておきます。「インタビューのうち、これを本物の繰り返し起きる問題だと語る人がX人未満なら、やめる」。データを見る前に基準を決めておくことが、やるべきでない開発へ自分を言いくるめないための、唯一の信頼できる防御です。

そして時には、正直な答えは「ノー」です。それは失敗ではなく、仕組みが働いている証です。「これは作るな」を決して返せない検証プロセスは、検証ではなく許可探しです。長いキャリアで勝ち続ける創業者は、悪いアイデアを一度も持たない人ではありません。悪いアイデアを、1年もかけて世話するのではなく、3週間と数百ユーロで葬る人たちです。

本当に作る準備が整ったとき

シグナルが良好だとしましょう。問題は本物で、人々は感情を込めて語り、数人がお金を出しました。今こそ――そして今だけ――作ることに意味が生まれます。しかしここでも、抑制は報われます。最初の版の目的は、あなたが思い描く製品になることではありません。検証済みの顧客がお金を払う、ただ1つの核となる成果を届けること、それ以外はまだ何もしないことです。

ここで検証は、あなたに静かに贈り物を手渡します。鋭く、証拠に裏打ちされた仕様です。誰のためのものか、核となる仕事は何か、人々がいくら払うか、そして繰り返し挙がった機能と、あなただけが気にかけた機能はどれか――それが分かります。その明晰さは、どれほどの事前設計よりも価値があります。正しい小さなものを作るか、高価なすべてを作るかの違いです。

よくある質問