mcpField
D
define-opportunity-tree

define-opportunity-tree

github.com/product-on-purpose生産性769781 回インストール4 日前に更新
リポジトリ

define-opportunity-tree について

define-opportunity-treeは、測定可能な成果を顧客の機会、解決策、仮説検証につなげるプロダクトディスカバリー用スキルです。根拠に基づくツリーで探索を整理し、優先順位を付けます。

主な機能

  1. 01成果から機会へのツリー構造
  2. 02顧客の機会を裏付ける根拠
  3. 03機会ごとの複数の解決策
  4. 04仮説検証と実験の設計
  5. 05枝の優先順位付けと学習記録

活用シーン

  1. 01継続的なプロダクトディスカバリーの整理
  2. 02探索する顧客機会の選定
  3. 03調査結果のプロダクト施策への反映

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/product-on-purpose/pm-skills --skill define-opportunity-tree

インストール後、Claude Code で/define-opportunity-treeを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

HISTORY.md
evals/
trigger-fixtures.json
references/
EXAMPLE.md
TEMPLATE.md

詳細

オポチュニティ・ソリューション・ツリー

オポチュニティ・ソリューション・ツリー(OST)は、ビジネス成果と顧客のオポチュニティ、潜在的なソリューションを結び付ける、プロダクトディスカバリーのための視覚的なフレームワークです。Teresa Torres が考案したこの手法では、すべての機能アイデアを顧客ニーズと測定可能な成果に結び付けることで、すぐにソリューションへ飛びついてしまうというよくある落とし穴を防ぎます。

使用する場面

  • 継続的なプロダクトディスカバリーで、学びを整理するとき
  • 取り組むオポチュニティに優先順位を付けるとき
  • プロダクト戦略をステークホルダーに伝えるとき
  • 機能アイデアが多すぎて、整理する枠組みが必要なとき
  • ユーザーリサーチの後に、インサイトを具体的な行動につなげるとき
  • チームで最も重視すべき成果について認識をそろえるとき

使用しない場面

  • 既知の候補を並べたリストにスコアを付け、順位を付けたい場合 → define-prioritization-framework を使用します。このツリーはディスカバリーを構造化するものであり、順位付けのためのものではありません
  • チームで取り組む特定の問題を定義したい場合 → define-problem-statement を使用します
  • 単一の仮説を検証する準備ができている場合 → define-hypothesis を使用し、その後 measure-experiment-design を使用します
  • 目指す成果についてまだ合意できていない場合 → まず foundation-okr-writer で設定します。合意された成果がないツリーは、意見を飾り立てるだけです

手順

オポチュニティ・ソリューション・ツリーの作成を依頼された場合は、次の手順に従ってください。

  1. 目指す成果を定義する 最上位に、明確で測定可能なビジネス成果またはプロダクト成果を設定します。プロダクトの変更によって影響を与えられる成果にしてください。可能な場合は定量的に表現します(例:「30 日間の継続率を 40% から 55% に上げる」)。

  2. オポチュニティ領域を特定する 3~5 個のオポチュニティ領域に枝分かれさせます。顧客のニーズやペインポイントに対応できる領域です。オポチュニティはソリューションではなく、顧客の問題、ニーズ、要望です。顧客の視点から表現してください。

  3. 裏付けとなるエビデンスを追加する 各オポチュニティについて、それを裏付けるエビデンスを記録します。ユーザーリサーチでの引用、行動データ、サポートチケット、市場トレンドなどが該当します。有力なオポチュニティには、複数のエビデンスソースがあります。

  4. ソリューションをブレインストーミングする 各オポチュニティに対して、潜在的なソリューションを 2~4 個考えます。この段階では、アイデアを自ら制限しないでください。ソリューションは、すぐに試せる実験から大規模な機能まで幅広く考えられます。評価できる程度に具体的にします。

  5. 仮説の検証方法を定義する 有望な各ソリューションについて、最もリスクの高い仮説を特定し、それを検証するための手軽な実験を設計します。適切な検証では、ソリューションが実際にそのオポチュニティに対応できるかどうかを確かめます。

  6. ツリーの優先順位を付ける すべての枝が同じ重要度というわけではありません。期待されるインパクト、確信度、労力を基に、最初に取り組むオポチュニティとソリューションを示します。このツリーは学びに応じて反復する、更新し続けるドキュメントです。

  7. 構造を可視化する 最上位に成果、その下にオポチュニティ、各オポチュニティの下にソリューション、末端に実験を配置したツリー図を作成します。

出力形式

出力を構成する際は、references/TEMPLATE.md のテンプレートを使用してください。完成したツリーでは、テンプレートのすべてのセクション(Desired Outcome、Visual Tree、Opportunity Branches、Prioritization、Experiments Backlog、Learning Log、Next Steps)を記入します。

品質チェックリスト

最終版を作成する前に、次の点を確認してください。

  • 成果が測定可能で、プロダクトチームが影響を与えられる範囲にある
  • オポチュニティが顧客中心である(機能ではなく、ニーズや問題になっている)
  • 各オポチュニティを裏付けるエビデンスが記録されている
  • 各オポチュニティに複数のソリューションがある(1 つに飛びついていない)
  • 仮説が明確に示され、実験が設計されている
  • 優先順位が明確である(最初にどの枝を探索するか)

例

完成例については、references/EXAMPLE.md を参照してください。

コメント