Product Discovery

コアプリンシパル

• 継続的ディスカバリー — エピソード的な調査ではなく、毎週のユーザー対話
• アウトカム駆動 — 構築する解決策ではなく、達成すべきアウトカムから始める
• 仮説テスト — リソースを投入する前にリスキーな仮説を検証する
• 共創 — ユーザーのためだけでなく、ユーザーとともに構築する
• データ駆動 — 直感とステークホルダー意見よりも証拠を使用する
• 問題優先 — ソリューションを構想する前に問題空間を深く理解する

---

硬いルール（必須）

これらのルールは必須です。これらに違反するとスキルが正しく機能していません。

ソリューションファースト思考は禁止

決してソリューションから始めてはいけません。常に問題とアウトカムから定義します。

❌ 禁止:
"商品ページに検索バーを追加すべきだ"
"AI推奨を追加しよう"
"ユーザーはモバイルアプリが必要だ"

✅ 必須:
"問題: ユーザーが商品を見つけられない（カタログで40%の離脱率）
アウトカム: 離脱率を20%に削減する
可能なソリューション:
1. フィルター付き検索バー
2. AI搭載の推奨
3. より良いカテゴリナビゲーション
4. ビジュアル商品ブラウジング"

エビデンスベースの意思決定

実際のユーザー調査からのエビデンスなしにユーザーニーズを想定してはいけません。

❌ 禁止:
- "ユーザーはおそらくXが欲しいだろう"（データなしの仮説）
- "競合他社がXを持っているから、私たちも必要だ"（検証なしの模倣）
- "CEOはXを構築すべきだと考えている"（エビデンスなしのHiPPO）
- "ユーザーが明らかにXを必要としている"（検証なしの直感）

✅ 必須:
- "インタビューした8人中5人がXを痛点として言及した"
- "分析によると60%のユーザーステップ3で中止している"
- "プロトタイプテスト: 10人中7人がタスクを正常に完了した"
- "調査（n=500）: 45%が機能を「必須」と評価した"

最小インタビュー閾値

セグメントごとに5件未満のユーザーインタビューで問題を検証してはいけません。

❌ 禁止:
- "2人のユーザーに話を聞いて、彼らはアイデアを気に入った"
- "1人の顧客がこの機能をリクエストした"
- "営業との簡単な会話に基づいて..."

✅ 必須:
| セグメント | インタビュー数 | 主な発見 |
|---------|------------|-------------|
| パワーユーザー | 6 | 6人中5人がXで苦労している |
| 新規ユーザー | 5 | 5人中4人がオンボーディングで離脱 |
| 解約ユーザー | 5 | 5人中3人が機能Yの欠落を理由に挙げた |

セグメントごとの最小値: 5インタビュー
より多くのインタビューで信頼度が向上

反証可能な仮説

すべての仮説は、明確な成功基準でテスト可能で反証可能でなければなりません。

❌ 禁止:
- "ユーザーは新しいデザインが好きだろう"（反証不可能）
- "これはエンゲージメントを改善するだろう"（成功基準なし）
- "機能は役立つだろう"（曖昧）

✅ 必須:
| 仮説 | テスト | 成功基準 | 結果 |
|------------|------|------------------|--------|
| ユーザーが新しいフローでオンボーディングを完了する | 10人のユーザーでプロトタイプテスト | 70%以上の完了 | 保留中 |
| ユーザーがビジュアル検索を好む | A/Bテスト | 10%以上のコンバージョン上昇 | 保留中 |
| 価格設定ポイントが受け入れられる | ランディングページテスト | 3%以上のコンバージョン | 保留中 |

---

クイックリファレンス

いつ何を使うか

シナリオ	フレームワーク/ツール	アウトプット
製品アイデアを検証する	Product Opportunity Assessment	Go/no-go判断
市場機会をサイジングする	TAM/SAM/SOM	市場規模推定
ユーザーニーズを理解する	User Research（インタビュー、調査）	ユーザーインサイト、痛点
競争を分析する	Competitive Analysis	競争環境マップ
ユーザー動機を発見する	Jobs-to-be-Done（JTBD）	ジョブストーリー、アウトカム
機能を優先順位付けする	カノモデル	機能カテゴリ分け
バリュープロポジションを定義する	Value Proposition Canvas	バリュープロポジション説明
製品コンセプトをテストする	Lean Startup / MVP	検証された学習
機会をマップする	Opportunity Solution Tree	優先順位付けられた機会

---

継続的ディスカバリー習慣

プロダクトトリオ

