見出し画像

PMFのはかり方、見つけ方: やや実践編

原健一郎 | Kenichiro Hara

同時に書いた"基礎編"では、若干細かい内容になるのでこちらのポストに記載することにしました。ただ、この内容もただいろんな記事をまとめただけの、"やや実践編"です。大切な真実、本物の実践、一番新しい方法、最先端、は常にプロダクトの現場にしかありません。また、こういう基礎が全部知りたい人はY Combinatorのスタートアップスクールがおすすめです。2015-2019、全部見て欲しいです。

基礎編はこちらです。

PMFのはかり方

PMFは曖昧な指標です。下記にはかり方の例をいくつか示しますが、下記の英文記事が参考になります。

PMFをはかるとき(見つけるときも同じですが)、対象となるユーザーが、友達や近しい人だと正しいフィードバックをくれない可能性が高いです。無料ユーザーについても同じです。ユーザーは、自分との距離が遠くなり、お金を払っていればいるほど、正しいフィードバックをくれます。

1. 先行指標

1-1: Sean Ellis test. このプロダクトが明日なくなったら困るか?

DropboxやEventbriteの初期のグロースを支え、グロースハッカーという言葉を作ったSean Ellisが作ったテストで、下記のような質問をします。

もしこのプロダクトが使えなくなったとしたら、どう感じますか？
1. とても残念である
2. まあまあ残念である
3. 残念ではない (あまり便利ではなかった)
4. もうこのプロダクトを使っていない

40%以上の人が、"1. とても残念である"を選んだとしたら、PMFがあるという考えです。PMFスコアとも呼ばれます。2015のSlackではこの数値は51%でした。昨年アメリカで彗星のように現れ爆発的に人気を得たのち、a16zらから$33M集めたemailクライアントのSuperhumanは2017の夏にこの数値が22%でしたが、PMFスコアを上げることに注力し3四半期で58%まで上昇しました。どうやってあげたかはPMFの見つけ方で記載します。

1-2: 口コミ

口コミがどれだけあるか、Y CombinatorのSam Altmanはこの指標をすすめています。

"I think the right initial metric is “do any users love our product so much they spontaneously tell other people to use it?” Until that’s a “yes”, founders are generally better off focusing on this instead of a growth target."
PMFがあるかという正しい指標は"自分たちのプロダクトを愛してくれているユーザーが、自主的に他の人にプロダクトを勧めているか"、この答えが"Yes"でないかぎり、プロダクトにフォーカスし、グロースに軸をおかない方がいい。

定性的にこれをはかったり、アンケートをとってもいいかもしれませんし、twitterで自社サービスを検索するだけでもある程度はわかるかもしれません。定量的にとりたいなら、友だち招待機能を実装し、口コミ係数"Viral Coefficient"をとってもいいかもしれません。kが1以上であればバイラルが聞いていることになります。

Viral Coefficient: k = 友だち招待を送ったユーザーの平均招待数 x コンバージョン率
C(0) * k = その期間の終了時点でのユーザー数
C(0) = その期間の開始時点でのユーザー数
i = ユーザーが送る友達招待の平均数
c = 友達招待のコンバージョン率

1-3: NPS

NPSもよく使われます。一方で、みんなが"5"をつけやすい日本では、どんな業界でもNPSは低くなります(NPSだと"5"はマイナスのため)。なので、同じ業界のプロダクトと比較して使いましょう。また、自分のサービスで、毎月、毎週、など新たなユーザーにNPSをとって、時系列で比較するのも有意義かもしれません。

2. エンゲージメント

先行指標よりも大切なのは、実際にユーザーが使っているか、というエンゲージメントの指標です。このエンゲージメントの指標はプロダクトによって使われ方が異なるため、どの数字を、どの頻度でとるべきか、プロダクトごとに検討してみましょう。SNSであれば毎日、メッセンジャーやAPI系(決済等)であれば毎時間使われるべきですし、Airbnbのような旅行であれば短期間すぎると正しい指標にはならないです。
このエンゲージメントの数字は、他のプロダクトや業界水準と必ず比較しないといけません。DAU/MAUが20%だと素晴らしいプロダクトも、微妙なプロダクトもあります。

画像1

3. リテンション

