Opportunity Solution Tree

Opportunity Solution Tree は、顧客の機会と解決策をつなげて考えるための可視化手法です。Teresa Torres の継続的ディスカバリーの文脈でよく知られています。

プロダクト開発では、アイデアがいきなりバックログに入ることがあります。「この機能がほしい」「競合がやっている」「営業で必要と言われた」といった理由で、解決策だけが増えていきます。Opportunity Solution Tree は、そのアイデアがどの顧客機会に対応しているのかを見えるようにします。

構造

基本構造は、上から順に次のようになります。

  • Outcome: 達成したい成果
  • Opportunity: 顧客の課題、ニーズ、欲求
  • Solution: 解決策のアイデア
  • Experiment: 検証方法

最上位には、チームが追いかけるアウトカムを置きます。たとえば「新規ユーザーの初回設定完了率を上げる」といったものです。

その下に、顧客の機会を並べます。「設定項目の意味がわからない」「どこまで入力すればよいかわからない」「社内確認が必要で止まる」などです。

さらにその下に、解決策を置きます。「入力例を表示する」「下書き共有をできるようにする」「必須項目を後回しにする」などです。

何がよいのか

このツリーを作ると、解決策の比較がしやすくなります。同じ機会に対して複数の解決策を並べることで、いきなり最初のアイデアに飛びつかずに済みます。

また、チーム内の会話が「その機能は必要か」から「その機会は重要か」「この解決策は他の案よりよいか」に変わります。議論の土台が顧客の状況に戻るのです。

使うときの注意

Opportunity は、単なる機能要望ではありません。「CSV出力がほしい」は Solution です。その裏にある「既存の承認資料に貼り付ける必要がある」「他部署と同じ形式で比較したい」が Opportunity です。

また、ツリーをきれいに作ることが目的ではありません。顧客から新しい学びが得られたら、機会を足し、解決策を消し、検証結果を書き込みます。ツリーは成果物ではなく、意思決定の道具です。

最初の一歩

最初から大きなツリーを作る必要はありません。ひとつのアウトカムを選び、顧客インタビューやサポートログから10個程度の Opportunity を出すだけでも十分です。

プロダクトの議論が機能名ばかりになっているとき、Opportunity Solution Tree は、顧客の問題に戻るためのよい地図になります。