オポチュニティ ソリューション ツリー: 製品発見のための視覚的なツール

公開: 2023-06-01

この製品発見作業を推進する 1 つの方法は、Opportunity Solution Tree (OST) と呼ばれるメンタル モデルを使用することです。 製品チームが価値を効果的に発見して獲得できるように、機会ソリューション ツリーとは何か、その使用方法、OST の例、OST を分析や実験に接続する方法について説明します。

重要なポイント

  • 製品発見では、定性的洞察と定量的分析を組み合わせて、解決すべき価値の高い顧客のニーズを判断します。
  • オポチュニティ ソリューション ツリーは、製品チームが顧客のニーズの主要な領域に集中するのに役立ちます。
    • 指標により発見がビジネス関連領域に制限される
    • 機会は解決すべき顧客の問題を特定します
    • ソリューションのアイデアは、顧客価値を創造するための仮説を提供し、
    • テストと実験は、ソリューションのアイデアを検証または反証します。
  • オポチュニティ ソリューション ツリーのビジュアル フレームワークを分析および実験スタックに接続することで、製品チームはより迅速に価値を提供できます。

製品発見とは何ですか?

製品発見は、チームが顧客のニーズを明らかにし、明確にするために使用する一連のプロセスです。 顧客が経験している問題の種類を理解することで、価値を生み出すソリューションの種類に優先順位を付けることができます。 製品発見は、製品開発プロセス全体の重要なサブセットであり、製品チームがどの製品アイデアを追求し、どれを脇に置くかについて情報に基づいた決定を下すのに役立ちます。

製品発見には、顧客へのインタビュー、顧客のシャドウイング、調査、顧客からのフィードバック、プロトタイプのテストが含まれます。 製品の発見は定期的かつ頻繁に行う必要があります。 言い換えれば、発見は単に四半期ごとに行われるべきではありません。 むしろ、それは毎日、すべての製品ポッド内で、小さな継続的な増分で行われる必要があります。

顧客中心の製品発見により、何が顧客にとっての価値を生み出すのかを最大限に理解し、継続的に学習しながらリアルタイムでアプローチを更新することができます。

しかし、製品発見は顧客のニーズをビジネス価値に変えるための鍵である一方で、この重要な作業は経営陣や部門横断的な関係者によって批判されたり、優先順位が下げられたりすることがあります。 なぜこれが起こるのかを見てみましょう。

製品の発見が採用の課題に直面する可能性があるのはなぜですか?

ほとんどのリーダーや関係者は原則として製品発見に反対しませんが、多くの製品チームは依然として製品発見の実践において採用の課題に定期的に直面しています。

これは、多くのリーダーが方向性のない発見に不快感を抱いているためです。 つまり、製品チームが「名所を見て回る」ために「探索サファリ」に出かけることがあまりにも頻繁であり、そのためリーダーは、この調査がビジネス価値を高めるのに十分なターゲットを絞っているかどうか疑問を抱くことになります。

具体的には、リーダーは次のような質問に対する答えを求めています。

  • 発見によって重要なビジネス指標が変化することをどのようにして知ることができるでしょうか?
  • この発見作業にはどれくらいの時間がかかり、どれくらいの費用がかかりますか?
  • この投資が利益をもたらすかどうかはどうやってわかりますか?

Product Teacher でのコーチング実践では、多くのプロダクト マネージャーが最初はこれらの質問に事前に対処できず、不必要な摩擦や緊張を引き起こしていることがわかりました。 私たちは、顧客の組織内の作業プロセスに機会ソリューション ツリーを導入することで、製品チームが顧客主導の発見を提唱することに成功する可能性が大幅に高まることを発見しました。

それでは、オポチュニティ ソリューション ツリーとは何なのか、そしてそれが組織のすべての部分にどのように価値を提供するのかを詳しく見てみましょう。

オポチュニティ ソリューション ツリー (OST) とは何ですか?

