[00:00:00] チラグ・メータ：私は最高製品責任者（CPO）として、かつて「最高製品責任者とは、最高バックログ責任者である」とよく言っていた。彼らはバックログの上に座っているのです。[00:00:10] かつてはそうだったのです。それに、あなたがそれを十分に届けることができなかったから。うん。そして [00:00:15] やるべきことはいつも山積みだった。そして今、あなたが提示しているのは、実験なしでは物事を正しく行うことはできない、という考え方だと思います。[00:00:20] [00:00:25] 

[00:00:25] チラグ・メータ：それに、実験を行うには、それなりのスキルが必要です。単に機能や成果、[00:00:30]その他諸々を作り上げるだけでは不十分で、何がうまくいっていて、何がうまくいっていないのかをしっかりと理解しなければならないのです。 

[00:00:34] トリシャ・プライス：[00:00:35] ソフトウェアを開発している方、あるいは開発チームを率いている方なら、ここはまさにぴったりの場所です。[00:00:40] こちらは『Hard Calls』です。確かな決断、確かなリーダー、確かな成果。[00:00:45] 

[00:00:45] トリシャ・プライス：みなさん、こんにちは。『Hard Calls』へようこそ。このポッドキャストでは、[00:00:50] 世界中の優れたプロダクトリーダーたちを紹介しています。この番組を初めてご覧になる方は、ぜひ[00:00:55]で「フォロー」または「チャンネル登録」をお願いします。そうすることで、最新のエピソードを常にチェックできます。本日の[00:01:00]エピソードは、Constellation Researchのチラグ・メータ氏との対談です。[00:01:05] 私たちは、単なる機能の提供者から、成果[00:01:10]重視の製品リーダーへと移行する動きが加速していることについて話し合いました。そして、私が皆さんにこれを聞いてほしかった理由はここにあります。私たちは今、AIによって製品のライフサイクルが、これまでに見たこともないほど、数年単位から数日単位へと短縮されているという[00:01:15]転換点に立っています。多くの場合。[00:01:25] 開発を始めたその日に、文字通り製品をリリースすることは可能です。しかし、それは同時に、これまで以上に早く[00:01:30] 間違ったものをリリースしてしまう可能性があるということでもあります。

[00:01:31] トリシャ・プライス：今回の対談では、[00:01:35] プロダクトチームを研究ラボのように運営することの真の意味について語ります。なぜ「ノーススター指標」が機能の数よりも重要なのか [00:01:40]。そして、プロダクトマネージャーとエンジニアの比率が根本的に変化しつつあることについても触れます。[00:01:45] また、[00:01:50] 優れた意思決定が実際に評価され、バックログに埋もれてしまうことのないようにする方法についても議論します。この点については、まだ十分に語られていないと私は思います。

[00:01:54] トリシャ・プライス：[00:01:55] もし、自分が「最高プロダクト責任者」ではなく「最高バックログ責任者」のように感じたことがある方、あるいは[00:02:00] 予算を使い果たさずにどうやって実験を行うか模索している方には、このエピソードがまさにぴったりです。[00:02:05] 

[00:02:05] チラグ・メータ：じゃあ、これから楽しくお話ししましょう。[00:02:10] 製品およびエクスペリエンスのライフサイクルに関するあらゆる事柄。以前は最高製品責任者を務めていました [00:02:15]。現在は、購入者およびエンドユーザーとして、最高製品責任者の役割を果たしています。

[00:02:19] チラグ・メータ：さて、これは[00:02:20]楽しい会話になりそうですね。それでは、私が感じていることをお話ししましょう。[00:02:25] まず、最近よく話題になっている「機能」と「成果」の違いについて、私たちが耳にしていることをお伝えします。[00:02:30] 機能自体は素晴らしいものですが、機能だけでは何も成し遂げられません。[00:02:35]誰でも[00:02:40]短期間で機能を構築することができます。

[00:02:41] チラグ・メータ：もし望めば、1日で製品をリリースすることもできますが、[00:02:45] 何の効果もないかもしれません。つまり、何かを作り上げてリリースすることはできるかもしれませんが、それが必ずしも[00:02:50] ビジネス上の成果につながるわけではありません。つまり、こうした変化が起きているのです。この[00:02:55]機能主導型のソフトウェア開発から成果主導型の製品開発へと移行しています。[00:03:00] 同じように感じていらっしゃいますか？

[00:03:01] チラグ・メータ：もしかして？まあ、それは良い出発点ですね。 

[00:03:02] トリシャ・プライス：そうですね、素晴らしい出発点ですね。[00:03:05] チラグ、これは本当に楽しみですね。私たち二人ともプロダクト担当者をサポートする立場でありながら、自分たちもプロダクト担当者ですから。[00:03:10] ですから、この議論をとても楽しみにしています。ええ、そうですね。[00:03:15] 昨年見られた[00:03:20]AIの勢いが生まれる前から、そう考えていました。

[00:03:20] トリシャ・プライス：確かに、焦点は「機能の量産」から[00:03:25]「成果」へと移行しています。なぜなら、多額の資金を投じて新しい[00:03:30]製品や機能をリリースしたことを祝うことはできても、結局のところ、それで何になるのでしょうか？もし誰も使わなかったら？もしそれがARRの向上につながらず、サポートコストの削減にもならないのなら、間違ったものをリリースしてしまったのに、それをリリースしたからといって、誰が気にするだろうか？

[00:03:41] トリシャ・プライス：さて、話を今日に移すと、[00:03:45] これから詳しく触れていくことになりますが、AIが登場しました。[00:03:50] 素晴らしいプロトタイピングツールを使ったり、さらには実際の[00:03:55]製品を作り上げたりすることが、かつてないほど簡単で、かつてないほど速くなりましたよね？そして[00:04:00]、Lovable や Bolt、Cursor といったツールがあり、これらはどれも素晴らしいツールで、[00:04:05] 製品をより迅速に市場に送り出すことができます。

