今回は、プロダクト開発についてです。
- 初期プロダクト (MVP) をローンチ後に、何をすればいい？
- 注意点、やってはいけないことは？
- ベンチャー企業の戦略的なプロダクト開発とは？
こんな疑問に答える内容でブログを書きました。
この記事でわかること
この記事でわかるのは、プロダクト開発における初期フェーズで、何に注力をすればよいか、注意点は何かです。
特にベンチャー企業がどのようにプロダクト開発を進めればいいかを解説します。
ぜひ、最後まで読んでみてください。
MVP ローンチ後に注力すること
プロダクトの初期開発フェーズで、MVP をローンチします。
MVP とは、Minimum Viable Product の略で、実用最小限の製品です。あえて最小限の機能に絞り、小さく始めます。
MVP ローンチ後に注力することは、仮説検証です。仮説は、以下のように4つあります。
4つの仮説
- 顧客仮説
- 問題仮説
- ソリューション仮説
- 価値仮説
それぞれを解説すると、次のようになります。
プロダクト開発の4つの仮説
- 顧客仮説：開発するプロダクトの顧客は誰が望ましいのか。相思相愛になれる顧客またはユーザーは誰か (顧客ターゲット設定の仮説)
- 問題仮説：仮説で設定した顧客･ユーザーが抱えている問題は何か。潜在的な問題やニーズも含めて、自分たちが解決すべき顧客の問題は何か (解くべき問題設定の仮説)
- ソリューション仮説：定義した問題を自分たちはどのような方法で解決するか (問題に対する解決方法の仮説)
- 価値仮説：ソリューションによって顧客にはどんな価値やベネフィットがもたらされるか (顧客が得られる価値の仮説)
MVP の仮説検証方法
では、MVP をローンチした後に、これらの仮説をどのように検証すればよいでしょうか？
想定するユーザーに直接使ってもらい、併せてインタビューやヒアリングによって先ほどの4つの仮説を検証します。
ユーザーへのインタビューは、可能な限り MVP を使ってもらいながら行うとよいです。使った後にヒアリングをする場合も、なるべく使ってから時間が経たない間に実施します。
MVP を使ってもらいながら、または使った後に、次のような質問をします。
インタビュー質問例
- これは何をするものだと思いますか (例: このボタンは何をするものだと思いますか)
- 表示されている xxxxx というワードをどう解釈しますか
- 今の動作は期待通りに動きましたか。期待通りでなければ、何を期待していましたか
- プロダクトは、これからも自分は使ってみたいと思いますか
- このようなプロダクトを導入するとしたら、どんな準備や必要なこと (新しい備品や説明会等) がありそうですか
直接インタビューをする中で、相手の言動や振る舞いから以下を観るようにします。
インタビューでのチェックポイント
- 興味を持っているか。前のめりか。自分ごと化されているか
- 質問はあるか。的を得ているか
- プロダクトを使いたい程度は (使ってもよい、ぜひ使いたい、お金を払ってでも使いたい)
- 導入イメージを持てているか。具体的な利用シーンが出てくるか
- 導入へのハードルは。スケジュール感。予算はどこから。誰が意思決定をするか
インタビュー相手が、顧客仮説で設定した人物像にふさわしいかどうかを確認します。望ましい人であれば、初期段階の MVP を使って欲しいファーストユーザーです。
MVP 仮説検証への姿勢
MVP でユーザーに向き合う際の考え方は、私は以下を大事にしています。
仮説検証の姿勢
- ｢ユーザーから学ぶ｣ という姿勢
- 仮説に固執しない。素直な目と耳で臨む
1つめは ｢ユーザーから学ぶ｣ という姿勢です。決して、MVP の使い方を ｢ユーザーに教えてあげる｣ というマインドセットではなく、あくまでこちらが学ばせてもらっているスタンスです。
2つめの仮説にこだわりすぎないことも重要です。
仮説とは思い込みと紙一重です。仮説に固執せず、いかに素直な目でユーザーの様子を観察できるか、話を聴くことができるかです。
MVP ローンチ後の注意点
MVP ローンチ後という開発初期段階で、どのようなことに注意するとよいでしょうか？
ここでは、次の2つの注意点を解説します。
MVP ローンチ後の注意点
- 次の開発要件の見極め
- BD やセールスとの連携
[注意点 1] 次の開発要件の見極め
MVP で仮説を検証しながら、次の開発要件の優先順位を見極めます。
ユーザーインタビューでは、様々な学びが得られます。ただし、フィードバックを全て対応するのは現実的ではありません。
MVP ローンチ後も、基本的なスタンスは絞ることです。全てに Yes と応えるのではなく、いかに No を決められるかです。
具体的には、次の通りです。
方向性を決める
- MVP の機能をさらに磨き込むのか
- 新しい機能を追加開発するか
- ユーザーを広げるか
優先順位を決め、順位グループを区切る
- Must have: 要件として開発が必須のもの。これが実現しなければ顧客が感じる最低価値を超えない
- Nice to have: あれば望ましい。ただし必須ではない。Must have と Nice to have の切り分けが重要
- Backlog: 例えば3ヶ月以内に実装すればよい機能。後々必要ということでまとめてプールしておく
ピボット判断基準の明確化
- ピボットという MVP からの大きな方向転換をする基準を持つ (Go or No go 判断)
- MVP での仮説検証から、仮説が間違っていれば方針を変える決断をする
[注意点 2] BD やセールスとの連携
注意点の2つめは、社内関係者との連携です。
特に顧客開拓 (BD: Business Development) や営業担当者とどのようにコミュニケーションし、協業していくかです。
MVP の時点では社内リソースは限られます。やみくもに顧客やユーザーを広げすぎると、リソースが分散してしまう危険性が高くなります。
BD やセールスは、彼ら･彼女らのインセンティブに任せてしまうと顧客拡大に走っていきます。
MVP 時点でできること･できないこと、開発や展開スケジュールをすり合わせ、社内関係者や顧客の期待値コントロールをします。
プロダクト開発チームが受け身で動いてしまい、社内関係者や顧客の要望にがんじがらめになってからでは手遅れになりかねません。
開発をリードするプロダクトマネージャーは、いかに社内関係者と連携するか、No を言うことに躊躇せず真摯に向き合えるかです。
戦略的なプロダクト開発
特にベンチャー企業の規模では、常にリソースとの戦いです。人やお金が足りず、リソース不足という制約下においてどのように開発を絞っていくかです。
MVP とは、ボーリングにおけるセンターピンです。機能を最小限に絞り、自分たちが正しいと思う本質だけを実装したプロダクトです。
これは、限りあるリソース状況において、戦略的にプロダクト開発をするということです。
戦略とは目的を達成するために、やること･やらないことを決めることです。戦略はリソース配分の指針です。
MVP という機能を絞り、顧客も初期は限定します。一点突破で、プロダクトのマーケットフィットがあるかどうかを MVP を使って検証していきます。
機能要件を実装するかしないかを決めて MVP を開発したように、MVP ローンチ後の方針や活動もいかにやらないことに No を言い、絞れるかなのです。
まとめ
今回は、プロダクト開発について書きました。
MVP という実用最小限の製品をリリースした後に、どういうことに注力をすればよいか、注意点、考え方をご紹介しました。
最後に今回の記事のまとめです。
MVP ローンチ後に注力することは仮説検証。仮説は4つ。
- 顧客仮説：相思相愛になれる顧客またはユーザーは誰か (顧客ターゲット設定の仮説)
- 問題仮説：設定した顧客･ユーザーが抱えている問題は何か (解くべき問題設定の仮説)
- ソリューション仮説：自分たちはどのような方法で解決するか (問題に対する解決方法の仮説)
- 価値仮説：顧客にはどんな価値やベネフィットがもたらされるか (顧客が得られる価値の仮説)
仮説検証方法は、想定するユーザーに直接使ってもらい、併せてインタビューやヒアリング。4つの仮説を検証する。
MVP でユーザーに向き合う際の姿勢は、
- ｢ユーザーから学ぶ｣ という姿勢
- 仮説に固執しない。素直な目と耳で臨む
MVP ローンチ後の注意点は、
- 次の開発要件の見極め：方向性、開発優先順位、ピボット判断基準の明確化
- BD やセールスとの連携：できること･できないこと、開発や展開スケジュールのすり合わせ。社内関係者や顧客の期待値コントロール
特にベンチャー企業の規模では常にリソースとの戦い。限りあるリソース状況において、戦略的にプロダクト開発をする。
MVP ローンチ後の方針や活動も、いかにやらないことに No を言い、絞れるかが重要