- ソフトウェア・プロダクト企業が product-led を「PMがすべての意思決定を行う構造」だと誤解すると、本来は例外的な創業者型リーダー向けのモデルを、平凡なキャリアPMに適用してしまうことになる
- 単一のリーダーにプロダクトの統制権を与える方式は、その仕組み自体よりも 誰に任せるか が核心であり、ビジョン・カリスマ・技術力・強い信念を持つ稀有な人物を前提としている
- 平凡なPMに過剰な権限が与えられると、データ、フレームワーク、承認プロセス、会議、役割体系が判断の道具ではなく、責任回避と政治 の防波堤になる
- この流れは優秀な人材を去らせ、会社は低リスクの課題と内部プロセスに閉じ込められ、ビジョンと才能 を失っていく
- 代案はPMという肩書中心の構造ではなく、各領域で 技術と品質に執着する人たち を1つのチームに束ね、プロダクト・ディスカバリー、観測可能性、エンジニアリング、デザイン、ビジネス、ドメイン知識を共に扱わせるやり方である
product-ledをPM独占構造だと誤解する問題
- 多くのソフトウェア・プロダクト企業では、ソフトウェア製品づくりの経験が豊富な人よりも、資金調達 と対象業界の理解に長けた人が創業することが多い
- こうした創業者は業界経験と人脈を土台に会社を始めるが、自らすべての意思決定を主導すると、ドメイン専門家としての確信が会社に害を及ぼすことがある
- 一部の創業者は、自分がリスクになり得ることを認め、意思決定を任せる相手を採用する
- このとき「サービス組織ではなくプロダクト企業になるべきであり、プロダクト企業は product-led だからPMが責任を持つべきだ」という誤解が生まれる
- ここでいう product-led は、PMがすべての意思決定を下すという意味ではない
- 反対意見が出ると、Amazon、Apple、Tesla のような優れた企業も1人に統制権を委ねている、という反論がよく持ち出される
- 優れた企業の多くが単一人物に統制権を任せているのは事実だが、すべての優れた企業が同じモデルを採用しているわけではない
単一意思決定者モデルの前提
- 会社の統制権を1人に与えるモデルは、誤ったやり方というより、誰に与えるか で成否が決まる
- Picasso、Jeff Bezos、Mozart、Steve Jobs、Nikola Tesla、Elon Musk、Robert Oppenheimer、Peter Thiel、Leonardo のような人物は、ビジョン、カリスマ、自信、回復力、卓越性によって大衆の崇拝を集める
- 彼らは代替現実を想像し、自分の仕事に完全に没入し、意志の力で大きな変化を生み出すタイプである
- こうした人物が実際にいるなら、単一統制権モデルは強力に機能し得る
例外的な人物は一般的なPMではない
- 偉大な人物たちは プロダクトマネージャー ではなかった
- 芸術家、数学者、発明家、科学者、CEOであり、複数の役割を同時に担っていた場合もあった
- 彼らは OKR、KPI、データ、他人の意見よりも、自らの ビジョンと技術 に執着していた
- 例外的な人物は、強い意見、大きな自我、自分なりのやり方、荒々しさ、凡庸さへの軽蔑を持っていることがある
- その特性ゆえに一般企業では雇いにくく、本人もたいていの会社では働きたがらない可能性が高い
- 偉大な人物を見つけ、邪魔せず、その強度に耐えられるなら、プロダクトと会社の統制権を任せることはできる
- 現実には、そういう人物を見つけるのは難しく、見つかったとしても一緒に働いてくれないかもしれず、会社側がその自我と強度に耐えられない可能性も高い
平凡なPMに偉大な人物向けの構造を適用するとき
- 最大の誤りは、例外的な人物 を必要とする運営モデルを、例外的な人物なしで導入することだ
- 会社が無理なく採用できるキャリアPMは、たいていその水準の人物ではないと批判される
- ビジネスの手先、フレームワーク原理主義者、主題専門家、企業のはしごを上った元制作者、指標中毒者、MBA出身者などと表現される
- product-led をPMがすべての意思決定を行うことだと理解し、キャリアPMを採用すると致命的になり得る
- こうしたPMはビジョン、カリスマ、専門性、強い信念、技術的能力に欠けるため、安全志向になり、政治的に振る舞う
- 自分の不足を自覚しているため、成果は自分のものにしつつ、責任は避けようとする行動が繰り返される
データとプロセスが防衛手段になる過程
- 第一段階は データ駆動の意思決定 の武器化である
- どんな主張にも裏づけとなるデータを見つけられることを認めず、データ上は自分の決定だけが合理的だと装う
- うまくいかなければ市場、データ品質、会社の不運のせいにし、自分の責任ではないと主張する
- 次の段階は、あらゆるものにフレームワークと役割を導入することだ
- 18段階のキャリアフレームワーク、四半期ごとの業績評価、PI planning、ADR、PRD、RACI、MOSCOW、OKR、KPI、DORA、SAFe などが登場する
- プロセスに従っていない、データ駆動ではない、文書が不足している、文書が最新ではない、といったことが非難の理由になる
- 組織には Director of KPIs、Deputy Director of Product Operations、Global Head of Digital Whiteboard Solutions のような役職が生まれる
- すべてに承認が必要になり、どのプロセスや領域も1人では完全に統制できなくなる
- 巨大な委員会では、誰でも「no」と言えるが、誰も完全な「yes」は出せない
- 会議も爆発的に増える
- ステータス報告、アラインメント会議、1:1、スタッフ会議、戦略議論、コンテキスト共有、リリースの go/no-go、プロジェクト報告などが増えていく
- 最後の段階は、よくない人を大量に採用することだ
- 脅威にならないかどうかを基準に採用し、卓越性の兆しは不採用の理由になる
- 理想の採用候補は、反対意見も品質への関心もなく、言われたことをそこそここなす万能型の人物になる
- PMの数は急増し、チームや領域ごとにPMの階層が生まれ、同じ行動が繰り返される
組織が失うもの
- 平凡な人が権限を握る流れが始まると、卓越した人 は最終的に去っていく
- 平凡な独裁者に追い出されるか、環境に耐えられず自ら去るかのどちらかである
- 仕事のスピードは止まり、何かを実行すること自体が苦痛で、大きなコミットメントであり、危険な試みになる
- 壮大なビジョンは非現実的なものとして扱われ、すぐに捨てられる
- 会社が行うことは、手の届きやすい果実と安全な選択肢に限定される
- 自分の技術にそれほど情熱がない人でさえ苦痛を感じて去り、残るほど鈍感な人たちは問題をさらに悪化させる
- 会社は最高の人材を失い、ビジョンを忘れ、内向きになり、無意味になっていく
- 最善でもいつかは死に、最悪の場合は情熱ある人を自分の仕事を嫌うゾンビに変える、中途半端な延命状態になる
代案は日常的に優れた人たちのチーム
- 例外的な人物を見つけて採用し、統制権を任せ、その強度に耐える以外にも、成功するプロダクト企業を作る方法はある
- 代案は 日常的に優れた人たち を採用することだ
- 各人が何らかの領域で優れていなければならない
- 自分の技術に執着し、品質に動機づけられていなければならない
- 互いの卓越する領域が最小限しか重ならないようにチームを組む
- 個人ごとの責任を細かく分割するより、彼らが好きな仕事を楽しんでできるようにし、その時間と技術を会社のために使ってもらう
- こうした人たちも、挑戦的で、頑固で、自我が強く、風変わりで、気まぐれなことがある
- 良い問題を与え、優れた仕事ができるようにすれば、会社の成功に完全にコミットする
リーダーとPMがいるべき場所
- リーダーを完全になくす必要はなく、チームリードを廃し、領域リードを対外・対内の調整役として置くこともできる
- 各領域に責任リーダーを置くなら、その役割には 偉大な人物に近い人 を据えるべきだ
- ビジョン、カリスマ、強度、情熱、極端な行動という面で、Jobs、Musk、Bezos に近い人が該当する
- 短期的に扱いやすく、指示によく従い、手間がかからない人を責任者にすると、前述の状況に陥る危険がある
- 伝統的な意味でのPMという役割には、うまく機能している会社の中では居場所がないと考える
- ただし、プロダクト・ディスカバリーやプロダクト観測可能性など、伝統的にPMに任されてきた領域に執着する人は必要である
- そうした人たちはPMという肩書を持っていたことがあるかもしれないが、それ自体は問題ではない
- 採用理由は肩書ではなく、執着と強みである
- 彼らを独立したPM職として置くのではなく、エンジニアリング、デザイン、パフォーマンス、ビジネス、ドメイン知識に執着する人たちと同じチームに配置する
PMだけの問題ではない
- ビジョン、カリスマ、情熱、技術的能力、意志力のない人が責任者になれば、同じ問題が起きる
- PMに焦点を当てたのは、ソフトウェア・プロダクト開発において product manager という肩書の人を責任者に据えようとする傾向があるためである
- 一部のPMは本当に例外的であり、どちらのモデルでも非常にうまくやれる
- しかし、そのようなPMが、異なる背景を持つ優れた人たちより必ず優れているとは限らない
- そうしたPMはごくわずかな少数であり、ほとんどのキャリアPMは、卓越性でリードできる水準には到底達していないと見る
1件のコメント
Hacker News の意見
今の会社には賢い人が多いものの、さまざまな理由でプロダクトマネージャーがおらず、その結果、プロダクトマネージャーがやるべき仕事がそのまま行われていない
顧客関係の維持、ユーザーインタビュー、潜在的な機能の発掘、リーダーシップ層の説得、リソース配分のための社内政治のようなことをやりたがるエンジニアはほとんどいない
前の会社ではプロダクトマネージャー3人のうち2人は無能で解雇されたが、1人は本当に優秀で、その人の一部の時間だけでも、今の会社が2年以上かけてやったことより多くのことを1年以内に成し遂げた
優れたプロダクトマネージャーが十分にいないという点には同意する。優れたプロダクトマネージャーになれる人の数は人口に線形に比例するが、ソフトウェア産業は指数関数的に爆発したため、実際に優秀なPMよりも100倍多いPMロールが必要になったのだと思う
技術的でもなかったので Jira チケットを管理することもなく、リーダーシップ対応は主にマネージャーたちが担っていた
そのプロダクトマネージャーたちは主に会議をし、リーダーシップ層と話し、エンジニアと話し、文書を書き、長引くスプリント計画会議を取り仕切っていたように思う
顧客・ユーザー・リソースの問題を扱うプロダクトマネージャーなら、はるかに価値があり得ると思う
「私たちはエンジニアリング優先の会社だ」と何度も聞かされたが、実際にはエンジニアリングチームが好き勝手に最新技術を追いかけていただけ、という意味だった
主要製品が3.5個、実質的には4.5個あるが、それぞれ別の技術スタックで作られており、レガシー要件のためにサポートしなければならない製品もさらに8個ほどある。製品間の標準化や相互運用性はなく、知識移転も行われないため、開発コストは天井知らずだ
今年だけで2回、勤続20年のエンジニアたちに、ある API は TLS 1.3 だけを使い、別のものは 1.x、さらに別のものは TLS すら要求しないことが、なぜ問題なのかを説明しなければならなかった
顧客は私たちを嫌っている。私の製品はマーケティング資料を先に書いておき、エンジニアたちに勝手に作らせたものだった。Oracle データを parquet に移す1つのステップを、3つの言語と2つの中間DB（MySQL と PG）で作っており、Redis まで入れようとしていたのを何とか止めた
幸い、2年前にプライベートエクイティが買収し、今では収益を上げられなければ終わりだという最後通告を受けている。20年続く会社が一度も利益を出したことのないコストセンターで、目標を達成できなくても、私たちが作ったソフトウェア設計の惨事が消えれば、宇宙は少し良くなる気がする
愚かなプロダクトマネージャーは、また別の業務台帳を追跡する擬似プロジェクトマネージャーになり、賢い人はビジネスを深く理解して昇進するか、去っていく
この役割は統治するのも難しい。時には他人の仕事で大きな功績を持っていき、時には何の功績も認められずキャリアが停滞する
この役割をエンジニアリング、エンジニアリング管理、一般管理に押し付けると、エンジニアリング能力が弱くなる。エンジニアを採用するならその能力を基準に選び、外部の人たちから守るべきだが、チームが対外的なやり取りまで処理しなければならないとなると、複合的な能力を持つ人を採ることになり、結局エンジニアリング面が希薄化する
プロダクトマネージャーの余力をあえてタイトにしておくと、高いレベルとビジョンに集中させ、深く入り込みすぎて無用なプロセスを作ったり機能を過剰に定義したりするのを避けさせる強制装置になり得る
10年以上にわたる低金利成長で膨らんだテック業界では、多くの人がただ出社しているだけで成功できたようなものだ
混乱した記事。 「PMの役割をなくすべきだ」と言いながらも、「PMがやっていた仕事を専任で担う人は依然として必要だが、PMとは呼ばず、単に普通に優秀な人と呼ぼう」と言っている
筆者はPMと嫌な経験をしたことがあり、MBAの話を見るとその痕跡がうかがえるので、赤ん坊まで風呂の水と一緒に捨てようとしているように見える
ビジネスの規模が大きくなると、役割の専門化が生まれ、必要になる。ひどいPMもいるし難しい仕事ではあるが、うちのチームのPMを失うなら本当にがっかりするだろう
私がPMと良い経験しかしていないだけかもしれないが、うちの会社のPMたちは、顧客が何を望んでいるか、製品が何を提供すべきかを把握し、エンジニアリングマネージャーと一緒に技術的に可能か、実装余力があるかをバランスよく調整している
エンジニアリングマネージャーが「このスケジュールでは絶対に無理だ」と言えば、PMはプロダクトのための代替案を見つけ出す
この記事は中間段階を飛ばして、ただ理由なく名前だけを変えようとしているように見える
チームがどの問題を優先すべきかは、いったい誰が決めると考えているのだろうか？ それこそがPMロールの中核的な責任だ
結局、その優先順位決定ができなかったPMと悪い経験をしたように見える
ただ、その人のせいで私が出席した会議の中で最も気まずい会議に入らなければならず、最初から最後まで1時間ずっと、製品をまったく理解していないことを上級管理職の前でさらけ出し、その上級管理職は製品を理解していた
良いPMたちは、顧客が望むこと、私たちが提供できること、現実的なスケジュール、法務やビジネス上のステークホルダー対応を理解していて、大いに助けてくれる。私は彼らが技術面を確認する必要があるときに手伝う
チームには、作るべきアイデアや製品・運用体験を改善する方法が不足していることはめったにない。プロダクトマネージャーは正しいものを作らせるための人だ
私はIT歴20年のPMで、知識と体系的なビジネス理解を得て、今後成長する助けになるようMBAを検討している
私に似たPMたちは、MBAを取った途端、軍隊式の表現を借りればくだらないゲームを始めたりはしない
問題は、高校、大学、MBA、管理職へと一直線に進んだ人たちだ。学部途中の短いインターンシップ程度を除けば、現場経験が1日もない場合が多い
奇妙な記事。多くの言葉を費やしているが、結局「成果の低い人を採用すると会社に有害だ」という話ではないかと思う
代案も「良い人を採用しろ、ただしPMロールとしては採用するな」というようなもの
自分をSteve Jobsだと思っているPMと悪い経験をした人が書いた記事のように読める。PMもただの普通の人なのに、その肩書きを持つ人が全員、特権意識のある人間だと仮定する理由がわからない
組織には何千人ものPMがいることもあり、それぞれ上司がいる。ただの奇妙な記事だ
「プロダクトマネージャーを採用するな、彼らは優秀な人ではないだろうから。代わりに優秀な人を採用しろ、それも1人ではなくチーム全体で！」という感じだ
毎日のように低パフォーマーを採用しているのに、なぜそうなるのかわからない。履歴書の山を持った訓練されていないチンパンジーのほうが、もっとましな的中率を出しそうだ
PMは非常に具体的なニーズを満たす。そのニーズは定量化しにくいが、良いPMがいないとすべてが崩れると言える
通常、ユーザーから何がうまくいき何がうまくいかないかの情報を集め、経営陣から会社運営に必要なことを聞き、業界リーダーから産業がどこへ向かっているのかを把握し、デザインと協働し、これらすべてを実際に作るべき機能へと精製する
また、エンジニアリングとともに何が実用的か、おおよそどれくらいかかるかを判断し、時間はかかるが価値の低い機能を取り除き、見積もりとチームの速度がある程度予測可能になるよう助ける
すでに1.5人分の仕事を説明したことになる。プロダクト組織をなくすと、これらすべての仕事がエンジニアリングチームに分散されるが、チームメンバー全員がその仕事をうまくできるわけではない
たとえバランスを取れたとしても、1人が辞めれば、採用で探してもいなかった見えない空白が生まれる
多くのチームが、機能不全のプロダクト組織で痛い目に遭ったように見える。そういう組織は顧客・業界・組織の側面と断絶しているか関心がないように見え、その代わりにモックアップを反復する会議に膨大な時間を費やし、デザイナーをマイクロマネジメントして優秀な人を去らせ、不要なプロダクト会議にエンジニアを縛り付ける
PMはチームと密接に働きながらロードマップを定義し、顧客とビジネスに最も大きな影響を与える仕事を優先順位付けする
PMがうまく仕事をすれば、エンジニアは次にどの問題を解くべきか、なぜ解くべきかを非常に明確に理解できるようになる
次に、プロジェクトについて上級経営陣とコミュニケーションするための組織内での格があるかも重要だ。この2つの属性を両方備えているなら、良い状態だ
テクノロジー業界で12年以上働いて学んだのは、役割とは組織の願望を表現する方法にすぎないということ
誰かにプロダクトとして考えてほしければPMのポジションを開き、チームリードがほしければエンジニアリングマネージャーのポジションを作る
肩書きは、仕事というRPGをさまざまな角度からプレイできるようにする架空の要素。結局、職場に持ち込むのは各自の才能と経験の固有の組み合わせ
こうした役割の境界をしばしば越える人もいて、それで問題ない。彼らにはアイデアがあり、自分だけの肩書きまで作り出せる
組織は、そういう人たちが成長し活躍できるようにしておくくらい賢くあるべき。PMとして成功できないとか、優れた仕事ができないという意味ではなく、たいていの組織は加わる人を深く知るための時間を十分に投資できないので、あらかじめ調理済みの役割を提供しているという意味
エンジニアもPMの役割を果たせるが、すべてをPMの視点で考えるわけではない。主たるアイデンティティがPMではなくエンジニアだから
役割の境界を越えるという文脈でもう一つ気づいたのは、たいていの場合、ある人の役割で最も価値のある部分は明示的に定義されていない責任だということ
説明は難しいが、人は記述したり定量化したりしにくい形で価値を提供することが多い
全体としてかなり厳しい見方だが、確かに当たっている部分もある。会社内にプロダクト組織ができると、筆者が描写したように、委員会、OKR、レビューサイクル、計画、大量の官僚主義へと流れがち
以前、顧客対応のセールスエンジニアリングの役割で、影響力によってプロダクトを非常にうまく導いていて、正式な統制権を持てるだろうと考え、ナイーブにもプロダクトマネージャーの仕事を引き受けた
実際に座ってみると、極度に制約された事務職で、自分にはまったく合わなかった。チケットとバックログの管理、意思決定ではなく調整、終わりのないPowerPointレポート作成がほとんどで、最も創造的な仕事は、会社がプロダクトロードマップを公式化するためのプロセスを作ることだった。6か月で逃げ出した
この機能は、何が作られているのかの可視性を与え、成長するプロダクトの衝突する優先順位を管理するうえではかなり有用。ただし、プロダクトの進化の方向を形作ったり、制御したりする仕事ではない
並べ替え、フィルタリング、運がよければデータ収集の機能であり、監査可能な意思決定の痕跡と、成熟した意思決定という印象を作って、上のMBAたちが少し安眠できるようにする役割
通常、月に新機能の提案書（PRD）を4〜12本作っていて、会社の規模や必要なプロセスの量によって数は違った
形式はいつも「ユーザーには現在Xという問題があり、それを解決するためにYを作るべきだ。Yはこういうものだ……」だった
もちろん調整やコミュニケーションの難しさはあるが、常に次に何を作るかを見極めるためのものだった
すべてのPMの役割がこうではないのは理解しているが、PMが「整列／フィルタリング／意思決定成熟度の芝居」以上に良くなり得ないという話には同意しない
単に既存バックログの順序を決める役割だったのなら、バックログに新しく入れる項目は誰が定義していたのかが気になる
プロダクト組織が支援者ではなく、政治的・官僚的な実体になり得るという点には同意する
個人的には、プロダクトの役割はエンジニアリングチーム内に組み込まれ、同じリーダーにレポートすべきだと思う。レベルは議論の余地があるが、そうすれば悪いPMも悪いエンジニアと同じように扱える
もちろん、会社が悪いエンジニアも手放せないなら、それは別の問題
筆者はこれについてのフレームワークをあまり提示していない
この記事の解決策には偉人理論のにおいがする
「すごい人たちは別の現実を想像し、仕事に完全に献身し、意志力で山を動かす」という最後の部分は、あまりに還元的
山を動かすのは意志力ではなく、実際にビジョンを実装する現場の人たち。せいぜいその「偉大な人」は、実行者や専門家が動くようにインセンティブを揃える程度
現在、PMの役割をほとんど置かない大手テクノロジー企業で働いているので、直接の感覚を言える
今のところは一長一短。PMが多い組織でも働いたことがあり、そういう組織があまり良くないという点には同意する。ただ結局、PMがやるべき仕事は依然として必要
私たちの組織では、その責任は公式にはソフトウェアマネージャーとシニア以上の開発者に降ってくる
例えばシニアエンジニアとしてチームのイニシアチブをリードすると、PMがやっていたすべての活動に責任を持たなければならない。他の活動はマネージャーやシニアマネージャーが担う
開発者の立場ではかなり大変。個人貢献者として自分の仕事もやり遂げなければならない一方で、他の人を調整し、仕事が完了するよう保証しなければならない
追加業務であるだけでなく、正直、多くの開発者は効果的なPMになるためのスキルを持っていない。レポートラインが異なる人たちを調整しなければならないので、チーム間コラボレーションも難しくなる
このやり方は、しばしば所有権の不足、説明責任の不足、重複した努力、隙間に落ちる仕事、全体的な無秩序につながる
ただし、数人が参加する小さなチーム内イニシアチブにはうまく機能する。PMのオーバーヘッドをなくし、作る人たちにコントロールを与えるから。ただ、より大きなイニシアチブにも合うのかは確信が持てない
多くの開発者に効果的なPMスキルがないというのは正しいが、公平に言えば、多くのPMにも効果的なPMスキルはない
レポートラインが異なる人たちと調整しなければならない難しさは、PMにとっても同じ
核心的な違いは「この仕事を専任の役割として切り出す価値があるか」という判断だと思う。私は、エンジニアにとってはほとんど常にその価値はないと見るほう
タイトルだけを見て、嫌いになる準備をしていた。典型的な「PMは愚かで、会社には世界を支配する賢いエンジニアだけがいればいい」という記事だと思った
しかし、そういう記事ではなく、問題そのものはほぼ完璧に突いていると思う
ただし解決策は、手を振るように消えてしまう。「それぞれが何かに秀で、自分の技術にこだわり、品質によって動かされる、普通に偉大な人たちを雇ってチームにまとめ、個人責任なしで働かせろ」というようなものだ
聞こえはいいが、実際に100人以上の会社でこのやり方が成功した例を誰が挙げられるだろうか。現実でどう機能し得るのか分からない
Valveは非常によく似たやり方をしている、あるいは少なくともしていたように思う。従業員ハンドブック[0]は昔HNでよく見かけたが、最近はあまり見ない。彼らにとってうまく機能しているのか気になる
[0] https://steamcdn-a.akamaihd.net/apps/valve/Valve_NewEmployee...
筆者は本当に平凡なプロダクトマネージャーたちと仕事をしてきたのだろう。私は独学のエンジニアリング背景を持つPMで、さまざまな分野で平凡な人をたくさん見てきた
自分の仕事は主にリスク管理だと考えている。優れたエンジニアとデザイナーのチームであっても、良いプロダクトをリリースする過程では多くのリスクに直面する
ビジョンを説明して他者を説得するスキルがないかもしれないし、法務チームができること・できないことに要件や制限を課すかもしれない
私の仕事はそうしたものを管理してチームの強みを引き出し、チームが本当に重要な仕事である、良いプロダクトを作ってリリースすることに集中できるよう助けることだ
成功は、自分がどれだけ不要になったかで判断する。目標は私が必要なくなること、チームが私なしでも良い判断を下せる文脈・自信・支援を備えることだ
エンジニアたちがそうした能力を身につけるよう一緒に働くのが好きだし、エンジニアリングマネージャーのパートナーたちと各エンジニアの強み・弱み・目標を理解し、成長の方法を見つけている
理想的なユートピアでは私が必要ないかもしれない、という主張も理解できる。だがほとんどの場合、本当に優れた仕事をするには課題やリスクにぶつかるもので、良いPMはチームと協力してそれを乗り越えさせる純価値の追加者だ
チームが最高の仕事をするために必要な文脈、要件、洞察、指標、目標などを備え、どの問題を誰のために、なぜ解くべきなのかを理解できるようにすることだ
良いPMは、エンジニアが「PMは何もしていないから必要ない」と思うほど環境をうまく整える。そうした判断は近視眼的で、率直に言って侮辱的だ