PMFをはかるための基本はリテンションです。グロースを始める前、つまりPMFがあると判断した前に、絶対にリテンションがないといけません。B2Cプロダクトなら、1日後、7日後、30日後(28日後)のリテンション。B2Bならチャーンレートになります。初期のFacebookではコンシューマーだけでなく、広告主側も、様々な下記のような機能に対して、リテンションで判断していました。
こちらも同じく他のプロダクトや業界の平均と比較してください。30d RRが20%あることが、いいプロダクト、悪いプロダクト、様々です。

下記実際のリテンションの例です。

画像5

↑ 12ヶ月後に70%で、7年後も30%のリテンション。こちらはNetflixです。

画像6

↑ 1ヶ月後に10%ですが、12ヶ月後で12%のリテンション。こちらはShopifyです。
リテンションが一度落ちてから一定水準に落ち着き段々あがるというスマイルカーブを描いています。
例えばAmazonのようなe-commerceでも、フードデリバリーでも同じようなカーブを描きます。フードデリバリーのいいプロダクトだとMonth 1の購買頻度は1.5回などですが、Month 2には3回弱、2yr後では3.5回などになったりします。

画像6

↑一方でこちらはサブスクリプションコマースのBlue Apronです。この数字も類似サービスと比較してみる必要がありますが、この数字から果たしてPMFがあるかどうかを判断すべきかと思います。

最初から年間契約にしていると、キャッシュフロー上はいいのですが、実は顧客に"本当に"ささっているかわかりづらくなります。一番怖いのは、年間契約で契約を取り続け、営業人員を拡大しつづけた後、一年後にユーザーが大幅にチャーンすることです。PMF期においては、ユーザーからのリテンションが頻繁に計測できたほうがいいかもしれません。

4. PMFがはかれない指標

PMFをはかる指標は、ユーザーの課題が解決され満足されているか、をはかるものです。したがって、登録ユーザー数、ページビュー、クーポンを出した上でのコンバージョン、など、広告やメディア露出や"補助金"でつくることができる数値ではありません。資金調達額やバリュエーションなんてもってのほかだと思います。

PMFの見つけ方

まず重要になるのは、PMFのMで、"どのユーザーを対象にして"PMFをはかるかです。ここが最初は小さくてもとにかく具体的に絞り込むことが重要かと思います。Facebookはハーバードの大学生、Yelpは"レストランのレビューを書く27歳でサンフランシスコに住む人"です。はじめは小さく見られている小さなセグメントで熱狂を生み、それが近接する市場へと広がっていきます。

一方で、どのユーザーをターゲットにするか、これはフレキシブルでいないといけません。自分が思いもしないユーザーを対象にPMFがあるかもしれません。Twitchはjustin.tvというライブストリーミングのプロダクトでしたが、知らない間にゲーマーに幅広く使われるようになり、ゲーマー向けにデザインを変えたものがTwitchとなりました。Twitchはその後約1000億円でAmazonに買収されています。

A. PMFの見つけ方(プロダクト作成前)

Y CombinatorのStartup SchoolでWeeblyのDavid Rusenkoが下記のようなプロセスを提示しています。(わかりやすい動画なのでおすすめです)

1. ユーザーと話す。ユーザーについての仮説を作る
2. ユーザーから"現状の課題"を聞く ("何が欲しいか"は聞かない)
3. プロトタイピング&ユーザーテスト (UXテストでは"何も言わない")
4. 2で聞いた課題を解決するソリューションを作る
5. ユーザーに公開する
6. ダメなら1に戻る

このループを10-20回は行います。1-2回でPMFを見つけた人はいません。
カスタマーインタビューは最低5-10人、UXテストは最低3-5回、と推奨されています。

2.現状の課題を聞く際の注意点および質問の例です。

注意点
1. 相手の生活について"聞く"。自分たちのプロダクトの話をしない
2. 具体例のみ話す。”仮定”、”もし”、という聞き方はしない
3. 聞く。こちらから説明しない
質問例
1. 何が一番いまのxxをしていて大変ですか?
2. 一番最近その課題に直面した時のことを教えてください?
3. それはなぜ大変なんですか?
4. その課題を解こうと思ったことはありますか? どのような解決策を試しましたか?
5. なぜその解決策ではだめだったのですか? 

