プロダクトは増え、プロダクトマネージャーは減っている
(kitemaker.co)- プロダクトチームにどれだけのPMを置くべきかという議論は、Airbnbのプロダクトマネジメント組織再編や、PMなしで成長するスタートアップの事例以降、より大きくなっている
- PMが増えるほど、プロダクトの事業成果よりもプロジェクト管理やロードマップ更新に時間を使う構造が生まれる可能性がある
- 熟練したデザイナーとエンジニアがいるチームでは、PM業務が必ずしもフルタイムである必要はなく、チームごとにPMを1人置くモデルも状況に応じて再検討すべきである
- 最初のPM採用は、創業者がすべての主要なプロダクト判断に関与するのが難しくなる時点、概ね50〜100人規模かつプロダクトチーム3〜5チーム程度で検討される
- PMの数を増やすだけではプロダクト中心の組織にはならず、むしろデザイナーやエンジニアが持つべきプロダクト責任を弱める可能性がある
PMを減らし、プロダクト責任を広げる構造
- PMの必要人数をめぐる議論は、Airbnbのプロダクトマネジメント組織再編や、PMなしでも成長するスタートアップ事例を扱った記事以降、より活発になっている
- 多くの企業では、PMはプロダクトをビジネスに最適化するよりも、プロジェクト管理やロードマップ更新のような業務で1日が埋まってしまうことが多い
- 一般的には、プロダクトチーム数よりPM数のほうが少ないべきであり、すべてのチームにPMを1人ずつ置く構造は、プロダクトやチームの状況に応じて見直す必要がある
- プロダクト業務が多く、チームがジュニア中心なら、1チームに専任PMが必要な場合がある
- 経験豊富なエンジニアやデザイナーがいるチームでは、PMの役割がフルタイムである必要はない、あるいはそうあるべきではない場合もある
- スタートアップで最初のPMを採用する適切な時期は、創業者がすべての重要なプロダクト判断に関与するのが難しくなる時である
- おおむね組織規模が50〜100人、プロダクトチームが3〜5チームのときが目安である
- 全体のプロダクト戦略がすでに明確であるべきで、PMはその戦略を土台に、より下位レベルの方向性や意思決定に関与すべきである
- 最初のPMは、ジュニアPMやCPOよりもシニアPMが適している
- 候補者が組織の成長に伴ってCPOの役割を担うことはあり得るが、創業者は事実上のプロダクト責任者としての役割を引き続き果たすべきである
プロダクト中心のチームを作る実践方法
- プロダクト責任はPM一人に集中すべきではなく、デザインとエンジニアリングもユーザーとプロダクトの文脈を直接理解する必要がある
- デザイナーとエンジニアは、プロダクト形成に積極的に参加し、細部のプロダクト議論を主導すべきである
- PMはUX、ワイヤーフレーム、進捗追跡、スタンドアップ運営、PRD/仕様の単独作成者になってはならない
- PMの焦点は、プロダクトビジョンの表現、正しい問題の選定、プロダクトの方向性維持、ビジネス要件との整合にある
- Michael Seibelの「Guide to product development」は、Social Camでこのやり方を実装した事例につながる
- チームは文脈と判断根拠を積極的に共有すべきである
- デザインとエンジニアリングもユーザーフィードバックにアクセスできるべきである
- 問題解決はPM中心ではなく、プロダクト、デザイン、エンジニアリングの協業であるべきである
- プロダクト志向のチームを作るための実践方法は4つに整理できる
- 一緒に始める: チケットや仕様を書く前、解決策を決める前に、デザイン・エンジニアリング・プロダクト/創業者が一緒に議論し、進め方と計画を揃える
- 全員をユーザーに触れさせる: ユーザーリサーチやユーザビリティテストに直接参加したり、動画ストリーミングやLookbackのようなツールで、ユーザーがプロダクトを使う様子を見られるようにする
- チーム管理のやり方に注意する: クローズしたチケット数やストーリーポイントで成果を測ると、チームは良いプロダクトではなくチケット処理に合わせて動くようになる
- PMツールを使わない: ユーザーフィードバック、インサイト、データ、仕様、ロードマップが別個のPMツールに閉じ込められると、チーム全体がプロダクトの文脈にアクセスしにくくなる
- プロダクト開発は本質的に予測が難しく、リリースそのものよりも、ビジネスに影響を与える正しいものをリリースすることのほうが重要である
- 大規模なプロダクト中心企業ではPMは非常に重要だが、必要なPM数は過大評価されやすく、PM数の増加がそのままプロダクトへの集中度向上につながるわけではない
1件のコメント
Hacker News の意見
エンジニアリングマネージャーや機能別組織の責任者としてプロダクトマネージャーたちとかなり長く働いてきたし、中堅テック企業で社内プロダクトの臨時PM役を務めたこともある
プロダクトマネジメントは、会社が行う仕事の中でも最も重要な領域の一つだと思う。だが仕事は本当に難しく、能力が足りないPMほどそこから離れて、エンジニアリングチームを「主導する」という名目のマイクロマネジメントや社内政治に流れがちだ
エンジニアリング組織とプロダクト組織が別々の指揮系統に分かれている組織では、この問題を扱うのが難しく、上にエスカレーションしても、そちらの帯域は自然と非常に限られる。EMの立場では、こうしたPMが最高のエンジニアたちを苦しめ、最終的に彼らが辞めてしまうことがよく起きる
今のところは、各チームにミニCEO型のPMを置き、技術的に十分でなければミニCTOとペアにするやり方が最善だと思う。政治が入り込む余地がずっと減り、チームワークの余地がずっと大きくなる
自分がいた最も成功したチームには専任のプロダクト職はなく、すべての意思決定は開発者たちがしていた
今は、開発者たちが落ち着いて作れるように、非技術職や中途半端に技術的な人たちでさえ開発者の進路からどかすのが最善だと思う
自分に見えるのは、人々が自分の選択肢を主張し、支持を得ようとする姿だ。人々が不満を言うような政治を見たことがない。自分が運がいいだけかもしれない
政治というのは、技術的には間違っているが、より説得力をもって主張する人のことを指すのか？「政治」とは何なのか？それとも、senior principalであっても自分の職位がまだ十分に高くないのか
この記事とこのテーマを分析しようとする多くの人が、重要な要素を一つ見落としている。それはインセンティブだ
多くの開発者は、技術そのもの、つまりコーディング、複雑な技術問題の解決、効率的な解法作りにより情熱を持っている。昇進、ボーナス、評価といった公式な報酬も、技術的成果と結び付いていることが多い
開発者が顧客調査に40時間を使っても、チーム全体の役に立つ新しい認証ソリューションを開発する技術的成果ほどには、公式に認められたり報酬を得られたりしないかもしれない
この力学を変えるには、開発者にプロダクトマネジメントの時間をもっと使うよう勧める程度では足りない。組織が何に価値を置き、どのように報いるのかについてのシステム的な変化が必要だ
インセンティブ構造を技術中心からユーザー中心へ変えると、中間・上級管理職の役割に大きな影響が出る。そうした変化は彼らの役割と責任の基盤を揺るがし、支配力と影響力の喪失につながり得る
だからこうした変化は、中間・上級管理職からの目立たないが強い抵抗を受ける可能性が高い。彼らは組織内でかなりの政治的な力と既得権を持っていることが多い
あらゆる職人的な仕事は、実際に触れる瞬間に学びがある。映画監督は編集室で映画を千回見ることができるが、実際の観客と初めて一緒に見る一回は、その千時間より多くを教えてくれる
大工は一週間ずっと家具を作って満足できるかもしれないが、本当の瞬間はその家具が顧客の部屋に置かれるときに訪れる。ソフトウェアも同じだ
ソフトウェアエンジニアにユーザーを気にかけさせるには、何がうまくいき、何がひどいのかについて直接フィードバックを受ける必要があり、できれば自分の目で見るべきだ
まともなソフトウェアエンジニアなら、仕事をうまくやり遂げることにある程度の誇りを持っている。その誇りがコード、コミット履歴、その他の抽象的な概念だけに結び付いていて、実際のユーザーのためにどれだけうまく使われているかにはまったく触れないのなら、そもそもどうやって関心を持ち始めるのか
記事とはほとんど関係ないが、ブログ記事のアイキャッチ画像にAI画像を使う最近の流れには本当にうんざりする
記事を書くときに明確なアイキャッチ画像が思い浮かばなかったのなら、コンピュータの妄想をダウンロードさせてこちらの帯域を無駄にしないでほしい
AI画像は非常に価値あるツールなので、自分は賛成寄りだ。だがページ唯一の画像としてAI画像を使うなら、本当にそうするだけの理由があるべきで、単なるスペース埋めであってはならない
特に、生成された画像内の全員の指の本数すらきちんとキュレーションできていないならなおさらだ
画像の目的はある種の雰囲気を伝えることだ。記事の抽象的な概念を、もう少し触れられるものにするためだ
以前はその目的に合う画像をインターネットで探して使っていた。今はDALL-Eで自分で作れるし、たいていはその方がずっと良い
この画像は記事を補完すべきだ。記事のテキストが情報、雰囲気、概念を伝えようとするのと同じように、画像もその一部を担うべきだ
主要な人種集団を全部入れた人々が円形に並び、互いに奇妙に笑い合う、不気味の谷めいた絵など誰も見たくない
こうした奇妙で魂のない企業風イラストの流行は、AI生成が爆発的に人気になる前から始まっていた
おそらく検索エンジン最適化についての何らかの信念のせいかもしれない
同時に見栄えが良くなければならないだけだ
ただ、ここには少し笑える面がある。ブログテンプレートが画像領域を要求するので、何も考えずに何かで埋める。それが難しすぎると味気ないストック写真を探し、それすら難しければ、わざと味気ないストック写真を生成する
インスピレーションもセンスもないAIゴミが、まもなくすべてを覆い尽くしそうだ
PMの問題の大半は、現場に足を運んで動く仕事をしていないことにある。優れたPMは、エンジニアリングとユーザーの間のギャップをつなぎ続けなければならない
このフィードバックループを繰り返さなければならない
しかし大半は、ドキュメントの世界だけで仕事ができると思い、ロードマップ文書を量産し、終わりのないチェックインと小言でステークホルダーの足並みをそろえ続けようとする。結局「プロジェクトマネージャー」の仕事をしていることになる
要件収集、バグに怒ったユーザーへの対応、週次ステータス会議、優先順位に関する悪い知らせの伝達まで、すべてシニア開発者かテックリードを送り込んでいた。忙しい人だからと言って、アジャイルの儀式の大半も省略した。JIRAチケットを書いたり直したりしたこともなく、それは技術組織が管理する仕事だと言っていた。他の2つの技術チームでも同じようにPMをしていた
テックリードとシニア開発者たちは最初の週からそのPMが良くないと分かっていたが、彼は私たち全員より長く残り、4年後にようやく人員削減で去った
アジャイル崇拝に陥った管理層はこうした人々に簡単に魅了され、組織を何年も脱線させることがある。理論上、PMのステークホルダーはユーザーだが、実際には自分を雇った上級経営陣の自尊心を磨く仕事になっている
上級経営陣、アジャイルコンサルタント、PMの間に、自己強化的な閉ループが生まれ得る
どちらの場合も競争力のないプロダクトで、たいていは停止されるまでそのまま残る可能性が高い。それでも会社はPMやPOを置き、SCRUM風の体制を作り、まるで革命的なプロダクトを作っているかのように振る舞う。緊急対応や成果へのプレッシャーまで含めて
こうした環境では、PMやPOが良いプロダクトや使えるプロダクトにはほとんど関心を持たず、社内の昇進階段を上るための政治に没頭することが多かった
彼らは機能や改善の面でランダムウォークのように見える断片化したプロダクトを作るとしても、自分が経営陣や顧客に良く見える方向へプロジェクトを持っていく
60年代、70年代、80年代にどう作っていたのかを知るほど年を取ってはいないが、SCRUM/PM/POはなかったように思う。過去数十年と比べて生産性が大きく鈍化し、今日ではおおむね過去に作ったものに寄りかかっているという悲観的な議論は、私の認識とかなりよく合っている
最近は他のPMたちをメンタリングしている。広く共有されるロードマップもあるが、私以外は誰も見返さないドキュメントやスプレッドシートが本当に大量に作られている。仕事をしていることを示すために作っているように感じ、その習慣を断ち切ろうとしている
技術プロダクト管理を強く支持する理由は、問題を単純化して見れば、一部のPMが高い抽象度に閉じ込められているからだと考えているためだ。毎日チームと細かな技術事項を話せないので、結局プロジェクト管理とプロダクト管理の間にある奇妙なグレーゾーンにとどまることになる
それ自体は構わないが、プロダクト決定をしたがるHIPPO症候群があると、ほとんどの時間を後方防衛と上方向けのマネジメントに使うことになる
PMはよく叩かれ、ときにはそれも正当だが、結局は物事を前に進めるために社内政治をしなければならないことが多い
優れたPMはビジョンや計画を作るだけでなく、実行と反復もリードする。計画は全体の**20%**だ
一緒に働いた中で最高のプロダクトマネージャーは、ただ非常に優秀な人で、実装の複雑さを理解しつつ、必要なら自分でやり遂げる可能性まであり、同時にビジネス上のニーズも理解していた
エンジニアリングマネージャーではないが、会社に価値を加える人だった
残念ながら、プロダクトマネージャーの大半は、その席に座っているだけの人だ。功績であれ責任であれ持っていく門番であり、自分自身の利害はほとんど懸かっていない場合が多い
全般的に、プロダクト管理組織が別にあるなら、それはやり方を間違えているのだと思う
私が参加した最高で最も成功したプロダクトは、すべて実際の実装者たちがプロダクトのオーナーシップを持っていた。エンジニア、デザイナー、カスタマーサクセスチームのような人たちだ
エンジニアとしてサポート当番に入るのが好きだった。自分の作業と、それを毎秒使っている実際の人々との間にある抽象化のギャップを埋めてくれたからだ
ごくまれに純価値を加えるPMと働いたこともあるが、そういう場合はいずれも、その人たちはまともなエンジニアにもなれたであろう人たちだった
主な理由は、PM、またはチーム内でその役割を担う人が同じエンジニアリング管理体系に報告する場合、すべてが結局エンジニアリングのニーズ側に傾くからだ
ビジネスを前進させる可能性が高い、本当に必要な機能開発であっても、技術的負債やインフラ作業が常に何らかの形で人々を妨げているという理由で、結局優先順位から押し出される。時にはそれが実際に正しい選択であることもあるが、そうした判断をするには、対等な立場を持つ2つの組織の間の緊張関係が必要だ。エンジニアリングの一部になると、それはうまく起きにくい
もちろん、私たちの業界の悲しい現実は、別個のPM組織が「ビジネスにとって良いこと」を所有するという理由で、エンジニアリング組織よりも大きな権限を持つようになる点だ。そこに、手順やフレームワークには従えるが、自分のプロダクトやユーザーを実際には理解していないPMたちが加わると、悪夢になる
私は比率で考えている
フロントエンドエンジニアとバックエンドエンジニアの比率はどれくらいか？ エンジニアリングマネージャーと個人貢献者の比率は？ テクニカルライターとエンジニア全体の比率は？ プロダクトマネージャーとエンジニア全体の比率は？
そしてこの比率を精緻に調整し、影響を最大化しつつ、干渉とマイクロマネジメントを最小化しようとしている
この比率の実際の数値は組織ごとに異なるだろうが、干渉が感じられたり、「どうやるか」がエンジニア自身から十分に出てこないなら、比率を変えるべきだ
ピープルマネージャーやプロダクトマネージャー1人あたりのエンジニア数を増やし、彼らがこのように口出しできないようにし、関与すべきことに優先順位を付けさせ、ミクロな領域から退いてエンジニアに手段の自律性を返すべきだ
QA、ジュニアエンジニア、シニアエンジニア、アーキテクト、人事担当者、VP、営業担当者についても同じだ
20年以上プロダクトマネジメントをしてきて、ここで述べられていることの大半に同意する。比率は重要だ
CPOはPMの軍団を抱えて帝国を作りがちだ。組織は、PMたちが単一ページのような顧客体験の一部の断片を所有し、ボタンのクリック率を最適化するが、プロダクト戦略やビジョンには意味のある貢献をしない状態になる
プロダクトを所有していないのにプロダクトマネージャーでいるのは難しい
PMは今よりずっとビジネス目標に集中すべきだ。ユーザーの問題を解決することは必要だが、それだけでは十分ではない。その問題解決が会社の価値にもつながらなければならない
これを可能にするには、プロダクト感覚の強いエンジニアリングとUXのパートナーが不可欠だ
さらに悪いことに、「簡単に置き換え可能な」開発者たちは外注会社から来る。こうして開発を顧客からさらに多くの管理階層で隔離しなければならなくなる
GDPを増やす素晴らしい方法だ
例えばERP、Oracle Fusion Apps、WorkDay、SAPのようなものを扱うなら、PM1人がプロダクト全体を所有することはできない。代わりに複数の機能を担当することになり、各機能自体が複雑で、ERPの性質上、他のさまざまなプロダクトとの統合もたいてい含まれる
それでもPMが意味のある何かを所有すべきだという大きな方向性には同意する
開発者であり開発マネージャーとして、一緒に働いた最高のプロダクトマネージャーたちは「どうやるか」にはほとんど関与しなかった
もちろんバックログにエピックレベルのチケットを作ることはできるが、それより下の段階では、あなたとプロジェクト担当者たちが仕事を終えられると信頼している
問題は、組織がそれを支援しなければならない点だ。多くの会社で最も注目を集める仕事は、ビジョンや成長中心のものではなく、最も声の大きいものだ
そしてそうした仕事は、プロダクト責任者やマネージャーが望む方向と直接衝突することが多い
「どうやるか」を理解していないPM、つまり自分のプロダクトがどう動くのかを知らないPMが最悪だ
一緒に働いた最高のPMたちは技術的背景を持っていた
人々が他人の領域を踏もうとすると、常に破滅的な結果になる。双方向にそうだ。エンジニアは「どうやるか？」の観点で考えすぎるため「なぜ？」と「何を？」が苦手で、プロダクトマネージャーも「何を？」や「なぜ？」を明確にするための場合でなければ、「どうやるか？」から退くべきだ
バランスが必要だ。PM/POにも基本的な理解は必要だ。コンピューターを使うのもやっとという人であってはならない
優秀なPMでも、周囲に平凡なPMが多すぎると、かなり縛られることがある
複数のFortune 500企業と仕事をし、壊れた文化を数多く見てきた
そういう場所では、PMは自分にある唯一の道具である会議で大半の問題を解決する。昇進インセンティブは、会議が大きいほど重要な人物に見えるようになっている
何百時間ものクロスファンクショナルチーム会議に参加したが、実際に仕事をしている人は1〜2人で、たいていPMがずっと話し、10〜20人はミュートのままで、最後に自分の存在を証明するかのように承認だけする
結果としてエンジニアチームは意欲を失い、実際の技術作業をする時間がなくなり、コードの調査や理解もないまま、その場で見積もりや約束を求められる
PMが数字や「ポイント」が気に入らないという理由で技術設計を却下し、エンジニアたちが正体不明のPM美学を満たすために、同じアイデアを別の「チケット」として再フォーマットしなければならなかったことも見た
理解不足と無意味なステータス誇示の儀式のために、プロジェクト全体が遅延し、脱線する
逆に、優れたPMと働いたこともある。そういう人たちはチームをこの手のくだらないことから守り、正しい目標に集中させてくれた。そういう人たちは貴重であり、前者の人たちはそれと同じくらい有害だ
PMの人数とは別に、私が一緒に働きたいPMのタイプについての話
業界で4社に勤め、40人未満のスタートアップからJP Morgan Chaseまで経験した
「技術系」の人が「非技術系」の人より賢いという考え方は否定する。実際、エンジニアである私は細部に入り込みすぎて大局を見失うことが多く、PMに引き戻してもらう必要がよくある
ただし私の経験上、エンジニアとして最も一緒に働きやすいPMは、コードに実際に少しでも触れたことがある人だ
大した経験である必要はない。昔HTMLとCSSでWebサイトを作ってみたことがある、臨時のSQLクエリを書いたことがある、大学院の課程でPythonの授業を受けた、という程度で十分だ
PMが、コードを書くことは厳密な科学でも完全な魔法でもないと理解できる何かがあればよい
こうしたPMは、一緒に働くエンジニアを擁護したり、少なくともビジネス上の要求とエンジニアリング上の現実とのバランスを取ろうとする
技術への接点がまったくないままPMになった人は、より「ビジネス志向」になりがちで、ある時点のビジネスにはまさにそれが必要な場合もあるが、常にそうとは限らない。エンジニアとしては、自分の視点もよりよく理解してくれる人と働きたい
別にまったく根に持っているわけではない :p