[00:04:06] トリシャ・プライス：しかし、それは単に、私たちが目指す成果を依然として生み出せないまま、質の悪い製品や機能をさらに作り続けてしまうことにもなりかねません。そして、[00:04:20] プロダクトにおけるこうした進化を目の当たりにするのは本当に楽しいものです。[00:04:25] プロダクト担当者は、まさに戦略家でありビジネスパーソンなのです。[00:04:30] そして、[00:04:35] ビジネス指標という観点では、会社の他の部門と同じ責任を負っています。

[00:04:36] チラグ・メータ：そうだね、君が言った戦略やビジネスパーソンについて、僕も共感するよ。そして、プロダクトマネージャーという職種について考えてみると、[00:04:45] 典型的なプロダクトマネージャーという存在ですが、私はもともとエンジニア出身で、[00:04:50] 私のチームにはプロダクトマネージャーも在籍しています。つまり、私たちにはエンジニアと、エンジニアリングの実務に携わる人々が混在しているわけです。[00:04:55] そのため、誰であれプロダクトマネージャーになり得るという、こうした組み合わせを目の当たりにしてきました。

[00:04:59] チラグ・メータ：[00:05:00] テクノロジー分野などに情熱を持っている必要があります。しかし、あなたは[00:05:05]、今は状況が変わってきていると指摘しています。[00:05:10] 技術的な知識が十分でなければならない、という考えがある。何が起きているのかを知るために。というのも、やはり[00:05:15]、結局のところ、すべてはテクノロジーにかかっているんです。製品を作っているけれど、[00:05:20]僕たちが話しているのは成果についてであり、その成果はビジネスや戦略に関わるものなんだ。

[00:05:24] チラグ・メータ：[00:05:25] 自社の目標を、市場における競合状況や顧客の動向といった外部の状況に照らし合わせて[00:05:30] 具体化しなければなりません。では、このテクノロジーとビジネスの融合[00:05:35]は、具体的にどのようなものなのでしょうか？ 

[00:05:39] トリシャ・プライス：私はこれを、インサイド・アウト思考とアウトサイド・イン思考の組み合わせだと捉えるのが好きです。[00:05:45] そして、エンジニアは――私がエンジニアだから偏見があるのかもしれませんが――素晴らしい[00:05:50] プロダクト担当者になれると思います。

[00:05:50] トリシャ・プライス：彼らは本当にそれができるのです。なぜなら、彼らは「インサイド・アウト」の思考を完璧に体現し、[00:05:55] テクノロジーを自在に操り、革新的な[00:06:00] 何かを生み出すための「可能性の芸術」を追求しているからです。そして、とりわけAIの時代においては、問題セットを分解できることが重要なんですよね。私が目指している成果はこれです。問題はこれです。そして[00:06:10]、具体的な要素は何でしょうか？

[00:06:11] トリシャ・プライス：出荷を開始し、勢いをつけて[00:06:15] 物事を世に出すために、どのような部分に分ければよいでしょうか。そして、その『インサイド・アウト』の思考はエンジニアにとってはごく自然なことですが、[00:06:20] それが原因で質の悪い製品をたくさん出荷してしまうこともあります。だから私にとっては、[00:06:25] エンジニアかどうかは関係ないんです。外向きの思考。また、これを[00:06:30]「プロダクトセンス」と呼ぶ人もいるかもしれませんが、要は市場を理解し、[00:06:35]目指すべき成果を把握することです。そして、非常に優れた商品感覚を持っていること。[00:06:40] 達成すべき課題を把握しておく必要があります。ユーザーのことを隅から隅まで理解し、[00:06:45] どのような問題が、単なる「ビタミン」ではなく、真に「痛みを和らげる薬」となるのかを把握しなければなりません。しかし、それでも[00:06:50]、自社の成果に結びつける必要があります。

[00:06:52] トリシャ・プライス：つまり、外から内への思考の部分があって、[00:06:55] ビジネス戦略には2つのパターンがあるんですよね。まず第一に。[00:07:00] ユーザーを理解し、ユーザーに提供しようとしている価値、そして[00:07:05] 解決しようとしている課題を把握することです。そして2つ目は、自分の会社のために何を目指しているのか、ということです。[00:07:10] そうですよね？私は新たなARRを獲得しようとしているのでしょうか？

[00:07:12] トリシャ・プライス：同じ顧客向けに新しい製品を作り、異なる課題を解決しようとしている場合は、その目標に合わせて製品のNorth Star指標をしっかりと調整する必要があります。 

[00:07:22] チラグ・メータ：「間違った製品をリリースしてしまう可能性がある」とおっしゃったのは興味深いですね。AIによって、開発ライフサイクルが本当に[00:07:30]短縮されていると思います。先ほど[00:07:35]も少し触れましたが、何かを作り、その日のうちにリリースすることも可能になり、[00:07:40]そして、どうなると思いますか？

[00:07:40] チラグ・メータ：間違った商品を発送してしまうのです。では、それをこの戦略の一環、またこの検証プロセスの一部として捉えていますか？そして、私たちや多くの人々が一般的に「プロダクトセンス」と呼ぶ―ご存知の通り、エンドユーザーを深く理解するという意味ですが―それが、[00:08:00] こうしたフィードバックループを加速させる能力をもたらしているという理解でよろしいのでしょうか？

[00:08:03] トリシャ・プライス：うん、 

[00:08:04] チラグ・メータ：以前は、フィードバックが返ってくるのを何時間も、何日も、何週間も待たされることがよくあって、[00:08:05] 時には「おい、間違ったものを送っちゃったよ」なんて言われることもありました。実際に直さなきゃいけないんだ。しかし今では、それらの[00:08:15]フィードバックループははるかに高速になっています。つまり、どうお考えですか？そのフィードバックループをどのように捉えていますか？[00:08:20]フィードバックループの方が速いのですか？

[00:08:23] チラグ・メータ：もしそうだとすれば、その状況の中で、プロダクトマネジメントという分野はどのように進化していくのでしょうか？ 

[00:08:28] トリシャ・プライス：ええ、まあ、フィードバックループが短くなり、サイクルも短くなっているというのは、[00:08:30] まさに魔法のようだ。というのも、[00:08:35] 戦略的であり、ビジネス上の成果を把握し、[00:08:40] プロダクトセンスを持ち、ユーザーを理解していれば、こうした迅速なフィードバックサイクルによって、[00:08:45] 真の実験を大規模に行うことができるんですよね。

