product-ideation
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: ビッグテック参入リスク
この分野にビッグテックが参入する確度はどれくらいか？
| 企業 | 参入シグナル | 脅威度 |
|---|---|---|
| 検索、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 でユーザーの生の声を調査する。
調査結果の共有例： 「調べたところ、〇〇という既存サービスが見つかりました」 「〇〇という課題に対しては、△△というアプローチが一般的なようです」 「同じ課題に取り組んだ〇〇は、□□という理由で失敗しています」
このステップでのストレステスト
-
その課題、本当に深刻か？ 「あったら便利」レベルは課題ではない。「ないと困る」「金を払ってでも解決したい」レベルか。
-
その課題を持つ人は何人いる？ 100人しかいないなら事業にならない。具体的な数字を出せるか。
-
その課題、Googleで検索して解決できない？ 検索で解決できるならプロダクトは不要。
Step 3: ソリューション設計
課題をどう解決するかを設計する。
確認すべきこと：コア機能（最小限で価値を提供できる機能）、ユーザー体験（どう使われるか）、技術的実現性。
フレームワーク → references/frameworks.md の「ソリューション設計」セクション参照
このステップでのWeb調査
以下の検索を必ず実行する。
[ソリューション] alternatives で代替サービスを網羅、[ソリューション] vs で比較記事、[ソリューション] open source GitHub でOSSの選択肢、[ソリューション] API で既存APIの活用可能性を調査する。
調査結果の共有例： 「類似サービスとして〇〇、△△、□□が見つかりました。それぞれの特徴は...」 「〇〇というOSSを使えば、コア機能の一部は実装不要かもしれません」 「〇〇のAPIを組み合わせれば、もっと早く実現できる可能性があります」
調査中により良いアプローチを見つけたら、積極的に提案する。ユーザーのアイデアより良い方法があれば遠慮しない。
このステップでのストレステスト
-
それ、既存ツールの組み合わせで実現できない？ Zapier + Notion + ChatGPT APIで十分では？ スプレッドシート + GASで十分では？
-
それ、ビッグテックが明日発表したら終わりでは？ GoogleやOpenAIのロードマップを確認したか。彼らが作らない理由があるか。
-
技術的な堀（モート）はあるか？ 独自データ？独自アルゴリズム？ネットワーク効果？「頑張って作った」は堀ではない。
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、紙、人力、何もしない）、ビッグテックの既存サービス、ビッグテックが今後出しそうなサービス。
ストレステスト（差別化）
以下の全ての問いに明確に答えられるか？
-
Google/Amazon/Microsoft/OpenAI/Salesforceが本気出したら勝てる？ 勝てないならその分野はやめる。勝てるなら、なぜか具体的に説明する。
-
「別にGoogleで良いじゃん」に対する回答は？ 回答できないなら企画やり直し。「使いやすさ」「サポート」だけでは弱すぎる。
-
参入障壁は何？ 技術 → 真似されたら終わり。データ → どうやって集める？ 顧客関係 → 具体的にどの顧客？ 規制 → 本当に参入障壁になる？
-
日本特化が差別化になると思っていないか？ 「日本語対応」は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 スキルでスライド化する。
/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）の生成 |