product-discovery

product-discovery skill の概要

product-discovery でできること

product-discovery skill は、チームが開発工数を投下する前に、AI エージェントを使って構造化されたプロダクトディスカバリーを進めるための skill です。機会の検証、リスクの高い仮説の洗い出し、ディスカバリースプリントの計画、そして進める・方向転換する・止めるの判断に向いています。単に「プロダクトアイデア」を出すのではなく、成果、機会、仮説、実験、学習にもとづく意思決定へ作業を寄せていきます。

Product Management 業務に向いているケース

product-discovery は、不明確な顧客課題、新機能への賭け、市場向けの実験、初期段階のソリューション案について、再現性のあるディスカバリーワークフローが必要な Product Management 業務に適しています。特に、汎用的なロードマップを生成するのではなく、AI アシスタントにディスカバリー成果物を整理させたいプロダクトマネージャー、創業者、プロダクトデザイナー、UX リサーチャー、クロスファンクショナルなチームに有用です。

この skill の違い

この skill は、Opportunity Solution Trees、仮説マッピング、Jobs-to-be-Done、Kano、デザインスプリント的な考え方、実験計画といった実践的なディスカバリーフレームワークを中心に設計されています。特に差別化されている点は、同梱されている scripts/assumption_mapper.py です。このスクリプトは、CSV に記載した仮説をリスクスコアと確信度スコアにもとづいて優先順位付けし、仮説カテゴリに応じた適切な検証テストを提案できます。

向いていないケース

主な目的がデリバリー計画、スプリントバックログの整理、PRD のフォーマット作成、グロース向けコピー、分析計測の実装である場合、この skill をインストールする必要はありません。product-discovery が最も価値を発揮するのはデリバリー前の段階です。つまり、チームがまだユーザー課題を明確にし、最もリスクの高い思い込みを特定し、低コストな検証方法を選ぶ必要があるタイミングです。

product-discovery skill の使い方

product-discovery のインストールとリポジトリパス

利用している skill manager が参照する GitHub リポジトリパスから skill をインストールします。一般的なインストールコマンドは次のとおりです。

npx skills add alirezarezvani/claude-skills --skill product-discovery

ソースは次の場所にあります。

product-team/skills/product-discovery

インストール後は、まず SKILL.md を読み、次に references/discovery-frameworks.md を確認してください。CSV から仮説をスコアリングする予定がある場合は、最後に scripts/assumption_mapper.py を確認します。この skill フォルダには個別の README.md や metadata.json はないため、主要な運用手順はこの 3 つのファイルに集約されています。

skill に渡すべき入力情報

質の高い product-discovery usage のためには、単なる機能リクエスト以上の情報をエージェントに渡してください。含めるべき情報は次のとおりです。

• 目標成果: 改善したい指標または行動
• ユーザーセグメント: 誰が、どのような文脈でその課題を抱えているのか
• 現在の証拠: インタビュー、サポートチケット、分析データ、営業メモ、解約理由
• 候補となる機会: 痛み、ニーズ、または達成したいジョブ
• 制約: 期間、チーム体制、コンプライアンス、市場、技術的制約
• 必要な意思決定: 進める、方向転換する、止める、インタビューする、プロトタイプを作る、実験を設計する

弱いプロンプト:

Help us validate a new onboarding feature.

より強いプロンプト:

Use product-discovery to plan discovery for reducing activation drop-off from 42% to 30% in 8 weeks. Segment: self-serve B2B admins setting up their first workspace. Evidence: 12 support tickets mention confusing permissions; analytics show most drop-offs happen before inviting teammates. We are considering an onboarding checklist but are unsure if the real opportunity is permissions clarity, team invitation anxiety, or lack of perceived value. Produce an Opportunity Solution Tree, risky assumptions, and a 1-week validation plan.

初回利用におすすめのワークフロー

まず、測定可能な成果を 1 つ定義し、Opportunity Solution Tree を作るよう skill に依頼します。構造は outcome → opportunities → solution ideas → experiments です。次に、証拠に裏づけられた機会と、社内の意見にすぎないものを切り分けさせます。そのうえで、desirability、viability、feasibility、usability の仮説を作成します。最後に、最もリスクの高い仮説を、インタビュー、プロトタイプテスト、fake-door test、価格テスト、技術検証スパイクへ変換します。

すでに仮説がある場合は、次の列を持つ CSV を作成します。

assumption,category,risk,certainty

risk と certainty には 0 から 1 の値を使い、次を実行します。

python3 scripts/assumption_mapper.py assumptions.csv