[00:08:47] トリシャ・プライス：つまり、もし私たちが「北極星指標」に全精力を注いでいると分かっているなら、それが何であれ、例えば「価値創出までの時間」といった指標に焦点を当てるべき時なのかもしれません。コンバージョン率かもしれないし、リテンション率かもしれません。とにかく、[00:09:00] あなたが向上させようとしているものが何であれ。もし今それを理解できれば、[00:09:05] あなたのユーザーの異なるサブセグメントに対して、3つの異なる方法や100通りの異なる体験を[00:09:10] 試し、フィードバックを得て、[00:09:15] その製品体験を本当に突き詰めることができるでしょう。エンジニアに依頼する前に、[00:09:20] どんな機能を作る必要があるのか。[00:09:25] そうですよね？ 

[00:09:25] チラグ・メータ：エンジニアに関わってもらう前からです。 

[00:09:26] チラグ・メータ：面白いですね。

[00:09:26] トリシャ・プライス：うん。もちろん、パートナーと常に連携し、[00:09:30] 対話を重ねるべきですが、プロトタイプを[00:09:35] 作成して実験し、フィードバックを得るために、エンジニアが実際に手を動かす必要はありません。

[00:09:38] トリシャ・プライス：今は、[00:09:40] 現在のツールがあるので、そんな必要はありません。そして、エンジニアリングが必要になる場面では、私はいつもエンジニアリングこそが私の貴重な[00:09:45]リソースだと思っています。これは貴重なので、本当に賢く使わなければいけません。さて、[00:09:50] エンジニアリングに、ユーザーに愛されるものを大規模に作ってもらう段階になると、[00:09:55] 適切な機能を選び、正しい成果を出せるという自信がとても高くなっています。[00:10:00] なぜなら、プロトタイプで実験やフィードバックループをすでに行い、[00:10:05] それを製品に組み込めるからです。

[00:10:06] チラグ・メータ：うん、そう思います。僕は、[00:10:10] これが本当に大好きだと思います。あなたの言いたいことは、そのシグナルの質がとても高いということだと思います。人々が直面している課題の一つで、私も両方の立場を経験してきました。[00:10:20] プロダクト側とエンジニアリング側の両方で働いてきたのです。エンジニアは、自分たちのプロダクトマネージャーは何も分かっていないと言うでしょう。

[00:10:25] チラグ・メータ：プロダクトマネージャーは、エンジニアは要求が厳しすぎると言うだろう。彼らは私たちの話を全然聞いてくれない。そして [00:10:30] 両者とも正しいのです。うん。[00:10:35] なぜなら、これまで市場や顧客からこれほど質の高いシグナルが得られたことは一度もなかったからです。その結果、[00:10:40] 実際には誰も[00:10:45] 欲しがっていないものを作ったり修正したりして時間を無駄にし、結局は何も解決しないことになるのです。

[00:10:48] チラグ・メータ：つまり、[00:10:50] 今はプロトタイピングのスピードが加速しているので、[00:10:55] 市場に出して顧客に見せるだけでよく、必ずしも完璧に動作したり、[00:11:00] 高度に設計されたり、高い拡張性を持つプロトタイプである必要はありません。しかし実際には、[00:11:05] それが本当に問題を解決しているかどうかという強いシグナルが得られるのです。

[00:11:09] チラグ・メータ：では [00:11:10] そう考えると、そして、この、この[00:11:15] 動きがどこへ向かっているかを踏まえると、結果の部分については、[00:11:20] 結果にずっと早く到達できて、たくさん実験もできる、[00:11:25] とはいえ、やはりコストの問題は残ると思います。[00:11:30] コストは依然として課題であり、企業も注目しています。私たちがアドバイスしている企業やクライアントからは、[00:11:35] 「終わりのない[00:11:40] 実験はしたくない」といった質問がよくあります。

[00:11:41] チラグ・メータ：それに、たとえ[00:11:45] AIの助けを借りても、やはり費用はかかります。では、[00:11:50] どのような提案がありますか？コスト面ではどのような状況が見られますか？どうすれば[00:11:55] 予算内で試行錯誤を続けつつ、[00:12:00] 素晴らしい成果を出せるのでしょうか？まさに「ケーキを持ちながら食べる」ようなものですが、AIによってそれが実現できることを願っています。

[00:12:04] トリシャ・プライス：うん、できると思うよ [00:12:05]。ねえ、そうね、[00:12:10]「よくやったな」とか「予算内に収めてプロジェクトをやり遂げた」とか、[00:12:15]自分に誤った安心感を抱いてしまうのは、とても簡単だと思うの。[00:12:20] 結果にこだわらないとき。ねえ、うん、プロジェクトは今なら仕上げられるよ [00:12:25]。僕が作ったもの、すごいだろ？また、その逆のケースも考えられると思います。[00:12:30] つまり、延々と実験を繰り返しても、[00:12:35] 結果につながらないこともあるということです。

[00:12:36] トリシャ・プライス：ですから、私としては、[00:12:40] ROI（投資対効果）を重視するかどうかは、問題ではないと思います。もちろん、誰もがそうあるべきですが、[00:12:45] 特にAIの世界において、エンジニアリングや技術的な製品は、開発コストも高く、[00:12:50] 維持コストも高いものです。したがって、ビジネスパーソンとして、自分自身やチームがROIに対して責任を果たすことは、極めて重要です。

[00:12:57] トリシャ・プライス：もしそうしているなら。そしてあなたは[00:13:00]、「今これだけの予算を投じ、これだけの時間をかけ、[00:13:05] 何かを世に出すために計画を立てた」と言うのです。[00:13:10] 成果に焦点を当てているなら、10回の実験で済んだのか、それとも100回や200回か、といったことには目を向けていない。[00:13:15] 重要なのは、「成果をもたらす製品を提供できたか」という点に集中しているのだ。

