『プロダクトマネージャーのしごと 第2版』読書メモ

https://www.oreilly.co.jp/books/9784814400430/

序文

p.xii いいプロダクトマネージャーの定義は、会社中心のBHAG（大きくて、難しくて、大胆なゴール）を持つ新しくて明快な財務モデルを社内に広めることができる人
p.xii プロダクトマネージャーはプロダクトを作るわけではありませんが、リリースから結果まで説明責任があります。…ビジョンを作り、そのビジョンを全員に広め、幹部とプロダクトチームから賛同を得て、障害を取り除く必要があります。

はじめに

p.xviii （ロードマップ、開発プロセスがないことについて）スタートアップで働くにはつきものだと思っていました…プロセス重視のエンタープライズ企業であっても、プロダクトマネジメントの実際の仕事は、合間時間や陰で行われているようでした…コーヒーブレイク中に…雑多な人間同士のコミュニケーションが支配的でした。
p.xviii 曖昧さや矛盾、しぶしぶする妥協といった、日常的なプロダクトマネジメントの実践についての本です。
p.xix 「プロダクトマネージャー」「プロダクトオーナー」「プログラムマネージャー」「プロジェクトマネージャー」あるいは「ビジネスアナリスト」と呼ばれているかもしれません…プロダクトマネジメントの成功は、肩書きやツールやプロセスの問題というより、実践の問題です。

1章 プロダクトマネジメントの実践

p.1 日々の仕事は、コミュニケーションやファシリテーション、支援の仕事のほうが多く、作るという仕事はそれより少ない
p.2 プロダクトマネジメントを知りたければ…そもそも定義が不可能だということを理解しなければいけません。（『プロダクトマネジメント』で）プロダクトマネージャーはビジネスと顧客のあいだの価値交換の管理人である
p.3 ビジネスモデル、企業規模に関係なく、プロダクトマネジメントの仕事に共通するテーマ

• 責任は大きいが権限は小さい：チームが締め切りを守れなければあなたの責任…プロダクトの成否の最終的な責任を負う
• 終わらせる必要があれば、それがあなたの仕事である：コミュニティマネージャー、HRリード、UXデザイナー、オフィスマネージャー…チームとプロダクトのパフォーマンスに対する責任を持つのはあなた
• あなたが中心になる

p.5 プロダクトマネジメントではないこと

• ボスではない：責任を果たせるかどうかは…チームの信頼とハードワーク次第…その信頼も、あなたが偉そうな上司のようにしていると、簡単に失われます。
• 実際にプロダクトを作るのはあなた自身ではない：人やものをつなげて前に進めるというプロダクトマネジメントの側面
• 誰かがやるべきことを言ってくれるまで待てない：チームがゴールを達成する能力に影響を与えるようなことを明らかにし、評価して優先順位をつけて対処するのはあなたの仕事

p.6 優れたプロダクトマネージャー…常に進化を続け…自分のやり方を変え…学ぶべき新しいことが常にあると考えるような謙虚な姿勢を持ち、周りの人たちから継続的に新しいことを学ぼうとする好奇心があります
p.7 悪いプロダクトマネージャーの典型

• ジャーゴンジョッキー：聞いたことのない言葉を…まくしたてる
• スティーブ・ジョブズ信奉者：偉そうに挑発的な質問を投げかける
• 英雄のプロダクトマネージャー
• 頑張り屋さん：たくさんのものを届けられる…それがビジネスやユーザーの目的を実際に達成したかどうかはまったく定かではありません
• プロダクト殉教者

p.9 これらのパターンが、悪意や無能さではなく、不安によって引き起こされる…（プロダクトマネージャーは）実際に何をしたのでしょうか？この質問と、価値を守ろうとする衝動が、意図せず自己破壊の行為につながることがあります
p.10 週に60時間働く…多くが経験不足、不安、自分の時間を効果的に優先順位づけできないことに起因
p.11 プロダクトマネジメントの分野では、自分の時間に境界線を設定し、優先順位をつけるという難しいことを身に付けた人をたくさん必要としています
p.12 ずっと増え続ける「プロなんとか」という肩書きのリストのことを「曖昧に書かれたプロダクト関連の役割（Ambiguously Descriptive Product Roles, ADPR）」だと考える…仲間のADPRと…協力して進めることに集中しましょう

2章 プロダクトマネジメントのCOREスキル

p.17 プロダクトマネージャーが、開発者、デザイナー、ビジネスアナリストのすべてのスキルと知識を持っていなければならないという思い込み…（プロダクトマネージャーに求められるのは）デザイナーや開発者、ビジネスアナリストの連携を生み出すスキル
p.18 プロダクトマネージャーは下記のことができる必要があります。…COREスキルモデル

• ステークホルダーとコミュニケーション（Communicate）する：心地よさより明確さ
• 持続的に成功するチームを組織化（Organize）する：自らを不要とせよ
• プロダクトのユーザーのニーズとゴールをリサーチ（Research）する：ユーザーの現実に生きよ
• プロダクトチームがゴールに到達するための日々のタスクを実行（Execute）する：すべての努力はアウトカムのために

p.20 コミュニケーションスキルを自分自身で評価できる質問