このスクリプトは、高リスクかつ低確信度の仮説を優先し、検証テストの種類を提案します。

実務で使いやすいプロンプト例

フレームワークだけでなく、意思決定に使えるアウトプットを依頼してください。よい依頼例は次のとおりです。

• “Create an OST and mark which branches need more evidence.”
• “Turn these interview notes into opportunity themes and confidence levels.”
• “Map assumptions and identify the cheapest test for each top risk.”
• “Design a 1-week discovery sprint with daily evidence reviews.”
• “Define stop, pivot, and proceed criteria before we run tests.”

この skill は、証拠ラベルを明示させるほど精度が上がります。たとえば、観察された行動、直接の発言、指標、社内意見、不明、のように分類させるとよいでしょう。

product-discovery skill FAQ

product-discovery はプロダクトマネージャー専用ですか？

いいえ。product-discovery skill は Product Management 向けに設計されていますが、プロダクト上の賭けを低リスク化したい創業者、デザイナー、リサーチャー、グロースチーム、テクニカルリードにも役立ちます。重要なのは、顧客、事業目標、制約に関する文脈をユーザーが提供できることです。

通常のディスカバリープロンプトより何が優れていますか？

通常のプロンプトでも質問や実験のリストは作れます。product-discovery は、エージェントにより具体的な運用モデルを与えます。測定可能な成果、Opportunity Solution Tree、仮説カテゴリ、リスク／確信度スコアリング、課題検証、ソリューション検証、ディスカバリースプリントの意思決定といった構造です。この構造により当て推量が減り、複数の機会を比較しやすいアウトプットになります。

ユーザーリサーチの代わりになりますか？

いいえ。ディスカバリーの計画と統合には役立ちますが、インタビュー、行動データ、プロトタイプテスト、市場からの証拠を置き換えることはできません。出力は仮説と運用計画として扱ってください。結果の品質は、提供する証拠の質と、弱い機会を却下するチームの姿勢に大きく左右されます。

初心者は何を最初に読むべきですか？

まず SKILL.md を読んでワークフローを理解し、次に references/discovery-frameworks.md でフレームワークの定義を確認してください。ディスカバリーに慣れていない場合は、最初に 3 つの概念に絞るのがおすすめです。Opportunity Solution Tree、Jobs-to-be-Done のインタビューフレーミング、仮説優先順位付けマトリクスです。Python スクリプトは、各仮説の意味を理解してから使ってください。

product-discovery skill を改善する方法

product-discovery の結果は証拠の質で改善する

product-discovery の出力を最も早く改善する方法は、整えられた結論ではなく、生の証拠を渡すことです。インタビュー抜粋、行動指標、サポートチケット、失注理由、利用ファネル、プロトタイプ観察などを含めてください。チームが社内の好みをうっかり検証してしまわないよう、エージェントには「証拠」と「解釈」を分けるよう依頼します。

よくある失敗パターンを避ける

弱いアウトプットでよく見られるのは、ソリューション起点のツリー、曖昧な仮説、大きすぎる実験、誘導質問だらけのインタビュー計画です。次の点を明示して対策してください。

• ソリューションより前に機会を整理する
• 仮説を検証可能な主張として書く
• 信頼できる最小の実験に絞る
• 成功と失敗のしきい値を決める
• テスト後にどの意思決定が変わるのかを明確にする

たとえば、“users want better onboarding” ではなく、“new workspace admins fail to invite teammates because they do not understand permission consequences.” のように書き換えます。

初回出力のあとに反復する

最初の結果を完成版として扱わないでください。コスト、スピード、証拠の質、意思決定への影響という観点で、skill にディスカバリー計画を自己批評させます。そのうえで、実際の意思決定を変えない実験を削除するよう依頼してください。2 回目のレビューに使いやすいプロンプトは次のとおりです。

Review this discovery plan. Identify assumptions that are too vague, experiments that are too expensive, and places where we are testing preference instead of behavior. Revise into a 5-day plan with clear proceed, pivot, and stop criteria.

チームに合わせて skill をカスタマイズする

長期的に使いやすくするには、チーム固有の例を追加してください。自社のプロダクト指標、顧客セグメント、リサーチテンプレート、実験基準、意思決定のしきい値などです。組織に厳格なコンプライアンス、エンタープライズ営業サイクル、マーケットプレイス特有の力学、ハードウェア制約がある場合は、それらもプロンプトに含めます。product-discovery は、一般的なフレームワークが実際の業務環境に根ざしているときに最も力を発揮します。