[00:13:18] トリシャ・プライス：ですから、[00:13:20] それがチームに責任を持たせる方法だと思います。そして、実際に実験を行った方が、[00:13:25]成果を得られる可能性は、単に数回のアンケートを実施したり、数回のZoom会議を行ったり、数人の[00:13:35]主要顧客と話をして誤った安心感を抱くよりも、はるかに高いと思います。というのも、[00:13:40] つまり、人々が購入したり[00:13:45] 使ったりする製品を作ることこそが重要ですが、プロダクトセンス[00:13:50] やプロダクトテイストについて語る際、往々にして重要なのは細部にあるからです。重要なのは、細部にまで気を配ることです。そうすることで、人々は[00:13:55]また戻ってきて、何度も繰り返し利用したくなるようになり、それが[00:14:00]価値を生み出すのです。彼らにとって欠かせないもの。そして、かなり本格的な実験を行わなければ、[00:14:05] あのレベルの詳細には到底到達できないでしょう。

[00:14:08] トリシャ・プライス：ですから、[00:14:10] 実験はROIの妨げにはならないと思います。むしろ、[00:14:15] 実験こそがROIを生み出すものだと考えています。しかし、いずれにせよ、[00:14:20] 指針となる指標を把握しておらず、絶えず測定を行っていなければ、成果は得られないでしょう。[00:14:25] 

[00:14:25] チラグ・メータ：つまり、試行錯誤ですね。まるで[00:14:30] 研究室のようですね。物理的な研究室でないといいんですが、でも、どうやら…… 

[00:14:34] トリシャ・プライス：[00:14:35] ええ。

[00:14:35] チラグ・メータ：……ご存知の通り、私たちは以前よりもはるかに多くの実験を行っています。 [00:14:40] それに、私はよく冗談で、[00:14:45] チーフ・プロダクト・オフィサーという立場から、「チーフ・プロダクト・オフィサー、つまり私たちの『チーフ・バックログ・オフィサー』は、バックログの上に座っているようなものだ」と言っていたんです。そう、それが、[00:14:55] 昔はよくあったことなんです。それに、十分な成果を出すことができなかったからです。

[00:14:58] チラグ・メータ：そして、[00:15:00] やるべきことは常に山積みでした。今、あなたが提唱しているのは、[00:15:05] 「実験なしでは物事を正しく行うことはできない」という考え方であり、[00:15:10] 実験を行うためのスキルが必要だということです。機能や成果とか、そういったものをわざわざ作らなくてもいいんです。しかし [00:15:15]、何がうまくいっていて、何がうまくいっていないのかを、しっかりと理解する必要があります。

[00:15:18] チラグ・メータ：では、[00:15:20] あなたはこの「リサーチラボ」という概念、あるいはより広範な分野の一部としての、リサーチ主導型や実験主導型のプロダクトマネジメントについて、どのように考えていますか？[00:15:25] [00:15:30] 

[00:15:30] トリシャ・プライス：そうですね、それは先ほど[00:15:35]お話ししたことに帰結すると思います。つまり、解決しようとしている問題について極めて深い理解を持ち、ユーザーや彼らが果たすべき役割に対して共感と理解を持つ必要があるということです。

[00:15:46] トリシャ・プライス：しかし、同様に、[00:15:50] どのように測定すべきか、そして成功とはどのようなものかを理解する必要があると思います。それに、[00:15:55] 私が時間を費やしているのは、そしてあなたも同じように世界中のプロダクトリーダーたちと[00:16:00]交流する機会があることを知っています。彼らはARRを伸ばそうとしているって分かってるよね？ [00:16:05] 新製品でARRを500万ドル、1000万ドル、何であれ[00:16:10]必要だと分かっているんだ。

[00:16:10] チラグ・メータ：今日は1,000万ドル、年末には1億ドル。

[00:16:13] チラグ・メータ：はい。 

[00:16:14] トリシャ・プライス：うん。彼ら [00:16:15] はそれを知っている。それは質問ではありませんが、プロダクトにおける[00:16:20]北極星指標でもありません。それは先行指標ではなく、遅行指標です。 

[00:16:23] チラグ・メータ：それは遅行指標ですね。[00:16:25] わかりました。うん。面白いですね。 

[00:16:26] 

[00:16:26] トリシャ・プライス：それには時間がかかりますよね？今週、機能[00:16:30]や新製品をリリースしたことが、ARRの増加につながっているのかどうかは分かりません。

[00:16:34] トリシャ・プライス：[00:16:35] それにはすごく時間がかかります。それで、考え始めなければならないのは、[00:16:40] 研究室で難しいのは、一体何を測定すべきかということです。[00:16:45] そうですよね？最終的にARRを牽引することになる、重要な「北極星指標」とは何でしょうか？例えば、最終的には単に、人々が[00:16:55]ログインしているかどうか、ということになるかもしれません。

[00:16:55] トリシャ・プライス：よし、ログインしている。彼らはやるべき仕事をこなしているでしょうか。そして[00:17:00]、私の製品を使うことで、購入する前よりも早く仕事を片付けることができるでしょうか？それなら［00:17:05］、まあ、そうかもね。実際のところ、彼らは［00:17:10］ワークフローを完了させているのかもしれないけど、でも。あるいは、彼らが取引を完了させているのかもしれません[00:17:15]が、特にAIが普及したこの時代において、真の価値は、彼らが何もする必要がないことにあるのかもしれません[00:17:20]。

[00:17:21] トリシャ・プライス：そこで、[00:17:25] 分析や指標、成果について考え始めると、事態は実に興味深く、複雑になってきます。というのも、[00:17:30] 本当の価値とは、その人が何もする必要がないことにあるかもしれないからです。でも、とにかく[00:17:35]完了するだけだ。それは、あなたが構築しているエージェントによって行われます。 

[00:17:37] チラグ・メータ：うん。そうは言っても、最高のユーザーインターフェース[00:17:40]とは、インターフェースがないことなんです。

[00:17:41] トリシャ・プライス：うん。本当に。あなたの製品では何もしたくない。ただ、[00:17:45] うまくいけばいいだけなんだ。そうね。ですから、先ほどお話しになったような考え方、つまり[00:17:50]「最高のユーザーインターフェースとは、私が何もしなくて済むことだ」という考え方は、とても重要だと思います。そして、あなたは[00:17:55]それが正しく完了したという自信を私に植え付けてくれているんです。そういうふうに考えなければならないんだ。

