INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント

投稿元：

レビューを見る

プロダクトマネジメントにフォーカスした書籍としてよくまとまっている（と思う）。
ただ、あまりに箇条書きが多く、ほとんどの章が「◯◯のための10のポイント」のような構成で食傷気味になる。とはいえ、プロダクトマネジャーとして忘れてはいけないことを思い出す、しっかりした内容だった。
技術やスキルを学んだり訓練したりする内容は無いが、かけだしのプロダクトマネジャーにも良い本だと思う。

投稿元：

レビューを見る

内容が繰り返し書かれている部分もいくつかあるが、基本的に参考になる考え方や手法が紹介されていると思う。

投稿元：

レビューを見る

まだまだ自分はアウトカムの認識が弱いなーとおもった。もっとディスカバリーの観点を意識して捉えてみよう。

チームマネジメントの観点だと外側のチーム（ステークホルダー）と内側のチーム（製品開発）の両方をマネジメントする立ち位置にも見えた。

傭兵ではなく伝道師のチームは指標にもなるし良いことば。

投稿元：

レビューを見る

GAFA、Netflix、Adobeなど最新技術で世界の市場をリードするテック系企業の「プロダクトマネジメント(事業責任者的ポジション)」の手法を紹介した一冊。過去に出版された「INSPIRED」を現代風にアレンジした2ND EDITION。NetflixやAdobeなど、近年業績を大幅に増加させた企業の事例を紹介しつつ、プロダクトマネジメントについて深く掘り下げる。製作の開発から成功するためのプロセス紹介、文化の醸成方法などさまざまな手法が紹介されている。

投稿元：

レビューを見る

考え方はシンプルで分かりやすいが、チャートのイメージがなくじゃあ何を作るの？って言うのがいまいちわかりづらい。
業務に入る前の心構えを学ぶ本

投稿元：

レビューを見る

プロダクトマネジメントにおける各工程から、カルチャーに至るまで、広範囲に成功させるためのスキルセットとチームが記載されている。第5章は良いチームについて具体的に描かれていて大変勉強になった。繰り返し読みたい。

投稿元：

レビューを見る

現代的なIT企業において、重視すべき製品開発のための取り組みや姿勢が簡潔に説明されている。ただ、具体的な方法論について学ぶための本というよりは、どちらかというと、今成功しているプロダクト開発はどういった哲学に拠っているのかなどを知りたい人向けだと思う。

全体としてあまり構成が練られているという感じではなく、繰り返し語られる概念が多かったり、問題提起はするが具体的な解決策を丁寧に説明するような感じではない。特に、本文中で成功する製品開発チームは1週間のうちに10-20のプロトタイプをテストするなど書かれているが、そんなに高頻度で回すイテレーションはどのくらいの忠実度のものが多いのかといった説明がなされることはなく、肩透かしを喰らう。プロトタイピングの中にはA/Bテストも含まれていて、それは既に市場導入の段階に入っているのでは？といった疑問も浮かぶ。Part IIIまではある程度納得感を持って読めるが、Part IV以降の成功する製品開発のためのソリューション部分はかなり物足りなく感じる。

本書の中で良いと思った言説の抜粋（本文ママではない）
・プロダクトマネージャーは誰よりも製品のことと顧客のこと、およびステークホルダーのことと市場のことを理解して説明できるようになっていなければならない
・アウトプットではなくアウトカムにコミットする（リリースで終わらさず、ビジネス上の課題を解決するまで取り組み続ける）
・成功のためには何度も繰り返し製品開発のイテレーションを回さなければならないということを知る
・他のどのリスクよりも「価値のリスク」が最も重要で、顧客にとって価値のある製品を真っ先に考えなければならない

投稿元：

レビューを見る

プロダクトマネジメントの全体像を概観するのに良い。ただ噂に聞いていた通り訳がなかなかに気持ち悪く、原書を読んでみたいなと思いました…

投稿元：

レビューを見る

書いてあることはもっともだけど話の全体感が掴みにくく、今ひとつ読みづらかった。プロダクトマネジメント(ビルドトラップ本)の方が簡潔にまとまっていて良いかも

投稿元：

レビューを見る

最初の方はいい本かなーと感じていましたが、中盤からは抽象的な議論になってきた印象。大事なことは書かれているのですがどこから手をつけたらいいのかわからないくらいやらなければならないことが多い感じ。

投稿元：

レビューを見る

プロダクトマネジメントのお勉強。

・作るものに価値がなければ、開発チームがどれほど優秀だろうと関係ない
・失敗の根本原因を探っていく中で、何を作るかを判断したのはプロダクトマネージャーだとわかった。

■優れた開発チームに働いている包括的な３原則
１．リスクには最後ではなく最初に取り組む
２．製品の定義付けとデザインは、順を追ってではなく、協調させながら同時に実行される
３．最後に、大切なのは機能を実装することではなく、問題を解決することである

■POとPM
　POは、アジャイル開発チームでプロダクトバックログに責任を持つ人の役割の名前。
　POの役割に関する講習を受けたり資格を取ったりしても、PMの責任の一部をカバーするだけ。

■デザイナー
　現代の優秀な開発チームでは、少なくとも機能がデザインを決めるのと同じぐらい、デザインが機能を特徴づける。これは極めて重要な考え方である。それを実現させるには、デザイナーを製品開発チームの一級のメンバーにし、プロダクトマネジャーの隣に座らせなければならない。デザインを脇役にしてはいけない。
　デザイナーに製品開発チームに尽くしてもらえるようになったら、そのデザイナーとの良好で健全な関係への鍵が５つある。
　１．デザイナーに隣にいてもらうために必要なことは何でもする。
　２．デザイナーには、すべてのアイデアが生まれるところに立ち会ってもらう。
　３．デザイナーには、顧客やユーザーとの交流にできるだけ多く参加してもらう。顧客やユーザーのことを一緒に学ぶのだ。
　４．自分自身のデザインのアイデアをデザイナーに伝えたい、という誘惑と闘う。問題をデザイナー自身が解決するように、デザイナーにできるだけ大きな機会を与える。
　５．デザイナーに、イテレーションを迅速にかつ頻繁にするよう促す。そのためには、初期のイテレーションでデザインの詳細をとやかく言わないようにする。もっと言うと、特定のデザインアプローチを繰り返すのではなく、自由にほかの解決策を探るように勧める。

■リーダーの役割
　…、技術組織のリーダーは技術的負債を管理するための明確な戦略を持っていなければならない。
　繰り返すが、これは、大規模で複雑なビジネスシステム、特に多くのレガシーシステムを持つ企業には絶対に不可欠な役割だ。そして技術組織のリーダーは、組織の中で良く目立ち、組織内の誰もが助けを求められるように配置されるべきだ。

