プロダクトマネージャー、1997年のベン・ホロウィッツが「良いプロダクトマネージャー、悪いプロダクトマネージャー」を書く

必須ではないが、ソフトウェア色の強い役割では役立つ。エンジニア出身のプロダクトマネージャーは多いが、デザイン、マーケティング、コンサルティング、カスタマーサポートから移ってくる人も少なくない。特定の学位よりも重要なのは、データを読み解き、明確に文章を書き、自分でコードを書かなくてもエンジニアと対等に議論できることだ。 肩書きは似ているが違う。プロジェクトマネージャーは、チーム全体のスケジュールを調整しながら作業が予定通り予算内で進んでいるかを追跡する。プロダクトマネージャーは、そもそも何を作るべきかとその理由を決め、根底にあるビジネスと顧客の論理を所有する。特に小規模な組織では両者の境界が実務上あいまいになることも多いが、それぞれが答える中心的な問いは異なる。

違う。プロダクトマネージャーがエンジニアやデザイナーなど誰かを直属の部下として持つことはほぼない――この仕事はしばしば「権限ではなく影響力で導く」役割だと説明される。プロダクトマネージャーは優先順位とその根拠を定めるが、実際の作業をどう進め誰が担当するかは通常エンジニアリングマネージャーやチームリーダーが決める。 国や企業によって大きく異なる。米国の大手テクノロジー企業では、ボーナスと株式を含めた総報酬が優に六桁ドル台(日本円で数千万円規模)に達することも珍しくない一方、インドやラテンアメリカの多くでは同等の役職でもその何分の一かにとどまる。株式を除く基本給だけで見れば、同じ会社のシニアエンジニアの給与に近い水準であることが多い。

データの要約、仕様書の初稿作成、顧客フィードバックの統合といった業務は、すでにAIツールによって高速化されている。自動化が難しいまま残るのは、そもそもどのアイデアに取り組む価値があるかを決めること、意見の異なる人々の間で妥協点を交渉すること、そして賭けが失敗したときに責任を負うことだ――これらはモデルに責任を負わせられない判断である。 「プロダクトオーナー」は1990年代にスクラムのフレームワークで定義された具体的な役割で、チームの作業バックログの優先順位付けを担当する。「プロダクトマネージャー」はより広範で歴史の長いビジネス上の肩書きで、戦略、市場調査、チーム横断の調整をカバーする。今日では両者を同義に使う企業も多いが、両方が併存する場合、プロダクトオーナーは通常プロダクトマネージャーの下、あるいはその隣で働く。