マーティ・ケーガンのリーダーシップスタイル：権限を与えられた製品チーム、発見、およびSVPGフレームワーク

マーティ・ケーガンはHP、Netscape、eBayのような企業内で20年を過ごし、製品を構築しました。その後、2001年に Silicon Valley Product Groupを設立し、その後20年間は、ほぼすべてのことを行っていることがほぼすべて — 機能に満ちたロードマップ、製品オーナーが要件をチケットに変える、プロジェクトのような製品のような四半期計画サイクル — が間違っていたことを企業に伝えていました。

彼は無愛想ではありません。

主要事実

• 創設者： Silicon Valley Product Group（SVPG）（2001年設立） — 業界の最も影響力のある製品コーチング企業。
• オペレーター背景： SVPG以前に20年以上。eBay（1999年～2001年）での製品ジェネラルマネージャーと、Hewlett-Packard（HP）、Netscape、AOLでのシニア製品ロール。
• シグネチャー書籍： 「INSPIRED: How to Create Tech Products Customers Love」（2008年、2017年に改訂 — 広く製品管理業界バイブルと呼ばれている）、「EMPOWERED: Ordinary People, Extraordinary Products」（2020年、Chris Jonesと共著）、「TRANSFORMED: Moving to the Product Operating Model」（2024年）。
• コーチング到達： SVPGはNetflix、Adobe、Uber、および数百の成長段階とエンタープライズテクノロジー企業で製品リーダーシップをコーチングしました。
• コアボキャブラリ： 「権限を与えられた製品チーム」、「機能工場」、「製品トリオ」、「デュアルトラックアジャイル」という用語を普及させました — 現在のモダン製品管理のデフォルト言語。

権限を与えられた製品チーム教義

権限を与えられた製品チーム教義（ケーガンINSPIREDモデルとも呼ばれます）は、耐久性のある製品企業が、機能リストを提供するのではなく、難しい顧客問題を解決するために与えられた製品マネージャー、デザイナー、エンジニアからの機能横断チームの周りに構築されることを保持しています。権限付与には2つの条件が必要です。すべてのチームのシニアキャリバータレント、および測定量ではなく結果を測定する経営陣。両方がないと、モデルは最新の製品語彙を着ている機能工場に低下します。

「INSPIRED」は、穏やかであるため、シリコンバレーで最も推奨される製品本ではなく、失敗モードを明らかに命名しているためです。ケーガンはほとんどのエンタープライズ製品組織を「機能工場」と呼びます — 彼らが言われていることを何が出荷し、速度を測定し、アウトプットが実際の問題を解決しているかどうかを決して質問しないチーム。その診断は不快です。それは今日動作している製品チームの大多数に正確だからです。

エンジニアリングが何がロードマップが言うか出荷し、誰もそれが正しいことを作成するかどうか質問しない企業を運営している場合、ケーガンのフレームワークは、あなたが必要とする直接的な介入です。

リーダーシップスタイルの分析

その割合は、ケーガンのフレームワークが同時に最も引用され、最も頻繁に製品管理で誤用される理由を説明しています。システム思考は明確です。それをインストールするのに必要なコーチングは難しいです。企業は「INSPIRED」を読み、診断に同意します。その後、天才、信頼、経営陣の調整の基礎的な仕事を行わずに権限を与えられたチームを実行しようとしてください。結果は、実際に脱出することなく、ケーガンのポイントについて確認します機能工場。

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

マーティ・ケーガンをリーダーとして定義した3つの決定

1. オペレーターとして継続する代わりに2001年にSVPGを設立

ケーガンはeBayを2001年に去り、別のジェネラルマネージャーの役割を取る代わりに Silicon Valley Product Groupを設立しました。それは、その後ろにある論文との賭けでした。企業は、内部から同じパターンを複製する必要がある必要があった企業は必要ありませんでした。彼らは、内部チームが見ることができない失敗モードを見ることができる実践者によって構築された外部コーチング モデルが必要でした。

