Product Management (Jan 2026)

このスキルは、アシスタントを講師ではなくオペレーターに変えます。

ここにあるものはすべて以下の特徴を持ちます:

• 実行可能: テンプレート、チェックリスト、デシジョンフロー
• 決定第一: 測定可能な成果、明示的なトレードオフ、明確な責任
• 体系的: 深掘り用リソース、即座にコピペできるテンプレート

---

モダンベストプラクティス (Jan 2026):

• 信頼度よりエビデンス品質を優先: 信号を strong/medium/weak でラベル付けし、何があなたの考えを変えるかを書く
• アウトプットよりアウトカム: ロードマップは機能リストではなく、測定可能なインパクトとガードレールを伴った賭けである
• メトリクスは定義されなければ実行可能でない (計算式 + 期間 + データソース)
• プライバシー、セキュリティ、アクセシビリティは事後対応ではなく要件
• ハイブリッド決定ループ: AIが異常、パターン、予測を浮かび上がらせ、人間が文脈、倫理、長期戦略を適用する
• アカウンタビリティ: プロダクトはしばしばビジネス成果に責任を持つ。組織内のオペレーティングモデルを確認し、ベンチマークを現在のソースで検証する
• ポートフォリオ多様化: 共通のヒューリスティックは 70% コア、20% 隣接、10% 変革的。戦略と制約に合わせて調整する

このスキルを使う場面

ユーザーが以下のようなプロダクト実務を行うよう求める場合、このスキルを使用します:

• "PRD / スペック / ビジネスケース / 1-pager を作成・改善する"
• "このアイデアをロードマップに変える" / "X のアウトカムロードマップ"
• "ディスカバリープラン / インタビュースクリプト / 実験プランを設計する"
• "成功メトリクス / OKR / メトリクスツリーを定義する"
• "このプロダクトを競合と位置付ける"
• "難しい会話 / フィードバック / 1:1 / ネゴシエーションを実施する"
• "プロダクト戦略 / ビジョン / 機会評価を計画する"

このスキルを使わない場面:

• 書籍の要約、哲学、または一般教育
• 長いケーススタディやストーリーテリング

---

クイックリファレンス

タスク	テンプレート	ドメイン	アウトプット
ディスカバリーインタビュー	customer-interview-template.md	Discovery	Mom Test パターン付きインタビュースクリプト
機会マッピング	opportunity-solution-tree.md	Discovery	アウトカム、問題、ソリューション付き OST
PMF サーベイ	pmf-survey-template.md	Discovery	Sean Ellis + NPS + 利用状況サーベイ
アウトカムロードマップ	outcome-roadmap.md	Roadmap	Now/Next/Later とアウトカム、テーマ
OKR 定義	okr-template.md	Metrics	1-3 個のオブジェクティブ、各 2-4 個のキーリザルト
プロダクト位置付け	positioning-template.md	Strategy	競合代替案 → 価値 → セグメント
プロダクトビジョン	product-vision-template.md	Strategy	From → To ナラティブ、3-5 年の視野
四半期レビュー	quarterly-product-review.md	Strategy	Keep / Cut / Double-down プロダクト監査
優先順位付け	prioritization-scorecard.md	Prioritization	RICE/ICE スコアリング、キル基準付き
キル基準	kill-criteria-template.md	Prioritization	イニシアチブごとの事前定義された停止条件
1:1 ミーティング	1-1-template.md	Leadership	チェックイン、進捗、ブロッカー、成長
インシデント後のデブリーフ	a3-debrief.md	Leadership	意図 vs 実際、根本原因、アクションアイテム

---

デシジョンツリー: 適切なワークフローの選択

