[レポート] B-7 マルチプロダクトでスケールするプロダクトチームをつくるために – プロダクトマネージャーカンファレンス2022 #pmconf2022

2022年11月02日(水)、プロダクトマネジメントに携わる人たちが共に学び、切磋琢磨するイベント『プロダクトマネージャーカンファレンス2022』がオンライン形式で開催されました。

当エントリでは、ブレイクアウトセッション『マルチプロダクトでスケールするプロダクトチームをつくるために』の参加(視聴)レポートをお届けします。

目次

• セッション概要
• セッションレポート
• まとめ

セッション概要

セッション概要は以下の通りです。

• タイムテーブル丨プロダクトマネージャーカンファレンス 2022
  • B-7 マルチプロダクトでスケールするプロダクトチームをつくるために丨SESSION 講演内容丨プロダクトマネージャーカンファレンス 2022

セッションレポート

自己紹介

• アプリ版KARTE、KARTE Blocksの事業責任者 兼PdMとして、立ち上げとグロースに従事
• プロダクト戦略、組織、プロセスづくり
• 株式会社PLAIDの「OUR MISSION」：データによって人の価値を最大化する
• KARTEのミッション：あらゆるサービスのCX(顧客体験)の向上に

ビジョンと成長モデルの話

• 一番重要なことは「ビジョンの実現」
  • ビジョン実現には成長モデル作成が重要 > ビジョンと成長モデルがあった上でそれを実現するためのプロダクト作成 > そのためのプロダクト開発組織
• ミッション＆成長戦略：顧客中心の企業活動を カスタマーデータの活用支援を通じて実現
• 狙っている成長モデル：マルチプロダクト x 強いSaaS
  • ネガティブチャーン(解約によって減少した収益と既存顧客からの新規収益を比較した際に、既存顧客からの新規収益が上回った状態)を獲得し、NRR(Net Revenue Retention/Net Retention Rate：売上維持率)を高い水準でキープ出来るSaaS
    • ネガティブチャーン とは :SaaSビジネスの基礎知識- Baremetrics Japan
    • 【SaaS必見】NRRはなぜ重要なKPI？意味＆向上方法を紹介｜pottosメディア
  • ポイント
    • 様々なエントリポイントがある
    • チャーンを低く押さえられる
    • アップセル＆クロスセルが生まれやすい構造である
• 理想の価値提供モデルに向けた歩みと現在地
  • Web接客[2015-2018] → CX Platform(シングルプロダクト)[2018-2021] → CX Platform(マルチプロダクト)[2021-現在]
• CoreのApplicationの関係性
  • 企業とエンドユーザーのタッチポイントにおいて価値あるプロダクトを作る(Application)
  • プロダクトが利用される中でデータが蓄積され、それを用いて解析基盤を強化・解釈データを付与・様々な切り口で可視化(Core)
  • Coreを強みにして周辺のタッチポイントに新たなプロダクトを提供(Application)

スケールする際に発生する課題

• プロダクトを考える際に重要な3要素(Why, What, How)
  • ビジョン・向かう方向性から考える
  • 世の中の課題・コンテキストから考える(市場変化、顧客変化、競争環境など)
  • 自社の強み・競争優位性・シナジーから考える
• 事業・組織規模が大きくなる中で顕在化してくる課題
  • 顧客課題とニーズの複雑化
  • 短期と長期のバランス
  • 管理・運用コスト増大
  • 意思決定速度の低下

プロダクト開発組織とプロダクトマネジメントプロセス

• 目的別に3レイヤーに切り分け
  • プロダクト：顧客課題を解決するための機能会圧(イシュードリブン)
  • コア機能：ビジョンを実現するための共通コア機能の開発(ビジョンドリブン)
  • コアプラットフォーム：安定性と技術的な競争優位性を持つための開発(テクノロジードリブン)
• レイヤー毎にチーム分け
• 3レイヤーに分けることで、4つの課題をまとめて解くことが出来るようになった。
• レイヤーの目的に合った役割配置を行う
• プロダクトマネジメントプロセス
  • プロダクトマネジメントプロセスの力点はプロダクトの特性や事業フェーズによっても異なる。
  • 良いプロダクトをつくり価値を生み出すために必要なプロセスに着目し、チーム内でこれらが満たされているようにする
    • チームとして動き出したら
      • (1).プロダクトに方向性をつけ、チーム全員が共通認識を持つ
      • (2).価値あるプロダクト・機能を見つける
      • (3).やるべき開発タスクが整理・優先順位付けされている
      • (4).チームが継続的に良いリズム、良い関係性で開発が行える
    • プロトタイプ〜ベータ提供を始めたら
      • (5).ユースケースをチーム全員が解像度高く理解している
      • (6).アウトカムを確認・評価する
      • (7).プロダクトフィードバックループが回る
    • ベータ〜GA提供を始めたら
      • (8).ポジショニングとメッセージングを継続的に改善する
      • (9).パッケージング＆プライシングを継続的に改善する
      • (10).プロダクト・機能の継続的なデリバリーが行われている
    • ※チームで誰がカバーしてもいいが、埋まらないプロセスはPdMが持つ
    • ※スケールに合わせてPdM/PMMで役割分担を行う(1-7はPdM,7-10はPMM)
• このプロセスを言語化し共通認識を持つことで今後以下を実現していきたい
  • 必要なプロセスがチーム毎に満たされているか気付ける
  • 満たされているないものを誰かがカバーしにいく動きに繋げる(最適なアサインや採用につなげる)
  • 各プロセスにおけるトライ＆エラーが行われ、学習が進むことにより継続的に会社にナレッジを蓄積する
  • このフレームを通してPdM個々人が自分の現在のカバー範囲を認識し、新しいチャレンジをしやすくなる／段階的に成長出来る機会を作る

まとめ

• 事業や組織規模が大きくなるにつれて複数の問題が同時に起こるのはとても大変
• スケールするには目的の切り分けと目的に対してベストな役割・体制をセットすることが重要
• スケールするには個人突破から組織としての再現性が必要。フレームを持ち、トライ＆エラーとナレッジ化を行いやすくする

まとめ

という訳で、プロダクトマネージャーカンファレンス2022のセッション『マルチプロダクトでスケールするプロダクトチームをつくるために』の視聴レポートでした。

• プロダクトマネージャーカンファレンス 2022 の記事一覧 | DevelopersIO