Product Managerをアーキタイプという切り口から考えてみる

今でもたまに、"Product Managerって何をする仕事なの"、と聞かれることがあるのだが、私はいつもちょっと回答に詰まってしまう。アメリカ西海岸の都市圏では、犬も歩けばProduct Managerにあたる状態なのだが、これだけProduct Managerの裾野が広がってくると、一つの言葉でその職務範囲や特徴を表すのが難しくなってくると私は思う。その際によく出てくるのがアーキタイプ、という議論だ。

（完全に正確な対比ではないのだが一つの比喩として言うならば）これはソフトウェアエンジニア、といってもその中には色々な種類があって、バックエンドなのかフロントエンドなのか、フルスタックなのか、はたまたMachine Learningエンジニアなのか、といった細分化が必要なのに少し似ている。Product Managerの場合はエンジニアよりもこうした細分化した定義が一般化していないこともあり、ここ5年くらいはアーキタイプを通じて、役割を再定義する議論を聞く機会が多いように思う（LinkedInなどを見ていてもアーキタイプ論に関する多数のPostが見つかるはずだ）。余り日本語媒体で議論されることがないポイントのようなので、本稿で大まかな議論を紹介しつつ、私見を述べてみたいと思う。

Product Managerのアーキタイプと活用する場合の利点

そもそもアーキタイプとはなにか。アーキタイプとは、何かの典型的な例やモデルのことである。Product Managementの文脈では、アーキタイプは、スキル、特性、それから仕事へのアプローチの仕方などによって特徴付けられる、Product Managerのロールモデルと言えるだろう。

Product Managerのアーキタイプを定義することにはいくつかの利点がある。Metaでも実際にアーキタイプを定義しているのだが、一般的に言われている利点及び私が実際に利点として感じるのは以下の通りである。

1. 採用に際して、採用側のニーズに合致したスキルと特性を持つ人材を特定し、採用しやすくなる

2. Product Managerの強みや弱みを議論し評価するための共通言語とフレームワークを提供することができる

3. Product Manager自身がどのスキルを伸ばすべきかなどキャリア面での指針や基準として利用することができる

4. Product Managerに対する期待について、協力するエンジニアやデザイナーなどのパートナーとの共通認識を作りやすくなる

例えば、ML/AI Domainで採用されたPMが、AIのある分野に深い見識のあるSpecialist PMとして採用されたのか、それともDomain知識は一定程度あるが新規顧客開発に真の強みを持つGrowth PM的な採用をされたのか、というのは結構重要なところで、このあたりの期待値のすり合わせがエンジニアやBiz Dev、デザイナーなどとできていないと結構悲劇的なシナリオに陥りがちだったりする。(このあたりの期待感のすれちがいはProduct Management組織を作り始めた会社などでは結構あるあるなのではなかろうか)

実際のアーキタイプ論

現実に役職として存在する(した)アーキタイプ

ここまで読んでくださった方の中には、このアーキタイプ論に懐疑的な方もいらっしゃるだろう。このような文章を書いているので当たり前かも知れないが、私はProduct Managerアーキタイプの穏健な支持者である。そして実際に、私が在籍するMetaも含め、いくつかの会社もアーキタイプ、乃至はそのようなものを公式なシステムとして導入している。

有名なところだとAmazon/AWSが挙げられる。Amazonには(少なくとも私が在籍していた当時は)三種類のProduct Managerが存在して、テクニカルな知識の有無や、テクニカルな顧客の要求を捌けるか(例えばAPIのスペックなど)といったところで違う職種になっていた。同じような話はGCPにも以前あって、Outbound PM vs. Inbound PMといったタイトルの違いが、少なくとも数年前まではあったように記憶している(今はなくなっている気がする)。

最近だと、LinkedInのタイトルに明確にData Product ManagerやAI/ML Product Managerなどと書いてあるものも散見される。アーキタイプ的なものが採用面でも少しずつ市民権を獲得しているように思われる。

アーキタイプの概念的な整理

前述の通りこれには余り通説的なものはないのだが、私が今までに見聞きしてきたことなどをベースに纏めると、大きく分けて(1) 業界やDomainに特化しているか否か、(2) 会社やProductのステージや特徴、(3) テクニカル寄りか否か、という三つの軸で考えられていることが多いように思う。(尚、前もって述べておくがこれら三つは相互に影響をもたらすことがあるので、綺麗な分類ではない)

