30日間で6つのMVPを設計・構築する機会を得たことで、どのような機能でローンチすべきかについて多くのことを学ぶことができました。
ここ数年、MVP（Minimum Viable Product）を発表するというコンセプトは爆発的な人気を博し、今ではスタートアップと既存のテック企業の両方にとって一般的な方法となっています。しかし、話題性のあるステータスに到達したほとんどのコンセプトがそうであるように、多くの混乱があります。熱烈な支持者、頑強な懐疑論者、そして、その意味をよく理解せずにこの言葉を投げかける多くの人々がいるのです。
そこで、同じページに戻るために、少し話を戻しましょう。MVPの全体的な考え方は、人々が価値を感じられる最小限の製品を作り、それに機能を追加していくというものです。MVPを支持する人たちは、まず最小限のものを作ることで、人々が実際にどんな追加機能を求めているかを知ることができ、誰も使わない機能をたくさん作って時間を無駄にすることがなくなると主張します。しかし、MVP懐疑派は、現実には、MVPは有用で愛すべき機能を十分に持たない、くだらない製品の束に過ぎない、と主張します。この議論によって、両者の人々は、MinimumValuableProduct、MinimumLoveableProduct、あるいは私のお気に入りのRAT(identify your Riskiest Assumption and Test it) など、さらに楽しい略語を思いつくようになったのです。
この議論はちょっと無意味だと言いたいのです。MVPのコンセプトは新しいものではありません。実際、それはまあ...永遠に続いています。MVPの考え方は、まさに「進化」の概念です。物事は小さく始まり、時間をかけて進化していきます。例えば、学校、食料品店、都市はすべて、今日の進化に比べれば小さなMVPとして始まりました。ですから、最初に小さなバージョンを作ってから、時間をかけて追加していくべきかどうかという点は、議論の対象にはならないはずです。もちろん、発売後もより良い製品にしたい！という気持ちはあります。それよりも、このコンセプトの最も難しい部分を理解することに時間を費やすべきでしょう。
どのような機能が初期バージョンに含まれ、どのような機能が待機すべきなのか？
この質問を難しくしているのは、次の3点です。1）お客様が本当に気に入る機能は、製品を使い始めてみないとわからない。2）人間は生来せっかちで、何でもすぐに欲しがる。そして3つ目は、私たちがあまり練習していないことです。経験豊富な起業家やアプリデザイナーでさえ、毎日MVPを展開しているわけではありません。その代わり、彼らはすでにあるものを改善することに主に集中しています。
As an experienced UX designer, this last point was true for me up until about a month ago. However, over the last 30 days, I went on an incredible journey. My co-founder and I were able to completely design & build the MVP for 6 different apps ranging in scale from small startups apps to an internal app for a large enterprise. And over the course of this fast-paced MVP-fest we came up with a framework for deciding which features were in and which features were out. (Side note: I'm the co-founder of Adalo, a startup that lets you quickly build apps without code.)
私たちのフレームワークを説明するために、私たちが手がけたアプリの1つである「Tavolo」を使って説明します。Tavoloは、基本的にDoorDashとOpenTableの出会いです。Tavoloのミッションは、テーブルの予約、注文、支払いをすべて前もって行うことで、「食事の好ましくない面を最小限にする」ことです。(素晴らしいアイデアだ。）
ステップ1：アプリのストーリーを作る。
まず、アプリが解決しようとする主な問題点を書き出し、その問題点を克服するために人が取るべき手順をすべてリストアップしてください。例えば、Tavoloのストーリー。
[彼らのアプリが解決する主な問題点】について］
テーブルの予約やお食事代金の支払いなどの煩わしさから解放されます。
[【タボロ経験者なら】］
アプリを開く → レストランを選ぶ → 予約する → 友達を誘う → 料理を選ぶ → お金を払う → お店に行く → チェックインする → 料理を楽しむ
[【さらに、レストランには】］
新しい予約と注文の通知を受ける → パーティーをチェックインする → キッチンへ注文を送る → パーティーに料理を渡す → 注文完了をマークする
ステップ2：各ステップでの役立つ情報をリストアップする
旅を一連の決定事項として書き出したら、次の仕事は、誰かが旅の次のステップを踏み出すのに役立つ情報をすべて見つけ出すことです。例えば、Tavoloの最初の決定事項の1つは、どのレストランに行くべきか、というものです。このとき、役に立つ情報がたくさんあります。名前、場所、価格、メニュー、レビュー、友達が行ったことがあるか、などなど。
ステップ3: 考えられるすべての機能のリストを作成する
ステップ1と2の終わりには、一連の決定ポイントと、その決定を容易にするために必要なすべての対応する情報を記載した長い文書（または付箋紙の束）ができているはずです。この文書は、あなたのアプリに可能なすべての機能のリストを作成するための完璧なインスピレーションとして機能します。これらのアクションと情報を具体的な機能に変換するだけです。
ステップ4：ミッションクリティカルな機能をマークする
さて、全機能が揃ったところで（あるいは、アプリをユーザーの手に渡さない範囲で可能な限り揃えたところで）、ミッションクリティカルなものに印をつけることから始めましょう。この機能は、旅のステップを完了するために100％必要なものでしょうか？例えば、レストランを選ぶには、レストランの名前と場所を知っていなければなりませんし、そのレストランを選択する方法がなければなりません。検索や評価など、他の機能は便利ですが、技術的には必要ではありません。
ステップ5：Easy Winの機能でアプリを強化する
どの機能が100％必要かを決めたら、それを使う人が、少なくともアプリが達成しようとした主なタスクを（おそらく非常に劣悪な方法で）達成できるところまで、製品を完成させましょう。 さて、ここからが楽しいところです。ユーザーにとってその体験を容易にするための機能をすべて決定する必要があります。これらの機能は、ステップ2で人々が意思決定をするために必要とする有益な情報に直接関連するものです。
厄介なものを判断するために、次のような質問を自分に投げかけてみてください。
- この機能は簡単に実装できるのでしょうか？
- 本当にみんなそんなに頻繁に使うのだろうか？
- アーリーアダプターにメリットがあるのか、それともユーザー数が多いときだけ有効なのか？
もし、これらの質問に対して赤信号が出たら、その機能は将来のバージョンに移行させます。例えば、Tavoloの場合。
[カットされなかった機能】について］
- 近くのレストランをユーザーに知らせる（ジオロケーションの構築は難しい）
- 飲食店向けの分析ダッシュボード（便利だが、まだユーザーが作成したデータがそれほど多くないだろうから、アーリーアダプター向けではない）
イッツ・ゴー・タイム!
ステップ5を完了すると、MVPが備えるべき機能と、将来的に待つべき機能についての優れた感覚が得られるはずです。また、どのような機能を追加すれば、アプリを実行可能な最小限の状態から愛すべき状態にまで簡単に持っていけるかについても、明確なリストが出来上がっているはずです。ローンチまでにどれだけの機能を追加できるかは、予算やスケジュール、そしてあなたやチームにとって使いやすさがどれだけ重要であるかによって決まります。
しかし、重要なのは、製品をMVPと呼ぶかMLPと呼ぶかにとらわれることではありません。重要なのは、あなたが今、将来の青写真となるべき優先順位の高い機能の素晴らしいリストを手に入れたということです。あなたは、単にそれがクールだと思うから機能を追加しているのではありません。多くのアーリーアダプターを集め、勢いをつけ、最終的に成功する可能性の高い、最高の最初のバージョンを作ろうとしているのです。
