- Web Director
- プログラミングスクール卒歓迎!
- アシスタントディレクター
- Other occupations (36)
- Development
-
Business
- Web Director
- Webディレクター/インターン
- Webメディアづくりのサポート
- ディレクターのアシスタント
- フルリモート/メディアサポート
- 事業開発・事業企画インターン
- メディア事業をお任せします!
- メディア企画インターン
- 事業作りに興味ある人
- Webマーケティング、ライター
- Webマーケティング
- マーケの基礎から知りたい人
- Webライター
- Webメディアディレクター
- Editing / Writing
- IT、教育に興味のあるライター
- フリーランス / ライター
- フリー/ライター・ディレクター
- ライター・ディレクター
- フルリモート/ライター
- フリーランス歓迎
- Webライター、ディレクター
- Webディレクター|インターン
- Webライター|インターン
- Webメディアディレクター候補
- Other
ベンチャー転職してなんでも屋として最初にやることリスト
Photo by Lala Azizli on Unsplash
創業期の会社に転職すると、毎日忙しくて何をやったか忘れてしまうので、メモ。
大学時代に創業4カ月のスタートアップに3年、社会人になって2回スタートアップに転職していて、だいたい成長期に至るくらいまでが3回目なので、毎回必ずやっていること(上司がやっていること)を忘れないようにメモしておきます。やり切れていないこともあるけど、やらなきゃねってことを自戒を込めてメモ。
LTV / 許容CPO / 許容CPAの確認
LTVとCPA(サービスによってはCPO)を出します。
これによって広告投資効果を計算し、出せる予算感などを決めます。
現状行ったすべて施策の洗い出し
僕の場合、最初からいる場合ではないので、今まで会社がやってきた施策をすべて洗い出します。
これは、転職した後に思いついて再度やろうとしたときに、6割くらいは試したことがあるパターンが多いです。
ただ、詳しくヒアリングしていると、イメージしたものと過去にやったもののディティールが違うことがあるので、初めに洗い出しておくとよいです。
各種施策ごとのKPIの理想値と現状とギャップの可視化
過去にマーケ施策を打っている場合、各種施策ごとの理想値と現状のギャップを可視化しましょう。
創業期のベンチャーで、社長がマーケや数値を作った経験がないと、売上目標はあってもそもそも施策ごとのKPIがない場合もあるので、そういう場合は作りましょう。
そして、施策ごとにKPIの理想値と、現状のギャップを明確にしましょう。
ファネルごとの離脱ポイントと、原因分析
ここまで見たら、ファネルごとの離脱ポイントを見ましょう。離脱ポイントで、そこがなぜ離脱が起こっているのか、ユーザーにヒアリングしたり、社員の担当者にヒアリングしたりしながら、仮説を立てていきます。
特に、特に離脱ポイントでテコ入れしたら大きく変わりそうな明らかに低い数値を見つけると、今後大きく伸びる可能性が高いです。
施策ごとの成功例/失敗例の共有と、成功例の再現性仮説の言語化
また、施策ごとの成功例と失敗例をチーム全体で共有します。なぜうまくいったのか、なぜうまくいかなかったのか、ある程度仮説を立てます。
そして、成功したものはだいたい成功する何らかの原因があるので、それを仮説でいいので言語化して、成功例の再現性仮説を立てます。
再現性仮説に基づいた施策の改善、または横展開
成功例の再現性仮説を立てたら、その施策を改善するか(深めるか)、横展開するか(広げるか)して、100発くらい施策を打ちます。その中で、確からしい施策が出てくるので、再現性の角度を上げていきます。
日次・週次でKPIをモニタリングし、次のアクションを決めるようなフィードバック体制
再現性を確認するうえでも、ボトルネックを確認するうえでも、各種KPIがチームに共有された状態にして、全員で数字を意識しながら施策を打ったり改善できるような仕組みを作ります。
ユーザーのプロファイリングとペルソナ作成
マーケ担当でも、CSと連携して、とにかくユーザー情報をヒアリングしまくります。僕のお勧めは、営業をする、CS対応する、できないなら営業やCSと仲良くなって、お客さんのことについてヒアリングしまくることです。
施策の精度を上げるうえでも、「誰」を常に意識し続けること、そしてそれをチームで共有できていること、これのハブになるイメージです。
期待値が合うお客さん、合わないお客さん、そもそもサービスの対象者ではないお客さんがだれなのか?という認識をチーム全体で持てるようにします。
セクショナリズムが起こらないように「前工程の感謝、後工程への思いやり」をフロントにいる人が言い続ける
小さな組織ですら、役割による分業は起こり、最悪の場合セクショナリズムに陥ります。そうすると、ユーザーを見たり、全体最適ができなくなるので、全体最適することが大事だとしっかりとチームで目線を合わせます。
これがないと部門間で対立して、生産性が落ちます。
あと、これをやる人はなるべくフロント(ファネルの一番上)の人がやるべきで、理由としては攻められるし守りもできる立場の人が守りをある程度知っておいた方がいいからです(守りは攻めの道理とのバランスを考えず、守りに徹したほうがいいため。)
あと全体最適な行動をしたらその人を誉めまくります。これをやると、チーム全体の生産性がぐわっと上がります。普通に仕事をしていて気持ちいし。
タスク管理する
Trelloでもなんでもいいので、だれが何をいつまでにやるのか証拠が残るような体制にします。「任せたのに、やってくれなかった」は、ほとんどの場合タスク管理のシステムが社内に存在しないからです。
------------------------------
ここまでが成長期に入るくらいまででやることと。成長期に入ったらやることリストがこちらです。
------------------------------
小さなチームに分ける
従業員規模10人くらいでも、小さなチームに分けます。これは責務を明確にするため。役割は責任を持つうえで、重要です。みんなが手を付けていないタスクが生まれないように、この系統ならこの人がなんとかしないといけないという仕組みにします。
チームメンバーの得意、不得意を言語化する
後述しますが、管理が得意な人、実務が得意な人、クリエイティブなことが得意な人、言われたことを最高の成果物できっちり仕上げて渡せる人、やることさえ明確であれば、ひたすら突っ込める人など、長所、短所は人それぞれ。
チームを作るうえで、だれが何をできるのか、言語化しつつ、チームメンバーの得意どころを伸ばせるようにすることが重要です。
適材適所に配置する
得意なところを活かすような配置にします。苦手なことはやらせないようにNOを出します。
マネージャーとプレイヤーの責務を分ける
最初は全員プレイヤーなんですが、マネージャーとして数値責任を負いつつ実務も実行できる人、プレイヤーとして実務だけ実行できる人に分かれます。
マネージャーとして実務も実行できる人は、なるべく早く管理できる責務を負いつつ、新しく定型化されていないカオスを言語化してオペレーションを組みます。
プレイヤーに関しては、とにかく数値を一緒にみて、ある程度標準化されたオペレーションの中で自走できるようにフィードバックだけできるようにします。
マネージャーは、1カ月前にやっている仕事と、今やっている仕事が同じだったら黄色信号です。「自分にしかできない」とか思っていたら赤信号です。それくらいの速さで今やっていることは権限委譲してほかのできる人に任せて、組織がまだ仕組み化できていないやばめなカオスを仕組み化します。
------------------------------
思い出せる範囲がこれくらいなので、思い出したら加えます。