ユーザーニーズ: [プロダクトワークタイプ]
    ├─ ディスカバリー / 検証?
    │   ├─ 顧客インサイト? → カスタマーインタビューテンプレート
    │   ├─ 仮説検証? → 仮説テストテンプレート
    │   └─ 機会マッピング? → Opportunity Solution Tree
    │
    ├─ 戦略 / ビジョン?
    │   ├─ 長期的方向性? → プロダクトビジョンテンプレート
    │   ├─ 市場位置付け? → 位置付けテンプレート (Dunford)
    │   ├─ 大きな機会? → 機会評価
    │   └─ Amazon スタイルのスペック? → PR/FAQ テンプレート
    │
    ├─ 計画 / ロードマップ?
    │   ├─ アウトカム駆動? → アウトカムロードマップ (Now/Next/Later)
    │   ├─ テーマベース? → テーマロードマップ
    │   └─ メトリクス / OKR? → メトリクスツリー + OKR テンプレート
    │
    ├─ 優先順位付け / フォーカス?
    │   ├─ 次に何を構築? → 優先順位付けスコアカード (RICE/ICE)
    │   ├─ 何をやめる? → キル基準テンプレート + 四半期レビュー
    │   ├─ スコープが大きすぎる? → スコープネゴシエーションパターン
    │   └─ PMF チェック? → PMF サーベイ + リテンション曲線分析
    │
    └─ リーダーシップ / チームオペレーション?
        ├─ 1:1 ミーティング? → 1-1 テンプレート
        ├─ フィードバック提供? → フィードバックテンプレート (SBI モデル)
        ├─ インシデント後? → A3 デブリーフ
        ├─ ステークホルダー抵抗? → ステークホルダー管理パターン
        └─ ネゴシエーション? → ネゴシエーション一覧 (Voss)

---

する / しない (Jan 2026)

する

• 決定から始める: 何を決定し、いつまでに、どんなエビデンスで決めるのか
• メトリクスを正確に定義し (計算式 + 期間 + データソース)、ガードレールを追加する
• ディスカバリーを使って構築前に価値をリスク軽減し、意見ではなくエビデンスで優先順位を付ける
• 機能グリッドではなく、競合デシジョンを「マッチ vs 無視」で書く

しない

• ロードマップシアター (アウトカムと学習ループなしの出荷リスト)
• 虚栄指標 (アクティベーション/リテンション定義なしの生サインアップ、インプレッション)
• "構築第一の検証" (仮説検証なし MVP の出荷)
• 目的制限、リテンション、アクセス制御なしでカスタマーデータを収集する
• ユーザー価値ではなく技術的エレガンスのために構築する (テックファウンダーの罠)
• キル基準なしで機能クリープ (すべての機能に事前定義された停止条件があるべき)
• トレードオフ分析なしでステークホルダーリクエストに「はい」と言う
• 一度だけ PMF を測定する、複数セグメント間で継続的に測定すべき

優先順位付けと「ノー」と言うこと

最も一般的なファウンダー-PM の失敗: すべてを構築し、何も止めず、インパクトの前に時間が尽きる。

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

フレームワーク	計算式 / 方法	最適な用途	注意点
RICE	(Reach x Impact x Confidence) / Effort	データ付きの機能比較	信頼度スコアのゲーミング
ICE	Impact x Confidence x Ease	素早い直感的優先順位付け	過度な簡素化
Opportunity Scoring	Importance x (Importance - Satisfaction)	ディスカバリー駆動、JTBD 整合	ユーザーリサーチデータが必要
Cost of Delay	Value per unit time / Duration	時間的に敏感なデシジョン	見積もりが難しい
Weighted Shortest Job First (WSJF)	Cost of Delay / Job Size	SAFe/Lean、フロー最適化	キャリブレーションされた見積もりが必要

1 つを選ぶ。継続的に使う。フレームワークより、すべてを同じ方法でスコアリングする規律の方が重要。

キル基準

すべてのイニシアチブには、停止するための事前定義された条件があるべき:

