Udemyメモ「プロダクトマネジメント入門講座：作るなら最初から世界を目指せ！シリコンバレー流Product Management」

[プロダクトマネジメント入門講座：作るなら最初から世界を目指せ！シリコンバレー流Product Management \| Udemy](https://www.udemy.com/course/introduction-to-pm/)

## PM の仕事とは

### プロダクトビジョンの作成
1. ProductVision とは
    - 会社の Misson を達成したい`超長期的ゴール`から導出される
    - プロダクトの長期的なゴール ( 1~2年スパン )
    - 例: 「次の1年で解決すべき顧客の課題は〜〜〜だから、プロダクトは〜〜〜となる必要あり」
2. 初めに会社が考えているゴールを確認 ( CxO 役職と調整 )
    - PM チーム全体で ProductVision を導出
    - 作成時期は、6ヶ月 ~ 1年スパン
3. 各担当 PM の担当領域でゴールを決定
    - 担当領域の中で、解決すべき問題は何か


### リサーチ
1. リサーチとは
    - 顧客が「良い」と思うプロダクトを作る視点を持つ
    - なぜ、ユーザは〜〜〜という問題を抱えるのか？
    - プロダクトが解決しようとする問題は何か？
2. プロダクトが世の中に存在する時の全体像を掴む
    - 顧客および周辺人々のネットワーク
    - プロダクト周辺のテクノロジーやトレンド
    - 顧客の行動や導線、感情
    - 使用場所やタイミング
3. プロダクトがビジネスとして成立するか
    - ProductMarketFit が存在するか仮説を立てる
    - マーケット規模、潜在ユーザ規模


### プロダクトプランニング
1. 自分の中で5つの質問に対する解を用意
    - ユーザが直面する問題に対して、自分の立ち位置や業界の流れは何か
    - プロダクトを通して、たどり着きたいゴールはどこか
    - そのために、どのような機能やプロダクトを継続リリースすることで、たどり着くのか
    - その際に想定できるリスクは何か
    - リスクを乗り越えていけると信じられる理由は何か


### ロードマップ
1. ロードマップとは
    - 新機能や新プロダクトのマーケット投入時期を示す
    - マーケティング部門は GoToMarketプラン、営業部門は Salesプランを策定
    - PM は常にアップデートを続ける
2. 会社全体として、方向性と戦略の意思統一を作り、KPI として定量的に設定 ( 3ヶ月後 ~ 1年後 )
3. KPI に一番効果のあるプロダクトの機能やアイデア、その前提となる仮説を洗い出し
4. アイデアが発生させる KPI へのインパクトとリソース配分から、優先順位付け
5. 優先順位に基づき、タイムライン毎に設定 ( 月毎、四半期毎、半年毎 )
6. 開発とユーザ向けテストを頻繁に回し、仮設検証しつつ、プロダクトをリリース
7. ロードマップに更新あれば実施


## PM とアジャイル開発プロセス
- すべての開発は、投資でありコストである
- どのような開発投資を決めることをスプリントプランニング
- スプリントは決定した方向で、投資効果を最大化すべく全速力で動く
- スプリント半ばにおける機能改善要求は、多大なコストが発生する
- `機能改善による実現見込み利益 >> スプリント中止による損失` を見て判断

### 開発プロセス
1. プロダクトバックログ（ 主担当: PM ）
    - PRD に基づき、開発するプロダクトの機能一覧をハイレベルで抽出
    - 各機能に対して、優先順位を設定
    - プロダクトの実装目的を記述
2. スプリントプランニング（ 主担当: PM・PG ）
    - 開発機能に対する担当者を決定
    - 開発機能に対する工数を見積もり
    - PRD の抜け漏れを PM に確認
3.  スプリントバックログ（ 主担当: PG ）
    - 開発機能について、エンジニアリングタスクに分解
    - タスクに対する工数を見積もり
    - タスクに対する優先順位を設定
4. スプリント（ 主担当: PG ）
    - 2~4 週間単位の開発期間
    - 毎日 or 週3回程度、チーム内で MTG 実施 ( 進捗報告、担当間のタスク依存関係を元に調整 )
    - バグ発生時、即座の修正 or 後回しか相談
    - インクリメント（ 主担当: PM ）
4. スプリント期間中の PM 対応
    - 次のスプリントで対応する事項を調整
    - バグの対応優先順位付け
5. スプリントレビュー
    - QA を通し、リリース可能な機能を確認
    - 開発中に発生したバグの対応時期を確認
6. スプリント振り返り
    - スプリント期間中に発生した、プロセス改善案等のフォローアップ

### 非開発部門との関わり
1. 他チーム内で、機能改善要求をまとめ、リストにして優先順位を設定
2. 他チーム代表は、PM に対して定期的に共有
3. PM は、既存の開発ロードマップを鑑みて優先順位を設定
    - 要求事項は、ユーザに対して価値を提供できるか
    - 要求事項は、他の開発を停止してでも、会社に利益をもたらすか
    - ロードマップとは、`今後の実装プロダクトや機能をリリース見通し` ( 必ず実装する性質の計画でなく、あくまで変化する可能性を加味した見通し )


## 実行と意思決定
### 開発中の PM の役割
- PRD の段階で、技術仕様書に落とし込み時に要件定義が甘い場合、都度、詳細の詰めを追加実施
    - 初期の開発見積もりより、ボリュームが多いことに気付く
    - API ドキュメント通り動かない
    - 技術的負債(バグ)が開発スピード落とす
    - 開発担当のエンジニアが転職等
- PM の役割: タスクの優先順位付け
    - バグ修正の優先順位付け
    - どのデザインパターンで進めるか
    - 想定通り動作しない場合、ワークアラウンドオプション出しと、リスク評価および選択
    - 実装機能の優先順位付け
- PM の役割: コミュニケーション
    - 開発メンバーが障害にぶつかってないか確認
    - 当初予定の PRD の通り進めるか、スコープ変更した場合は影響範囲との調整
    - 上層部への調整 ( 進捗・投資効果・メンバーのモチベーション維持 )
- PM の役割: プロダクトリリース時
    - クリティカルなバグは全て潰す
    - ユーザに対する UI/UX は、期待値に届いているか
    - GoToMarket 戦略は、実行可能な状態か
    - KPI のモニタリング準備はできているか
- PM の役割: プロダクトリリース後
    - KPI のモニタリング
    - ユーザからのフィードバック確認
    - クラッシュやバグの発生率を確認

### PM の姿勢
- 失敗の可能性がある限り、初期段階では小さく試す
- 事前に失敗時の手打ちをする
- 失敗は隠さず、学ぶ
- 失敗を共有し、組織全体の「知見」に昇華


## PM を生かせる組織形態とは
1. 組織文化
    - PM がプロダクト開発に集中できる仕組みを整える
    - ロードマップの変更が許容できる文化を整える
    - 失敗をネガティブ感覚から、組織への学びの感覚を持つ
2. チーム構成
    - 最小構成
        - PM
        - Dev ( 兼QA )
        - Designer
    - 標準構成
        - PM
        - PjM
        - DataAnalyst
        - Dev
        - QA
        - Designer
    - 最適構成
        - PM
        - PjM
        - DataAnalyst
        - Web/Mobile Dev
        - Backend Dev
        - QA
        - Designer
3. 会社側によるチームへのサポート
    - 自律的に動けるよう、Vision や KPI を決めたら、会社はチームに委ねる
    - 意思決定をしやすくして、意思決定ラインを短く簡潔にする
    - 構成単位を小さく ( 例: Amazon はピザ2枚で賄える人数程度を設定 )