見出し画像
Photo by rimiko

MVP検証後のネクストアクションについて

浪花祐貴（Yuki Naniwa）

はじめに

2022年10月より始動した新規事業の検証に関するプロジェクトですが、アイデア検討〜MVP実証実験まで約1年の歳月をかけて取り組んできたものがちょうど節目を迎え、ポジティブな結果も相まって、MVP検証の次の取り組みについて議論を重ねるタイミングに来ましたので、その考察の内容を以下に認めておこうと思います。


前提

私自身は、このプロダクトの起案者をサポートするStartup StudioのProduct Managerです。弊社（Startup Studio）としては事業会社の新規事業開発支援として入っております。そういった状況もあり、顧客やプロダクトなど、特定できる条件は一切排除して、あくまで１つのカテゴリーにおける考え方としてまとめておこうと思います。この点について、ご容赦ください。
簡単ですが、カテゴリーは以下の通りです。

プロダクトのカテゴリー（領域）

  • ソフトウェア（Webサービス、アプリ）

  • BtoC

  • ホリゾンタル

  • ドメスティック（国内）

一般的な考え方

株式会社才流の栗原康太さんが、提唱されているフィットジャーニーという考え方を参考にさせてもらっております。

フィットジャーニー｜PMFを理解するために必要な用語

今回の状況に当てはめてみると、CPF（Customer Problem Fit）とPSF（Problem Solution Fit）に関しては、MVP検証を実施する前のUIUX検証の中で、主に想定顧客に対するインタビューを通じて確認することができました。そして、今回のMVP検証においては、SPF（Solution Problem Fit）の部分と、勝手ながら追加させていただいた「CSF（Customer Solution Fit）= 顧客に解決策が受け入れられたか」を確認したフェーズになるかと思います。（個人的には「CmvPF（Customer Minimum Viable Product Fit」でも良いかと思いましたが、語呂を全体に合わせました。）」）

改めて整理させていただくと以下のようなイメージです。

フィットジャーニーをもとに作成／検証工程

この２つの問い（SPF、CSF）に対して、MVP検証を通じてポジティブな結果を得ることができまして、次のフェーズにおける「PMF（Product Market Fit）をいかにして達成するか」という問いが、次の論点となっている状況です。

PMF（Product Market Fit）をいかにして達成するか

前章で提起させていただいた「PMF（Product Market Fit）をいかにして達成するか」という論点ですが、大きく二つのパターンがあると考えております。

MSP検証を実施する（検証を続ける）

端的に申し上げるとこのまま次のフェーズの”検証を続ける”という判断がパターンの１つとなりますが、まずはMSPというものが何なのかについて簡単に説明を加えさせていただこうと思います。

市場に受け入れられるプロダクトを作り上げていくプロセスにおける一つの考え方として、MLP→MVP→MSP→MMPというものがあります。ざっくり解説すると以下の通りです。

  • MLP：最小学習可能製品（Minimum Learnable Product）

  • MVP：最小実行可能製品（Minimum Viable Product）

  • MSP：最小販売可能製品（Minimum Sellable Product）

  • MMP：最小市場可能製品（Minimum Marketable Product）

※詳細な解説は以下をご参照ください。

今回のMVP検証においては、「想定顧客の想定課題に対して、構築したソリューションが提供価値を与えているか」という観点で検証を行いました。この検証の中では、「実際にこのサービスが公開されたら使ってみたいか？」「使うとしたらいくら払うか？」といった価格受容性に関する問いもユーザーに投げかけます。しかしながら、この問いに対してポジティブな回答を得られたとしても、”実際に購入する”というユーザーの行動検証ができていないため、MSPというフェーズにおいて当該観点で検証を実施します。

具体的な方法として、抽出した案が以下の２つになります。

方法論１
ティザーサイト（LP）を作成し、
ウェイティングリストにどの程度希望ユーザーが集まるかを測る

ティザーサイトというのは、一般的に商品イメージや情報を小出しにしてユーザーを焦らすサイトで、例えば、発売前のゲームHPなどのように商品動画、発売日など情報が小出しでアップデートされるようなサイトのことを指します。検索するといくつか事例なども出てきます。

今回の場合、MSP検証であるため以下の目的で検証を実施します。

  • サービスのコンセプトや概要を見て、どの程度の規模のターゲットが興味を示すか？（市場性がどの程度か？）

また、成果物や検討要素、スケジュール感としては以下の通りです。

  • 成果物

    • LP

  • 検討要素

    • メッセージ仮説（想定ターゲットに対して、どんなメッセージが石っばん刺さるか）

    • KPI設計（ウェイティングリストにどの程度ターゲットが集まったら市場性があると定義するか？）

    • LPのデザイン、Web開発

  • スケジュール（目安）

    • １ヶ月〜２ヶ月

  • 費用規模

    • 小

方法論２
LP＋MSP（MVPを一部アップデート）で限定公開

方法論２に関しては、MVPで構築したプロダクトを踏襲し、一部支払い機能などを追加開発して、実際にお金を払って使ってもらうところまでの行動を検証するものになります。この検証で１点留意したほうがいい内容は、MVP検証で構築したプロダクトは、サービス公開を目的とするものではなく学習を目的としたものであり、そのままローンチをすることができない場合が多いため、限定公開という形でユーザーに利用いただく方針をとります。

