nDiki : 『Hacking Growth グロースハック完全読本』を読む会

『Hacking Growth グロースハック完全読本』を読む会

2021年9月8日 (水)

第0回 『Hacking Growth グロースハック完全読本』を読む会 キックオフ

rimage:ASIN:4822255824

知識と共通言語をチームで獲得し事業推進につなげるのを目的に『Hacking Growth グロースハック完全読本』を輪読する勉強会を部内の関係者ですることにした。輪読形式の勉強会エッセンシャル スクラムを読む会ぶり。

今日は参加者で集まってキックオフミーティング。顔合わせと勉強会の趣旨を確認したあと、進め方を打ち合わせた。各回担当者が事前にまとめたサマリーを発表し、事前に読んできている参加者全員で内容について話し合うオーソドックスなスタイルに決定。

初回は来週から。楽しみ。

ちなみに『Hacking Growth グロースハック完全読本』の新品単行本(紙)はいくつか通販サイトを見た限り品切れになっていた。増刷予定はないのかな?

スポンサード リンク
[ 9月8日全て ]

2021年9月17日 (金)

第1回 『Hacking Growth グロースハック完全読本』を読む会 はじめに

rimage:ASIN:4822255824

先週キックオフミーティングをした『Hacking Growth グロースハック完全読本』を読む会の輪読がいよいよ今日からスタート。

第1回は「はじめに」でウォーミングアップといったところである。今回は「はじめに」の「戦略書の決定版」節以降の部分を自分が担当した。

一番印象に残ったのは「部門横断」「特効を探すプロセスではない」だ。

※追記あり

高速かつ部門横断的な実験を通じて急成長を促すアプローチ

前半の「グロースハックは誰にでも役立つ」節ではまずグロースハック

高速かつ部門横断的な実験を通じて急成長を促すアプローチ、つまり私がのちに「グロースハック」と名付けた手法だ。

と短く表現していた。「高速」「部門横断」「実験」「急成長を促す」にグロースハックが意味することころが含まれている。「部門横断」がしっかり入っていることが肝だと感じた。グロースチーム内でのプロセスについて考えがちだけれどチーム内で閉じた活動だけでは十分な成果につながらないのだな。

※追記あり

フィールド・オブ・ドリームスの誤謬

優れたプロダクトを開発すればユーザーのほうから集まってくると誤解すること

を「フィールド・オブ・ドリームスの誤謬」 と書いているところで「嗚呼……」となった。プロダクト開発をしているとついプロダクトの方ばかり向いてしまうことがある。注意せねば。

週2回

新たな実験を始めたら、結果の良しあしを週に2回見て、そのたびに次はどこを変えて実験するかを決める「ハイテンポ検証法」で、実験の効果をほぼリアルタイムで評価していった。

については、週2回はさすがに速いなと驚いた。どのような仮説検証なら週に2回検証できるのだろうか。気になる。

小さな勝利を積み重ねてグロースする

グロースハックのへの迷信を捨てる」節ではまず始めに

第一に、グロースハックは「特効」を探すプロセスではないということだ。(中略)こうした必殺のアイデアグロースハックの理想ではあるものの、実際には小さい勝利を積み重ねてグロースすることがほとんどだ。預金が複利で増えていくように、地道な歩みが飛躍につながる。

とビッグアイデアを求めるものではないと述べている。小さなアイデアを過小評価したり馬鹿にしたりしてはいけないということだよね。バリューがあり早く終わるものから高速にすすめていくという優先順位判断をしていくことを常に意識したい。

2021年9月24日 追記

本書では cross-functional を部門横断的/組織横断的/組織横断型と訳しているようだ。本書で組織横断・部門横断と書かれている場所は、「部門を超えて」というニュアンスもありつつ機能横断の意味で読んだ方が良いのかもしれない(特にチームの文脈では)。

[ 9月17日全て ]

2021年10月1日 (金)

第2回 『Hacking Growth グロースハック完全読本』を読む会 第1章 グロースチームを結成する

rimage:ASIN:4822255824

『Hacking Growth グロースハック完全読本』を読む会の第2回目。今日からいよいよ第1章に入る。第1章は「グロースチームを結成する」だ。

グロースチームに必要なメンバ構成、チームの規模と業務範囲

グロースチームに必要な役割として以下が挙げられている。スクラムチームと同様に機能横断型チームであることがグロースチームには求められる。

チームの規模によって1人が複数の役割を兼任したり、複数の人が1つの役割を担当したりする。

チームのマネジメントはグロースリードが行う。

グロースリードはマネジャー、プロダクトオーナー(プロダクトの最終決定権と責任を持つ役割)、データサイエンティストをあわせたような役割を担う。

本書ではプロダクトマネージャー

一般的には、プロダクトマネジャーはプロダクトのさまざまな要素を形にする過程を監督する。

と説明している。グロースサイクルでプロダクトの新機能を実験として選定した場合に、グロースリードはメンバの中のプロダクトマネージャーを実験のオーナとして任命すると後の章である。