• 利用閾値: ターゲットユーザーの X% 未満が Y 週以内に採用すれば、停止する
• コスト上限: 開発が X 時間/ドルを超えた場合、一時停止し再評価する
• 時間制限: X 週以内に出荷されなければ、キルするか根本的にスコープ削減する
• メトリクスガードレール: [ガードレールメトリクス] が X% 以上低下した場合、ロールバック

開始前にこれらを定義するために assets/prioritization/kill-criteria-template.md を使用します。

フィーチャーブリッジ移行

既存フィーチャーを新しいフィーチャーに置き換える場合、古いフィーチャーをハードキルしないでください。ブリッジ移行パターンを使用してユーザーの喪失を防ぎます。

ブリッジモード: 古い機能と新しい機能を同時に実行します。デフォルトではユーザーを新しい体験にルーティングしますが、古いパスにアクセス可能なまま保ちます (リンク、フォールバック、または設定トグル経由)。

置換ベースのキルルール:

1. 吸収メトリクスを定義: 同じジョブに新しい機能を使用する古い機能のユーザー %
2. キル閾値を設定: 新機能が古い機能のユーザーの ≥80% を吸収
3. 期間を設定: 閾値がリテンション回帰なしで 14 連続日間保つ
4. 3 つの条件がすべて満たされた場合のみ古い機能をキル

ブリッジ移行シーケンス:

1. 古い機能と一緒に新機能をリリース
2. 新規ユーザーをデフォルトで新しい体験に
3. 既存ユーザーを段階的に移行 (段階的ロールアウト)
4. 監視: 吸収率、コホート別リテンション、サポートチケット
5. 古い機能が ≥80% を吸収していて 14 日間リテンション低下なし?
   ├─ はい → 古い機能をキル、コード削除
   └─ いいえ → ギャップを調査、新機能を反復、ブリッジを延長

ブリッジを使わないとき: セキュリティ脆弱性、コンプライアンス要件、またはほぼゼロ利用機能 (<1% MAU)。これらは通知をもって直接キルできます。

スコープネゴシエーション

ステークホルダーがスコープを追加するよう推し進める場合:

• トレードオフとして再フレーム: "X を追加できますが、Y をカットする必要があります。どちらが重要ですか?"
• アウトカムに固定: "目標は [メトリクス] です。この追加は動きますか?"
• 段階的デリバリーを提供: "V1 でなしで、測定し、データが支持していれば V2 で追加"
• すべてのスペックで明示的に非目標を文書化

「やめることリスト」四半期レビュー

毎四半期、assets/strategy/quarterly-product-review.md でプロダクトをレビュー:

• どの機能の利用率が <5%? → 削除候補
• どのイニシアチブが測定可能なアウトカムを生み出さなかった? → 停止またはピボット
• どの継続的コスト (メンテナンス、サポート) が価値を超えている? → サンセット
• "いつもそうだから" やっているが誰も求めていないことは? → 質問

詳細な優先順位付けパターンと実施例については references/prioritization-frameworks.md を参照してください。

---

プロダクト-マーケットフィット測定

PMF はバイナリイベントではありません。複数の次元で測定する信号です。

Sean Ellis テスト

ユーザーに調査: "[プロダクト] を使えなくなった場合、どう感じますか?"

• とても残念: PMF 信号では >40% がターゲット
• やや残念: 有用だが依存していない
• 残念でない: 価値を見出していない

完全なサーベイ (Sean Ellis + NPS + 利用質問を組み合わせたもの) については assets/discovery/pmf-survey-template.md を使用してください。

リテンション曲線分析

• コホートリテンションを時系列でプロット (プロダクトケイデンスに応じて週次または月次)
• 曲線の平坦化 = PMF 信号 (留まるユーザーは留まる)
• 曲線の低下 = PMF なし (保持されたユーザーも最終的に去る)
• ICP でセグメント化: 1 つのセグメントに PMF があり、別のセグメントにはないかもしれません

エンゲージメントスコアリング

アクティベーションを正確に定義 (計算式 + 期間 + データソース):

