ソリューション検証(プロトタイプ/MVP設計と提案)の考え方

ニーズが確認できたからといって、いきなり理想型を目指してサービスを開発し出すのは危険です。というのも、ニーズの確認方法にもよりますが、サービスに対してお金を払ってもらっていない(あるいは文字情報か簡単なコンセプトイメージくらいしか伝えていない)場合、どこまでいってもニーズは仮説の域を出ていないからです。

では最初のサービスはどんなものを作るべきか、についてお話しします。

最初のサービスは、新規事業の界隈ではMVPと呼ばれることがあります(他の言葉もありますがMVPが一番一般的なのでここでも取り上げます)。MVPはMinimum Viable Productの略で、直訳すると、最小限の実現可能なプロダクト、です。何が実現可能なのかというと、想定する価値の提供です。つまり「顧客が価値を感じてくれる最小限のプロダクト」となります。

なんとかお金をもらえるくらいのものがここでの理想です。

ここでMVPをイメージすると、大体の方は、ソフトウェアであれば、顧客がPCやスマホ上で触って動かして実際に課題を必要最低限解決できる様子をイメージします。しかし、そこまであることは必須ではありません。

MVPのPが曲者なのですが、一番最初の開発マイルストーンを「顧客候補の獲得」とした場合、MVPのPは前述のイメージのプロダクトでなくても問題ありません

では顧客候補の獲得にはどんなパターンがあるか考えてみます。

1パターン目として、一番いいのはお金を払って購入/契約してもらうことです。こう聞くと前述のレベル感のプロダクトがあることが前提に感じられそうですが、それ無しでやっている人達もいます。ここでは2つのケースがあり、一つ目は課題解決に期待してお金を払ってもらえるケースです。ただし、これは課題が特に大きい場合でないと難しかったり、そうでなければアーリーアダプターあるいはその前のイノベーターがどのくらいいるかにより、国や業界によっては難しいかもしれません。

もう一つは、課題解決のソリューションを少し変えて有料で提供するケースです。「ソリューションを変えては元も子もない」という意見があるかもしれませんが、顧客候補はあくまで課題の解決にお金を払うのであって、ソリューション自体ではありませんので大丈夫です。例えば、ある作業を自動化するツールを想定している場合、最初は裏側で手動対応する、といったかたちでのサービス開始も実は珍しくありません。あるいは、ある価値を提供するツールを想定している場合、まずはコンサルティングで同じ価値を提供することから始める、というケースもあり得ます。例えば当社自身、事業開発のツール化を想定しつつ、まずはコンサル的に開始しています。これにより、ニーズに寄り添ったかたちでの開発を実現しやすくなります。

顧客候補獲得の1パターン目が実際にお金を払ってもらうことでしたが、2パターン目は事前登録や事前注文などで、顧客候補の手間や何らかのコミットメントを引き出す手法です。こちらの方が、確実性は下がりますがやりやすいかとは思います。

例えば、クラウドストレージサービスのDropBoxは、サービス紹介動画で事前登録を獲得したというのは実は有名な話です。

他にも、靴と衣類のECの先駆けであるZapposは、1999年当時まだ消費者がオンラインで靴を購入するか分からない中、実店舗で靴の写真を撮影し、それをオンラインに掲載し、注文が入ったらそれを店舗で購入し発送する、ということをやっていました。

実はMVPの事例探すと、MVPのPにも色々あることがわかって興味深いものです。

どのような「プロダクト」を準備するにせよ、こういったかたちで顧客候補を獲得できると、より有益なフィードバックを得られるようになります。やはり顧客候補も、ヒアリングを受けているだけだと他人事の域を出ませんが、事前登録して期待が具体化したり、ましてはお金を払ったりすると自分事となりますので。

新規事業に関しては、作る側も使う側も、誰も最初は完成形を知りません(知らないことがほとんどです)。そのため、顧客との対話を行いつつ、ニーズとサービスのすり合わせをしつつ、ブラッシュアップしていくのが、時間がかかるようで無駄のない、リスクを減らしつつ成功の解像度を上げるアプローチです。

 

すべての投稿
×

もう少しで完了します。

あなたのメールアドレスにメールを送信しました。 読者登録の承認のため、届いたメールのリンクをクリックください。

OK該当機能はStrikinglyより提供しています。