サービス開発初期における「熱狂」への全集中の呼吸
意識していないと忘れてしまうことに、「0->1」のリリース直後にいかに「熱狂」に集中できるか、というのがあると思う。誰しも、リリース後の情報量・ノイズに飲まれるとブレがちになる。（まさに「自分だけは違う」、となる）
熱狂への全集中
「熱狂」への全集中とは、端的に言えば、以下のようなアプローチだ。
・触った人全体ではなく、「触ってドハマりしている人」の「有無」とその「ハマり度合い」を見ること
・「触ってハマっている人」が、「継続的に」使うか、そして「どんどんハマっていくか」を見ること
・「触ってハマっている人」の「観察」から学び、彼らに踊らされながら開発をしていくこと
熱狂はその後の成長の「角度」を作る。
「SoSo」なプロダクトや機能を伸ばしていくことと、「熱狂」のあるプロダクトや機能を伸ばしていくことは、難易度・成長角度が全く異なる。（シンプルには、リテンションレートに現れやすく、その後の成長投資のROIに直結する）
以下、鬼滅ブームにもあやかって、熱狂への全集中の呼吸を妨げる罠や実事例についていくつか書いておく。
＊注：私の経験上ではC向けサービスの話だが、toBでも初期においては大差ないかなと想像する（私はtoB中心のプロダクトを立ち上げたことはないので想像）。
一方、あくまで「0->1」の新規事業や、ブレイクスルーを狙う新機能開発についての話で、1->10フェーズやスケール期は多くの点が別である。
（逆にいえば、「事業」でなくても、「機能」単位でも0->1要素を含む場合は大いに当てはまる)
バグ≠ダメ の罠
（反応の「強烈さ」への集中）
新規事業や新機能の最初期はたいていはボロボロだ。バグも多い。Linkedinの創業者リード・ホフマンは「リリースした最初のバージョンが恥ずかしくなかったらそれは遅すぎるということだ」と述べている。
バグ・障害は良くない。そんなことは自明なのだが、「バグが多いからまだ何とも言えない」はダウトだ。
本当に刺さっているモノは、一部のユーザーが「小さな障害を越えて熱狂的に使うようなもの」だからだ。
例えばミラティブの初期バージョンのクオリティは褒められたものではなかった。配信をはじめたあと、しょっちゅうアプリが落ちる。それで離脱した人もいただろう。
ただ、何度アプリが落ちても一部のユーザーは配信しなおしてきてくれた。世の中に他に代替（スマホ1台で画面配信）できるものがなく、その人たちにとっては強烈なソリューションだった。
拡大フェーズ、マーケをするフェーズではバグがないことは重要・前提条件になる。ただ、最初期においては、「そもそもPMFする素養があるものか（スタートラインに乗っているか）」は、バグが残るモノでも見分けられうる。
「恥ずかしくてもリリースする価値」はここにある。反応の有無ではなく、反応の強烈さの有無、に全集中する。
マーケティングの罠
（歯欠けでも回る熱への集中）
「招待機能がつけば広がるはずです」「ネットワーク効果がまだないからハマっていないんです」「まだテストで絞ってるのでユーザー数が足りないんです」等もよく聞く「初期の言い訳」だが、これもダウトだ。
例えば、ミラティブの最初のバージョンはAndroidアプリ「しか」なかった。配信機能に至っては、そのAndroidユーザーのさらに15％に当たる当時の最新OS(5.0)でしか使うことができなかった。
実態としてはiOSアプリの審査が通らなくて私は青ざめていた。だって、「配信してもiOSの友達が見れないって致命的じゃないですか…」と。
が、当時師匠だった元mixi原田さんは「最初期にはあんまり関係ないからいいんじゃないですか」と言っていてホントかよと思った。結論としてはホントだった。iOSアプリは半年以上あとまで出せなかったが、PMFするかどうかにはまったく関係がなかった。（むしろ、その期間にAndroidのPDCAだけに集中できて良かった）
ごく一部のユーザーからでも、熱狂的な反応は観測できる。観測できたら、それがどういうユーザーで、何に刺さっているのかを観察して、それを少しずつ広げていく。
重要なのは、
・どんなクラスタが（誰が）熱源になるのか
・何が刺さっているのか、どこで「WOW」になるのか（熱量のトリガー）
・熱量を生むのに必要十分な環境・ネットワークの最小セット（1人でいいのか、2人いるのか、10人いるのか、その関係性、等々）
を見極めることだ。
見極めた上で、深め方→広げ方（まずは広げ方というよりも、「にじみ出し方」が近い） を考える。深めるのが先だ。
これらが見極められたPMは、ターゲットはどういう顧客クラスタなのか、クリアに答えられる。そのクラスタ以外のユーザーの行動はノイズであり、いっさい気にしなくてよい。見極められていないPMは、薄く広くウケそうな施策を繰り返す。そして、関係ないユーザーのKPI変動に踊らされることとなる。
「マーケティングすることで（ユーザーが増えることで・ネットワーク効果が効くことで・ブランドができることで）さらにハマる」ことはある。
ただ、「マーケティングしないと誰もハマらない」「マーケティングしたからユーザーがハマりはじめる」はほぼない。あってもそれは、ハマったように見えるだけの一時的なドーピングなことが多い。
初期は、熱量の発火源に全集中する。
KPIの罠
（熱量を図るメトリクスへの集中）
全体KPIや機能タッチ者全体の数値の変動を見るのは、俯瞰把握としては良いが、初期のメトリクスとしては適切でないことが多い。
見るべきは、「ハマったユーザーの動向（リテンションや利用時間の推移）」だと思っている。
ミラティブ初期に起こったことは、日本だとシェア3割のAndroidユーザー、その中でもAndroid最新OSである15％（＝対全体4.5％）のユーザー、さらにそのうちの配信したい人、という、わずかなユーザーの熱狂だった。この人たちが超高リターンレート（RR）を叩きだし、残りのクラスタのRRは正直ボロボロだった。
が、ハマったクラスタ（「2日つづけて使った人」など）に絞って、「コホート分析」で、「はじめた週からの時間軸」を横軸に、「1人あたり配信時間」を縦軸に取ると、ある改善以降は、RRが100％近いのはもちろんのこと、配信時間が毎週伸び続けていた。これは「どんどんハマるサービス」の典型的な初期動態だ。
結果、ターゲット外の薄いユーザーのRRはその後も長らく低いままだったが、サービスはノンプロモーションでも伸び続けた。
「ハマりつづけているか」の指標はサービスや機能によって異なる。SaaSならChurn RateやNegative Churnなのだろうし、SNSなら滞在時間の伸びなどが一般的だろう。（ただ、コホートの有効性は概して高いように思う）
全体の俯瞰数値には出てきづらい適切な「熱量指標の分解」ができるか、その数値にバイアスなく向き合えるか、が肝要だ。
初期は、熱量あるユーザーに絞っての反応とKPIに全集中する。特に継続性に。
全集中での「観察」
「顧客と話す」はYコンビネーターでも最大奨励される初期の重要行動だが、「話す」とバイアスも多い。
ユーザーインタビューの誤謬はよく知られているとおりで、顧客は本当に欲しいものは知らないし、誰でも「触ってみてどうでしたか？」と聞かれるとバイアスたっぷりに「良く」「盛って」話してくれる。（リリース後の「良いインタビュー」例は↓の最下段など参照）
が、リテンションや利用時間は嘘をつかない。ましてや、継続的に、より長く使っているかはなおさらだ。
つまり、顧客を多方面から「観察」することが「顧客と話す」の上位概念だ。観察の手段として、ログ分析やインタビューやユーザーテストがある。
ミラティブ最初期では、ハマっているユーザーは数にして数十人とかだったのではないかと思う。数十人の頃のメリットは、「ひとりひとり全員を細かく観察できる」ということだ。
観察の中で、ふとした時に出てくる使いにくさへの不満を拾うのも重要だが、「勝手に手間をかけてやっていること」が見つかると大チャンスだ。
例えば当社でいうと、「配信タイトルにゲーム名を必ず入れる」「Skypeを別途準備して音声通話をつなぐ」「メモアプリを起動して注意事項を画面に映しておく」などを初期からユーザーが勝手にやっていた。
こうした「勝手にやっていること」を、簡単に（ex: 数タップで）できるように「機能化」すると熱狂的な反応が返ってくる。（ミラティブの「マイアプリ」「コラボ通話」「配信メモ」などの機能はこうした観察を経た結果）
この繰り返しで、熱を深め、じわじわと周辺領域に滲み出していく先に、十分な機能を備えた、拡大やマーケ（あえて言うと「希釈」）にも耐えうる「製品」ができあがる。
行動は嘘をつかない。まずは全集中して、観察から学ぶ。
おわりに
繰り返すが、スケールさせるフェーズでは、これらとはまったく異なる考え方も重要、と思っている。そちらもそちらで、とても面白い。つまり、プロダクト開発は、とても面白い。
（まさに、恥ずかしいものを出して一点集中しろと言っているリーン志向のリード・ホフマンが、「ブリッツスケーリング」という本を出していることに顕著だ。他、熱量を取れるアイデアと、それをどうスケールアップさせていくか、を初期から両立する動きは例えば「顧客起点マーケティング」等が参考になる。当社もここは終わりなき課題フェーズだ。）
ただ、取り組むと決めて世に出したモノの0->1の最初期は、熱量に全集中だ。がんばれ炭治郎。
---
ミラティブ社では採用強化中です。
まだまだ新機能や新しい動きのリリースがどんどんあり、毎週1回以上のリリースを続けながら成長を続けています。
0->1、スケール、どちらの要素も開発領域によって存在していて、それぞれ各PMやエンジニアが裁量を持って個別チームでどんどん開発を進めているので、腕に覚えのあるモノづくり屋には最高に面白い時期だと思っています。そして、ユーザーの濃い熱量に開発が追いつかず、とにかくとても困っています。
どっぷりプロダクトに向き合いたいPM・エンジニア・デザイナー・分析の方に助けてほしいのです。興味ある方、ぜひお気軽に声をかけてください！！(現職が、俯瞰の全体KPI重視ばかりで違和感がある方など、ぜひに！！)
年内、noteの頻度をあげてます。よかったらフォローやハート、シェアしていってください！
＊Special Thanks: このあたりの話は、だいたいが元mixi副社長・現DeNA常務執行役員の原田さんに生々しく教わったことです。謝辞を添えてnoteを終えておきます。
この記事が気に入ったらサポートをしてみませんか？