オポチュニティ ソリューション ツリー フレームワークは、スタンフォード大学のデザイン教授によって最初に設計されました。 2016 年、Product Talk の創設者である Teresa Torres は、このフレームワークを製品発見プロセスに適用しました。

すべての機会ソリューション ツリーには、次の 4 つの主要なコンポーネントが含まれています。

  1. 指標: 発見のガイドとなるビジネス関連の指標
  2. 機会: 顧客が抱える問題点
  3. ソリューションのアイデア: 製品チームとして顧客の痛みに対処できる考えられる方法
  4. テスト: ソリューションを検証または無効にするために実行できる実験。これにより、機能のリスクを軽減し、反復的な価値を迅速に提供できるようになります。

以下に、機会ソリューション ツリーがどのようなものになるかを示す例を示します。 指標を青、機会を緑、ソリューションのアイデアを黄色、実験をオレンジに色分けしました。 それぞれのテキストを読む必要はありません。この例については後のセクションで詳しく説明します。

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

Torres が機会ソリューション ツリー モデルを作成したのはなぜですか? 彼女は、製品発見を通じて製品チームをトレーニングする際の観察に基づいてこれを行いました。 彼女は、チームが発見作業をガイドし、提案されたソリューションと発見された顧客の課題を調整し、部門を越えて賛同を確保するための視覚的な構造が必要であることに気づきました。

トーレス氏は、スタンフォード大学バーニー・ロス教授が教えたテクニックを参考にした。 ロス教授は、人々が望む解決策がその根底にあるニーズや問題点とどのように結びついているのかを尋ねた後、同じ問題点を解決するためのさまざまな潜在的な解決策を考え出す「発散解決」を行うよう参加者に求めました。

このツリー状の一連の質問を機会ソリューション ツリーの視覚的なグラフとして構成することで、製品チームが顧客の痛みに真に対処するソリューションを主張する可能性がはるかに高くなることがトーレス氏は発見しました。

オポチュニティ ソリューション ツリーはディスカバリーの導入をどのように改善しますか?

重要なことは、機会ソリューション ツリーの視覚化は、プロダクト マネージャー、エグゼクティブ リーダー、および部門横断的な関係者に対して次のことを実行することです。

  • 製品発見のための焦点レンズとしてビジネスクリティカルな指標を確立する
  • 機能のチェックリストを作成するのではなく、顧客の苦痛を解決することに重点を置く
  • 発見の洞察を投資すべき「機会領域」に変換します
  • 対話を「機能の提供」から「迅速な実験」に移行します。
  • 非インタラクティブな社内ブレーンストーミングではなく、実験を顧客の痛みと顧客と一緒に繰り返す反復に結びつける

先ほど、リーダーは製品発見がもたらす可能性のあるビジネス価値と、製品発見に関連する潜在的なコストやリスクを理解することに熱心であると述べました。 発見をビジネス関連の結果にまとめることで、製品チームは、製品発見の洞察が実用的なものになるかどうかについての不安を和らげることができます。

また、機会ソリューション ツリーが整備されていれば、チームは特定のソリューションに対してインデックスを過剰に作成する可能性が大幅に低くなります。 代わりに、どのような機会や顧客の悩みを解決しようとしているのかを時間をかけて検討し、この広い視野を活用してイノベーションを起こし、より効果が高く、より低コストのソリューションを考案し、最終的にはより多くの ROI を生み出します。

オポチュニティ ソリューション ツリーの視覚的な構造は、「最終結果」としての特定の機能の優先順位を明らかに下げ、代わりにビジネス関連の指標を動かすことが本当に重要であるというメッセージを強化します。

したがって、オポチュニティ ソリューション ツリーを組織に導入することに成功した製品チームは、利害関係者が、期限付きの機能の膨大なリストに焦点を当てるよりも、実験に取り組むことにはるかに積極的であることに気づく傾向があります。

オポチュニティ ソリューション ツリーはどのように機能しますか?

