結論：MVPは“作る”ためではなく、“学ぶ”ために存在します。Aha％→TTV→D1を先行指標に置き、BtoBtoC特有の摩擦を検証することで、リスクを最小化できます。
「まずはMVPを作ろう！」――よく聞くフレーズですが、作っただけで終わってしまうケースも多いはずです。特にBtoBtoCでは「法人導入」×「エンドユーザー利用」の二重構造があるため、検証設計が甘いと全く学べません。この記事では、Aha％・TTV・D1を基準にMVPをどう設計すればいいか、テンプレとチェックリストを交えて具体的に解説します。
MVP検証の目的を明確にする
最初に押さえるべきは「検証目的」です。BtoBtoCのMVPでは、顧客（法人）とユーザー（消費者）の双方を巻き込むため、単なるプロトタイプでは不十分です。
- 法人にとって：導入判断に足る“実績”が見えるか？
- ユーザーにとって：最短で価値に触れる体験があるか？
- PdMにとって：Aha％・TTV・D1を計測できるか？
コピペ素材（目的の一文）
「このMVPは“ローンチの可否”ではなく、“ユーザーが価値に触れられるか”を検証するためのもの。」
まとめ：目的を“リリース可否”にすると誤る。例：実績提示用MVPは法人には響いても、ユーザー検証にはならない。
Aha％を測るMVP設計
Ahaは「価値の初回成立」を意味します。BtoBtoCでは法人アカウントの発行後、エンドユーザーがどこで価値を感じるかを明示することが重要です。
- 法人側：管理画面で◯◯を登録できる瞬間。
- ユーザー側：◯◯機能を初めて完了できる瞬間。
- PdM側：Aha定義を計測できるイベント設計。
Aha→TTV→翌日活性の順で見ると意思決定が速くなります。詳しくはKPI設計と運用ガイドへ。
コピペ素材（Aha定義テンプレ）
「Ahaは、ユーザーが◯◯を初めて完了する瞬間。法人側は◯◯を登録し、そのデータをユーザーが体験する時点で成立。」
まとめ：Ahaは法人・ユーザー双方に定義を置く。例：法人が商品登録→ユーザーが購入完了、の一連が初回成立。
TTVを短縮する導線設計
BtoBtoCのMVPでは「法人導入→ユーザー利用」までの時間が長引きがちです。導入までに1か月かかれば検証不能です。そこでTTV短縮の工夫が必要です。
- 法人導入フローを仮想化（手入力ではなくサンプルデータ配布）。
- ユーザー体験は最短2クリックで試せるデモ導線。
- 裏側は手動オペレーションでもよい（Wizard of Oz方式）。
コピペ素材（TTV短縮チェック）
・導入までに30日以上かかっていないか？
・ユーザーが初回体験に到達するまで何手かかっているか？
・オペレーションで代替できる部分はないか？
まとめ：法人導入を“演出”し、ユーザー体験に直行させる。例：サンプルデータで即座に検索体験を提供。
D1を確かめる復帰設計
翌日活性（D1）は「もう一度戻る理由」があるかで決まります。MVPでもD1が測れないと、継続性を誤認します。
- 通知：翌日、保存したデータや結果を呼び戻す。
- 再開導線：ログイン後すぐ“続きから”を提示。
- 法人視点：ユーザーが翌日戻る理由を法人に説明できる。
コピペ素材（通知文テンプレ）
「昨日の◯◯の続きがこちらから始められます。」
まとめ：D1は“再開の設計”。例：検索履歴を翌日呼び出す通知でD1を計測。
関連記事
FAQ
Q1：法人導入に時間がかかる場合は？
A：サンプルデータや疑似導入で“体験”を先に作り、TTVを短縮してください。
Q2：MVP段階で通知やD1は必要ですか？
A：はい。翌日活性が測れないと継続性を誤解します。簡易通知でも必須です。
Q3：Wizard of Oz方式は不誠実では？
A：検証目的を明示すれば問題ありません。むしろ“必要最小限で学ぶ”正攻法です。
▼有料note（直リンク）
コメント