# プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける
## 2021/11/08 下田
## 書籍情報
「プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける」- Melissa Perri　著、吉羽 龍太郎　訳
https://www.oreilly.co.jp/books/9784873119250/
https://www.amazon.co.jp/dp/4873119251

## どんな本？
プロダクトマネジメントの基本を網羅した本です。
- 第I部 ビルドトラップ
- 第II部 プロダクトマネージャーの役割
- 第III部 戦略
- 第IV部 プロダクトマネジメントプロセス
- 第V部 プロダクト主導組織
と5部構成になっており、第I部ではプロダクトマネジメントの全体像、第II部～第V部で役割、戦略、プロセス、組織が、企業が提供する価値にどれだけ影響を与えるかについてを解説しています。

### 企業がプロダクト主導かどうかを判断する6つの質問

1. 最後に作った機能やプロダクトのアイデアを思いついたのは誰ですか？
2. 最後に開発中止を決めた機能や廃止したプロダクトは何ですか？
3. 顧客と最後に話をしたのはいつですか？
4. 目標は何ですか？
5. 現在何に取り組んでいますか？
6. プロダクトマネージャーはどんな人ですか？

## 参考にすべきトピック

### 第I部 ビルドトラップ
#### ビルドトラップ
> ビルドトラップとは、組織がアウトカムではなくアウトプットで成功を計測しようとして、行き詰まっている状況

アウトプットとは作り出した製品のことで、アウトカムはそのアウトプットをユーザのもとへ届けた結果ユーザから得られたもの表す言葉です。
製品をアウトプットしユーザのもとへ届けた瞬間は本来のゴールではなく、届けた後にユーザが価値を解釈した後にリピートするなり口コミなりのアウトカムが発生するまでがプロダクトマネージャの責務で、ユーザの顧客価値とサービス提供者側の価値を最大化することを説いています。

### 1章　価値交換システム

> 顧客やユーザーは問題や要望、ニーズを持っています。

> 顧客が価値を認めるのは、自分たちの問題が解決したり、要望やニーズが満たされたりしたときだけです。

> そのときだけ、彼らはビジネス側に価値を返してくれます。

問題が解決したり、要望やニーズが満たされると、お金などの価値を返してくれる。
交換システムとなっている。

### 2章　価値交換システムの制約
#### アウトカム
> アウトカムとは、 私たちが機能を届けて顧客の問題を解決したという結果のことです。

> リリースした機能の数によってチームを評価するのをやめなければいけません。代わりに、価値を定義して計測し、ビジネスやユーザーのアウトカムを実現できたら称賛すべきです。そして、その実現の助けになるようなプロダクトを作るべきなのです。

### 3章　プロジェクト / プロダクト / サービス

#### プロダクト
ユーザに価値を届ける「もの」

#### サービス
> サービスはプロダクトと違って、ユーザーに価値を届けるのに人手を使います。

#### プロジェクト
> プロジェクトとは作業のかたまりで、特別な目的を持ったもの

### 4章　プロダクト主導組織
組織の形をいくつかの類型に分けられる。

#### セールス主導の企業
セールスが契約を取ってきて、それにあわせてプロダクトやサービスを作る形態。

> セールス主導の企業では、プロダクト戦略は顧客への約束によって決まります。

約束した機能の実装に追われて、戦略的に機能開発できないことが問題点

#### ビジョナリー主導の企業
> ビジョナリー主導の企業については、アップルを例に考えるのがいちばん簡単です。スティーブ・ジョブズがプロダクト戦略を考えて、会社はそれに向かって進みました。

持続可能な組織ではないことが問題点

#### テクノロジー主導の企業
差別化できるテクノロジーを持っていて、テクノロジーを軸にプロダクトを作っていく形態。

> 誰も買い手のいないクールなものを大量に作っていること

になりかねないのが問題点

#### プロダクト主導の企業
本書で目指すべきとしている形態で、ビジネスアウトカムを軸に最適化していく。

> プロダクトの持続的な成長の原動力になるようないちばん効果的なプロジェクトに優先して取り組みます

### 第II部 プロダクトマネージャーの役割

