テレサ・トーレスのリーダーシップスタイル：継続的ディスカバリー、オポチュニティ・ソリューション・ツリー、そしてアウトカム駆動のプロダクト業務

ほとんどのプロダクトチームは、ディスカバリーをまとまった単位で行います。リサーチスプリントを実施し、調査結果をまとめ、レポートを引き継いで、そのまま次に進んでしまうのです。テレサ・トーレスは長年プロダクトチームをコーチングする中で、このやり方がほとんどうまくいかないことに気づきました。理由はリサーチの質が悪いからではなく、ディスカバリーと意思決定の間のギャップがあまりに大きいからです。

彼女の継続的ディスカバリーのフレームワークは、そのギャップを埋めます。

主要事実： テレサ・トーレスはプロダクトディスカバリーのコーチであり、『継続的ディスカバリーの習慣』(Product Talk Press、2021年)の著者、オポチュニティ・ソリューション・ツリー手法の考案者です。Product Talkを通じて、Spotify、Atlassian、Ancestryなど500以上のプロダクトチームに継続的ディスカバリーを指導してきました。Mind the ProductやProductConでも頻繁に基調講演を行っています。

トーレスの継続的ディスカバリー・ドクトリン

オポチュニティ・ソリューション・ツリーは、望ましいプロダクトのアウトカムを顧客のオポチュニティ、候補となるソリューション、そして各ソリューションが前提とする仮説に結びつける、視覚的なディスカバリーの成果物です。トーレスのドクトリンは、このツリーを、プロダクトトリオ(PM、デザイナー、エンジニア)が実施する、絶対に譲れない毎週の顧客インタビューの習慣と組み合わせます。この二つが揃うことで、ディスカバリーは定期的なリサーチプロジェクトから、配信のコミットメントが固まる前に仮説を更新し続ける継続的な習慣へと変わります。

オポチュニティ・ソリューション・ツリーは、目新しい方法論ではありません。それは、ある特定の失敗パターン、つまり自分たちが解決しようとしている顧客課題を明確に言語化できないままリリースしてしまうプロダクトチームへの、構造的な回答です。トーレスは10年をかけてProduct Talkをコーチングと執筆のプラットフォームとして築き上げ、プロダクトマーケットフィットは確立しているもののプロダクトプロセスがまだ未成熟なB2B SaaS企業のPMチームと直接向き合ってきました。

自社のPMが問題解決者というよりプロジェクトマネージャーに近い状態にあるなら、トーレスの仕事は、今いる場所とマーティ・ケーガンが「あるべきだ」と説く場所との間を結ぶ、最も明確で実践的な道筋になります。彼女は、ケーガンが描くビジョンを実際に運用可能な形にする人物です。

リーダーシップスタイルの内訳

この比重の分け方は、プロダクト論の正典におけるトーレスの立ち位置をよく表しています。ケーガンが組織のアーキテクチャを提供し、トーレスが毎週の実践を提供する。彼女のコーチング・コホートと『継続的ディスカバリーの習慣』の構成は、ケーガンの診断を受け入れたうえで、それに対して何かを行うための具体的な行動システムを必要としているチームのために設計されています。彼女は、権限を持つプロダクトチームのための実装レイヤーなのです。

主要なリーダーシップ特性

テレサ・トーレスをリーダーたらしめた3つの決断

1. コンサルティング会社ではなく、実践重視のプラットフォームとしてProduct Talkを構築する決断

トーレスは、Product Talk(producttalk.org)を、コンサルティングファームやSaaSプロダクトとしてではなく、コーチングと執筆のプラットフォームとして築きました。この違いは、見た目以上に重要な意味を持っています。

コンサルティングファームは、コンサルタントを増やし案件を売ることでスケールします。SaaSプロダクトは、ソフトウェアを作ることでスケールします。実践重視のプラットフォームは、自分の考え方を信頼してくれる実務家のオーディエンスを育て、そのオーディエンスに構造化された学習体験を提供することでスケールします。

Product Talkのモデルは、ブログ記事、コーチング・コホート、オンラインコースを通じて10年かけて築かれました。オーディエンスは、マーケティングによってではなく、具体的で役に立つ考えを一貫して発信し続けることで、徐々に育っていきました。『継続的ディスカバリーの習慣』が2021年に出版された頃には、トーレスの文章を何年も定期的に読んでいたPMやプロダクトリーダーが1万人以上に達していました。