■製品ビジョンの原則
１．WHYから始める。
２．解決策ではなく問題に恋をする。
３．臆病にならずに大きな視野でビジョンを考える。
４．チームを混乱させることを恐れない。あなたがしなくても誰かがそうする。
５．製品ビジョンは人の心を揺さぶらなければならない。
６．関連性があり意味のあるトレンドを見つけ出し、取り入れる。
７．パックがある場所ではなく、パックが向かっているところに滑って行く。
８．ビジョンには頑固で、ディテールには柔軟でいる。
９．どんな製品ビジョンも信じて賭けることだと考える。
10．絶え間なく、粘り強く説得して回る。

■製品戦略の原則
１．１度につき１つのターゲットやペルソナに集中する。
２．製品戦略はビジネス戦略と整合する必要がある。
３．製品戦略は販売戦略やゴー・トゥ・マーケット戦略と連携する必要がある。
４．ライバルではなく、顧客のことだけを考える。
５．組織全体で戦略についてコミュニケーションを取る。

■PMが夢を売るためのアドバイス
１．プロトタイプを使う。
２．悩みを共有する。
３．ビジョンを共有する。
４．学習したことを惜しみなく共有する
５．成果を惜しみなく共有する
６．優れたデモをおこなう方法を学ぶ
７．常に学習に励む
８．心からワクワクする。
９．熱意の見せ方を学ぶ。
10．チームと一緒に時間を過ごす。

■プロトタイプテストのテクニック
・実際にユーザビリティテストを始めるとき、テスト対象はまだプロトタイプで、ごく初期の製品のアイデアにすぎず、実際の製品ではないことを被験者にちゃんと伝えよう。また、良い悪いにかかわらず、被験者の率直なフィードバックによって開発チームが感情を害したりしないことを説明しよう。あなたはプロトタイプの基にあるアイデアをテストするのであって、被験者をテストするのではない。被験者には合格も不合格もない。合格や不合格の評価がされるのはプロトタイプだけである。それをきちんと伝えよう。
・タスクを開始する前にもう1つすべきことがある。被験者がプロトタイプのランディングページを見てあなたの意図を理解できたかどうかを確かめよう。特に、被験者にとって価値があったり、被験者の興味を引いたりするはずのものが理解されたかどうかを確かめよう。いったんタスクが始まったら新規ビジターというコンテキストが失われてしまうので、そのチャンスを無駄にしてはいけない。予想と実際のプロトタイプの動作とのギャップを橋渡しする上で、ランディングページが極めて重要なことがわかるだろう。
・テスト中は、ユーザーを批評モードではなく使用モードにしておくために、できるかぎりのことをしよう。重要なのは、ユーザーが実行しようと思うタスクが簡単にできるかどうかである。ユーザーがページ上の何かを見苦しいと思ったり、移動や変更すべきだと考えたりするのは問題ではない。時々、勘違いをしたテスターが、ユーザーに「このページで3カ所変更するとすればどこですか?」などという質問をすることがある。私は、ユーザーがたまたまプロダクトデザイナーだったりしないかぎり、そんなことには関心がない。もしユーザーが自分が本当にしたいことをわかっているなら、ソフトウェアはずいぶん作りやすいだろう。だから、ユーザーが何を言うかではなく何をするかを観察するのだ。
・テストをしている間に必要とされるスキルは黙っていることだ。誰かが悪戦苦闘しているのを見ると、たいていの人はつい手を貸しあげたくなるものだ。そうした衝動は抑えなければならない。ここでのあなたの仕事は救いようのない話し下手になることだ。沈黙に慣れよう。沈黙こそあなたの友だちだ。
・予期される主なケースは3つある。
(1)ユーザーは何の問題もなくタスクをやり遂げ、支援の必要はなかった。
(2)ユーザーは苦労し、多少不満をもらしたが、最終的にはタスクをやり遂げた。
(3)ユーザーは非常にいらだち、諦めた。
中にはすぐに諦めるユーザーがいるので、もう少し粘ってみるように励ます必要が生じるかもしれない。だが、ユーザーがその製品を本当に諦めて競合他社に行くと確信できるところまで来たら、完全に見限ったと認識しよう。
・一般的に、どんな形にせよ手助けをしたり誘導尋問をしたりすることは避けるべきである。ユーザーがページを上下にスクロールさせて、明らかに何かを探しているように見えるときは、何を探しているのか具体的に聞いてもかまわない。その情報はあなたにとって非常に価値があるからだ。考えていることをそのまま言葉にし続けてほしいとユーザーに頼む人がいるが、これは自然な行動ではないので、ユーザーを批評モードにしてしまいがちだ。
・オウムのようにふるまおう。これはいろんな意味で役に立つ。第1に、ユーザーを誘導するのを避けられる。ユーザーが黙っているのが気まずくてどうしても我慢できないときは、ユーザーがしていることを言葉にして伝えよう。「右側のリストを見ていますね」という具合だ。これによってユーザーは、自分がしようとしていること、探しているもの、あるいはほかの何であれ話そうという気になるだろう。もしユーザーが質問をしたら、誘導するような答えをするのではなく、その質問をオウム返しにしよう。たとえばユーザーが「ここをクリックしたら新しいエントリーが作れるのだろうかと思っているのですか?」と聞き返すのだ。ユーザーはあなたの質問に答えようとして、大概、「はい、作れると思います」といった具合に、そこから話を続けるだろう。第2に、オウム返しは価値判断を誘導することを避けるのにも役立つ。あなたが「よくできました!」と言いたくなったら、その代わりに「新しいエントリーができました」と言うのである。第3に、重要な点をオウム返しすると、それを書き留めるための時間の余裕ができるので記録係が助かる。
・基本的に、あなたが取り組むのは、ターゲットユーザーがその問題についてどう考えているのかを理解し、プロトタイプの中で、ソフ トウェアが提示するモデルが、ユーザーの問題の捉え方と食い違う場所を特定することである。つまり、それは直感に反しているを意味している。運良くその場所を特定できたら、通常、修正は難しくなく、製品にとって大きな成功につながる可能性がある。
・ボディーランゲージや声のトーンからも多くのことがわかる。ユーザーがあなたのアイデアを気に入らないときはひりひりと伝わってくるし、心から気に入ったときもまたはっきりとわかる。プロトタイプを気に入れば、ユーザーは必ずと言っていいほど、製品がリリースされたらメールで知らせてほしいと言うし、心底気に入れば、 リリース前にあなたから入手しようとするだろう。

