プロダクトマネジメントAIスキル

.factory/skills/product-management/
├── SKILL.md
├── prd-template.md (optional)
├── feature-analysis-framework.md (optional)
└── user-research-templates.md (optional)

---
name: product-management
description: Assist with core product management activities including writing PRDs, analyzing features, synthesizing user research, planning roadmaps, and communicating product decisions. Use when you need help with PM documentation, analysis, or planning workflows that integrate with your codebase.
---
# Skill: Product management AI

## Purpose

Assist with core product management activities including writing product requirements documents (PRDs), analyzing feature requests, synthesizing user research, planning roadmaps, and communicating product decisions to stakeholders and engineering teams.

## When to use this skill

- You need to **write or update PRDs** with clear requirements, success metrics, and technical considerations.
- You're **evaluating feature requests** and need structured analysis of impact, effort, and priority.
- You need to **synthesize user research** findings into actionable insights.
- You're **planning roadmaps** and need to organize, prioritize, and communicate plans.
- You need to **communicate product decisions** clearly to engineering, design, and business stakeholders.
- You're doing **competitive analysis** or market research synthesis.
- You need to **track and analyze product metrics** to inform decisions.

## Key capabilities

Unlike point-solution PM tools:

- **Integrated with codebase**: Can reference actual code, APIs, and technical constraints.
- **Context-aware**: Understands your specific product, architecture, and technical debt.
- **Flexible templates**: Adapt documentation to your organization's needs.
- **Version controlled**: All artifacts live in git alongside code.
- **Collaborative**: Works within existing dev workflows (PRs, issues, docs).

## Inputs

- **Product context**: Current state, key stakeholders, strategic goals.
- **Feature requests**: User feedback, business needs, or strategic initiatives.
- **Technical constraints**: Known limitations, dependencies, or technical debt.
- **User research**: Interview notes, survey results, analytics data.
- **Business goals**: Metrics, OKRs, or success criteria to optimize for.

## Out of scope