機会ソリューション ツリーの 4 つの主要なコンポーネントをそれぞれ分解し、それぞれのベスト プラクティスについて説明します。

メトリクス

仕事がビジネスの成功に直接結びつくように、オポチュニティ ソリューション ツリーの指標は、OKR (目標と主要な結果) の KPI (主要業績評価指標) と一致している必要があります。 この指標は、製品発見を行うためのレンズです。

言い換えれば、指標を動かさない顧客との会話や製品発見の取り組みは考慮すべきではありません。 指標を変更する可能性が実際にある取り組みや取り組みのみを積極的に調査する必要があります。

しかし、適切な指標を選択するにはどうすればよいでしょうか? 優れた指標では、「ビジネスの成功」と「製品への近さ」の間の緊張のバランスをとる必要があります。

指標が製品から遠すぎる場合 (全社の収益や全社の利益など)、製品チームは発見の取り組みにおいて何らかの真の焦点を当てるのに苦労するでしょう。 理論的には、どのような取り組みも収益増加またはコスト削減の手段として正当化される可能性があります。

また、指標が製品に近すぎる場合 (機能のクリック率など)、チームは特定のソリューションに重点を置きすぎ、顧客の痛みやビジネスの方向性を変える投資機会に十分に焦点を当てていません。

優れた指標では、顧客のために生み出された価値と、その価値がビジネスのために獲得されたことを追跡する必要があります。 例には、プラットフォームの使用時間や月間アクティブ ユーザーなどが含まれる場合があります。

機会

私たちがどのような指標を追い求めているかを知っているからといって、顧客がどのような苦痛を感じているかを知っているわけではありません。 多くの場合、ウォーターフォール指向のチームは、顧客の悩みを顧客から学ばずに、「会社の四方の壁の内側」でアイデアを思いつきます。

機会は、顧客に新しい価値を生み出すと同時に、企業がその価値を使用状況、収益、紹介、その他の関連するビジネス推進要因の形で獲得できるようにする必要があります。

製品チームは、以下のいずれかを活用して機会を特定できます。

  • インバウンド顧客のフィードバック
  • アウトバウンド 1:1 面接
  • アウトバウンド調査
  • 製品データ分析
  • 社内関係者とのディスカッション (サポート、マーケティング、販売など)

この概念をより具体的にするために、Google が提供する電子メール受信箱である Gmail について考えてみましょう。

チャンスは「より優れたスパム フィルターが欲しい」ということではありません。 これは解決策のアイデアですが、私たちはどの問題を解決するかではなく、何を構築するかに耳を傾けるという罠にはまってしまいました。

「より優れたスパム フィルターが欲しい」という機能のアイデアを考慮すると、これは実際には、次のようなさまざまな根本的なユーザーの苦痛を示している可能性があります。

  • 特定のメールを見つけるのに時間がかかりすぎる
  • 知らない人からメールを受け取るのが好きではない
  • プレゼンテーション中に電子メール通知が頻繁に邪魔してイライラする

ご想像のとおり、「電子メールをより速く見つける」機会に対処するための一連の可能な解決策と、「電子メールの邪魔をしない」という機会に取り組むための一連の可能な解決策は、互いに大きく異なります。 「より優れたスパム フィルターが欲しい」という同じ機能のアイデアを共有しているのは事実ですが、それはスパム フィルターがどちらかの目的を達成する最良の方法であることを意味するものではありません。

そのため、特定の機能リクエストの背後に表れている真の苦痛を理解するために、定性的な顧客インタビューと定量的な分析を実施することが重要です。

さらに、同僚が機能を提案するときは、その機能を額面通りに受け取るべきではありません。 代わりに、「この機能リクエストは顧客のどのような根本的な悩みを解決するのか?」と尋ねるべきです。 そこから、ソリューションのアイデアの完全なセットを検討することができます。その多くは、最初に提案されたアイデアよりも満足度が高く、構築が容易で、維持が容易である可能性があります。