ディスカバリーは3つの役割が毎週一緒に行います:

Product Manager → アウトカムを定義し、ロードマップを所有
Designer        → ソリューションを探索し、ユーザビリティをテスト
Engineer        → 実行可能性を評価し、技術的ソリューションを提案

毎週のアクティビティ

## 1. カスタマーインタビュー（毎週）
- 最低週3～5件のインタビューをスケジュール
- 現在のユーザー、解約ユーザー、見込み客の混在
- ソリューションのピッチではなく、問題を理解することに焦点
- インタビューを記録し、チームと共有

## 2. 仮説テスト（毎週）
- ソリューションについての最もリスキーな仮説を特定
- クイックテストを設計（プロトタイプ、ランディングページ、フェイクドア）
- 実際のユーザーでテストを実施
- 成功基準に対して結果を測定

## 3. 機会マッピング（継続的）
- Opportunity Solution Tree を構築
- 顧客ニーズを潜在的なソリューションにマップ
- インパクトと実行可能性に基づいて優先順位付け
- 学習に応じて更新

ディスカバリー対デリバリー

ディスカバリー（何を構築するか）      デリバリー（どのように構築するか）
├─ カスタマーインタビュー             ├─ スプリント計画
├─ プロトタイプテスト                 ├─ 開発
├─ 仮説検証                           ├─ QAテスト
├─ 市場調査                           ├─ デプロイ
└─ 機会評価                           └─ ローンチ後のモニタリング

主な違い: ディスカバリーは構築を約束する前にリスクを低減

---

Product Opportunity Assessment

Marty Cagan の10つの質問

製品イニシアチブを開始する前に、これらの質問に答えてください:

## 1. 問題定義
**どの問題を解決していますか？**
- 具体的で測定可能である
- 実際の問題であることを検証する（想定ではなく）

## 2. ターゲット市場
**誰のために この問題を解決していますか？**
- 特定のユーザーセグメントを定義
- アドレス可能な市場をサイジング（TAM/SAM/SOM）

## 3. 機会規模
**機会の大きさはどのくらいですか？**
- 収益ポテンシャル
- ユーザー成長ポテンシャル
- 戦略的価値

## 4. 成功メトリクス
**成功をどのように測定しますか？**
- 先行指標（使用状況、エンゲージメント）
- 遅行指標（収益、リテンション）
- 目標を事前に定義

## 5. 代替ソリューション
**今日、どのような代替案が存在していますか？**
- 直接競合
- 間接的ソリューション
- 現在のユーザーの回避方法

## 6. 私たちのアドバンテージ
**なぜ私たちがこれを解決するのに最適なのですか？**
- ユニークな能力
- 市場ポジション
- 技術的アドバンテージ

## 7. 戦略的適合
**なぜ今？なぜ私たちなのか？**
- 市場タイミング
- 戦略的アライメント
- リソース可用性

## 8. 依存性
**成功するために何が必要ですか？**
- 技術的依存性
- パートナーシップ要件
- 規制上の考慮

## 9. リスク
**何が間違っていく可能性がありますか？**
- 市場リスク（誰かがそれを望むか？）
- 実行リスク（構築できるか？）
- マネタイゼーションリスク（支払うか？）

## 10. 遅延のコスト
**これを構築しなかったら何が起こりますか？**
- 競争上の不利
- 失われた収益
- 市場機会のウィンドウ

Value vs Effort フレームワーク

機会のクイック優先順位付け:

High Value, Low Effort  → 最初にやる（クイックウィン）
High Value, High Effort → 戦略的に計画する（ビッグベット）
Low Value, Low Effort   → 後からやる（ギャップを埋める）
Low Value, High Effort  → やらない（金銭の無駄）

---

ディスカバリーメソッド

いつ何を使うか

## ジェネラティブリサーチ（どのような問題が存在するか？）
使用時期: 新製品領域を開始時、未知の領域を探索
メソッド:
- エスノグラフィックフィールドスタディ
- コンテキスト的インクワイアリー
- ダイアリー調査
- オープンエンド型インタビュー

## エバリュアティブリサーチ（私たちのソリューションは機能するか？）
使用時期: 特定のソリューション、デザインをテスト
メソッド:
- ユーザビリティテスト
- プロトタイプテスト
- A/Bテスト
- コンセプトテスト

## 定量的リサーチ（どのくらい？何個？）
使用時期: 統計的検証が必要、インパクト測定
メソッド:
- 調査
- 分析分析
- A/B実験
- 市場サイジング