このプラットフォーム型モデルが可能にするのは、特定のオーディエンスに対する深さです。トーレスの読者は、戦略フレームワークを求める経営幹部ではなく、自分の実践を磨こうとしている現場のPMたちです。このオーディエンスの存在が、彼女が築くものの形を決めました。ソートリーダーシップ・ブランドではなく、実務家コミュニティです。コーチング・コホートは、資格認定ではなく実際のチームの実践を軸に組み立てられています。ブログ記事が扱うのは、会社の支援がない中で顧客インタビューをどう実施するか、明確なアウトカムがまだない状態からオポチュニティ・ソリューション・ツリーをどう作るかといった、具体的な課題です。

このモデルが制約するのは、スケールです。トーレスが一度に1万社をコーチングすることはできません。プラットフォームは執筆やコースを通じてより多くの人に届きますが、深いコーチングは時間という制約を受けます。これは意図的なトレードオフです。リーチよりも深さを取る、という選択です。

2. オポチュニティ・ソリューション・ツリーの開発

オポチュニティ・ソリューション・ツリーは、トーレスのフレームワークの中心となる成果物です。望ましいアウトカムを起点に、オポチュニティの領域、ソリューションの領域、そして仮説検証へと、プロダクトディスカバリーを整理していく視覚的なツリー構造です。

構造はこうです。頂点に望ましいアウトカムを置き、そこから顧客のオポチュニティ(対応すればアウトカムに貢献するニーズ、ペインポイント、欲求)が枝分かれし、次に特定のオポチュニティに応えるための提案ソリューションが続き、さらに各ソリューションが前提とする仮説、そして最後に最も重要な仮説を検証する実験へとつながります。ここでの理論的な先駆けはジョブ理論(Jobs-to-be-Done)です。トーレスのオポチュニティの捉え方は、顧客はある「ジョブ」を片づけるためにプロダクトを「雇う」という考え方を直接的な土台としており、彼女のツリー構造は、すべての枝でそのジョブを明示的にします。

手順が多いように感じるかもしれません。しかし実際には、これはたった一つの失敗パターンを解決するためのものです。問題空間をマッピングする前にソリューションへ飛びついてしまう、という失敗です。ほとんどのプロダクトチームは、顧客からの要望、営業のコミットメント、あるいは経営幹部のアイデアといった形でソリューションから出発し、そこから逆算して正当化を行います。オポチュニティ・ソリューション・ツリーは、提案したソリューションを、特定の顧客オポチュニティと望ましいアウトカムに結びつくツリーの枝の上に置くことをチームに求めることで、その近道を可視化します。

ソリューションがどのオポチュニティにも結びつかないなら、それはツリー上に存在する資格がありません。これが構造的な制約です。実践してみると、誰も診断していない問題に対してソリューションを作ってしまっているという事実が、しばしば明らかになります。

トーレスは、このフレームワークを視覚的なものにすることに意図的にこだわりました。コーチングを通じて彼女が気づいたのは、チームは抽象論としてはアウトカム駆動のディスカバリーのロジックに同意できても、次の計画会議になるとすぐにソリューション優先の思考に逆戻りしてしまうということです。ホワイトボードやMiroボード上のツリーのように、チームが指し示せる物理的またはデジタルな成果物があることで、口頭での合意だけでは得られない、共有された説明責任の構造が生まれます。シュレヤス・ドシのアンチゴール実践も、別の角度から同じ構造的ロジックを補強しています。どちらのツールも、計画時の楽観論が普段は覆い隠してしまう決断を、明示的に強制するために存在しているのです。

3. 実務家のためのマニュアルとして『継続的ディスカバリーの習慣』を執筆する決断

トーレスは、2021年に『継続的ディスカバリーの習慣』をProduct Talk Pressから出版しました。伝統的なビジネス書出版社ではなく、自分自身のプラットフォームを通じて自費出版するという選択自体が、この本が誰のために書かれたのかを物語っています。リーダーシップフレームワークを求める経営幹部ではなく、現場で実践するPMたちのためです。

本書は、たった一つの絶対に譲れない習慣を軸に構成されています。それは、プロダクトトリオが毎週例外なく、最低1回は顧客にインタビューするというものです。トーレスの主張は、ディスカバリーが失敗するのは、それが始まりと終わりのあるリサーチフェーズ、つまりプロジェクトとして扱われるときだ、というものです。継続的ディスカバリーは、顧客との接点を、スプリントやスタンドアップと同じようにインフラとして扱います。それは、他のすべてがその上に成り立つ、最小限の実践可能な習慣なのです。