• やっていることとそのりゆをチームが明確に理解しているか確かめるために、必要な質問や会話のファシリテーションをしているか？
• ユーザーやビジネスにとってより大きなアウトカムを得られそうだと思ったとき、他のチームやプロダクトマネージャーに積極的に働きかけにいくか？
• 連絡してきたステークホルダーに素早く、思慮深く反応しているか？
• 解決策になりそうなことを探しているとき、いつも選択肢をいくつか示して、それぞれのトレードオフをステークホルダーに説明しているか？

p.22 組織化スキルを自分自身で評価できる質問

• もし1ヶ月休暇を取ったら、日々の介入がなくても優先順位づけとデリバリーができるだけの情報とプロセスがチームにあるか？
• 「今何をしているのか？それはなぜ？」とチームの誰に聞いても、すぐに答えられ、回答に一貫性があるか？
• 他のチームが今自分たちのチームが何をしているか知りたい場合でも、簡単に最新で理解しやすい情報にたどり着けるか？
• あるプロセスもしくはシステム（あるいはそれがない場合）がチームにとってうまく機能しない場合、それらを変えるために積極的にチームと協力できているか？もしくは、そのプロセスやシステムを直接変えられる立場ではない場合、関わり方を変えるために積極的にチームと協力できているか？

p.23 プロジェクトの納期を守ったり、プロダクトバックログを管理したり、損益計算書の計算をしたりといった、あなたにとって重要なことは、ユーザーにとってまったく重要ではありません。ユーザーには、ユーザー自身の優先順位があり、ニーズがあり、関心事があります
p.23 リサーチスキルを自分自身で評価できる質問

• 自分のチームは少なくとも週1回はユーザーや顧客から直接学んでいるか？
• すべてのプロダクトに対する意思決定は、ビジネスゴールとユーザーニーズにもとづいているか？
• 自分のチームは、ユーザーニーズや行動に対する理解を深めるために、定期的に自分たちのプロダクトと、それと競合・関連するプロダクトを使っているか？
• ユーザーニーズと利用目的は実際の自分たちのユーザーのニーズと利用目的を反映してはっきりとまとめられているか？それとも、ビジネスが創造するニーズや目的だけか？

p.24 実行スキルを自分自身で評価できる質問

• 自分のチームは顧客とビジネスインパクトから考え、そこに至るための複数の道筋を評価し、優先順位をつけているか？機能から考えて、インパクトを後づけで見積もることで正当化していないか？
• 自分のチームの戦略的なゴールと目的は、スプリントプランニングやストーリー作成といった、戦術的な会話や活動の中でも中心になっているか？
• チームのゴールや優先順位を反映する形で自分の時間を使えているか？
• 疲れ果てるまで仕事をしないと、チームが必要とすることができないくらい余裕がないときは、マネージャーに直接相談できているか？

p.25 まとめると「ソフトスキル」…ハードスキル…それは、プロダクトマネージャーに期待される日々の仕事とはほとんど関係ありません
p.26 コミュニケーションスキルは、見方によれば、同僚の専門知識と組織の状況を尊重しながらハードスキルを学ぶ助けになります
p.27 重要なのは、技術面でエキスパートであることではなく、技術的ではないことと同じように、技術のことについて探索したり学んだりするのに抵抗がないことです

3章 好奇心をあらわにする

p.32 プロダクトマネージャーが…開発者、データサイエンティスト…専門家たちの信頼を獲得する…「相手の仕事に心からの興味を持ちましょう」
p.32 ハードスキルを使う仕事を課されている人たちに直接教えてもらえば、自分の組織が今いちばん必要としているハードスキルについて学ぶことができます。さらに、そうすることで技術系の同僚との絆が深まります。
p.33 何かを求める前に関係性を築いておきましょう。…少し時間をとって、チーム外の誰かに声をかけてみましょう…あなたの知識と信頼のネットワークを広げるためには適切な一歩です。
p.34 伝統的な技…コーヒーを一緒に飲んだり、お酒を飲みに行ったりして、相手の仕事や問題について少しずつ知る
p.35 しなやかなマインドセットの人は、失敗や挫折を学習の機会だととらえ…初めてのスキルや物事を成長の機会として取り組む
p.36 しなやかなマインドセット…未知のものだけでなく、あからさまに間違っていることも受け入れること
p.37 行動で示すべき最重要の資質が好奇心…その逆…守りの姿勢…何かを守るためにするすべての試みは、実際には害になる
p.38 守りの姿勢と距離を置くための実践的なヒント

• 議論ではなく選択肢を与える
• 不安や守りの姿勢のために何かを強いられているように感じるなら、書き留めておいて翌日再度取り組む
• まず「いいね、素晴らしい」と言ってからあとのことは考える
• 助けを求める

p.42 好奇心は人から人へ広がり、それによって自然に人がコラボレーションする距離も近くなり、お互いのものの見方の理解度が深まります
p.43 プロダクトマネージャーとして、実にさまざまなスキルセットやゴールや課題を持つ人たちとコミュニケーションし、方向性をそろえ、通訳となって働くのがあなたの責任です。…その人たちの仕事に対して素直に純粋な興味を持つことです。

4章 過剰コミュニケーションの技術

