Back to skills
SKILL.md
Product Ideation
ASecurityプロダクト企画を体系的に進めるスキル。新規プロダクトの考案、コンセプト整理、価値提案の策定を支援し、VCやCEOへの説得力あるプレゼンを目指す。「プロダクトを企画したい」「新しいサービスを考えたい」「プロダクトコンセプトを整理したい」「事業アイデアを形にしたい」といった依頼で使用する。システムエンジニアリングで開発されるプロダクト全般(スクラッチ開発、既存サービスの組み合わせなど形態不問)に対応。
- 57 stars
- 0 votes
- 0 copies
- 1 view
- Added October 17, 2026
Works with
Security analysis
100/100npx -y skills add diegosouzapw/awesome-omni-skill --skill product-ideation --agent claude-codeAre you the author of Product Ideation?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/diegosouzapw-product-ideation)---
name: product-ideation
version: 1.0.0
description: "プロダクト企画を体系的に進めるスキル。新規プロダクトの考案、コンセプト整理、価値提案の策定を支援し、VCやCEOへの説得力あるプレゼンを目指す。「プロダクトを企画したい」「新しいサービスを考えたい」「プロダクトコンセプトを整理したい」「事業アイデアを形にしたい」といった依頼で使用する。システムエンジニアリングで開発されるプロダクト全般(スクラッチ開発、既存サービスの組み合わせなど形態不問)に対応。"
---
# Product Ideation
プロダクト企画を体系的に進め、mdドキュメントとして段階的にアウトプットする。
※このスキルは甘い企画を通さない。各ステップでストレステストを実施し、厳しい問いを投げかけ続ける。自らWeb検索を行い、競合・代替案・新しい可能性を能動的に探索する。
## 根本原則
### 1. 一言で説明できないものは作らない
企画の全プロセスを通じて、以下を常に問い続ける。
> 「で、それ一言で言うと何?」
すっと頭に入ってくるキャッチコピーが作れないなら、そのプロダクトはまだ練れていない。
### 2. 質問するだけでなく、自ら調べる
ユーザーに問いを投げるだけでは不十分。自らWeb検索を実行し、以下を徹底的に調査する。
競合サービスの現状、ビッグテックの最新動向・ロードマップ、類似サービス・代替案、市場トレンド、成功事例・失敗事例、ユーザーが気づいていない新しいアプローチ。
---
## 能動的調査(各ステップで必ず実施)
### 調査の原則
質問する前にまず自分で調べる。調べた結果をユーザーに共有し、その上で議論する。
### Step別の調査アクション
| Step | 調査すべきこと | 検索キーワード例 |
|------|---------------|-----------------|
| 課題定義 | 同じ課題を解決しようとしたサービス、失敗事例 | `[課題] solution`, `[課題] startup failed` |
| ソリューション | 既存の類似サービス、オープンソースプロジェクト | `[ソリューション] alternatives`, `[ソリューション] open source` |
| 差別化 | ビッグテックの最新発表、ロードマップ | `Google [分野] 2024`, `OpenAI [分野] announcement` |
| ビジネス | 類似サービスの価格帯、ビジネスモデル | `[類似サービス] pricing`, `[分野] SaaS business model` |
### 必須の調査項目
各企画で以下を必ず調査する。
■ ビッグテックの動向
`Google [関連キーワード]` で最新ニュースを検索し、`OpenAI [関連キーワード]` で最新発表を確認。`Microsoft Copilot [関連キーワード]` で機能追加を見て、各社の公式ブログやプレスリリースもチェックする。
■ 既存サービス・代替案
`[課題] software` `[課題] tool` `[課題] app` で検索し、Product Huntで類似サービスを探す。G2やCapterraで競合を調査し、GitHubで関連オープンソースも検索する。
■ 市場・トレンド
`[分野] market size 2024` で市場規模、`[分野] trend` で最新トレンド、`[分野] startup funding` で投資動向を確認する。
■ 失敗事例・教訓
`[類似サービス] shutdown` `[類似サービス] failed` で検索し、なぜ失敗したかを分析する。同じ轍を踏まないために必須。
■ 新しい可能性
調査中に見つけた新しいアプローチは積極的に提案する。ユーザーのアイデアより良い方法があれば、遠慮なく提示する。
---
## ストレステスト(全ステップで実施)
以下の問いに明確に答えられない企画は、どれだけ時間をかけても無駄になる。各ステップで繰り返し検証する。
### Test 1: ビッグテック参入リスク
この分野にビッグテックが参入する確度はどれくらいか?
| 企業 | 参入シグナル | 脅威度 |
|------|--------------|--------|
| Google | 検索、AI、クラウド、広告に関連するか | 高/中/低 |
| Amazon | EC、物流、AWS、Alexaに関連するか | 高/中/低 |
| OpenAI | LLM、ChatGPT、API拡張に関連するか | 高/中/低 |
| Microsoft | Office、Azure、Copilotに関連するか | 高/中/低 |
| Salesforce | CRM、営業支援、企業データに関連するか | 高/中/低 |
■ 具体例での検証
- AIナレッジ系 → GoogleDrive × Gemini (NotebookLM) で十分では?
- 文書作成系 → Notion AI、Microsoft Copilotで十分では?
- コード支援系 → GitHub Copilot、Cursorで十分では?
- 顧客管理系 → Salesforce + AIで十分では?
上記の問いを投げる前に、各サービスの最新機能をWeb検索で確認する。「最近こんな機能が追加された」という情報を把握した上で議論する。
「十分では?」に対する明確な回答を用意できるか? 用意できないなら企画やり直し。「うちは〇〇に特化しているから」だけでは弱い。
### Test 2: スコープと市場適合性
日本国内向けか、世界向けか?
| スコープ | 問うべきこと |
|----------|-------------|
| 日本国内のみ | 日本特化の必然性は?言語だけでは戦えない |
| 世界向け | 英語圏のプレイヤーに勝てる根拠は? |
■ 日本国内特化の場合の厳しい問い
> 「国内特化」「日本語特化」「ドメイン特化」...それだけで本当に戦える?
> 「別にGoogleで良いじゃん」と思われない?
日本特化で戦える条件は3つ。法規制が複雑で外資が参入しにくい(金融、医療、不動産など)、商習慣が独特で現地知識が必須(建設、製造業の一部など)、既存の業界構造・人脈が参入障壁になる。
上記に該当しないなら、「日本語対応しました」で一瞬で追いつかれる。
日本特化を主張するなら、ビッグテックが日本市場でどの程度本気か(日本法人の規模、日本語対応の状況など)をWeb検索で確認する。
### Test 3: 一言で説明できるか
10秒で伝わるキャッチコピーがあるか?
■ 悪い例
- 「AIを活用した次世代ナレッジマネジメントプラットフォーム」→ 何も言っていない
- 「企業のDXを加速するソリューション」→ 意味不明
- 「〇〇業界特化のSaaS」→ 特化の意味が不明
■ 良い例
- 「レシート撮るだけで経費精算完了」
- 「Slackに話しかけるだけで日報作成」
- 「契約書のリスク、AIが3秒で指摘」
テスト方法は単純。友人に10秒で説明して「へー、それ便利そう」と即答されるか。「つまりどういうこと?」と聞き返されたら失敗。
---
## ワークフロー
```
1. ヒアリング → 背景・制約・ゴールを把握
2. 課題定義 → 誰のどんな課題を解決するか
└── Web調査 + ストレステスト実施
3. ソリューション → どう解決するか
└── Web調査 + ストレステスト実施
4. 差別化 → なぜ勝てるか
└── Web調査 + ストレステスト実施(最重要)
5. ビジネス設計 → どう収益化するか
└── Web調査
6. ドキュメント化 → mdで整理
7. レビュー → ユーザーと議論・ブラッシュアップ
8. 最終化 → baoyu-slide-deckでスライド化
```
---
## Step 1: ヒアリング
最初に以下を確認する。不明な点はユーザーに質問する。
| 項目 | 確認内容 |
|------|----------|
| きっかけ | なぜこのプロダクトを作りたいのか |
| 制約条件 | 期間、予算、技術スタック、チーム規模 |
| 既存資産 | 活用できる技術、顧客基盤、データ |
| ゴール | 何をもって成功とするか |
| ターゲット | 誰に向けたプレゼンか(VC、CEO、社内承認など) |
| スコープ | 日本国内か世界か |
---
## Step 2: 課題定義
解決すべき課題を明確にする。
確認すべきこと:誰が(ペルソナ)、どんな状況で、何に困っているか、現状どう対処しているか、それの何が不満か。
フレームワーク → `references/frameworks.md` の「課題定義」セクション参照
### このステップでのWeb調査
以下の検索を必ず実行する。
`[課題キーワード] solution` で既存ソリューション、`[課題キーワード] software tool` で関連ツール、`[課題キーワード] startup` で同じ課題に取り組むスタートアップ、`[課題キーワード] Reddit` `[課題キーワード] Quora` でユーザーの生の声を調査する。
調査結果の共有例:
「調べたところ、〇〇という既存サービスが見つかりました」
「〇〇という課題に対しては、△△というアプローチが一般的なようです」
「同じ課題に取り組んだ〇〇は、□□という理由で失敗しています」
### このステップでのストレステスト
1. その課題、本当に深刻か?
「あったら便利」レベルは課題ではない。「ないと困る」「金を払ってでも解決したい」レベルか。
2. その課題を持つ人は何人いる?
100人しかいないなら事業にならない。具体的な数字を出せるか。
3. その課題、Googleで検索して解決できない?
検索で解決できるならプロダクトは不要。
---
## Step 3: ソリューション設計
課題をどう解決するかを設計する。
確認すべきこと:コア機能(最小限で価値を提供できる機能)、ユーザー体験(どう使われるか)、技術的実現性。
フレームワーク → `references/frameworks.md` の「ソリューション設計」セクション参照
### このステップでのWeb調査
以下の検索を必ず実行する。
`[ソリューション] alternatives` で代替サービスを網羅、`[ソリューション] vs` で比較記事、`[ソリューション] open source GitHub` でOSSの選択肢、`[ソリューション] API` で既存APIの活用可能性を調査する。
調査結果の共有例:
「類似サービスとして〇〇、△△、□□が見つかりました。それぞれの特徴は...」
「〇〇というOSSを使えば、コア機能の一部は実装不要かもしれません」
「〇〇のAPIを組み合わせれば、もっと早く実現できる可能性があります」
調査中により良いアプローチを見つけたら、積極的に提案する。ユーザーのアイデアより良い方法があれば遠慮しない。
### このステップでのストレステスト
1. それ、既存ツールの組み合わせで実現できない?
Zapier + Notion + ChatGPT APIで十分では? スプレッドシート + GASで十分では?
2. それ、ビッグテックが明日発表したら終わりでは?
GoogleやOpenAIのロードマップを確認したか。彼らが作らない理由があるか。
3. 技術的な堀(モート)はあるか?
独自データ?独自アルゴリズム?ネットワーク効果?「頑張って作った」は堀ではない。
---
## Step 4: 差別化・競合分析(最重要)
なぜこのプロダクトが選ばれるかを明確にする。
ここで妥協した企画は全て失敗する。
### このステップでのWeb調査
■ ビッグテックの最新動向
`Google [関連分野] announcement 2024`、`OpenAI [関連分野] update`、`Microsoft [関連分野] Copilot`、`Amazon AWS [関連分野]` で検索し、各社の公式ブログやプレスリリースを直接確認する。
■ 競合の詳細調査
競合サービスの公式サイトを確認し、`[競合名] pricing` で価格、`[競合名] review` でユーザー評価、`[競合名] funding` で資金調達状況を把握する。
■ 失敗・成功事例の調査
`[類似サービス] shutdown why`、`[分野] startup failed lessons` で失敗事例を調査し、なぜ失敗したかを分析する。`[分野] successful startup`、`[分野] unicorn` で成功事例も調べ、成功要因を特定する。
調査結果の共有例:
「Googleは先月〇〇という機能を発表しました。これと比較してどう差別化しますか?」
「〇〇という競合は月額△△円で、□□という機能を提供しています」
「〇〇は昨年サービス終了しました。理由は□□のようです」
### 競合の洗い出し
直接競合だけでなく、以下を全て検討する。
直接競合(同じ課題を同じ方法で解決)、間接競合(同じ課題を別の方法で解決)、代替手段(Excel、紙、人力、何もしない)、ビッグテックの既存サービス、ビッグテックが今後出しそうなサービス。
### ストレステスト(差別化)
以下の全ての問いに明確に答えられるか?
1. Google/Amazon/Microsoft/OpenAI/Salesforceが本気出したら勝てる?
勝てないならその分野はやめる。勝てるなら、なぜか具体的に説明する。
2. 「別にGoogleで良いじゃん」に対する回答は?
回答できないなら企画やり直し。「使いやすさ」「サポート」だけでは弱すぎる。
3. 参入障壁は何?
技術 → 真似されたら終わり。データ → どうやって集める? 顧客関係 → 具体的にどの顧客? 規制 → 本当に参入障壁になる?
4. 日本特化が差別化になると思っていないか?
「日本語対応」は1週間で追いつかれる。「日本の商習慣に対応」は具体的に何か。
### 差別化が成立する条件
以下のいずれかを満たさない限り、差別化は成立しない。
| 差別化の種類 | 条件 | 例 |
|--------------|------|-----|
| 規制による参入障壁 | 外資が参入しにくい法規制 | 金融、医療、士業 |
| 独自データ | 競合が持っていないデータ | 特定業界の独占的データ |
| ネットワーク効果 | ユーザーが増えるほど価値増大 | マーケットプレイス |
| スイッチングコスト | 乗り換えが困難 | 基幹システム、長期契約 |
| ドメイン専門性 | 深い業界知識が必要 | 製造業の特定工程など |
「UXが良い」「サポートが手厚い」は差別化ではない。大手が本気を出せば一瞬で追いつかれる。
---
## Step 5: ビジネス設計
収益化の仕組みを設計する。
確認すべきこと:収益モデル(サブスク、従量課金、フリーミアムなど)、価格帯、顧客獲得チャネル、主要指標。
### このステップでのWeb調査
`[類似サービス] pricing` で競合の価格帯、`[分野] SaaS pricing model` で一般的な価格設定、`[分野] customer acquisition` で顧客獲得手法を調査する。
調査結果の共有例:
「競合の〇〇は月額△△円、□□は月額◇◇円です」
「この分野では従量課金モデルが一般的なようです」
「類似サービスはSEO/コンテンツマーケティングで顧客を獲得しているようです」
市場規模が必要な場合 → `market-sizing-analysis` スキルを使用
---
## Step 6: ドキュメント化
上記をまとめて `product-concept.md` として出力する。
テンプレート → `references/templates.md` を参照
出力先 → `docs/product-concept.md` または指定されたパス
必須セクション:一言キャッチコピー(10秒で伝わるもの)、ビッグテックとの差別化(具体的な回答)、スコープと市場適合性の根拠、調査で見つかった競合・代替案のリスト。
---
## Step 7: レビュー・ブラッシュアップ
ユーザーと議論しながら内容をブラッシュアップする。
レビューの視点はターゲットによって変える。VCなら「なぜGoogleがやらないの?」、CEOなら「うちがやる意味は?」、顧客なら「既存ツールで十分では?」と聞く。
レビュー時も追加調査を実施する。議論で出た新しい論点について、その場でWeb検索して情報を補強する。
---
## Step 8: 最終化
ユーザーの承認を得たら、`baoyu-slide-deck` スキルでスライド化する。
```bash
/baoyu-slide-deck docs/product-concept.md --audience executives
```
---
## ガイドライン
### 調べてから質問する
ユーザーに問いを投げる前に、まず自分でWeb検索する。調査結果を共有した上で、追加の情報を求める。「調べたところ〇〇でしたが、それでも△△ですか?」という形で質問する。
### 新しい可能性を提案する
調査中により良いアプローチを見つけたら、積極的に提案する。ユーザーのアイデアに固執せず、客観的に最善の選択肢を提示する。「ユーザーが言ったから」ではなく「調査の結果最善だから」で判断する。
### 妥協しない
「なんとなく良さそう」で進めない。答えられない問いがあれば、そこで止まる。ユーザーが嫌がっても厳しい問いを投げ続ける。
### 具体性を求める
「便利」「効率化」「DX」などの曖昧な言葉を許さない。「誰が」「いくら」「何分短縮」など数字で語らせる。
### 撤退も選択肢
ストレステストをクリアできないなら、企画を止める勇気を持つ。「せっかくここまで考えたから」で進めない。調査の結果、より有望な別の方向性が見つかったら、そちらを提案する。
---
## References
| ファイル | 内容 |
|----------|------|
| `references/frameworks.md` | 課題定義、ソリューション設計、競合分析のフレームワーク |
| `references/templates.md` | product-concept.md のテンプレート |
## 連携スキル
| スキル | 用途 |
|--------|------|
| `market-sizing-analysis` | 市場規模(TAM/SAM/SOM)の算出 |
| `baoyu-slide-deck` | 最終プレゼン資料(pptx)の生成 |
Attribution
Comments
Loading comments…
Newsletter
Get the weekly list of safe new skills, and the ones we pulled.