## 定性的リサーチ（なぜ？どのように？）
使用時期: 動機を理解、インサイトを発見
メソッド:
- ユーザーインタビュー
- フォーカスグループ
- カスタマーアドバイザリーボード
- ユーザー観察

インタビューベストプラクティス

## 準備
- 研究目標と仮説を定義
- インタビューガイドを作成（ただし柔軟に）
- 適切な参加者をリクルート（セグメントごと6～8人）
- 45～60分のセッションをスケジュール

## インタビュー中
✓ オープンエンド型の質問をする（「～について話してください」）
✓ 「なぜ？」で5回フォローアップして根本原因に到達
✓ 話すより聞く（80/20ルール）
✓ 将来の仮説ではなく、過去の行動について聞く
✓ 回避方法と痛点を探す
✓ 記録してメモを取る

✗ 誘導的な質問をしない
✗ あなたのソリューションをピッチしない
✗ 「Xを使いますか？」と聞かない（人は嘘をつく）
✗ インタビュー中にマルチタスクをしない

## 質問例
- 「最後に[タスク]をやったときのことを説明してください」
- 「[現在のソリューション]で最もイライラすることは何ですか？」
- 「今日、この問題をどのように解決していますか？」
- 「[タスク]を簡単にするものは何ですか？」
- 「それについて詳しく教えてください...」

調査ベストプラクティス

## いつ調査するか
✓ 定性的調査からの発見を検証
✓ 規模での満足度またはセンチメントを測定
✓ 機能に優先順位を付ける（カノ調査）
✓ ユーザーを行動/ニーズでセグメント化

## 調査デザイン
- 短く保つ（10分以下で完了）
- モバイルで1画面1問
- 質問タイプを混ぜる（複数選択肢、スケール、オープンエンド）
- 誘導的または偏った質問を避ける
- 送信前に5人で調査をテスト

## 質問タイプ
- 複数選択肢 → セグメンテーション、カテゴリ分け
- リッカートスケール（1～5） → 満足度、重要度
- オープンエンド → 定性的インサイト
- ランキング → 優先順位付け
- NPS（0～10） → ロイヤルティ測定

## 配布
- アプリ内調査（高回答率、エンゲージド ユーザーに偏り）
- メール調査（より広いリーチ、低回答率）
- 思慮深い回答にインセンティブを与える（$10ギフトカード、早期アクセス）
- 興味深い回答をした人にフォローアップインタビュー

---

2025年のProduct Discovery トレンド

AI搭載リサーチ

## ディスカバリー向けAIツール
- **インサイト合成** — AIがインタビュートランスクリプトを分析し、パターンを特定
- **合成ペルソナ** — 高速テスト用のAI生成ユーザープロキシ
- **市場インテリジェンス** — 競合の動きと価格変更を追跡するAI
- **調査分析** — 自動感情分析、テーマ抽出
- **トレンド検出** — 新たな市場トレンドを早期に特定するAI

## 例
- Crayon → 競争インテリジェンスの自動化
- Glimpse → Webデータからのトレンド検出
- Delve AI → 自動ペルソナ作成
- Attest → AI搭載調査インサイト
- Quantilope → 機械学習研究自動化

## ベストプラクティス
✓ AIを使用して調査を拡張し、人間のインサイトを置き換えない
✓ AIの発見を実際のユーザー対話で検証
✓ AI分析と定性的深さを組み合わせる
✗ 合成ユーザーのみに依存しない
✗ 実際の顧客との対話をスキップしない

規模でのContinuous Discovery

## 現代的アプローチ
- ディスカバリーはフェーズではなく、すべてのスプリントに組み込まれている
- 毎週のユーザータッチポイント（インタビュー、テスト、フィードバック）
- 高速実験（数十のテスト実施中）
- エビデンスに基づく高速ピボット（数ヶ月ではなく数日）

## チーム構成
- Product trios は各領域のディスカバリーを所有
- 集中研究チーム（ツール、メソッド）が支援
- カスタマーサクセスがフィードバックループを共有
- データアナリストが定量的インサイトを提供

## ケイデンス
- 毎週: カスタマーインタビュー、プロトタイプテスト
- 隔週: 機会レビュー、仮説検証
- 毎月: 市場分析、競争レビュー
- 四半期ごと: 戦略的ディスカバリー（新市場、ビッグベット）

---

Opportunity Solution Tree

それは何か

アウトカムからソリューションへのパスをマップするビジュアルフレームワーク:

        OUTCOME（ビジネスゴール）
             |
    ┌────────┴────────┐
    │                 │