方法論２における検証目的は以下になります。

  • サービスのコンセプトや概要を見て、どの程度の規模のターゲットがど興味を示すか？　※ただし、限定公開であることに留意が必要

  • 興味を持った上で実際に想定ターゲットがどの程度規模で購入という行動に踏み切るか。

また、成果物や検討要素、スケジュール感としては以下の通りです。

  • 成果物

    • LP

    • MSP（MVPの改修版）

  • 検討要素

    • メッセージ仮説

    • KPI設計（利用者がどの程度規模で顕在化するか、利用者の内どの程度が有償利用するか。）

    • LPのデザイン、Web開発

    • MSPの設計・開発

  • スケジュール（目安）

    • ２ヶ月〜３ヶ月

  • 費用規模

    • 中

MSP検証を選択した場合の方法論として２パターンお伝えしましたが、あくまで目的は”検証をする”ことでありサービスローンチが目的ではないため、検証するためのスピード感としては早い一方で、”MVP検証→MSP検証→ローンチ”の流れで勘案した際の費用・スケジュールとMSP検証という工程を飛ばして”MVP検証→ローンチ”の流れで勘案した際の費用・スケジュールとがトレードオフになることは留意いただく必要があります。

ローンチする

MVP検証において、ユーザーの購買行動まで検証できなかったとしても提供価値に対する受容性が十分に感じられた場合、市場にサービスを公開していくという方法も一つの選択として十分に考えられます。

この選択の場合、検証ではなく”サービスローンチ”であるため、プロダクトとしてのサービスレベルも一段上げる必要がありますし、運用体制を整えていく必要があります。しかしながら、サービス公開範囲を徐々に広げていくやり方や、プロダクト機能をはじめは小さくローンチして徐々に追加していくやり方などで、いきなり膨大なコストを投下せずに進める手法をとることもはやぶさかではありません。（むしろこちらの方が一般的かもしれません。）ある意味、後戻りはできない（抜本的な変更したり辞めやりする選択ができたとしても、ハードルがかなり大きい）判断になりますので、色々と試しながらプロダクトを改善していく（育てていく）スタンスを経営サイド含め一致させる必要があります。

成果物や検討要素、スケジュール感としては以下の通りです。

  • 成果物

    • 正式なプロダクト

  • 検討要素

    • サービス名、ロゴなど

    • メッセージ仮説

    • 法務面の取り決め（利用規約、プラポリなど）

    • マーケティング

    • LPのデザイン、Web開発

    • 正式プロダクトのデザイン、設計・開発

    • 運用フロー、手順の構築

    • KPI設計（利用者がどの程度規模で顕在化するか、利用者の内どの程度が有償利用するか。）※あくまでプロダクトを改善する上での判断要素としての位置づけ

  • スケジュール（目安）

    • ３ヶ月〜６ヶ月

  • 費用規模

    • 大

前述でも軽く触れましたが、市場にプロダクトを正式ローンチするというゴールは変わらないにしても初回ローンチの前提を変えることはできます。主には以下の要素が考えられるかと思います。

  • サービス公開範囲を限定する（例：社内、申込者先着など）

  • 構築機能を限定する

上記の前提を踏まえ、できる限り早く小さく、初回のプロダクトをローンチし、ユーザーの反応を見ながら目指している姿までプロダクトを育てていくというプロセスを踏む形です。おそらく多くの開発組織でも当初のアイデアをフルフル盛り込んで開発や周辺の体制が確立されてから正式にリリースという形を踏むわけではなく、上記のようにできる限り早く小さくローンチを行っているはずだ認識しております。

このプロセスを踏む中で大事なポイントとしては、以下の通りです。

  • プロダクトが目指したい世界観が描けている

  • 世界観から逆算した中長期のロードマップが描けている

  • ロードマップを達成するために必要となるタスクのリスト化（バックログ化）とその優先順位付けができている

上記の「世界観」「ロードマップ」「バックログ」を組織の大きさに応じてCEO、プロダクト責任者（CPO）、プロダクトマネージャーなどが責任を持って計画し周囲を説得していく必要があります。

・・・ということで、
このまま話を続けるとリリースしてからプロダクトをグロースさせるまでの話を延々と続けることになりそうですので、一旦ここまでで話を終わりにしようかと思います。

まとめ

今回は、特定領域（ソフトウェア、BtoC、ホリゾンタル、ドメスティック）のプロダクト、かつMVP検証を実施し事業化に向けてポジティブな結果が得られているという前提において、ネクストアクションの選択肢に関する考察をさせていただきました。まとめると以下の通りです。

  • パターン１：MSP検証実施する（検証を続ける）

    • 方法論１：ティザーサイト（LP）を作成し、ウェイティングリストにどの程度希望ユーザーが集まるかを測る

    • 方法論２：LP＋MSP（MVPを一部アップデート）で限定公開

  • パターン２：ローンチする

このパターン、方法論自体が全てというわけではなく、他にも様々な選択肢があると思いますので、考え方の一つとしてご参考頂けますと幸いです。

この記事が気に入ったらサポートをしてみませんか？