■良い製品開発チーム／悪い製品開発チーム
・良い開発チームは人を魅了する製品ビジョンを持っていて、伝道師のような情熱でそれを追求する。悪い開発チームは傭兵である。
・良い開発チームがひらめきや製品のアイデアを得るのは、自分たちのビジョンや目標からであり、顧客が苦労している様子を見ることや、自分たちの製品を使うことで顧客が生み出すデータを分析すること、実際の問題を解決するために常に新しいテクノロジーを適用しようとすることからである。悪い開発チームは販売部門や顧客か ら要望を集める。
・良い開発チームは重要なステークホルダーが誰と誰かを知っていて、ステークホルダーが負っている制約を理解し、ユーザーや顧客に役立つだけではなく、ビジネスの制約を守ったソリューションを考え出すことに全力を注ぐ。悪い開発チームはステークホルダーから要望を集める。
・良い開発チームは多くのテクニックに熟達していて、製品のアイデ アを迅速に試し、どれが本当にビルドする価値があるかを判断する。悪い開発チームは会議を開き、優先順位を付けたロードマップを作成する。
・良い開発チームは会社中の頭の切れる第一人者やリーダーとブレーンストーミングをするのが大好きである。悪い開発チームは、チーム外の人が何かするように助言すると不機嫌になる。
・良い開発チームは、製品開発、デザイン、エンジニアリングの各担当者が並んで座っていて、職能間のギブアンドテイクや、ユーザーエクスペリエンス、実現技術を活用する。悪い開発チームはそれぞれのサイロに閉じこもり、自分たちの協力が欲しい場合は文書の形で要望したり会議を設定したりするように求める。
・良い開発チームはイノベーションのために常に新しいアイデアを試しているが、必ず収益とブランドを守るように配慮している。悪い開発チームはテストをする許可が出るのをひたすら待っている。
・良い開発チームは、強力な製品デザインといった、成功する製品を生み出すのに必要なスキルセットをチームの中に持っていると胸を張る。悪い開発チームはプロダクトデザイナーが何をする人かすら知らない。
・良い開発チームは、製品発見においてエンジニアが毎日プロトタイプを試す時間を確保し、製品をより良くする方法について自分たちの考えを提案できるようにする。悪い開発チームはスプリントプランニングのときにエンジニアにプロトタイプを見せるので、エンジニアは推測するしかない。
・良い開発チームは、毎週エンドユーザーや顧客と直接関わって、顧客をよりよく理解し、自分たちの最新のアイデアに対する顧客の反応を見る。悪い開発チームは自分たちが顧客だと思っている。
・良い開発チームは、自分たちが気に入っているアイデアの多くが、 結局、顧客の役に立たないことを自覚していて、役立ちそうなものでも、望んだようなアウトカムを生み出すところに到達するには何回かのイテレーションが必要になると考えている。悪い開発チームはロードマップにあるものをビルドするだけであり、予定の期日に間に合い、品質を確認できれば満足する。
・良い開発チームはスピードが必要であり、イテレーションがどれくらい速くできるかがイノベーションの鍵だと理解しており、そのスピードは強制からではなく、適切なテクニックから生まれることを知っている。悪い開発チームは、自分たちの仕事が遅くなるのは同僚が一生懸命働かないからだと愚痴をこぼす。
・良い開発チームは、要望を評価し、顧客にもビジネス���も有益で実行可能なソリューションができたことを確認したあとで、ハイインテグリティーコミットメントを作成する。悪い開発チームは、販売主導だと不満を言う。
・良い開発チームは、自分たちの製品がどんなふうに使われているかを知るために製品に計装し、データに基づいて調整する。悪い開発チームは、分析と報告は、あればいいが、なくてもかまわないと考えている。
・良い開発チームは、小さなリリースをコンスタントに続ければ、顧客に、より安定したソリューションを提供できることがわかっているので、継続的にインテグレーションをおこなってリリースする。 悪い開発チームは、骨の折れるインテグレーション段階の最後に手動でテストをおこない、すべてを1度にリリースする。
・良い開発チームはリファレンスカスタマーにこだわる。悪い開発チームは競争相手にこだわる。 ・良い開発チームは業績に大きく貢献したときに祝う。悪い開発チームは最終的に何かをリリースしたときに祝う。

■イノベーションが失われる最大の理由
１．顧客中心の文化。AmazonのCEO、ジェフ・ベゾスが言うように、「私たちにとってこのうえなくありがたいことに、顧客はいつも満たされていない。顧客自身が満足していると言い、売れ行きが順調なときですら不満を持っている。自覚がなかったとしても、顧客は何かがもっと良くならないかと願っている。だからこそ、私たちは顧客を喜ばせたいという欲求に駆られて、顧客のために新しいものを生み出すのだ」。このように、顧客に焦点を合わせる姿勢を持っていない企業、つまり、直接、頻繁に顧客と接触しない企業は、情熱を失い、重要なインスピレーションの源を失うのである。
２．魅力的な製品ビジョン。多くの企業は、スケールアップを遂げる頃には、当初の製品ビジョンのほとんどを実現し、開発チームは次は何なのかをつかもうと苦闘する。この状況は、ビジョンの番人の役割を果たしていた創業者がすでに現場を離れていると、さらに深刻になる。この場合、誰かほかの人、通常はCEOや製品開発VPが乗り出して空白を埋める必要がある。
３．的を絞った製品戦略。製品開発を失敗させる最も確実な方法の1つは、同時にすべての人を喜ばせようとすることである。だが、大企業はこの事実を忘れてしまいがちだ。製品戦略では、製品開 発チームが的を絞るための、論理的で意図的な一連のターゲット市場が明確に示される必要がある。
４．強力なプロダクトマネジャー。製品開発にイノベーションが起こらない大きな理由は、強力で有能なプロダクトマネジャーがいな いことだ。会社が小さいときはCEOか共同創業者の1人がこの 役割を果たすが、規模が大きくなると、それぞれの製品開発チームに強力で有能なプロダクトマネジャーが必要になる。
５．安定した製品開発チーム。持続的なイノベーションには、開発チームが、製品開発の世界や、テクノロジーや、顧客の悩みを学ぶ機会を共有してきたことが必須条件の1つになる。もし開発チームのメンバーが絶えず入れ替わっていたら、こういうことは、起こらない。
６．製品発見へのエンジニアの参加。イノベーションの鍵を握るのは、しばしば開発チームのエンジニアだが、これが意味するのは、(a)エンジニアが製品開発���最後だけではなく、最初から参加し、(b)エンジニアが直接、顧客の悩みを聞く、ということである。
７．企業の勇気。よく知られていることだが、多くの企業は規模が大きくなるにつれてリスクを避けるようになる。確かに失うものは多くなる。しかし、最も優れたIT製品企業は、最もリスクの大 きい戦略はリスクを冒すのをやめる戦略だと知っている。私たちは仕事のやり方について賢明でなければならないが、現在のビジネスを混乱させるリスクをあえて冒そうという意欲は、持続的なイノベーションに不可欠である。
８. 権限を与えられた製品開発チーム。たとえあなたの組織がベストプラクティスを使ってスタートしたとしても、多くの組織はスケ ールアップするにつれて後退する。もしあなたが開発チームに機能のロードマップを渡すだけに逆戻りしたら、もはや権限を与えられた製品開発チームのメリットは期待できない。権限委譲というのは、開発チームが、最も適切だと考える方法で与えられたビ
ジネスの問題に取り組み、解決できることを意味する。
９．製品開発のマインドセット。ITのマインドセットを持つ組織では、製品開発チームはビジネスのニーズに応えるために存在する。一方、製品開発マインドを持つ組織では、製品開発チームはビジ ネスのニーズに合った形で顧客の役に立つために存在する。この2つの姿勢は結果として数多くの大きな違いを生む。
10．イノベーションを起こすための時間。スケールアップすると、製品開発チームは、これまでの業務をこなすだけですべての時間を使ってしまう可能性が高くなる。バグを修正し、ビジネスのさ まざまな部署のために機能を実装し、技術的負債に対処し、といった具合だ。もしあなたがこういう状況にあるなら、イノベーションが起こらなくても驚くに当たらない。こうした業務の中には当然やるべき健全なものもあるが、開発チームがもっと困難でもっと影響力の強い問題を追求する時間を、ぜひとも確保しなければならない。

