あらすじ
大幅な書き直しをした2ND EDITION
日本に足りないのはプロダクトマネジャーだ!
Amazon, Apple, Google, Facebook, Netflix, Teslaなど、最新技術で市場をリードする企業の勢いが止まらない。はたして、かれらはどのようにして世界中の顧客が欲しがる製品を企画、開発、そして提供しているのか。
本書はシリコンバレーで行われている「プロダクトマネジメント」の手法を紹介する。著者のマーティ・ケーガンは、成功する製品を開発するために
・どのように組織を構成し
・新しい製品を発見し
・適切な顧客に届けるのか
を、具体的な例を交えながら詳細に説明する。
Adobe、Apple、BBC、Google、Microsoft、Netflixの、今日最も成功を収めているプロダクトマネジャーと
そのテクノロジーを活用した製品企業のプロファイルも紹介。スタートアップ企業から、成長企業、世界的な大企業まで、多くの読者に対応し、学習した情報をいますぐ自分の組織内で活用して、製品と製品開発組織を劇的に改善できる! プロダクトマネジャー、エンジニアはもとより経営者、スタートアップ、新規事業開発担当も必読!
感情タグBEST3
Posted by ブクログ
噂に聞く素晴らしい本。PdMのバイブルと言われるのも納得。
ネタバレですが、メモです。
-------------
- チームメンバーを伝道師にする。傭兵のチームでは無い
- 使命感を持った開発チームはビジョンを信じ、顧客のために問題の解決に全力を傾ける
- チームが一緒に学習する。チームは顧客の悩みを一緒に受け止め、あいであが失敗するのを経験して何が重要で何をすべきかの文脈を全員が理解する
- プロダクトマネージャ
- 何を顧客に届けるのかを判断する(製品発見)のが主な仕事
- 多くの顧客に有効な１つのソリューションを考え出す（顧客の数だけ考えるのでは無い）
- 製品発見の鍵は、顧客と対話すること
- できるだけ迅速に、コストをかけずにアイデアの妥当性を見つけ出す
-
- 下記知識を持つ
- 顧客に関する深い知識
- データに関する深い知識
- 自分のビジネスについての深い知識
- 市場と業界についての深い知識
- 効率的な
- エンジニアがPMFするための製品探し（製品発見と呼んでいる）も行うべき
- 有能なチームは即座にリスクに取り組み、有効なソリューションに対しイテレーション(PoC検証)を何度も繰り返し実行する
- アイデアのプロトタイプをｔくり、ユーザー、顧客、エンジニア、ビジネスホルダーに対しテストする
- 1週間に１０～２０イテレーションを行う
- エンジニアは機能を提供するのがゴールではなく、本質的な問題を解決する必要性がある
- エンジニアのパフォーマンスは結果で測定
- ビジネスの根本的な問題を解決できなければ何も解決したことにならない
- 製品開発チームは企業がどこへ向かっているかを確実に把握し、大きな目標に対して自分のチームがどのように貢献するのが望ましいか理解する必要性がある
- どうやるかを指示してはいけない。何をすべきかを指示すればよい。そうすればエンジニアは創意工夫するだろう
- プロダクトマネージャによる製品に関するエバンジェリズム
- プロトタイプを見せる
- 顧客の悩みを開発チームと共有する
- 我々の仕事がそのビジョンにどれだけ貢献し、どれだけ理念に忠実であるかを見せる
- ユーザテストや顧客訪問の後は必ず学習したことを共有する。チームみんなで考える
- 開発チームが製品はプロダクトマネージャのものでは無く、自分たちのものだと思えるようにする
- 失敗した場合はPdMがすべての失敗の責任を引き受け、失敗からも学べることをチームに示す
- あなたが心からワクワクしていると周りの人に伝わるようにする
- デザイナーやエンジニアと顔を合わせて十分な時間を使う
- メンバーはあなたの目に宿る熱意を見ることができる
- 相手のモチベーションのレベルが変わる
- カスタマーレター テクニック ★★
- 架空のプレスリリースを書く（ワーキングバックワードプロセス）
- それはどのように顧客の生活を向上させるのか？
- 顧客の利益は何か？
- 開発チームがこのプレスリリースを見て胸を躍らせないなら、それは実行する価値が無い
- 開発チームをアウトプットでは無く、アウトカム（結果）に集中させる
- 開発チームが機能の一覧表にすぐ取り掛かるのは良くない
- さらなる進化系
- 仮想的なカスタマーレター
- その製品によって顧客の生活がどんなふうに代わり向上したかが書かれている
- カスタマーレターの方が顧客の現在の共感を生む効果が高い
- 自分たちの仕事がどのように顧客の生活に役に立ちうるかを開発チームにより明確に印象づけられる
- スタートアップキャンバス
- 製品の全体像を的確に把握できる
- ビジネスのどういう分野に影響を与えるかを理解することが容易になる
- リスクに光を当ててくれる
- 最大のリスクにこそ真っ先に取り組まなければならない
- 顧客発見
- 6つのリファレンスカスタマーを見つける
- プロダクトマーケットフィット
- もしその製品が使えなくなったらどう感じるか？
- 「非常に残念」と答えたユーザーが４０％以上ならばPMFしている可能性高い
- 良いチーム
- 人を魅了する製品ビジョンを持っていて、伝道師のような情熱で追及する
- エンジニアが毎日プロトタイプを試す時間を確保し、製品をよりよくする方法について、自分たちの考えを提案できるようにする
- 毎週エンドユーザーと関わって、顧客をよりよく理解し、自分たちの最新のアイデアに対する顧客の反応を見る
- 望んだアウトカムを生み出すためには何回かの繰り返しが必要になると考えている
- 良い開発チームはスピードが必要であり、イテレーション（繰り返し）が適切なテクニックからくると知っている
- 自分たちの製品がどんなふうに使われているかを知るために製品にデータ取りを実装し、データに基づいて調整する
- 良い開発チームは業績に大きく貢献した時に祝う（悪いチームはリリース時に祝う）
- スピードが失われる理由
- PdMが開発チームに動機や使命感を与えられてこなかった
- 仕事の全体像と目の前の仕事がどのように全体に貢献するかについて開発チームがビジョンを持つことが重要
- 強い製品開発文化
- 実験の文化。テストの多くは失敗することを知っている。失敗が受け入れられることを知っている
- 優れたアイデアは最初は必ずしもその良さがわからないことを知ってる
Posted by ブクログ
プロダクトマネジメントの原則、成功するチーム・リーダーと失敗するチーム・リーダーの違いを説明した本。
多くのIT企業のプロダクトマネジメントに関わってきた著者の経験則が原則のかたちでまとめられている。魅力的な製品を生み出すためにはどう言った組織・チーム・人にどんな文化、ビジョンが必要かといった言及がされている。
成功のためのプロセスとして、製品発見のためのテクニックがいくつか紹介されている。私にとって、何度も読み返す必読書になるだろう。
Posted by ブクログ
事業会社で事業立ち上げメンバーとしてPdM、PO、EMしています。メンバーが増えていくにつれてどのような組織体制にしていくべきかモヤモヤしているところでこの本に出会いました。PdMや開発チームの責務やマインド、プロダクトビジョンの必要性など私がモヤモヤしていた内容が多く書かれていました。
特に前半の成功するための組織と人のパートはとても参考になることが多く、繰り返し読んで自分の言葉や自分の事業に当てはめて語れるようになりたいと思います。
Posted by ブクログ
製品開発は、
プロダクトマネージャー
プロダクトデザイナー
エンジニア
が主たるメンバーとなるチームを組んで取り組むものである。
日本の製造業においては、
プロダクトに対するCEOである
プロダクトマネージャーは、いない。
また、プロダクトデザインを担当する人もいない。
製品開発は、
アウトプットでなくアウトカムを基準に
バタンリレーでなくチームプレイで
できることからでなく、重要なことから
取り組むことが大事である。
これまでは、リリースすること、
つまり、とにかく機能をつくりきることを
目標にしてきた。
リリースすることが目標なのではなく、
製品によって、顧客の課題が解決され
結果、自社ビジネスが成長することが目標。
ここに、組織の力を集中させるために、
OKRが活用できる。
Objectives and key results
ウォーターフォールで、工程ごとに主担当がわかれてきた。
このため、前工程への理解が足りずに
結果手戻りをしてきた。
関係が前工程から検討にはいり、
短いスパンで何度も検討する。
これがアジャイルであり、リーン。
やりやすいことは、機能の開発。
そのまえに、
顧客は買ってくれるのか
使ってくれるのか
作れるのか
ビジネスとして成り立つのか
に答えなければならない。
Posted by ブクログ
PdMの役割を知るには良い教科書。どのような人がPdMに向いているか、どのようか役回りをするポジションなのか、どのようなマインドセットを持っているべきかというのが理解できました。
Posted by ブクログ
プロダクトマネージャーとはどんな仕事か？が分かる本
良い開発文化やチームについても理解を深められる（ここら辺は「ユニコーン企業の秘密」と共通している）
プロダクトマネージャーの仕事はCEOの前段階と言われるほど大変
「製品開発チームが全てだ」「傭兵ではなく伝道師のチーム」
これらの言葉が印象に残った
Posted by ブクログ
プロダクトマネジメントにおける各工程から、カルチャーに至るまで、広範囲に成功させるためのスキルセットとチームが記載されている。第5章は良いチームについて具体的に描かれていて大変勉強になった。繰り返し読みたい。
Posted by ブクログ
プロダクトマネジメントにフォーカスした書籍としてよくまとまっている（と思う）。
ただ、あまりに箇条書きが多く、ほとんどの章が「◯◯のための10のポイント」のような構成で食傷気味になる。とはいえ、プロダクトマネジャーとして忘れてはいけないことを思い出す、しっかりした内容だった。
技術やスキルを学んだり訓練したりする内容は無いが、かけだしのプロダクトマネジャーにも良い本だと思う。
Posted by ブクログ
評価が難しい
前半は具体的で良い本だなと思ったんですが、
後半は同じような抽象的な内容の繰り返しでイメージが湧かず読み終えてから特に記憶に残ってなかった
Posted by ブクログ
新しいプロダクトを作るときにプロダクトを作る人に参考になる本
以下メモ
リーンなプロダクト開発の中心テーマ
1. リスクには最初に取り組む、価格、ユーザビリティ、実現可能性
2. 製品の定義とデザインは協調させながら、持ちつ持たれつ進める
3. 機能の実装ではなく問題解決が目的
製品開発チームが全て
プロダクトマネージャーとは
・失敗の責任を持つ人
・顧客に関する深い知識
・プロダクトに関するデータ分析
・ビジネス、市場や業界に対する深い知見
製品開発ロードマップの問題点
・経営陣の事業運営上計画を立てる必要性、いつ機能が使えるのか知りたいといったことから求められる
・半分以上のアイデアはうまくいかないことが考慮されていない
・ロードマップに書いた途端、約束事項として理解してしまう
・解決すべきビジネス上の問題によって記述するアウトカムベースのロードマップがよい
製品ビジョン
・2〜5年の間に実現しようとする未来、みんなを勇気づけ人を集めるビジョン
1. Whyから始める、目的をはっきりさせる
2. 解決策ではなく問題に恋する
3. 臆病にならず大きな視野で
4. チームを混乱させることを恐れない
5. 人の心を揺さぶらないといけない
6. 重要なトレンドを見つけ出し取り入れる
7. 時間軸で変化するところと変化しないところを見極める
8. ビジョンには頑固で、細部には柔軟でいる
9. どんなビジョンも信じて賭けること、見極めるのに数年はかかる
10. 絶え間なく、粘り強く説得して回る
製品戦略
1. 1度のリリースにつき１つのターゲット市場やペルソナに集中する
2. ライバルではなく顧客のことだけ考える
3. どうやるかは指示しない、何をやるかを指示する
製品の発見
・多くの顧客に有効な一つのソリューションを考え出す必要がありながら、100%信頼がない製品をリリースしてあとは祈るというやり方が許されないこと
原則
1. 何を作るべきか顧客は教えてくれない
2. 説得力のある価値を確立する
3. 優れたユーザーエクスペリエンスは困難だが欠かせない
4. アイデアの多くはうまくいかない、どのアイデアが、役に立たないかを前もって知れない、様々な方法を試す
5. アイデアの妥当性は実際のユーザーで立証しないといけない、製品に対する顧客の反応を予測できると思うのは間違え
6. できる限り迅速にコストをかけずにアイデアの妥当性を立正する
市場発見
1. ビジネスの目的objective 何を達成するのか
2. 何をもって達成するのかkey results
3. どんな顧客のどんな問題を解決するのかcustomer problems
4. どんな種類の顧客かtarget market
・顧客が書いた仮想的なカスタマーレターを書くことで需要の評価をすることも良い
・スタートアップキャンバスは新製品投入において特にリスクの発見に役立つ
発見のためのプランニング
①ストーリーマップ
・バックログのような羅列されたリストではなく、主要なユーザーのアクティビティを時間軸、実行の順に沿って左から右に並べる。縦軸は詳細さ、主要なタスクほど上
②顧客発見プログラム(リファレンスカスタマー、ロイヤルカスタマーの発見)新製品や新しいビジネスを生み出す際に役立つ(マイナーチェンジには向かない)
・ターゲット市場における6〜8のリファレンスカスタマーを目指す
・候補企業を集める、本当に悩みを抱えていて開発しようとしているソリューションが欲しくてたまらない企業。顧客と会いたいと言う人たちは後で良い、リード扱い
・6つのプロダクトを作るのではなく、全てに役立つ1つのソリューションを見つけだす。
・リファレンスカスタマー探しに苦労しているようだと重要ではない問題を追いかけている可能性が高い
顧客インタビュー
心がけるべきこと
1. 顧客は考えていたような人たちか？
2. 本当に考えている問題を持っているか？
3. 現在どうやって解決しているか？
4. 自社製品に乗り換えさせるために何が必要か？
・インタビューの間に何かを証明しようとしない、理解と学習に努める
・コンシェルジュテスト：顧客に変わり手作業で顧客の仕事をすること、
・プロダクトアウト、マーケットイン以外に顧客が予期せぬ使い方をするところから可能性を広げる方法もある
需要テスト
・リリースしてから価値がなかった、は最も避けるべきでかつ容易に避けられる。
・フェイクドアテスト: 適切な箇所に新機能のボタンを追加し、特殊なページに遷移させる。そこがテストの協力フォームになる。需要に関する適切な証拠と新しい機能を使いたいユーザーリストが手に入る
Posted by ブクログ
プロダクトマネジメントの必要なものを話す本
ちょっと広すぎるというか、色々書いてて良いんだけどまとめてくれたらなあと。
製品発見・プロトタイプ・市場投入・マーケットフィット
開発チーム、構成・使命・権限委譲・説明責任・規模・上下関係・協力・場所・業務範囲・継続期間・自律性
プロダクトマネージャー、責任、顧客・データ・ビジネス・市場と業界知識、頭がよく粘り強い、
Posted by ブクログ
プロダクトマネジャーではなく、その役割に近いところのビジネスサイドで仕事をするにあたり、役割の理解が深まった。アジャイル風の、アイデアベースのウォーターフォール開発では失敗する。エンジニアをはじめとしたプロダクトチームが真に顧客や事業の課題や背景を理解し、積極的に参加してサイクルを回すことこそ、真のアジャイル事業経営につながる。
Posted by ブクログ
最初の方はいい本かなーと感じていましたが、中盤からは抽象的な議論になってきた印象。大事なことは書かれているのですがどこから手をつけたらいいのかわからないくらいやらなければならないことが多い感じ。
