product-discovery

プロダクトディスカバリー

お客様が本当に求めているプロダクトを作りましょう。シリコンバレーで実証された Marty Cagan のフレームワークを活用し、価値があり、使いやすく、実現可能で、事業として成立するソリューションを見つけます。

このスキルを使う場面

• 新規プロダクト開発で、何を作るべきかを検証するとき
• 機能の優先順位付けで、実際の課題を解決していることを確認するとき
• 現在の方向性がうまくいかないときのピボットの判断
• 解決すべき課題についてのチームの足並みをそろえるとき
• 開発リソースを投入する前のリスク低減
• プロダクトマーケットフィットを維持するための継続的なディスカバリー

方法論の基盤

観点	詳細
出典	Marty Cagan 著『Inspired』（2008年、2018年）および『Empowered』（2020年）に着想を得ています
基本原則	「ソリューションではなく、課題に惚れ込みましょう。優れたプロダクトチームは、お客様の要望を聞くだけでなく、お客様に必要なものを見つけ出します。」
重要な理由	多くのプロダクトは、作り方が悪いからではなく、間違った課題を解決するために失敗します。ディスカバリーによって、正しく作る前に、作るべきものを見極められます。

Claude が行うことと、あなたが決めること

Claude が行うこと	あなたが決めること
コンテンツのフレームワークを構成する	最終的なメッセージ
説得のテクニックを提案する	ブランドのトーン
下書きのバリエーションを作成する	バージョンの選択
最適化の機会を特定する	公開のタイミング
競合他社のアプローチを分析する	戦略の方向性

このスキルでできること

1. 4つのリスクを整理する - 価値、ユーザビリティ、実現可能性、事業性
2. ディスカバリーとデリバリーの違いを明確にする - 考え方もプロセスも異なります
3. 機会の評価方法を学ぶ - どの課題を解決するべきか
4. プロトタイピングのスキルを身につける - 作る前にアイデアをテストする
5. 顧客リサーチをガイドする - お客様が必要とするもの（望むものではなく）を学ぶ
6. 継続的なディスカバリーを構成する - 一度きりのリサーチではなく、継続的に学ぶ

使用方法

プロダクトの機会を評価する

I'm considering building [feature/product].
Apply product discovery principles to assess this opportunity.
Context: [target customer, current state, hypothesis]

開発前にリスクを低減する

We're about to build [feature].
Help me identify the key risks and design tests to address them.

継続的なディスカバリーを始める

I want to implement continuous discovery for my product team.
Help me design a weekly discovery rhythm.

手順

ステップ 1：4つのリスクを理解する

## The Four Product Risks

Every product idea has four risks to address BEFORE building:

### 1. Value Risk
"Will customers buy/use this?"

**Questions:**
- Does this solve a real problem?
- Is the problem painful enough to pay/switch for?
- Will users actually adopt this?

**Tests:**
- Customer interviews
- Demand testing
- Fake door tests
- Concierge MVP

### 2. Usability Risk
"Can customers figure out how to use it?"

**Questions:**
- Is it intuitive?
- Can users accomplish their goals?
- What's the learning curve?

**Tests:**
- Prototype testing
- Usability studies
- Wizard of Oz tests
- A/B tests on UX

### 3. Feasibility Risk
"Can we build this?"

**Questions:**
- Do we have the technology?
- Can we do it in reasonable time?
- What are the technical dependencies?

**Tests:**
- Technical spike
- Proof of concept
- Architecture review
- Build vs. buy analysis

### 4. Viability Risk
"Should we build this?"

**Questions:**
- Does it fit our strategy?
- Can we support/maintain it?
- Is it legal/compliant?
- Does the business model work?

**Tests:**
- Business case
- Stakeholder review
- Compliance review
- Financial modeling

---

ステップ 2：ディスカバリーとデリバリーの違い

## Two Tracks: Discovery and Delivery

### Discovery (Figure out WHAT to build)

**Mindset:**
- Embrace uncertainty
- Test assumptions
- Fail fast and cheap
- Learn over deliver