p.46 コミュニケーション不足が引き起こす問題は、巨大で恐ろしい…コミュニケーション過剰が引き起こす問題は、あきれられるか、嫌味の1つ2つくらい
p.46 良いプロダクトマネージャーは、あたりまえのことを必要以上に明確に説明しようとする…他の人にはあたりまえでないことがあるから…コミュニケーションの大惨事を引き起こす可能性がある
p.48 遠回しではなく、単刀直入に
p.50 他人にやりたくない仕事をやってもらうように依頼しなければならない場合があります…他に優先度を下げられるタスクがないか…全体的に優先度を検討したかどうか
p.51 プロダクトマネージャーとして、チームのアウトカムについての最終的な責任はあなたにあります。とはいえ、その責任を自分だけで負う必要はありません。失敗したことをすべて自分の個人的な失敗にしたら、チームから学習と成長の機会を奪うことになります。…自分を不要にするという重要な行動指針に反します。チームと一緒に、失敗を引き起こした可能性のあるシステムそのものにまつわる課題に取り組みましょう。
p.52 「…アウトカムを大きくするために、何を変えたらよいでしょう」…注意を感情からアウトカムにシフトでき、受動的攻撃性のある個人攻撃に繋がってしまいがちな会話を避けられます。
p.53 いちばん危険な言葉：「よさそう」
p.54 プロダクトマネジメントの世界では、（幹部のステークホルダーからの）はっきりした承認、明示的な賛意でないものは、驚くほど危険です…例として…「よさそう」という反応…（そう答えられないようにするために）選択肢を提供します…
p.55 Intelの…Disagree & Commitという、まさにこの問題に取り組むためのテクニック…集団での合意形成の際には、参加者全員の「進めてよい」と積極的なコミットメントが必要
p.56 参加者全員が具体的で積極的なコミットメントを示す必要があります。コミットメントを示せないなら、質問や反対を表明する必要もあります…ゴールは、質問や懸念点があったら共有することによって、できる限り良い判断を下すこと。
p.57 Disagree & Commitを導入する…いくつかコツはあります

• 使う前にDisagree & Commitを紹介すること：事前に紹介して合意を得ておく
• 沈黙は不合意として扱う：積極的なコミットメントしか合意として扱いません
• 参加者の多いミーティングでは、すばやくパルスチェックを試す：特にビデオチャットで…コミットする人は『いいね』して
• ゴールを設定し、テストし、学ぶ：判断を先送りにするのを防げますし、成功かどうかを計測し判断するという説明責任を共有しながら、先に進められます
• すべてを曲解して、「Disagree & Commitなんだから、合意するかどうでもいい」などと言わない

p.60 自分とは違うコミュニケーションスタイルの人がいることを認識するのは非常に重要です…素直に興味を持って付き合ってみましょう…理解と共感を広げていくのに役立つでしょう
p.61 相手がどのようにあなたとコミュニケーションしようとするかを観察する…人は、自分が情報をいちばん理解しやすいコミュニケーションを使って、情報を伝えようとします
p.63 みんなスマートで、良い意図を持って働いていると想定しましょう…謙虚に…会社の他の部署の人たちを知ることが、もっと重要な場合もあります
p.65 特定の機能について議論するよりも、顧客が抱える本質的な問題を深く掘りましょう…アカウントマネージャーに…開発者にパートナーとしての協力を求めましょう
p.67 プロジェクトのゴールにいちばんあっている選択肢は何かを尋ねる…ゴールは常にそろえておきましょう
p.68 あたりまえのこと、気まずいこと、そしてあたりまえだけど気まずいこと、それらを質問する

5章 シニアステークホルダーと働く（ポーカーゲームをする）

p.73 シニアステークホルダーはあなたがまったく知らないようなビジネス上の重要かつ上位の情報に触れることができます。そういった情報にもとづいて、プロジェクトの途中で優先順位をひっくり返したり変えたりすることもあります。…シニアステークホルダーはいつもポーカーに勝つのです。あなたの使命は、それを受け入れて…ビジネスもユーザーも勝てるようにすることです。…「上司をうまく使う方法」
p.74 シニアステークホルダーが間違ったように見えたり…ひどい意思決定をすることもあります…考慮に入れておくべきだった戦術的なトレードオフを…知らせておかなかったことが理由…ステークホルダーに影響を与えることではなく、情報を知らせることがプロダクトマネージャーの仕事
p.75 最高のプロダクトマネージャーは、リーダーが正しい情報をもとに意思決定できるようにします…言い争いをするのではなく選択肢を提示し、リーダーがその意思決定に伴うトレードオフを前向きに理解できるようにします。リソースの追加を主張するより、しっかりとした推奨案を含んだ選択肢をいくつか提示するようにしましょう。
p.78 チームのところに行き「上司が馬鹿だ」みたいなことを言った瞬間に、実質的にはチームを壊します…組織の観点では失敗するように仕向けてしまうのです。
p.82 「大きな」ミーティングでシニアステークホルダーに何かを伝える場合は、絶対に驚かせないことです。…発表する前に…個別に説明するのが良いでしょう…リモートワークの時代…シニアステークホルダーに時間を割いてもらうのは言うほど簡単ではありません。大きなミーティングの前に、シニアステークホルダーの時間をまったく確保できないのであれば、「大きなアイデア」を1つの道として発表するのではなく、アイデアを小さく分割し、いくつかの選択肢を提示することをお勧めします。
p.83 大々的なお披露目を避けてインクリメンタルに賛同を得る…全部まとめて提示しても、みんなどこにフィードバックすればよいかわかりません
p.84 あなたの最終的な成功は、ステークホルダーを満足させるかどうかではなく、ユーザーを満足させるかどうか…プロダクトマネジメントの行動指針の1つである「ユーザーの現実に生きよ」…ユーザーニーズのためになることがビジネスゴールにとってもプラスになるようにしておく
p.85 ユーザーニーズとビジネスゴールの関係を…正確に説明しましょう…「オンボーディング体験…負担を減らせば、新規ユーザー登録を20%ほど増やせる…広告収入に換算すると…四半期の利益目標の達成に向けた重要なステップ…」
p.92 創業者や幹部のようなステークホルダー…彼らが最善の意思決定を下せるように支援し、その人たちの経験から学び、我慢強く、好奇心旺盛でいましょう
p.93 メテオフォール…根底にある問題を見つけて対処する機会を探してください。シニアステークホルダーが突然何か違うことをしてほしいとチームに言ってきたら、理由を探りましょう。

