はじめに
enechainでプロダクトマネージャーをしている酒見 (Kemmy)です。 enechainでは「共通基盤」と「新規事業」の2つの異なる性質のプロダクトマネジメントに携わっています。
私自身、これまで大手企業からスタートアップまで、さまざまな事業ドメイン・フェーズのプロダクトマネジメントに従事してきました。
事業フェーズや規模、それを担う組織によって、プロダクトマネージャーの役割やプロダクトマネジメントのスコープも異なる、というのはよく聞く話です。とはいえ具体的な経験がないと、その違いをなかなかイメージできず、いざ異なるプロダクトを担当することになったときに戸惑う方も多いのではないでしょうか。
今回は、転職や異動などで、これまでと性質の異なるプロダクトを担当することになったプロダクトマネージャー(またはエンジニアやデザイナー含めたプロダクトマネジメントに従事する方々)が、新しい環境において自分自身がどんな役割を担うことでプロダクト価値の向上に貢献するのか、その役割を見出すまでのステップについて具体例を交えて紹介したいと思います。
今回紹介するステップの流れ
プロダクトマネジメントトライアングルの重心
プロダクトマネージャーの責務や、プロダクトマネジメントの定義は、「プロダクトの提供価値/ROIの最大化」という言葉に集約されます。
抽象的でとっつきにくいかもしれませんが、これをモデル化したものの1つとして、プロダクトマネジメントトライアングルが参考になります。
引用元: The Product Management Triangle
【翻訳】プロダクトマネジメントトライアングル - ninjinkun's diary
こちらの記事中では、プロダクトを構成する根源的な要素を「開発者」「ビジネス」「顧客(ユーザー)」としたうえで、これらを繋ぐ役割を「プロダクトネットワーク」として表現しています。
そして、プロダクトマネージャーの役割については、以下のように記述してあります。
プロダクトマネージャーはプロダクトネットワークの全ての領域を健全に機能させることに責任を持っている
- プロダクトネットワークの要素の間の重要な空白を認識し、埋める。
- プロダクトマネジメントトライアングルの三つの融合領域の中で、直交している異なるインプットを融合させる。
これらに異論がある方はいないでしょう。
一方で、全ての領域を健全に機能させることは、極めて難しいのが現実ではないでしょうか。仮に全ての領域をカバーできたとしても、それが本当にROIが高いかたちになっているかどうかという問題も出てきます。
そこでまずは、自分が担当するプロダクトのトライアングルを構成する要素を洗い出し、その達成レベル (あるべき姿) の定義することを提案します。
事業フェーズや規模が異なるプロダクトにおいて、このトライアングルの構成要素や、それぞれに求められる達成レベルが異なることは想像に難くないと思います。
トライアングルのなかで、特に高い達成レベルが求められる領域 (言い換えるならばROIが高い重点領域) を、今回は「プロダクトマネジメントトライアングルの重心」と呼ぶことにします。
まずはあなたの担当するプロダクトのトライアングルの重心を定めることをスタートラインにしましょう。
事業フェーズや規模の違いを意識してトライアングルの重心を考える
事業フェーズや規模など、プロダクトの特性によってプロダクトマネジメントトライアングルの重心は異なります。
私が担当する「共通基盤」と「新規事業」を具体例として考えてみたいと思います。
表: 各プロダクトの特徴
A. 共通基盤 | B. 新規事業 | |
---|---|---|
影響範囲 | 広い (多くのプロダクトが依存) | 狭い |
ステークホルダー | 多い | 少ない |
意思決定 | 複雑・慎重 | スピーディー |
要求・要件 | 前提条件からしっかり構築が必要 | 状況に応じて変化 |
Return | B/S重視、持続可能性が重要 | P/L重視、不透明な部分もある |
上記の違いを踏まえて、それぞれトライアングルの重心を以下のように定義しました。
A. 共通基盤の場合
- 共通基盤という性質上、「開発者」側にトライアングルの重心がある
- さらにステークホルダーが多岐に渡る → それぞれのインプットを統合させる「融合領域」に重みを置く必要がある
B. 新規事業の場合
- 内部・外部環境の変化に合わせてゴールもプロダクト自身も変わる可能性があるため、「顧客」や「ビジネス」側に重心がある
- 少人数で対応するため満たせない空白領域ができやすい → 重心に近い「空白領域」から埋めることが先決
※ あくまで一例。共通基盤 / 新規事業だからといって、必ずしも上記のようなかたちになるわけではないことにご注意ください。
重心の決め方には、必ずしもプロダクトマネジメントトライアングルを用いる必要はありません。
例えば、「トレードオフスライダー」を使ってもいいでしょう。
目的とトレードオフを決め、ステークホルダーの合意を得る - highfive3’s diary
チームやステークホルダーをマッピングする
プロダクトマネジメントトライアングルの重心を定め、埋めるべき役割のあるべき姿がイメージできたら、いよいよプロダクト開発を担うチームメンバーやステークホルダー、そして自分自身がなにを担うべきかを決めるフェーズとなります。
大きな石理論に従って、トライアングルの重心に近く、かつ満たすことができない空白領域・融合領域が見つかったならば、まずはそれが最初に解決すべき課題です。
チームメンバーや自分自身のスキル・経験を元に、パズルのピースを埋めていきましょう。
具体例に戻って説明しましょう。
私が担当した2つのプロダクトにおいては以下のような特徴や課題がありました。チームの状況を踏まえて、自分自身の担う役割を決めて取り組みました。
A. 共通基盤の場合
- チーム内に、トライアングルの重心を担うメンバー(開発者)は揃っていた
- 一方で、ステークホルダー (関係するプロダクトのメンバーやCS/Opsなど) が多岐にわたるため、目線合わせが大変で、調整が難航しがちという課題が大きい状況であった
主な役割
- ステークホルダー、各プロダクト担当のプロダクトマネージャーと認識齟齬が発生しないように密な連携の実施 (融合領域の拡充)
- 共通認識化や合意形成のためのドキュメンテーションなどを担当し、重心領域を担当するエンジニアやステークホルダーをサポート
B. 新規事業の場合
- 少人数ながら、広い領域をカバー可能なチームメンバーが揃っていた
- 一方で、ドメイン知識については、事業責任者含めたBizDevと圧倒的な開きがある状態
- 事業の状況変化によって、ゴールが変わる = プロダクトのスコープや、プロダクトマネジメントの重心も変わる可能性があった
主な役割
- BizDevの要件定義・開発プロセスへの巻き込み (デザイナーとともに「顧客」「ビジネス」の役割を担ってもらい、重心に近い「空白領域」「融合領域」を補強)
- 自分自身の役割としては、残りの空白領域・融合領域の役割に徹することで、他の領域にヌケモレが発生しないことを担保
PDCAサイクルを回し続ける
PDCAサイクルの継続的な改善プロセスを通じて、環境変化に応じて自分の役割をアップデートすることが重要です。
チームやあなたの役割が決まったからといって、それが今後も保証され続けるわけではありません。トライアングルの重心や課題だと思っていたものが間違っている可能性もありますし、前提条件から変わることもあります。
例えば、以下のようなケースはどんなプロダクト (事業・組織) でもありえる話だと思います。
- 主要なチームメンバーが異動・退職した
- プロジェクトを進めている間に、ステークホルダー側の優先順位が変わってしまった(事業優先度の高い施策が差し込みできた)
- 事業がピボットしたため、プロダクトに対する要求・ゴールが当初から大きく変化した
また、上記とは逆にいい意味での変化もあると思います。
チームが成熟することで、一人ひとりが担う領域が広がることで、いままでプロダクトマネージャーとして担っていた役割を他のチームメンバーに担ってもらったほうがROIが高くなるケースも十分ありえます。
これらのような場合に、それまでと同じ役割を演じていても、プロダクト価値の最大化には繋がりません。重要なのは、状況を常にアップデートし、本質的な課題を特定し、それに対してアプローチを取り続けることです。
まとめ
今回は、新しいプロダクトを担当することになったプロダクトマネージャー(またはプロダクトマネジメントに従事する方々)が、自分自身がどんな役割を担うことでプロダクト価値の向上に貢献するのか、その役割を考えるステップを紹介しました。
これまで述べてきたとおり、ビジネス特性や事業フェーズ・規模、またプロダクトを担う組織やチームメンバーが異なると、プロダクトマネージャーの役割や立ち振る舞いは大きく変わります。
また、一度決めた役割も、前提や環境の変化に応じて変化させ続ける必要があります。
プロダクトマネジメントに「銀の弾丸」はありません。
各フェーズでの挑戦や役割は異なりますが、本質的な役割――すなわち、プロダクトの価値最大化に向けて、課題を問い続け、それに向き合い続ける姿勢には変わりはありません。
プロダクトを通して、世の中に価値を提供しようとする皆さんの一助になれば幸いです。