Opportunity Solution Tree（オポチュニティ・ソリューション・ツリー）

このツリーは上から下へ4つの階層で読みます。根には単一の望ましいアウトカムが置かれます——アクティベーションを高める、価値到達までの時間を短縮するなど、チームが追いかけている測定可能な目標です。その下にオポチュニティが枝分かれします。継続的ディスカバリーによって明らかになった、顧客自身の言葉で表現された顧客のニーズ、痛み、望みです。各オポチュニティの下には候補となるソリューションがあり、各ソリューションの下には、そのソリューションが実際にオポチュニティを動かすかどうかを検証する仮説テストや実験があります。

この構造は意図的にツリー(木)であり、リストではありません。単一のアウトカムが多数のオポチュニティに枝分かれし、各オポチュニティが複数のソリューションに、各ソリューションが複数のテストに枝分かれします。この枝分かれによって、チームは各階層で1つ以上の選択肢を保持することを強いられます。これは、最初にもっともらしく聞こえたアイデアにコミットしてしまうことへの解毒剤です。

このツリーの役割は、ディスカバリーの意思決定を可視化し、異議を唱えられるようにすることです。すべてのソリューションは上にたどればオポチュニティに、すべてのオポチュニティは上にたどればアウトカムに行き着くため、誰でも「これはどの顧客ニーズに応えているのか、そのニーズはどの目標を動かすのか?」と問うことができます。これらの質問に答えられない機能は、スプリントを消費する前に孤立した作業であることが露呈します。

また、優先順位付けの考え方も変わります。フラットな機能のバックログを順位付けするのではなく、チームはまずアウトカムに対してオポチュニティを比較します——どのニーズが解決されればアウトカムを最も動かすかを評価し——選ばれた枝の中でのみソリューションを探索します。Torresはこれを「ソリューションではなくオポチュニティを比較する」と呼び、これによってRICEのようなスコアリングフレームワークの誠実さが保たれます。評価対象が既製の機能ではなく、本物の顧客ニーズであることが保証されるためです。

最も一般的な失敗は、ソリューションをオポチュニティに偽装して書くことです。「Slack連携を追加する」はソリューションです。本当のオポチュニティは「メンションが別のツールにあるため見失ってしまう」です。オポチュニティの階層が機能で埋め尽くされると、ツリーはバックログへと崩壊し、その比較の力は失われます。オポチュニティは、特定の1つの解決策とは区別された、顧客の言葉で、顧客のニーズとして表現される必要があります。

2つ目の失敗は、ツリーを一度きりの成果物として扱うことです。ツリーは、新しいインタビューの証拠が届くたびに毎週進化するべきものです——枝が追加され、剪定され、重み付けが見直されます。1か月変化していないツリーは、通常ディスカバリーが静かに止まっている印です。3つ目の落とし穴は、実験の階層を完全にスキップし、あるオポチュニティの下で最初のソリューションをそのままリリースしてしまうことです。これは、この構造が強制するはずの選択肢生成を放棄することになります。

Opportunity Solution Treeは、各枝の下にある証拠の信頼度に応じてのみ信頼できます。実際には、その証拠——インタビューのメモ、サポートチケット、利用状況の信号、それを提起したアカウントの背後にある収益——は通常別々のツールに存在するため、オポチュニティは本物のニーズから推測へと漂流しがちで、アウトカムは実際のアカウントの挙動との結びつきを失います。

AIOProductOSのようなプロダクトOSは、その証拠を共有の基盤上で結びつけ可能な状態に保ちます。そのInsightsフィードは、フィードバックをCustomer-360レコードとその背後にある収益の隣に表示するため、あるオポチュニティが枝を得るに値するかどうかを、それを提起した有償アカウントを示すことで判断できますし、根にあるアウトカムはスライドに貼られた数字ではなく、実際のプロダクト分析に対して追跡できます。ツリーはあくまでディスカバリーのツールであり続け、基盤はその下の証拠を最新の状態に保ちます。