この中心的な習慣を軸に、本書はオポチュニティ・ソリューション・ツリーの手法全体を構築していきます。望ましいアウトカムの定義の仕方、ソリューションではなくオポチュニティを引き出すインタビューの仕方、ツリーの構築と維持の仕方、協働でのソリューションの生み出し方、そしてソリューションを最もリスクにさらす仮説の特定と検証の仕方です。

「プロセス」や「方法論」ではなく「習慣」という枠組みを選んだことは、意図的なものでした。トーレスは行動科学の研究(ジェームズ・クリアの著作を引用しています)を土台に、継続的ディスカバリーを定着させる方法はプロセスの展開ではなく、個人とチームのレベルでの習慣形成にあると論じています。この枠組みは本の構成にも影響しており、各章はプロセスのステップではなく、特定の習慣を扱っています。

その結果生まれたのは、ほとんどのプロダクトマネジメント書籍とは読み味の異なる一冊です。理想の状態を描写することよりも、月曜日に何をするかを語ることに重きが置かれています。

テレサ・トーレスならあなたの立場でどう動くか

CEOであれば、トーレスからの最も重要なメッセージは、「顧客主導」であるということが構造的には実際に何を求めるのか、という点です。多くの企業は、NPS調査を行っていたり、四半期ごとに顧客諮問委員会を開いていたりすることを理由に、自分たちは顧客主導だと信じています。しかしトーレスの主張は、そうした仕組みは、プロダクトを作るチームと、そのプロダクトを届けようとしている顧客との間に、距離を置きすぎてしまうというものです。顧客諮問委員会が教えてくれるのは、用意された場で顧客が「欲しい」と言うものです。プロダクトトリオによる毎週のインタビューが教えてくれるのは、顧客が実際の業務で何に苦労しているかです。前者は既存の計画を裏づける材料を生み出し、後者は計画を変える発見を生み出します。後者を求めるなら、そのための構造的な条件を自ら作る必要があります。

COOであれば、トーレスが浮かび上がらせるオペレーション上の問いは、プロダクトチームのディスカバリー業務が、配信のコミットメントとどうつながっているかです。多くの企業は6〜12ヶ月先まで配信を計画しますが、それはつまり、その計画に組み込まれた仮説が配信の何ヶ月も前に形成されたものだということです。トーレスの継続的ディスカバリー・モデルは、その仮説を毎週更新する仕組みを組み込みます。これは年次計画サイクルとの間に緊張関係を生みます。オペレーション上の解決策は、計画そのものをやめることではなく、計画サイクルの合間に仮説を追跡する軽量な仕組みを作り、中核となる仮説が誤っているとディスカバリーが明らかにしたときに、配信計画を更新できるようにすることです。

プロダクトリーダーであれば、定着させるべき最も重要なトーレスの実践は、プロダクトトリオのための毎週の顧客インタビューの習慣です。リサーチスプリントではありません。ユーザーテストのイベントでもありません。PM、デザイナー、エンジニアが揃って行う毎週のインタビューを、スプリント計画が長引いてもキャンセルされない、繰り返しのカレンダー予定として定着させることです。トーレスがエンジニアの同席にこだわるのは、顧客インタビューに参加したエンジニアは、細部まで書き込んだ要件ドキュメントがなくても、より良い実装判断を下せることに気づいたからです。インタビューそのものが、コミュニケーションのレイヤーとして機能するのです。

営業やマーケティングの立場であれば、トーレスのオポチュニティ・ソリューション・ツリーは、顧客からのフィードバックがなぜプロダクトの変更につながらないのかを理解するための診断ツールになります。営業チームが顧客からの要望をプロダクトチームに持ち込み、それがバックログに滞留してしまうのは、多くの場合、その要望がオポチュニティ(顧客はYをするのに苦労している)ではなく、ソリューション(機能Xが必要だ)として語られているからです。トーレスのフレームワークは、営業から上がってくる顧客の声を、プロダクトチームが実際に使えるオポチュニティの言葉に翻訳する助けになります。これは政治的な調整ではありません。語彙を変えることで、その情報の行く末そのものが変わるのです。

リワークがトーレスのドクトリンを運用する方法