タイミングは重要でした。2001年はドットコムクラッシュ後でした。インターネット製品企業の最初の世代が崩壊しました。2番目の世代 — Google、Amazon、初期Facebook — を開始しました。ケーガンはブラウザ戦争、AOL-Netscape合併、eBayマーケットプレイスビルドの規模での製品開発を見ていました。彼は製品組織が動作したもの、そしてそうではなかったものを区別するものの特定のビューを持っていました。

SVPGはライティングとスピーキングプラットフォームとして始まりました。ケーガンは「INSPIRED」が本の前に何年も前のSVPG ブログで製品管理思考を出版しました。その執筆は、認定コース理論ではなく実践者ベースのガイダンスを渇いていたPMの聴衆を構築しました。「INSPIRED」が2008年に出てきたとき、それは事前に構築された読者を持っていました。

コーチング企業モデルはケーガンが、1つの組織の内部にいることなく実際の組織的問題と密接に接触を保つことを許可しました。25年後、SVPGは数百の企業をアドバイスしました。それは、単一のオペレーター役割が提供できないもの、そしてなぜケーガンの製品の失敗についてのパターン認識がほとんどより信頼できるのかの広さです。

2. 「INSPIRED」を執筆 — 2つの版、異なる聴衆

「INSPIRED」の最初の版は2008年に出ました。それは、製品管理の実用的なガイドであり、彼らの仕事がどのように実際に動作するべきかのテンプレートを持っていないPMを目指していました。2008年には、製品管理の深刻な実践者執筆はほぼありませんでした。ケーガンはギャップを埋めました。

2017年の第2版は異なる本です。それは単に更新されません — 再構成されます。2017年までに、ケーガンは失敗モードがシフトしたことを理解するために、十分な製品市場適合企業をコーチングしていました。問題は、PMがファンダメンタルを知らないことではありませんでした。問題は、ほとんどの製品組織がモダン製品管理の語彙（アジャイル、スプリント、ロードマップ、ユーザー物語）を採用していたが、基礎的な文化を変更していなかったことでした。彼ら は依然として、より良い処理劇場を持つ機能工場でした。

第2版は権限を与えられた製品チームを明示的に導入し、製品トリオ（PM + デザイナー + エンジニアをコ等しい発見チームとして働く）を定義し、デュアルトラックアジャイル モデルを中央にしました。デュアルトラックアジャイルは発見を実行します — 何を構築するかと、それが動作するかどうかを考え出すことです — 配信と平行して、代わりにそれらをシーケンシャルフェーズとして扱う。識別により、ケーガンが観察した最大の失敗モード：実際のロードマップ全体の機能のロードマップが検証されたことがなく、実際の問題へのソリューションとして。

「INSPIRED」はGoogle、Microsoft、および数百の成長段階企業の通貨として使用されています。SVPGの直接コーチングベースを超えた到達は、ケーガンの語彙— 機能工場、権限を与えられたチーム、製品トリオ — 深刻な製品管理の支配的な言語になった理由です。

3. 権限を与えられた製品チームの論文を発展させる

製品トリオの概念は一見単純です。PM、デザイナー、エンジニアが発見に一緒に動作し、順次ではありません。PMは要件をデザインに手渡さず、デザインはエンジニアリングにエンジニアリングをします。3人すべてが問題を理解し、最初から解決策を形成するのに関わっています。

これは、ほとんどのアジャイルおよび Scrum 実装が実際にどのように機能するかと直接矛盾します。実際には、ほとんどの「アジャイル」組織にはPM執筆ユーザーストーリー、デザイナー製造のモックアップ、エンジニアリング実装があります。PMは顧客入力をフィルタリング優先化プロセスを通じてバックログを生成する仲介者です。エンジニアの仕事は、品質を持つバックログを実行することです。

