開発コスト低下で顕在化する「新たなボトルネック」
かつてソフトウェア開発のライフサイクルにおいて、コーディングをはじめとする「構築（ビルド）」は最も時間のかかる工程だった。しかし今、AIはその作業の多くを数分でこなしてしまう。
「プロダクト構築には、常に3つの大きな課題があった」とケーガン氏は前置きし、次のように説明する。
「1つ目は、どの問題を解決したいのかを決める『プロダクト戦略（Strategy）』です。2つ目は、顧客が他の手段を捨ててでも買いたくなるような解決策を見つけ出す『プロダクトディスカバリー（Discovery）』。そして3つ目が、そのソリューションを実際に構築・提供する『デリバリー（Delivery）』です」
言語モデルは自然言語よりもプログラミングコードの生成をはるかに得意としている。そのため、生成AIは「デリバリー」の自動化において圧倒的な成果を上げている。つまり、現在の本当のボトルネックは、上流工程である「戦略」と「ディスカバリー」に絞られたのだ。
「戦略はCPOのようなリーダーが責任を持つ領域ですが、プロダクトチームに所属するプロダクトマネージャーが責任を負うのはディスカバリーとデリバリーです。従って、現在の本当のボトルネックは『プロダクトディスカバリー』になります」
過去50年間、多くの企業は「エンジニアの開発スピードが遅いこと」が問題だと勘違いしてきた。しかし、彼らはボトルネックだったかもしれないが、問題の本質ではなかったのだ。
「問題は常に、競合他社よりも優れたソリューションを考え出すことでした。今、エンジニアが問題ではないことが誰の目にも明らかになったため、『構築する価値のあるソリューションをいかに発見するか』というディスカバリーに光が当てられているのです」
AIプロダクトにおける「4つのリスク」の変化
プロダクトディスカバリーでは、従来から「価値（Value）」「ユーザビリティ（Usability）」「実現可能性（Feasibility）」「事業成立性（Viability）」という4つのリスクを管理することがプロダクトマネージャーの基本とされてきた。AI時代において、このリスクの「比重」はどう変化したのだろうか。
ケーガン氏によれば、ここで「従来型の決定論的プロダクト」と、AI技術を中核に据えた「確率的プロダクト」を分けて考える必要があるという。Waymo（ウェイモ）のような自動運転車など、真のAIプロダクトを構築する場合、これら4つのリスクは劇的に跳ね上がる。
「AIプロダクトは現在、利益を出す（収益化／Monetize）のが非常に難しく、事業成立性や実現可能性の財務的リスクが跳ね上がっています。また、自動運転車がもし事故を起こせば、金銭的コストだけでなく企業の評判を根底から破壊しかねません。さらに、予測不可能なAIシステムとどう接すればよいかユーザーが戸惑うため、ユーザビリティのリスクも増大します」
しかし、現在多くのプロダクトチームが最も過小評価しており、かつ警戒すべきは価値（Value）のリスクだという。
「テクノロジーが大好きでこの業界に入ったプロダクトマネージャーは、最新のAI技術を見ると『これを作ったらクールじゃないか？』と言わずにはいられません。しかし、どれほどクールな技術を使っても、人々は買ってくれません。それだけでは不十分なのです」
多くの企業が「AI搭載」を謳うマーケティング目的でプロダクトを急造している。やがてAI搭載が当たり前になれば、「これは以前より優れたプロダクトなのか？」という本質的な価値が厳しく問われるようになる。
プロダクトマネージャーが避けるべき役割と、フォーカスすべき「学ぶための構築」
AIが普及する中で、チーム内の役割や意思決定のあり方はどう変わるのだろうか。ケーガン氏は、現代のプロダクト開発モデルにおける「3つのモデル」を提示し、AI時代にプロダクトマネージャーがとるべきスタンスを明確にした。
1つ目は「アジャイルプロダクトオーナー」だ。ケーガン氏は「もしあなたがこの役割を担っているなら、それはプロダクトマネージャーではないと認識すべきだ」と指摘する。同氏がここで問題視しているのは、本来の理想とは裏腹に、ディスカバリーに関与せず実態としてデリバリー（開発・提供）のみを担ってしまっている状態のモデルだ。このような単なるデリバリーの仕事は「生成AIに代替されるため、未来はない」と断言し、手遅れになる前にスキルの再習得を急ぐよう警告した。
2つ目は、日米で最も一般的な「プロジェクトモデル（フィーチャーチーム）」だ。経営陣がロードマップを決定し、現場に機能開発が割り当てられる。ケーガン氏は「このモデルでは、肩書きこそ『プロダクトマネージャー』と呼ばれていても、実態としてはプロジェクトマネジメント（進行管理）を行っているにすぎない」と指摘する。さらにこの手法は、構築した機能の80％が期待した成果を生まないという統計的欠陥を抱えている。
3つ目が、真の成功を収めている「プロダクトモデル（プロダクトオペレーティングモデル）」だ。チームは機能ではなく「解決すべき問題」を与えられ、顧客が愛し、ビジネスとしても成立するソリューションを自ら見つけ出す権限と責任を与えられた（Empowered）状態にある。
この「プロダクトモデル」において、AIは劇的な変化をもたらした。今ではデザイナーやエンジニアに頼らずとも、プロダクトマネージャー自身がプロトタイプを即座に作成できるようになったのだ。
「プロトタイプは『学ぶため（Build to learn）』に作り、プロダクトは『稼ぐため（Build to earn）』に作ります。プロダクトマネージャーは自身がコーディングに没頭するのではなく、ビジネスと顧客の深い理解をもとに『正しい意思決定』を下すことにフォーカスすべきなのです」
