プロダクトマネジメントの進化を担うProduct Ops

プロダクトマネジメントの考え方が普及し、大手企業にもDXと名前を変えて浸透し始めています。その中で、数十名規模以上のプロダクトマネージャー組織を持ち始めている企業も出てきています。

どのような組織でも1部署で20-30名を超え始めると、仕組み化やプロセス化のニーズが高まってきます。プロダクトマネージャー組織でも例にもれず、20-30名になると、Product Opsというチームの組成を検討し始め、組織のスケーラビリティの向上に取り組んで行くことになります。

本記事では、国内でも徐々に検討が進められ始めているProduct Opsという組織に着目し、その役割や実際の運用で気をつけるべきことを確認していきます。

Product Opsとは

Product Opsとは、プロダクト企画や開発のオペレーションを設計、構築し、運営しながら、最適化を目指す役割を指します。プロダクトマネジメント組織のサポートを中心に据えつつ、デザイン、エンジニアリングとの連携や、ビジネスサイドとの連携も含め、様々なオペレーションを担当することが多いです。

つまり、プロダクトマネージャーがプロダクト企画や開発に集中できるように、業務フロー設計やその運用を引き受け、企画、開発リソースの効率的活用を目指します。社内のプロダクトマネージャーをユーザーとし、プロダクト企画や開発の業務フローをスコープにしたプロダクトマネージャーと言えるかもしれません。

国内だと、まだ少なくProduct Opsを担う方々のバックグラウンドはバラバラだと思いますが、海外だと抽象度の高い業務を型化していく点に着目し、コンサル出身者の割合が高いように思います。コンサルというと、戦略面ばかりが強調されますが、オペレーションの構築にも戦略的思考は相性が良いからだと思います。

プロダクトマネージャーとの比較

プロダクトマネージャーは担当領域におけるプロダクトビジョンから効果測定まで行い、プロダクト自体の進化を担います。他方、Product Opsはプロダクト企画や開発における業務フロー設計から運用までを担当し、会社全体の企画、開発リソースの効率化を担います。

つまり、視点とスコープが大きく異なります。プロダクトマネージャーはあくまで自分の担当領域の中でプロダクトを通してユーザー価値の創出を検討しますが、Product Opsではプロダクトマネジメント組織全体の効率化を担います。そのため、Product OpsはCPOやVPoPと同じ視点で考え、アウトプットを求められるのです。

また、プロダクトマネージャーはプロダクトを通したユーザー価値の創出をスコープとしますが、Product Opsは直接ユーザー価値を創出を担うのではなく、その基盤となる業務フロー設計と運用をメインで担当します。

Product Opsが担う具体的な役割

Product Opsはプロダクト企画や開発に関する業務フロー設計と説明していきましたが、その業務内容は非常に多岐にわたります。ここでは、戦略面と組織面にわけて詳述していきます。

1.戦略面

経営陣とのコミュニケーションの最適化

• 経営陣と連携し、プロダクトビジョンやロードマップを整備し、実行計画を策定・管理

ビジネスサイドとの連携

• リリーススケジュールやユーザーへの公開開始など、ビジネスサイドにプロダクトに関する情報を連携する際のルールの設計と運用
• ビジネスサイドが得たユーザーからのフィードバックをプロダクトマネージャーに連携し、それをプロダクト開発に活かすプロセスを設計・最適化

日々の運用のフォーマット化

• PRDなどの主要ドキュメンテーションのフォーマット化や、PRDなどの主要ドキュメンテーションのフォーマット化や、場合によってSaaSの導入検討も含む

プロダクト間、ビジネスユニット間における各種調整

• NPSなど、ユーザーサーベイの設計や評価
• プロダクトのバンドリングやチャージモデルの選定、最終的な価格感の策定
• 特許など、プロダクト横断テーマの運営

予算策定、予算管理業務

• プロダクト戦略を実現する上での人員計画や、リサーチや各種ツールの予算、採用や異動に伴う育成計画の設計
• 予算決定後、各種支出状況の管理や運営

2. 組織面