[00:17:59] トリシャ・プライス：そして[00:18:00]、この研究ラボを運営するにあたって、私たちは3つの異なる取り組みを試みる予定です。どれが[00:18:05]信頼を築いたのでしょうか？どれが最も効率的だったのでしょうか？どれが最も質が高かったでしょうか？ [00:18:10] そして、それらをどのように組み合わせて、この体験を完璧なものにすればよいのでしょうか？ [00:18:15] 

[00:18:15] チラグ・メータ：信頼、効率、そして品質。興味深いですね。そして、[00:18:20] 好きなように優先順位をつけることができます。

[00:18:22] チラグ・メータ：仕事の内容が[00:18:25]単に信頼を得ることだけなら、効率を追求したくないこともあるでしょう。その場合は、その指標だけに集中すればいいのです。つまり、これは[00:18:30]製品のライフサイクルにつながると思います。というのも、[00:18:35]ライフサイクルの特定の一部分[00:18:40]だけで仕事をしているということは決してないからです。ライフサイクルにおいて、あなたは常にプロダクトマネージャーやプロダクトリーダーとして……

[00:18:44] チラグ・メータ：あなたは今、[00:18:45] 何か新しいものを築き上げているところです。あなたは現在進行中の事態を収拾しつつ、火消しに追われている。[00:18:50] 事態が深刻化しており、あなたは電話対応中だ。そう、まさにその通り。それが、つまり、[00:18:55] すべてのプロダクトリーダーやプロダクトマネージャーが実際に送っている生活なんです。ただ、重要なのは、[00:19:00] 発見から提供までのプロセスにおいて、Pendoの一部として、そしてPendoのプラットフォームや製品の一部として、[00:19:05] まさにこのライフサイクルのど真ん中に位置しているということです。[00:19:10] 何が変化しているのでしょうか？AIがライフサイクルのあらゆる側面に影響を与えていることは承知しています。[00:19:15] 良い影響を受けたケースもありました。中には、あまり良い意味ではないものもある。あなたはどう見ていますか？ [00:19:20] 

[00:19:20] トリシャ・プライス：ええ、確かに製品開発のライフサイクルは変化していると思います。[00:19:25] とはいえ、以前から反復的なプロセスが長く続いていました。そういえば、「ねえ、[00:19:30] ビジネス成果を明確にしよう」って話があったよね。計画を立てましょう。デザインを作りましょう。[00:19:35] フィードバックを集め、開発し、状況を把握し、そしてリリースしましょう。特にB2Bソフトウェアにおいては、現場の顧客が活用できるように支援しましょう。[00:19:40] そして、成果を測定し、そこから学びましょう。[00:19:45]そして、ある意味、最初からやり直すような感じですね [00:19:50]。今や、ビジネス成果の定義から[00:19:55]設計、構築、フィードバックの収集までが、すべて[00:20:00]一体となっているのです。なぜなら、これらのプロトタイピング[00:20:05]ツールを使えば、まるで本物のような、そして実際に本物であるものを構築し、そこから[00:20:10]フィードバックを得ることができるからです。

[00:20:11] トリシャ・プライス：その「ダブルダイヤモンド」プロセス全体[00:20:15]やライフサイクルのその部分が[00:20:20]すべて一つにまとめられてしまって、まるで「ねえ、目指すべき成果があるんだ」[00:20:25]という感じで、実行すべき様々な実験が山ほどある、といった感じですね。そして、その多くは[00:20:30]ビルドの前に起きています。つまり、以前私たちが「ビルド」と呼んでいたものは[00:20:35]、まず最低限の機能をリリースして、それに対するフィードバックを得て、改善を重ねていくものだったと思います。[00:20:40] 

[00:20:40] トリシャ・プライス：さて、もしビルドが真のエンジニアリングビルドのようなものであれば、それは[00:20:45]たくさんのプロトタイピングを経て、[00:20:50]作りたい製品や何がうまくいくかについて、より確固たる見通しが立った後に実施されるものです。[00:20:55]つまり、[00:21:00]ライフサイクルの最初の段階を本当に加速させるようなものなのです。 

[00:21:01] チラグ・メータ：大手金融会社のバイヤーの一人と話していた際、[00:21:05]彼らが教えてくれたのは、[00:21:10]従来型のスプリントを採用しているということでした。この2週間の間に、「スプリントゼロ」という概念があり、これはデザイナーやプロダクトマネージャー、エンジニアが一堂に会するというものです。計画を立てたり、その他の準備を行います。そして彼が[00:21:25]私に言ったのは、スプリントゼロの終わりには実際に製品ができているということでした。[00:21:30]ただし、それは動作する製品ではありません。

[00:21:32] チラグ・メータ：実際にリリースするものではありません。[00:21:35]しかし、スプリントゼロは計画のためのものではありません。ご指摘の通り、ダブルダイヤモンドは存在しません。 

[00:21:39] トリシャ・プライス：そうよね？ 

[00:21:39] チラグ・メータ：[00:21:40] スプリントゼロの終了です。あなたは一部を納品していて、[00:21:45]実際にリリースする予定のバージョンの一部を提供しているのです。そしてビルドが始まります。ご指摘の通り、人々が参加し始め、今や「さて、これをどうやって形にすればいいんだろう？」という段階ですね。

[00:21:55] チラグ・メータ：このシステムが確実にスケールし、適切なコンプライアンスを満たしていることをどう確認すればよいでしょうか？そして、[00:22:00]ここもまた銀行です。 

[00:22:01] トリシャ・プライス：うん。 

[00:22:01] チラグ・メータ：いろいろなルールがある。そして、[00:22:05] 製品部門以外のリーダーたちからも、[00:22:10] こうした声が聞かれるようになっていると思います。そして、これはCFOたちからの声なのですが、[00:22:15] ついに、ようやく「これで使えるツールができた」という感じです。