3. プロトタイピングのポイントになるのは、完成品に近いものではなく、最低限の機能と"仮説検証"に使えるプロトタイプをつくるということです。
ユーザーの課題がなにで、この機能で課題を解決でき、ユーザーから満足をえられるか、という仮説検証に使えないものはプロトタイプには適さないかもしれません。

画像2

一方で、課題解決だけでなく、"楽しさ"などの価値も提供する場合は、MVP (Minimal Viable Product)ではなく、MLP (Minimal Lovable Product)という発想をしてもいいかもしれません。

画像3

ここでMVPの例です。基礎編でも示したように、Airbnbでの初期の検証課題は"ユーザーが他人の部屋にお金を払って泊まるか"です。したがって、初期のプロトタイプには決済手段(現場手渡し)も地図も日付指定もありませんでした。

↓Twitch (旧justin.tv)です。解像度は低く、Justinの生活をストリームするだけのプロダクト。ビデオゲームは全く関係ありませんでした。繰り返しになりますが、TwitchはJustin.tvをローンチした後に、妙に盛り上がっているユーザーセグメントがあったのがゲーマーで、そこに特化したプロダクトです。

画像7

↓Stripeです。機能は少なく、プロダクトのデプロイは創業者が自分で顧客を訪問して行っていました。

画像8

プロトタイプを作ったらいつ公開するか、Y CombinatorのPaul Buchheitの言葉です。

"Launch when your product is better than what's out there"
世の中にあるものよりも、自社プロダクトがよくなったら公開しろ

B. PMFの見つけ方 (プロダクト作成後: Superhumanの例)

ここでは、SuperhumanがいかにPMFスコアを22%から58%にあげたかを書きます。下の記事がものすごく参考になります。ここではあえていくつかの記事からの僕なりのまとめや学びではなく、この一本の記事の要約にします。
プロダクトをやっている方は、ぜひぜひこの英文記事を熟読してほしいです。かなりの本数の記事を読んでいると思いますが、Superhumanの記事は本当にいいです。

前提としてSuperhumanは2015年から開発を続け、2017年ごろからローンチ前にPMFをテストをする方法としてEllisのスコアを用い、そしてそれをベースにPMFスコアを40以上になるように開発をする、という手法を用いました。なので下記のユーザーインサイトは初期のベータ版の人からのものです。

まずEllisのPMFテストに加えて、ユーザーに下記の質問を行います。

1. (PMFテスト) 明日からもうSuperhumanが使えなくなったとしたらどう思いますか
2. Superhumanを使ってもっとも助かると思うはどういう人だと思いますか
3. あなたがSuperhumanを使って、一番よかった機能は何ですか
4. Superhumanをより良くするとしたら何が必要ですか

2-4は定性的な自由質問です。

ステップ1) カスタマーセグメントの絞り込みともっとも期待されているカスタマー(HXC)の解像度向上

1.のEllisの質問でSuperhumanは22%しか"とても残念だと感じる"と思う人がいませんでした。ただそこからすべての人を職種ごとにカテゴリします。そして、創業者、マネージャー、エグゼクティブ、事業開発、に絞ると"とても残念だと感じる"人の割合は32%に増えました。
プロダクトを改善する前に、まずセグメント(PMFのM)を絞るとで40%にやや近づいています。

画像9

画像10

画像11

Superhumanは、もっとも期待されているカスタマーセグメント(HXC: high-expectation customer)にフォーカスし、HXCがどのような人物像なのかペルソナを書き上げます。ここで役立つのが2つめの質問の"2. Superhumanを使ってもっとも助かると思うはどういう人だと思いますか"です。下記がペルソナです。

ニコルはよく働くプロフェッショナルで多くの人と仕事をする。例えば彼女はエグゼクティブまたは起業家またはマネージャーまたは事業開発。ニコルの労働時間は長く、よく週末も仕事をする。ニコルも自分が意思がしいことを認識していて、もっと空き時間ができればと思っている。ニコルは自分が生産的であると感じているものの、もっと生産性があげられると考えており、生産性を上げる方法をよく探している。彼女の1日でemailのやりとりを行っていることが多く、1日に100-200のemailを読み、15-40のemailを送信する。(忙しい日には80通も送信する)
ニコルは常に返信が早いことが重要だと考えており、そうしていることにプライドを持っている。自分がすぐに返信しないとチームに迷惑がかかるし、評判も悪くなるし、事業機会も失うと感じている。常に受信箱の未読をゼロにしたいが、週に2-3回しかゼロにはできていない。そしてごく稀に(年に一度くらい)、受信箱にメールが溢れた結果一括削除してしまう。彼女は成長意欲が強い。新しいプロダクトにもオープンで新しいテクノロジーのチェックも欠かさないが、emailについては特に何も考えていない。新しいemailクライアントも試してみたいが、本当にそれで早くなるかは疑問を持っている。