ここで言うプロダクトマネージャーはグロースチーム内での機能開発をマネジメントするのか、それとも別チームを率いているプロダクトマネージャーで、そちらで実験のための機能開発をマネジメントするのか。組織体系の節にあるチームだと前者なのかな。

このあたりは企業によって組織構造や役割名の定義が違うので、そういった典型的な型があるよねぐらいで読んだ方が良いだろう。

業務プロセス

詳しくは4章。

チーム内での役割分担

「専門分野に応じた業務を担う」とありメンバの専門性に頼っているイメージ。スクラムのように銃士の姿勢まではここでは求めていないようだ。銃士の姿勢であることに越したことはない。

まとめ

分析とプロダクト開発とマーケティングができる機能横断型のグロースチームを結成せよ。

[ 10月1日全て ]

2021年10月8日 (金)

第3回 『Hacking Growth グロースハック完全読本』を読む会 第2章 プロダクトの渇望度を測る (前半)

rimage:ASIN:4822255824

『Hacking Growth グロースハック完全読本』を読む会の第3回目。第2章は「プロダクトの渇望度を測る」。コアバリューが確立してからグロースハックすべきで、コアバリューの発見/確率までの方法が本章で解説されている。

前回の輪読会までと同じく章を前半・後半に担当分けしたんだけれど、今回は前半だけで時間を使い切ってしまった。第2章後半は次回に繰り越し。

[ 10月8日全て ]

2021年10月15日 (金)

第4回 『Hacking Growth グロースハック完全読本』を読む会 第2章 プロダクトの渇望度を測る (後半)

rimage:ASIN:4822255824

『Hacking Growth グロースハック完全読本』を読む会の第4回目。前回 第2章の前半で時間を使い切ってしまったので今回は第2章の後半だ。以下2回分のまとめ。

第2章は「プロダクトの渇望度を測る」。

プロダクトのコアバリューが最重要

グロースするには大前提として顧客に愛されるプロダクトでなくてはならない。価値あるプロダクトであり、顧客がその価値を感じた瞬間「アハ体験(本書ではアハ・モーメントとも)」に愛が生まれる。

プロダクトのコアバリューとユーザーのアハ体験を見つけるのは容易ではないが、プロダクトが「マストハブ」であると思われているかどうかは、著者であるショーン・エリスが開発したユーザーアンケート調査「マストハブ・サーベイ」と顧客維持率測定によって判別できるという。

プロダクトのコアバリューとアハ体験が発見できておりマストハブなプロダクトであれば、グロース実験へ進むことができる。

そうでなければ追加のユーザー調査(顧客インタビュー・実施調査・試作品・文言変更実験・プロダクト変更実験・ユーザーデータ分析)を通して、まずプロダクトのコアバリューとアハ体験を探すことになる。

プロダクトのコアバリューが無いままにバイラル性を作り込んで一時的にグロースすることができても結果失速してしまうであろう。

たった一人の分析から事業は成長する 実践 顧客起点マーケティング』でも良いプロダクトでなければプロモーションを工夫しても限界があると述べられている。

ただし SNS ではそう単純な話ではない。

プラットフォームの利用者がコアバリューであるソーシャルネットワークサービスなどは例外

と括弧書きで小さく書かれているのを見落とさなかった。 そうそう、 SNS にとっては多くのユーザーがいる事自体が大きな価値なんだよね。

ユーザー調査

すでにプロダクトがあり顧客があるならば、プロダクトのコアバリューとアハ体験を発見するためにプロダクト上で実験したりユーザデータ分析したりできる。

ユーザーデータ分析については「顧客体験のあらゆる側面からデータを集めて細かく分析」するために「適切な追跡機能を付加」し「ユーザー行動の緻密な全体像に仕上げ」て、ロイヤルユーザーに特徴的な行動を見つけるとある。分析を通じた予想外の発見のためにもデータ収集と実験が必要だという。

プロダクトが小さい初期段階ではデータ収集処理を網羅的に仕込んでいきやすそうだが、有限の資金と時間の中で進めていかなければならないだろうから、ほとんどの場合取捨選択が必要だろう。

「予想外の発見」とは結果である。予想できないからと闇雲にデータを集め眺めていてはいくら時間があっても足りない。やはり仮説思考で進めるべきだ。

[ 10月15日全て ]

About Me

Naney Naney

Naney (なにい)です。株式会社ミクシィで SNS 事業の部長をしています。

About nDiki

nDiki1999年1月に始めたコンピュータ日誌を前身とする NaneyWeb 日記(兼パーソナルナレッジベース)です。

#nNote タグがついている記事は他の記事に比べて、より断片的・未整理・不完全なちょっとしたノートです。まだ結論に至っていない考えなども含まれます。頻繁/大幅に更新したり削除したりすることがあります。

※本サイトの内容は個人的見解であり所属組織とは関係ありません。

Other Notes

ナレッジベースアプリケーション Obsidian で書いているノートの一部を notes.naney.org で 公開しています。

最近検索されている記事

月別インデックス
Process Time: 0.055751s / load averages: 0.24, 0.67, 0.51
nDiki by WATANABE Yoshimasa (Naney)
Powered by DiKicker