product-discovery - SKILL.md Agent Skill

name: product-discovery description: > プロダクトの基盤情報（課題仮説・ソリューション・市場スコープ・原体験・ビジネスモデル・競合・差別化）をユーザーとの対話で掘り下げ、構造化されたドキュメント（product-context.md）として整理するスキル。「自分のプロダクトって結局何なの？」を一緒に整理する壁打ち相手として機能する。ペルソナ作成、LP設計、機能優先順位、マーケティング戦略など、プロダクトの方向性に関わるあらゆる意思決定の「前提情報」を1ファイルにまとめる。コードベースがあれば自動で読み取れる部分は埋め、残りをユーザーにヒアリングする。 Use when: 「プロダクトを整理したい」「ターゲット整理」「コンテキスト作成」「ペルソナの前に」「誰向けのプロダクトか整理」「プロダクト情報まとめ」「product context」「プロダクト定義」「プロダクトの前提」「product discovery」「誰向け」と言われた時。新しいプロジェクトの立ち上げ時や、方向性を見直したい時にも使う。ペルソナ作成スキルを使う前に、まずこのスキルでプロダクトの前提を整理すべき。 Triggers: "product discovery", "product context", "プロダクト整理", "ターゲット整理", "コンテキスト作成", "プロダクト定義", "プロダクトの前提", "ペルソナの前に", "誰向け", "プロダクト情報まとめ", "プロダクトって何", "何を作ってるか整理", "どんな需要があるか"

Product Discovery Skill

プロダクトの方向性を決める 8つの基盤情報 をヒアリング + コードベース分析で整理し、 product-context.md として出力する。

このドキュメントは、ペルソナ作成・LP設計・機能優先順位決定など、あらゆるプロダクト意思決定の入力として使える。

なぜこのスキルが必要か

ペルソナ作成やマーケティング戦略を始める前に、以下が曖昧だと手戻りが発生する：

「誰向けのプロダクトか」が決まっていない → セグメント設計が空中戦になる
「競合との違い」が言語化されていない → 差別化の訴求ができない
「なぜ自分が作るか」が整理されていない → ストーリーが弱くなる

8つの基盤情報

必須（これがないと下流の意思決定ができない）

#	項目	問い	情報源
1	課題仮説	世の中のどんな問題を解決する？	ユーザーに聞く
2	ソリューション方向性	どうやって解決する？	コード + ユーザー
3	市場スコープ	どの地域・言語・業界を狙う？	ユーザーに聞く
4	原体験	なぜ自分がこれを作るのか？	ユーザーに聞く

あると精度が上がる

#	項目	問い	情報源
5	ビジネスモデル仮説	どう稼ぐ？	コード + ユーザー
6	競合・代替手段	ユーザーは今どうしてる？不満は？	ユーザーに聞く
7	プロダクトの現状	構想段階？MVP？成長期？	コード + ユーザー
8	差別化ポイント仮説	競合と何が違う？	ユーザーに聞く

ワークフロー

Phase 1: コードベース分析（該当する場合）

コードベースが存在する場合、以下のファイルを読んで自動で情報を抽出する。コードがない場合（構想段階）は Phase 2 に進む。

読むべきファイル（優先順）:

README.md → プロダクト概要、機能リスト
package.json / Cargo.toml / pyproject.toml → 名前、説明、依存関係
CLAUDE.md → 開発方針、アーキテクチャ
ランディングページのコード（app/page.tsx, index.html 等）→ 訴求メッセージ
環境設定ファイル → 使用サービス（決済、認証、AI等）からビジネスモデルの手がかり
DB スキーマ → データ構造からプロダクトの中核機能を推測

抽出する情報:

プロダクト名
コア機能の一覧
技術スタック
外部サービス連携（決済、AI API 等）
既存のユーザー向けテキスト（LP コピー、説明文）

抽出結果を「分かったこと」「推測（要確認）」「分からないこと」に分類する。

Phase 2: ユーザーヒアリング

AskUserQuestion を使って、Phase 1 で埋められなかった項目をヒアリングする。

ヒアリングの原則:

コードから分かったことは確認として提示する（「〇〇という理解で合ってますか？」）
一度に聞く質問は 最大4つ まで（AskUserQuestion の制限）
必須4項目を先に聞き、あると良い4項目は後から聞く
選択肢を用意できる質問は選択肢を出す。自由回答が必要なものは Other で対応
ユーザーの回答が曖昧な場合、掘り下げの質問を追加で行う

ヒアリング順序:

Round 1（必須項目）:

質問1: 課題仮説

このプロダクトは、どんな課題を解決しますか？（コードから推測した場合）「〇〇という課題を解決するプロダクト」という理解で合ってますか？

質問2: ソリューション方向性

どうやってその課題を解決しますか？他のツールとの違いは？（コードから推測した場合）機能一覧を提示して確認

質問3: 市場スコープ

メインのターゲット市場はどこですか？選択肢例: 日本市場 / 英語圏 / グローバル / 特定の業界

質問4: 原体験

なぜ自分がこのプロダクトを作ろうと思いましたか？きっかけや原体験は？

Round 2（あると良い項目）:

質問5: ビジネスモデル仮説

どうやって収益化する予定ですか？選択肢例: SaaS 月額 / フリーミアム / 買い切り / OSS + Open Core / 未定

質問6: 競合・代替手段

ユーザーは今どうやってこの課題を解決していますか？その方法の不満点は？

質問7: プロダクトの現状

今のプロダクトの状態は？選択肢例: アイデア段階 / プロトタイプ / MVP / リリース済み / 成長期

質問8: 差別化ポイント仮説

競合や代替手段と比べて、一番の違いは何だと思いますか？（まだ仮説でOK）

Phase 3: 整理と出力

ヒアリング結果を product-context.md として出力する。

出力先の決定:

リポジトリがある場合: {リポジトリルート}/docs/product-context.md
リポジトリがない場合: ユーザーに保存先を確認

出力時のルール:

必須4項目は必ず埋める。ユーザーが「分からない」と言った場合は [未定義 - 要検討] と明記
あると良い4項目は、情報があれば埋める。なければセクション自体を「未整理」と明記
コードから推測した情報は [コードから推測] タグをつける
ユーザーの言葉をできるだけそのまま使う（言い換えすぎない）
事実と仮説を区別する

product-context.md テンプレート

# Product Context: {プロダクト名}

> 作成日: {YYYY-MM-DD}
> 最終更新: {YYYY-MM-DD}

## 1. 課題仮説

**解決する課題:**
{ユーザーの回答}

**この課題を持つ人:**
{誰がこの課題を持っているか}

**課題の深刻度:**
{あれば: どれくらい困っているか、頻度、代替手段の有無}

## 2. ソリューション方向性

**プロダクト概要:**
{何をするプロダクトか、1-2文で}

**コア機能:**
- {機能1}
- {機能2}
- {機能3}

**技術スタック:** {該当する場合}

## 3. 市場スコープ

**地域:** {日本 / 英語圏 / グローバル / その他}
**言語:** {日本語 / 英語 / 多言語}
**業界:** {特定業界 / 汎用}
**優先順位:** {Phase 1 でどこを狙うか}

## 4. 原体験

**なぜ作るのか:**
{ユーザーの原体験、きっかけ}

**自分自身の課題体験:**
{自分がユーザーとして感じた不満や課題}

## 5. ビジネスモデル仮説

**収益モデル:** {SaaS / フリーミアム / OSS + Open Core / 買い切り / 未定}
**価格帯:** {想定があれば}
**ターゲット顧客:** {個人 / チーム / 企業}

## 6. 競合・代替手段

**ユーザーの現在の解決方法:**
- {代替手段1}: {不満点}
- {代替手段2}: {不満点}

**直接競合:**
- {あれば}

## 7. プロダクトの現状

**ステージ:** {アイデア / プロトタイプ / MVP / リリース済み / 成長期}
**既存ユーザー:** {いればその規模・特徴}
**利用データ:** {あれば}

## 8. 差別化ポイント仮説

**一番の違い:**
{競合・代替手段との最大の差別化要因}

**なぜ代替手段では不十分か:**
{ユーザー視点での不満}

---

## メモ・補足

{ヒアリング中に出た補足情報、今後検討すべき点}

既存のコンテキストファイルがある場合

docs/product-context.md や .claude/persona-creation/*/context.md が既に存在する場合、それを読み込んで不足項目のみヒアリングする。全項目を最初から聞き直さない。

他のスキルとの連携

このスキルで作成した product-context.md は以下のスキルの入力として使える:

persona-creation: ペルソナ作成の前提情報として
user-journey: ジャーニーマップのプロダクトコンテキストとして
aso-optimize: ASO 最適化のプロダクト理解として
feature-discussion: 機能検討のプロダクト方針として

各スキルを使う際、「product-context.md を読んでから始めて」と指示すると、前提情報が揃った状態でスタートできる。