ソリューションのアイデア

機会を選択したら、設計およびエンジニアリングと連携して、顧客の問題に対処するさまざまな方法を特定します。

  • 多様な考えを持ち、できるだけ多くのアイデアを生み出す
  • 「悪い」アイデアを恐れないでください。良いアイデアが生まれる可能性があるからです。
  • 「何を出荷するか」については、後の実験中に集中します。

デザインは、現実世界で人々が現在この問題にどのように対処しているかを考えるのに役立ちます。 彼らは、競合他社が自社の製品を通じてこの問題をどのように解決しているかを評価することができ、また、顧客が苦痛を軽減するために代替品、代替品、または手動プロセスをどのように使用しているかを特定することもできます。 この 360 度のビューにより、ソリューションのためのより優れたアイデアを思いつくことができます。

エンジニアリングは、この顧客の痛みを、関連する複数のユースケースを含むより広範な痛みに抽象化できるかどうかを判断するのに役立ちます。 場合によっては、多くの問題がユーザー レベルではまったく無関係に見えるかもしれませんが、システム レベルでは一気に簡単に解決できる場合があります。

たとえば、あなたが Asana や Trello などのプロジェクト管理プラットフォームを担当しているとします。 ユーザーの中には、どのタスクが期限を守れない可能性があるのか​​を知りたいと考えている人もいます。 ユーザーの中には、一部の担当者に仕事の負担がかかりすぎているかどうかを知りたいと考えている人もいます。 ユーザーの中には、どの部門が最も多くのタスク要求を行ったかを把握したいと考えている人もいます。 また、どのグループが最も多くのタスクを完了したかを知りたいユーザーもいます。

これらはすべて、ユーザーの痛みの観点からはまったく別のものに見えますが、エンジニアリングでは、根底にあるユーザーの痛みが「各タスクについてすでに持っている属性に基づいて物事を簡単にグループ化したりフィルターしたりできない」ことであると特定できます。 そして、その視点から、エンジニアリングは、単一のユーザーでは提案できなかった非常に柔軟なソートおよびフィルター システムを提案できます。

最後に、部門を超えたパートナーからフィードバックを求めることを恐れないでください。 結局のところ、彼らはあなたが検討できるようにすぐに利用できる機能リクエストを持っているかもしれません。

ただし、前に述べたように、ソリューションのアイデアについて部門を超えたフィードバックを受ける場合は、それらのアイデアが、優先順位を付けて選択した機会領域に実際に適合していることを確認する必要があります。 取引を成立させたり、特に声高に主張する顧客を満足させるためのソリューションのアイデアにただ取り組むだけではなく、必要最小限のリソースを使用して、可能な限り最速の時間で最大限の価値を提供したいと考えています。

テストと実験

優れた ROI を達成するには、ソリューションのアイデアをそのまま完全に出荷すべきではありません。これは高価でリスクが高いためです。 各ソリューションには複数の基礎となる仮定があり、適切に設計された低労力の実験を通じてこれらの仮定をそれぞれテストする必要があります。 このアプローチにより、リスクが軽減され、学習が促進され、最終的に ROI が向上します。

たとえば、Ironclad のような契約ソフトウェア プラットフォームを担当しており、AI/ML に基づいて関連する契約条件を自動的に組み込む機能を出荷したいとします。 レコメンデーション システム全体を一度に構築するのではなく、この取り組みを小さな部分に分割してリスクを回避する必要があります。

仮定の 1 つは、「弁護士は提案を契約書に組み込む前に検討したいと考えている」というものかもしれません。 そうであれば、私たちが提供する UI は、弁護士が提案されている契約条項を確認し、受け入れるか拒否するかを選択できるようにする必要があります。

しかし、「弁護士はこれを自動的に入力してくれるソフトウェアに慣れており、明白な提案を何十も検討するのは限られた時間の無駄だ」という仮定があるのであれば、この UI を構築すべきではありません。

