product-manager

プロダクトマネージャー

適切なものを、適切な順序で、適切な人々とともに作るための戦略的なプロダクトマネジメントの専門知識です。

哲学

優れたプロダクトマネジメントとは、機能のことではありません。成果、つまり、実際のユーザーが抱える問題を、ビジネス上の結果につながる方法で解決することです。

優れたプロダクトマネージャーは、次のように行動します。

1. 解決策ではなく、問題にこだわる — 作る前に深く理解します
2. 「はい」よりも「いいえ」を多く言う — 集中することも機能の一つです
3. あらゆる世界をつなぐ — 顧客、エンジニアリング、デザイン、ビジネスを結びつけます
4. 決定を取り消せるようにする — すばやくリリースし、さらにすばやく学びます
5. アウトプットではなく成果に責任を持つ — 影響がなければ、機能をリリースしても意味がありません

このスキルの仕組み

呼び出されると、rules/ にある次のガイドラインを適用します。

• roadmap-* — ロードマップの作成、維持、共有
• prioritization-* — RICE、ICE、MoSCoW、優先順位付けのフレームワーク
• stakeholder-* — 組織の上層、下層、各部門との関係管理
• sprint-* — スプリント計画、バックログの整理、セレモニー
• scoping-* — 機能のスコープ設定、トレードオフ、MVP の定義
• release-* — リリース計画、調整、共有
• metrics-* — プロダクト指標、OKR、成功の測定
• debt-* — 技術的負債の管理とバランス調整

主要なフレームワーク

プロダクトトリオ

         ┌─────────────────┐
         │     Product     │
         │     Manager     │
         └────────┬────────┘
                  │
    ┌─────────────┼─────────────┐
    │             │             │
    ▼             ▼             ▼
┌────────┐  ┌──────────┐  ┌──────────┐
│  UX    │  │Engineering│  │  Data    │
│Designer│  │   Lead    │  │ Analyst  │
└────────┘  └──────────┘  └──────────┘

優先順位付けフレームワークの比較

フレームワーク	最適な用途	スコアリング	複雑さ
RICE	機能の優先順位付け	リーチ × インパクト × 確信度 / 労力	中
ICE	迅速な意思決定	インパクト × 確信度 × 容易さ	低
MoSCoW	リリースのスコープ設定	必須／すべき／できれば／対象外	低
Kano	顧客満足度	魅力／性能／基本	高
価値対労力	迅速な 2×2 プロット	定性的な象限	低

プロダクト開発ループ

┌──────────────────────────────────────────────────┐
│                                                  │
│   ┌──────────┐    ┌──────────┐    ┌──────────┐  │
│   │ Discover │───▶│  Define  │───▶│  Develop │  │
│   └──────────┘    └──────────┘    └──────────┘  │
│         ▲                               │        │
│         │         ┌──────────┐          │        │
│         └─────────│  Measure │◀─────────┘        │
│                   └──────────┘                   │
│                                                  │
└──────────────────────────────────────────────────┘

ロードマップの種類

種類	対象者	期間	詳細度
ビジョン	取締役会、投資家	2～5 年	大まかなテーマ
戦略	リーダーシップ	1 年	四半期ごとの目標
リリース	ステークホルダー	四半期	機能／エピック
スプリント	開発チーム	2 週間	ストーリー／タスク

PM 意思決定マトリックス

                    High Confidence
                         │
         ┌───────────────┼───────────────┐
         │   VALIDATE    │     SHIP      │
         │  (test more)  │   (execute)   │
Low      │               │               │   High
Impact───┼───────────────┼───────────────┼───Impact
         │    IGNORE     │  INVESTIGATE  │
         │  (say no)     │  (research)   │
         └───────────────┼───────────────┘
                         │
                    Low Confidence

ステークホルダーマップ

ステークホルダー	主な関心事	コミュニケーションスタイル
経営幹部	ビジネス上の成果、戦略	大局的、指標重視
エンジニアリング	技術的な実現可能性、品質	詳細、協調的
デザイン	ユーザー体験、使いやすさ	視覚的、ユーザー中心
営業	収益、競争優位性	顧客事例、スケジュール
マーケティング	ポジショニング、ローンチ時期	メッセージ、日程
サポート	ユーザー満足度、問い合わせ量	問題点、頻度
顧客	解決される問題、価値	共感、傾聴

アンチパターン

• 機能ファクトリー — 成果を測定せずにリリースする
• ロードマップ劇場 — ロードマップを仮説ではなく約束として扱う
• ステークホルダー主導の開発 — 重要なことではなく、声の大きい要望に応じて作る
• スコープクリープの容認 — 「もう一つだけ」に決して断らない
• ベロシティ崇拝 — インパクトより速度の最適化を優先する
• ドキュメントによる麻痺 — リリースするより完璧な仕様を優先する
• 注文を受けるだけの PM — 問題を解決せず、チケットを書く
• 技術的負債の無視 — 崩れかけた基盤の上に機能をリリースする