グロースハック・改善のメモ帳

Growth Hackやサイト改善、集客、リテンション、収益化、ディレクション、プロダクトマネジメントなどなどを、スタートアップの何でも屋が発信します。

グロースハッカーの参考資料-Growth編

グロースハック 修行

この記事は、梶谷さんのツイートをもとに書き起こしています。

前回はUX編をまとめたので、今日はGrowth編！

Growth理論

マーケティング基礎知識

グロースハッカーの参考資料-UX編

修行 グロースハック

つい昨日なんですが、「いちばんやさしいグロースハックの教本」の著者、梶谷さんがツイートをしていました。

・・・・・！！！！

ディレクター募集、のところはまぁ置いといて(ちょっと行きたかった)、
画像、神では？！プロ以上のグロースハッカーが推すグロースハッカーの基礎のリストなんてすばらしすぎます😂
とりあえずここに書いてある本をマスターしたいので、文字に起こしました。

超たくさんあるので、この記事はUXデザイン編です。 ※リンクがついていないものは、みつかりませんでした・・・

UXデザイン

サービスデザインプロセス、UX概論

ユーザーオンボーディング

ユーザー調査、ユーザーテスト

UX Toolkit

心理学基礎

デザイン基礎理論

UIデザイン

  • UI GRAPHICS
  • モバイルデザインパターンギャラリー
  • 好きなアプリのUIをトレース
  • ランダムなアプリのお題に対してUIkitを用いながらUIデザイン

アクセス解析の思考法

グロースハック 修行

グロースハッカーとして活躍されている梶谷さんが、グロースハックをやるうえで抑えておきたい書籍やスライドをまとめたツイートをしていたので、その中から気になったスライドを調べてきました。

www.slideshare.net （たぶんこのスライド。）

その中のOGSMシートというのが良かったので、この記事にまとめます

OGSMシートとは

f:id:HotcakeMiix:20190404215232p:plain
OGSMシート
こういうシートです。
左側から記載していき、Object(目的)とGoal(ゴール)を、戦略＞行動＞分析を通じてつなげていくためのシートです。

OGS＋戦術と、Mの認識をあわせる

OGS＋戦術の認識をあわせる

目的、ゴール、戦略、戦術の4つは、改善に関わる全ての人の認識が揃っているべきです。
例えばウェブサイトを改善するとしたら、

  • なんのために改善をして（目的）
  • どんな状態になっていればOKで（ゴール）
  • そのためにどの方向に進み（戦術）
  • 進み方はどうするのか（戦術）

というのをみんな認知しておかないと、こまかいデティールで「おもってたのと違う」ものができてしまいますよね・・・

Mの認識をあわせる

Measurement(評価)は、チームの共通言語になります。
一口に「有料会員への転換率」と言っても、「率」には分母と分子があるわけで、その認識があっていないと正しい評価ができません。
（分母が「継続会員」なのか「ユーザー全体」なのかでも全然ちがいますし）
なので、「この指標の定義はこういう計算式」とうのを定義して、認識を揃えておく必要があります。

戦術、施策ごとにターゲットとゴールを選定する

f:id:HotcakeMiix:20190404222233p:plain
戦術、施策ごとにターゲットとゴールを選定する
目的や戦術は一つでも、そこにたどり着く方法（戦術）は複数あります。
この戦術ごとに、ターゲットユーザーも違えば、期待するゴールも違うわけです。

それをちゃんと踏まえて、施策の全体像を掴みましょう。

まとめ

まだまだ興味深いトピックがたくさんあったのですが、疲れたので（←）きょうはここまで！

エンジニア組織論への招待より、認知バイアスについて。

読書まとめ

各所で話題の本、エンジニア組織論への招待。
色んな人が「この本は絶対読むべき」と言っていたので読み始めました。

まだ全部読み切っていないのですが、読んだ範囲の内容の大枠としては、

  • エンジニアリング（というか仕事全般）は、不確実性を下げてモノを生み出す活動である
  • 不確実性を下げるには、ルールと事象を正しく認知し、正しく演繹して考える必要がある
  • その妨げになるのが、認知バイアス。これを避けると不確実性を下げる精度が高くなる

という内容でした。

認知バイアスの例がたくさんでてくるのですが、どれも「あるある！！」と思うものばかりで、これらをもっと意識できれば自分の意思決定ももっと正確になるだろう・・・とおもったので、本に記載の事項から少し踏み込んで記載します。

バイアスの種類