これをどのようにテストすればよいでしょうか? 弁護士と一緒に「機械の中の人」テストを実施して、契約条項が見られずに挿入されることに彼らが満足しているかどうかを確認することもできます。

テストする必要があるかもしれないもう 1 つの仮定は、「契約条項はさまざまな種類の契約間で一貫している」ということです。 これは真実ではないかもしれません。 契約によっては、挿入前に条項の編集が必要になる場合があります。 その場合、ここでも実験を実行したいと思います。

実験ごとに、次のことを行ったことを確認する必要があります。

  • 当社の顧客、競合他社、および当社が使用しているテクノロジーに関する暗黙的および明示的な仮定をすべて特定する
  • 成功したと判断するために「メトリクスがどの程度変動するか」についての事前のしきい値を作成します。
  • 実験のパフォーマンスに基づいて、事前に決められた次のステップの草案を作成し、仮説が検証された場合に行うべきことと、仮説が反証された場合に行うべきことをカバーします。

ソリューションのアイデアに対して実行したいさまざまな実験にどのように優先順位を付けるのでしょうか? 一般に、次の 3 つの要素を念頭に置いて優先順位を付けます。

  1. 包括的な OST 指標を最も大きく動かす実験はどれですか?
  2. どの実験が最大の仮定のリスクを軽減するでしょうか?
  3. 最も時間と労力がかかる実験はどれでしょうか?

オポチュニティ ソリューション ツリーを使用する場合

機会ソリューション ツリーのポイントは、企業が投資できる潜在的な機会領域を整理することです。 言い換えれば、顧客のために解決できる実行可能な問題点を分類します。

したがって、機会ソリューション ツリーは、四半期レベルでロードマップを作成する場合でも、年次レベルでロードマップを作成する場合でも、あらゆる種類のロードマップ作成作業への入力として使用する必要があります。 結局のところ、顧客がどのような問題点を抱えているかが分からなければ、効果的なロードマップを構築することはできません。

オポチュニティ ソリューション ツリーは、特にこれらの提案を経営陣に提示する予定の場合、製品提案を組み立てるのにも非常に役立ちます。 重要な主要指標について経営陣との連携を確保し、利用可能なさまざまな機会を協力して発見するスペースを提供することで、考えられるソリューションをより効果的に反復し、より少ない労力と時間でより多くの価値を提供できるようになります。 。

多くの製品チームはオフサイトで定期的な製品戦略を実行しています。 次回オフサイトの戦略に参加するときは、オフサイト終了後に参加者全員に実行可能な次のステップとして「機会ソリューション ツリー」を提案することを検討してください。

また、将来のオフサイト戦略については、チームが積極的に取り組んでいる現在の OST のレビューから始めるよう主催者に依頼することを検討してください。 そうすることで、すべての出席者は、今後の機会スペースと、それらの機会への取り組みにおける進捗状況を共有することができます。

オポチュニティ ソリューション ツリーの実世界の例

この概念を具体化するために、実際の機会ソリューション ツリーの実例を考えてみましょう。 Web サイトビルダー (Squarespace、WordPress、Wix など) である B2B 製品内の検索機能を強化する責任があるとします。

あなたは、成功の指標を「顧客ごとに、週ごとに完了した検索の平均数」と定義しているかもしれません。 つまり、検索機能が顧客に価値を提供している場合、顧客のエンド ユーザーが他の競合ソリューション (Google カスタム検索など) の機能ではなく、あなたの検索機能をますます使用するようになると予想されます。

ユーザー調査と顧客からのフィードバックを通じて、私たちは 3 つの主要な改善の機会があることを発見したかもしれません。

  1. 現在、機能内の検索結果を選別するのは非常に困難です
  2. ユーザーは検索結果が返されるまで長時間待たなければならず、イライラします。
  3. 多くのユーザーは、クエリに「ローカル」の場所ベースのキーワード (「ニューヨーク」や「サンディエゴ」など) を追加しています。これは反復的で面倒ですが、正確な結果を得るには必要です。

