CPOの役割定義と1年目にやったこと
はじめに
2021年10月にスタートアップのCPOに就任し、その後1年間CPOの定義から模索しながら様々な活動をしてきました。
というのも、昨今はプロダクトマネージャー(PM)についての役割や業務事例は増えてきたものの、CPOという役割はまだベンチマークとなりうる事例が少ないからです。
そこで、私は独自にCPOの役割を「プロダクトポートフォリオマネージャー」と定義しました。それは、保有するプロダクト群から生み出される顧客価値とキャッシュフローの最大化に責任を持つ役割です。
この記事では、CPOの役割をそのように定義した背景や、具体的にポートフォリオ全体から生まれる成果を最大化するために行った取り組みを紹介します。
cf. プロダクトマネージャーの役割について
プロダクトマネージャーの役割についてはこちらの記事を提唱し、反響を頂きました。よろしければこちらも併せてご覧ください。
TLDR(長すぎて読めないよという方に)
① CPOの役割は「プロダクトポートフォリオマネージャー」
② 従来のPPMとは異なり、投資判断よりもグロースにフォーカス
③「プロダクトを中心に事業が成長する構造」を創る
④ CPOはPM業よりも周辺の事業責任者的なスキルが求められる
CPOの役割定義の背景
CPOを「プロダクトポートフォリオマネージャー」と定義した背景を説明します。
私が所属している会社の特性上、単一プロダクトをスケールさせるような会社ではなく、プロダクト数も増やしながらスケールするMulti-Productな会社です。
つまり、単体プロダクトをグロースさせるだけでなく、「既存プロダクトの成長率」×「プロダクト数の成長率」をマネジメントする責務を負うことになります。そのためCPOの役割を「プロダクトポートフォリオマネジメント」と定義しました。
BCGが提唱するPPMとの違い
似たような概念で、ボストンコンサルティンググループ(BCG)が提唱したフレームワークにもPPM(Product Portfolio Management)があります。
こちらのフレームワークはCEO・CFOレイヤーの資源配分の意思決定の際に重宝された考え方です。しかし、こちらのフレームワークにも2つの難点があります。
1つ目はそもそも市場を定義するのが難しいことです。市場の中でも商品カテゴリベースの市場定義では視野狭窄に陥るリスクがあります。(例えば電車の競合は自動車や飛行機)便益ベースで競合を定義するとプレイヤーは多岐に渡り、新たなイノベーションが市場を激変させる可能性もあります。従って、そのような捉え方をすると、市場の定義や見通しの難易度が飛躍的に高まります。
2つ目は仮に事業毎のポートフォリオ内のポジションを定義できたとしても、ダイナミックに資源配分を変えることが現実的には難しいからです。B事業よりも、A事業の方が有望だとして、B事業の人員や予算を、A事業にドラスティックに移動させることは容易ではないからです。
BCGのPPMの説明はこの程度にしておいて、こちらの理論との違いはCEO・CFOレイヤーに求められる資源配分の意思決定よりも、プロダクト全てのグロースの実現に重きを置いています。
つまり、成長率の低いプロダクトを「負け犬」として諦めるのではなく、「負け犬」から「スター」に変えるためにはどうすればよいのか?「スター」を更に伸ばすためにはどうすればよいのか?を突き詰めて考え、実現する役割です。もちろん、時には諦めることや、投資を縮小させる責務もあります。
cf. ラクスルCOOの福島さんのPodcastで提唱された「グロース・ポートフォリオマネジメント」にかなりインスパイアされています。
プロダクトマネージャーとの棲み分け
プロダクト全体のグロースを実現すると言っても、自分がPM業を行ってグロースさせるには限界があります。実際にはそれぞれのプロダクトをグロースする主体は担当プロダクトマネージャー(PM)であることが理想です。そのためCPOはPMを採用し、PMが活躍できる土壌や仕組みを創る業務がメインです。
もっと言うと「プロダクトを中心に事業が成長する構造を創る」ことです。
プロダクトは事業に内包されています。そのため、良いプロダクトをつくる手前には良い事業戦略が必要です。また、顧客が求める良い機能や改善を実現するだけでは事業は伸びません。プロダクトの強みがプロモーションによって適切なターゲットに適切な便益が伝達される必要があります。
他にも、オペレーション・カスタマーサポート・コンテンツなど、プロダクト以外にも様々な事業活動があります。それらの全ての事業活動が、プロダクトの価値を中心に一本槍となって連携・連動(Alignment)することで事業は成長します。
そのため、CPOの役割はPM業というよりも事業部長やCOOのようなジェネラルなスキルも求められます。私ももう少しプロダクトと向き合いたかったのですが、予想以上にその周辺領域の課題解決が求められました。
ちなみに、前職で関わっていたCPOの方はプロダクトマネジメントのスペシャリストに近かったので、様々な正解があるのだと思います。
CPOとしての業務の全体像
CPOはつまるところ、正しいプロダクト開発を中心に、事業全体をアラインメントさせるのが役割という訳ですが、言い換えるとソフトウェアプロダクトのドメインにおいて「自律的な課題解決ガバナンス」を実現することと定義しています。
自律的な課題解決ガバナンスについて
「自律的な課題解決ガバナンス」とは以下の本で提唱されており「優れた企業」を実現するために必要なことです。
この本では「優れた企業の特質」を以下のように定義しています。
優れた企業の特質を実現するためには特に「組織としての自律的な課題解決能力」の獲得、即ち「自律的な課題解決ガバナンス」の確立が経営者の命題だと提唱されています。
私はこの考え方はCPOの役割と非常に近しいと感じました。複数プロダクトを正しくグロースさせる役割を持つので、全てのプロダクトに「PMを中心とした自律的な課題解決ガバナンス」の確立を目指しています。また、それは以下の状態です。
自律的な課題解決ガバナンスの実現に必要なこと
私は1年間「PMを中心とした自律的な課題解決ガバナンス」を実現するために様々な組織的モジュールを事業やプロダクトに導入してきました。以下の図が全体像です。
「自律的な課題解決ガバナンス」を実現するために必要なモジュールは時間軸によって異なります。また、上から固めていけばいいというものではありません。何をやるか以上に、どの順番でやるのかが重要です。
私は1年間で以下の図の順番で施策を実施してきました。基本的には難易度×緊急度を加味しつつ、目の前の事業活動のボトルネックになりそうな課題を順番に実行してきました。基本的に周期軸が長い施策の方が難易度が高いです。
次の章からは各モジュール・施策についての具体的なフォーマットや業務内容について時系列順に紹介していきます。
1/ 事業戦略の策定
事業戦略の策定は非常に労力を要し、難易度も高いです。しかし事業戦略の策定は事業成長の1丁目1番地です。というのも、事業戦略が固まっていない状態での事業活動は無駄・非効率になる可能性が極めて高いからです。
もちろん、事業戦略をコロコロ変えていては信頼が損なわれ、実行力が生まれません。そのため、情報が集まりきっていない時に策定するリスクも大きいので慎重に策定すべきではあります。しかし、だからといって放置してはいけない難題です。
具体的な事業戦略の展開タイミングは、大きくは外さないと判断できたタイミング「東西南北に分けるとしたら東方面であることは間違いないだろう」と確信できたタイミングで公表しました。
東に進んでいる途中で、南東、北東寄りにピボットする程度は耐えうるからです。45°のピボットであれば、多少道程は非効率だとしてもそこまでの歩みは無駄になりません。また、事業部に関わるメンバーにも受け入れられる範囲内だと思います。(もちろん大きな組織になればなるほど受容度は下がります。)
事業戦略の定義と策定方法
そもそも事業戦略とは何でしょうか。世の中には様々な定義があると思いますが、私は以下のように分解して定義しています。
顧客戦略というのはWho(ターゲット)とWhat(便益)です。顧客戦略は十分に独自で価値がある必要があります。顧客戦略の策定方法はこちらの本を読む事を推奨しますが、自分が実施したプロセスも簡単に紹介します。
基本的に顧客戦略は”他サービスにはないプロダクトの強み”を発見することが9割です。プロダクトの強みは、自社サービスのロイヤルカスタマーに10人前後インタビューすることでなんとなく肌で感じ取ることが出来ます。
更に競合サービスのロイヤルカスタマーにもヒアリングが出来れば尚良いです。競合サービスのロイヤルカスタマーと自社のロイヤルカスタマーの間にサービスを選ぶ理由や、価値観や雰囲気が違うなと感じ取れればベターです。(競合サービスのロイヤルカスタマーは自社のライトユーザーの中からソーシングする事も可能です。)
プロダクトの強みを発見できたら、その強みに価値を感じてくれるWho(ターゲット)とWhat(便益)を言語化することで基本的には完成です。
ただし、ターゲットの出現率は定性インタビューのみでは分かりません。そのため、ネットリサーチサービスを利用したり(10万円くらいでも可能です)、最低限自社のユーザーにGoogle Formなどで、同様な便益を感じているユーザーや、同じようなニーズを持っている、ターゲット顧客の出現率を把握しておくことも重要だと思います。
また、顧客戦略(WhoとWhatの組み合わせ)は複数あっても構わないのですが、まずは顧客戦略を1個に絞りプロダクトを磨き込むことをおすすめします。
コスト戦略に関しても、競合には真似できない独自のコスト構造を実現できるのがベターです。そのためには誰がターゲットで誰がターゲットではないのか。 何の便益を磨き込み、何の便益を磨き込まないのか。顧客戦略を明確にする必要があります。
自社がやらない事を決めることで、他社には削れないコストの余地が生まれる可能性があるからです。
顧客戦略は顧客シェアを伸ばす≒トップラインが伸びていくのに対して、コスト戦略はボトムラインの底上げに繋がります。表裏一体で設計されているのが美しいです。
2/ Steering Committeeの導入
事業戦略を立案後は、それぞれの事業活動を事業戦略にアラインメントする必要があります。そのために導入した会議体がSteering Committee(以下SC)です。
SCとは事業責任者+各チームリーダーが以下の目的とアジェンダで月に一度開催しています。(月初のPLが確定したタイミングなど)
アジェンダは事業部全体と各チームごとに各月のOKR(施策内容の共有)とMetrics(数値の共有)の共有と相互レビューを実施します。1チーム15分~20分程度で進行します。相互レビューではなるべく横のチーム同士で疑問解消や施策のアイディアが生まれるように促します。
1つ目のOKRは以下のフォーマットで共有します。(青字は入力項目)
OKRは1つから多くても3つ程度です。OKRの進捗だけでなく、どのような施策を行ったのかなども他の方にもわかるように共有しています。
※ 実はOKRの導入はSC導入後の数カ月後です。最初はOKRではなく施策とMetricsの共有でしたが、慣れてきたタイミングでOKRを導入しました。
2つ目のMetrics Reviewのフォーマットです。Metricsの数に指定はありません。OKRで設定した数値も含みますが、それ以外にもモニタリングすべき指標なども共有します。どちらかというと網羅性重視です。
24ヶ月分の数値を可視化しているのがポイントです。というのも24ヶ月程度の数値を見ないと数値の変動要因が外部環境要因なのか施策要因なのかたまたまなのかわからないからです。
人間には確証バイアスという特性があります。施策を実施した月にたまたま数値が良かった時、その施策が要因だと思いがちです。(何度も何度もあります…)
それに対して、去年のデータも照らし合わせると季節要因で上がっている可能性が見えてきたり、翌月以降も数値が高いままであるかどうかなどを見比べることで、施策要因が確からしいことがわかります。
SCを実行することで2つのメリットが有りました。1つ目は、事業戦略や事業計画を意識した活動が増えました。2つ目は横串の連携が多く生まれ、実際にプロダクトのKPIが伸びました。
また、きちんとMTGを運用・フィードバックすることで次回のSCまでに何かしらの成果を持ってこようというプレッシャーにもなりうるので、各事業内のチームのコミットメント向上にも繋がると考えています。
※ 以下のようにConfluenceに事業部+各チームごとに毎月ページを作成し、上記のような内容を記入し、相互フィードバック・アイディア出しを実施しています。
3/ 事業部全体にOKRを導入
Steering Committeeを月次で行うことで、施策の内容とその結果の共有の機会をセッティングしました。さらに非連続成長を促進するための仕組みとしてOKRを事業部全体に導入しました。
本来であればSteering Committeeのタイミングでの同時導入がベストでしたが、OKRとの同時導入はメンバーへの負荷が高いと判断し、SCの運用が安定するまで待ちました。
OKRを導入するメリットは以下のとおりです。事業活動はともすれば惰性で行われがちです。効果が出ていないにも関わらず続けられる活動も少なくはありません。そこで、四半期に一度は何かしらの非連続的な目標を掲げてチャレンジする習慣を醸成します。
また、OKRにはいくつか策定における注意点があります。
① Key ResultsはなるべくKDIよりもKPIを設定
なるべく行動目標ではなく成果目標をセッティングするべきです。例えば新商品売上向上を課題定義したときの例を紹介します。
非連続成長は模索のプロセスです。非連続成長を促進するにも関わらず、行動目標を設定するとやることが目的化します。成果を達成するために様々な方法を模索するほうが非連続成長が実現する可能性が高くなります。
尚、OKRは評価にも使わないですし、非連続成長を促進するためのツールであるため、予実は外れても構いません。下手に予実を合わせようとすると非連続成長は生まれません。
②~④も同様です。
OKRは非連続成長を促進するためのツールにも関わらず、②のような確実性の高い目標、③のような現状維持的な目標、④のような数値目標を決めきらないというのは本末転倒です。
もちろん現状維持的な目標も必要です。しかしそれはOKRである必要はありません。事業計画なり他の考え方で管理・モニタリングすべき対象です。
⑤KRは成長率(+x%)ではなく絶対値(x1→x2)で記載
これは単純に他の人もわかりやすいからです。以下に例を示します。
後者のほうがインパクトがわかりやすいので、後者のフォーマットで記述することを推奨します。
また、OKRの運用は四半期毎に設定しています。以下のように、事業部全体のOKR+各チーム毎のOKRを策定しています。
各チームごとのOKRは必ずしも事業部OKR以外の内容をセッティングして問題ありません。というのも、事業部のOKRが全てのチーム活動を内包するものではないからです。網羅性を重視しすぎると目標が抽象的になり、非連続な行動が生み出されにくいです。網羅性よりも具体的でクリティカルであることを重要視しています。
4/ 経営へのレポーティングフォーマットの改編
組織に新メンバーが増えた影響で、過去のプロダクトの経緯や歴史を説明する機会が増えました。それを機に、経営サイドや新メンバーの誰が見ても事業の状況がわかる週次のレポーティングフォーマットを模索しました。
模索の結果、レポートのフォーマットはAmazonの週次の経営会議の"Weekly Business Review"という会議体の資料をベンチマークとしました。私も週次レポートをWeekly Business Reviewと命名し、毎週作成、共有しています。
基本的な構成はSteering Committeeと同様にOKR Review + Metrics Reviewです。(※ AmazonはOKRを導入していません)
基本的にはSteering Committeeのフォーマットと揃えています。異なる点は各チームごとの粒度では共有せずに、各プロダクト毎に事業部全体のOKRのみに絞って共有しています。各チームのホットトピックがある場合は、次のMetrics ReviewパートやAppendixで共有しています。
OKRを共有することで今注力している事業課題を説明することが出来ます。経営会議などでは、一般的に「今後はどういうことをするのか?」「こういうことをしたら良いのではないか?」という質問や意見を頂くことも多いです。(ちなみにGENDAは的外れな指摘や過度な確認が驚くほど少なくてやりやすいです。)
OKRを掲げることで四半期レベルでPDCAサイクルを回していることを理解されます。そのため、方針のピボットは四半期レベルに吸収することが可能です。
次にこちらはMetrics Reviewのフォーマットです。実際にMTGで共有するKPIは数個ですが、チャート自体は網羅的に毎週生成するようにしており、最大30個程度のチャートを添付しているプロダクトもあります。
また、SCのフォーマットと異なる点は週次の数値も記載している(チャート左部)ことです。そもそもレポーティングの周期が週次であることと、施策実施後の数値変動などは、最低でも週次単位で見ないと変化がわからないからです。
また、上記のチャートを見て頂けると分かる通り、週次の単位でも昨年の数値と連動する傾向が見えます。(数値自体はダミーですが、実際にモニタリングしているチャートに近い形になるように生成しています)
故に直近の8週間の数値だけでなく、昨年同月週の8週間分の数値と照らし合わせることで施策要因での数値変動がわかります。
SC同様Weekly Business Reviewについても、Confluenceに各プロダクト毎に毎週レポートを作成しストックしています。
過去のnoteでも書きましたが、個人的にレポート業務は非常に重要だと考えています。プロダクトの責任を預かっていて、結果が確約出来ない以上、プロセスに対する説明責任も一定生じます。また、説明責任を果たすことでPLの変動要因への解像度が高まることになります。ですから、読めばMetricsの変動要因を追えるレポートを目指しています。
ちなみに、チャート自体はthink-cellというサービスを用いて、アシスタントサービスにアウトソースして生成していますので、運用負荷はそこまで高くありません。(最初は手作業で自分でやっていましたが1日掛かりました。)
5/ パネルリサーチの導入
SC・OKRの導入で非連続的な施策が生まれ、事業成果も出始めました。一方で定期的に事業の方向性が正しいのかを点検し修繕する必要があります。具体的には以下のような論点を定期的にチェックする必要があります。
そこで、パネルリサーチやコンセプトテストなどを導入しました。ネットサーベイで実施したこともありますが、Google Formで自社ユーザーへのアンケートでも十分であることがわかったので、以下の調査項目のアンケートを四半期に一度程度実施しています。
分量的にこのセクションは別のnoteで記述しようと思いますが、基本的には以下の書籍のスマートニュースの調査事例をもとに設計しています。(神本すぎる)
コンセプトテストについて
パネルリサーチとは別に、コンセプトテストの導入で企画の打率がかなり高められると確信していますので少し触れたいと思います。アンケート調査で以下のような質問項目を用意します。
また、「5.絶対に利用する」の選択肢をTop Boxと呼びます。コンセプトテストの回答結果のTop Box率を以下のように可視化して、最も利用意向の高い機能を洗い出します。
何%以上だと望ましいなどの理論もありますが、母集団セッティング次第ですので、相対評価と何度も何度も実施する事をおすすめします。評価が横並びの場合はどれも刺さっていない可能性が高そうです。 基本Google Form×テキストの選択肢で実現できるので、実装前にテストする事が非常にオススメです。
6/ 事業計画と年間計画の策定フォーマット導入
期中からの参画だったため、事業計画や年間行動計画などの策定のテコ入れは後回しになりました。すでに事業計画はあるものの、プロダクトとマーケティング関連のKPI目標まで落とし込まれていないケースがありました。
また、何をやるかよりも、いつやるか、つまりスケジュールを詰めるプロセスに重きがおかれていて、ソフトウェアのスケジュールや効果見積もりの不確実性に対応しきれていないケースもありました。
もちろん営業など、行動計画で事業成果が予測しやすい領域であれば、スケジュールをきっちり詰める事が重要です。しかし、ソフトウェアサービスは同じようにうまくは行きません。
また、私が所属する会社はベンチャー企業です。コロナの外部環境の変化の影響を受けやすく、toC事業という特性があり、そもそも事業計画の策定の難易度が非常に高いです。ですが、そのような事業でも他業種と同じような予実を合わせることが求められます。
そのため、不確実性を考慮した事業計画の策定が不可欠です。そこで私は以下のようなフォーマットを導入しました。
■ 年間行動計画フォーマット
まずは年間行動計画のフォーマットです。Q1~Q4の区分毎になにをやるのかを記述します。
事業部として一つにまとめてしまうのも良いですが、事業部内の各チームにも展開し、各チーム毎にも記述してもらう方が施策を洗い出す事が出来ます。
ここでの肝はQ3以降はきっちり書かないことです。(特にプロダクト開発の計画において)というのも、Q1・Q2とスケジュールを建てたとしても大抵の場合は遅延します。
また、Q1・Q2で想定していた通りのKPIに到達する可能性は、スケジュールが守られる可能性よりもさらに低いです。そのため、Q3・Q4はQ1・Q2のバッファ・リカバリー期間と設定することが吉です。(もちろん不確実性に応じてQ4のみをリカバリー期間と設定するのもありです)
■ 来期末目標フォーマット
次に事業計画策定のために来期末目標フォーマットを作成しました。事業計画策定の際はよく12ヶ月分の売上・利益目標の記述を求められますが、それは最後の作業です。まずは来期末時点の目標値を固める方が組み立てやすいです。尚、こちらも事業部全体で一纏めではなく、事業部内のチームにも展開してすり合わせをした方が良いです。
まず期末時点(1ヶ月分)の目標値とKSF(施策内容)を記述します。というのも、プロダクト開発においてスケジュールと効果は不確実です。そのため、各月の行動計画を建てて12ヶ月分の目標値を設定するのは複雑過ぎます。
「1年間でこのくらいのことをやれたとしたら、期末時点ではこのくらいになっているだろう。」程度の方が返って見積もりの精度が高くなります。
また、行動計画の箇所でも述べた通り期末目標値はQ1・Q2の行動計画がうまくいった時の値程度にしておき、Q3・Q4はリカバリー期間と設定することをおすすめします。
ここまで揃ったタイミングで、12ヶ月分の数値を入力します。基本的には期末推定に向かって12ヶ月分の値を線形にプロットします。線形で入力した後に季節要因や施策スケジュール要因などを調整するのが良いです。
尚、事業規模やフェーズ、不確実性次第ではより精緻に作り込みが必要なケースはあります。
7/ 2030年Vision策定(途中)
GENDAには「世界中の人々の人生をより楽しく」というAspiration(大志)やVisionなどは存在します。一方で、目指しているVisionと日々の活動とのつながりを感じにくい状態でした。
そこで以下のように、現在と未来のVisionのギャップを埋めるために、中間VisionとRoadmapを策定し、共有することが必要だと判断しました。
そこで、2030年の中間Visionを策定するワークショップをメンバー全員で行いました。ただし、最終的なVisionの言語化と決定は少数のマネジメントメンバーで行います。
※ 組織構造がややこしいので割愛しましたが、ここでのVison策定プロセスはテクノロジー組織に限定したスコープです。
cf. ワークショップはメルカリ様のスライドも参考に設計しました。
Visionの策定の考え方は。以下の観点からの情報を取捨選択・組み合わせをすることと定義しました。
また、Visionが成果として策定されること以上に、Visionの策定プロセスがより重要だと考えています。というのも、メンバー全員の想いやアイディアを共有することで、個々人がどのようなアイディアを持ち、何をモチベーションに日々業務に取り組んでいるかを理解出来るからです。
Vision策定ワークショップの設計
ワークショップは以下の3部パートで設計しました。4人一組のチームに分かれてワークショップ1~3を半日かけて実施しました。
■ ワークショップ1. メンバーのWill編
まずはメンバーそれぞれのWillを言語化します。日々の業務や発言の裏側にある考え方や想いなどが知れて非常に有意義なワークショップでした。こちらのセッションはディスカッションではないので、事前にGoogle Formなどで回収しても良いと思います。
■ ワークショップ2. 外部環境の変化編
次にPESTの観点に沿って外部環境の変化を洗い出します。そのうえで、自社が取り組むべきキーワードをピックアップします。
こちらのワークショップは難易度が非常に高いにも関わらず、想定以上に良いアウトプットが出ました。個人的な反省点としては事前準備に時間が掛かる点です。もう少し事前準備のバッファを設けるべきでした。
■ ワークショップ3. 2030年のVision策定編
ワークショップ1, 2のアウトプットをベースに、2030年時点の業界→自社(事業・組織)→個人においての理想状態を定義します。
各チームによって様々なアウトプットが出ます。外部環境の捉え方は似通ったとしても、そこからのVisionへの昇華にはチーム毎の価値観が混入します。結果として個々人が理想としているゴールイメージやロジックを理解することが出来るので、Vision自体のロジックが強固になるだけでなく、共感されるVisionを策定できる可能性が高まります。
執筆時点ではVisionの策定途中ですが、なるべく多くのメンバーと一緒にVisionを考え、意見を発散してもらうことは非常に有意義です。(かくいう私も最初は大人数で策定することには否定的でしたが、やってみて考えが変わりました。)
8/ その他
上記以外にも様々な業務を行いました。各職種の採用活動も行いましたし、行動指針や評価制度の策定もCTO/VPoEと共に行いました。(自分が主体ではないことと、まだ完成とは言えないので、本noteには記載しませんでした。)
もちろんPMが居ないプロダクトでは自分もPMとしてジョインし、PRDやバックログの整理などをすることもあります。SQLも叩きます。
また、PM組織に関しては、幸いなことに組織づくりまでリードして頂けるシニアのプロダクトマネージャーの方にジョイン頂きましたので、自分はリードしていません。(お陰様で副業PMの方も安心して業務ができるほどプロセスが整備されました)
PM以外にも今のフェーズではCPO直下にマーケティング担当が複数名在籍し、Designer・Analyst・BizDevポジションの方も募集しています。
「PMを中心とした自律的な課題解決ガバナンス」実現のために様々な事を行いましたが、1年目で実施できなかったこともあります。
「既存プロダクトの成長」の型を定義できましたが、浸透はまだまだです。そして、プロダクト数自体は有難いことに手に負えないほど増えているのですが、「プロダクト数の成長」の仕組み化はまだ実現できていません。他にも採用をリファラルに依存しているので安定採用も課題です。2年目はそれらの課題も取り組んでいきたいと考えています。
終わりに
長文を最後まで読んでいただきありがとうございました。CPOとしては1年目で手探りでしたが、様々な仕組みの導入が実現できたという気持ちと、やるべきことの半分も出来ていない気持ちが混在しています。
ただ、CPOの定義自体は自分なりには納得しています。正解は1つではありませんが、もしどなたかの参考になれば幸いです。
PS. PM向けなどのイベントを開催したいと考えています。こちらで会場提供や運営なども可能ですので、お声がけください。