> プロダクトマネージャーはビジネスと顧客の両方を深く理解し、 価値を生み出す適切な機会を見極めます

### 6章　悪いプロダクトマネージャーの典型

#### ミニCEO
プロダクトに関する全権があると勘違いしてしまうこと

#### ウェイター
人の言うことを聞いてばかりで、優先順位を決定できないこと

#### プロダクトマネージャーだった人
プロダクトマネージャーが「いつ」にコミットしてしまうと、プロダクトマネージャーではなくなってしまう。
「いつ」はプロジェクトマネージャの仕事で、「なぜ」がプロダクトマネージャの仕事。

### 7章　優れたプロダクトマネージャー

> 優れたプロダクトマネージャーでありたいなら、ビジネス部門やテクノロジー部門、デザイン部門と連携して、それぞれの知識を総合的に活用できなければいけません

> 「プロダクトマネジメントで学んだいちばん大きなことは、 常に問題に集中することです。『なぜ』から外れないようにしていれば、適切なもの を作れる可能性が高くなります」

スクラムのプロダクトオーナーは役割で、最終的に優先度を決定することだけが定義されている。プロダクトマネージャーはキャリア(ラクーンで言うスキルシートに乗るもの)で、全員がプロダクトマネージャとならなかればならない。

### 第III部 戦略

> 戦略とは意思決定を下すのに役立つフレームワークのことです

### 10章　戦略とは何か？

> 優れた戦略は単なる機能の列挙ではなく、より高いレベルのビジョンや目標に焦点を当てるべき

#### スティーブン・バンギーの戦略の概念
著書「The Art of Actiony」より

> 戦略とは実行可能な意思決定のフレームワークであり、現在のコンテキストとの整合性を保ちながら、現在の能力の制約のもとで、望ましいアウトカムを達成するための行動を可能にするものである。

### 11章　戦略のギャップ
アウトカム→計画→行動→アウトカム→計画・・・とサイクルを回していく。
次のフェーズに進めるとき、ギャップが生じてしまう。
「いつ何をやるか」といった計画を戦略として定めると、これらのギャップにより組織内に摩擦が起きてしまう。
この3つのギャップを是正するように戦略を定めれば、自律的にチームが動きマネジメントは不要になる。

#### 知識のギャップ
アウトカムから得ている知識と、計画を立てるために必要な知識の差

ギャップを埋めるために上層部は具体的な問題の解決方法などを部下に詳細な情報を求めがちだが、上層部は詳細な情報を集めても情報過多になってしまうだけとなってしまう。
解決方法の前に「なぜそのアウトカムが起こったのか」という理解が必要で、「なぜその解決方法なのか」というストーリーを語る必要がある。
上層部から部下に戦略的意図やビジネス上の目標を定義して伝えることでギャップを埋める。

#### アラインメントのギャップ
立てた計画と、実際に起きている行動の差

このギャップを埋めるために、上層部は詳細な指示を出しがちだが、「どうやって」実現するかは部下にまかせるべき。
それぞれの階層で「なぜそれが必要なのか」を伝えて、認識を揃えることでギャップを埋める。

#### 効果のギャップ
行動によって期待する達成と、実際に達成したことの差

効果のギャップを埋めるためには、チームが自律的に動く必要がある。
（このギャップを埋めるための具体的な方法は、本書には書かれていません）

### 12章　 良い戦略フレームワークを作る
#### ビジョン
企業レベル CxOが策定
5～10年でどうなりたいか、顧客にとっての価値、マーケットでのポジション、ビジネスがどうなっているか

#### 戦略的意図
企業レベル ビジネスリードが策定
ビジョンを実現する上で立ちはだかっているビジネス上の課題は何か

#### プロダクトイニシアティブ
プロダクトレベル プロダクトリーダーシップチームが策定
プロダクトの観点で課題に取り組むには、どんな問題を扱えばよいか

#### オプション
プロダクトレベル プロダクト開発チームが策定
問題を解決して目標を達成する別の方法はないか

### 14章　プロダクトビジョンとポートフォリオ

Netflixのプロダクトイニシアティブは次のようにしている。