以下のような機会ソリューション ツリーを思いつくかもしれません。

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

営業、マーケティング、カスタマー サクセス、カスタマー サポート、設計、エンジニアリングとのディスカッションを通じて、3 つの機会それぞれについて考えられるソリューションのアイデアを特定する必要があります。

そして、どのようなアイデアであっても、最初から最後まで単にそのアイデアを出荷するのではなく、テスト可能な仮説と実験を作成して、アイデアのどの側面が最も価値があるかを特定します。

たとえば、ユーザーが検索結果を簡単に選別できるようにしたい場合、説得力があると思われるアイデアの 1 つは、結果のプレビューをユーザーに表示することです。

ただし、「結果プレビュー」は非常に広範囲にわたります。 プレビューの魅力とは一体何でしょうか?

「すべての結果はユーザーによってレビューされるべきである」という前提をテストしたいとします。 その場合、返されたすべての結果に独自のテキストベースのプレビューが関連付けられた実験を開始します。

しかし、この仮定の裏返し、つまり「ユーザーはただ 1 つの最良の結果をできるだけ早く望んでいるだけである」ということをテストすることもできます。 また、ページの上部にある「最も関連性の高い」テキスト スニペットを 1 つ強調表示して実験を実行したいと考えています。

そして、テキストが実際に前進する最善の方法であることをどうやって知ることができるのでしょうか? ユーザーが Pinterest や Instagram のような画像に特に興味がある場合はどうすればよいでしょうか? その場合、テキストベースのリンクを表示する代わりに、検索結果として画像ベースのスナップショットを表示する実験を実行する必要があります。

OST と製品戦略の相互作用

オポチュニティ ソリューション ツリーは、2 つの主要な方法で製品戦略と相互作用します。

まず、OST 手法は製品戦略を補完し、強化します。 結局のところ、OST に対して選択された指標は特定された製品戦略と一致している必要があるため、すべての OST は製品戦略から始まります。

第 2 に、機会ソリューション ツリーは、検証または反証された仮説と、実験から新たに発見された洞察に基づいて、製品戦略に情報を提供し、影響を与えます。

経験則として、3 回の実験ごとに製品戦略を改良します。 各実験を完了する際には、定期的に次の質問をしてください。

  • 特定された顧客セグメントは依然として追求するのに適切なものでしょうか?
  • その機会は当初考えていたよりも大きいのでしょうか、それとも小さいのでしょうか?
  • 市場へのアプローチは容易になりましたか、それとも難しくなりましたか?

OST を通じたステークホルダーとの連携と協力

人々は自分が持っているコンテキストに基づいて意思決定を行い、同じコンテキストがあれば、合理的な人々も同じ意思決定を行います。

意見の相違に直面した場合は、次のいずれか (または両方) が発生していると考えられます。

  • 同意しない人はあなたの文脈を理解していません
  • あなたには、反対する人が持つような文脈がありません

オポチュニティ ソリューション ツリーを使用すると、顧客の学習から始まり、次に何を出荷するかという結論に至るまで、関係者や経営幹部を発見の旅に同行させることができます。

組織内で機会ソリューション ツリーを設定する方法を詳しく見てみましょう。 このハンドブックは、当社がフォーチュン 500 企業と実施したチーム ワークショップと、当社が将来性の高い製品リーダーに提供する 1 対 1 のエグゼクティブ コーチングに基づいています。

以下で説明します。

  1. 最初の OST を確立する方法
  2. 既存の OST を成熟させる方法
  3. 新しい OST に向けて方向転換する方法

最初の OST を作成する

組織内に新しい作業プロセスや思考のフレームワークを導入するときは常に、リーダーや部門横断的な対応者の賛同を確保する必要があります。