- Making final product decisions (this is the PM's job; the skill assists).
- Managing stakeholder relationships and politics.
- Detailed UI/UX design work (use design tools and collaborate with designers).
- Project management and sprint planning (use project management tools).

## Conventions and best practices

### PRD structure
A good PRD should include:

1. **Problem statement**: What user pain point or business need are we addressing?
2. **Goals and success metrics**: What does success look like quantitatively?
3. **User stories and use cases**: Who will use this and how?
4. **Requirements**: Functional and non-functional requirements, prioritized.
5. **Technical considerations**: Architecture implications, dependencies, constraints.
6. **Design and UX notes**: Key interaction patterns or design requirements.
7. **Risks and mitigations**: What could go wrong and how to address it.
8. **Launch plan**: Rollout strategy, feature flags, monitoring.
9. **Open questions**: What still needs to be decided or researched.

### Feature prioritization
Use structured frameworks to evaluate features:

- **RICE**: Reach × Impact × Confidence / Effort
- **ICE**: Impact × Confidence × Ease
- **Value vs. Effort**: 2×2 matrix plotting value against implementation cost
- **Kano Model**: Categorize features into basic, performance, and delighters

### User research synthesis
When synthesizing research:

1. **Identify patterns**: What themes emerge across participants?
2. **Quote verbatim**: Include actual user quotes to illustrate points.
3. **Quantify when possible**: "7 out of 10 participants said..."
4. **Segment findings**: Different user types may have different needs.
5. **Connect to metrics**: How do qualitative findings explain quantitative data?

### Roadmap planning
Effective roadmaps should:

- **Theme-based**: Group work into strategic themes, not just feature lists.
- **Time-horizoned**: Now / Next / Later or Quarterly structure.
- **Outcome-focused**: Emphasize goals and outcomes, not just outputs.
- **Flexible**: Leave room for learning and adjustment.
- **Communicated clearly**: Different views for different audiences.

## Required behavior

1. **Understand context deeply**: Review existing docs, code, and prior discussions before proposing changes.
2. **Ask clarifying questions**: Don't assume; clarify ambiguous requirements or goals.
3. **Be specific and actionable**: Avoid vague language; provide concrete, testable requirements.
4. **Consider tradeoffs**: Explicitly discuss pros/cons of different approaches.
5. **Connect to strategy**: Tie features and decisions back to higher-level goals.
6. **Involve stakeholders**: Identify who needs to review or approve.
7. **Think through edge cases**: Don't just focus on happy paths.
8. **Make it measurable**: Propose concrete metrics to track success.

## Required artifacts

Depending on the task, generate:

- **PRD document**: Comprehensive product requirements in markdown format.
- **Feature analysis**: Structured evaluation of a feature request.
- **Research synthesis**: Summary of user research findings with insights.
- **Roadmap document**: Organized view of planned work with themes and timelines.
- **Decision document**: Record of key product decisions and rationale.
- **Competitive analysis**: Comparison of competitor features and approaches.
- **Metric definitions**: Clear definitions of success metrics and how to measure them.

## Implementation checklist

### Writing a PRD
- [ ] Understand the problem space and strategic context
- [ ] Review related code, APIs, and technical constraints
- [ ] Interview key stakeholders (engineering, design, business)
- [ ] Research user needs and competitive landscape
- [ ] Draft problem statement and goals
- [ ] Define user stories and use cases
- [ ] Specify functional and non-functional requirements
- [ ] Document technical considerations and dependencies
- [ ] Define success metrics and measurement approach
- [ ] Identify risks and mitigation strategies
- [ ] Plan rollout and launch approach
- [ ] Review with stakeholders and iterate

### Analyzing a feature request
- [ ] Clarify the user problem or business need
- [ ] Identify target users and use cases
- [ ] Estimate impact (users affected, business value)
- [ ] Assess implementation effort and complexity
- [ ] Identify dependencies and risks
- [ ] Check alignment with product strategy
- [ ] Compare against alternatives
- [ ] Calculate prioritization score (RICE, ICE, etc.)
- [ ] Make recommendation with clear reasoning

### Synthesizing user research
- [ ] Review all research materials (transcripts, notes, data)
- [ ] Identify key themes and patterns
- [ ] Extract representative quotes
- [ ] Segment findings by user type if relevant
- [ ] Connect qualitative findings to quantitative data
- [ ] Formulate insights and implications
- [ ] Generate actionable recommendations
- [ ] Prioritize recommendations by impact

### Planning a roadmap
- [ ] Review strategic goals and OKRs
- [ ] Collect input from stakeholders
- [ ] Assess current state and technical debt
- [ ] Group potential work into strategic themes
- [ ] Prioritize themes and initiatives
- [ ] Estimate sizing and dependencies
- [ ] Organize into time horizons (Now/Next/Later)
- [ ] Define success criteria for each initiative
- [ ] Create views for different audiences
- [ ] Review and socialize with stakeholders

## Example workflows

### Example 1: Writing a PRD for a new feature

```markdown
# PRD: 高度検索機能

## 問題の説明
ユーザーは、複数の条件（価格帯、場所、カテゴリ、機能）でカタログ内の特定のアイテムを見つけるのに困難を感じているとの報告が頻繁にあります。現在の検索は単純なテキストクエリのみをサポートしており、以下の結果をもたらしています：
- 検索結果ページの高い離脱率（サイト平均32%に対し65%の離脱率）
- 検索ヘルプを求めるサポートチケットの増加（月150件）
- コンバージョン機会の損失（年間売上影響額推定50万ドル）

## 目標と成功指標
**主要目標**: ユーザーが複数のフィルターを使用して関連するアイテムを迅速に見つけられるようにする。

**成功指標**:
- 検索結果ページの離脱率を65%から40%未満に削減
- 検索からの購入コンバージョン率を25%向上
- 検索関連サポートチケットを50%削減
- 30日以内にユーザーの70%が少なくとも1つのフィルターを使用

## ユーザーストーリー

### Must Have
1. 購入者として、予算内のアイテムを見つけられるよう価格帯でフィルタリングしたい
2. 購入者として、近くのアイテムを見つけられるよう場所でフィルタリングしたい
3. 購入者として、アイテムタイプを絞り込むためにカテゴリでフィルタリングしたい
4. 購入者として、必要なものを正確に見つけるために複数のフィルターを組み合わせたい
5. 購入者として、適用前にマッチするアイテム数を知るためにフィルター件数を見たい

### Should Have
6. 購入者として、再適用の必要がないようフィルター設定を保存したい
7. 購入者として、検索クエリに基づく推奨フィルターを見たい
8. 購入者として、フィルタリングされた結果を関連度、価格、または日付で並び替えたい

### Nice to Have
9. 購入者として、新しいマッチを通知する保存検索を作成したい
10. 購入者として、フィルタリングされた検索URLを他の人と共有したい

## 要件

### 機能要件

**フィルタータイプ** （優先度: Must Have）
- 価格帯フィルター: 最小/最大入力 + 一般的なプリセット（$0-50、$50-100など）
- 場所フィルター: 半径選択 + 郵便番号入力
- カテゴリフィルター: 複数選択可能な階層カテゴリツリー
- カスタム属性フィルター: アイテムタイプに基づく（サイズ、色、状態など）

**フィルター動作** （優先度: Must Have）
- フィルターは即座に適用（「適用」ボタンなし）または500ms未満の遅延
- アクティブフィルターを反映したURL更新（共有可能リンク）
- フィルターがアクティブな時に全フィルタークリアボタンが表示
- セッション内でフィルター状態が持続
- モバイルフレンドリーなフィルターUI（モバイルではドロワーまたはモーダル）

**検索統合** （優先度: Must Have）
- フィルターがテキスト検索クエリと連動
- テキストクエリに基づくフィルターファセット件数の更新
- 検索語に基づく自動フィルター提案（例：「赤」→ 色フィルターを提案）

### 非機能要件

**パフォーマンス** （優先度: Must Have）
- 初期ページ読み込み時間p95で2秒未満
- フィルター適用応答時間p95で500ms未満
- 性能劣化なしに10,000以上の同時ユーザーをサポート
- 100万以上のアイテムに対する効率的なインデックス化

**スケーラビリティ** （優先度: Should Have）
- コード変更なしに設定可能なフィルター定義
- 50以上のフィルタータイプのサポート
- 新カテゴリ用の新フィルタータイプを簡単に追加

**アクセシビリティ** （優先度: Must Have）
- すべてのフィルターでキーボードナビゲーション
- 適切なARIAラベルによるスクリーンリーダーサポート
- ハイコントラストモードサポート
- モバイルでタッチターゲットサイズ≥44×44px

## 技術的考慮事項

### アーキテクチャ
- **検索バックエンド**: フィルター集計で既存Elasticsearchクラスターを拡張
- **API変更**: フィルター用の新しい`/search`エンドポイントクエリパラメータ; レスポンスでフィルターファセットを返す
- **フロントエンド**: URL状態管理付きReactコンポーネント（React Router）
- **キャッシュ**: フィルター定義とファセット件数をキャッシュ（Redis、TTL 5分）

### 依存関係
- 効率的な集計をサポートするためElasticsearch 8.xへのアップグレード（現在7.x）
- フィルター固有フィールドを含むようアイテムスキーマを更新
- 段階的展開をサポートするバックエンドAPIバージョニング

### データモデル
```typescript
interface SearchFilters {
  price?: { min: number; max: number };
  location?: { lat: number; lng: number; radius: number };
  categories?: string[]; // Category IDs
  attributes?: Record<string, string[]>; // Dynamic attributes
}

interface SearchResponse {
  items: Item[];
  facets: {
    [filterName: string]: {
      values: Array<{ value: string; count: number }>;
    };
  };
  total: number;
}
```

### 技術的リスク
1. **Elasticsearchパフォーマンス**: 複雑な集計が検索遅延に影響する可能性
   - *軽減策*: 本番データでの負荷テスト; キャッシュ追加; 事前集計を検討
2. **インデックスサイズ拡大**: より多くのフィールド = より大きなインデックスとより遅いインデックス化
   - *軽減策*: インデックスサイズを監視; 異なるアイテムタイプに対して分離インデックスを検討
3. **スキーマ進化**: 新しいフィルター追加にはインデックス更新が必要
   - *軽減策*: 柔軟なスキーマ設計; 段階的展開を計画

## デザインとUXの注意点

### デスクトップレイアウト
- 左サイドバーのフィルター（持続的、折りたたみ不可）
- 上部にソートコントロールがあるメイン結果エリア
- アクティブフィルターを示すフィルターチップを結果の上に配置

### モバイルレイアウト
- ヘッダーの「フィルター」ボタンがボトムシートを開く
- ボタンにアクティブフィルター件数のバッジを表示
- ボトムシートに適用ボタン（リクエスト削減のためモバイルでは自動適用しない）

### フィルターUIパターン
- 価格: デュアルスライダー + テキスト入力
- 場所: 場所検索オートコンプリート + 半径選択
- カテゴリ: チェックボックス付き展開可能ツリー
- 属性: チェックボックスグループ、折りたたみ可能セクション

## リスクと軽減策

| リスク | 可能性 | 影響 | 軽減策 |
|------|-----------|--------|------------|
| 複雑フィルターでのパフォーマンス劣化 | 中 | 高 | 負荷テスト; キャッシュ; 機能フラグによる段階展開 |
| ユーザーによるフィルター採用率の低さ | 中 | 高 | ユーザーテスト; 目立つUI; 初回訪問時のチュートリアル |
| Elasticsearchアップグレード問題 | 低 | 高 | ステージングでテスト; ロールバック計画; オフピーク時デプロイ |
| フィルターオプションが圧倒的になる | 中 | 中 | フィルター優先順位付けのためのユーザー調査; 「その他フィルター」段階的開示を検討 |

## ローンチ計画

### フェーズ1: MVP (週1-2)
- 価格、場所、カテゴリフィルターのみ
- デスクトップウェブのみ
- パフォーマンステストのため5%展開

### フェーズ2: 拡張 (週3-4)
- カスタム属性フィルターを追加
- モバイル対応デザイン
- 25%のユーザーに拡張

### フェーズ3: 完全ローンチ (週5-6)
- 保存検索設定（ログインユーザー）
- 100%展開
- メトリクス監視と改善

### 機能フラグ
- `advanced_search_enabled`: 機能全体のマスターフラグ
- `advanced_search_filters`: 個別のフィルタータイプを有効/無効にできる
- `advanced_search_saved_prefs`: 保存設定機能

### 監視
- 成功メトリクス（離脱率、コンバージョン、エンゲージメント）を追跡するダッシュボード
- 検索APIのエラー率と遅延
- フィルター使用状況分析（最もよく使われるフィルター、組み合わせ）
- 検索遅延>1秒またはエラー率>1%のアラート

## 未解決の質問

1. **フィルターデフォルト**: ユーザー履歴や場所に基づいて事前適用すべきフィルターはあるか？（担当者: PM、期限: 週1）
2. **パーソナライゼーション**: 保存設定と共有フィルターURLの競合をどう処理するか？（担当者: Eng、期限: 週2）
3. **モバイルUX**: モバイルは即座適用か「適用」ボタンが必要か？（担当者: Design、期限: 週1）
4. **分析**: どの特定のフィルター操作を追跡すべきか？（担当者: Data、期限: 週2）

## ステークホルダーとレビュワー

- **PM担当**: Jane Doe
- **エンジニアリングリード**: John Smith
- **デザイン**: Alice Johnson
- **データサイエンス**: Bob Lee（メトリクスと計装）
- **承認必要**: VP Product、VP Engineering

---
*最終更新*: 2025-11-19
*ステータス*: 下書き → レビュー → 承認 → 進行中
```

### Example 2: Feature request analysis

```markdown
# 機能分析: ダークモードサポート

## リクエスト要約
**ソース**: ユーザーフィードバック（過去6ヶ月で150以上のリクエスト）、競合圧力
**説明**: ウェブおよびモバイルアプリにダークモードテーマオプションを追加

## ユーザーニーズ
低照度環境で作業するユーザーが、現在のライトモードのみのテーマで目の疲労を報告。パワーユーザー（DAUの25%）は1日3時間以上アプリを使用し、ダークモードを強く好む。よくあるフィードバック：「他のところではダークモードを使っているのに、なぜここでは使えないのか？」

## 対象ユーザー
- パワーユーザー: 30万ユーザー、1日3時間以上の使用
- 夜間/夜のユーザー: 主に午後6時から午前12時にアプリを使用する45万ユーザー
- アクセシビリティユーザー: 光過敏症や視覚障害のあるユーザー

## 影響評価

### ユーザー影響
- **リーチ**: 約75万ユーザー（ユーザーベースの45%）がダークモードをリクエストまたは使用する
- **影響スコア**: 8/10 - 対象ユーザーには高影響; 他のユーザーには中立
- **確信度**: 85% - ユーザー調査と競合データからの強いシグナル

### ビジネス影響
- **リテンション**: パワーユーザー（高価値セグメント）のリテンション向上の可能性
- **獲得**: 競合ポジショニングのための必要最低条件
- **収益**: リテンションと満足度を通じた間接的影響
- **推定価値**: 全体リテンション+2% = 年間約80万ドルの収益

## 工数評価

### エンジニアリング工数
- **フロントエンド**: 3週間（エンジニア2名）
  - デザインシステム更新（カラートークン、テーマプロバイダー）
  - コンポーネント更新（約150コンポーネント）
  - ブラウザーとデバイス間でのテスト
- **バックエンド**: 1週間（エンジニア1名）
  - ユーザー設定保存とAPI
  - デフォルトテーマロジック
- **総工数**: 約7エンジニア週

### デザイン工数
- ダークテーマの設計と検証に2週間
- すべての画面とコンポーネントの監査
- コントラスト比のアクセシビリティテスト

### 依存関係
- まずデザインシステム更新が必要（Q2に既に計画済み）
- モバイルアプリにはReact Nativeテーマプロバイダー更新が必要
- メールテンプレートはライトモードのまま（現在の範囲外）

## 検討した代替案

### オプション1: フルダークモード（推奨）
- **長所**: ユーザーニーズに対応; 業界標準; 将来性
- **短所**: 最初により多くの実装作業
- **工数**: 7エンジニア週

### オプション2: 自動ダークモードのみ（システム設定に従う）
- **長所**: よりシンプル（ユーザー設定保存なし）; それでもユーザーを助ける
- **短所**: ユーザーにコントロールを与えない; ユーザー設定に合わない可能性
- **工数**: 5エンジニア週

### オプション3: プレミアム機能（有料ユーザー向けダークモード）
- **長所**: 機能アップグレードからの潜在的収益
- **短所**: ユーザーの反発（必要最低条件として期待される）; 採用を制限
- **工数**: 7エンジニア週 + ペイウォールロジック

## 優先順位スコア

RICEフレームワークを使用：
- **リーチ**: 75万ユーザー = 750
- **影響**: 8/10（対象セグメントに高い） = 0.8
- **確信度**: 85% = 0.85
- **工数**: 7週間 = 7

**RICEスコア**: (750 × 0.8 × 0.85) / 7 = **73.2**

比較：
- 最近の機能A: RICE = 45
- 最近の機能B: RICE = 92
- 平均機能RICE: 55

## リスク

1. **スコープクリープ**: 色についての細かい議論が起こりやすい; 明確なデザイン権限が必要
   - *軽減策*: 早期にデザインを確定; フィードバックサイクルを時間制限
2. **アクセシビリティ**: 悪いコントラスト選択がアクセシビリティを損なう可能性
   - *軽減策*: WCAG AAテスト; ローンチ前のアクセシビリティ監査
3. **保守負担**: 今後すべてを両モードでテストする必要
   - *軽減策*: 自動視覚回帰テスト; CIチェック
4. **不完全なカバレッジ**: 一部がテーマを尊重しない場合にユーザーが気づく
   - *軽減策*: 包括的コンポーネント監査; 段階的展開

## 戦略的整合性

**プロダクト戦略**: ✅ 整合 - パワーユーザー（戦略セグメント）のコアユーザー体験を向上
**技術戦略**: ✅ 整合 - デザインシステムとコンポーネントアーキテクチャを近代化
**ビジネス目標**: ✅ 整合 - リテンション目標と競合ポジショニングをサポート

## 推奨事項

**✅ オプション1（フルダークモード）で進める**

**理由**:
- 大規模ユーザーセグメント（ベースの45%）への高い影響
- 強いユーザー需要と競合圧力
- 価値に対して工数が妥当
- RICEスコアが閾値（>50）を上回る
- プロダクト、技術、ビジネス戦略に整合

**推奨タイムライン**:
- 2025年Q2: デザインとデザインシステム更新
- 2025年Q3: 実装とテスト
- 2025年Q4: マーケティングプッシュでローンチ

**次のステップ**:
1. ステークホルダー承認を得る
2. Q2ロードマップに追加
3. デザイン作業を開始
4. エンジニアリングスプリント配分を計画

---
*分析者*: Jane Doe (PM)
*レビュー者*: Design、Engineering、Data
*日付*: 2025-11-19
```

## Common PM artifacts

### PRD (Product Requirements Document)
Comprehensive specification of what to build and why. Include problem statement, goals, user stories, requirements, technical considerations, risks, and launch plan.

### Feature Brief
Lighter-weight than PRD; quick summary of a feature idea with key details. Use for early-stage exploration before committing to full PRD.

### User Research Synthesis
Summary of user research findings (interviews, surveys, usability tests) with patterns, insights, and recommendations.

### Roadmap
Strategic plan of what to build over time. Organize by themes and time horizons; focus on outcomes not just outputs.

### Decision Document
Record of important product decisions, the options considered, the decision made, and the reasoning. Critical for institutional memory.

### Launch Plan
Detailed plan for rolling out a feature including phases, feature flags, metrics, monitoring, and rollback procedures.

### Competitive Analysis
Comparison of competitors' features, approaches, and positioning. Inform product strategy and feature prioritization.

### One-Pager
Executive summary of a product initiative. Use to communicate to leadership and get alignment.

## Best practices for AI-assisted PM work

### When using AI to write PRDs
- Provide comprehensive context about the product, users, and technical constraints.
- Review and edit generated content carefully; AI may miss nuances or make wrong assumptions.
- Use AI for structure and first drafts; refine with human judgment and stakeholder input.
- Validate technical details with engineering; don't assume AI knows your architecture.

### When using AI for feature analysis
- Provide quantitative data when possible (usage numbers, customer feedback counts).
- Use structured frameworks (RICE, ICE) to make analysis consistent and defensible.
- Don't let AI make the final decision; use it to organize thinking and surface considerations.
- Supplement AI analysis with qualitative stakeholder input and strategic context.

### When using AI for research synthesis
- Provide full transcripts or detailed notes for best results.
- Ask AI to identify patterns but validate with your own reading of the data.
- Use AI to extract quotes and organize themes; add your own interpretation and implications.
- Don't let AI over-summarize; sometimes important details are in the nuances.

## Safety and escalation

- **Strategic decisions**: AI should inform, not make, key product decisions. Involve human PMs and stakeholders.
- **User data**: Don't feed PII or sensitive user data to AI without proper data handling procedures.
- **Technical feasibility**: Always validate technical assumptions and effort estimates with engineering.
- **Competitive intelligence**: Be cautious about including confidential competitive info in prompts.
- **Tone and voice**: Review and adjust tone for your audience; AI may be too formal or informal.

## Integration with other skills

This skill can be combined with:

- **Data querying**: To analyze product metrics and user behavior data.
- **AI data analyst**: To perform deeper quantitative analysis for feature decisions.
- **Frontend UI integration**: To implement features designed in PRDs.
- **Internal tools**: To build PM tools like feature flag dashboards or metrics viewers.