ケーガンの議論は、このモデルが正確に間違ったインセンティブを生成するということです。PM スループット（バックログをクリア）を最適化し、デザイナーは個々の機能の視覚的品質を最適化し、エンジニアは技術的な実行を最適化します。誰も製品が正しい問題を解決しているかどうかについては説明責任がありません。

製品トリオモデルは、すべての3つのロールに対する結果の共同説明責任を置きます。問題に興味のあるエンジニア、単に実装ではなく。ビジネス制約に従事できるデザイナー、ユーザーエクスペリエンスだけではなく。そして権限ではなく影響力を通じてリードできるPMが必要です。

それはハード組織の変化です。ほとんどの企業が現在雇用しているものより異なるスキルのために雇用が必要で、それはこれら3つのロールがどのように評価されるかを変更する必要があります。ケーガンはこれを認識しており、「EMPOWERED」（2020年）が指導者層に焦点を当てているのはなぜです。ボトムアップから製品トリオをインストールすることはできません。

マーティ・ケーガンがあなたの役割で何をするか

CEO の場合、ケーガンの最も直接的な質問は信頼についてです。あなたは、あなたの製品リーダーシップチームに、構築する内容について真の権限を与えましたか、またはあなたはロードマップをレビューし、本能または最後の顧客呼び出しに基づいて変更しますか？ほとんどのCEOは、実際にロードマップ制御を行使しながら、自分たちが自分たちの製品チームに自動性を与えていると信じています。ケーガンのポイントは、あなたはそのうちの1つを持つことができるということです。ロードマップ管理、または製品リーダーシップに対する結果の説明責任。両方をしようとすると、権限付与について使命声明を持つ機能工場が作成されます。

COO の場合、運用上の質問は発見容量についてです。あなたの製品組織は、エンジニアリングリソースにコミットする前に仮定を検証するための構造化処理を持っていますか？ほとんどの企業はそうではありません。彼らは、その間に規律段階なしで要件から計画ストライキを移動します。デュアルトラックアジャイル、継続的に発見を実行し、バッチ研究スプリントではありません。製品サイクルが「要件を書く、デザイン、構築、リリース、測定する落胆」のように見える場合、発見追跡トラックが欠落しており、ケーガンの双追跡モデルが特定の修正です。

製品リーダーの場合、実行する最も重要なケーガン診断は次のとおりです。エンジニアの何パーセントがチケットを見なくても、彼らの現在の仕事で彼らが解いている顧客問題を伝えることができますか？80%未満が質問に答えることができる場合、機能工場を運営しています。修正は通信プログラムではありません。それは発見がどのように起こるかを再構成することです — 顧客会話にエンジニアを取得し、ソリューション設計が始まる前に問題フレーミングに関わるし、スループットではなく結果のチーム測定をします。

営業またはマーケティングの場合、ケーガンのフレームワークは、あなたが理解する必要がある特定の緊張を作成します。権限を与えられた製品チームは、販売コミットメントではなく、製品判断に基づいて賭けをするはずです。それは、まだ構築されていない販売機能、または最大顧客がロードマップに命じることを許可する一般的な実践と直接矛盾しています。ケーガンは販売入力を無視することを言っていません — 彼は、製品組織が、より広い顧客ベースに対してその入力を評価し、約束ではなく製品の賭けをする必要があることを言っています。販売チームが製品ロードマップを所有している場合、専門的なサービスビジネスを構築しており、製品企業ではありません。

Reworkが権限を与えられたチーム運用モデルをサポートする方法

ケーガンの診断は、スループット報酬ではなく、結果が機能工場を永続させるということです。ロードマップ、チケット、Jiraボード — 日々の成果物の表面を操作します。権限を与えられた製品チームへの切り替えには、チームが実際に動作する日々のアーティファクトが必要とする移行が必要です。これはReworkの Work Operations プラットフォームが適合する場所です：配信チケット横に仮定と実験を追跡する発見ボード、エンジニアリング作業を解くことを整わせるアウトカムベースのチームダッシュボード、顧客問題、およびツール全体で PM、デザイナー、エンジニアが単一の真実源を共有する機能横断スペースを共有します。

