Buffer創業者は、なぜコードを書く前に料金ページを作ったのか

企画を話したら「それ、いいね」と言われた。では、その相手は本当に使ってくれるだろうか。

SNS投稿管理サービスBufferの創業者、ジョエル・ガスコインは、作り始めてから、その問いに戻った。

SOURCE｜完成品より先に、選択してもらった2011年2月の本人記事によると、ガスコインは需要を確かめる前にコードを書き始めたことに気づき、開発をいったん止めた。

まず用意したのは、構想を伝えてメールアドレスを登録してもらう2ページのサイト。反応を得た後、登録までの途中に料金ページを追加した。有料プランを選ぶ人がいるかも確かめてから、動く製品の本格的な開発へ進んだという。原典：Buffer創業者の記録

EDITOR’S TAKE｜「興味」と「利用」を同じ箱に入れないここまでがBuffer創業者本人の記録である。ここから先は、その事例をFORWARD BASISがどう整理するかだ。

この事例の要点は、ホームページを小さく作ったことだけではない。開発前に確かめる問いを、段階に分けたことだと編集部は考える。

FORWARD BASISでは、初期検証を少なくとも四つに分けて考える。

1. 興味 - 説明を読んで反応する。

2. 登録 - 連絡先を残す。

3. 支払い意思 - 料金を見ても先へ進む。

4. 実利用 - 実際に使い、その後も必要とする。

それぞれ、分かることが違う。前の段階の反応だけで、後ろの段階まで証明されたことにはしない。

ただし、料金ボタンを押しただけで、購入や継続利用が確定したわけではない。原典は創業者自身の振り返りであり、この四段階も研究で検証された標準手順ではなく、事例を実務で使いやすくするためのFORWARD BASISの整理である。

「反応があったから、需要は証明できた」と結論を急げば、小さなテストも大きな勘違いの入口になる。

TRY THIS｜「どう思う？」の次に、何を頼むか例えば、仕事帰りに参加できる読書会を考えているとする。以下は編集部による仮の例だ。

「読書会があったら来たい？」だけでは、相手が想像した場所も内容も分からない。候補日時、開催方法、読む本を示し、「この条件なら参加を希望するか」を確かめれば、企画を直す材料になる。

ただし、それも参加意向まで。実際の参加や、次回も来たいと思うかは、別に確認する必要がある。

逆に反応がなくても、即座に「企画に価値がない」とは言い切れない。日程が合わないのか、説明が伝わらないのか、本自体に興味がないのかを切り分けたい。

試す前に、次の問いをメモしておこう。

• 今回、何が分かれば次に進めるのか。

• 相手のどの行動で、それを確かめるのか。

• その行動だけでは、何がまだ分からないのか。

募集や案内を出す場合は、企画段階であることを明示する。未完成なのに利用できるように見せる必要はない。

次に「いいね」と言われたら、喜びながら、もう少し具体的な条件を見せてみよう。賛成してくれた人と、実際に参加できる人が同じとは限らないからだ。