トーレスの継続的ディスカバリーの習慣が崩れるのは、フレームワークのせいではなく、カレンダーのせいです。スプリント計画が長引くと毎週の顧客インタビューが後回しになり、更新のオーナーが誰もいないとオポチュニティ・ツリーは古びていき、仮説検証は配信バックログに一度もつながらないまま終わります。リワークは、ディスカバリーを儀式ではなく追跡可能な業務として扱うことで、こうしたギャップを埋めます。プロダクトトリオは、PM、デザイナー、エンジニアをアサインした繰り返しのリワーク・タスクとして毎週のインタビューをスケジュールし、インタビューのメモや顧客の発言はオポチュニティのレコードに直接紐づけられます。オポチュニティ・ソリューション・ツリーの各枝はリワークのワークアイテムに対応づけられるため、仮説、実験、そしてそこから生まれるソリューションは、アウトカムからリリースまで一貫した系譜を共有します。この系譜こそ、経営幹部が本当に必要としているものです。どの仮説が動いたか、どのオポチュニティが育ったか、その結果としてどの配信コミットメントを更新すべきかを、毎週見渡せる状態です。月額12ドル/ユーザーから利用でき、詳しくはリワークの料金プランをご覧ください。

印象的な言葉と、会議室の外にある教訓

「最低限、プロダクトを作っているチーム自身が、顧客と毎週接点を持つこと。」これがトーレスによる継続的ディスカバリーの定義であり、この具体性こそが重要な点です。月に1回ではありません。四半期に1回でもありません。リサーチチームがプロダクトチームの代わりに行うのでもありません。トリオ自身が、毎週行うのです。このペースこそが、ディスカバリーをプロジェクトにするか実践にするかを分ける違いです。

顧客諮問委員会を直接接触の代替とすることへの彼女の反論は、じっくり考える価値があります。顧客中心のプロダクト開発に関するHBRのリサーチも、アカデミックな側面から整合的な結論にたどり着いています。チームを顧客の苦労に近づけ続ける構造化されたディスカバリーの習慣は、定期的な諮問インプットを一貫して上回るというものです。諮問委員会が生み出すのは、参加意欲の高さで選ばれた顧客からの、選別され合意形成された意見です。それは特定の種類の戦略的インプットには有用です。しかし、リアルタイムで問題を解決しようとしている顧客との、直接で仲介のない接点の代わりにはなりません。諮問委員会の顧客は自分が欲しいものを説明します。毎週のインタビューの顧客は、自分が何に苦労しているかを見せてくれるのです。

「仮説」を、プロダクトの意思決定の中で最も検証されずに見過ごされている変数として位置づけたことは、トーレスの最も知的に精緻な貢献です。あらゆるプロダクトへの賭けは、顧客が何を望んでいるか、そのソリューションが機能するか、チームがそれを作れるか、それが実際に採用されるかといった、仮説の積み重ねです。ほとんどのチームはそれらの仮説を明示的に洗い出さないため、最も重要な仮説を検証することができません。オポチュニティ・ソリューション・ツリーの仮説検証の枝は、まさにこの、もし間違っていれば他のすべてを無効にしてしまう仮説を表面化させるために存在しています。

このスタイルが機能しない場面

継続的ディスカバリーが成り立つには、プロダクトチームが学んだことをもとに行動できるだけの自律性を持っている必要があります。エンジニアリングのリソースが年次計画サイクルによって固定されている企業や、機能レベルの意思決定にまで経営幹部のサインオフが必要な企業では、トーレスの毎週のペースは勢いではなく、フラストレーションを生んでしまいます。発見したことが自分たちの作るものを変えられないのであれば、毎週インタビューをする習慣そのものは、問題を解決してくれません。

オポチュニティ・ソリューション・ツリーは、経験を積んだプロダクト思考の持ち主のためのツールでもあります。プロダクトの成熟度がまだ低いチーム、たとえば顧客インタビューの進め方をまだ学んでいる最中のPMや、顧客との会話に一度も同席したことのないエンジニアには、このフレームワーク単体が提供する以上の足場が必要になることが多いのです。

そして、トーレスの手法が最も実戦で鍛えられているのは、中堅段階のB2B SaaSにおいてです。複雑な調達サイクルを持つエンタープライズソフトウェア、ハードウェアプロダクト、数百万ユーザーを抱えるコンシューマーアプリは、彼女のフレームワークが大枠では扱えても、具体的な運用にまでは落とし込めていないディスカバリーの課題を抱えています。リーナス・トーバルズは、エンジニアリング文化として最も鋭い対比をなす存在です。トーレスがエンジニアの顧客ディスカバリーへの継続的な関与を主張する一方で、トーバルズは外部からの要件圧力からエンジニアをできる限り遠ざけることで、過去30年で最も影響力のあるエンジニアリング上の貢献を築き上げました。

プロダクトディスカバリーと権限を持つチームについて関連する記事は、マーティ・ケーガンのリーダーシップスタイル、シュレヤス・ドシのリーダーシップスタイル、そしてアウトカム駆動のプロダクトチームを構築するをご覧ください。