**Activities:**
- Customer interviews
- Prototyping
- Experiments
- Opportunity assessment

**Outcome:**
- Validated problems
- Tested solutions
- Confidence to build
- Clear success metrics

### Delivery (BUILD it right)

**Mindset:**
- Reduce uncertainty
- Execute efficiently
- Ship quality
- Hit timelines

**Activities:**
- Engineering
- QA
- Launch prep
- Documentation

**Outcome:**
- Working software
- Happy customers
- Business impact
- Technical quality

### The Critical Point

Most teams skip discovery and jump to delivery.

**Result:**
- Build features no one wants
- Waste engineering resources
- Miss market opportunities
- Frustrated team, frustrated customers

**The ratio:**
Spend 10-20% of time on discovery to avoid wasting
80-90% of delivery time on wrong things.

---

ステップ 3：機会の評価

## Assessing Product Opportunities

### The Opportunity Assessment Framework

Before committing to solve a problem, answer:

**1. Is this problem worth solving?**
| Factor | Questions |
|--------|-----------|
| **Frequency** | How often does this problem occur? |
| **Intensity** | How painful is it when it happens? |
| **Willingness** | Will people pay/switch to solve it? |
| **Reach** | How many customers have this problem? |

**Scoring:**
- High frequency + High intensity = Strong opportunity
- Low frequency OR Low intensity = Weak opportunity

**2. Can we solve it effectively?**
| Factor | Questions |
|--------|-----------|
| **Capability** | Do we have the skills/tech? |
| **Fit** | Does it align with our strategy? |
| **Uniqueness** | Can we solve it better than alternatives? |
| **Sustainability** | Can we maintain competitive advantage? |

**3. Should we solve it now?**
| Factor | Questions |
|--------|-----------|
| **Urgency** | Is timing critical? |
| **Resources** | Do we have capacity? |
| **Dependencies** | What else needs to happen first? |
| **Opportunity cost** | What are we NOT doing instead? |

### Opportunity Score Card

機会：[名称]

課題の評価

• 発生頻度：[1-5]
• 深刻度：[1-5]
• 支払い／乗り換えの意思：[1-5]
• 市場規模：[1-5] 課題スコア：[平均]

ソリューションの評価

• 技術的な実現可能性：[1-5]
• 戦略との適合性：[1-5]
• 競争優位性：[1-5] ソリューションスコア：[平均]

タイミングの評価

• 緊急性：[1-5]
• リソースの確保状況：[1-5] タイミングスコア：[平均]

総合：[課題 × ソリューション × タイミング = X]

推奨事項：[進める／保留／見送る]

---

ステップ 4：ディスカバリーの手法

## Core Discovery Techniques

### 1. Customer Interviews

**Purpose:** Understand problems, not validate solutions

**Structure:**
1. Context: Understand their current situation
2. Problem: Explore the pain points
3. Impact: How does it affect them?
4. Current solutions: What do they do today?
5. Ideal state: What would "solved" look like?

**Key rules:**
- Ask about past behavior, not future intentions
- Don't pitch, just listen
- Follow the emotion
- Get specific stories

**Questions:**
- "Walk me through the last time this happened..."
- "What did you do? What happened next?"
- "Why was that a problem?"
- "What would have made it better?"

### 2. Prototyping

**Purpose:** Test solutions before building

**Types:**
| Type | Fidelity | Tests | Time |
|------|----------|-------|------|
| **Paper sketch** | Low | Concepts, flow | Hours |
| **Wireframe** | Low-Med | Structure, navigation | Days |
| **Clickable prototype** | Medium | Usability, flow | Days |
| **Wizard of Oz** | High | Full experience | Weeks |

**Principle:**
Use the lowest fidelity that tests your hypothesis.
Higher fidelity = More time = More risk of attachment.

### 3. Experiments

**Purpose:** Test assumptions with real behavior

**Types:**
- **Fake door:** Button for feature that doesn't exist
- **Smoke test:** Landing page before building
- **Concierge:** Manual delivery of automated value
- **A/B test:** Compare variations with real users