6章 ユーザーに話しかける（あるいは「ポーカーって何？」）

p.97 ユーザーとの会話こそが、プロダクトマネージャーが身に付けなければいけないいちばん難しいことかもしれません。…ステークホルダーとうまく働くためのふるまいは、ユーザーから学ぶときにそのまま使ってもうまくいかないことが多い…ユーザーの目的やニーズ、どんな社会に生きているのかを学べるだけ学ぶ
p.98 ユーザーと上手に話をして、ユーザーから学ぶためには、具体的な答えや特定の解決策をユーザーに教えたくなる誘惑に抗わなければいけません。
p.99 非公式なユーザーリサーチは…カンファレンスでの和やかな会話や、家族への「技術サポート」など、あらゆるところで起こります
p.100 ユーザーリサーチを実施した経験から得たいちばん注目に値する教訓

• 一般論ではなく具体的な例をお願いする：具体的な1つの実例でユーザーの現実世界を忠実に反映する
• 自分が聞きたかったことを聞いても興奮しすぎないようにする：（プロダクトを）必要とする理由はまったく違うかもしれません
• ユーザーにあなたの仕事を依頼してはいけない：自分たちの目的やニーズと…会社独自の機械を結びつける…それは…あなたの仕事

p.102 ユーザーペルソナは、私たちの思い込みや先入観を有害な作り話として具現化させる方法になりやすい
p.103 落とし穴に落ちないためのコツ

• ペルソナが実際のリサーチにもとづくものであることを確認する：ユーザーの属性のみにもとづくのであれば…ステレオタイプ
• 定期的にペルソナを見直す：プロダクトは変わり、マーケットは変わり、人も変わります。
• アンチペルソナを使って、誰のために作るのではないのかを明確にする：対象としない人たち…意思決定をいっそう具体的にする

p.105 リサーチとプロダクトを整合させるコツ

• 穏やかかつ恐れることなく制約を説明する
• 決定的に重要なインサイトを膨大なスライドに埋没させない
• チーム全体を巻き込む

7章 「ベストプラクティス」のワーストなところ

p.109 ベストプラクティスに集中しようとすることで…成功から遠ざかる

• ベストプラクティスに集中することで、好奇心を失う：厄介で予測不能で絶対に回避できない人間の複雑さ
• ベストプラクティスはおとぎ話のような結末を騙る：人生は続きます。変化は避けられません。永続する「ベストプラクティス」などありません
• ベストプラクティスに魔法を期待しても、失望して悲しむことになるだけ

p.111 どんな会社でも、政治抗争があり、リソースの制約があり、ロジスティクスの課題を抱えている…「業界トップ」企業のケーススタディのほとんどは…採用のためのプロパガンダ
p.113 「会社はわかってない」は最高の言い訳です…どんな組織も何らかの変えられない制約のなかで活動している…制約をより早く認識し理解できれば…あなたとチームがユーザーに価値を届けることに集中できる…「現実と恋に落ちる」
p.114 組織の制約や限界を批判せずに受け入れろと言っているわけでもありません…制約と限界のなかでベストを尽くすところから始めるのが…限界を越えるいちばんの道です
p.115 フレームワークやモデルは、有用なフィクションと考えるとよい…哲学の虚構主義…「このフィクションは、自分にどう役立つだろう？」と質問します
p.116 フィクションであると認識することで、「ベストプラクティス」をチームや組織の特有のニーズに適応させやすくなります
p.119 （組織の）具体的なゴールが定まってから、ゴールの達成を助けるプラクティスについて考え始めます…会話の中心をツールやフレームワークから、根底にある人間の問題に移動させるための質問

• 「ロードマップにお勧めのツールは？」→「どうやって会社の内部、外部に次に開発する機能を説明しているか？」
• 「プロダクトビジョンを書くのにどのツールを使っているか？」→「チームを動機づけるためにどうやって未来のビジョンを共有しているか？」
• 「OKRをトラッキングするのに最適なツールは？」→「会社にとって重要なこと、そうでないことをどうやって判断しているか？そして、どうやって伝えているか？」
• 「スクラムとカンバンはどっちがいい？」→「開発するものとしないもの、どうやって判断している？」
• 「コンセプト共有のためのワイヤーフレームツールのお勧めは？」→「初期のプロダクトアイデアをどうやって伝えているか？」

