それではこの章の最後にユーザーインタビューをしていきましょう。ここでは、MVP仮説を検証するMVPインタビューを行います。構築したMVPを実際にユーザーの方に使ってもらいつつ、対話を通して仮説を検証していきます。
ここでも重要になるのが、ユーザー集めと台本づくりです。ユーザーについては、これまでのユーザーインタビューで協力してくれた方を軸にお願いしてみましょう。他の方を紹介してもらうのもいいです。
Twitterを運用しているのであれば、Twitter上で募集のお願いを投稿するのも効果的です。MVPは実際に体験できるプロダクトなので、これまでのプロブレムインタビューやソリューションインタビューよりも協力してくれる方がふえる傾向にあります。
台本については、プロダクトによって様々なので一概にはいえません。MVP仮説を検証できるようにMVPを利用してもらう、という観点で台本をつくってみましょう。
MVPインタビューを行ったら、その都度結果をまとめます。仮説マトリクスを更新したり、あるいはMVP自体を修正する必要も出てきます。もちろんあわせて必要に応じてリーンキャンバスやフックモデル、ユーザーストーリーマップなどほかのドキュメントも修正する必要があるかもしれません。
いずれにしても、実際のプロダクトをつくる前の最後のブラッシュアップの機会です。MVPインタビューを繰り返して、不確実な仮説をできるだけなくしていきましょう。
MVP仮説を検証するのがMVPインタビュー。インタビューを繰り返して、仮説マトリクスを修正する必要がなくなったときが完了の目安です。
やってみよう
MVPインタビューの相手を3人以上集めてみましょう。あわせて台本をつくりましょう。インタビューをしたら、結果をまとめましょう。必要に応じて仮説マトリクスやこれまでつくったドキュメントを更新しましょう。
ユーザーインタビューについては、「ユーザーインタビューのやり方」で詳しく解説しています。あわせてご覧ください。
例:tsukuri
前のセクションで、MVP仮説の仮説マトリクスを整理しました。これをもとにMVPインタビューをしていきます。
まず、tsukuriは開発者とユーザーからなるコミュニティです。開発者側のインタビューの相手としては、ソリューションインタビューに協力してくれた7名のうち、都合のついた5名にお願いできました。それ以外にも、ユーザー側としてTwitterで呼びかけたところ、20名ものユーザーに協力してもらえました。
MVPインタビューの流れとしては、以下になります。まず開発者の方にひとりひとつ公開チャンネルをつくってもらいます。このチャンネルで、すきなタイミングでプロダクトのアップデートなどを投稿してもらいます。
ユーザーには、気になるチャンネルに自由に参加してもらいます。チャンネル内では、開発者の投稿に対するリアクションやコメント、またプロダクトに対する意見などを自由に投稿してもらいます。
これを2週間続けました。並行して、1週間が経過したタイミングで開発者に対するMVPインタビューをはじめました。その結果、MVP仮説に対して次のような結果が出ました。
- 収益モデルとして、チーム利用に4,980円/月を設定していた。ただ、個人用途でも十分使えるので、有料にしてまで利用しようとは思わない
- 投稿に対してリアクションやポジティブなコメントをもらえるのはすごくうれしい。これだけで利用を継続したいと思える
- フォロワーの数はそこまで重要ではない。それよりも「誰がフォローしてくれたか」が気になる
以上の結果、次のような学びを得ました。
- 料金モデルを見直す必要がある。インタビューを繰り返したところ、API連携や独自ドメインの設定といった「機能の開放」のためなら支払いたいという開発者が多かった
- フォロワー数やリアクション数などの数値も重要だが、「誰が行ったか」というユーザーにフォーカスした情報を提示すべき
- その他、tsukuriへの投稿をTwitterに自動で同時投稿したい、というニーズが大きかった
この学びをもとにMVPやフックモデル、ユーザーストーリーマップなどを見直しました。インタビューを繰り返し、新しい学びが出なくなったところでMVPの検証を終了としました。次はいよいよ実際の製品をつくりはじめていきます。