**Structure:**
1. Hypothesis: "We believe [X]"
2. Test: "We will test by [Y]"
3. Metric: "We will measure [Z]"
4. Success: "[Number] indicates we should proceed"

### 4. Opportunity Solution Trees

**Purpose:** Map problem space to solution space

**Structure:**

        [望ましい成果]
               |
┌──────────────┼──────────────┐
|              |              |

[機会 1] [機会 2] [機会 3] | | | ┌─┴─┐ ┌─┴─┐ ┌─┴─┐ | | | | | | [S1] [S2] [S1] [S2] [S1] [S2]

- Start with business outcome
- Break into opportunities (problems to solve)
- Brainstorm solutions for each opportunity
- Test solutions, not opportunities

---

ステップ 5：継続的なディスカバリー

## Weekly Discovery Rhythm

### The Cadence

**Monday: Prep**
- Review last week's learnings
- Prioritize this week's questions
- Schedule interviews/tests

**Tuesday-Thursday: Research**
- Customer interviews (2-3 per week minimum)
- Prototype testing
- Data analysis
- Experiment monitoring

**Friday: Synthesis**
- Consolidate learnings
- Update opportunity assessment
- Share with delivery team
- Plan next week

### The Habits

**1. Weekly customer touchpoint**
- Minimum: 2-3 customer conversations/week
- Mix: Prospects, users, churned customers

**2. Assumption tracking**
- List key assumptions
- Design tests for riskiest ones
- Document learnings

**3. Experiment backlog**
- Always have 2-3 experiments running
- Quick iterations over perfect tests

**4. Cross-functional involvement**
- Engineering in discovery
- Design in customer calls
- PM facilitates, doesn't dictate

### The Anti-Patterns

**Discovery theater:**
- Doing research but not changing decisions
- Fix: Tie discovery directly to roadmap decisions

**Big bang research:**
- Quarterly research sprints instead of continuous
- Fix: Small, frequent over large, infrequent

**Validation bias:**
- Only seeking confirmation
- Fix: Actively try to disprove hypotheses

---

例

例 1：新機能のディスカバリー

入力：

「プロジェクト管理ツールにカレンダー連携を追加しようと考えています。開発する前に、どう検証すればよいでしょうか？」

出力：

ディスカバリープラン：カレンダー連携

リスク評価

リスク	レベル	理由
価値	高	実際の課題を解決するかどうかが不明です
ユーザビリティ	中	カレンダーの UI は複雑です
実現可能性	低	Google、Outlook との連携は確立されています
事業性	低	プロダクト戦略に適合しています

**ディスカバリーで重点的に確認すること：**価値のリスク（最優先）、次にユーザビリティ

ディスカバリー活動

第 1 週：課題を理解する

顧客インタビュー（5～8 件）

対象：時間的制約のあるプロジェクトを管理している既存ユーザー

質問：

1. 「現在、チームの作業をどのようにスケジュールしているか、詳しく教えてください。」
2. 「納期に遅れが出ると、どうなりますか？ どのようにしてそれを知りますか？」
3. 「プロジェクト管理において、カレンダーはどのような役割を果たしていますか？」
4. 「プロジェクトとカレンダーの同期を保つうえで、何に不満を感じますか？」
5. 「カレンダーとプロジェクトの連携が取れていなかったために、何かを見落とした直近の事例を見せてください。」

確認するポイント：

• 実際に課題があるか？ その深刻さはどの程度か？
• 現在、どのような回避策を使っているか？
• 「あればよい」ものか、それとも「なくてはならない」ものか？

第 2 週：需要を評価する

偽の導線テスト

1. 設定に「カレンダー同期（近日公開）」ボタンを追加する
2. クリック時に「ご関心をお寄せいただきありがとうございます！ ウェイトリストにご登録ください。」と表示する
3. クリック率とウェイトリスト登録率を追跡する

成功基準：

• MAU の 5% 超がボタンをクリック＝強いシグナル
• 2～5%＝中程度のシグナル
• 2% 未満＝弱いシグナル

既存データの分析：