p.120 「ベストプラクティス」と呼ばれるまでには、多数のトライアンドエラー…テストと学習、失敗と適応といったプロセスは、どんな組織でも避けられない
p.121 解決しようとする問題を本当に理解するために時間を取らなければ、どんなベストプラクティスも暗闇でむやみに鉄砲を撃つようなもの…組織特有の状況について学ぶ…小さく始め、だんだん広げていく
p.123 変更を提案します…チームのやり方に対する変更を攻撃と考える人たちと、うまくやるために私が使ってきたアプローチ

• アイデアを考えるところから、プロセス嫌いな人たちを一緒に巻き込む：あらかじめアイデアを共有しレビューしてもらう…その人たちの価値を認識していることを伝える
• 起こりうるひどいことをすべて包み隠さず認識し、文書に残す：懸念事項に対して率直に向き合ってみれば、学びが得られる
• すべてを決定事項ではなく、実験ととらえる
• 「今やれること」ではなくて、「次にやれること」にフォーカスする：直近の仕事に追われている状況ではインパクトを出すのは難しい

p.125 ベストプラクティス…組織にポジティブな変化をもたらす最初のステップになれる…出発点にすぎない…成功は保証されません

8章 アジャイルについての素晴らしくも残念な真実

p.127 どのアジャイルフレームワークを選んだにせよ…プロダクトマネジメントにおける人間の複雑さをプロセス化して切り離すことはできません…相互理解やコミュニケーションやコラボレーションをなくすことはできません
p.128 アジャイルは方法論ではありません…仕事のやり方を変えるという話なのです…ユーザーに価値を届ける責任から私たちを解放してくれるわけではありません
p.129 （アジャイルの）価値観の中心にあるのは、人間の独自性と複雑さを受け入れること…より良い仕事の仕方を見つけ出そうとしている過程
p.131 「アジャイルをやる」ことが成功の保証につながるわけではない
p.133 アジャイルが私たちにやれということは非常に常識的…チームの働き方を変えたければ…ともに内省し変わるのです。…もっと多くの価値を届けたければ…動くソフトウェアをもっと頻繁に届けるのです。
p.137 プロセスを内省し洗練する時間を作らなければ、ビジネスやユーザーにまったく価値をもたらさないでっち上げのセレモニーや儀式のせいで、結果的にチームの士気を低下させることになりかねません
p.137 チームのアジャイルプラクティスやセレモニーを変える時は、変更の背後にある理由や変更自体の本質や変更の本来の目的をドキュメントに残すとよい

• 私たちがやってきたアジャイルプラクティスやセレモニー
• どんな目的を達成するために役立つと考えたか
• 実際に起きたこと
• 次のイテレーションで変更する内容
• この変更を踏まえた目的達成の方法

p.139 デイリースタンドアップミーティングが本来あるべき姿と正反対のことをしてしまっている…待ちを発生させないようにするはずだったミーティングが、実際には待ち状態の言い訳に使われていました….待ち状態が発生したら誰でもその場でチームに割り込みをかけ、待ちが発生していることについて話すようにした

9章 ドキュメントは無限に時間を浪費する（そう、ロードマップもドキュメント）

p.145 プロダクトマネージャーとして行ういちばんインパクトのあることの多くは、目に見えません…コミュニケーションの問題の解決、大まかなゴールに向けた会話の推進、戦術的なトレードオフに関する経営陣への説明など…ほとんどのイケてるドキュメントは、実際にチームがゴールを達成するのには役立ちませんでした…どうすれば使う時間を減らしつつ、ドキュメントをもっと役立つものにできるか
p.147 ロードマップは…チームと役に立つ会話をするきっかけとなるもの…自分たちの努力や重要性を示す記念碑ではありません…問題はロードマップではなく、それをどう使うか…いつ何を実行するかの厳密な計画ではない
p.148 重要なのは…自問自答すること…「ロードマップのREADME」を書くこと

• ロードマップでどこまで先を見据えるか？
• ロードマップに「短期」計画と「長期」計画の区別があるか？
• ロードマップには誰がアクセスできるか？顧客に見せるのか？一般に公開するのか？
• ロードマップは誰がどんな頻度でレビューするのか？
• ロードマップの変更はどう伝えるのか？どれくらいの頻度か？
• この先3か月のロードマップにとある機能があったとして、組織の誰が何を合理的に期待できるか？
• この先1年のロードマップにとある機能があったとして、組織の誰が何を合理的に期待できるか？

p.150 アウトカムベースのロードマップ、問題領域ベースのロードマップといったもっとまともな選択肢…機能がどんなもので、いつリリースされるのかをステークホルダーが正確に知りたい場合…不確実なことや変わりそうなことを率直に恐れることなく伝えるようにしてください
p.151 プロダクト仕様書…ドキュメントがあれば、プロダクトを作る上での構造化、ファシリテーション、優先順位づけがしやすくなります。でも、これはプロダクトではありません。チームが実際に何かを作るまでは、プロダクト仕様書はユーザーにまったく何も価値を届けていません。
p.152 プロダクト仕様書はプロダクトではありません。「ユーザーストーリー」はユーザーではありません。
p.153 何かを書き出すというのは、かなりの諸刃の件です。書けば書くだけ時間がかかりますし、実際にやらなければいけない仕事から遠ざかってしまいます。長くて詳細な仕様書を書くと、プロダクトを作るために多くの仕事をしている気にはなりますが、それは必ずしも正しい仕事ではありません。
p.153 意図的に不完全にしたドキュメントがチームのコラボレーションの足並みをそろえて加速する...不完全であることは...行動のきっかけになります
p.154 発表、批評、編集といういサイクルを何度も繰り返すよりも、一緒に（不完全な、雑な）ドキュメントに取り組む方がずっと簡単...最初のドラフトは1ページで、作るのに1時間以上かけない
p.156 チームの役に立つ価値あるテンプレートにするためのコツ

