More than 3 years have passed since last update.

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

Posted at 2021-03-28

PM の仕事とは

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

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

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

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

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

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

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