• サポートチケットで「カレンダー」に言及するユーザーは何人いるか？
• ユーザーは現在、どのようなインテグレーションに接続しているか？
• カレンダーツールを使っているユーザーは、エンゲージメントが高いか、それとも低いか？

第 3 週：ソリューションをテストする

プロトタイプテスト（第 1～2 週にシグナルが見られた場合）

以下を示す低忠実度プロトタイプを作成します。

1. カレンダー同期の設定フロー
2. 同期されたイベントの表示方法
3. 競合の解決方法

5 人のユーザーでテストします。

• 助けなしで設定できますか？
• ユーザーのメンタルモデルに合っていますか？
• 何がわかりにくいですか？

ウィザード・オブ・オズテスト

10 人のユーザーに対して：

1. カレンダーの項目を手作業でプロジェクトに同期する
2. 毎日、概要メールを送信する
3. 1 週間後にインタビューする：これは役に立ちましたか？

意思決定のフレームワーク

調査結果	判断
強い価値のシグナル＋使いやすいプロトタイプ	開発する
強い価値のシグナル＋ユーザビリティの問題	再設計して再テストする
弱い価値のシグナル	開発せず、アイデアを保留する
一部のユーザーにのみ価値がある	対象範囲やセグメント分けを検討する

スケジュール

• 第 1 週：インタビュー → 課題の理解
• 第 2 週：偽の導線＋データ → 需要の検証
• 第 3 週：プロトタイプ → ソリューションの検証
• 第 4 週：結果の統合 → 開発の判断

ディスカバリーにかかる投資の合計： 4 週間、約 40 時間
ディスカバリーを行わずに開発する場合との比較： エンジニアリングに 3～6 か月

---

例 2：継続的なディスカバリーの導入

入力：

「B2B SaaS のスタートアップで PM をしています。正式なディスカバリーは何も行っていません。顧客からの要望や CEO の希望に沿って開発しているだけです。継続的なディスカバリーを始めるには、どうすればよいでしょうか？」

出力：

継続的なディスカバリーを始めるためのガイド

小さく始め、習慣を身につける

避けること：

• プロセス全体を一新しようとする
• 現在進めている開発をすべて止める
• リサーチチームを雇う

実行すること：

• 毎週、ディスカバリーの習慣を 1 つずつ追加する
• 自分でコントロールできることから始める
• すぐに価値を示す

第 1 週：顧客との会話を習慣にする

アクション： 来週の顧客との通話を 2 件予定します。

話を聞く相手：

• 最近、解約またはダウングレードした顧客 1 人
• 最近、アップグレードした顧客、またはエンゲージメントが非常に高い顧客 1 人

スクリプト： 「私たちは、あなたのような方にとって [product] をより良いものにするために取り組んでいます。 どのように使っているか、何を改善できるかを理解するために、20 分ほどお話を伺いたいです。 営業の電話ではなく、学ぶための機会です。」

各通話の後： 次の内容を箇条書きで 3～5 点書きます。

• どのような課題を解決しようとしていたか？
• うまくいっていることは何か？ うまくいっていないことは何か？
• 何が意外だったか？

第 2 週：仮説を追跡する

アクション： 開発中の機能について、主な仮説を 3 つ挙げます。

形式の例：

Feature: New onboarding flow
Assumptions:
1. Users don't complete onboarding because it's too long
2. Users who complete onboarding retain better
3. Users want to invite teammates during onboarding

Evidence level:
1. Assumption (no evidence)
2. Validated (we have data)
3. Assumption (no evidence)

チームと共有する： 「これが私たちの仮説です。最も確信が持てないのはどれですか？ どのように検証できるでしょうか？」

第 3 週：インタビューの質問を追加する

アクション： すべての顧客との通話（サポート、営業、カスタマーサクセス）に、ディスカバリーの質問を 1 つ追加します。

質問： 「現在、私たちがサポートできていないことで、あなたが直面している最大の課題は何ですか？」

回答を集める： チームが回答を投稿する共有ドキュメントまたは Slack チャンネルを用意します。

週次レビュー： 「8 人の顧客と話しました。課題について、次のような話を聞きました……」