バイアスの種類には、大きくい下記のものがあります

  • ベーコンの4つのイドラ
  • 認知のゆがみ
  • スプリッティング
  • 一般化のしすぎ
  • すべき思考
  • 選択的注目
  • 結論の飛躍
  • 感情の理由づけ
  • 認知的不協和

それぞれを詳しく解説します。

ベーコンの4つのイドラ

種族のイドラ

種族のイドラは、人間が共通でもつ錯覚や本性に基づく先入観や誤解のことです。
例えば遠くにあるものが小さく見えたり、外気が寒いと水が暖かく感じられたりする感覚のことです。

洞窟のイドラ

洞窟のイドラは、個々の人間それぞれが、それぞれの立場や環境に固執するあまり生まれてしまう先入観のことです。
例えば自分がパクチーを食べてまずかったからパクチーが好きな人なんていない、思ってしまうのは洞窟のイドラにあたります。

市場のイドラ

市場のイドラは、人々が集まる場（市場）において起きるイドラで、言葉の不適切な使用が原因になって生まれる先入観です。
まちがった人の噂話を信じてしまうと発生します。

劇場のイドラ

劇場のイドラは、権威のイドラとも呼ばれ、権威や伝統を無批判に信じてしまうことから生じる先入観です。
例えば丙午の女の子は気性が荒いとか。

認知のゆがみ

認知のゆがみとは誇張的で非合理的な認知方法で、下記の様な内容があります。 もともとはうつ病の人が回復するために必要なポイントを整理したものなので、ネガティブな思考を否定しているものが多いですが、極端にポジティブな考え方も良くないものですよね。 認知のゆがみの例です。

スプリッティング

ALL or NOTHING の思考法です。中間がなく、全か無か的な思考になってしまいます。
施策が大成功するかユーザーから批判を受けるか、みたいな思考ですね。実際にそんな大成功や批判が生じることはほとんどないのですが。

一般化のしすぎ

情報が少ないのに、それだけで広すぎる事象について判断してしまうことです。
例えば、リスティング広告のキーワードに「節約」を入れたらCPAが下がったので、節約に効果がある機能をサービスに追加すればリテンションが上がる！とか。

結論の飛躍

「心の読みすぎ」と「先読みの誤り」の2つのパターンがあります。
心の読みすぎは、相手が悪い反応をするのでは？と、相手に確認もせずに類推して予防線を不必要にはってしまうこと、先読みの誤りは、この先に悪いことがおこるのでは？というのを考えすぎてしまうことです。

すべき思考

他人に対し、〇〇すべきである、と決めつける思考です。

感情の理由づけ

感情で判断してしまっているのにそれに気づかず、論理的に判断しているかのように勘違いしてしまうことです。
例えば、とある施策を実行するのが怖いあまりに、その施策のイケてないところやリスクばかりに目がいってしまうことです。

選択的注目

良い面を見ず、悪い面ばかりに注目してしまうことです。

認知的不協和

自分の感情と行動が一致しないときに、必要以上に攻撃的になってしまったりすることです。
例えば、肺がんになるリスクが高まることがわかっていながらタバコを吸う人は、「そうはいってもたばこにはそんなに害はない」などと考えてストレスを緩和する傾向があります。

まとめ

エンジニアリングや施策実行に関係なく、仕事をするうえでも、プライベートでも、こういう認知の歪みは良い結果をもたらさないですね。。
人は歪んだ認知をしてしまうものなので、それを受け入れたうえで正しい判断をしていきたいものです。

ユーザーモデリングとは？

UX

先日、UXの勉強会に行ってきました。
学んだことを忘れないように記事にしておきます。

ユーザーモデリングとは

ユーザーモデリングは、人間中心設計プロセスの中の利用状況の把握と明示というフェーズで登場します。

言葉にすると、

ユーザー調査で得たユーザーの典型的な基本属性、過去/現在の体験、利用文脈を図表でわかりやすく表現する作業。および、図表化を通じてユーザーの本質的要求を抽出する作業

だそうです。

ユーザーモデリングの用途

ユーザーモデリング主な目的には、下記のようなものがあります。

  • ユーザーについての共通理解を持つ
  • デザインにおける意思決定に用いる
  • ユーザーの本質的課題を発見し企画立案に役立てる

ユーザーについての共通理解を持つ

一緒にプロダクトを作るメンバーだったり、依頼者/発注者などのステークホルダーと共通理解を持つ目的で利用します。
よく、誰かの意見ではなくペルソナだったらどう思うか？というのを判断基準にして意思決定しましょう、というのを聞きますが、それがまさにユーザーについての共通理解を持つ、ということですね。