採用やチーム内の異動を調整・管理

• プロダクト戦略を元に、人員計画の策定をサポート
• 採用枠を元にJDを作成し、採用の目標管理、採用プロセスの最適化を行う
• 各種カンファレンスへの登壇や社外向けにブログ等の配信など、採用ブランディングの企画、運営

オンボーディングメニューの設計、運用

• 入社した方や異動してきた方向けに、会社全体ではなく、プロダクトマネージャーとして、すぐ立ち上がれるようなコンテンツの設計と運用

コミュニケーションの設計

• All handsやSlack、ミーティングなどの設計と運営

上記の通り、プロダクトマネージャーの業務をかなり広く把握し、課題感の抽出を行い、業務フロー設計、フレームワーク化、場合によって自ら入って行って調整を行うことになります。

Product Opsの立ち上げと運用

まず、Product Opsを立ち上げる上で、どのような方をアサイン、採用していくかが大きな論点となります。当然まで国内で普及しているロールではないので、親和性の高い職種からの異動、採用を行うことになります。Product Opsは、その役割からプロダクトマネージャー向けの業務フローコンサルに近いので、マネジメントコンサルやITをコンサル出身者がスキルや知見という意味ではフィットし易いです。その中でも、スタートアップやベンチャーに近いプロジェクトの経験があると、より適性が高まります。オペレーションとは、目的やゴールを明確化し、それまでのクリティカルパスの設計とインプリを行うことになるため、実はコンサルが武器にする戦略的思考と相性が良いです。ただし、国内ではオペレーションという言葉自体がやや弱いので、CPO室、プロダクト戦略室などと打ち出し、Product Opsに求められる視座の高さや、スコープの広さ、そして戦略面での役割をしっかり訴求していくことが重要だと思います。

次に、Product Opsが立ち上がると、業務スコープの広さからプロダクトマネージャーからいろいろ相談を受けることになります。プロダクトマネージャーは、その業務の性質上、プロダクトビジョンや戦略に対する意識が高い人が多く、プロダクトマネージャー組織全体に向けた各種仕組み化などを後回しにしてしまいがちです。そのため、Product Opsが立ち上がると、自分の担当領域外のことを引き取ってもらえないか相談しに来るのです。しかし、Product Opsはただ引き取るのではなく、引き取ることで業務フローを整備し、プロダクト企画や開発の運用効率が上げられないと、あまり意味はありません。あくまで目標はプロダクト企画や開発の効率化であり、プロダクトマネージャーのアシスタントではありません。

Product Opsはプロダクトマネージャー陣から業務を巻き取る側面だけではなく、各種業務フローを設計し、実際プロダクトマネージャーに運用してもらう必要もあります。そのため、CPO/VPoPなど経営レイヤーからの強いサポートが不可欠になることもあります。彼らに新しい業務フローの価値を組織全体に説明してもらい、普及を促進したりします。もちろん、トップダウンで落とすだけではなく、モニター的に個々のプロダクトマネージャーをサポートして、ある程度型化できたタイミングで、プロダクトマネージャー組織全体に展開するという流れもあります。

プロダクトマネージャー組織内において、Product Opsは業務を集約するアウトソーシングチームではなく、プロダクトマネージャー組織の効率化を主眼に掲げたチームであり、CPO/VPoPやプロダクトマネージャーと良きパートナーであることが重要なのです。

まとめ

国内のプロダクトマネジメント関連の記事を追っていると、戦略や意思決定に関する話が多いです。Product Opsの役割で記載したことが組織の規模やプロダクトのフェーズに応じて進化していないと、想像以上にリソースを割くことになってしまいます。にも関わらず、プロダクトの進化というイノベーションを主軸に抱えるプロダクトマネージャーからは、仕組み化、プロセス構築という業務は後回しにされがちです。

そこで、Product Opsを立てて、プロダクトマネージャーのパートナーとしてプロダクト企画や開発における業務フローの構築と運営を最適化していくことで、次なるプロダクトマネジメントの進化を担う一手となりうるでしょう。