• テンプレートの内容だけでなく、構造自体も「活用する」：ゴール達成には役に立たないと思ったら、ためらわずにテンプレートの構造を変えましょう
• 定期的にテンプレートを見直して更新する：テンプレートをチームみんなで変える
• 人にテンプレートを埋めるように依頼する前に自分で最低３回は必ず埋めてみる：サンプルとして共有する

p.158 「どのロードマップツールを使うべき？」という質問は、「何をロードマップに載せるべきか？」もしくは「ロードマップは自分たちにとってどんな意味があるのか？」という質問と比べると、安易で価値の低いもの...イケてる商用ツールをただ導入すれば成功が保証されるわけではありません...問題は、必要な情報と、...その情報がなぜ必要なのかを明らかにして理解できるように、腹を割ったコミュニケーションをすること

10章 ビジョン、ミッション、達成目標、戦略を始めとしたイケてる言葉たち

p.162 その手の重要そうなものを作る…チームに来年何を達成してほしいか、どうやってそれを達成するつもりか、ざっくりと書き留めるところから始めるといい…チームのところに持っていってフィードバックをもらうまでは、1ページ以内で、1時間以上かけて作ってはいけない
p.162 チームのゴールと戦略を設定する「正しい」方法を求める時間が減るほど、さっさとチームと働き始め…どこに…どうやって向かうのかをチームにはっきり伝えることができる
p.163 「アウトプットよりもアウトカム」を「アウトカムのためのアウトプット」にすると役に立つ…アジャイルマニフェストの「包括的なドキュメントより動くソフトウェア」…にも使えます…二者択一ではなく、つながっているシステム…アウトカムに具体性がなければ、アウトプットに具体性が求められる…アウトプットとアウトカムがシーソー
p.165 プロダクトオーナー…顧客にどれだけの価値をデリバリーできたかに照らして評価される…どれだけ多くのプロダクトを所有しているかとか、金曜日の夜にどれだけ遅くまで残るかではない
p.168 戦略と実行を常に結び付けておくことがあなたの仕事です…不完全で未完成な戦略文書をチームに持ち込み、一緒に「試乗」して日々の意思決定の役立つ指針になるかを見てみるとよい
p.170 「良い戦略は必ずと言っていいほど……単純かつ明快である。…」… すぐに使えるプロダクト戦略は、「ユーザーは誰？」、「解決しようとしている課題は何？」、「私たちがその課題を解決するのにふさわしい会社であるという理由は？」といった、単純な質問に集中的に答えられるものになっている
p.171 具体的なプロダクト戦略…どんなものを作るか、どう作るか…いちばん重要なのは、何をつくらないか
p.172 戦略が手短で鋭く集中的であればあるほど、有意義なアウトカムをビジネスとそのユーザーに届けられる

11章 「データ、舵を取れ！」

p.175 ユーザーやプロダクト、マーケットのデータから学ぶものはたくさんあります…何のデータが自分にとって重要なのか、なぜ重要なのか、どのような意思決定に役立つのか
p.176 データという言葉は、具体性がなくとも権威性を持つ…データという言葉を一切使わないで…その情報について…どうやってその結論に至ったのかを説明してください
p.177 「必要な情報が全部揃ったとしたら、自分たちはどのような意思決定ができるのか？」…代わりのデータソースや大雑把ながらも使える代替の指標…前に進める方法は常にあります
p.178 データドリブンの実験…直感に従い、そのあとで直感が適切かをテストするためのフィードバックループを作る
p.181 特定のアウトカムが「良い」か「悪い」かは、アウトカムが自分が望んだものなのかを積極的に把握しにいく勇気がない限り、実施的に断言できません…新しいプロダクトや機能のリリースの前にこの会話の機会を設ける方がずっと良い
p.186 A/Bテスト…「統計的に有意」な結果をもたらしても、それがビジネスやユーザーにとって重要というわけではありません

12章 優先順位づけ：すべてのよりどころ

p.191 チームと協力して答える…何を作りますか？…どこまで作りますか？どうなったら成功だと思いますか？…切り捨てるべきところはどこですか？
p.194 どの意思決定もトレードオフ…ある種類のユーザーのために…別の種類のユーザーをイライラさせる…トレードオフに慎重かつ効果的にあたるためのヒント

• 小さく始める：やってみないとわかりません…軌道修正できる程度に
• さまざまなユーザーセグメントやペルソナを念頭に置き、そのニーズに合わせて優先順位づけする
• 仮説は文書化しておく：チームと議論しましょう…一緒に仮説をカタログ化して理解しておくと…軌道修正をするための良い備えになります
• 何を作ろうにもコストはかかることを覚えておく（隠れたコストでも）