第 4 週：小さな実験

アクション： 小さな実験を 1 つ実施します。

簡単な選択肢：

• 提案中の機能についてアプリ内アンケートを実施する
• 機能アイデアのフェイクドアを設置する
• オンボーディングで A/B テストを実施する

結果を共有する： 「[X] をテストしました。ここでわかったことは [Y] です。 これにより、[Z] に対する考え方が変わります。」

経営陣の賛同を得る

許可を求めるのではなく、価値を示しましょう。

4 週間後、次の内容を共有します。

• 「8 人のお客様と話しました。ここでわかったことをお伝えします。」
• 「実験を 1 つ実施しました。その結果、[X] がわかりました。」
• 「データから、お客様が実際には必要としていないとわかった [feature] を、開発せずに済みました。」

提案内容： 「大規模なリサーチへの投資を求めているわけではありません。週に 2～3 時間を使ってお客様と話し、小規模なテストを実施しています。 すでに、より適切な優先順位付けに役立っています。」

拡大する

習慣が定着したら（4～8 週間後）、次のことを行います。

1. インタビューの頻度を正式に定める： チーム標準を週 2～3 回にする
2. 機会のバックログを作成する： 解決できる可能性のある問題を記録する
3. ロードマップと連携させる： ディスカバリーの結果を、開発するものに反映する
4. エンジニアを巻き込む： エンジニアもお客様との通話に参加する

---

例 3：機会の評価

入力：

「開発候補の機能が 3 つあります。（A）AI を活用した提案、（B）チームコラボレーションの改善、（C）モバイルアプリです。どれを優先すべきか、どう評価すればよいですか？」

出力：

機会の評価：機能の優先順位付け

機会 A：AI を活用した提案

問題の評価

要因	スコア	理由
頻度	3	毎日利用するユースケース
強度	2	あると便利ですが、なくても困りません
支払い意欲	2	市場は AI を期待していますが、差別化につながるでしょうか？
市場規模	4	ほとんどのユーザーに当てはまります
問題スコア	2.75

ソリューションの評価

要因	スコア	理由
実現可能性	3	ML の専門知識が必要ですが、実現可能です
戦略との適合性	4	「インテリジェントな製品」というビジョンに沿っています
競争優位性	2	他社が簡単に模倣できます
ソリューションスコア	3.0

主なリスク：

• 価値：提案は実際に使えるほど優れたものになるでしょうか？
• 実現可能性：ML の人材はいますか？
• 事業性：トレーニングデータの要件とコスト

機会スコア：8.25

---

機会 B：チームコラボレーション

問題の評価

要因	スコア	理由
頻度	5	チームでは 1 日に複数回発生します
強度	4	現在の不便さから回避策が生まれています
支払い意欲	4	チーム向け料金プランがあります
市場規模	3	チームアカウントに限られます
問題スコア	4.0

ソリューションの評価

要因	スコア	理由
実現可能性	4	標準的な機能で、既知のパターンがあります
戦略との適合性	5	成長戦略を直接支えます
競争優位性	3	差別化は可能ですが、大きなものではありません
ソリューションスコア	4.0

主なリスク：

• 価値：具体的にどのコラボレーション機能が重要でしょうか？
• 使いやすさ：チーム機能はすぐに複雑になる可能性があります

機会スコア：16.0

---

機会 C：モバイルアプリ

問題の評価

要因	スコア	理由
頻度	3	モバイルを求めるユーザーもいますが、大半はデスクトップを使います
強度	4	モバイルユーザーは非常に不満を感じています
支払い意欲	2	プレミアム機能ではなく、あって当然と見なされています
市場規模	2	モバイルを必要とするのは一部のユーザーに限られます
問題スコア	2.75

ソリューションの評価

要因	スコア	理由
実現可能性	2	大規模な作業が必要です（iOS、Android、および保守）
戦略との適合性	3	現在のポジショニングの中核ではありません
競争優位性	2	必須要件であり、差別化にはなりません
ソリューションスコア	2.33

主なリスク：

