順風満帆なスタート
他の99%のプロダクトマネージャーと同様、Minimum Viable Products (MVP) について、エリック・リース（Eric Ries）の著書「リーン・スタートアップ」から私は学びました。この本とエリックの方法に偶然出会ったとき、「やった！これ自分が探していたものだ。これはとても理にかなっている」と心の中で叫びました。「プロダクトを作る前にテストする？なんて斬新なアイデアなんでしょう。」とワクワクしました。体に力がみなぎってきました。「これからは顧客にとって意味のあるものを作っていこう」と心に誓ったのです。
正直、私にとってこの出会いは完璧なタイミングでした。誰も使わないプロダクトを作ったり、Googleアナリティクスで数字を見て上がるまで待っていることに私は辟易していました。そのようなやり方は古くなっていたのです。私とチームは、成功すると思ったプロダクトを何ヶ月もかけて作っていましたが、失望するばかりでした。新プロダクトでMVPのアプローチを試す機会が訪れた時、すぐに飛びつきました。
EC会社のCEOから、エンゲージメントを高め、商品をより多く販売できる新プロダクトのアイデアを持ちかけられました。サイトで商品を販売している有名人が自分の生活について投稿できるように、ツイッターのようなフィード機能をCEOは実装したがっていました。このアイデアはテストに最適で、いろんな憶説が入っていました。プラットフォームで販売している有名人の動向を顧客は聞きたいのだろうか？より多くの商品が売れるのか、それともユーザーの継続を高めるのか？
私はエンジニアのところに行き、CEOが提案しているアイデアをゼロから完全に実現するにはどれくらいの時間がかかるのかを聞いてみました。概算の見積もりを持って、私は大胆不敵なCEOの元に戻りました。「これは完全に構築するのに750万円かかるし、顧客がそれを望んでいるかどうかもわからない。これが売上などに影響があるかどうか、1週間で20万円で証明できます。」その提案をCEOは受け入れました。
１週間以内に、ツイッターのようなフィードがひどいアイデアであることを証明しました。その１週間後、商品のクリックスルー率を３倍に増加させる別のソリューションを見つけました。またコンバージョン率も２倍になりました。会社全体に受け入れられ、実験の継続を許されました。「素晴らしい」と私は思いました。「みんなこの価値を分かってくれた！とても簡単な事だ」
その後、別の会社に転職して、新しいチームにもMVPの概念を導入することを考えていました。正直なところ、その会社の誰もがまだMVPを使っていないことに少しショックを受けました。この素晴らしい魔術を知らなかったのでしょうか？前の会社と同じように、すべてがうまくいくと確信していました。
「ここではそんな事はしません」
「Minimum Viable Product」という言葉を初めて口にしたとき、会議室内の反応は私の予想とは全く違っていました。英語の辞書に載っている全ての呪いの言葉を私が暗唱したのかと思っただろうし、会議の最中にビギー・スモールズ (訳者注：ラッパーの Notorious B.I.G) の曲を陽気な歌詞に交えて披露したのかと思ったかもしれません。まるで先祖を怒らせたかのように彼らは反応しました。最後に CMO が沈黙を破って、「ここではそんな事はしません。ひどいプロダクトはリリースしません」と言いました。
それからの数年間、何度も同じ目に会いました。
「Minimum Viable Products」は広く誤解されています。先入観のせいで一部の人々はMVPを作ることを恐れています。また、MVP という言葉を使いすぎて MVP の意味を見失った人もいます。「あれを MVP するべきだ！」という言葉は、プロダクト開発におけるスローガンとなっていますが、MVP は単に「最小限にする、安く作る、早く作る」という意味になっています。
どうして、MVP が完全に勘違いされているのか？いつもだいたい同じ話です。誰かが「The Lean Startup (リーン・スタートアップ 日経BP)」を読んで、感銘を受けて「ここで MVP をやるべきだ！」と言い放ちました。MVP の目的が何なのか、どうすればうまく作れるのかを完全に理解しないまま、プロダクトを手っ取り早く、安く、実行する方法だと思い込んでしまいました。特に私がうんざりとした会社では、新機能をテストするために開発者が乱暴な仕事をしてしまい、誰かが新機能を使おうとするたびに壊れていました。顧客は怒っていました。この会社の本当の問題はずさんな開発にあるにも関わらず、全面的に MVP のせいにしました。
MVP のせいではありません。問題は MVP とは何かを誤解していたことと、それに伴うコミュニケーションのミスから生じています。
MVPとは何か？
私の定義する MVP とは、「学ぶための最小の努力」です。ワークショップで MVP を教えるとき、大抵は反対意見に出会います。「MVP は、構築して販売できる最小の機能セットだ！ユーザーは、ただの実験の相手ではない」
では、本当のところはどうなのでしょう？MVP はプロダクトなのか、プロダクトの一部の機能だけのものなのか、それとも単なる実験なのか？
「Minimum Viable Product」は、スティーブ・ブランク (Steve Blank ) が最初に作った造語で、その後、エリック・リース (Eric Ries) が「The Lean Startup（リーン・スタートアップ 日経BP社）」の中で広めました。この2人の専門家や他の数人の専門家がこの用語をどのように定義したのかを調べてみました。
「Minimal viable product」とは、出荷できるだけの機能を備えていて、アーリー・アダプターが使えるプロダクトで、少なくとも一部の人が共感し、お金を払い、フィードバックを受け始めます。
–エリック・リース、2009年
『Minimum feature set（minimal viable productとも言う）は、エンジニアリングの無駄を省き、アーリーバンジェリスト (Earlyvangelists) の手に早くプロダクトが渡るようにするための「顧客開発戦術」である。』
– スティーブ・ブランク、2010年
「Minimal viable product（MVP）とは、必ずしも最終プロダクトの小型化・廉価版とは限らない。」
– スティーブ・ブランク、2013年
「MVPとは、機能の半分を切り取っただけのプロダクトや、プロダクトを少し早く出荷するための方法ではありません。実際、MVPはプロダクトである必要は全くありません。また、MVP は一度だけ作って、仕事を終えたとみなすものでもありません。」
– イエヴゲニー・ブリクマン (Yevgeniy Brikman)、Y Combinator、2016年
混乱しますよね？この調査を通して明らかになったことは、MVP の定義が進化してきたということです。当初は、スタートアップのアイデアを検証するためのものとして MVP の話をしていました。どのプロダクトもプロダクトと市場の適合性を模索していました。当時、私はコンシェルジュ実験やオズの魔法使いについて学び、それが定義や理解を形作ってくれました。スタートアップや大企業のプロダクトマネージャーとしてこれらの方法を使い続けるうちに、私は自分の定義と、MVP を構築する実践の両方をカスタマイズする必要がありました。私が学んだことは、成功するためには、実験するというコンセプトと、最低限の機能セットを構築するというコンセプトの、両方が必要だということです。
MVP の定義については反対意見が多いですが、ゴールについては、誰もが同意しています。MVP のゴールは、顧客が何を求めているのかを素早く知ることです。できるだけ素早く知ることで正しいものを構築することに集中できます。なので MVP を流行語としてではなく、それが意味するものに焦点を当ててみましょう。MVP とは何かで議論するのをやめて、企業として何を学ぶべきかについて話しましょう。
どうやっていつ学ぶ
新しい機能やプロダクトを作り始めると、無数に質問が出てきます。「顧客の問題をこれは解決するのか？本当にこの問題は存在するのか？最終的にユーザーは何を得ることを期待しているのか？」
最小限の機能セット (minimum feature set) から始めるのは、危険だというのはこのためです。実験を行わずに、新プロダクトや機能の最初のバージョンをすぐ構築してしまうと、学ぶことを忘れてしまいます。この段落冒頭の質問に答えながら実験を行うことで、顧客の問題の発見と適切なソリューションの発見に役立ちます。１つだけの実験では終わりません。追加の実験を複数行い、更に質問に答えていきましょう。ソリューションを最終的に決める前に、できるだけ多くの質問に答えた方が、プロダクトをユーザーが使ってくれる確度があがります。
実際にあなたのプロダクトをユーザーが欲しがっていることを証明したら、次は最低限の機能セット (minimum feature set) を調査しましょう。これで、市場があり、売れるプロダクトを見つけはじめられます。また実験を通して明らかになったユーザーのニーズにプロダクトが近づきます。できるだけ早く市場にプロダクトを投入するのが最も重要なゴールであり、それで顧客からのフィードバックを得て反復できます。しかし小さなものであっても、質の高いプロダクトを提供してください。壊れたプロダクトは、顧客にとって価値が無く、悩みの種になるだけです。価値の無いプロダクトは、どのバージョンも意味がありません。
ここで実例をひとつ紹介します。私が働いていた SaaS のある会社では、顧客のゴール予測に役立つ新機能を実装しなければなりませんでした。顧客からの話を聞いた営業チームの報告を受けた後、もっと学ぶ必要があると気づきました。
このゴール予測の機能で、顧客が何を求めているのかを理解しようと、顧客に実際に会ってみました。顧客のニーズを十分に把握できたと判断したので、一部の顧客でスプレッドシートを作成し、現在のデータを入力しました。これには１週間もかかりませんでした。このスプレッドシートを顧客に１週間使用してもらってからフィードバックをもらいました。１回目、２回目、３回目はスプレッドシートがうまく機能しませんでした。しかし、４回目の反復では、顧客が求めていた正確な結果を出せました。他の数人の顧客にもこのスプレッドシートを使ってもらって、同じく正確な結果が出ることを確認しました。
実験をした一部の顧客にはこのスプレッドシートはすぐに価値がありましたが、社内には全ての顧客をカバーできる体制はありませんでした。そのため、ソフトウェアでソリューションを構築する必要がありました。スプレッドシートで得たフィードバックから、最低限の機能セットの検討を開始しました。顧客が他にも欲しがっていた機能はたくさんありましたが、必要なものだけに絞り込みました。最初のバージョンが動作するまでに数週間かかりました。そして、フィードバックを得るために、さらに少数の顧客をピックアップし、このバージョンをリリースしました。何度か反復を繰り返した後、他の顧客に販売し始めました。
このプロセスは、あなたの会社で問題とソリューションの適合性を見つけるのに役立ちます。ユーザーにとって異なる問題を解決する新しい機能を作ったり、新しいビジネス領域を立ち上げているとき、顧客にとって正しいものを構築しているかどうかをこの方法で確認できます。しかし、成熟したプロダクトがあり、ゼロからのスタートではない場合はどうでしょうか？
エンタープライズでの実験
ゼロから全く新しいプロダクトを作る提案をするコンサル会社によって、現在多くの企業がMVP を紹介されています。これは最良のアイデアではないかもしれません。自分の会社にプロダクトと市場の適合性がある場合、すでに顧客が使っているプロダクトがあるはずです。その場合はプロダクトを再構築する必要はなく、プロダクトを改善する必要があります。
この２つのどちらかを選ぶのを決めるのは、ゴールです。プロダクトと市場の適合性を手探りしている時、プロダクトをユーザーが採用し、課金してもらいたいと考えるでしょう。既存のプロダクトを改善する場合、採用や課金は常にゴールではありません。その代わりに、ゴールは継続率を向上させることや、プロダクトの特定の部分へのエンゲージメントを高めることかもしれません。設定したゴールが何であれ、チームにとって明確なものであり、チームのすべての意思決定に影響を与えるものでなければなりません。
ゴールが明確になったら、学ぶことに集中しましょう。どのソリューションにするか最終的に決める前に何を学ぶ必要がありますか？目立った変化を起こすものの仮説を書き出し、その仮説をテストするためのプロダクト実験を設計します。全く新しいプロダクトを作る必要はありません。もしかしたら、実験を通して新しいプロダクトが必要であることが分かるかもしれませんが、それが最終的なゴールではありません。
私がコーチングしたある企業は、サイト全体のコンバージョン率を上げたいと考えていました。その企業にはすでに数千人のユーザーを抱える人気の高いECのサブスクリプションプロダクトがありました。トラフィックは入ってきていましたが、予測したほどユーザーはコンバージョンしていませんでした。様々な特典を用意しても、大きな変化はありませんでした。優良な顧客がどこから来ているのかを掘り下げると、多くが紹介者を介して来ていることを発見しました。しかし、実際に紹介状を送っている人はごくわずかでした。ユーザーリサーチを通じて、２つの主な理由を発見しました。１つ目は顧客が招待状を送信できることを知らなかったこと、２つ目は招待状を受け取った自分の友人にどういうメリットがあるか分からなかったことです。
１つ目の問題に対して「きちんと招待機能を伝えれば、ユーザーは友達を招待するだろう」という仮説を立てて取り組むことにしました。最初の実験では、ユーザーがサイトにログインしたとき、招待機能のポップアップを表示しました。招待状の送信数は30%増加し、コンバージョン率の向上につながりました。全く新しい機能を作る必要はなく、もっと目立つように表示するだけで良かったのです。
このチームは、コンバージョン周りの問題をさらに掘り下げました。ウェブサイト内の体験の問題の上位３位は、すべて情報の不足が原因であったことを学びました。
- 顧客は、どのようにサービスが機能するか理解できなかった。
- 顧客は、どのアイテムがサブスクリプションに含まれているか知りたかった。
- 顧客は、競合他社よりもサブスクリプションの価格が高く設定されている理由がわからなかった。
ユーザーに価値を与えながら、同時に学習も行いたいと考えていました。「新規登録フローの中で、ユーザーが探している情報を提示すれば、より多くのユーザーがサブスクリプションに登録するだろう」という仮説を立てました。サインアップフローにいくつかのリンクを追加し、これらの３つの問題に関する質問を提示するというシンプルな方法を計画しました。リンクがクリックされると、その質問に答えるポップアップが表示されます。３つのうちどの質問が一番理解できなかったかを判断するために、最も多くクリックされたリンクを測定しました。
週の終わりには、この実験でコンバージョン率が上昇しました。また、ユーザーがサブスクリプションで何を受け取るかに関するリンクが最もクリック数が多く、知りたかった情報の中で最も重要であることが分かりました。見込み客の登録を何が妨げているのかを学び続け、それらの疑問に実験を通して体系的に答えていきました。
ここからの注意
プロダクト実験に取り組む際に企業が犯す間違いの一つは、一度学習した機能をそのままにしておくことです。そうすると、そのままの機能は壊れてしまい、ユーザーに問題を引き起こしてしまいます。あなたが設計しているのは、学習して次に進むためのものであって、永遠に続く機能を実装するためのものではありません。
上記のチームでは、提供する情報は見込み客の回答に役立っているが、その解決策を見つけている人が十分ではないことを知りました。さらに実験を重ねた結果、より強固なソリューションが必要であることがわかりました。そして、実験で学んだことを取り入れた持続可能なソリューションの計画を始める時が来たのです。
プロダクト実験から次のフェーズに移ったからといって、測定をやめる口実とはなりません。このチームはコンポーネントを小ロットでリリースし続けましたが、それらの小さな機能は美しいデザインとより全体的なビジョンを持って完成されていました。隔週でリリースした後、コンバージョンにどのような効果があったかを測定し、顧客の前でテストしました。そのフィードバックは、コンバージョン率の目標に到達するプロダクトに向けての反復作業に役立ちました。
Chris Matts氏は、これを「Minimum Viable Investment(実用最小限の投資)」と雄弁に名付けています。彼はまた、ユーザーに向けたプロダクトの改善だけでなく、それらのプロダクトを迅速に作成するための組織の改善にも目を向けるべきだと指摘しています。上のチームは、実験のテスト結果が出るのをもっと早くするために、サイトアーキテクチャの改善も行っていたそうです。プロダクト・カタを紹介したのは、プロダクトの実験や最低限のバイアブルな投資を通じて、チームが構造を見つけやすくなるようにプロダクトを改善しているチームです。
学びがゴール
多くの企業にとって、このプロセスの中で最も避けたいことのひとつは完璧ではないものをリリースすることです。デザインの品質と工期、開発の品質と工期、のバランスが重要です。それにはUIデザイナーと開発者がペアを組むことが最良です。反復や実験のゴールを定義後、UIデザイナーと開発者がミーティングをして、開発に関して話し合うようにします。少し違った方法でデザインしたとしても、ユーザーにとって同じように有用であれば、より簡単に構築できる方法を選びましょう。スケッチやプロトタイプを一緒に作成し、トレードオフについて常に話し合いましょう。これが良いチームが迅速に動き、手戻りが減る方法です。
ユーザーが何を求めているのかを早い段階で知ることで、多くの時間をかけて手直しをしたり、作った機能を捨てることを避けられます。これが、B2BであろうとB2Cであろうと、実験が非常に重要な理由です。
プロダクトチームがユーザーと直接会話できるようにします。プロダクトチームがユーザーを怒らせるような言動をすることを恐れている企業を見てきました。しかし、プロダクトチームに正しいコミュニケーション方法や実験方法を教えれば、このようなことは起こりません。プロダクトチームにユーザーリサーチのトレーニングをしましょう。実験を全てのユーザーに行ってはいけません。一部のユーザーだけのグループを作ります。一部のユーザーだけに実験や機能を提供できるインフラを構築します。ユーザーのニーズに合致する機能に導いてくれます。
どこかの会社で MVP と言っても、「ここではそんなことはしない 」などと言われない日を夢見ています。「Minimum Viable Product」の定義は、私たちを混乱させるかもしれませんが、MVP の背後のゴールは、プロダクト企業に非常に価値のあるものです。もしあなたが社内で MVP の実践に苦労しているならば、わざと MVP という流行語を控えてみてください。かわりに「実験」のような用語を使い、実験の背景に焦点を当ててください。ユーザーが何を求めているのかを構築する前に学ぶことが、良いプロダクト開発につながります。機能やソリューションが正しい事を確認して、投資しましょう。
引用元
Finding the Truth Behind MVPs
