本稿は、4月23日に東京で開催された Microsoft Innovation Day の取材の一部である。 「ソフトウェアによるイノベーション」をキーワードに、革新的なアイデアをカタチにしたソフトウェア、サービスを表彰するマイクロソフトのアワードプログラム「Microsoft Innovation Award」。これまでに、導電性インクで電子回路をプリントできる AgIC、手術室の画像閲覧操作を…
シリコンバレーで急成長中のスタートアップの多くは “Growth team” というものを持っているらしい。それでは、「Growth team とはそもそも何をする人たちなのか」「どう組織すればいいのか」「何から始めればいいのか」。
本稿は、これらの一見初歩的ながら一筋縄ではいかない問いかけに、出来る限り一般化して回答することに挑戦します。Growth team 未経験の方々に対しては、まず Growth team を組織していく大まかなイメージを掴んで頂きつつ、具体的なアクションも把握できる「入門編」のような位置づけになることを願って。
既に Growth team を運営されている方々にとっては、シリコンバレーの事例に触れてヒントを得られる「補助線」となることを願いながら。紙面の許す限り心を込めて書いてみます。
まず、Growth team とは必ずしも Growth Hack を行う集団のことではない。より大きな問題意識に基づいた組織論なんだ。既存の機能別縦割りの組織体系では、スタートアップの成長指標を伸ばすのに決して最適な形とは呼べない。これが解くべき問いだ。
この Graham の言葉から紐解くに、Growth team とは「成長指標を最大化させるために最適化された組織体系」と定義できそうです。では、この Growth team が解こうとしている「問い」をもう少し深くみていきましょう。こちらの図は、大企業によくある機能別にMECEな組織形態を示しています。
しかし、このように機能別に組織を構成することが、必ずしも成長指標にとって最適とは限りません。例えばあるEコマースのスタートアップが Dave McClure の提唱する AARRR のフレームワークをそのまま用いて指標を置き、プロダクトの成長を定義していたとします。 (なお、AARRR をそのまま用いることは少ないですが、多くのスタートアップが AARRR をベースに自分たちなりのユーザーファネルを定義して指標化していることが多いです)
この際、通常の Marketing team であれば “Acquisition” のみを担当したり、Product team はやんわりと全ファネルに関わっていたりと、どこかに偏りやモレ、手薄になってしまう箇所が現れてしまいます。先ほどの図で例えると、このようにカバーし切れていない溝が空いてしまっているイメージです。
本当は全てのモデルに関して解説を添えたいところなのですが、文量の都合上なかなか困難なので、詳細は上記リンクに譲らせてください。ここでは簡単にそれぞれの型に触れるに留めます。
Sean Ellis model はこの中で恐らく一番分かりやすいプロセスです。
エンジニア主導の Growth team に適していて、上記リンクをご覧いただければ英語でもかなりイメージが掴めるかと思います。Brian Balfour model は、Sean Ellis model をより細かなプロセスまで踏み込んだモデルです。Backlog(検証アイデア集)や Playbook(成功アイデアを汎用化)の管理の仕方が参考になります。
と、元 Evernote Growth Head の Naomi Ionita は述べます。一方で Pinterest の Lead Product Manager である Casey Winters は、この Independent モデルに次のように警鐘を鳴らします。
「このモデルは往々にして Product team との不和を招く。Pinterest も当初は Independent モデルを採用していた。そして実際にものすごいスピードで成長を実現できた。例えばこのモデル移行後、サインナップフローを集中的に改善した結果、Acquisition と Activation の指標を大幅に増やすことができた。しかし Product team からユーザーエクスペリエンスを犠牲にしすぎていると声が上がり、結局 Functional モデルに戻したんだ。」
ではこのような Growth team と Product team 間の信頼関係を維持するにはどうしたらいいのでしょうか。この点に関して Naomi は彼女自身の経験を次のように述べます。
「Growth 施策が Product team の活動に影響を与えてしまうのは不可避です。しかしその一方で Growth team と Product team の棲み分けを出来る限り明確にし、Growth Head と Product Head が綿密にコミュニケーションを取り合うことで、この不和を限りなくゼロに近づけることも十分に可能です。結局のところ、この問題の原因は Independent モデルそのものにあるのではなく、人間関係のマネジメント能力に依るところが大きいのです。」
”Growth Hack” の生みの親で元 Dropbox Growth Head の Sean Ellis は次のように述べます。
「Growth team の成否を分けるのは、仮説検証プロセスそのものだけではなくコミュニケーションに依るところも大きいのかもしれない。私の今の会社は Functional モデルだが、それでも各施策のユーザー体験へのリスクを検討し、実装後も徹底して影響度を測っている。そしてそのデータを全員にシェアし、透明性を確立するよう努めている。Growth meeting で各部門の Head を参加させているのもこの透明性確立のためだ。」
Sean の述べるように、Functional モデルであったとしてもこうした地道なコミュニケーションの積み重ねが、組織内の透明性を高め、Growth とユーザー体験のバランス維持につながるのでしょう。
ここまでお付き合いいただきありがとうございました。最後に「では結局何をすればいいの?」にお答えするため、Growth team をつくるにあたってのチェックリストを作成しました。参考になれば幸いです。
1. そもそも本当に Growth team は必要か?
Growth team を持たないスタートアップもたくさん存在する
そもそも本当に Growth team が必要なのか?短期的な成長を求める明確な理由はあるか
2. 始める準備はできているか?
プロダクトの成長を定義できているか
成長に寄与する因数を User Funnel の形に整理し指標化できているか (例: “AARRR”)
Product Market Fit がつかめているか
3. Hustle ステージのアクション
Growth team 責任者 (≒Growth PM) を置く (初期においては大抵 CEO が兼務)
チームに合った Growth Process を確立させる
4. Scale ステージのアクション
自分の組織に合った Growth team モデルを選択、構築する(例: 急速な成長を追い求めるのであれば Independent モデル、UX とのバランスを取るのであれば Functional モデル)
どのモデルを選択するにせよ、組織内の透明性を高めることが成否を分ける
それぞれのモデルを起点として、自社にとって最適な組織体系をデザインしていく
以上、「Growth team とはそもそも何をする人たちなのか」「どう組織すればいいのか」「何から始めればいいのか」という一般化の難しい問いかけに対して、出来る限り多くの方にご理解いただける回答となるよう努めました。文量の都合上どうしても具体論の足りない箇所があったり、僕より豊かな経験をお持ちの方の中には、ご自身のご意見と反する箇所もあったかと思います。