opportunity-solution-tree

opportunity-solution-tree skill の概要

opportunity-solution-tree skill は、プロダクトディスカバリーのための Opportunity Solution Tree を作るのに役立ちます。つまり、望ましい成果から始めて、顧客機会、候補ソリューション、そして実験へとつながる構造化された道筋を整理する skill です。次に何を作るべきかを、機能発想に飛びつかずに判断したい Product Management チームに特に向いています。

この skill は何のために使うか

戦略、リサーチ、OKR を、意思決定に使えるディスカバリーマップへ落とし込みたいときに opportunity-solution-tree skill を使います。プロダクトの成果を定義したいとき、顧客の痛みをグルーピングしたいとき、ソリューション案を比較したいとき、または実装前にテスト計画を立てたいときに適しています。

どんな人に最も役立つか

この skill は、プロダクトマネージャー、ディスカバリーリード、デザイナー、そして共通の課題領域に取り組むクロスファンクショナルチームに最適です。特に、すでに関係者が機能アイデアを持っている一方で、それらを根拠に結びつける、より дисциплинированый な進め方が必要な場面で力を発揮します。

汎用プロンプトと何が違うのか

汎用プロンプトでも OST 風の回答は作れますが、opportunity-solution-tree skill は再現性のある構造を与えてくれます。まず成果、次に機会、3 番目にソリューション、最後に実験、という順番です。この順序は、解決策へのバイアスを減らし、トレードオフをチームに説明しやすくするため重要です。

opportunity-solution-tree skill の使い方

skill をインストールして中身を確認する

opportunity-solution-tree install では、skills 環境のディレクトリインストール手順を使い、まず SKILL.md を開いてください。エージェント設定が repository ベースのインストールに対応しているなら、phuryn/pm-skills と pm-product-discovery/skills/opportunity-solution-tree の path を指定します。

意思決定に使える入力を渡す

この skill は、最初に次の 4 つを渡すと最もよく機能します。ターゲット成果、ユーザーセグメント、すでに持っている証拠、そして既知の制約です。たとえば「OST を作って」ではなく、次のように依頼します。「セルフサーブのトライアルユーザーにおける 7 日間 retention を改善するための Opportunity Solution Tree を作ってください。インタビューのメモ、離脱理由、既存の onboarding flow が 1 つあります。ソリューションより先に opportunity を優先してください。」

最初に読むべきファイルを選ぶ

ワークフローと必須入力を理解するために、まず SKILL.md を読みます。ローカルインストールで 1 ファイルしか見えないなら、それを唯一の正本として扱ってください。環境が repository 全体を反映している場合は、近くの package metadata や discovery guidance も確認し、チームのプロダクト用語に tree を合わせられるようにします。

正しい順番でワークフローを進める

実用的な opportunity-solution-tree usage の流れは、成果を定義する、リサーチやユーザーフィードバックから opportunity を集める、それらをグループ化して順位づけする、各 opportunity に対して複数のソリューションを考える、最後に最もリスクの高い仮説を検証できる experiment を付ける、という順番です。tree は 1 つの成果に絞っておくと、バックログの寄せ集めにならず、実用性を保てます。

opportunity-solution-tree skill の FAQ

これは単なるブレインストーミング用テンプレートですか？

いいえ。opportunity-solution-tree skill は、ランダムなアイデアを出すためではなく、プロダクトディスカバリーを構造化するためのものです。価値は、成果から、根拠のある opportunity を経て、テスト可能な solution へつながる流れを明確にする点にあります。

どんなときに使わないほうがいいですか？

問題がすでに完全に定義されていて、作業の中心が実行である場合や、実際の opportunity を見つけるのに十分な顧客証拠がない場合は、OST を使わないでください。そうしたケースでは、より簡潔な要件ブリーフや delivery plan のほうが適しています。

初心者向けですか？

はい。ただし、すでにプロダクトゴールがあることが前提です。難しいのは形式ではなく、1 つの成果に絞ることと、機能を隠した表現ではなく、顧客視点で opportunity を書くことです。

Product Management にどう役立ちますか？

Product Management において opportunity-solution-tree skill は、優先順位づけの会話を改善し、ディスカバリー作業を可視化し、なぜある opportunity や experiment が他より価値が高いのかをチームで説明しやすくします。ロードマップの約束をする前に、特に有効です。

opportunity-solution-tree skill の改善方法

より狭い成果から始める

より良い OST は、より絞られたプロンプトから生まれます。「activation を増やす」は広すぎますが、「signup から 7 日以内に新規 team admin の activation を増やす」なら、skill に具体的な目標、ユーザーセグメント、そして使える意思決定の境界を与えられます。

実際の opportunity データを入れる

tree の質は、opportunity の質に左右されます。インタビューの引用、サポートの論点、セッションメモ、勝敗パターン、利用データなどを入力し、社内の思い込みと本当の顧客課題を切り分けられるようにしてください。

枝分かれだけでなく、順位づけされたトレードオフを求める

opportunity-solution-tree usage の結果をより強くするには、opportunity の順位づけ、それぞれがなぜ重要かの説明、そして各 solution を否定できる最小限の experiment の提案まで求めます。そうすると、ディスカバリーレビューや関係者との認識合わせで、より実行可能な出力になります。

最初の tree のあとに反復する

最初のバージョンで抜けている点を洗い出し、その後、より良い証拠とより鋭い言葉で磨き直します。tree がソリューション寄りに見えるなら、機能表現を opportunity の言葉に戻してください。逆に曖昧なら、セグメントの詳細、成果指標、そして期間、技術制約、リサーチの確度といった明示的な制約を追加します。