[00:22:18] チラグ・メータ：そして、プロダクトチームを評価するための共通のマトリックス、すなわち共通の指標セットができるのです。というのも、以前はおっしゃっていたように、[00:22:25]みんな「さあ、いくつかリリースしてこよう」と言って出て行ってしまうようなことがあったからです。ARRが増加するかどうかは、年末までわからないだろう [00:22:30]。だから、チームにその責任を問うことはできない、本当にできないんだ。だって、それってあまりにも複雑すぎるから。

[00:22:37] チラグ・メータ：じゃあ、どうすればいいの？ですから、[00:22:40] こうした成果や、早期に検証結果を得られるという点を踏まえると、[00:22:45] 製品開発以外のリーダー層も、[00:22:50] 開発ライフサイクルに積極的に関与するようになってきていることがわかります。お客様にもそのような傾向が見られますか？もう、製品そのものを超えているのでしょうか？ [00:22:55] 

[00:22:55] トリシャ・プライス：もちろん。つまり、まず第一に、私たち自身も[00:23:00]、そして同僚たちもまた、プロダクトリーダーとして、私たちが作ったものを使っている人々に対して責任を持つことができると思います。[00:23:10] 

[00:23:10] トリシャ・プライス：そして、それらは価値を提供できているのでしょうか？そして、製品[00:23:15]のスコアカードが経営陣に提示される必要があると思います。つまり、人々が計画する「岩」のようなものですね。[00:23:20] つまり、これらはビジネスレベルの議論です。予算が無限にあるわけではないのと同じように、[00:23:25] 素晴らしい新アイデアも無限にあるわけではありません。しかし、CFOやCEO、[00:23:30] そして実際には経営陣全体が、プロダクト部門やエンジニアリング部門に対して説明責任を求めているのです。[00:23:35] 

[00:23:35] トリシャ・プライス：出荷した製品は、実際に使われていますか？そこで、Pendoが大いに役立ちます。[00:23:40] ええと、そして、単に利用しているだけでなく、そこから価値を得られているのでしょうか？そして [00:23:45] それが会社の収益につながるわけですよね？ですから、私は[00:23:50]、これが経営陣全体で議論されるべき幅広いテーマであり、[00:23:55]間違いなく重要な課題であると考えています。

[00:23:57] トリシャ・プライス：財務やCFOは[00:24:00]これを非常に重視するでしょうが、CROだってそうですよね？CROたちも、[00:24:05] いわゆる“バケツに穴が開いている”状態、つまり顧客が流出している状況をよく理解していますよね？ 

[00:24:07] チラグ・メータ：うん。 

[00:24:07] トリシャ・プライス：これは、製品を販売しているあらゆる[00:24:10]ソフトウェア企業において非常に当てはまることであり、顧客が契約を更新しない場合、[00:24:15] それって問題ですよね？そして、CROたちは新規顧客を獲得するために多大な労力を費やしています。

[00:24:19] トリシャ・プライス：そして [00:24:20] 顧客を失っているとしたら、それは大きな問題です。そして、その製品には[00:24:25]間違いなく説明責任があります。つまり、ここもまた、CROがログインして[00:24:30]「私たちが販売した製品を顧客が使っているか？」と確認するのに最適な場所です。そして、そのデータを活用して、「この顧客は健全か、赤、黄、それとも緑か？」といったリスクに関する議論を進めることができます。[00:24:35][00:24:40]

[00:24:42] トリシャ・プライス：さて。つまり、CROは[00:24:45]、目標数値を達成するという点において、そのことを非常に重視しているのです。 

[00:24:47] チラグ・メータ：うん。ある[00:24:50]会社と話をしていたんですが、そこはソフトウェア会社で、かなり迷走している会社なんです。そして [00:24:55] 彼らは、プロダクトチームへの資金提供の仕組みや、[00:25:00] 顧客リテンションの向上を図ろうとしています。[00:25:05] 製品リテンションに特化した非常に明確な予算枠があり、彼らはそれに準じた仕組みを取り入れていました。

[00:25:09] チラグ・メータ：通常は[00:25:10] 市場開拓チームが資金を拠出していましたが、過去には「ねえ、[00:25:15] この顧客との契約更新が近づいているんだ」といったような、一度きりのケースが多かったのです。「何かおかしなことが起きている。もう動かなくなったこの2つの機能[00:25:20]を直してくれないか。」つまり、現在導入されているのは「顧客維持予算」です。[00:25:25] これは、顧客との契約を更新できるかどうかに直接結びついています。

[00:25:29] チラグ・メータ：[00:25:30] 私がエンタープライズソフトウェアに携わる方々や、そうでない方々に説明していることの一つは、エンタープライズソフトウェアがコンシューマー向けソフトウェアとどのように異なるかという点です。[00:25:35]貴社の購入者は、[00:25:40] エンドユーザーではありません。 

[00:25:41] トリシャ・プライス：うん。 

[00:25:41] チラグ・メータ：あなたに対して支払いを行う顧客は、実際にソフトウェアを利用しているユーザーとは異なり、ソフトウェアの購入判断にほとんど影響を与えません。

[00:25:52] チラグ・メータ：よくあることです。特に大企業では。一方、[00:25:55] 消費者向けソフトウェアの場合は、自分のお金、つまり自分の財布から支払いを行います。そして [00:26:00] ですから、実際に何を使うか、何を使わないかについては、あなた自身が決めることができます。 

[00:26:03] トリシャ・プライス：うん。 

[00:26:03] チラグ・メータ：そして、[00:26:05] AIの急速な進化によってライフサイクルが短縮される中で、エンドユーザーが継続的にログインしていること自体が、何かをしているか否かにかかわらず、非常に重要なポイントになっていると考えます。

[00:26:22] トリシャ・プライス：うん。 

[00:26:23] チラグ・メータ：それでは、少し[00:26:25] AIの話に切り替えましょうか。数分間。 [00:26:30] 現在、AIが[00:26:35]ライフサイクルや業務の進め方に影響を与えているのは明らかです。なぜなら、AIを使って[00:26:40]X、Y、Zを行うようになっているからです。しかし、現在多くの企業は[00:26:45]単にAI製品を開発しているだけであり、そのソフトウェアは以前とは大きく異なっています。