• どのアクションが「アクティベーション」を構成? (サインアップだけでなく)
• アクティベーション期間は? (最初の 7 日、最初の 14 日?)
• どのエンゲージメント深さが power users を casual と分離?

機能監査

定期的に機能利用を監査して、何を保持、改善、または削除するかを識別:

• 利用率上位 20% の機能 → 投資、磨く
• 中位 60% → 保持、拡張しない
• 下位 20% → 削除または再設計の候補
• 利用率に対してサポートコストが高い機能 → 再設計またはサンセット

セグメント化された PMF

PMF はセグメントによって異なります。以下を個別に測定:

• ICP vs 非 ICP カスタマー
• 無料 vs 有料ユーザー
• セルフサーブ vs セールス支援
• 会社規模、業種、地理別

詳細な PMF 測定方法については references/pmf-measurement.md を参照してください。

---

ステークホルダー管理

ファウンダーはボードメンバー、投資家、初期カスタマー、共同創業者、(最終的には) チームリードを管理します。多くの場合、公式な PM トレーニングなし。

主要なパターン:

• ボード / 投資家: メトリクス + デシジョン + 質問で月次更新。スライドデックではなくナラティブ形式。「出荷したこと」ではなく「学んだこと」で主導
• 初期カスタマー: パートナーであり、単なるユーザーではない。ロードマップ意図を共有 (コミットメントではなく)。フィーチャーリクエストではなく優先事項について入力を求める
• 共同創業者整合: 優先事項について週次同期。意見は違うが約束を守る。デシジョンを文書化
• ステークホルダーにノーと言う: "X をやっていません。[戦略に結びついた理由]。代わりにこれをやっていて、なぜかです。"

詳細なステークホルダー管理パターンについては references/stakeholder-management.md を参照してください。

---

良い状態とは

• エビデンス: 実質的な賭けのための 5-10 の実際のユーザータッチポイントまたは同等のプライマリデータ
• スコープ: テスト可能な明確な非目標と受け入れ基準
• 学習: 出荷後のレビュー、メトリクスデルタ、ガードレール影響、次の決定

PRD とスペック

PRD/スペックと執筆品質要件については、../docs-ai-prd/ のテンプレートを使用してください:

• PRD テンプレート: ../docs-ai-prd/assets/prd/prd-template.md および ../docs-ai-prd/assets/prd/ai-prd-template.md

オプション: AI / オートメーション

明示的にリクエストされ、ポリシー準拠の場合のみ使用します。

• AI システムライフサイクル: assets/ai/ai-lifecycle-template.md
• エージェントワークフロードキュメント: assets/ai/agentic-ai-orchestration.md
• AI プロダクトパターン: references/ai-product-patterns.md

ナビゲーション

リソース

• references/discovery-best-practices.md
• references/roadmap-patterns.md
• references/delivery-best-practices.md
• references/strategy-patterns.md
• references/positioning-patterns.md
• references/data-product-best-practices.md
• references/interviewing-patterns.md
• references/metrics-best-practices.md
• references/leadership-decision-frameworks.md
• references/operational-guide.md
• references/prioritization-frameworks.md
• references/pmf-measurement.md
• references/stakeholder-management.md
• data/sources.json

テンプレート

• ディスカバリー: assets/discovery/customer-interview-template.md, assets/discovery/assumption-test-template.md, assets/discovery/opportunity-solution-tree.md, assets/discovery/pmf-survey-template.md
• 優先順位付け: assets/prioritization/prioritization-scorecard.md, assets/prioritization/kill-criteria-template.md
• 戦略/ビジョン: assets/strategy/product-vision-template.md, assets/strategy/opportunity-assessment.md, assets/strategy/positioning-template.md, assets/strategy/PRFAQ-template.md, assets/strategy/quarterly-product-review.md
• データ: assets/data/data-product-canvas.md
• ロードマップ: assets/roadmap/outcome-roadmap.md, assets/roadmap/theme-roadmap.md
• メトリクス: assets/metrics/metric-tree.md, assets/metrics/okr-template.md
• Ops/リーダーシップ: assets/ops/1-1-template.md, assets/ops/feedback-template.md, assets/ops/a3-debrief.md, assets/ops/negotiation-one-sheet.md

