これはプロダクトチームのメンバーとなる人の必読書。
勉強になった。
最善を尽くしたにもかかわらず、あるチームメンバーについて、成功への道筋がイメージできなくなることがある。この段階に達したら、決然と行動するのが重要である。
多くのマネジャーにとっては、この原則が最も実践しづらい。コーチングとは
...続きを読む人を育てることなので、必然的に問題点を成長の機会として見ることになる。それ以上に、部下に仕事ができていないと伝えるのは、精神的に最もきつい会話の1つだ。いっそのこと、目を背けてサボったほうが気が楽だろう。
しかしそうすると、マネジャーも、チームも、本人も傷つく。まず、マネジャーは他の人を犠牲にして、この人に必要以上の時間を割いている可能性が高い。次に、他のチームメンバーにはハードワークを求めながら、その人には凡庸であることを許すというシグナルを出してしまっている。それは信頼を損ない、モチベーションを失わせるための確実な道のりだ。最後に、パフォーマンスに問題のある本人が、もっと成功できる可能性のある他の職場に移るチャンスを与えられていない。
■プロダクト担当者らしい行動
傾聴し、協力し、共同学習し、啓蒙し、鼓舞し、手柄を渡し、責めを引き受け、責任を取り、知りえないことを知り、知らないことを認め、謙虚さを示し、会社全体にわたってさまざまな関係を築き、個人レベルで顧客を知り、リーダーシップを発揮することをいう。
■マネジャーのアンチパターン
・マネジャーが無関心
・マネジャーがマイクロマネジメントに回帰する
・マネジャーが話してばかりで相手の話を聞かない
・マネジャーが厳しいフィードバックをしない
・マネジャーが不安定か、あるいは能力不足である
・マネジャーが損切りをしない
つまり、デザイナーやエンジニアと協力して、価値、ユーザビリティー、実現可能性、事業実現性を備えたソリューションを編み出すことだ。それがプロダクトディスカバリーであり、毎日４時間専念すべき仕事である。
■プロダクトチームの４大リスク
１．顧客はこのプロダクトを買うか、あるいは選ぶか？（価値のリスク）
２．ユーザーはこのプロダクトの使い方がわかるか？（ユーザビリティーのリスク）
３．私たちはこのプロダクトを製造・構築できるか？（実現可能性のリスク）
４．ステークホルダーはソリューションを支持するか？（事業実現性のリスク）
５．私たちはこのプロダクトを製造・構築するべきか？（倫理的リスク）
■私が気に入っている面接の質問
１．実行力―どのくらいうまくものごとをやり遂げ、言われなくても正しいことを実行し、複数の目標を同時に追求できるか。
２．創造力―その場にいる人の中で、あなたが一番多くのアイデア、または最も優れたアイデアを提案できたケースはどの程度頻繁にあるか。
３．戦略―現在取り組んでいる内容を俯瞰的に、より広いマーケットやビジョンのコンテキストでとらえ、それを他の人たちに対して明確に提示することが、どのくらいうまくできるか。
４．成長―プロセスの賢い使い方やチームマネジメントなどを通じて取り組みの成果を倍増させる能力に、どのくらい優れているか。
しかし、多くの企業にとっては、問い自体が変化している。
いまや、私に寄せられる問いは、「プロダクトチームが分散し、一部または全体がリモートワークに従事しているという前提で、自分たちが継続的なイノベーションを起こす可能性を最大限に高めるために、ベストプラクティス（最良の方法）をどのように活用するか」に変質している。
■トポロジーとデザイン
ほとんどの企業は、職能横断型プロダクトチーム、少なくともエクスペリエンスチームには、専任のプロダクトデザイナーが必要であることを理解しているこれは、優れたプロダクトをつくるために、プロダクトデザインがどれほど決定的に重要かという認識を示している。
ただし、デザイン部門のリーダーが、「社内エージェンシーモデル」という別の形を好む場合もある。…
…
社内デザインエージェンシーモデルでは、重要な意思決定が行われるときに、デザイナーは通常その場にいない。したがって、デザイナーは―そして最終的にはユーザーが―そのツケを払うことになるのだ。
デザインは社内サービスとして運営するには、あまりに重要だ。デザインマネジャーは、プロダクトマネジャーやテックリードと同様に、プロダクトチームの中でも特に優秀なメンバーが務めなければならない。
スタートアップ企業の創業者やCEOの多くは、有能なエンジニアリング組織と協力して仕事をしたことがありません。そのため、テクノロジーの役割や、エンジニアがプロダクトマネジャーやプロダクトデザイナーのパートナーとして果たすべき貢献について、根本的に誤解していることが珍しくありません。
■チームに答えを導かせるほうが優れている理由
・最も適切なソリューションを判断するのに適した人々は、問題に最も近く、必要なスキルを備えた人々―つまり、プロダクトチームである。
・会社としては、求められるアウトカムを達成するために、チームに責任を持ってもらいたい。
・構築すべき機能を会社からチームに指示してしまったら、その機能が必要な結果をもたらさなかった場合に、チームの説明責任を問えない。
・解決すべき問題と、その問題を最適と思える形で解決するための余地をプロダクトチームに与えれば、チームは問題に対し、はるかに高いオーナーシップを感じるようになる。
・チームが考えついた初めてのソリューションによって求められるアウトカムが生まれなかった場合、チームは、そのソリューションを引き続き繰り返すか、別のアプローチを試すかして、求められるアウトカムを生み出すソリューションを見つけなければならない。
■実在の急成長企業の事例からの最重要ポイント
１．トポロジー、プロダクト戦略、チームの戦略から、四半期中に発生する問題や障害の臨機応変なマネジメントまで、プロダクトリーダーが果たすべき重要な役割。
２．フォーカスとインサイトに基づく真のプロダクト戦略の重要性。
３．チームの目標を積極的にマネジメントする重要性。
４．エンパワーされたチームと伝道師のチームの価値。
５．知ることができる情報とできない情報に関する制約。
６．一部しか功を奏さないとわかっていても複数の方法に賭ける、というリスクマネジメント要素。
７．インサイトを行動に変える際にチームトポロジーが与えるインパクト。
８．リーダーとプロダクトチームに必要なギブアンドテイク。
９．すべてのプロダクトチーム間のおける広範囲の戦略コンテキストの共有の重要性。
10．不確かなことは面倒で、うまくいく保証はない。しかし賢いリーダーはたいてい、うまくやる方法を見つける。それは、チームを信頼し、不確かさを受け入れ、リスクを適切に管理するからである。
■エバンジェリズム10のテクニック
１．プロトタイプを見せよう。
２．ペイン（痛み、悩み）を共有しよう。
３．ビジョンを共有しよう。
４．学びを共有しよう。
５．貢献してくれる人々の名前を気前よく共有しよう。
６．素晴らしいデモをする方法を学ぼう。
７．自己学習をしよう。
８．心の底からときめきを感じよう。
９．熱意を表に出すやり方を学ぼう。
10．プロダクトチームと時間を過ごそう。 
範囲を拡げ過ぎて総花的で表層的で焦点が不明瞭になっている。結果フレームワークとコンセプト紹介がただただ400ページ続いているようになっている。パーツパーツでは有益な情報が豊富なのでWhyとHowのプロダクトマネジメントに絞ってページ数をコンパクトにしたほうが良かった気がする。PMを志す人の指南書に成...続きを読むPosted by ブクログ
伝統的な製造業でのデジタライゼーションをどうするか、という視点で学べるところがないかという気持ちで読んだ。
OKRのストーリーと解説の本
JavaScriptを勉強したくて購入。エンジニア歴1年で、プログラム歴は2年弱くらいの俺。ある程度プログラムの仕組みが分かっていたから、変数や条件分岐や繰り返し、などそこまで新しい言葉が出てきた訳ではなかった。「あぁ、JavaScriptではそうやって書くのね」くらいの感じ。
許可を求めることより許しを乞う方が簡単