> 「Netflixの視聴者として、どこでも、誰とでも、快適にNetflixを見たい」

このプロダクトイニシアティブをもとに「Xboxで視聴可能にする」といった、やり方(オプション)を示せるようになっている。

#### プロダクトビジョン
> なぜあなたが作っているのか、顧客に対する価値提案が何なのかを伝えます

#### プロダクトポートフォリオ
> 複数のプロダクトを持つ会社は、プロダクトポートフォリオと呼ばれるものでプロダクトを包み込むことがよくあります

adobeのCreative suiteみたいなもの。

### 第IV部 プロダクトマネジメントプロセス

### 15章　プロダクトのカタ

メリッサ・ペリが提唱している「プロダクトのカタ」というプロセス。

5つの項目を決める。

- 現状
- 学習すべきこと
- 次のステップ
- 期待値
- 学習結果

決めるために6つの質問に答えていく。

1. 目標は何か？
2. 目標を踏まえて、自分たちは今どこにいるのか？
3. 目標に到達する上で立ちはだかる最大の問題や障害は何か？
4. どうやってその問題を解決するか？
5. 何が起こると予想されるか？（仮説）
6. 実際には何が起こったか、そこから何を学んだか？

### 16章　方向性の理解と成功指標の設定

##### 海賊指標
- アクイジション ユーザーがあなたを見つける
- アクティベーション ユーザーが初めてあなたのプロダクトを体験する
- リテンション ユーザーが戻ってくる割合
- リファーラル ユーザーがあなたのことをほかの人に話してくれる
- レベニュー 得られる利益

##### HEARTフレームワーク
ハピネス（幸福）、エンゲージメント、アダプション（採用）、リ テンション（利用継続）、タスクの成功

> HEART 指標の詳細については、ロッデンの記事「How to Choose the Right UX Metrics for Your Product（プロダクトに適したUX指標の選び方）」を参照してく ださい。

### 17章　問題の探索

##### ユーザー調査
ユーザー調査、観察、アンケート、顧客フィードバックは「顧客の声」を聞くというプロダクトマネージャの仕事。

##### 検証的調査
ユーザにプロトタイプを操作してもらうようなユーザビリティテストは、ユーザーが簡単にソリューションを使えるか確認するもので、実際に問題 を解決するかどうかではない。こういった手法は検証的調査といい、ユーザー調査とは異なる。

##### 生成的調査
解消するべき問題を見つけること

### 18章　ソリューションの探索

なにか作る場合、学習のための場合と、収益のための場合がある。

#### MVP (実用最小限の製品)
MVPは実験であると、提唱者も言っていて、学習のためのものつくり。収益を目指すプロダクトに最も重要な「体験」はMVPに含まれないから。

#### コンシェルジュ実験
まず手作業で新機能を提供する実験。

#### オズの魔法使い
ガワだけ本番にリリースして、裏では手作業で行う実験。

#### コンセプトテスト
LPやワイヤーフレーム、モック、動画でデモなどを見せる方法。簡潔に対象者へアイデアとメッセージを伝えるために使う。投資家などステークホルダへ伝える場合は特に有効。
もしテストユーザへ使って仮説を検証するなら、仮説が正しいか検証できる「質問」を用意すること。

#### そもそも実験は不要
実験はリスクの評価のために使う。
確実に改善することがわかっている場合は、実験をする必要がない。

### 19章　ソリューションの構築と最適化

#### ストーリーマッピング
横軸に時間・縦軸に派生的な機能を並べていく手法。
時間軸ごとに成功指標を付けていく。

> 、「自分たちの作業や価値を届けるために必要なことについてのコ ミュニケーションを助けるのが、ストーリーマッピングの目的である」

#### ベネフィットマッピング
#### 狩野モデル

#### 遅延コスト
価値と緊急度の掛け算で表すもの。

> ドン・レイネルトセンは著書『The Principles of Product Development Flow』の なかで、作業の優先順位づけにおける遅延コストの重要性について説明しています。 彼はそれを定量化すべき「唯一のもの」と呼んでいます。

### 第V部 プロダクト主導組織