■スピードが失われる最大の理由
１．技術的負債。しばしば、アーキテクチャーのために、製品の急速な進化が円滑に進められなかったり、できなかったりすることがある。これは一晩で解決できるような問題ではない。協調的な取り組みを根気よく続ける必要がある。
２．強力なプロダクトマネジャーの不在。強力で有能なプロダクトマネジャーがいないことは、製品開発に時間がかかる典型的な原因である。力のないプロダクトマネジャーの影響はさまざまな形で表れるが、開発チームが伝道師のチームではなく傭兵のチームになることで目に見えてわかる。プロダクトマネジャーが開発チームに動機や使命感を与えてこなかったか、開発チームがプロダクトマネジャーへの信頼を失っているかだ。
３．デリバリーマネジメントの欠如。デリバリーマネジャーの最重要な機能は障害を取り除くことだが、障害のリストは、技術が成長するにつれて非線形的に増加する。ほとんどの障害は、誰かが積極的に排除しないかぎり、すぐにはなくならない。
４．リリースサイクルの長期化。スピードの遅い開発チームの多くはリリースの間隔が長すぎる。開発チームは2週間に1回以上の類度でリリースしなければならない(特に優秀な開発チームになる と1日に何回もリリースする)。これを改善しようとすれば、通常、開発チームが迅速に作業し、自信を持ってリリースできるように、テストの自動化やリリースの自動化を真剣に考える必要がある。
５．製品ビジョンと戦略の欠如。仕事の全体像と、目前の仕事がどのように全体に貢献するかについて、開発チームが明確なビジョンを持つことが不可欠である。
６．同じ場所にいて、長続きする開発チームの不在。開発チームがいくつかの場所に分散していて、さらに悪いことにエンジニアリン グを外注している場合は、イノベーションの機会が激減する上に、仕事のスピードが大きく損なわれるだろう。単純なコミュニケーションさえ困難になる。多くのアウトソーシング会社が加わることで、連携し、意思疎通しなければならない人々の層が増えると、大概、事態は悪化する。
７．製品発見に早い時期からエンジニアを参加させない。エンジニアはアイディエーションを始めるときから製品発見に加わる必要がある。もし、プロダクトマネジャーやデザイナーが調整できる早い時期からエンジニアを製品発見のプロセスに加えたら、エンジニアは、たいてい、もっと迅速に実装できる別のアプローチを提案するだろう。エンジニアの参加が遅れたら、重要な提案を製品発見に取り入れるのが間に合わなくなる。
８．製品発見にプロダクトデザイナーを使わず、エンジニアがビルドしている間にブロダクトデザインの仕事をさせようとする。プロダクトデザイナーが製品発見に参加しなければ仕事のスピードが低下するし、ひどいデザインになる。
９. 優先順位を変える。優先順位が目まぐるしく変わると深刻な混乱が生じ、全体のスループットとやる気を著しく低下させる。
10. コンセンサス文化。多くの組織がコンセンサスを得ようと努力する。これは、大概、善意から生まれるが、実際には決断が非常に難しいことを意味しており、あらゆることが遅々として進まな
くなる。

■強いイノベーション文化を持つとは？
・実験の文化―開発チームはテストができることを知っている。中には成功するものもあるが多くは失敗するということが受け入れられ、理解されている。
・開かれた心の文化―開発チームは、優れたアイデアはどこからでも生まれるとわかっているし、最初は必ずしもその良さがはっきりわからないことを知っている。
・権限委譲の文化——個人もチームも、アイデアを試す権限を与えられていると感じている。
・テクノロジーの文化——真のイノベーションは、顧客がきっかけになるのと同様に、新しいテクノロジーとデータの分析をきっかけにして生まれることを、開発チームはわかっている。
・ビジネスと顧客に精通した開発チームの文化―開発者を含む開発チームは、ビジネスのニーズと制約を十分に理解しており、ユーザーや顧客への深い理解(とアクセス方法)を持っている。
・多様なスキルセットとスタッフの文化―開発チームは、さまざまなスキルとさまざまなスタッフの経歴が、ソリューションのイノベーション、特にエンジニアリング、デザイン、製品開発に貢献することを実感している。
・製品発見テクニックの文化―アイデアを(ブランドと収益、顧客 と仲間を守りながら)迅速かつ���全にテストするための環境が整っている。

■強い実行力文化を持つとは？
・切迫感の文化―人々が戦時であるかのように感じていて、迅速に動く方法を見つけられなければ悲惨なことが起こりかねないと思っている。
・ハイインテグリティーコミットメントの文化―開発チームは責任を負う必要性（と能力）を理解しているが、同時にハイインテグリティーコミットメントも主張する。
・権限委譲の文化―開発チームが、責務を果たすのに必要なことをするためのツールと、資源と、許可を持っているかのように感じている。
・説明責任の文化―スタッフや開発チームは、自分たちの責務を果たすことに強い責任感を抱いている。説明責任はまた、結果にも関わる。重大な失敗を繰り返す場合を除けば必ずしも解雇されることはないが、同僚の間での評判に影響する可能性は高い。
・協力の文化―開発チームの自律性や権限委譲は大切だが、開発チームには、最も大きく最も意義深い目標を達成するために協力するという、はるかに重要なニーズがあることを理解している。
・成果の文化―焦点はアウトプットに置かれているのか、それとも成果に置かれているのか?
・認知の文化―開発チームは、しばしば、報われたものや受け入れられたものからヒントを得る。新しく素晴らしいアイデアを考えついた開発チームと、とても過酷な責務を果たした開発チームの、どちらが報われるべきだろうか?そして、責務を果たせないことが許容されてしまう場合、そのメッセージは何なのだろう?

