Cat Wu氏の見解では、AI時代のプロダクトマネージャー（PM）に最も求められるコア能力は、アイデア創出からユーザー提供までの時間を短縮し、「箱を開けてすぐ使える」コアタスクを定義することだ。かつてPMは6～12か月先のロードマップを描くのが常套だったが、今やAnthropic内部では、機能がアイデア段階からリリースまで、なんと最短1日で完了する！
多くの人がAnthropicが後発でありながらなぜ優位に立てたのか不思議に思っているが、Cat Wuが示した答えは、チームメンバーのミッションが一致していることだ。彼らは採用時に「全人類に安全なAGIをもたらすことを最も重視する人材」だけを選ぶ。彼女は、会社全体のAI安全ミッションのためなら、たとえ自身が担当する製品ライン（例えばClaude Code）が犠牲になっても全く構わないとまで言い切った！
このポッドキャストには他にも多くの素晴らしい視点が含まれている。インタビュー原文は以下の通り：
Boris Chernyは目標設定に長け、Cat Wuは部門横断協力で実現を担う
Lenny： Catさん、ようこそポッドキャストへ。
Cat Wu： お招きありがとうございます。
Lenny： 聞きたいことが山ほどあります。お招きできて本当に興奮しています。まずはあなたとBoris氏の役割分担について皆さんに理解してもらいたいです。Boris氏のことは皆さんご存じでしょう。彼のエピソードは当ポッドキャストで最も人気の回になりました。プレッシャーに感じないでくださいね。彼はClaude Codeを生み出し、チームを率いています。毎日スマホからでも無数のPR（プルリクエスト）を提出していて、その数が今どれくらいか私には見当もつきません。Claude Code、Cowork、そして皆さんが構築しているすべての成果に対して、あなたの功績が過小評価されている気がします。チームにおけるあなたの役割、Boris氏との協業方法、責任の分担について理解を深めさせてください。Claude CodeチームにおけるPMの役割とは具体的にどのようなものですか？
Cat Wu： Borisと仕事ができて本当に幸運だと思います。彼は常に素晴らしい思考のパートナーです。彼は私たちの技術責任者であり、大部分において製品のビジョンリーダーでもあります。彼は目標設定が非常に上手く、例えば「3か月後、6か月後に製品はどうあるべきか」、つまり製品の「AGIの究極形態」を描くのです。一方で、私の役割の大部分は、現状からどうやってその3～6か月先のビジョンに到達するかを具体化することです。私はより多くの時間を部門横断的な協業に費やし、マーケティング、営業、財務、計算リソースなどのチームが計画に同意していることを確認し、皆が同じ方向を向き、力を合わせられるようにします。そして機能の準備が整ったら、リリースプロセスに一切の障壁がないようにします。多くの点で、私たちは一種の「思考融合」を達成しているため、相性が良いのだと思いますが、境界線は実際には非常に曖昧です。私たちのアイデアの約80％は同期しており、残りの20％のうち、私が彼よりも気にかけていることは私が主導し、彼が私よりも気にかけていることは彼が推進します。
AnthropicがPMを採用する基準：開発期間の短縮とコア機能の定義
Lenny： 収録前におっしゃっていましたが、あなたは数百人のPMを面接してきたのですね。誰かがAnthropicのPMの口利きを私に頼むたびに5セントもらっていたら、今頃300億ドルの年間経常収益（ARR）があったでしょうね。ここは皆が最も働きたい場所ですから。だから面接した人数がどれほどか想像がつきます。多くの人が間違っており、「AI時代に成功するPMになる方法」についての彼らの理解が間違っているとおっしゃいました。あなたが見ている現象と、人々が今の成功の秘訣として理解すべきことについて話してください。
Cat Wu： AIが登場する前は、技術の進化はずっと遅かったのだと思います。ですから6～12か月先の計画を立てることができました。機能のリリース速度が遅かったため、他のパートナーチームとの調整により重点が置かれ、彼らがリリースする機能が自分の布石となるように確実を期していました。当時はコードを書くコストが非常に高かったからです。しかし今、AIの登場により、エンジニアリング効率が加速し、モデルの能力が向上したおかげで、私たちの多くの製品機能の開発サイクルは6か月から1か月、時には1週間、1日にまで短縮されました。それに伴い、製品を非常に迅速にリリースできるようにする必要があります。つまりPMとしては、複数四半期にわたるロードマップをパートナーチームと整合させることに重点を置くのではなく、「製品を市場に投入する最速の方法を見つけるにはどうすればいいか？」「エンジニアやPMが週末までにアイデアを思いついたら、すぐにユーザーに届けられるような、製品ポートフォリオの『コンセプトコーナー』をどう作り上げるか？」といったことにもっと関心を払うべきだということです。AIネイティブな製品で最も優れた成果を出しているPMは、「アイデア創出からユーザー提供までの時間を短縮し」、製品の中で最も中核的で、箱を開けてすぐ使えるようにすべきタスクを定義できる人たちだと思います。
チームの迅速な行動を支えるPMの責務：明確な目標設定、再現可能なリリースプロセス確立、製品開発プロセス体系の構築
Lenny： 「人々がどれだけ速く走る必要があるかまだ気づいていない」という点、そして今の責務の大部分が「チームが速く走れるよう助けること」というのが、非常に気に入りました。具体的にはどうやって？最先端のモデルを持っていること以外に、あなたとPMチームは人々がこれほど速く動けるように他に何をしているのですか？
Cat Wu： 第一に、明確な目標を設定することだと思います。大規模言語モデル（LLM）は非常に汎用的であるがゆえに、「誰のために作るのか」「どの問題を解決するのか」「中核的なユースケースは何か」といった点に多くの曖昧さが生じています。そのため、優秀なPMはこう言うことができるのです。「よし、私たちのコアユーザーはプロ開発者だ。この機能が解決すべき主な課題は、権限要求が多すぎて疲れてしまうことだ。目標は、企業のプロ開発者が安全に『権限要求ゼロ』を実現できるようにすることだ。」これは非常に明確な目標を設定します。なぜなら、多くの潜在的な解決策を排除し、一度の要求でより多くの作業を完了できるようにするからです。
第二に非常に重要なのは、再現可能なリリースプロセスを確立することです。Claude Codeに関しては、ほとんど全ての機能を「リサーチプレビュー」という形でリリースしています。リリース時にこのラベルを明示的に貼り、ユーザーにこれが初期段階の製品であり、単なるアイデアで、フィードバックを得て繰り返し改善したいだけであり、恒久的にサポートされるとは限らないことを伝えます。これにより、リリースのプレッシャーが下がり、1～2週間でものを作り上げることができるのです。
第三に、PMはチームのためにフレームワークを作成すべきです。いつ部門横断的なパートナーを巻き込むべきか、そして彼らの期待値は何かを知らせるためです。例えば、私たちにはエンジニアリング、マーケティング、ドキュメントチーム間で非常に緊密なプロセスがあります。エンジニアが機能の準備が整い、内部テスト（ドッグフーディング）を経たと判断したら、彼らは私たちの「エバーグリーン・リリースルーム」チャンネルに投稿します。ドキュメント担当のSarah、プロダクトマーケティング（PMM）担当のAlex、そしてTarやLydiaなどのデベロッパーリレーションズ（DevRel）メンバーがすぐに加わり、翌日には市場向け広報アナウンスを展開できます。プロセスが非常に緊密であるため、エンジニアが製品をリリースする際のあらゆる摩擦が軽減されます。そしてPMこそが、このシステムを構築すべき人なのです。
Anthropicの内部アラインメント：厳格な指標と「チーム原則」リスト、数か月がかりのプロジェクトのみPRDを作成
Lenny： PRD（製品要件定義書）はこのプロセスでどのような役割を果たしますか？目標が重要であり、「成功とはどのような状態か」「誰にサービスを提供するのか」について合意することが大事だとおっしゃいました。PRDを書きますか？それとも箇条書き程度ですか？PMの世界では、それはどのように進化していますか？
Cat Wu： 私たちは2つのことを行っています。一つは、非常に厳格な指標を持っており、毎週チーム全体で指標の読み合わせを行っています。その目標は、全員がビジネスのあらゆる側面、中核目標、トレンド、推進要因を深く理解していることを確実にすることです。二つ目は、「チーム原則」リストを保持していることです。これには「誰がコアユーザーか」「なぜ彼らなのか」といったことが含まれます。これらを明確にするのは、チームの全員がビジネスロジックを理解し、何が自分たちにとって重要で、何をトレードオフする用意があるかを理解していると感じられるようにするためです。そうすれば人々は、PMや他のステークホルダーに行く手を阻まれることなく、自律的に意思決定できます。
Lenny： 未来でもまだPMが必要だという感覚が気に入りました。今は「PMなんてなぜ必要？そのまま作ってリリースすればいい。必要なのはエンジニアだ」という言説がたくさんありますからね。
Cat Wu： 特に曖昧さの大きい機能については、1ページのドキュメント（ワンページャー）を書くことは確かに役立ちます。目標は何か、喜ばしいユースケースは何か、現在修正が必要な失敗モードは何かを明確にするのです。時折、特に大規模なインフラを必要とするプロジェクトなど、実際に数か月を要するものもあります。そのような場合は、今でもPRDを書きます。
製品リリースの速さはMythosだけの功績ではない
Lenny： 皆さんがどうやってこれほど速く動いているのか、もう少し深掘りしたいです。Anthropicのようなペースは見たことがありません。誰かが皆さんのリリーススケジュールのカレンダーを作ったほどで、ほぼ毎日、重要な機能や製品がリリースされています。ネットではこう尋ねられています：「リリースしているだけでなく、この信じられないMythosモデル（現在プレビュー段階）を作り上げた。その能力があまりに強力なので、人々は少し恐れさえ感じている。ずっと使っているのか？これがそんなに速く動ける理由なのか？」
Cat Wu： 実は、私たちはこの高速ペースをもう数四半期も維持しています。ですから、これが全てMythosのおかげとは思いません。Mythosは極めて強力なモデルであり、内部で確かにこれらのモデルを使用していて、リリース速度を少しは向上させていますが、速度向上の大部分を説明するものではないと思います。もっと大きな要因は、プロセスとチームの期待値にあると思います。私たちのプロセスは非常に無駄がなく、リリースを妨げるあらゆる障害を取り除きたいと考えています。チームの全員がエンパワーメントされていると感じ、アイデアを構想から現実のものとし、1週間以内、場合によっては1日で世に送り出せることを望んでいます。
Claude Codeソースコード漏洩事件：プロセス上の失敗
Lenny： 最高のモデルを持ちながら、同時に製品も構築しているというのは、あまりにも大きなアドバンテージですね。Anthropicで起きている出来事が多すぎるので、いくつかのエピソードについてお聞きしたいです。約1週間前、Claude Codeの完全なソースコードが漏洩し、誰かがネット上にアップロードしました。誰かのミスだったのだと思います。これについて何か言いたいことはありますか？一体何が起こったのですか？何が間違っていたのですか？
Cat Wu： それを見てすぐに調査を開始しました。これはヒューマンエラーの結果だと認識しました。当時、ある社員がClaudeを使ってPRを作成しており、それは単にソフトウェアパッケージのリリース方法に関するアップデートでした。それは実際に2段階の人間によるレビューを受けていました。ですから、これはヒューマンエラーの結果であり、我々は将来同じことが起きないようにプロセスを強化しました。
Lenny： その人物はまだAnthropicにいますか？
Cat Wu： はい、います。これはプロセス上の失敗であり、最も重要なことは教訓を学び、より多くの防御柵を追加することです。それが私たちが注力してきたことであり、大部分の防御策は既に適用済みです。
OpenClawでClaudeが使えない理由：サブスクリプションプランはサードパーティ製品向けに設計されていない
Lenny： もう一つの質問はOpenClawについてです（注：ユーザーがサードパーティ製ツールを通じてClaudeサブスクリプションを利用することを指す）。最近、人々がサードパーティツールでClaudeサブスクリプションを使うのを阻止する動きがあり、ユーザーは怒り、困惑しています。オープンソースコミュニティへの打撃のようにも感じられます。この決定の背後にある考え方を人々は理解する必要がありますか？
Cat Wu： Claudeに対する巨大な需要を目の当たりにしており、当社はインフラの拡張と、トークン使用におけるフレームワークの効率化に継続的に取り組んできました。サブスクリプションプランは当初、サードパーティ製品向けには設計されておらず、それらの利用パターンは当社の自社製品とは異なります。私たちは、提供できる最もスムーズな移行方法は何か、多くの時間をかけて考えました。ですから、サブスクリプションにいくらかのクレジットが付与されることを発表できて嬉しく思います。しかし、自社製品とAPIを優先する必要があるという厳しい決断を下さなければなりませんでした。これがこの決定の本意です。
Lenny： 私には完全に筋が通っています。皆さんはこの利用法に対して月額20ドルで補助しているわけですが、それはほぼ無制限の使用に近い。人々は企業も利益を出さなければならず、収益化を達成しなければならないこと、計算需要がこれほど巨大な時にタダで提供し続けられないことを理解していないのでしょう。
Anthropicには5つのPMチームがあり、全ての役割が融合している
Lenny： PMチームの話に戻りますが、AnthropicのPMチームはどのようなものですか？何人いて、どのように構成されていますか？
Cat Wu： いくつかのPMチームがあり、現在約30～40名のPMがいます。DianeがリサーチPMチームを率いており、モデルに対する顧客フィードバックの収集と研究チームへの伝達、さらにモデルのリリースを担当しています。Claude開発者プラットフォームチームもあり、Claude Codeを支えるAPIを維持し、「マネージド・エージェント」のような製品をリリースしています。次にClaude Codeチームがあります。そして、エンタープライズチームは、企業顧客がこれらのツールをより簡単に導入できるように、コスト管理、RBAC、セキュリティ管理などを担当しています。最後に、製品ライン全体の成長を担うグロースチームがあります。
Lenny： グロースといえば、以前Amole氏がポッドキャストで非常に興味深い視点を述べていました。「みんな将来はPMの必要性が下がり、エンジニアが直接やればいいと思いがちだ。しかし彼は、エンジニアがあまりに速く走るため、PMやデザイナーがむしろ圧迫され、全ての変化に追いつく時間がないと考えている。だから彼はより多くのPMが必要だと考えている。追いつくのが大変すぎるからだ。」あなたはどう思いますか？PMの採用は増えると思いますか？長期的にこの職業はどうなりますか？
Cat Wu： 全ての役割が融合していると思います。PMはエンジニアリング業務を行い、エンジニアはPMの仕事をし、デザイナーはプロダクトマネジメントを担当しつつコードをコミットしています。より多くの優れたプロダクト審美眼を持つエンジニアを採用するか、エンジニアの採用数を維持したまま、作業を指導するためにより多くのPMを採用するか、そのどちらかです。私たちのチームでは、優れたプロダクト審美眼を持つエンジニアの採用に非常に注力しており、それにより製品をリリースする際のコミュニケーションコストを削減できます。我々のチームの多くのエンジニアは、Twitterでユーザーフィードバックを目にするところから、週末に製品をリリースするまで、ほぼPMの介入なしでエンドツーエンドに完璧に処理することができます。これが最も効率的な方法だと思います。つまり、エンジニアとPMの境界線は重なり合っているのです。
それでもプロダクト審美眼は依然として非常に希少なスキルであり、誰かがこの能力を発揮していると判断した場合、私たちはほぼ例外なく採用してきました。
Lenny： あなたのバックグラウンドはエンジニアリングですね？
Cat Wu： はい。私は何年もエンジニアを務め、Anthropic入社前に短期間VCの経験もあります。実は私たちのチームのPMのほぼ全員が以前はエンジニアであるか、Claude Codeにコードをコミットしています。これがチームの信頼構築に役立ち、より速く動くことを可能にしています。我々のデザイナーでさえ、以前はフロントエンドエンジニアでした。
最も価値のあるコアスキル：プロダクト審美眼（センス）
Lenny： これは大きな問題ですね。境界線が融合している中で、エンジニアリング、プロダクト、デザインのどのバックグラウンド出身であれ、どのコアスキルが最も価値がありますか？
Cat Wu： それでも結局はプロダクト審美眼に尽きると思います。コードを書くコストが下がるにつれ、より価値が高まるのは「何を書くべきか」を決めることだからです。正しいデザイン（UX）とは何か？ユーザー体験が最も快適な方法は何か？私たちは様々な機能を要求する何千ものGitHub Issueを受け取りますが、どれが取り組む価値があるのか？正しいアプローチは何か？を見極めるには、膨大な忍耐力と審美眼が必要です。このスキルはどのようなバックグラウンドからも生まれ得ます。
Cat Wu： そうです。Coworkの能力上限を押し上げる取り組みも見られます。例えば、彼らは複数の顧客を担当しているため、忙しい日には1日5～10回の顧客ミーティングをこなすこともあります。彼らはよく前日の夜にCoworkに「明日のミーティングは？顧客からどんな要望があった？今最も緊急な課題は？過去のミーティングのTODOは？」と要約を依頼します。Coworkはすぐに、次のミーティングに入る前に知っておくべきブリーフィング資料をまとめ上げます。さらにCoworkは、「X機能はいつリリースされますか？」といった顧客からの質問に対し、Slackを隅々まで検索して最新のETAを見つけ出し、メモに追加するといった調査も行います。これらはすべて、メンバーが自身のために構築し、チームで共有している自動化ワークフローなのです。