MVPとは、Minimum Viable Product。最小限の実用可能なプロダクト。
でも、多くの人が誤解している。
「最小限だけど、完璧なプロダクト」だと。違う。
MVPは、恥ずかしいくらいシンプルでいい。
完璧なMVPを作ろうとする
ある起業家が、こう言った。
「MVPを作っています。あと3ヶ月で完成します。」
3ヶ月？それはMVPではない。
MVPは、1週間で作るものだ。長くても1ヶ月。それ以上かかるなら、最小限ではない。
「でも、これがないとユーザーは使えません」
「この機能がないと、価値がありません」
「バグがあると、評判が悪くなります」
そう言って、機能を追加し続ける。デザインを磨き続ける。テストを繰り返す。
気づけば、3ヶ月が経っている。
MVPの目的
MVPの目的は、何か？
完璧なプロダクトを作ることではない。学ぶことだ。
仮説を検証すること。ユーザーの反応を見ること。間違いに早く気づくこと。
完璧なプロダクトを作っても、誰も使わなければ意味がない。
シンプルなプロダクトを作って、使われるか確認する。それがMVPだ。
Dropboxの例
Dropboxの最初のMVPは、プロダクトですらなかった。
ただの動画だった。
創業者のDrew Houstonは、Dropboxがどう動くかを3分の動画で説明した。それだけ。
でも、その動画を見た人が、ベータ版のウェイティングリストに殺到した。
これで分かった。「需要がある」と。
プロダクトを作る前に、学んだ。これが、MVPだ。
Zapposの例
Zapposは、靴のオンラインショップだ。
でも、最初のMVPは、在庫を持っていなかった。
創業者のNick Swinmurnは、近所の靴屋で靴の写真を撮り、ウェブサイトに載せた。
注文が入ったら、靴屋に行って買い、自分で発送した。
効率は悪い。でも、学べた。「靴をオンラインで買う人がいる」と。
80点で出す勇気
完璧を目指すと、永遠に完成しない。
80点で出す勇気を持て。
80点で出して、ユーザーの反応を見る。残りの20点は、ユーザーと一緒に作ればいい。
100点を目指して1年かけるより、80点で出して学ぶ方が速い。
「恥ずかしい」くらいでいい
LinkedInの創業者Reid Hoffmanは、こう言った。
「最初のプロダクトに恥ずかしさを感じないなら、リリースが遅すぎる。」
恥ずかしいくらいシンプルでいい。バグがあってもいい（致命的でなければ）。デザインが粗くてもいい。
重要なのは、速く出して、速く学ぶことだ。
MVPで削るもの
では、MVPで何を削るのか？
「あったら便利」な機能。 必須ではないものは、すべて削る。
完璧なデザイン。 デザインは後から磨ける。最初は機能するだけでいい。
スケーラビリティ。 最初は10人のユーザーでいい。1万人に対応するのは、後で考える。
エッジケース。 95%のユースケースをカバーすればいい。残りの5%は、後で対応する。
MVPで残すもの
削ってばかりではない。残すものもある。
コアバリュー。 このプロダクトの核となる価値。これがないと、意味がない。
1つの問題解決。 1つの問題を確実に解決する。10の問題を中途半端に解決するより、1つを完璧に解決する。
フィードバックループ。 ユーザーから学べる仕組み。アナリティクス、フィードバックフォーム、ユーザーインタビュー。
MVPの後
MVPを出したら、終わりではない。そこから学ぶ。
ユーザーは使っているか？どこでつまずいているか？どの機能が使われているか？
データを見て、ユーザーと話して、学ぶ。そして、次のバージョンを作る。
これを繰り返す。
完璧を待つな
完璧なプロダクトは、存在しない。
完璧を待っていたら、永遠に出せない。
80点で出せ。恥ずかしいくらいシンプルでいい。そして、速く学べ。
完璧なMVPは、MVPではない。