このサポート構築のステップを詳しく分析すると、最も成功しているプロダクト マネージャーは、製品発見の実践に向けて関係者を調整するために少なくとも 4 回の会議を使用する傾向があることがわかりました。 4 つの会議と、それぞれの会議で取り上げられるトピックは次のとおりです。

  1. 指標の調整: 主要なビジネス指標に合わせて調整し、長期的には発見がウォーターフォールよりも良い結果にどのようにつながるかについて話し合います。
  2. 機会の探索: 顧客のフィードバックに基づいて一連の最初の機会領域を検討し、関係者にも機会を共有するよう招待します。
  3. 機会の選択: まず開始する機会を共同で選択し (どれが「正しい」か「間違っている」かではありません)、意思決定プロセスを一緒に文書化します。
  4. 解決策のアイデア作成: さまざまな解決策を共同でアイデア出し、実験を通じてどの初期解決策を探索するかについて合意します。

結果よりもその過程の方が重要なので、このような会議を急いで終わらせる必要はありません。 特定の利害関係者が沈黙している、敵対的である、または単に混乱していることがわかった場合は、これらの会議の外で時間をかけて 1 対 1 で対話してください。 彼らの懸念が何であるかを理解し、彼らと協力してそれらの懸念に対処します。

また、関係者を同行させるには 4 回以上の会議が必要になる場合があります。 とはいえ、同じ会議に複数のトピックを詰め込むことはお勧めしません。疲労、集中力の低下、関係者の不満を引き起こす傾向があるためです。

余談ですが、ステークホルダーの好みをより広範囲にナビゲートする方法についてさらに詳しく知りたい場合は、毎月録​​画された PM クラスの一部として 1 時間の講義を録画しました。

本題に戻ります。これで、最初の機会ソリューション ツリーが配置されました。 しかし、これで終わりではありません。実験のアイデアを考える必要があり、実験の進行状況や全体的な指標の動きを関係者と共有する必要があります。

既存の OST の熟成

各実験のアイデアを作成するときに、OST を更新して、各実験でどのソリューションのアイデアに取り組んでいるかを特定します。 可能な場合は、テストしたい仮説についての 1 文の説明を実験に注釈として付けてください。

次に、実験が終了したら、各実験の結果を OST にも表示します。 検証された仮説にはチェックマークを使用し、無効な仮説には X を使用できるため、関係者は特定のメトリック結果の詳細に入ることなく、進捗状況をすぐに確認できます。

実験の解決速度に応じて、1 ~ 2 週間ごとに最新情報を関係者やマネージャーにブロードキャストしてください。 そうすることで、発見の取り組みが実を結んでいること、そして単に顧客と話すために顧客と話をしているわけではないことを証明することになります。 代わりに、発見作業により、ビジネス指標が積極的に前進します。

最初の 2 ~ 3 回のブロードキャストでは、ライブ会議と組み合わせることもできます。 これらのライブ会議では、機会ソリューション ツリーの目標は、製品発見の取り組みがビジネス指標を確実に動かし、機能ではなく実験を出荷していることを確認することであることを要約する必要があります。

各会議では、優先順位を付けた機会や検討中の解決策のアイデアについて質問できるスペースを関係者に与えます。 そうすることで、彼らは製品の意思決定プロセスに積極的に参加し、顧客が取り組むべき問題や解決策のアイデアについてアイデアを提供できるようになります。

また、利害関係者が指標や以前に特定された機会領域と一致しない特定の機能を推進する場合は常に、その機能が優先順位の高いビジネス成果を動かす可能性は低いことを穏やかに、しかししっかりと説明することができます。

これらの会議を通じて関係者の信頼を獲得したら、更新情報を非同期で送信して、時間と労力を節約できます。 そうは言っても、OST に追加する質問、懸念、提案、または新しいアイデアがある場合、関係者が連絡できる、また連絡すべきであるという明確な期待を必ず設定してください。

新しいOSTへの移行