p.195 誰かにとっての現実の問題を解決できれば、その人は上司にその話を伝え…あなたの仕事は全社から支持を得られているのです
p.198 顧客の観点からすると、プロダクトのいちばん重要な部分が個々の機能であることは少なく、むしろ、機能を組み合わせていかにシームレスでまとまりのある体験を作り出せるかにあります。
p.198 プロダクトマネージャーにとって...あなたの組織のどこにサイロや境界があるかに関わらず...それを乗り越えるというきつい仕事をする必要が出てくる...直属のチームの範囲を超えて、機会を特定し、優先順位をつけ、実行するための戦術的なヒント

• 定期的に自分たちのプロダクトを使って、タスク全体やユーザージャーニー全体を通しでやってみる
• 作業の依存関係ではなく、チームのゴールから始める：複数の機能やプロダクトの領域に関わる仕事は、ユーザー（ひいてはビジネス）に対して特別に価値があります
• 引き算の解決策に目を向ける：足し算の解決策を追求しがち
• 小さく始める（再）

p.200 最高のアウトカムを出すために...片足をユーザーの現実に...もう片足をチームやサイロの外に踏み出す
p.201 チームが計画を実行するだけでなく、学習し、考え、実験するための...重要な機会
p.202 成功するには単に多くのことをやるだけではダメ...ゴールを達成するためにいちばん役立ちそうな活動を優先する
p.204 「緊急」の要求...を処理する方法...質問から始める

• 問題は何か？
• 報告者は誰か？
• 何人のユーザーに影響するか？
• この問題は収益のような全社的なゴールにどう影響するか？
• この問題を半月放っておくと何が起きるか？
• この問題を半年放っておくと何が起きるか？
• この問題についてさらに議論したり、解決したりするときの担当は誰か？

13章 おうちでやってみよう：リモートワークの試練と困難

p.210 ランチタイムやコーヒータイムの気楽なおしゃべりなしに、どうやって仕事のやりとりを超えた…信頼を築けるというのでしょうか？…お互いにすばやく信頼するという選択をする必要がある…チームのメンバーがお互いを信頼するという判断が必要….チームのメンバー同士で、どのように働きたいと思っているのか？その理由は？といった会話がなされるように促さなければいけません。
p.211 カメラオンルール…よりも、「みんなにリモートミーティングにもっと積極的に参加してもらうには…？」と考える…小さな変更を行い…レトロスペクティブを行うという繰り返しが、いちばん持続可能
p.213 信頼…日々のコミュニケーションに対する期待が合っていない…レスポンス時間に対する合意…タスクにかかる時間の期待
p.214 コミュマニュアル

• それぞれのチャネル（メール、SMS、Slackなど）の非同期メッセージに、どれくらいすばやく反応することを期待するか？
• お互いに仕事をお願いするときに、明示すべき基準は？（例：どれくらいの期間お願いするのか？納期は？この仕事が遅れると他の仕事に影響を与えるのか？）
• 個人とチームの仕事時間は？仕事時間以外に送受信したメッセージの扱い方は？

p.215 Slack…チャネルに対して即時に注意を払うことを期待する人がいる一方、1日に1回か2回チェックすれば十分と考える人もいます
p.216 同期時間を進捗報告から、協働して判断を下す時間にシフトさせたい…かなり『意図的に』やる必要がある…計画、準備そして規律が必要

• 短く集中する：1時間を上限に…明確なインプット、アウトプット、ゴールを設定
• 共有ドキュメントで作業する：誰か1人に議事録を頼むのではなく…共有ドキュメントで…共同オーナーシップの感覚を育む
• 慣れたツールを使う
• 準備と練習には3倍かける

p.219 2x2のインパクトエフォートマトリクス…作るのがどれだけ大変か？ユーザーにどれだけのインパクトがあるか？…ユーザーにとっていちばん価値のあるものを届け、開発者の時間をいちばん有効に使う
p.220 「クイックピン」の山でコミュニケーションする癖…「ちょっとみてくれる」、「ちょっと質問があるんだけど」…全体として…コンテキストを理解し、優先順位づけをする…際限のない時間のコミットメントが必要になります…何日もの生産的な時間を食いつぶすことになる…メッセージを送っている理由とか…期限…どれだけ重要なのか…をなるべく直接明確に書くように
p.221 「送信」ボタンを押す前に自分に問いなさい…非同期メッセージに時間と労力をもっとかけましょう…結果的に、同僚の時間と労力を節約できます

• メールを読んだ受信者は、10秒以内に、取って欲しいアクションがわかるか？
• 期待する結果と納期は期待してあるか？（例）金曜日の午後3時までに〜
• 複数の受信者に送る場合は、それぞれの受信者への依頼事項は明確か？
• フィードバックを求める場合は、どんな種類のフィードバックを求めているのか、フィードバックを求める理由を明確に示したか？
• 一般的なフォローアップやチェックの場合は、どんなタイプの反応・アクションが欲しいかを明確にしているか？

