目次
この記事にはコードを書かずにプロダクトをテストする時の教訓が書かれています。Paul Grahamの有名な言葉に「人々が欲しがるものを作れ」というものがあります。正しいアドバイスですが、起業家にとって重要な問題を残しているのです。
どうやって人々が欲しがるものを知ればいいのでしょう？IPO後のお金で買うつもりの島に頭金を払ってしまう前に、自分が開発しているプロダクトは50万ユーザーの壁を突破できるのか知る必要があります。
実際のプロダクト開発にリソースを割く前にアイデアを検証するのはいまやスタートアップ的手法として定番になっています。しかし、開発前にどれくらい正確にプロダクトを検証できるでしょうか？
一つの方法としてはMVP ((MVP: Minimum Viable Product の略。検証に必要な最低限の機能を持った製品という意味))があります。（けどMVPのPはプロダクトの略ですよね？）PはプロダクトのPです。しかし、これまでに書かれたMVP的手法についての記事を読むと、MVPは必ずしもプロダクトである必要はないと言っており、書いてあることをそのまま受け取ってしまうと危険を冒すことにつながります。
本来、MVPは統計的有意性によってテストし検証する必要がある仮説です。検証はコード0行で成し得ます。例えば、Siriのような音声認識型のデジタルアシスタントが受け入れるかのテストは、AIを使わなくても電話の向こう側にいる人を使い相手の質問にこちらが答えた時の反応を測ればよいのです。私たちのプロダクトであるCubeitをどうやって検証したか理解してもらうためには、プロダクトの簡単な説明が必要でしょう。申し訳ありませんがちょっと説明にお付き合い下さい。
Cubeitとは
簡単なプロダクトの概要をお話しさせていただくと、Cubeitはモバイルのファイリングシステムです。リンクやドキュメントから写真やビデオ、タスクやカレンダーの予定に至るまでなんでも追加できます。全てのコンテンツをカード形式で表示することによってスマートフォンでのコンテンツの整理や閲覧がとても簡単にできるのです。
次はコラボレーションについてご説明します。コレクション、もしくはCubeと呼ばれるリンクの一覧を右にスワイプするだけでシェアできますし、そうするとCubeはただちに共同編集できるようになるのです。あなたがシェアしたコンテンツに他の人がコンテンツを追加することができます。
Cubeitはモバイルでの利用に最適化された、コラボレーションできるDropboxだと思ってください。モバイルに最適化されているがゆえに早く、手軽に使えます。
しかしながらプロダクトの性質上、ニーズのある機能とのインテグレーションを実装し、誰にでも扱いやすいUXにするために人々がCubeitをどんな風に使うかを早めに突き止める必要がありました。実際にユーザーに使ってもらえる製品がない状態でどうやって検証すればいいでしょうか？
注記：下記に行った一連のテストは初期のユーザーインタビューでプロダクトの大方針を決めた後に実施したものです。下記のテストでは主に定量的な指標に注目していました。
プロダクトがない状態でどうやってテストをしたのか？
1. ランディングページ
これはいまや一般的な手法です。ランディングページを作り、広告やブログでトラフィックを呼び込みクリック数やコンバージョン数を計測しました。特にメッセージ機能とユースケースについて検証したかったので、それぞれ全く見た目の違う（異なるユースケースを描いた）複数のランディングページを試しました。
そのうちの一つはコンバージョンレートが20%程度でしたが、それ以外は10%程度でした。このアプローチによる結果にはあまり納得できませんでした。良いコンバージョンレートとはどれくらいなのかをわかっていなかったのが原因ですが。コンバージョンレートが15%、20%、それとも25%だと喜ぶべきなのでしょうか？確実な数字を突き止める術はありません。結局私たちは欲をだして、一番結果がよかったランディングページをさらに改良し続けることにしたのです。
2. アプリのモックアップをFacebookでシェアする
ランディングページのデザインと同様アプリの操作画面を表示するのが良いのではという予想を立て、実験成功の評価基準としてlikeとshareの目標値を決めてベンチマークにしました。この実験は表面上は失敗に終わったのですが、おそらくFacebookを見ているオーディエンスにはこういった特定の一部のコンテンツを見せても反応が薄いという学びを得ました。（有料広告やコンテンツのプロモーションは行っていませんし、すでに我々のFacebookページのオーディエンスはlikeやshareでうんざりしているのではという仮説を立てました。）
3. ビデオ
通常であれば次のステップはビデオになります。ビデオは制作が非常に難しいですが、Dropboxは例外です。彼らは最小限のプロダクトの価値を紹介したビデオで多くの注目を集めました。テクノロジー界隈の興味を惹いたイースターエッグは例外です。Dropboxが革新的でこの種のものとして一番最初のプロダクトであることも注目を集めた理由でしょう。
革新的なプロダクトを開発していないスタートアップにとってビデオで製品の価値を伝えるのは非常に重要ですが、私たちは検証のためにビデオを作るようなお金を持っていませんでした。（複数のユースケースを想定したテストも必要でしたが、そのためには複数のビデオを作らなければならず、より多くの費用がかかります。）
4. ブログをMVPに使う
ブログをMVPとして利用するという素晴らしいアイデアを思いついたのは、Redditで少し無駄に時間を費やしていたときでした。プロダクトの説明を1,000字の記事で説明するのです。もし5分時間をもらって人々をわくわくさせることができなければ、そのアイデアは自分が思っていたよりも素晴らしいものではないという仮説です。
これは大変ですが、もしそのブログが何回もレコメンドされたら（記事はMediumに投稿しました）自信を持ってβ版の開発を進められます。成功事例としてはMattermarkがブログからプロダクトに発展したものがあります。
Mediumでの検証
というわけで私たちはMedium上で連続した3つの記事を書き、ユースケースを検証し、それぞれの記事にベンチマークを設定しました。学んだことは以下です。
- Mediumでは簡単に自然流入を得ることができます。コンテンツマーケティングの最大の問題の一つはトラフィックを集めることです。Mediumはこの問題をいくらか解決してくれます。記事に最初に興味を持ってもらうことができれば（ハイライトかレコメンドされれば）Medium内の自然流入は増え、労力をかけずにトラフィックを集めることができます。
- ストーリーに集中できます。Mediumは見た目のレイアウトの良さや便利な編集機能を持ち、ストーリーを語るのに適した場です。そしてローンチ前のスタートアップにはそういった場こそが彼らのニッチ、つまり素晴らしいストーリーを語る場としてふさわしいです。ここでは2語に収まるキャッチフレーズのことは忘れてしまいましょう。ストーリーをきちんと伝えることができれば、結果はついてくるでしょう。
- お願いしたら手伝ってくれます。私たちはストーリーを読んでくれる人の気が散らないように自分たちのWebサイトのリンクを載せませんでした。その代わり、読んでくれた人にこの記事に書いてあることが実行可能なアイデアだと思ったらレコメンドし、実行可能でないと思ったら理由をコメントでくれるように頼んだのです。この施策はうまくいき、プロダクト改善にどうすべきかたくさんの有益なフィードバックをもらうことができました。
- 検証は困難でした。どれだけ試してみたところで、実際に人々がプロダクトを使っている様子を見なければ真にアイデアを検証することはできません。ランディングページのコンバージョンレートからFacebook広告のクリックレートに至るまでの全てが検証のほんの一部でしかないのです。検証実験を行っても50万ダウンロードが確実にならないことは仕方がないものです。
この記事はアイデアをどうやって検証しようかと思案している人に向けて書きました。残念ですが、簡単な方法などないということが私が学んだことです。（顧客にお金を払って検証する方法は除きます。B2Cのスタートアップにとってはお金こそが問題なのです。）
ダウンロード数が50万を超えて初めてサービスが有名になったと知るのです。ため息が出ますね。さて、この不確実さと、途方もない時間と、何が起こるか分からない明日に乾杯しましょう。
この記事は、CubeitのブログWhat we learnt by testing our Minimum Viable Product on Medium*を著者の了解を得て日本語に抄訳し掲載するものです。 Repro published the Japanese **translation of this original article on *Cubeit* in English under the permission from the author.*
執筆者
