同じ週に2人のプロダクトマネジャー（PM）が採用された。
1人目──テオと呼ぶことにしよう──は動きが速かった。AIコーディングのプロンプトは一晩で山積みになり、動くプロトタイプを作ってはステージング環境にプッシュし、朝会前にはデモの準備が整っていた。最初の四半期で、彼は7つのAI機能をリリースした。要約、レコメンデーションエンジン、チャットアシスタント、スマート検索バー、自動タグ付け、予測ルーティングツール、センチメント分析ウィジェットである。関係者はそのスピードを称賛し、CEOは全社集会で彼の名を挙げた。
2人目のPM──マヤとしよう──はその四半期で14の仮説を検証した。多くはディスカバリー段階で潰れた。5つは顧客インタビュー後に消え、4つは最もリスクの高い前提のテストに失敗し、3つはROIの計算が合わずスコープから外れた。リリースまで到達したのは2つだ。いずれもトライアルから有料への転換率を測定可能な形で押し上げた。リリース本数だけを見ていた一部の関係者は、彼女を「遅い」と評した。
6カ月後、テオは解雇され、マヤは昇進した。違いは才能ではない。違いは順番にあった。テオはプロダクト・ビルダーとしてだけ動き、とにかく速く作った。マヤはまずプロダクト・エクスプローラーであり、その後にプロダクト・ビルダーとなった。
順番の重要性
「プロダクト・ビルダー」という言葉は、業界全体で一般名詞のように使われている。LinkedInでも、求人票でも、ポッドキャストの紹介でも、多くの「AI PM」講座のランディングページでもそうだ。AI機能をリリースする人をまとめて指す、ゆるい総称になっている。この曖昧な用法こそが、私が本稿を書こうと思った理由である。
他の職種は、仕事を順番で呼び分けているが、プロダクトはそうしてこなかった。営業はすべてを「営業担当」とひと括りにしない。リード獲得、リードの精査、プリセールス、アカウント・エグゼクティブ業務を分けている。異なるタスク、異なるスキル、そして順序がある。リード獲得担当にエンタープライズ案件のクロージングを任せたりはしない。
エンジニアリングもすべてを「エンジニア」でひと括りにしない。データエンジニアはパイプラインを構築する。データサイエンティストはデータをモデル化する。データアナリストは実用的なインサイトを引き出す。
ところが最近のプロダクトは、何でもかんでも「プロダクト・ビルダー」に押し込めている。そうであってはならない。仕事には順番がある。探索が先、構築が後だ。この順序は本質的に重要である。
プロダクト・ビルダーとプロダクト・エクスプローラーの違い
AIによってツールチェーンが民主化され、作るスキルは、ほとんど誰にでもできるものへと圧縮された。
探索するスキルはそうではない。ここで求められるのは、プロダクトの意思決定をCEOが資金を投じる成果へと遡って結び付けること。エンジニアリングがコミットする前に、自分の最良のアイデアを安く反証すること。リリースするよりも多くのアイデアを、意図的に葬ること。こうした行動は、経営層の前で、現実の結果を伴いながら何年も仕事を積み重ねることで複利的に効いてくる。AIは構築の障壁を下げたが、判断の障壁は動いていない。
プロダクト・ビルダーはAIツールを使ってプロダクトをリリースする。かつてないほど速く、安く、完成度高く。プロダクト・ビルダーの超能力はスピードである。一方で盲点は、そのスピードが正しい指標を動かしているかどうかだ。
私は「プロダクト・エクスプローラー」という言葉を、関係者が求める機能をリリースするためではなく、経営層が重視する成果を動かすために雇われる人として用いている。コードが1行も出荷される前に、プロダクト・エクスプローラーは経営者のように考え、発明家のように発見する。つまり、仕事を経営層が説明責任を負う事業成果へと結び付け、提案する解決策がその成果を動かすことを検証する。
順番が重要だ。まずプロダクト・エクスプローラー、次にプロダクト・ビルダーであれ。エクスプローラーの工程を飛ばせば、より速くリリースできる一方で、動かせる事業成果は少なくなる。テストはなく、真実もなく、あるのはスピードだけだ。
探索段階を飛ばすコスト
機能の採用率が低い、クリック率のテストがベースラインを下回る、ユーザー調査で旧来の機能と見分けがつかない、あるいは実際の購買者の関心と結び付いていない──こうした状態では、機能の数は意味をなさない。実際の事業課題を解決していないからだ。
テオの機能は彼を救わなかった。経営層が重視する数字を動かさなかったからである。レイオフの局面でCEOが目にしたのは、四半期丸ごとのエンジニアリング能力が費やされながら、彼が1年を通じて狙っていたトライアルから有料への転換率が動いていないという事実だった。テオは、誤ったものを、速く出荷したことで解雇された。
Inspired: How to Create Tech Products Customers Loveの著者であるマーティ・ケーガンは、この失敗パターンを「プロダクトマネジメント・シアター」と呼んでいる。肩書はPMでも、量は生み出すが価値は生まない人々のことだ。スピードがタダになると、判断の浅い仕事はより速く複利で積み上がってしまう。
プロダクト・エクスプローラーのように考える方法
マヤがリリースした2つの機能は、彼女がテストした14の仮説の結果である。多くは潰れた。しかし残った解決策は効果的だった。
プロダクト・エクスプローラーも、プロダクト・ビルダーと同じ種類の関係者要望から始める。「トライアルのオンボーディングフローにAIを追加してほしい」あるいは「スマートなインポート・ウィザードを作ってほしい」といった要望だ。しかし彼らは、そのブリーフを額面通りには受け取らない。
各仮説について、プロダクト・エクスプローラーは次を問うべきである。
1. これはどの成果に資するのか？ トライアルから有料への転換率が経営の優先事項なら、関係者要望がそこに結び付いていることを確認するか、結び付かないものは保留にする。
2. 仮説は何か？ 「スマートなインポート・ウィザード」は仮説ではない。「10分以内にインポートを完了したトライアルユーザーは、転換率が3倍高い」は仮説である。
3. 最もリスクの高い前提は何か？ それが誤りであれば機能全体が死ぬ仮説である。多くの場合、それは最も恐れているものではなく、証拠が最も薄い前提だ。
4. 最も安い実験は何か？ 多くの場合、クリック可能なプロトタイプ、フェイクドア・テスト、あるいは手作業で提供するバージョンである。
多くの仮説はディスカバリー段階で死ぬ。いくつかはリリースされたプロダクトへと昇格する。しかしその場合、経営層が目にするのは、会社の四半期を実際に動かし得る意思決定である。
プロダクト・エクスプローラーに共通する行動：何から始めるか
プロダクト・エクスプローラーになるために、次の3つの行動を優先せよ。
1. 成果に執着する。 すべての意思決定は、測定可能な事業成果へと遡れなければならない。遡れないなら、保留にするか、葬る。
2. 前提優先の思考を採用する。 作る前に問う。「このアイデアに織り込まれた最もリスクの高い信念は何か。どうすればそれを安く反証できるか」。
3. 殺す判断に慣れる。 本物のエクスプローラーは、リリースするより多くのアイデアを葬る。評価されるのは、どれだけ出荷したかではなく、どれだけ適切に殺したかだ。
PMが担うのは判断である。提供が最も難しい次元であり、自分のアイデアが間違っていることを、公の場で、しばしば認める必要があるからだ。
AIがプロダクト・エクスプローラーのスキルをコモディティ化すると思うかもしれない。だが起きているのは逆である。デリバリーが安くなるほど、誤ったものを作るコストは増す。悪いアイデアから守ってくれるエンジニアリングのボトルネックが、もはや存在しないからだ。
成功するPMは、最速のビルダーではない。最良の意思決定者である。その違いが、人員整理から彼らを分ける。