[00:26:49] チラグ・メータ：そのソフトウェアは[00:26:50]、これまでに見たものとはまったく似ていません。おそらく[00:26:55]、私たちが知っているコンポーネントのいくつかが使われているのでしょう。それでもクラウド上で動作しており、おそらくコンテナも利用しているでしょうし、[00:27:00] APIを使用し、特定のSDKをテストしています。しかし[00:27:05]、ソフトウェアの開発プロセスそのもの、つまり、モデルを学習させたり、エージェントを構築したり、[00:27:10] これらのエージェントやモデルをデプロイしたりする手法から、顧客データ[00:27:15]や自社データを扱う方法に至るまで、そのすべてが関わってくるのです。

[00:27:17] チラグ・メータ：これは、これはとても複雑だ。 

[00:27:19] トリシャ・プライス：うん。

[00:27:19] チラグ・メータ：では[00:27:20]、具体的にどのような支援を行っているのですか。人々は、いわゆる「AIネイティブ」[00:27:25]な製品を作っているのでしょうか？ 

[00:27:26] トリシャ・プライス：そうですね、まず、アナリティクスの原点であるPendo [00:27:30]に立ち返ってみると、私たちは、機能が実際に[00:27:35]利用されているかどうか、ユーザーがタスクを完了するためにどのようなワークフローやクリック経路をたどっているのか[00:27:40]を把握し、それを深く理解して最適化できるよう支援してきました。

[00:27:44] トリシャ・プライス：ええと[00:27:45]、エージェント体験でも同じことが必要ですが、実際には[00:27:50]クリックという概念はないんですよね？質問を入力したり、会話を交わしたりしていますが、[00:27:55]共通点も多い一方で、[00:28:00]違いもたくさんあります。共通点があるとはいえ、私は依然として価値を得る必要があります。[00:28:05]ソフトウェアについて質問しに来ました。

[00:28:06] トリシャ・プライス：レポートを実行したりダッシュボードを確認したりしたのか、[00:28:10]それともエージェントに質問をしたのか？いずれにせよ、正しい[00:28:15]回答が必要です。さて、エンジニアリングチームとプロダクトチームの間には、大きな違いがあります。[00:28:20]従来のQlikのSaaSの世界に戻ってみると、[00:28:25]物事が「正しい」かどうかは、かなり[00:28:30]白黒はっきりしていたでしょう？ユニットテストケースを作成しました。

[00:28:33] トリシャ・プライス：たとえAPI [00:28:35] の呼び出しだったとしても、結果は「はい」か「いいえ」で返ってきて、動作しました。私たちはそれをクリックした。[00:28:40] そう、返事が来たんだ。しかし、[00:28:45] 会話をするということになると。それは単純な二者択一ではない。正解が一つだけとは限りませんよね？[00:28:50] 相手側には訓練を受けたエージェントがいて、複数の回答が正解となり得ます。[00:28:55]

[00:28:55] トリシャ・プライス：したがって、品質を理解し、評価を正しく行うことは、[00:29:00] エージェント主導の体験を構築する私たち全員にとって非常に重要です。[00:29:05] また、プロダクトマネージャーとして、自分たちが構築しているエージェントがどのような会話をし、どのようなワークフローを完了しているのか、[00:29:10] そしてユーザーベースが何を達成しようとしているのかを理解できるようになることも重要です。[00:29:15]

[00:29:18] トリシャ・プライス：彼らが画面を開いてX、Y、Zをクリックしたとき、彼らが何をしようとしていたのか、なんとなく分かっていましたよね。さて、次は[00:29:25]会話の内容を確認する必要があります。同じレベルの知識を持つこと。そして、Pendoにとって、この1年間、[00:29:30]「エージェント・アナリティクス」と呼ばれる機能の構築に注力してきました。[00:29:35]これは、プロダクトマネージャーがユーザーとの会話を深く理解し、ユーザーが[00:29:40]何を達成しようとしているのかを把握できるよう支援するためのものです。

[00:29:42] チラグ・メータ：面白いですね。さて、[00:29:45] 実は私たちも顧客も含めて、[00:29:50] これまで話してきた中で、少なくとも現時点では明確な答えが出ていないことの一つが[00:29:55] あるという点です。チームをどのように構成すべきか、そして[00:30:00]、かつてプロダクトマネージャーとデザイナー[00:30:05]、そしてエンジニアの間には黄金比のようなものがありました。マイクロソフトには独自のやり方があり、大企業である[00:30:10]Googleはまた別のやり方を採っていました。

[00:30:12] チラグ・メータ：そして業界も、ある意味その[00:30:15]ような形を取り入れたので、私たちにとっては問題なかった。私たちは、御社にとって理想的な比率がどのようなものか、だいたい理解していたと思います。[00:30:20]何をしていても。あれ、崩れかけてる。[00:30:25]のその比率は、もはや当てはまらないと思います。また、こんな話も耳にします。これはちょっと[00:30:30]残念なことなのですが、「ジュニアエンジニアならAIで代用できる」といった具合に。

[00:30:34] チラグ・メータ：もう、大学から誰かを[00:30:35]採用する必要はないんだ。それは明らかに事実ではない。[00:30:40] 同僚たちは、エントリーレベルの仕事をAIに置き換えられるなんて、今まで聞いた中で最も奇妙な考えの一つだと思っているようです。[00:30:45]そこには、そんなものは存在しない。私たち、このことは[00:30:50]前から知っていました。

[00:30:50] チラグ・メータ：でも、あの考えについて、人々は今でも考えているんですよ。[00:30:55] なんだか、そういう意味ではちょっと変だよね。それについてどう思いますか？[00:31:00] その割合は変わっていると思いますか？それって同じことだと思いますか？AI製品を開発するにつれて、チームの構成は[00:31:05]変化していると思いますか？ 

[00:31:07] トリシャ・プライス：それは、[00:31:10] 開発している製品の種類や所属しているチームによって異なると思います。

