<Pick Up> 10 Ways to test if your MVP is actually viable

コンセプトをMVP (Minimal Viable Product)に落とし込み、ユーザーの反応などを見た上で可能性を確かめる。無駄がなく効率的な方法ではあるものの、何を持ってMVPと呼ぶかは難しいところ。バグが多過ぎて評価に傷がつくようでもダメだし、それでいて時間を無駄にせずミニマルである必要がある。

Young Entrepreneur Councilに参加した10人の起業家に聞いた、MVPがリリースできる状態かどうかを確認するための10の方法。その一部をご紹介します。人に寄って意見がさまざまで、とても参考になるはず。

課題を解決しているか

プロダクトを判断する際、それを単なる機能の集まりとして見てはいけない。その判断は、プロダクトが課題解決をしているかどうかを基に行うべき。仮に、君は人がA地点からB地点に行くことを手助けしたいとする。車を開発したいけれど、十分なMVPは自転車かもしれない。それにさらに機能を足せばスクーターが出来上がる。時間をかけて、最終的に車が出来上がる。その間も、プロダクトはバグがない状態できちんと機能し、社会が抱える本当の課題を解決すべき。実在する顧客が抱える切実な課題を解決することがわかった時、プロダクトはローンチする準備が整った状態だと言える。

仮説を検証できるか

MVPをリリースすることのポイントは、瞬時にユーザーを集めることではない。むしろ、自分が持つ仮説を検証し、結果を知るために必要な最小限の時間だけを注ぐもの。バグがあって見た目もひどくても、その仮説が事実であることを検証することに影響がないのであれば問題ない。将来見込むオーディエンスの一部に対してテストするため、全ての機能を一度に開発する必要は無い。また、あれば素晴らしいけれど絶対必要ではない機能は無視し、この時点ではスケールすることも考えなくていい。スケールすることを前提に時間をかけて開発して仮説が間違いだった場合、失った時間は大きい。まずは世に出し、そこから最短距離で学べることを意識せよ。

意味のあるフィードバックを取り入れる準備があるか

MVPをリリースする意味は、より洗練されたプロダクトを開発するためのフィードバックサイクルを作るため。作ったプロダクトをユーザーに目の前でいじってもらう時、フィードバックの焦点がバグばかりになってしまわない必要がある。モバイルでの体験がいまいちならPCを使ってもらえばいい。ログインのポータルが存在しないなら、最初の100人は手動で登録すればいい。これらは、どれもMVPのテストを中断させるほどのものではない。でも、ページをロードする度に20秒かかってしまう場合、唯一集まるフィードバックは「もっと速く」になってしまう。プロダクトを洗練させるためのフィードバックが集まる状態であること。

via. readwrite