　これらの特徴がそれぞれの文化を定義するのに役立つとすれば、次のようなかなり難しい問題が生じる。
・イノベーションの文化は、何らかの意味で、実行力の文化と本質的に対立するのだろうか?
・強い実行力の文化は、ストレスの大きい(あるいは劣悪な)労働環境につながるのではないか?
・リーダーを含めて、どんなタイプの人間が、それぞれの文化に引き付けられ、必要とされるのか?


　現実には、持続的なイノベーションと実行力のどちらにも非常に強い企業が存在する。Amazonはその最も良い例の1つだ。しかし、よく知られているように、Amazonの労働環境は気の弱い人には向かない。私が見たかぎり、並外れて実行力が強い企業のほとんどは、極めて厳しい職場である。
　多くの企業と仕事をしてきた私の経験では、イノベーションと実行力の両方に優れている企業はほんのわずかしかない。多くの企業は実行力に優れているがイノベーションには弱い。イノベーションには強いが実行力はまあまあという企業はそれよりも数が少ない。そして、うんざりするほどの数の企業が、イノベーションも実行力も乏しいのだ(ほとんどは、製品開発の魔法をとっくの昔に失ったが、まだ強いブランドを維持し、寄り掛かれる顧客基盤を持っている古い企業である)。
　いずれにせよ、私があなたやあなたの開発チームにしてほしいのは、イノベーションと実行力の両面から自分自身を見直し、あなたが、チームや企業として、どの位置に行きたいのか、どの位置に行く必要があると考えているのかを自分に問いかけることである。

投稿元：

レビューを見る

プロダクトマネジメントのお勉強。

・作るものに価値がなければ、開発チームがどれほど優秀だろうと関係ない
・失敗の根本原因を探っていく中で、何を作るかを判断したのはプロダクトマネージャーだとわかった。

■優れた開発チームに働いている包括的な３原則
１．リスクには最後ではなく最初に取り組む
２．製品の定義付けとデザインは、順を追ってではなく、協調させながら同時に実行される
３．最後に、大切なのは機能を実装することではなく、問題を解決することである

■POとPM
　POは、アジャイル開発チームでプロダクトバックログに責任を持つ人の役割の名前。
　POの役割に関する講習を受けたり資格を取ったりしても、PMの責任の一部をカバーするだけ。

■デザイナー
　現代の優秀な開発チームでは、少なくとも機能がデザインを決めるのと同じぐらい、デザインが機能を特徴づける。これは極めて重要な考え方である。それを実現させるには、デザイナーを製品開発チームの一級のメンバーにし、プロダクトマネジャーの隣に座らせなければならない。デザインを脇役にしてはいけない。
　デザイナーに製品開発チームに尽くしてもらえるようになったら、そのデザイナーとの良好で健全な関係への鍵が５つある。
　１．デザイナーに隣にいてもらうために必要なことは何でもする。
　２．デザイナーには、すべてのアイデアが生まれるところに立ち会ってもらう。
　３．デザイナーには、顧客やユーザーとの交流にできるだけ多く参加してもらう。顧客やユーザーのことを一緒に学ぶのだ。
　４．自分自身のデザインのアイデアをデザイナーに伝えたい、という誘惑と闘う。問題をデザイナー自身が解決するように、デザイナーにできるだけ大きな機会を与える。
　５．デザイナーに、イテレーションを迅速にかつ頻繁にするよう促す。そのためには、初期のイテレーションでデザインの詳細をとやかく言わないようにする。もっと言うと、特定のデザインアプローチを繰り返すのではなく、自由にほかの解決策を探るように勧める。

■リーダーの役割
　…、技術組織のリーダーは技術的負債を管理するための明確な戦略を持っていなければならない。
　繰り返すが、これは、大規模で複雑なビジネスシステム、特に多くのレガシーシステムを持つ企業には絶対に不可欠な役割だ。そして技術組織のリーダーは、組織の中で良く目立ち、組織内の誰もが助けを求められるように配置されるべきだ。

■製品ビジョンの原則
１．WHYから始める。
２．解決策ではなく問題に恋をする。
３．臆病にならずに大きな視野でビジョンを考える。
４．チームを混乱させることを恐れない。あなたがしなくても誰かがそうする。
５．製品ビジョンは人の心を揺さぶらなければならない。
６．関連性があり意味のあるトレンドを見つけ出し、取り入れる。
７．パックがある場所ではなく、パックが向かっているところに滑って行く。
８．ビジョンには頑固で、ディテールには柔軟でいる。
９．どんな製��ビジョンも信じて賭けることだと考える。
10．絶え間なく、粘り強く説得して回る。

■製品戦略の原則
１．１度につき１つのターゲットやペルソナに集中する。
２．製品戦略はビジネス戦略と整合する必要がある。
３．製品戦略は販売戦略やゴー・トゥ・マーケット戦略と連携する必要がある。
４．ライバルではなく、顧客のことだけを考える。
５．組織全体で戦略についてコミュニケーションを取る。

■PMが夢を売るためのアドバイス
１．プロトタイプを使う。
２．悩みを共有する。
３．ビジョンを共有する。
４．学習したことを惜しみなく共有する
５．成果を惜しみなく共有する
６．優れたデモをおこなう方法を学ぶ
７．常に学習に励む
８．心からワクワクする。
９．熱意の見せ方を学ぶ。
10．チームと一緒に時間を過ごす。