[00:31:12] トリシャ・プライス：だって、AIファーストの[00:31:15]製品だって、たいてい何らかの[00:31:20]バックエンドの独自技術があるじゃないですか？作業が行われている場所、[00:31:25] データが保存されている場所、分析が処理される可能性のある場所、そしてそれらのチームは[00:31:30] 以前と変わらない姿をしているかもしれません。しかし、[00:31:35] 一般的に言えば。AIはエンジニアリングにスケール感[00:31:40]とスピードをもたらしています。

[00:31:41] トリシャ・プライス：優れた設計上の判断を下すことができるだろうか？まだそうは思いません[00:31:45]。では、不安定な[00:31:50]基盤の上にソフトウェアを構築し、不安定なユーザー体験を生み出してしまうことになるのでしょうか？可能です。それは、優れたアーキテクチャを構築した優秀なエンジニアたちをさらに強化できるのでしょうか？そして、強固な基盤を築き、それに[00:32:00] 規模とスピードを与えることができます。私は確かにそのような現象が起きているのを見ており、それが今後さらに拡大し続けると考えています。

[00:32:06] トリシャ・プライス：つまり、プロダクトマネージャーがプロトタイピングツールを使うことで得られる効率性を掛け合わせると[00:32:10]、そして[00:32:15]、実験[00:32:20]段階や発見段階でエンジニアリングの時間を無駄にせず、エンジニアリングに入る頃には[00:32:25]提供する成果により自信を持てるようになるのです。私は確かに、プロダクトとエンジニアリングの比率が変化している現場を目の当たりにしています。そして、かつては優れたプロダクトを作るために、プロダクトマネージャー1人に対して7～8人のエンジニアが必要だった可能性がありました。

[00:32:43] トリシャ・プライス：今では、同じ素晴らしい製品を作るのに、プロダクトマネージャー1人とエンジニア3～4人、時には2人で[00:32:50]十分な場合もあるでしょう。しかし、結局のところ、それはプロダクトマネージャーが[00:32:55]理解しているかどうかにかかっています。その成果として、[00:33:00]非常に優れたプロダクト感覚を持ち、リサーチラボを通じて体験をキュレーションしているのです。そして、[00:33:05]エンジニアリングが最高水準のアーキテクト、つまり基盤構築において卓越したエンジニアであること、そして[00:33:15]AIを活用してそれをスケールさせることにかかっています。

[00:33:16] トリシャ・プライス：私は確かにそのようなことが起きているのを見ています。 

[00:33:18] チラグ・メータ：[00:33:20] あなたがそうおっしゃるのは興味深いですね。私も以前、[00:33:25]人々がAIの最大の隠れた側面を[00:33:30]誤解していると説明したことがあります。当初、AIは一種の効率化、[00:33:35]エンジニアリングの効率化として捉えられていました。つまり、コードを書き、[00:33:40]コードを出荷し、テストケースを作成できるのは素晴らしいですが、それが最大の推進力だとは私は思いません。

[00:33:44] チラグ・メータ：これは[00:33:45]誰もが活用すべき手近な解決策だと思います。もし[00:33:50]AIがコードを書けるなら、AIにコードを書いてもらうべきです。その通りです。そうする必要はないけど、[00:33:55]それが最大の突破口だとは思わない。最大の鍵は、[00:34:00]最初に正しい決断を下すことです。[00:34:05]そうすれば、あなたが言及しているような規模とスピードが得られます。

[00:34:08] チラグ・メータ：つまり、かつては[00:34:10]たとえ人々が間違った判断やあまり良くない判断を下したとしても、[00:34:15]結局は多少の労力が無駄になるだけで、それほど大きな意味はありませんでした。そして、1年、1年半もかかり、その頃には[00:34:20] 何が起きたのかさっぱり分からなくなってしまいます。[00:34:30]ですから、私がこれまで一緒に仕事をしてきたり、アドバイスをしてきた多くの優秀なプロダクトマネージャーたちは、自分たちの優れた判断が正当に評価されていないという現実に、非常に不満を抱いていました。

[00:34:33] チラグ・メータ：たとえ優れた[00:34:35]プロダクトセンスを持っていたとしても、結局はチーフ・バックログ・オフィサーになってしまいました。だって、[00:34:40]これからどうすればいいんでしょうか？素晴らしい決断ですね。これが必要なのは間違いない。[00:34:45]これを求めている顧客がいます。収益を上げられることは分かっています。私たちは[00:34:50]結果を出せると分かっていますが、実際にはそれを実行に移すことができませんでした。

[00:34:54] チラグ・メータ：では、[00:34:55]どのように推進し、AIをどのように活用するのでしょうか？事前に十分な情報に基づいた意思決定と判断を下すことで、最終段階ではその規模とスピードを活かし、実際に[00:35:05]より迅速に変化を起こすことができるのです。なるほど、それは興味深いですね。これは素晴らしいです。[00:35:10]最後に一つだけ質問させてください。もし[00:35:15]プロダクトリーダーに一つだけ[00:35:20]重要なポイントを持ち帰ってほしいなら。

[00:35:20] チラグ・メータ：この会話の中で、もし一つだけ覚えてもらえるとしたら、それは何でしょうか？[00:35:25] 

[00:35:26] トリシャ・プライス：一番重要なのは、[00:35:30] 非常にしっかりとした製品スコアカードを用意し、[00:35:35] 達成しようとしている成果を明確に理解することだと思います。そして、私が言っているのは、単にそのレベルの[00:35:40]売上高のことだけではなく、そうした成果を牽引する先行指標となる具体的な製品指標のことであり、[00:35:50]その成果を達成するために、研究ラボを設立し、絶え間なく実験を重ねることです。[00:35:55]

[00:35:56] チラグ・メータ：すごい。トリシャ、本当にありがとう。これは[00:36:00]、素晴らしい会話でした。本当に楽しかったです。ありがとうございます。 

[00:36:03] トリシャ・プライス：うん、シャード、ありがとう。[00:36:05] こちらにお招きいただき、ありがとうございます。 

[00:36:06] トリシャ・プライス：「Hard Calls」をお聴きいただきありがとうございます。本ポッドキャストでは、成功に必要なベストプラクティスやあらゆる情報を発信しています。[00:36:10]今日の番組[00:36:15]を楽しんでいただけたなら、ぜひお友達にもシェアして、また[00:36:20]お越しください。