グロースをするチームへの基本的な問いを言語化してみる

基本的な問い

① KPIモデルはどのようになっていますか？企画者+リーダーはそれを更で書けますか？（メンバー全員それを更で書けますか？）
③ 現時点で考えうることは机の上に広げられてますか？
② それぞれの検証はどのKPIをどの程度あげるための施策/施策を導き出すための検証ですか？それは3ヶ月の売上、1年の売上で見たときざっくりどのくらいのインパクトがあるものですか（目指すべき大きさの可能性がある打ち手ということを確認できてますか）

そのときに困るだろうことと解決の指針

規模小さくて正直効果が見えないもの

① それって本当に大事？計測もできない大きさだよ？を問い直してみる
② メンテンスと割り切って工数を割くパーセンテージを決めておきその中で月次xx個とかでやる
③ 同じ指標に効くものをたくさんまとめてやってこうかの良し悪しを1ヶ月単位で見る
④ 本質的にも必ず前進するから本当は大胆にやるべきことが小さく縮こまってないか問い直す。開発サイドも省力化のやりすぎを疑い、明確な変化をもたらすソリッドなMVPの提案ができないか問い直す

計測ができないもの

① それって本当に大事？計測もできてないものだよ？を問い直してみる
② 大事なのに計測してなかった過去を反省して計測しに行く
③ メンテンスと割り切って工数を割くパーセンテージを決めておきその中で月次xx個とかでやる

施策としてやるとなったときにMVPで毎回問い直したほうがいいこと

小さくしすぎてないか

• メールで訴求、文言で訴求、ちょっとした機能の作成で試してみるとしてしまっていないか

• 数値の変化が見えなくて、結局良かったのか悪かったのか両方わからず検証にならない

=> 検証時に見る数字と目標を出したときに、仮にそうなったときに評価できるかを検算してみるとよい。ブレに飲み込まれる数字感にしかなっていない。間違ってたらモニタリングが成否を出してくれるから大胆にやろう

大きくしすぎてないか

• 価値提供に関係ないカスタマイズや管理機能をつけて工数を使ってしまい検証に時間=お金をかけすぎてしまう

• そういうプランニングにして工数大きすぎて費用対効果が少ないから実行しないという結論をだして検証自体ができない

=> サービス規模次第で1ヶ月とかで区切りそれ以上になりそうな場合はもっとソリッドにする。削ぎ落とせ、ただし効果出たなら後始末（必要だった機能の追加）はやろう

後始末忘れてないか

• 数値が落ちたときに

  • もとに戻す （基本動作、これやってなかったら失格）

• 効果が出なかったら

  • 残すものなのか（個別・全体両方に対してあるべき前進）

  • もとに戻す （あるべき前進ではないから効果ないなら撤退）

• 効果が出たときに

  • 本当に残すものなのか （施策に集中していると忘れがちだが大事。全体に対してあるべきではないから個別との葛藤 => 全体数字モニタリングで線引き先に決めておく）

  • 削ぎ落としすぎたものはないか（MVPで作ったので恒久化する場合本来は品質として満たすべきものは完成まで）

最後に

まだグロースのドライバーが見つかっていないが仮説は色々あって試し続ける形式のチームでやっていくときの基本指針を書き下してみています。
会社やプロダクト、チームによって違うとか、「ユーザーへの価値が…」とか社内で当たり前のように考えられているところは省略しているので、一つの指針の例として