カスタマーファネル
年末年始に、タベリーというプロダクトをする過程をブログに記載したり、CAREER HACKさんに取材していただいたりした。 ※記事はこちら
ところが、プロダクトは「発明前」より、その価値を測定・分析し、磨き込む「発明後」の期間のほうがずっと長い。
プロダクトのタイプごとに、いわゆる「グロースのための方法論」はMediumなどを少し漁ると多くの事例と出会うことができる。たとえばGreylock Partnersや、著名なProduct Managerが公開している記事は秀逸なものが多い。
他方で、
- 「他国で成功したプロダクトをローカライズするプロダクト」や、
- 「プロダクト自体ではなくそこに乗るコンテンツに差別化要因があるプロダクト」ではなく、 「新しい発明」を目指す場合、汎用化された事例を元に意思決定するのは難しいと感じる。
タベリーは「意思決定の新しいフォーマット」のチャレンジでもあるため、どういった切り口で分析をしていくかは試行錯誤している。振り返りも兼ね、その過程をフェーズごとにまとめてみた。
プロダクト前
課題とマーケットを狙い定めて、プロダクト「発明」を志す僕らとしては、
- 「解くべきイシューは何か」
- 「発明すべきは何か？」 といった問に自分なりの答えをみつけることが「初期の仕事のすべて」になる。
この問いに対して僕は
- 「人の課題を実際に解けるまでプロトタイプを創り続ける」ことと
- 「実験を繰り返すこと」 が自分にはフィットしているなぁと、タベリーの開発を通じて改めて思い直したりした。
ただ、いろんな実験を通じて課題の広さ、深さ、プロダクトの精度などを検証するも、それは結局「ラボ・サイズ」であり、「実際に社会サイズで受け入れられるかはわからない」事が本当に多い。
実のところ、プロダクトを世に出すことでしか真実に近づくことはできないのだと思う。
初期のポジショニング
「C向けのプロダクトは大企業にすぐ模倣されたり、お金で勝負になった時に厳しいから出来る限りステルスで成長させるべき」 といったスタンスはよく推奨される。というか僕自身もこのスタンスをとる予定だったが、クローズドβテストでは十分な実験ができないフラストレーションがあった。ユーザーの流量が不足すると、実験から得られたデータへの信頼性が低い。
「これは本当にスケールするのか？」というイシューに、クローズドβテストから答えを見出すのは無理があった。
この背景もあり、株主である堀井さんや赤坂さんとの対話を重ねる中で、結果的にタベリーは早々に公開し、プレスリリースも行うことにした。
「ユーザーから愛されるための鍵はなにかという暗黙知に最速で達することでしかProduct Market Fit（PMF）はなし得ない。」
このシンプルな結論から、プロダクトやチームのスタンスを公にすることでユーザーを集め、採用をすすめ、実験の速度を早めることを優先した。明確なポジションをとることにしたわけだ。
「早期にポジションを取る」という意思決定を「正しいもの」にしていくのはこれからのプロセス次第だが、「難しいポジションを取るほど、多くを集める」ということを実感しつつもある。
リリースしてから
早期にポジションをとったこともあり、プロダクトのリリース後・PR後は大きな反響があった。
ユーザー（に見える人）からの「こうしてほしい」というフィードバック - 「10Xで仕事がしたい、興味があります」 - 資金提供オファー - 事業提携オファー - 講演しませんか - マーケしませんか - PRしませんか… etc こういった「外からのフィードバック」に加えて、
- 「タベリーが提供したかった体験に対して、初期リリースでは断念したもの」
- 「プロダクトの数字が指し示す改善点」 の2つのリストを加え、「いまリソースを割くべきは何か」について意思決定することが大きな仕事となる。
最優先すべきは「ユーザーの習慣に溶け込む = 使われるプロダクトに近づけること」であるのはリリース直後も現在も変わらないのだが、
- 「習慣化」に必要な要素を明確にしきれていなかったこと
- プロダクト構想時に描いた体験との差分を埋めたいという「意志の慣性」
- タスク過多… orz などからプロダクト開発のサイクル単位では「優先度ジャッジをミスったな」と思うことが何度かあった。
それでもサイクル自体を短く保つ（現在は1週間で1リリース）ことでフィードバックが得られ、細かなピボットが常にできているのは「チームを小さく保つ」ことによるメリットだなと感じる。
試行錯誤の帰結として、タベリーはいま「day 0–7ファネル」の改善に全てを投下している。つまり、プロダクトを訪れたユーザーが、1週間の間に価値を理解し、「ここは自分の居場所だ」と感じてもらうまでのステップを築くことだ。
通常アプリではRetention Rate（RR）の測定が共通言語のようになっている。一方で、RRは「安定的に最低数百ボリュームの新規ユーザー/dayがないと統計が取りづらい」「結果指標であるため、アクションを導きにくい」という側面がある。
コア価値の磨き込みの段階では、「その価値に触れ、満足するユーザーを100%に近づけること」が最重要であり、その上で最も使い勝手の良いフレームワークはファネルではないかと考えている。
スピードの本質
「売上の立ち上がり < スティッキーなプロダクトの発明」 を優先するスタートアップとしては、時間期限が明確な中で目的を達成していく必要がある。スピードが全てと言っても過言ではない。では僕らにとって、今のスピードの本質は何か。
それは「大きな機会だけにトライすること」だと考えている。ホームラン・スイングしかしない。
このためには常時「機会の探索と評価 = Issue Mining」が必須となる。この事はアタマに徹底的に叩き込んだつもりでいたのだが、タベリーのリリース後のジャッジミスの経験から、様々なノイズが「徹底」を妨げるのだな、と改めて反省した。
こういった反省をチームに蓄積しつつ、「ユーザーのすべての行動を描写する」という原点に立ち返り、再度掘るべき穴の探索、ファクトの収集にリソースを割いている。
ファネルとの向き合い方
実際に現在ファネルとどうやって向き合っているか。大きく3つのプロセスに分けている。
- （探索）理想的なユースケースに対して、離脱のもっとも大きい区間A→Bを把握する
- （探索）A→Bの間にユーザーが行う細かな行動プロセスもファネルにし、離脱要因a→bを特定する
- （観察）2に対してユーザーの動きを観察し、なぜそこで離脱したのか？を突き詰める
1と2は「Where」、3は「Why」を理解するプロセスとも言える。特に1, 2はSQLをサッと叩いてダッシュボードをつくって定点観測したり、気になる細かいログを都度確認したりしているが、3をある程度の規模で実施するにはすこしパワーが要る。
タベリーでは3の行動観察にReproを実弾投入しており、かなり活用させていただいている。
実弾としてのRepro
Reproは2015年ごろ、ECのプロダクトを手がけてきたときに重宝していたSaaSの分析ツールだ。
かつて愛用していたときから3年ほど経ち、タベリーリリース後に久しぶりに触ってみると大幅な進化を遂げていた。特にIn App Marketingの領域では「コーディング不要でマーケターが施策を実施できる」という点にフォーカスし、市場を急速拡大している様子だった。
Repro内に送ったイベントの成否に応じて自在にセグメントを作成し、リッチメディアを添付したPush通知が管理画面から実施可能。
メッセージの作成例。こちらもセグメントやトリガーを自在に設定し、インタースティシャルからポップアップまでユーザーへの訴求に合わせて作り変えることができる
メッセージの作成例。こちらもセグメントやトリガーを自在に設定し、インタースティシャルからポップアップまでユーザーへの訴求に合わせて作り変えることができる
一定規模の検証を終えたプロダクトでは、こういった通知基盤はより細かなニーズに応えられるよう内製することが常だと思う。
タベリーでもPushツールは内製してしまったので、メッセージのみ利用している状態ではあるが、とりわけ検証初期のプロダクトでほとんど工数をかけずにPushを打ち分けられるReproの仕組みは重宝されるはずだ。
そういったフェーズで利用するプロダクトとしては、少なくともFirebase Notificationsより10Xで使いやすい管理画面を提供している。同じく分析SaaSとして重要されているmixpannelと比較してもかなりとっつきやすく感じる。
他方で、これらのリッチなマーケティング機能より、Reproの真骨頂は「イベントログ以上の解像度でユーザーを正しく理解できる」というところにあると思う。Reproには「Reproにしか解けない強いユースケース」があると感じており、重宝している。
あらゆるプロダクトに通じることだが、人が持つ課題意識と1on1で想起されるプロダクトは本当に強い。僕のなかでReproは「ユーザーはなぜそこに躓いたのかを知りたい」という問に応えてくれるプロダクトである。
献立をつくる、というコアアクションを研ぎ抜く
タベリーは「献立をつくるのがめんどくさい」というペインを解くためのプロダクトであり、コアのアクションはどこまでいっても「献立をつくること」である。
インストール直後の人も、ヘビーユーザーも、迷わず献立をつくることができ、自身の習慣に取り入れてもらえるかどうかが生命線だ。
そのため、直近では「インストール後、day0–7の間に献立をN回作成する」というプロセスを改善するためのファネルと向き合ってきた。そしてコアの価値に向き合うほど、自分たちが磨くべきこと、対処すべき課題の優先度がさらにソリッドになっている。
ポスト・プロダクトの「実験と観察」
Day Oneというブログに、「実験と観察」を重視すると書いた。主にリリース前の開発方針について言及したものだが、この姿勢は今も一切変わっていない。
タベリーはどのように創られたか。また今後どのように創っていくのか。それは「観察と実験」による。これは絶対に変えるつもりがない — 中略 — 僕らは「言っていること」より「していること」に重きを置いた。インタビューやヒアリングより、テストであることが重要だった。人が欲しがるものは、人が言語化できていないもの、だから。人の行動を観察し、その中にある負を見つけるのが発明家の仕事だと感じている。プロダクトが世に出た「ポスト・プロダクト」では観察や実験の方法にも「幅」ができる。データとしてファクトが集まり、ファクトを観察対象に含めることができる。ファクトに合わせて実験をチューニングできる。
プロダクト前には、ひたすらユーザーのもとに足を運んで観察を行っていたのは、それしか「手段」がなかったからとも言える。
リリース後は明確にマインドを切り替えて、より効果的・効率的な実験を繰り返しながら、プロダクトを前に進めることを意識している。
通常、アプリの評価といえば、「DayX Retention Rate(RR)どうなの？」という会話がポピュラーだ。確かに結果指標としてRRはわかりやすいし有効だが、RRは「プロダクトが価値が届けられていない理由」を語ってはくれない。その点で僕らはファネルに向き合うことがより現在の目的に一致していると考えている。
ファネル・ドリブン
Dropboxは8人目のメンバーとして分析エンジニアを雇用し、初期からファネルに対して30%のリソースをアサインしていたと記載されている。ユーザーがプロダクトの価値を学習するためのステップをきめ細やかに最適化する文化が初期からあったのだろう、と推測する
Consistent with this priority, the company hired an analytics engineer as its eighth employee. Inspired by Facebook’s growth team, which was dedicated to user acquisition and engagement, Houston later assigned 30% of engineering resources to optimizing customer acquisition efforts. This team closely tracked metrics across Dropbox’s conversion funnel by cohort.a Metrics included the percent of landing-page visitors who registered as free users; the percent of registrants who still were active free users after X months; and the percent of free users who upgraded to paid subscriptions after Y months. — HBS Dropbox: “It Just Work”
タベリーとDropboxに共通項があるとするなら、コンテンツではなくプロダクトを生み出す企業であり、ファネルドリブンなところではないかな、と感じている。
また、一見競争され尽くしたように見える市場へアプローチする、という意味でも、一つのモデルケースとして勉強になる。
数十社いる競争に2年以上遅れて参入したDropbox。VCにそこを聞かれるとCEOのDrewはこう返していたそう。「じゃあその中で実際あなたが使っているクラウドストレージありますか?」ほとんどのVCはこう答えたという。「一つもない」“熾烈”に見えてもこういう事多いのかもなあ。(HBSのケースより) — Kenichiro Hara | DCM Ventures (@kenichiro_hara) 2018年2月25日
10Xは「社会からイシューを拾い上げ、プロダクトを落とす」というビジョンを合意する組織にしたいと考えている。仮にタベリーがうまく行かなかったとしても、何度でも発明を通じて 大きなマーケットにチャレンジする組織でありたい。