p.222 同期サンドイッチ…1日前までには、事前に読む資料を非同期で送る…同期ミーティング…判断を下し…問題を解決する…次のアクションを含むフォローアップを非同期で送る
p.226 物理的に離れたオフィスのあいだだで、偶然の会話ができる部屋をどうやったら作れるかという、おもしろい問題…チームの仲間意識やチーム内コミュニケーションに大きな差をもたらし増田
p.227 チームのコミュニケーションは、積極的に取り組み、一緒に育むべきもの…複雑さが増すほど、必要なコミュニケーションも増す…コミュニケーションを続けましょう

14章 プロダクトマネージャーのなかのマネージャー（プロダクトリーダーシップ編）

p.229 何回か昇進したあと…昔の癖…「…この会社はめちゃくちゃだよね！」…表向きは会社をちゃんとさせるべき立場…まったく適切ではありません…マネージャーになるにあたって、どれだけ学び、アンラーニングをし、そして再度学ぶべきか
p.230 「公式…非公式に…他人の仕事に責任を持つ人物」…マネージャーやリーダーと便宜的に呼んでいます
p.231 シニアプロダクトマネージャーの職責は何だと思いますか？…職務記述書を書き出して…現在あなたが果たせている責任と、まだできていない責任に踏み出すための成長計画をまとめて
p.232 今会社が成し遂げられていないことで、（あなたが）昇進すると会社が成し遂げられるることは何ですか？…自分の理想とする役割の潜在的なインパクトと、なぜ自分が…ふさわしいのかを考えざるを得ない
p.233 プロダクトの世界では、インディビジュアルコントリビューターの昇進する理由が、リーダーとしては効果的と言えない行動である場合があります…こういった行動を続けると…マイナスの結果をもたらします…自身は燃え尽き、チームはやる気も自身も失う…古い行動様式を忘れ（アンラーン）、新しい行動様式を学ぶ（ラーン）必要がある
p.234 プロダクトリーダー…自分自身に課す基準は自分がチームに課す基準…夜8時までオフィスにいるなら…チームは自分たちも夜8時までいることを期待されていると考えます…やることに圧倒されて忙しすぎ…簡単なエクササイズ…自分がやっていることをすべて積み上げて、チームがゴールに到達するのに役立つ順序に並べる…実際の勤務時間中にまあまあ終わらせられる量の下に線を引く…下にあるものは全部委譲するか、形を変えるか、単にやめる
p.235 優れたプロダクトリーダーになる…残業時間や一生懸命さ以外の方法で自分の価値を測るすべを学ぶこと

15章 良いときと悪いとき

p.251 「ベストプラクティス」、完璧な優先順位づけのフレームワーク、アジャイルの魔法の言葉のどれもプロダクトの成功を保障してくれません…プロダクトマネジメントのプラクティスを使えば…プログラマーはコミュニケーションがうまくなり、マーケティング担当は技術的な仕事にワクワクするようになり、幹部は上位の戦略決定が戦術にもたらす影響を理解できるようになります。….じわじわ広がる対立構造やズレを学習、共有、コラボレーションの機会へと変えてくれる
p.252 自動操縦モードにはかなりリスクが…チームは閉鎖的になって、好奇心を無くし、重要な質問が放置され、重要な機会が失われます。…挑戦的なアイデアや別の説明を探すことが今まで以上に重要になります。
p.253 プロダクト組織にとって本当に良い状況…を示す一般的な指標

• 対立をオープンに議論している
• 全員が自分たちのしている仕事に注力していると感じている：無関心は反対よりもっと危険
• 新しい情報（や新しい人）を脅威ではなく、好機だと考えている：どんな情報でも人でもアイデアでも贈り物

p.254 プロダクトマネジメントがいちばんうまくいっているときというのは、新しい課題を積極的に探し、素直な気持ちで、好奇心を持ち、先入観なく取り組んでいるとき
p.255 遭遇する問題はすべてて自分が解決しなければいけないと感じがち…危険な道…プロダクトの英雄崇拝と殉教という諸刃の剣に陥らないようにするために

• 自分のコントロール外のことをリスト化する：別の会社のロードマップ…他人の野望…すべての問題を解決するのが自分の仕事なのではない
• 重要なことを委譲する機会を探す：チームがステップアップして、共通の成功のために不可欠なことの責任を持ってもらう…グループとして課題に対処する
• チームをまとめるいつものルーティンや儀式に顔を出す：参加しないと…「…チームと過ごす時間はそれほど重要ではない」という強力で危険なメッセージを受け取る

p.258 自分が世界最高の会社で働いていることを想像する…「リーダーが悪い知らせに対応できない」と思わないなら、何を伝えますか？…「この会社は意味のない大量の新しいことをリリースすることにしか興味がない」と思わないなら…次の大きなステップとして何を提案しますか？…個人も…チームや組織も、絶対に変化できます。でもそのためには、変化に踏み出す機会を与えられなければいけません。
p.259 自分の過去の経験をチームや組織に関する未検証の思い込みへと硬化させないようにしましょう。うまくいくかどうか確実ではないことをやってみて、周りの人にあなたとともに学習して成長する機会を与えるようにしましょう。

16章 どんなことでも

p.261 プロダクトマネージャーという肩書きには何もありません…他の人の助けがなければ、意味のあることなど何もできないのです。…信頼を築き続けなければいけません。…プロダクトマネジメントをするには失敗することを学ばなければいけません。言動を裏付ける行動が必要なことを学ばなければいけません
p.262 成功したいなら、良いコミュニケーター、良い同僚、そして良い人間になる必要があります。