「プロダクトマネージャーのしごと 第2版 ―1日目から使える実践ガイド」を読んで、そのメモ


読書記録です。「プロダクトマネージャーのしごと 第2版 ―1日目から使える実践ガイド」をななめ読みして、そのメモ。


[プロダクトマネージャーのしごと（第2版） 1日目から使える実践ガイド | Ohmsha](https://www.ohmsha.co.jp/book/9784814400430/)
[楽天ブックス: プロダクトマネージャーのしごと 第2版 - 1日目から使える実践ガイド - Matt LeMay - 9784814400430 : 本](https://books.rakuten.co.jp/rb/17581217/)

![](https://m.media-amazon.com/images/I/41P6RbH+s6L._SY445_SX342_.jpg)


内容紹介（出版社より）
> プロダクトマネジメントは、小さなスタートアップから大企業まで、現代の組織にとって重要な役割です。プロダクトマネージャーは、人々が愛する製品を作るとともに、チームに目的と方向性を示して共に働くファシリテーターでもあります。

役割分担難しいですよね。以下も参考:
[プロダクト開発におけるエンジニアリングマネージャー（EM）とテックリード（TL）とPMの役割分担｜みね＠PRONI](https://note.com/mine_unilabo/n/nab0d71933f35)


## キーフレーズと感想 (目次順)
### １章　プロダクトマネジメントの実践
- プロダクトマネジメントを知りたければ、何か1つ「正しく」定義するだけではダメで、そもそも定義が不可能だということを理解しなければいけない
- ボスではない / 実際にプロダクトを作るのはあなた自身ではない / 誰かがやるべきことを言ってくれるまで待てない
### ２章　プロダクトマネジメントのＣＯＲＥスキル
- What, exactly, is a Product Manager? https://mtp2017.wpenginepowered.com/what-exactly-is-a-product-manager/
- エンジニアの尊敬を集めるにはハードスキルが必要？→ エンジニアは自分たちと同じスキルセットを持つ人しか尊敬しないという考えだが、エンジニアに対する侮辱である (その後実装の詳細までマイクロマネジメントして敬遠されるようになったのを見たことすらあるとの話)
### ３章　好奇心をあらわにする
- 「なぜ」と聞く代わりに、ちょっと角度を変えて「やり方を見せてもらえますか？」と聞くのが有効。たとえば「なんでこんなのを作ったんですか？」とは対照的に、「いい感じですね！ チームがどうやってそんなアイデアを思いついたのか教えてくれますか？」等。
- 質問をする側を調査官ではなく生徒の立場にする。質問された側にとっても、真摯でよく考えられた回答をするための余裕が増えます。「参ったな、正直言って、どうやって思いついたかなんて特にないんです」とか、「自分たちが思いついたわけではありません。上司がなんとなくくれたんです」などと広がる。
### ４章　過剰コミュニケーションの技術
- 「このアプローチにコミットする人は『いいね』してください」のようにすばやくチェックをするのが有効。反応を返してくれる人が1人か2人しかいなくても、議論を掘り下げられるかもしれないし、反対意見であっても歓迎し真剣に議論するのだと示せる。
- チームがコミュニケーションに使う時間を過小評価しないようにする。時間をうまく使えばよいだけ。
### ５章　シニアステークホルダーと働く（ポーカーゲームをする）
- 「この機能が私たちの成功につながることにワクワクしています。考えていることを理解できるように助けてもらえないでしょうか？ そうすれば、これまでの成功を続けながら確実にこれを実行できます」といったことを伝える。
- シニアステークホルダーと働くときは、「勝つ」ことを目的にしないこと。その人たちが素晴らしい意思決定を下せるように支援し、あなたが価値ある協力的な思考パートナーであることを示す。
### ６章　ユーザーに話しかける（あるいは「ポーカーって何？」）
- 「ユーザーと話しましょう！」
### ７章　「ベストプラクティス」のワーストなところ
- ベストプラクティスに関する会話は、たいてい楽観主義と希望にあふれて始まる。でもベストプラクティスが組織の既存の慣習やリズムと衝突するのは避けられないので、すぐに諦めと不満に取って代わられる。組織を特徴づけているユニークな特性そのものが、変化を実現するためのガイドではなく、コントロールできない変化への障害とみなされる。
- ベストプラクティスは出発点にすぎない。成功は保証されません。うまくいっていること、改善や調整が必要なことによく注意を払うこと。
### ８章　アジャイルについての素晴らしくも残念な真実
- アジャイルなフレームワークに絶対的な役割の明確化と定義を求めようとする誘惑に耐えよう。
### ９章　ドキュメントは無限に時間を浪費する（そう、ロードマップもドキュメント）
- あなたの仕事でいちばんインパクトがある仕事は、形がないものかもしれない。
### １０章　ビジョン、ミッション、達成目標、戦略を始めてとしたイケてる言葉たち
- **本章を読むのは終わりにして、さらっと汚くていいのでチームのゴールと戦略についてラフにメモしましょう。続きはみんなでワークショップをしましょう。冗談抜きで！**
### １１章　「データ、舵を取れ！」
- データドリブンな手法であっても、優先順位を決めたり意思決定をしたりすることは引き続き必要である。
- 特定の情報を一般化するためにデータという言葉を使わない。
### １２章　優先順位づけ：すべてのよりどころ
- 会社やチームのゴール、戦略、達成目標、指標は、きれいに並んだ層に落とし込んではいけない。ぐちゃぐちゃの層からなるケーキとして扱い、どんな意思決定をしてもできる限り最高になるようなひと口を探すこと。
- 「緊急」の要求をさばくための簡単なプロセスを用意しておこう。1人で慌てて対処してはいけない。
### １３章　おうちでやってみよう：リモートワークの試練と困難
- プロダクトマネジメントは難しい。リモートプロダクトマネジメントはさらに難しい。リモートワークを自分のコミュニケーション能力の強化トレーニングと考えてみましょう。今はしんどくて快適ではないかもしれませんが、次に難しい仕事をするときに、やっておいてよかったと思える。
### １４章　プロダクトマネージャーのなかのマネージャー（プロダクトリーダーシップ編）
- 「
そうですね。いいんじゃないですか
」 は罠。
### １５章　良いときと悪いとき
- まとめ：大変な仕事だがその価値はある
### １６章　どんなことでも
- **「私は毎日いったい何をやったらいいんだ？」。自分でも知らないうちに、すでに答えを見つけていました。「どんなことでも」。**




## 他 参考

[プロダクトマネージャーの仕事はプロダクトマネジメント｜Aki](https://note.com/ak_iii/n/nf8959c8c01d8?sub_rt=share_b)

[新米PdM目線でおすすめする書籍「プロダクトマネージャーのしごと 第2版」 | DevelopersIO](https://dev.classmethod.jp/articles/product-management-in-practice-review/)

[「エンジニアリングマネージャーのしごと」を読んで、マネージャーの楽しさを学ぶ #読書 - Qiita](https://qiita.com/e99h2121/items/316530888c25d9961642)


>「本章を読むのは終わりにして、さらっと汚くていいのでチームのゴールと戦略についてラフにメモしましょう。続きはみんなでワークショップをしましょう。冗談抜きで！」

ここが何よりでした。

以上です～。