業界やDomain特化というのは、よくSpecialist vs. Generalistという形で議論されることが多い。顧客や潜在顧客に対する深い理解が必要とされるProduct Managementという仕事の特性もあって、対象顧客の分野に対する深い理解が求められる場合がある。例えば、ML OPs的なProductを作るのであれば、ML Development Lifecycleに対する実際の経験や理解がないと、顧客に対するEmpathyを持つのは難しいだろう。一方で、一般消費者に訴求するようなProduct、例えばeCommerceであれば、自分も含めて一般に普及しているProductであることから、分野によっては、SpecialなDomain Knowledgeが必ずしも必要ということはないかもしれない。尚、PMとしての職位がICとして上がるほど、Specialistであることを求められる気がする。

会社やProductのステージや特性、というのは、例えば、スタートアップでPMFを見つけようとしているステージにおけるProductと、すでにかなりのスケールになったProductを扱うのでは要求される動き方が全然違ってくるはずである。前者はとにかく早い速度で仮説を回していくような動き方が求められるので、強いProduct Senseや不確実性への耐性のようなものが求められるかもしれない。後者はどちらかというとじっくりデータを分析して機会を見つけたり、内部の関係部署との調整に強いタイプが好まれるかもしれない。

テクニカル寄りか否か、というのは色々な要因に左右されるのだが、個人的にはお客様がテクニカルな職業（例えばエンジニアの人にAPIベースのサービスを売るなど）か否かというところが大きい。Product Managerたるもの、お客様と会話をすることは欠かせないわけだが、お客様とのテクニカルな議論をきちんと理解し、それをベースにProduct Vision/Strategyの策定などができるだけのテクニカルな理解があるか否か、というのはできる仕事の範囲を結構変えてしまうものである。

実際によく聞くアーキタイプ

と概念的なことだけを書いていてもしかたがないので、よく聞くアーキタイプをいくつか挙げてみたいと思う。イメージを掴んで頂ければ幸いである。

(1) 業界やドメイン特化型

AI/ML Product Manager: AIやMLというソフトウェア開発の中でも色々な意味で特殊な領域のドメイン知識を持つProduct Manager。MLやAIを利用したRecommendation Systemなど大規模なソフトウェア製品を担当する

Data Product Manager: データドリブンな製品を定義し、構築する責任を負うProduct Managerで、分析プラットフォーム、データ可視化ツールなどを担当することが多い

Platform Product Manager: いわゆるPlatform系の製品を扱うProduct Managerである。APIのマネジメントや物凄い数のFeature Requestsに対するPrioritizationについて深い知見が求められる。顧客がTechnicalな場合が多いので、そういった人たちにEmpathyを持てるようなバックグラウンドの人が多い気がする

(2) 会社やProductのステージや特性

Growth Product Manager: PMFしていたりしかけている会社において、さらなるユーザーの獲得やEngagementの上昇の獲得を主目的にする。因みにMetaのGrowth PM Teamはとても有名

Product Manager, New Product: 0 -> 1の新規事業や製品の立ち上げをするProduct Manager。Agileな環境でより早くPOC -> Customer Feedbackを回してくことが求められる

Product Manager, Enterprise: エンプラ向けの製品開発を担当する。大企業ほどSecurityやComplianceの要求が高いので、SalesやBiz Devなどと協力してエンプラセグメントに売れる製品を作る必要がある

(3) テクニカル寄りか否か

Technical Product Manager: テクニカルなお客様に対する商品設計をしたり、はたまた担当する製品が無茶苦茶テクニカルなものだったりする場合に、この"Technical"という単語がタイトルについたりする

どういった運用がよいのだろうか (私見)

ここからは先は完全に私見である。私は穏健なアーキタイプ支持者である。もう少し踏み込んだ言い方をすれば、採用や組織作りの際にアーキタイプを意識して採用活動をするべきであるが、Job codeやタイトルなどといった社内の人事制度と公式に紐づける形でのアーキタイプの導入には否定的な見方をしている。

これはJob codeやタイトルが給与と相関している会社が一定数(大部分そうかもしれない)存在するからである。例えばTechnicalなProduct Managerの給料はそうでないProduct Managerの給料よりもかなり高く設定されていたりする。そうなると会社のPriorityとは全く無関係に、給与を主要因とした人材の異動や採用速度の不均衡が起きる可能性がある。実際にそういった悲しい事例も過去に見てきた。

一方でアーキタイプを全く使わないとエンジニアやビジネスサイドとの期待値のすり合わせに苦労する。データ分析に強みのあるProduct ManagerをGrowthのロールで採用したのに、エンジニア側はAPIの設計の議論をリードできるような人を想定していた場合、これは悲劇である。そういった観点で、極めてInformalに、Product Managerのアーキタイプを採用やチーム作りの際に利用することは有用であると考えている。

結論として、Product Manager組織を作ろうとしている場合、アーキタイプという話にも少し思いを馳せてもよいのではないだろうか、と思うのである。