デザインにおける意思決定に用いる

どちらのデザインが良いか判断する際に、ユーザーモデリングの結果を用いて判断します。

例えば、ユーザーが深夜布団の中で見るコンテンツだったら背景は黒で白抜き文字が良いし、不特定多数の人に画面キャプチャをシェアしたい/してほしいなら、同じ画面上に個人が特定できる情報は掲載しないデザインが良いですよね。
今のは使われる場面での話ですが、例えばカスタマージャーニーマップでユーザーの行動が見えていると、どういうデザインであるべきかが見えてきます。

ユーザーの本質的課題を発見し企画立案に役立てる

これは、複数のユーザーの行動を演繹的に抽象化したり、不足しているタッチポイントを見える化することで実現できます。
一つひとつのインタビュー結果では見えてこないことも、複数の人の共通項が見えれば抽象化が可能です。

まとめ

ユーザーモデリングは、ユーザーインタビューで得た結果をもとにプロダクトの意思決定材料を作る作業といえます。
ここをしっかり抑えておけば、ステークホルダーが同じ目線でプロダクト改善に取り組めるので意思決定がスムーズになります。

グロースハックの手前のフェーズ、PSFとPMF

グロースハック

こんにちは、ひよこです。
つい先日、「このサービスをグロース出来ない？」という話を頂いて、結論、「うーん、難しいです」という返答をしました。
そのときにお話をくれた方にPSFとPMFの話をしたので、ここにもまとめておきます。

グロースハックはPMFしてから実施すべき

プロダクトを成長させる手法としてグロースハックというのがありますが、グロースハックという言葉をつくったSean Ellisさんの定義では、グロースハックはPMF（プロダクト・マーケット・フィット）の後で実施する活動です。

プロダクトをグロースする手前には、おおまかに次のフェーズを踏んでいます。

f:id:HotcakeMiix:20190331214110p:plain
ゼロからグロースハック実施までのフェーズ

それぞれのフェーズを解説

では、それぞれのフェーズを簡単に解説します。

良質なISSUEの発見

ここが本当に大事だと思うのですが、そもそも作るべきプロダクトが解決する課題が良質でなければ、どれだけ素晴らしいプロダクトになってもスケールしません。

ここは半分個人的な意見ですが、良質なISSUEというのは

  • 顕在的/潜在的に誰かが困っている
  • 解決が可能な問題である
  • 解決することで経済的なリターンが得られる

この3つが揃っているISSUEのことです。

ちなみに、良質なISSUEの立て方には「イシューからはじめよ」という本がとても参考になるので、ぜひ読んでみてください。

イシューからはじめよ――知的生産の「シンプルな本質」 安宅和人

PSF(Probrem Solution Fit)

正しいISSUEが定まったら、次はISSUE（PMFでいうところのProbreｍ）に対する、適切な解決策を検討します。
一つの問題には複数の解決策があるので、どの解決方法が最も適切なのか？を探るわけです。

ちょっと有名な話では、"宇宙ではボールペンが使えない"というProbremにたいしてアメリカとロシアがとったSolutionが良い例になります。
宇宙でボールペンが使えないと、文字が書けないので記録やコミュニケーションが難しくなってしまいます。
そこでアメリカは、数百万ドルを投資して、無重力状態でも書けるボールペンを開発したそうです。
一方、ロシアは鉛筆を使いました。

Solution一つで、かけたコストが膨大に変わることは想像がつくと思います（笑）

このたとえ話の場合はコストに大きな差がつきましたが、ユーザー体験に差がついたり、スケールできる規模に差がついたりするのでPSFも慎重に行いたいところです。

PMF (Product Market Fit)

PSFが完了したら、PMFを目指します。
解決すべき課題とその解決策を、適切なマーケットに対して当ててみるわけです。

PMFの明確な基準は打ち立てるのが難しいのですが、PMFを達成したプロダクトは、事後的にPMFを達成したことがなんとなくわかるそうです。
PMFが成功すると、プロダクトがある程度勝手に伸びていくようになります。

↑これがPMFを達成した状態、という意見もあります。田所さんのツイートなので十分参考にしてよいかと。

価値の最大化