関連スキル

• ../docs-ai-prd/SKILL.md — PRD、ストーリー、プロンプト/プレイブックテンプレート
• ../software-architecture-design/SKILL.md — スペックの設計システムガイダンス
• ../software-frontend/SKILL.md — プロダクト仕様の UI 実装考慮事項
• ../software-backend/SKILL.md — プロダクトデシジョンのバックエンド/API 含意
• ../startup-growth-playbooks/SKILL.md — アクティベーション設計用 PLG ケーススタディ

---

オペレーショナルガイド

詳細なパターン、テンプレートウォークスルー、例フロー、実行チェックリストについては references/operational-guide.md を参照してください。SKILL.md はナビゲーションハブとして保ちます。アーティファクト製作時は assets/ を使用してください。

---

外部リソース

公式フレームワーク (Lean Startup、OST、PR/FAQ、OKR) と AI/LLM セーフティリファレンスについては data/sources.json を参照してください。

---

上記のクイックリファレンスとデシジョンツリーを使用してテンプレートを選択し、深掘りについてはオペレーショナルガイドに従ってください。

---

トレンド認識プロトコル

重要: ユーザーがプロダクト管理ツール、フレームワーク、プラクティスに関する推奨質問をする場合、回答する前に web 検索ツールを使用して現在のトレンドを確認してください。Web 検索が利用できない場合は、data/sources.json を使用し、検証したことと想定したことを明確に述べてください。

トリガー条件

• "[ロードマップ/プロダクト分析/ディスカバリー] 用の最適なツールは?"
• "[OKR/メトリクス/カスタマーフィードバック] に何を使うべき?"
• "プロダクト管理の最新動向は?"
• "[ディスカバリー/ロードマップ/優先順位付け] の現在のベストプラクティス?"
• "[フレームワーク/ツール] は 2026 年でも関連がある?"
• "[Linear] vs [Jira] vs [その他]?" または "[Amplitude] vs [Mixpanel]?"
• "[AI プロダクト管理/エージェントプロダクト] の最良のアプローチ?"

必須検索

1. 検索: "product management best practices 2026"
2. 検索: "[特定ツール] vs alternatives 2026"
3. 検索: "product management trends January 2026"
4. 検索: "[ディスカバリー/ロードマップ/OKR] frameworks 2026"

報告内容

検索後、以下を提供:

• 現在のランドスケープ: 現在人気のある PM ツール/フレームワーク
• 新しいトレンド: 注目を集めている新しいツール、メソッド、パターン
• 非推奨/低下: 関連性を失ったフレームワーク/ツール
• 推奨: 新しいデータに基づき、静的知識だけではない

例トピック (新鮮な検索で検証)

• プロダクト管理ツール (Linear、Productboard、Notion、Coda)
• 分析プラットフォーム (Amplitude、Mixpanel、PostHog)
• ディスカバリーおよびリサーチツール (Maze、UserTesting、Dovetail)
• ロードマップアプローチ (アウトカムベース、テーマベース、now/next/later)
• AI プロダクト管理パターン
• 優先順位付けフレームワーク (RICE、ICE、機会スコアリング)
• OKR およびメトリクスツール

ファクトチェック

• Web 検索/web フェッチを使用して、最終回答の前に現在の外部事実、バージョン、価格、期限、規制、またはプラットフォーム動作を検証してください
• プライマリソースを優先; 不安定な情報についてはソースリンクと日付を報告
• Web アクセスが利用できない場合は、制限を述べ、ガイダンスを未検証としてマーク