四半期ごとに、同じ OST を使い続けるか、新しい OST に切り替えるかを決定する必要があります。 結局のところ、すべての OST は限界収益が減少することになります。たとえば、コンバージョン率が 100% を超えることはありません。

初期の指標をターゲットにしても最高の ROI が得られないと判断した場合は、新しい OST を開始するための新しい指標を特定する必要があります。 その時点で、「最初の OST の確立」で説明した OST ワークフロー全体を再開する必要があります。

ただし、利害関係者は OST の背後にある基本的な概念をよく理解しているはずなので、プロセスを少し加速することができます。 ビジネス指標、機会スペース、および焦点を当てる 1 つの機会について調整するには、1 ~ 2 回の会議だけで十分です。

焦点を当てるべき機会領域を確保したら、追加の入力なしでソリューションや実験を実行できるはずです (時間をかけて利害関係者と十分な信頼を築き上げ、利害関係者の質問が来たときにそれに対処している場合に限ります)上)。

OST を関係者と共有する方法がわかりました。 しかし、実験を実行するときに進行状況を視覚的に追跡するにはどうすればよいでしょうか? 以下に、関連するコンテキストを提供し、製品の発見を最前面に置くビジュアル ダッシュボードを起動する方法のテンプレートを提供します。

OST を分析に接続する

オポチュニティ ソリューション ツリーは、分析機能と自然にうまく組み合わされます。 結局のところ、特定のソリューションのパフォーマンスを分析しない限り、そのソリューションがビジネスにとって有意義な進歩をもたらしたかどうかはわかりません。また、偏りのない実験を正確に作成できない限り、ソリューションを出荷すべきかどうかもわかりません。

分析を通じて機会ソリューション ツリーを実現する方法の例として、Amplitude Notebooks を使用してその方法を説明します。

特定の機会ソリューション ツリーの Amplitude Notebook を作成します。 このノートブックは、情報の一元的なハブとして機能します。

ノートブックの一番上にあるのは、製品発見の取り組みを通じて進めようとしている主要な結果である必要があります。 そうすることで、実験の取り組みに基づいて、重要な結果が実際に時間の経過とともに改善されているかどうかを確認できます。

その直後に、機会ソリューションのツリー図を主要な結果ダッシュボードの下に画像として追加します。 この図は、Miro などのあらゆる種類の作図ツールで作成できます。

その後、これまでに行った各実験をリストアップします。 これらの実験には、機会ソリューション ツリーでターゲットとしている特定の機会のラベルを付ける必要があります。

ノートブックの最後には、機会ソリューション ツリーを具体化するために実施したすべての顧客インタビューと顧客調査にリンクする付録を含める必要があります。 そうすれば、取り組むことを決めた機会の証拠と証拠が得られます。

最後に

オポチュニティ ソリューション ツリーを使用することにより、製品計画プロセスのすべての段階で継続的な製品発見を織り込んでいます。 また、利害関係者が製品発見を活用できるようにするには、機会ソリューション ツリー フレームワークを使用する必要があります。

次の 3 つの原則を念頭に置いている限り、特定の状況やニーズに合わせてプロセスや用語を微調整する権限が与えられていると感じる必要があります。

  1. 製品の発見はビジネス目標を達成する必要があります。
  2. 製品チームのポイントは、任意の期限までに機能を出荷することではなく、顧客の痛みに対処するソリューションを反復することです。
  3. 私たちはチームとして、四半期や年次のペースを待つのではなく、顧客の学習やフィードバックにリアルタイムで対応できなければなりません。

利害関係者や経営幹部に機会ソリューション ツリーを紹介すると、慣れるまでに時間がかかります。 しかし、彼らを旅に連れて行けば、彼らが私たちの製品決定とより一致していることがわかります。 さらに良いことに、彼らは積極的なコラボレーターや貢献者となり、あなたが想像しているよりも多くのアイデアや顧客のコンテキストを共有してくれるでしょう。