PMFを達成したらやっと、グロースの出番です。
正直、PMFを達成していないプロダクトであってもDAUやインストール数などのKPIを伸ばすことは可能といえば可能なのですが、そもそも解決すべきでないISSUEを解消しようとしていたり、その解決策がイケてないと必ずどこかでひずみが生まれます。
そうならないためにも、グロースの手前のフェーズはしっかり時間をかけておこなってください。

某スタートアップでは、PMF達成まで社員は社長一人、あとは外注という布陣で事業を推進し、6ヶ月経ったところでPMF達成と判断、人を一気に雇ってスケールを目指しているそうです。
これくらいの慎重さがあっても全然よいとおもいます。

急がばまわれの精神で、あなたのプロダクトが着実に成功しますように！

LPOを効率よく回す改善サイクル

グロースハック

こんにちは、ひよこです。

先日某社でLP〜決済完了までのCVR改善を依頼いただいいて、久々LPOに取り組むことになりました。
長らくLPOをやっていなかったので、この機会に過去やってうまくいったパターンを整理してみました。 はじめてLPOをする方の参考になれば幸いです。

LPOは準備が9割

LPOと言われると、「常に改善サイクルを回して・・・」「分析・改善案出し・実装・計測を繰り返して・・・」といったLPOの運用面のコツややり方を聞かれることが多い印象ですが、私はLPOは準備が9割だな〜と思います。
よく見る光景として、「数を打ってなんぼ」「とにかくやってみよう」という一見前向きな言葉が、深く考えないことに対する言い訳になっていることがあります。

LPOに限らずですが、最も時間もリソースも無駄になるのは、成果が上がらない施策を実施することです。
1週間かけて企画と実装を行って、1週間計測してたら2週間も進捗がなかったってことですからね😭

なのでしっかり時間をとって考えて、そのための準備も手を抜かずにやりましょう。

LPOのサイクル

この記事の主題は準備ですが、まずはじめに、準備が終わった後の改善サイクルについて記載します。
この改善サイクルの前段として、準備があるとおもってください。 LPOのサイクルは、下記の通り進めます。

f:id:HotcakeMiix:20190329020232p:plain
APDMサイクル（PDCA的な）

このサイクルの細かい説明は別の記事で書くので、この記事では、上記のサイクルを回すための下準備についての記事ですが、これから記載する下準備あっての、改善サイクルがあることを忘れないでください。

APDMサイクルを回すための下準備

今回は、まだないLPを作るところからではなく、すでに一度作成が完了しているLPの改善を想定します。
下準備では、

  • KPIツリーの作成
  • ファネルの作成と数値の確認
  • ヒートマップツールの導入と分析

を行います。

KPIツリーの作成

最終的に向上させたい数字（KGI）を決め、それに紐づくKPIを定義します。
大体の場合、KGIは粗利の最大化になり、その直下のKPIとしてCPAの削減とCV数の向上が来ると思います。
そのさらに下のKPIとしては、LPの構成に応じて

  • LPのUU数
  • フォームの入力数（フォームが長い場合はどの入力枠まで入れたのかも追いたい）
  • 確認画面への遷移数
  • 確認完了数 などが来ると思います。

ファネルの作成と数値の確認

KPIツリーができたら、それをもとにファネルを作成します。
ファネルは、KPIの項目をユーザーがたどるフロー順に並べれば完成です。
また、運用に入ってからちょっと気をつけておきたいこととして、改善案を出す際はファネルに縛られないのが結構大事です。 ユーザーフローが変われば、ファネルは変化します。

例えば、
LP→入力フォーム画面→入力内容確認画面→完了画面
という画面構成だったものが、

入力フォームをLPの下部に記載する構成に変えたら、ユーザーフローは変わりますよね。

LPOの全体像を把握するためにファネルを見るのはとても重要ですが、ファネルにとらわれてしまって"ファネルそのものを変える"という手段を見落とさないように注意してください。

ヒートマップツールの分析と導入

ヒートマップツールとは、例えばMIERUKAやPtengineといったツールです。
ヒートマップツールをつかうことで、

  • ユーザーがどこまでページをスクロールしたか
  • ユーザーが興味を持っているところはどこか
  • ユーザーがよくクリックするのはどこか（ボタン以外をクリックしていないか？） ということがわかるようになります。

LPOの最初の改善は、このヒートマップツールでの発見から改善を始めると非常にスムーズですので、ぜひやってみてください。

まとめ

LPOを開始する前は、急がば回れで、まずは上記の下準備をしっかりやると施策がうまく回りだします。 ヒートマップツールは特におすすめです！最初の2週間は無料で使えるものもあったりするので、ぜひつかってみてください。