■プロトタイプテストのテクニック
・実際にユーザビリティテストを始めるとき、テスト対象はまだプロトタイプで、ごく初期の製品のアイデアにすぎず、実際の製品ではないことを被験者にちゃんと伝えよう。また、良い悪いにかかわらず、被験者の率直なフィードバックによって開発チームが感情を害したりしないことを説明しよう。あなたはプロトタイプの基にあるアイデアをテストするのであって、被験者をテストするのではない。被験者には合格も不合格もない。合格や不合格の評価がされるのはプロトタイプだけである。それをきちんと伝えよう。
・タスクを開始する前にもう1つすべきことがある。被験者がプロトタイプのランディングページを見てあなたの意図を理解できたかどうかを確かめよう。特に、被験者にとって価値があったり、被験者の興味を引いたりするはずのものが理解されたかどうかを確かめよう。いったんタスクが始まったら新規ビジターというコンテキストが失われてしまうので、そのチャンスを無駄にしてはいけない。予想と実際のプロトタイプの動作とのギャップを橋渡しする上で、ランディングページが極めて重要なことがわかるだろう。
・テスト中は、ユーザーを批評モードではなく使用モードにしておくために、できるかぎりのことをしよう。重要なのは、ユーザーが実行しようと思うタスクが簡単にできるかどうかである。ユーザーがページ上の何かを見苦しいと思ったり、移動や変更すべきだと考えたりするのは問題ではない。時々、勘違いをしたテスターが、ユーザーに「このページで3カ所変更するとすればどこですか?」などという質問をすることがある。私は、ユーザーがたまたまプロダクトデザイナーだったりしないかぎり、そんなことには関心がない。もしユーザーが自分が本当にしたいことをわかっているなら、ソフトウェアはずいぶん作りやすいだろう。だから、ユーザーが何を言うかではなく何をするかを観察するのだ。
・テストをしている間に必要とされるスキルは黙っていることだ。誰かが悪戦苦闘しているのを見ると、たいていの人はつい手を貸しあげたくなるものだ。そうした衝動は抑えなければならない。ここでのあなたの仕事は救いようのない話し下手になることだ。沈黙に慣れよう。沈黙こそあなたの友だちだ。
・予期される主なケースは3��ある。
(1)ユーザーは何の問題もなくタスクをやり遂げ、支援の必要はなかった。
(2)ユーザーは苦労し、多少不満をもらしたが、最終的にはタスクをやり遂げた。
(3)ユーザーは非常にいらだち、諦めた。
中にはすぐに諦めるユーザーがいるので、もう少し粘ってみるように励ます必要が生じるかもしれない。だが、ユーザーがその製品を本当に諦めて競合他社に行くと確信できるところまで来たら、完全に見限ったと認識しよう。
・一般的に、どんな形にせよ手助けをしたり誘導尋問をしたりすることは避けるべきである。ユーザーがページを上下にスクロールさせて、明らかに何かを探しているように見えるときは、何を探しているのか具体的に聞いてもかまわない。その情報はあなたにとって非常に価値があるからだ。考えていることをそのまま言葉にし続けてほしいとユーザーに頼む人がいるが、これは自然な行動ではないので、ユーザーを批評モードにしてしまいがちだ。
・オウムのようにふるまおう。これはいろんな意味で役に立つ。第1に、ユーザーを誘導するのを避けられる。ユーザーが黙っているのが気まずくてどうしても我慢できないときは、ユーザーがしていることを言葉にして伝えよう。「右側のリストを見ていますね」という具合だ。これによってユーザーは、自分がしようとしていること、探しているもの、あるいはほかの何であれ話そうという気になるだろう。もしユーザーが質問をしたら、誘導するような答えをするのではなく、その質問をオウム返しにしよう。たとえばユーザーが「ここをクリックしたら新しいエントリーが作れるのだろうかと思っているのですか?」と聞き返すのだ。ユーザーはあなたの質問に答えようとして、大概、「はい、作れると思います」といった具合に、そこから話を続けるだろう。第2に、オウム返しは価値判断を誘導することを避けるのにも役立つ。あなたが「よくできました!」と言いたくなったら、その代わりに「新しいエントリーができました」と言うのである。第3に、重要な点をオウム返しすると、それを書き留めるための時間の余裕ができるので記録係が助かる。
・基本的に、あなたが取り組むのは、ターゲットユーザーがその問題についてどう考えているのかを理解し、プロトタイプの中で、ソフ トウェアが提示するモデルが、ユーザーの問題の捉え方と食い違う場所を特定することである。つまり、それは直感に反しているを意味している。運良くその場所を特定できたら、通常、修正は難しくなく、製品にとって大きな成功につながる可能性がある。
・ボディーランゲージや声のトーンからも多くのことがわかる。ユーザーがあなたのアイデアを気に入らないときはひりひりと伝わってくるし、心から気に入ったときもまたはっきりとわかる。プロトタイプを気に入れば、ユーザーは必ずと言っていいほど、製品がリリースされたらメールで知らせてほしいと言うし、心底気に入れば、 リリース前にあなたから入手しようとするだろう。

■良い製品開発チーム／悪い製品開発チーム
・良い開発チームは人を魅了する製品ビジョンを持っていて、伝道師のような情熱でそれを追求する。悪い開発チームは傭兵である。
・良い開発チームがひらめきや製品のアイデアを得るの��、自分たちのビジョンや目標からであり、顧客が苦労している様子を見ることや、自分たちの製品を使うことで顧客が生み出すデータを分析すること、実際の問題を解決するために常に新しいテクノロジーを適用しようとすることからである。悪い開発チームは販売部門や顧客か ら要望を集める。
・良い開発チームは重要なステークホルダーが誰と誰かを知っていて、ステークホルダーが負っている制約を理解し、ユーザーや顧客に役立つだけではなく、ビジネスの制約を守ったソリューションを考え出すことに全力を注ぐ。悪い開発チームはステークホルダーから要望を集める。
・良い開発チームは多くのテクニックに熟達していて、製品のアイデ アを迅速に試し、どれが本当にビルドする価値があるかを判断する。悪い開発チームは会議を開き、優先順位を付けたロードマップを作成する。
・良い開発チームは会社中の頭の切れる第一人者やリーダーとブレーンストーミングをするのが大好きである。悪い開発チームは、チーム外の人が何かするように助言すると不機嫌になる。
・良い開発チームは、製品開発、デザイン、エンジニアリングの各担当者が並んで座っていて、職能間のギブアンドテイクや、ユーザーエクスペリエンス、実現技術を活用する。悪い開発チームはそれぞれのサイロに閉じこもり、自分たちの協力が欲しい場合は文書の形で要望したり会議を設定したりするように求める。
・良い開発チームはイノベーションのために常に新しいアイデアを試しているが、必ず収益とブランドを守るように配慮している。悪い開発チームはテストをする許可が出るのをひたすら待っている。
・良い開発チームは、強力な製品デザインといった、成功する製品を生み出すのに必要なスキルセットをチームの中に持っていると胸を張る。悪い開発チームはプロダクトデザイナーが何をする人かすら知らない。
・良い開発チームは、製品発見においてエンジニアが毎日プロトタイプを試す時間を確保し、製品をより良くする方法について自分たちの考えを提案できるようにする。悪い開発チームはスプリントプランニングのときにエンジニアにプロトタイプを見せるので、エンジニアは推測するしかない。
・良い開発チームは、毎週エンドユーザーや顧客と直接関わって、顧客をよりよく理解し、自分たちの最新のアイデアに対する顧客の反応を見る。悪い開発チームは自分たちが顧客だと思っている。
・良い開発チームは、自分たちが気に入っているアイデアの多くが、 結局、顧客の役に立たないことを自覚していて、役立ちそうなものでも、望んだようなアウトカムを生み出すところに到達するには何回かのイテレーションが必要になると考えている。悪い開発チームはロードマップにあるものをビルドするだけであり、予定の期日に間に合い、品質を確認できれば満足する。
・良い開発チームはスピードが必要であり、イテレーションがどれくらい速くできるかがイノベーションの鍵だと理解しており、そのスピードは強制からではなく、適切なテクニックから生まれることを知っている。悪い開発チームは、自分たちの仕事が遅くなるのは同僚が一生懸命働かないからだと愚痴をこぼす。
・良い開発チームは、要望を評価し、顧客にもビジネスにも有益で実行可能なソリューションができたことを確認したあとで、ハイインテグリティーコミットメントを作成する。悪い開発チームは、販売主導だと不満を言う。
・良い開発チームは、自分たちの製品がどんなふうに使われているかを知るために製品に計装し、データに基づいて調整する。悪い開発チームは、分析と報告は、あればいいが、なくてもかまわないと考えている。
・良い開発チームは、小さなリリースをコンスタントに続ければ、顧客に、より安定したソリューションを提供できることがわかっているので、継続的にインテグレーションをおこなってリリースする。 悪い開発チームは、骨の折れるインテグレーション段階の最後に手動でテストをおこない、すべてを1度にリリースする。
・良い開発チームはリファレンスカスタマーにこだわる。悪い開発チームは競争相手にこだわる。 ・良い開発チームは業績に大きく貢献したときに祝う。悪い開発チームは最終的に何かをリリースしたときに祝う。