> プロダクト主導組織の特徴は、アウトプットではなくアウトカムを中心にも のごとを組み立てて理解する文化にあり、それにはアウトカムに応じて戦略 を評価するリズムを企業が持っていることも含まれます

### 20章　アウトカムに着目したコミュニケーション

次の2つの会議は意思決定する場ではなく、進捗を示し、調査すべき危険信号を出すための手段。

#### プロダクトイニシアティブレビュー
プロダクトイニシアティブのオプションを四半期ごとにレビューする会。
CPO、CTO、プロ ダクト担当VP、プロダクトマネージャーが参加します。

#### リリースレビュー
毎月行う、チームが行ってきたことを一生懸命説明する会。

#### ロードマップ
ガントチャートと違い、リリース日を決めるものではない。
トッド・ロンバード とブルース・マッカーシーの著書『Product Roadmaps Relaunched』がおすすめ。

次の4つが重要な要素となり

- テーマ
- 仮説
- 目標と成功指標
- 開発のステージ
- 重要なマイルストーン

ステージの例

- 実験：問題の理解のみで、プロダクションコードは作らない
- アルファ版：MVPを作ったりして、最低限の機能を作って実験する
- ベータ版：一部の顧客のみが使用できる。リスクがある場合のみ作る
- GA：すべての顧客が使用できる

### 企業がプロダクト主導かどうかを判断する6つの質問

#### 1. 最後に作った機能やプロダクトのアイデアを思いついたのは誰ですか？
プロダクトのアイデアは自分たちのチームで考えるのが普通なので、「誰」と答えられずに困るのが健全。
誰かに作れと言われたから作っているとしたら、危険。

#### 2. 最後に開発中止を決めた機能や廃止したプロダクトは何ですか？
取り組むべき課題を決めた後でも、目標達成のために役に立たないとテストして気づくことはよくある。
何も廃止しないということは、チームに権限がないということで、プロダクトマネジメントが成功する環境とはほど遠い。

#### 3. 顧客と最後に話をしたのはいつですか？
プロダクトマネージャーにとって、顧客と話すことは推奨するべき仕事の一つ。

#### 4. 目標は何ですか？
目標がないのは論外、目標がアウトプット重視であるなら不健全。
アウトカム志向で、実行可能なものであるべき。

#### 5. 現在何に取り組んでいますか？
顧客とビジネスにとって解決するべき問題を熱心に語れればOK。そして様々な階層の人が同じ答えをするもの。

#### 6. プロダクトマネージャーはどんな人ですか？
> 開発者やUXの人たちが「プロダクトマネージャーが好きです。明確な方向性を持っていて、コミュニケーションも上手で、目標や問題に集中して取り組むのを助けてくれます」と言うようであれば、健全なプロダクトチームです

## 所感
アウトカムを軸に最適化していくプロダクト主導企業を目指すべきだという趣旨の本でした。
アウトカム≒顧客の感動ととらえると、『顧客に「感動」を与えていることが商品力（サービス力）として最も大事なこと』というラクーンの思想と似ているように思いました。
言い方を変えると同じものでも見え方が変わる場合があります。ラクーンがどこを目指しているのかを、この本の言葉と相互に翻訳すると、俯瞰的に状況が見えるかもしれないと思います。

「プロダクトマネージャはキャリアである」というのが印象的でした。
良いプロダクトはチームで協力しなければ作れないと思ってます。
もちろんプロダクトマネージャという役割を置いてプロダクトのアウトカムに責任を持つこともありますが、チームみんながアウトカムを考えて行動することが大事で、スキルだと思うとしっくりきました。

## お勧め度（☆☆☆☆☆）
★★★
プロダクトマネジメントについて基礎から網羅的にまとめられていて、すごく良いのですが、読みづらいです。
Netflixなど実在の企業のエピソードと、架空の企業でストーリー形式での説明がまぜこぜになっていて、どこまでがフィクションなのか注意深く読み解く必要があります。
翻訳も決して良くはないことも読みづらさの一因だと思います。
流し読みするには最適で、深く読み解くには別で調べたほうが良いのではないかと思いました。

## 質疑応答