Matt LeMay 著、永瀬 美穂、吉羽 龍太郎、原田 騎郎、高橋 一貴 訳「プロダクトマネージャーのしごと 第2版 ―1日目から使える実践ガイド」を読んだ。
原著は「Product Management in Practice, 2nd Edition」
各章の目次は以下
プロダクトマネージャーという仕事は、多岐に渡っており会社やプロダクトによってやっていることが大きく異なっている。 そのため、何をやるべきか、どのように何を学ぶべきなのかわからなかった。
本書を読んで、具体的にやるべきこと・やらないべきこと・指針や考え方を学べた。 端的にまとめたものが序文に書かれている。
理想では、プロダクトマネジメントは、人に愛されるプロダクトを作ること 実際には、直面する非常に多くの根本的な問題を斬新的に改善する戦いを意味します
世間一般に「プロダクトマネージャー」「プロダクトオーナー」の役割についていろいろと書かれているが 以下のようにまとめられている。
プロダクトマネージャー、プロダクトオーナーといった曖昧に書かれたプロダクト関連の役割(ADPR: Ambiguously Descriptive Product Roles)は気にせず、 たくさんの質問を投げかけ、チームと密接に仕事し、いちばんインパクトがあることに集中すること
要するに役割や名称は 「気にするな」 と書かれている。 プロダクトマネージャーの方向性・モチベーションは、1章のまとめで端的に書かれている。
困難に対してオープンであり続けるために最善を尽くし、あなたの役割には曖昧さがあって、 全く新しい多くのことを学習することになる事実を楽しもう！
序章・まえがきと1章を読み終わると、プロダクトとチームに向き合うべきで、地位や自身のがんばり・細かな役割の違いに意味はないことが分かる。 個人的に一番刺さったのは、1章のチェックリスト。
チームのゴールに貢献できることなら、日々の仕事がビジョナリーなものでなかったり重要そうに見えないことだったりしても心配しないでください
なにか「かっこよいミッションのようなもの」を追い求めて心配していたが、心配しなくて良いと書いてあり安心感と自信につながった。
以下は各章で私が気になった部分のメモ。 本書の各章の最後に、「まとめ」と「チェックリスト」が書かれている。これを読むだけでも十分価値がある。 13章以降は、今現在そこまで僕の関心が高くなかったため流し読みしたためメモなし。気になったときに読み直す。
プロダクトマネージャーは、プロダクトを作るわけではありませんが、リリースから結果まで説明責任があります
ビジョンを作り、そのビジョンを全員に広め、かんぶとぷろだくとちーむから賛同を得て、障害を取り除く必要がある
プロダクトを作るというのは、英雄的なミッションではありません
理想では、プロダクトマネジメントは、人に愛されるプロダクトを作ること 実際には、直面する非常に多くの根本的な問題を斬新的に改善する戦いを意味します
本書では、プロダクトとその周辺をつなぐ役割の集まりを全部まとめてプロダクトマネジメントと呼ぶ プロダクトマネジメントの成功とは、肩書きやツールやプロセスの問題というより実践の問題です
時間と経験によって構築されることで、事例と教育だけでは学ぶことができない
p2 メリッサ・ペリ著書「プロダクトマネジメント」
プロダクトマネージャーはビジネスと顧客のあいだの価値交換の管理人である
p4 プロダクトマネジメントではないこと
- ボスではない（ミニCEOではない。責任ではなく名誉ある地位への関心）
- プロダクトの成否の責任を担う。これを果たせるかは、完全にチームの信頼とハードワーク次第
p6 優れたプロダクトマネージャー
- 常に進化を続け、現在のチームや組織の具体的なニーズに合わせて自分のやり方を変えている
- 学ぶべき新しいことが常にあると考えるような謙虚な姿勢を持ち周りの人たちから継続的に新し
p7~8 悪いプロダクトマネージャー
- 業界用語を駆使する怪しげな人（ジャーゴンジョッキー）
- 英雄のプロダクトマネージャー
- がんばり屋さん これらは全て不安によって引き起こされる
p13
どの会社の仕事も少しずつ違う プロダクトマネージャー、プロダクトオーナーといった合間に書かれたプロダクト関連の役割（ADPR: Ambiguously Descriptive Product Roles）は気にしない。 たくさんの質問を投げかけ、チームと密接に仕事し、いちばんインパクトがあることに集中すること
まとめ
困難に対してオープンであり続けるために最善を尽くし、あなたの役割には曖昧さがあって、全く新しい多くのことを学習することになる事実を楽しもう！
チェックリスト
- チームのゴールに貢献できることなら、日々の仕事がビジョナリーなものでなかったり重要そうに見えないことだったりしても心配しないでください
→これがいちばん私の心に響いた
p20
よいコミュニケーションとはイケてる言葉や印象的な発言ではない コミュニケーションの行動指針は心地よさより明確さ
→心地悪さは明確さの欠如の兆候であることが多い
p21
組織化の行動指針は自らを不要とせよ
組織化に優れたプロダクトマネージャーは、チームと協力して人、プロセス、ツールを整理し、都度の介入や監視を必要としない自己持続的な仕組みを作ります
成功しているプロダクトマネージャーは、ユーザがどうやってプロダクトを利用するかだけではなく、ユーザのより広い現実世界とプロダクトがどう適合しているのかを理解している
ルル・チェンの記事
PMの日々の責任と技術的なスキル水準は、業界と会社の規模 プロダクトのどの部分を担当するのかに大きく依存する。 広く尊敬を集めるPMになるために資質は、技術的な専門知識とはほとんど関係ない
重要なのは、技術のことについて探索したり学んだりするのに抵抗がないこと
p35 しなやかなマインドセット
あなたを凌ぐ知識や特定分野の専門知識を持った人たちを徹底的に巻き込むことに前向きになるべき
p38
もっとうまくやれた、「うわ、しまった」と思い不安になったとき 深呼吸をし、不安に駆られた行動は書き留め、翌朝あらためて確認する およそ90%のことは翌日にはやる価値がないと思える
チェックリスト
- プロダクトの限界については冷静に認識するよう努め、あなた自信の個人的な限界ではないと認識
- 「忙しすぎて今それをやる暇はない」など、チームのやる気を削ぐ発言はやめる
p46
ベン・ホロウィッツ「Good Product Manager / Bad Product Manager」
良いPMは、あたりまえのことを必要以上に明確に説明しようとする 悪いPMは、あたりまえのことを絶対に説明しない
あたりまえについて
自分があたりまえと思っていることも、==他の人にはあたりまえでないことがあるから
やってほしいことを曖昧にするのはよくありません 責任回避であり、「悪い奴」と思われずに結果を得ようとする受動的攻撃性の表れ
p51
チームの失敗をすべて自分のせいにするというのは、==自分を不要にする==という重要な行動指針に反します
p54
PMの世界では、はっきりとした承認、明示的な賛意でないものは、驚くほど危険です 曖昧な注意を払っていない**非明示的な賛意の例としていちばんに上がるのが「よさそう」**という反応
→ 優秀なPMは、イライラさせる可能性さえあっても必ず自由回答の質問をする → 3章の通り議論より選択肢を提供する
- 「〜できたらいいのに」「〜できると思う」のような責任逃れな言い方はやめましょう。何かを依頼するなら、何を依頼しているのか？なぜ依頼するのかを明確にして下さい
- 「MTG嫌い」「メール嫌い」になる誘惑に耐える。他人の時間を使うことを謝罪してはいけない。うまく使うこと
p92
シニアステークホルダー(幹部)も人間であり、自信をなくしたり、防御的になったりする彼らが最善の意思決定を下せるように支援し、その人たちの経験から学ぶこと 勝つことを目的にしてはいけない
p105
ユーザリサーチャーに恐れることなく制約を説明する
ユーザに経験を話してもらっているときは、広く一般化した話ではなく、個別の具体的な出来事について話してもらう
p114
制約と限界のなかでベストを尽くすところから始める
結果として、制約を取り除き、限界を超える一番の道
p115
フレームワークやモデルは有用なフィクションと考える
このフィクションは、自分にどう役だっただろう？と考える
p125
ベストプラクティスは出発点にすぎないことを忘れないでください。成功は保証されません
利用するベストプラクティスのゴールを忘れないで下さい。
「うまくいっている」ということの意味を正しく捉えられます
p132
うまくいかないからと完全な失敗を宣言するような全か無かの手法をとってしまうこと。
時間をかけて内省しなければ、どんなアジャイルプロセスでも停滞し、荒れ果て、最終的には失敗するでしょう
2008年ラグ・ガルドらの論文
不完全であることは、危険をもたらすのではなく、行動のきっかけになります。
行為者が不完全なままのものを完成させようとするときも、新たな問題や機械を生み出し、それが絶えずデザインを進める原動力になるのです
問題解決のために一緒に働きながら、継続的にかつ協調的に問題を再構築していくことがよい
p159
アラン・ワッツ**「メニューは食事ではない」**
最高の印象的で網羅的なメニューを作ることより、素晴らしい食事を作ることに集中しましょう
p162
プロダクトマネジメントにまつわる大げさでイケてる言葉の多くは、次の2つの質問に集約される
何を達成しようとしているのか？
どうやって達成するつもりか？
p163
「アウトプットよりもアウトカム」というスローガンが誤解されやすい
アウトカムを達成させるためにアウトプットを遅らせてしまったり・・・（ずっとアウトプットされない）
「アウトカムのためのアウトプット」と考えること。どちらかではなく、つながっているシステムだと考える
p183
ティム・カサロラのニュースレター 価値を証明するな。価値を作れ
→ 価値があることを同僚に証明する目的で実験するのではなく、ユーザに価値を提供することを目的にして実験する
会社やチームのゴール、戦略、目標、指標は、きれいに並んだ層に落とし込んではいけない
ぐちゃぐちゃの層からなるケーキとして扱い、できる限り最高になるように１口にする
読んでみると、気にすべきこと・気にしなくて良いことが具体的に分かった。 日々の仕事で具体的なアクションとして想像して実践できるようになれた。 とても学びになった。