機会1          機会2
    │                 │
    ├─ ソリューションA  ├─ ソリューションC
    ├─ ソリューションB  └─ ソリューションD
    └─ ソリューションC

これを構築する方法

## ステップ1: アウトカムを定義
測定可能なビジネスアウトカムから始まる
例: 「Day 30 リテンションを20%から30%に増加させる」

## ステップ2: 機会をマップ
調査を通じて顧客ニーズ/痛点を発見
例: 「ユーザーはコア機能を理解していない」

## ステップ3: ソリューションを生成
各機会について、複数のソリューションをブレインストーム
例:
- より良いオンボーディングチュートリアル
- アプリ内ツールチップ
- インタラクティブな製品ツアー

## ステップ4: 仮説をテスト
各ソリューションについて、最もリスキーな仮説を特定してテスト
例: 「ユーザーが5ステップのチュートリアルを完了する」
テスト: シンプルなプロトタイプを構築し、10人のユーザーでテスト

## ステップ5: ソリューションを比較
エビデンスを使用して最適なパスを選択
検証されたテストを構築し、失敗したものを破棄

メリット

✓ アウトカムへの複数のパスを可視化
✓ 最初のソリューションへのジャンプを防止
✓ 絞る前に広くを探索することを促進
✓ なぜ決定が下されたかを記録
✓ チームをプライオリティに合わせて保つ

---

ディスカバリーとデリバリーを統合

ディスカバリーカンバン

## ディスカバリーボードのカラム

┌─────────────┬──────────────┬──────────────┬─────────────┐
│ 機会         │ 仮説         │ 実験         │ 検証済み    │
│             │              │              │             │
│ 発見した    │ テストする   │ 実行中の    │ 構築する    │
│ 顧客ニーズ  │ リスキーな   │ テスト      │ 準備ができた│
│             │ 仮説         │              │ ソリューション│
└─────────────┴──────────────┴──────────────┴─────────────┘

## フロー
1. 調査から機会がフロー
2. ソリューションは テストする仮説を生成
3. 実験は仮説を検証/反証
4. 検証されたソリューションがデリバリーバックログに入る

Definition of Ready

ディスカバリーからデリバリーに移動する前に:

## ディスカバリーチェックリスト
- [ ] 顧客問題が検証済み（5件以上のインタビュー）
- [ ] ソリューションがプロトタイプでテスト済み（10人以上のユーザー）
- [ ] 成功メトリクスが定義され測定可能
- [ ] 技術的実行可能性がエンジニアリングで確認済み
- [ ] ビジネスケースが承認済み（収益/リテンション影響）
- [ ] デザインモックが完成して テスト済み
- [ ] 未解決の質問が解決または明示的に認識
- [ ] ストーリーが配布可能なインクリメントに分割

---

一般的なアンチパターン

してはいけないこと

## ✗ ソリューションファーストディスカバリー
「Xを構築すべき」から始まり、それをサポートするエビデンスを見つける
→ 代わりに: アウトカムと問題から始まり、複数のソリューションを探索

## ✗ エピソディックリサーチ
ディスカバリーをフェーズとして行い、開発開始時に停止
→ 代わりに: 製品ライフサイクル全体を通じた継続的な毎週のディスカバリー

## ✗ 確認バイアス
あなたのアイデアを検証するだけのユーザーと話す
→ 代わりに: 不確認エビデンスを求め、解約したユーザーと話す

## ✗ 偽の検証
「これを使いますか？」と聞いて答えを信頼する
→ 代わりに: リアルなプロトタイプでテストし、実際の行動を測定

## ✗ 分析麻痺
終わりなき調査、決して配送なし
→ 代わりに: 前もって「十分な」エビデンスが何かを定義

## ✗ すべての人のために構築する
すべてのユーザーを一度に解決しようとする
→ 代わりに: 特定のセグメントに焦点を当てて、それをネイル、次に展開

## ✗ 弱いシグナルを無視する
早期の否定的なフィードバックを「ただの少数のユーザー」として却下
→ 代わりに: 苦情を早期警告として扱い、調査する

---

参照

• reference/market-research.md — TAM/SAM/SOM、Porter の Five Forces
• reference/user-research.md — インタビューガイド、調査メソッド、エスノグラフィー
• reference/competitive-analysis.md — 競争フレームワークと分析
• reference/opportunity-frameworks.md — JTBD、カノ、Value Proposition Canvas
• templates/discovery-template.md — Product Discovery ドキュメントテンプレート