プロダクトマネージャー（PdM）になるために #1_導入編（概論）
本の読み込み系は久しぶりの投稿です。
今回からは最近IT企業で引く手あまたのプロダクトマネージャーについてです。
まずは導入編からです。
文字数：約4,100
今回は以下のnoteから参考図書を決めてみました。
Shoko Suzukiさん、ありがとうございます。
自分の備忘メモに近く、読み物としては最適ではないですがご容赦ください、ちゃんとインプットとしてアウトプットします。
参考図書
① 一流企業から学んだこと
・作るものに価値がなければ開発チームがどれだけ優秀でも関係ない
・プロダクトマネージャー（以下PdM）はマーケティング部門に属し、作る製品を定義する責任者
・この本の狙いは最も成功した製品を生み出した企業のベストプラクティスを共有すること
熱狂させる製品を生み出すプロダクトマネジメント
ISBN 978-4-8207-2750-7 C2034
P12〜14
◼️ Chapter1 優れた製品の背後にあるもの
・優れた製品には必ず製品開発チームを率いて、技術と設計を組み合わせ、顧客が抱える課題をビジネスニーズに合った形で解決する人がいる（PdM）
・PdMはデザイン、エンジニアリング、マーケ、プロジェクトマネージャー（以下PM）と役割が全く異なる
◼️ Chapter2 ITに基づいた製品やサービス
・本書はITに基づいた製品、サービス、体験に焦点を絞る
熱狂させる製品を生み出すプロダクトマネジメント
ISBN 978-4-8207-2750-7 C2034
P15〜18
◼️ Chapter3 スタートアップ〜PMFを達成する〜
・IT業界は企業のステージをスタートアップ（創業）期 → 成長期 → エンタープライズ（成熟期）の3つにわける
・スタートアップ期におけるPdMの役割は共同創業者の一人が担うことが普通
・スタートアップ期は資金ショートする前にPMF（Product Market Fit：顧客を満足させる最適な製品を最適な市場に提供している状態）を達成するレース
熱狂させる製品を生み出すプロダクトマネジメント
ISBN 978-4-8207-2750-7 C2034
P19〜20
◼️Chapter4 成長期企業〜成功へ向けてスケールアップする〜
・より多くの人を雇用することに加え、新しい関連製品やサービスで以前の成功を再現する方法を考える
・プロダクトチームは自分たちの仕事が大きな目標にどのように貢献しているかわからないと（＝プロジェクトの全体像が見えない）不満をもらす
・最初の製品ニーズに合うように作られた技術インフラはしばしば能力の限界に達する
・リーダーはスタートアップ期とは異なる自分の役割、行動を変えざるを得なくなる
熱狂させる製品を生み出すプロダクトマネジメント
ISBN 978-4-8207-2750-7 C2034
P21〜22
◼️Chapter5 成熟期企業〜常に製品のイノベーションを図る〜
・常に顧客とビジネスにとって新しい価値を生み出し続けなければならない
・多くのエンタープライズは死のスパイラルに陥ることが多い
・企業が成熟期に到達するともともとのビジョンをほとんど実現してしまい、従業員が次に何をすれば良いか分からなくなる
・Apple Amazon Adobe Facebook（Meta）Google Netflixは死のスパイラルを避けることができた。その理由を後述
熱狂させる製品を生み出すプロダクトマネジメント
ISBN 978-4-8207-2750-7 C2034
P23〜24
◼️Chapter6 製品開発が失敗する根本的原因
・多くの企業が使っている製品プロセスはアイデアから始まり、それを優先してロードマップを作成
・個々のアイデアに対して常に以下の二つが求められる
1、それはどれくらいの利益や価値を生み出すのか
2、それをどれくらいの時間とコストがかかるのか
・あるアイデアの優先度が1位となれば、PdMがステークホルダーに話をして要求事項を考え出し、デザイナーやエンジニアに何を作るか伝える
・最後に要求仕様とUI/UX仕様がエンジニアに届きアジャイル開発が始まる
・QAからゴーが出ればリリースされる
・これらの開発プロセスは常にイノベーションの欠如と、アイデアから製品化までに長い時間を要する
熱狂させる製品を生み出すプロダクトマネジメント
ISBN 978-4-8207-2750-7 C2034
P25〜28
◼️Chapter6.２多くの企業が取る開発プロセスの10の問題点
1、ウォータフォールプロセスは販売主導の製品やステークホルダー主導の製品につながる。開発チームへの権限移譲が行われず開発チームがただの道具と化す
2、ビジネスケース（投資を行う合理的根拠と見込まれる利益やリスクをまとめた提案書）を作るための想定利益・コストに対する客観的明白な事実はこの段階ではないし、知りようもない
利益はプロダクトの出来にかかっているし、ビルドまでにどれだけコストかかかるかも分からない
製品開発における重要な教訓は「何が知り得ないのかを知ること」
3、次に企業がプロダクト開発のロードマップに夢中になったとき大きな問題が起こる。ほとんどのロードマップは単に機能やプロジェクトの優先順位が付いたリストに過ぎない
＋製品の2つの不都合な真実は逃れることが出来ない。優れた製品開発ができる企業はこの不都合な真実への対応の仕方が違う
A）アイデアの半分はうまくいかない
顧客がそのアイデアに心が躍らず使わないほうを選ぶ
B）可能性があることが証明されたアイデアでさえ、Time to Money（アイデアか収益をあげるまでに要する時間）が発生する
4、このモデルにおけるPdMは本来のPdMとは異なり、PMの一形態であり、エンジニアのために要求事項を集めて文書化することが中心
５、デザインにおいても同じであり、プロセスにデザインの真の価値を取り入れるのが遅すぎる
6、このモデルが最も タイミングを逸しているのはエンジニアを導入するのが遅すぎること。エンジニアはいつも優れたイノベーションの源であるので、議論プロセスに早くから招くことが不可欠
7、エンジニアだけでなくアジャイル開発の原理や利点を取り入れるのも遅い
8、プロセスがプロジェクト中心で、プロジェクト自体がアウトプットであり、プロダクトがアウトカムになっている
9、従来のウォーターフォールの最大の欠点はリスクが最後に来ること。つまり顧客実証が遅すぎる
10、このプロセスの実行に忙しく時間と金をムダにしているが、それ以上にその間に選択できたはずことへの機会損失が最大の損失
熱狂させる製品を生み出すプロダクトマネジメント
ISBN 978-4-8207-2750-7 C2034
P28〜32
◼️Chapter7 リーンとアジャイルを超えて
・優れた製品開発チームはリーンとアジャイルの中核原理を利用しながらも、達成目標と仕事のやり方を上げており、3つの包括的な原則が動いている
1、リスクは最後でなく最初に取り組む
作る前に以下のリスクに取り組む
・価値のリスク（顧客が購入するか）
・ユーザビリティのリスク（使い方がわかるか）
・実現可能性のリスク（エンジニアの時間とスキルとテクノロジーで作ることができるか）
・事業実現性のリスク（ビジネスとして問題がないか）
2、プロダクトの定義とデザインは順を追ってではなく協調させながら同時に実行
・製品開発、デザイナー、エンジニアが持ちつ持たれつの関係で協調し、顧客に愛され、ビジネスに貢献する高い視座で取組む
3、機能を実装することでなく、問題を解決すること
熱狂させる製品を生み出すプロダクトマネジメント
ISBN 978-4-8207-2750-7 C2034
P33〜35
◼️Chapter8 基本的概念
＜ホリスティックな製品＞
・製品には「機能・特徴」「実現するテクノロジー」「UXデザイン」「マネタイズできる方法」「顧客を惹きつけて獲得する方法」が含まれる
・機能の実装だけを考えていてはいけない
＜継続的な製品発見と市場投入＞
・製品発見と市場投入は職能横断型チームの２つの主要な活動であり、具体的に２つのことに取り組む
1、作る製品を発見する（PdMとデザイナー）
2、高品質なプロダクトを市場投入する（エンジニア）
・近年では1、２の活動をPdM、デザイナー、エンジニアが互いに支援している
＜製品発見＞
・目的は良いアイデアと悪いアイデアをすぐに判別することであり、以下の問いへの答え
1、顧客はそれを買って（使って）くれるか
2、顧客は使い方が分かるか
3、エンジニアがそれを作れるか
4、ステークホルダー達の指示を得られるか
＜プロトタイプ＞
・コストをかけずに早く学習できる
＜市場投入→PMF＞
・製品開発の世界ではPMF達成のために努力する
・ここでは実際の製品なので市場投入の結果である。製品発見は必要なプロダクトを見極めるのに役立ち、プロダクトのビルド、テスト、リリースに必要な仕事は市場投入において行われる
＜製品ビジョン＞
・ビジョン達成のために「どうすれば一週間に15の実験ができるだろうか」と考えることで、優秀なプロダクト開発チームのやり方に近づく
熱狂させる製品を生み出すプロダクトマネジメント
ISBN 978-4-8207-2750-7 C2034
P36〜40
＜① 一流企業から学んだことの所感＞
各項目が簡潔かつ分かり易くまとまっているな、というのが本に対する最初の印象です。
内容はウォータフォール型の従来開発プロセスだといつもの間にか、「課題解決」→「機能実装」と手段の目的化が生じてしまっていると理解できました。
とくに日本人は真面目なのでこの思考に陥ってしまいがちですね（自戒の意味も込めて）
「従来の考え方を打破して、メンバーを巻き込む力と製品理解がある人」
これが最低限の要件だと思いました。
この記事が気に入ったらサポートをしてみませんか？