■イノベーションが失われる最大の理由
１．顧客中心の文化。AmazonのCEO、ジェフ・ベゾスが言うように、「私たちにとってこのうえなくありがたいことに、顧客はいつも満たされていない。顧客自身が満足していると言い、売れ行きが順調なときですら不満を持っている。自覚がなかったとしても、顧客は何かがもっと良くならないかと願っている。だからこそ、私たちは顧客を喜ばせたいという欲求に駆られて、顧客のために新しいものを生み出すのだ」。このように、顧客に焦点を合わせる姿勢を持っていない企業、つまり、直接、頻繁に顧客と接触しない企業は、情熱を失い、重要なインスピレーションの源を失うのである。
２．魅力的な製品ビジョン。多くの企業は、スケールアップを遂げる頃には、当初の製品ビジョンのほとんどを実現し、開発チームは次は何なのかをつかもうと苦闘する。この状況は、ビジョンの番人の役割を果たしていた創業者がすでに現場を離れていると、さらに深刻になる。この場合、誰かほかの人、通常はCEOや製品開発VPが乗り出して空白を埋める必要がある。
３．的を絞った製品戦略。製品開発を失敗させる最も確実な方法の1つは、同時にすべての人を喜ばせようとすることである。だが、大企業はこの事実を忘れてしまいがちだ。製品戦略では、製品開 発チームが的を絞るための、論理的で意図的な一連のターゲット市場が明確に示される必要がある。
４．強力なプロダクトマネジャー。製品開発にイノベーションが起こらない大きな理由は、強力で有能なプロダクトマネジャーがいな いことだ。会社が小さいときはCEOか共同創業者の1人がこの 役割を果たすが、規模が大きくなると、それぞれの製品開発チームに強力で有能なプロダクトマネジャーが必要になる。
５．安定した製品開発チーム。持続的なイノベーションには、開発チームが、製品開発の世界や、テクノロジーや、顧客の悩みを学ぶ機会を共有してきたことが必須条件の1つになる。もし開発チームのメンバーが絶えず入れ替わっていたら、こういうことは、起こらない。
６．製品発見へのエンジニアの参加。イノベーションの鍵を握るのは、しばしば開発チームのエンジニアだが、これが意味するのは、(a)エンジニアが製品開発の最後だけではなく、最初から参加し、(b)エンジニアが直接、顧客の悩みを聞く、ということである。
７．企業の勇気。よく知られていることだが、多くの企業は規模が大きくなるにつれてリスクを避けるようになる。確かに失うものは多くなる。しかし、最も優れたIT製品企業は、最もリスクの大 きい戦略はリスクを冒すのをやめる戦略だと知っている。私たちは仕事のやり方について賢明でなければならないが、現在のビジネスを混乱させるリスクをあえて冒そうという意欲は、持続的なイノベーションに不可欠である。
８. 権限を与えられた製品開発チーム。たとえあなたの組織がベストプラクティスを使ってスタートしたとしても、多くの組織はスケ ールアップするにつれて後退する。もしあなたが開発チームに機能のロードマップを渡すだけに逆戻りしたら、もはや権限を与えられた製品開発チームのメリットは期待できない。権限委譲というのは、開発チームが、最も適切だと考える方法で与えられたビ
ジネスの問題に取り組み、解決できることを意味する。
９．製品開発のマインドセット。ITのマインドセットを持つ組織では、製品開発チームはビジネスのニーズに応えるために存在する。一方、製品開発マインドを持つ組織では、製品開発チームはビジ ネスのニーズに合った形で顧客の役に立つために存在する。この2つの姿勢は結果として数多くの大きな違いを生む。
10．イノベーションを起こすための時間。スケールアップすると、製品開発チームは、これまでの業務をこなすだけですべての時間を使ってしまう可能性が高くなる。バグを修正し、ビジネスのさ まざまな部署のために機能を実装し、技術的負債に対処し、といった具合だ。もしあなたがこういう状況にあるなら、イノベーションが起こらなくても驚くに当たらない。こうした業務の中には当然やるべき健全なものもあるが、開発チームがもっと困難でもっと影響力の強い問題を追求する時間を、ぜひとも確保しなければならない。

