Imported from David-Li0406/meta-skill-evloving (skill-flow/data/skills-refined-agentskillos-36k/skillsmp/product-ideation/SKILL.md). Install upstream with npx skills add David-Li0406/meta-skill-evloving --skill product-ideation. Copyright stays with the author.

Product Ideation

プロダクト企画を体系的に進め、mdドキュメントとして段階的にアウトプットする。

※このスキルは甘い企画を通さない。各ステップでストレステストを実施し、厳しい問いを投げかけ続ける。自らWeb検索を行い、競合・代替案・新しい可能性を能動的に探索する。

根本原則

1. 一言で説明できないものは作らない

企画の全プロセスを通じて、以下を常に問い続ける。

「で、それ一言で言うと何？」

すっと頭に入ってくるキャッチコピーが作れないなら、そのプロダクトはまだ練れていない。

2. 質問するだけでなく、自ら調べる

ユーザーに問いを投げるだけでは不十分。自らWeb検索を実行し、以下を徹底的に調査する。

競合サービスの現状、ビッグテックの最新動向・ロードマップ、類似サービス・代替案、市場トレンド、成功事例・失敗事例、ユーザーが気づいていない新しいアプローチ。

能動的調査（各ステップで必ず実施）

調査の原則

質問する前にまず自分で調べる。調べた結果をユーザーに共有し、その上で議論する。

Step別の調査アクション

必須の調査項目

各企画で以下を必ず調査する。

■ ビッグテックの動向

Google [関連キーワード] で最新ニュースを検索し、OpenAI [関連キーワード] で最新発表を確認。Microsoft Copilot [関連キーワード] で機能追加を見て、各社の公式ブログやプレスリリースもチェックする。

■ 既存サービス・代替案

[課題] software [課題] tool [課題] app で検索し、Product Huntで類似サービスを探す。G2やCapterraで競合を調査し、GitHubで関連オープンソースも検索する。

■ 市場・トレンド

[分野] market size 2024 で市場規模、[分野] trend で最新トレンド、[分野] startup funding で投資動向を確認する。

■ 失敗事例・教訓

[類似サービス] shutdown [類似サービス] failed で検索し、なぜ失敗したかを分析する。同じ轍を踏まないために必須。

■ 新しい可能性

調査中に見つけた新しいアプローチは積極的に提案する。ユーザーのアイデアより良い方法があれば、遠慮なく提示する。

ストレステスト（全ステップで実施）

以下の問いに明確に答えられない企画は、どれだけ時間をかけても無駄になる。各ステップで繰り返し検証する。

Test 1: ビッグテック参入リスク

この分野にビッグテックが参入する確度はどれくらいか？

■ 具体例での検証

• 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: ヒアリング

最初に以下を確認する。不明な点はユーザーに質問する。

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 スキルでスライド化する。

/baoyu-slide-deck docs/product-concept.md --audience executives

ガイドライン

調べてから質問する

ユーザーに問いを投げる前に、まず自分でWeb検索する。調査結果を共有した上で、追加の情報を求める。「調べたところ〇〇でしたが、それでも△△ですか？」という形で質問する。

新しい可能性を提案する

調査中により良いアプローチを見つけたら、積極的に提案する。ユーザーのアイデアに固執せず、客観的に最善の選択肢を提示する。「ユーザーが言ったから」ではなく「調査の結果最善だから」で判断する。

妥協しない

「なんとなく良さそう」で進めない。答えられない問いがあれば、そこで止まる。ユーザーが嫌がっても厳しい問いを投げ続ける。

具体性を求める

「便利」「効率化」「DX」などの曖昧な言葉を許さない。「誰が」「いくら」「何分短縮」など数字で語らせる。

撤退も選択肢

ストレステストをクリアできないなら、企画を止める勇気を持つ。「せっかくここまで考えたから」で進めない。調査の結果、より有望な別の方向性が見つかったら、そちらを提案する。

References

連携スキル