#book #r2023  # なぜこの本を読んだか # 何が書かれている本か # メモ ## 1章 プロダクトマネージャーの概形が語られているものの、本書でも触れている通り明確な定義を作ることの難しさを感じた。(つまり定義をするのは諦めた方がいいのかも) 一方で [[プロダクトマネジメント ビルドトラップを避け顧客に価値を届ける]] (本書の中でも引用されている) とかでも語られているようにアウトプット (レビューを受けるとか案件概要を書くとか) ではなくアウトカム (KPIの達成など) を最重要視してそのために様々な活動をすべきという話は改めて整理されて印象的だった。 ## 2章 COREスキルというのは知らなかった。 全てをプロダクトマネージャーがやる必要はなく (というかやってたらプロダクトについて考える時間がない) 例えば、O (組織化) はテックリードと協力するとか、R (リサーチ) は、ディレクターにも動いてもらうとか、E (実行) については開発チームに主導権を渡すとかあくまでもチームとして必要であり自分が実行するのはどれで任せるのはどれかみたいなグラデーションを考えるのがいいのかなと思ったりした ちなみにこのグラデーションの話は [How Facebook Builds Products](https://productlife.to/p/-execution-at-facebook) という記事と関連して思ったことです。 ## 3章 全体を通して「わかる」という感じでプロダクトマネージャーに限らず職能の壁を越境しようとしている人にとってはすごく整理になるなという章だった。 ## 4章 特に現代においては、リモートなのもあってここの章で学ぶことが多かった。 このドキュメントで私が好きなのは、「良いプロダクトマネージャーは、あたりまえのことを必要以上に明確に説明しようとする。悪いプロダクトマネージャーは、あたりまえのことを絶対に説明しない」というものです。 自分もこの考えが好きでどちらか迷ったらオーバーコミュニケーションをしようという風にしたいと考えている。 Disagree & Commit この本では、「参加者全員の『進めてよい』と積極的なコミットメントが必要」と書いてあるが多分オリジナルのベゾスの発言では「異議を唱えるのはリーダーの責任である。がいざ決定がなされたら全面的にコミットをするべきである」という趣旨のものなのでちょっと極大解釈をしてそう。 ( [[GitLabに学ぶ 世界最先端のリモート組織のつくりかた ドキュメントの活用でオフィスなしでも最大の成果を出すグローバル企業のしくみ]] でもベゾス同様の捉え方をしてる ) ただし、本書に書いてある方法自体はめっちゃ良かった ## 5章 海外でも社内政治 (言い方が悪いもののこれはこれでプロダクトのアウトカムのために必要だとも思う) があるんだなーと思ったりして読んでた。 ただしシニアステークホルダーにしか見えていない世界や力学もあるのだからプロダクトのためにうまく活用しましょうねみたいな考え方は自分も大事にしていきたいと思った。 あと内容で言うと ミーティングでシニアステークホルダーに何かを伝える場合には、絶対に驚かせないことです。 というのは、エンジニア界では結構有名な [[驚き、最小の法則]] に近いものを感じるなーと思ったりした ## 6章 ユーザーと会話することは明確にスキルなんだということを書いていて、非常にアメリカ (というかプロダクトマネージャーが職能として一般的になった世界) っぽい考え方だなと思いました。( [[Continuous Discovery Habits: Discover Products that Create Customer Value and Business Value]] でもそういった話があるし、[[Running Lean]] でもユーザーインタビュー設計の話が出てくる ) また、「一般論ではなく具体的な例をお願いする」は、対話型ファシリテーションの手ほどき (簡単に読めるのに発見があっておすすめ) の中でも出てくる話で、「いちばん好きな食べ物」のように主観を聞いてしまうことは多々あるので事実を引き出すべく気をつけて設計しないといけない箇所だなと改めて。 ## 7章 「ベストプラクティスを真似したからといってあなたの環境は異なるので大抵うまくいかないが有益な参考情報ではある」というのはエンジニアリングの世界でもよく出てくるので共感が多かった ( [Spotifyは "Spotifyモデル "を使っていない](https://agile.quora.com/Spotify%E3%81%AF-Spotify%E3%83%A2%E3%83%87%E3%83%AB-%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6%E3%81%84%E3%81%AA%E3%81%84?ref=JeremiahLee) とかも割と有名なやつ ) 今自分が担当しているプロダクトでもスクラム開発をしているものの、かなりそれぞれのフェーズや状況に応じて調整して導入しているし、フレームワークをめちゃくちゃ細かく説明するというよりもやっていったらそうなるを目指しているのは間違っていないのかもなあと改めて思ったりしました。 また「何のために問題解決しているのか？」は、プロダクトだけではなくプロダクトの後ろにあるプロセスづくりやルールづくりにも適用されなければいけないんだなと改めて思いました。 ## 8章 7章とも関連するが、アジャイルの話がプロダクトマネージャー向けに書かれていて良いと思う部分もあるし、ある一定の素養がないとあんまりうまく伝わらないかもなとか思ってしまった。 自分はある程度素養があるので、ここは他の人の感想も聞きたいなと思うところ。 ## 9章 ドキュメントのようなアウトプットはそれだけでは何も生んでいないというのは大事にしたい考え方だなと改めて思いました。その上でこの本ではドキュメントをちゃんと書くことが前提にあるように書かれているが、プロダクトによってはドキュメント自体も軽視されていることがあるように感じるので書くこと自体は重要なことであるというのは意識していきたいなと思ったし価値観を合わせたいなあとも思った。 ## 10章 戦略やビジョンは軽視されがちだなと前から思っていて、プロダクトマネージャー向けの本の中でないといけないものとして語られているのがよかった。 特に「ゴールがないので、各プロダクトオーナーは、個人の想定とその場しのぎの成功指標に頼るしかなかったのです」というのはぐさっと刺さった。 自分の好きな言葉で [Dropbox Engineering Career Framework - What is Impact?](https://dropbox.github.io/dbx-career-framework/what_is_impact.html) の中にある、 > They Win, We Win. というエンジニア組織が持っているバリューが好きで、組織一体となって自分達の勝ちがプロダクトの勝ちにつながるようなプロダクトづくりがしていきたいなあというのを思い出しました。 # 感想 - 社内の読書感想会に投稿したもののほぼそのまま書いただけ