ステップ2) フィードバックを分析し、熱狂的とは言えないユーザーを熱狂的なファンに転換する

このステップでは、EllisのPMFテストで、すごく残念であると答えたユーザーと、まあまあ残念である、と答えたユーザーを分析します。何があるから熱狂的になり、何がそうでないユーザーをブロックしているのか。

ここで使うのが、"3. あなたがSuperhumanを使って、一番よかった機能は何ですか"で、まず熱狂的なユーザーから解析します。その答えをまとめたのが下の図です。

画像12

熱狂的なユーザーが、スピード、ショートカット、キーボード入力、があるからSuperhumanがいいと思っていることがわかります。つまりこれを強化すると、より一層熱狂的なファンになるということです。

次に、"まあまあ残念だと思う"グループの同じ質問を分析し、どれくらいの人が"スピード"が一番Superhumanで気に入っている機能だと答えているかをみます。その結果が下のようになります。

画像13

つまり、"まあまあ残念だと感じる"グループの中にもスピードが重要だと感じている人たちがいることがわかります。問題はこの人たちをどのように熱狂的なファンにするか。

このプロセスで見逃せないのが、プロダクトがなくなってもまったく残念だとは思っていないユーザーや、スピードが一番の魅力だとは感じていない"まあまあ残念だと感じる"グループはフォーカスに入れないことです。重要なのはプロダクトがないと"とても残念に思う"人を40%にすること。それにフォーカスします。

次に、スピードが一番の魅力だと感じている、"まあまあ残念だと感じる"グループ(熱狂的なファンにしやすいグループ)の、"4. Superhumanをより良くするとしたら何が必要ですか"の質問を分析します。その結果がこちらです。

画像14

ここで明らかになるのが、モバイルアプリがないこと、が熱狂的なファンが足りない理由だということです。

ステップ3) ロードマップの作成: 熱狂的なファンの強化、および、"まあまあ残念だと感じる"グループへのアドレス

ここでSuperhumanはチームを2つに分けます。一つのチームは、熱狂的なファン("とても残念に感じる"グループ)が喜ぶ機能(スピード、ショートカット、自動化)を強化し競合との差別化にします。もう一つのチームは、もう少しで熱狂的なファンになるグループが欲しがる機能(モバイルアプリ、カレンダー、添付ファイル、インテグレーション、検索など)の改善を行います。

この段階ではPMF前です。Superhumanのチームのサイズは14人です。とにかく小さく、早く、まわしています。

ステップ4) プロセスを繰り返し、PMFスコアを最も大切な指標におく

チームはPMFスコア40以上をOKRにも設定し、新しいユーザーにも先の質問とその分析を繰り返します。PMFスコアは、毎週、毎月、毎四半期にトラックし、それを簡単にトラックできるツールも開発しています。
そしてその結果が以下になります。

画像15

2017年に14人だったSuperhumanはこのPMFを経て、ようやく22人にチームをスケールしました。

C. まとめ (PMF後)

ここからはまとめになります。PMFがあったプロダクトでも、新しい機能の開発、さらなる市場拡大、には同じPMFのプロセスがあると思っています。Facebookの成長も、ただ一度のPMFではなく、グローバル、モバイルと何度もPMFを続け成長しているのがわかります。

画像16


PMFは正しい数値をはかりながら、何度も何度もユーザーのフィードバックを参考に改善を繰り返すのちに見つかるものです。そこに近道はありませんし、天才起業家/PMでないといけない道でもありません。
ただ、PMFがないと事業が成功しないことは間違いないですし、このPMFを見つけるプロセスこそスタートアップの面白いところだと個人的には思っています。めちゃくちゃ大変ですが、最高な時間なのかもしれません。

ここまで長い記事をお読みいただきありがとうございました。
最高のプロダクトづくりに興味がある方、DCMの投資先に是非ご連絡ください。

参考文献



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