■スピードが失われる最大の理由
１．技術的負債。しばしば、アーキテクチャーのために、製品の急速な進化が円滑に進められなかったり、できなかったりすることがある。これは一晩で解決できるような問題ではない。協調的な取り組みを根気よく続ける必要がある。
２．強力なプロダクトマネジャーの不在。強力で有能なプロダクトマネジャーがいないことは、製品開発に時間がかかる典型的な原因である。力のないプロダクトマネジャーの影響はさまざまな形で表れるが、開発チームが伝道師のチームではなく傭兵のチームになることで目に見えてわかる。プロダクトマネジャーが開発チームに動機や使命感を与えてこなかったか、開発チームがプロダクトマネジャーへの信頼を失っているかだ。
３．デリバリーマネジメントの欠如。デリバリーマネジャーの最重要な機能は障害を取り除くことだが、障害のリストは、技術が成長するにつれて非線形的に増加する。ほとんどの障害は、誰かが積極的に排除しないかぎり、すぐにはなくならない。
４．リリースサイクルの長期化。スピードの遅い開発チームの多くはリリースの間隔が長すぎる。開発チームは2週間に1回以上の類度でリリースしなければならない(特に優秀な開発チームになる と1日に何回もリリースする)。これを改善しようとすれば、通常、開発チームが迅速に作業し、自信を持ってリリースできるように、テストの自動化やリリースの自動化を真剣に考える必要がある。
５．製品ビジョンと戦略の欠如。仕事の全体像と、目前の仕事がどのように全体に貢献するかについて、開発チームが明確なビジョンを持つことが不可欠である。
６．同じ場所にいて、長続きする開発チームの不在。開発チームがいくつかの場所に分散していて、さらに悪いことにエンジニアリン グを外注している場合は、イノベーションの機会が激減する上に、仕事のスピードが大きく損なわれるだろう。単純なコミュニケーションさえ困難になる。多くのアウトソーシング会社が加わることで、連携し、意思疎通しなければならない人々の層が増えると、大概、事態は悪化する。
７．製品発見に早い時期からエンジニアを参加させない。エンジニアはアイディエーションを始めるときから製品発見に加わる必要がある。もし、プロダクトマネジャーやデザイナーが調整できる早い時期からエンジニアを製品発見のプロセスに加えたら、エンジニアは、たいてい、もっと迅速に実装できる別のアプローチを提案するだろう。エンジニアの参加が遅れたら、重要な提案を製品発見に取り入れるのが間に合わなくなる。
８．製品発見にプロダクトデザイナーを使わず、エンジニアがビルドしている間にブロダクトデザインの仕事をさせようとする。プロダクトデザイナーが製品発見に参加しなければ仕事のスピードが低下するし、ひどいデザインになる。
９. 優先順位を変える。優先順位が目まぐるしく変わると深刻な混乱が生じ、全体のスループットとやる気を著しく低下させる。
10. コンセンサス文化。多くの組織がコンセンサスを得ようと努力する。これは、大概、善意から生まれるが、実際には決断が非常に難しいことを意味しており、あらゆることが遅々として進まな
くなる。

■強いイノベーション文化を持つとは？
・実験の文化―開発チームはテストができることを知っている。中には成功するものもあるが多くは失敗するということが受け入れられ、理解されている。
・開かれた心の文化―開発チームは、優れたアイデアはどこからでも生まれるとわかっているし、最初は必ずしもその良さがはっきりわからないことを知っている。
・権限委譲の文化??個人もチームも、アイデアを試す権限を与えられていると感じている。
・テクノロジーの文化??真のイノベーションは、顧客がきっかけになるのと同様に、新しいテクノロジーとデータの分析をきっかけにして生まれることを、開発チームはわかっている。
・ビジネスと顧客に精通した開発チームの文化―開発者を含む開発チームは、ビジネスのニーズと制約を十分に理解しており、ユーザーや顧客への深い理解(とアクセス方法)を持っている。
・多様なスキルセットとスタッフの文化―開発チームは、さまざまなスキルとさまざまなスタッフの経歴が、ソリューションのイノベーション、特にエンジニアリング、デザイン、製品開発に貢献することを実感している。
・製品発見テクニックの文化―アイデアを(ブランドと収益、顧客 と仲間を守りながら)迅速かつ安全��テストするための環境が整っている。

■強い実行力文化を持つとは？
・切迫感の文化―人々が戦時であるかのように感じていて、迅速に動く方法を見つけられなければ悲惨なことが起こりかねないと思っている。
・ハイインテグリティーコミットメントの文化―開発チームは責任を負う必要性（と能力）を理解しているが、同時にハイインテグリティーコミットメントも主張する。
・権限委譲の文化―開発チームが、責務を果たすのに必要なことをするためのツールと、資源と、許可を持っているかのように感じている。
・説明責任の文化―スタッフや開発チームは、自分たちの責務を果たすことに強い責任感を抱いている。説明責任はまた、結果にも関わる。重大な失敗を繰り返す場合を除けば必ずしも解雇されることはないが、同僚の間での評判に影響する可能性は高い。
・協力の文化―開発チームの自律性や権限委譲は大切だが、開発チームには、最も大きく最も意義深い目標を達成するために協力するという、はるかに重要なニーズがあることを理解している。
・成果の文化―焦点はアウトプットに置かれているのか、それとも成果に置かれているのか?
・認知の文化―開発チームは、しばしば、報われたものや受け入れられたものからヒントを得る。新しく素晴らしいアイデアを考えついた開発チームと、とても過酷な責務を果たした開発チームの、どちらが報われるべきだろうか?そして、責務を果たせないことが許容されてしまう場合、そのメッセージは何なのだろう?

　これらの特徴がそれぞれの文化を定義するのに役立つとすれば、次のようなかなり難しい問題が生じる。
・イノベーションの文化は、何らかの意味で、実行力の文化と本質的に対立するのだろうか?
・強い実行力の文化は、ストレスの大きい(あるいは劣悪な)労働環境につながるのではないか?
・リーダーを含めて、どんなタイプの人間が、それぞれの文化に引き付けられ、必要とされるのか?


　現実には、持続的なイノベーションと実行力のどちらにも非常に強い企業が存在する。Amazonはその最も良い例の1つだ。しかし、よく知られているように、Amazonの労働環境は気の弱い人には向かない。私が見たかぎり、並外れて実行力が強い企業のほとんどは、極めて厳しい職場である。
　多くの企業と仕事をしてきた私の経験では、イノベーションと実行力の両方に優れている企業はほんのわずかしかない。多くの企業は実行力に優れているがイノベーションには弱い。イノベーションには強いが実行力はまあまあという企業はそれよりも数が少ない。そして、うんざりするほどの数の企業が、イノベーションも実行力も乏しいのだ(ほとんどは、製品開発の魔法をとっくの昔に失ったが、まだ強いブランドを維持し、寄り掛かれる顧客基盤を持っている古い企業である)。
　いずれにせよ、私があなたやあなたの開発チームにしてほしいのは、イノベーションと実行力の両面から自分自身を見直し、あなたが、チームや企業として、どの位置に行きたいのか、どの位置に行く必要があると考えているのかを自分に問いかけることである。

投稿元：

レビューを見る

プロダクトマネージャーとはどんな仕事か？が分かる本
良い開発文化やチームについても理解を深められる（ここら辺は「ユニコーン企業の秘密」と共通している）
プロダクトマネージャーの仕事はCEOの前段階と言われるほど大変

「製品開発チームが全てだ」「傭兵ではなく伝道師のチーム」
これらの言葉が印象に残った

投稿元：

レビューを見る

プロダクトマネジャーではなく、その役割に近いところのビジネスサイドで仕事をするにあたり、役割の理解が深まった。アジャイル風の、アイデアベースのウォーターフォール開発では失敗する。エンジニアをはじめとしたプロダクトチームが真に顧客や事業の課題や背景を理解し、積極的に参加してサイクルを回すことこそ、真のアジャイル事業経営につながる。

投稿元：

レビューを見る

PdMの役割を知るには良い教科書。どのような人がPdMに向いているか、どのようか役回りをするポジションなのか、どのようなマインドセットを持っているべきかというのが理解できました。