ケーガンモデルをインストールする製品リーダーにとって、最難関な文化的転換は発見を見えるようにすることです。ほとんどの組織には、「ここに私たちが想定したものがあります。ここに私たちがそれをテストした方法があります。ここにある私たちが学んだこと。」Reworkは、製品トリオに共有ワークスペースを与えます — 発見を第1級の実践にするために十分な構造化、別のステージゲート処理に変わるのを避けるのに十分な柔軟性。ツールは権限を取り付けません。しかし、運用システムが機能工場の動作を強制しているという言い訳を削除します。

注目すべき引用と教訓を経営方針以上に

ケーガンは、製品マネージャーが何ではないかについて具体的です。彼は「製品のCEO」の説明に対して議論しており、実際の仕事を曖昧にしています：「製品マネージャーの仕事は、エンジニアリングチームと密接に動作して、顧客によって価値のあり、ビジネスのために実行可能な製品を発見および配信することです。」それは戦略所有権とは非常に異なるアカウンテーション。これの完全な表現はSVPGの記事アーカイブで発展しており、ケーガンは2001年以来、数百の実践者中心のエッセイを出版しています。

「機能チーム」と「製品チーム」の違いは、壁に値します。機能チームはソリューションを構築する与えられます。製品チームは問題を解決するために与えられます。ほとんどの組織は、機能チームとして動作し、彼らのチームを製品チームと呼びます。その2つの間のギャップは、競争上の利点を作成する製品組織と、リストに対して実行する製品組織の間のギャップです。

彼の最も不快な観察は、ほとんどの企業が製品を「名前のみで」実行することです。彼ら は、製品マネージャーのタイトルを持つPM がチケットを書くのに時間を費やし、配信を管理しています。彼ら は、アジャイル式典と四半期ロードマップレビューがあります。そして、彼らは顧客が実際に望む製品を作成する能力の継続的な失敗を持っています。ケーガンのポイントは、モダン製品管理の語彙が、それが説明している基礎的な能力よりもはるかに速く広がったということです。

このスタイルが壊れるところ

ケーガンの権限を与えられた製品チーム モデルは、真の自動性を持つことができ、高品質の賭けをすることができる強いシニア製品マネージャーを持つことを想定しています。ほとんどの初期段階および中段階企業は、その天才基盤を持っていません。フレームワークのアドバイスは正しい — しかし、現実的な開始地点が、発見を実行したことのない3人のジュニアPMのチームであるとき、それは麻痺を作成できます。

モデルはまた、構築するのに数年かかる製品判断に対する経営の信頼を必要とします。販売またはエンタープライズカスタマーが直接ロードマップを駆動する組織では、権限を与えられたチーム原則は、フレームワークが特定が完全に解決されない政治的矛盾を作成します。ケーガンは、ボトムアップからモデルをインストールすることはほぼ不可能であることを認めています。しかし、「実行前にエグゼクティブの買い込みを取得する」は常に可能なアドバイスではありません。

そして、ケーガンはもはや動作していません。彼のフレームワークはHP、Netscape、eBayでストレステストされ、プレモバイル、プレクラウドエンタープライズでした。モダンB2B SaaS、マーケットプレイスビジネス、または消費者モバイル製品の特定の動力学は、彼の仕事が不完全に覆われているしわを導入しています。Shreyas Doshiは、最も有用な拡張を提供します — 彼のLNO フレームワークと製品思想家の違いは、ケーガンのオペレーター年を後続する Stripe と Twitter 経験から構築されています。そしてSteve Jobsは、ケーガンの核となる論文が保持されることの最も明確な歴史的証拠のままです。最も重要な製品決定は、製品の直感を組織の権限から分離することを拒否したリーダーから来ました。

---

製品リーダーシップと発見実践に関する関連読み取りについては、Teresa Torres Leadership Style、Shreyas Doshi Leadership Style、Building High-Performance Product Teamsを参照してください。