• 事業性：継続的な保守コスト
• 実現可能性：ネイティブとクロスプラットフォームのどちらにするか

機会スコア：6.4

---

まとめと推奨事項

機会	課題	解決策	スコア	順位
チームコラボレーション	4.0	4.0	16.0	1位
AI による提案	2.75	3.0	8.25	2位
モバイルアプリ	2.75	2.33	6.4	3位

推奨事項：

1. チームコラボレーションを優先する

   • 課題の深刻度が最も高い
   • 戦略との適合性が明確
   • 実現可能

2. AI による提案は当面保留する

   • まず価値に関するリスクを検証する
   • 検討事項：どのような具体的な提案に価値があるでしょうか？
   • 機械学習の前に、簡単なルールでテストする

3. モバイルアプリの優先度を下げる

   • 開発工数が大きく、リーチが限られる
   • 検討事項：暫定策としてプログレッシブウェブアプリを検討するか？
   • チームコラボレーションが軌道に乗ったら再検討する

次のステップ：

• チームコラボレーションの課題に焦点を当てたインタビューを5件実施する
• 具体的なコラボレーション上の課題を上位3つ特定する
• 本格的な開発を決定する前に、プロトタイプを作成してテストする

---

チェックリストとテンプレート

ディスカバリー開始チェックリスト

## Before Starting Discovery

### Define the Scope
□ What outcome are we trying to achieve?
□ What problem might we solve?
□ Who is the target customer?
□ What's the timeline for decision?

### Identify Assumptions
□ List top 10 assumptions about problem and solution
□ Rank by risk level (if wrong, how bad?)
□ Identify top 3 to test first

### Plan Activities
□ Customer interviews scheduled (minimum 5)
□ Data/analytics to review identified
□ Prototype or experiment designed
□ Success criteria defined

### Align Team
□ Cross-functional team identified
□ Discovery goals shared
□ Calendar blocked for activities

---

ディスカバリー概要テンプレート

## Discovery Summary: [Feature/Opportunity]

### Problem Statement
[What problem are we solving? For whom?]

### Research Conducted
- [X] customer interviews
- [X] data analyses
- [X] prototype tests
- [X] experiments

### Key Findings

**What we learned about the problem:**
1.
2.
3.

**What we learned about solutions:**
1.
2.
3.

### Risk Assessment

| Risk | Level | Mitigation |
|------|-------|------------|
| Value | | |
| Usability | | |
| Feasibility | | |
| Viability | | |

### Recommendation
[Build / Don't Build / Need More Discovery]

### If Building, Success Metrics
- Metric 1:
- Metric 2:
- Metric 3:

---

スキルの範囲

このスキルで得意なこと

• 説得力のあるコンテンツの構成
• コピーライティングのフレームワークの活用
• 草案のバリエーションの作成
• 競合他社のアプローチの分析

このスキルでできないこと

• コンバージョン率の保証
• ブランドの声の確立に代わること
• 特定のオーディエンスを把握すること
• 最終承認の判断

参考資料

• Cagan, Marty. 「Inspired: How to Create Tech Products Customers Love」（2018）
• Cagan, Marty & Jones, Chris. 「Empowered」（2020）
• Torres, Teresa. 「Continuous Discovery Habits」（2021）
• Silicon Valley Product Group（SVPG）のリソース
• Intercom のプロダクトマネジメントに関する資料

関連スキル

• customer-discovery - Steve Blank のより広範なフレームワーク
• mom-test - 顧客インタビューの手法
• lean-canvas - ビジネスモデルの検証
• shape-up - Basecamp の開発手法
• design-sprint - Google Ventures のスプリント

---

スキルのメタデータ

• モード: cyborg

name: product-discovery
category: product
subcategory: methodology
version: 1.0
author: MKTG Skills
source_expert: Marty Cagan
source_work: Inspired, Empowered
difficulty: intermediate
estimated_value: $10,000+ product consulting engagement
tags: [product, discovery, validation, PM, Cagan, SVPG, risk, prototyping]
created: 2026-01-25
updated: 2026-01-25