プロダクトマネジメントはストーリーテリングである。だから、私がどうプロダクトマネジメントを捉え、AI がそれをどう変えたかについて、一つの物語を通じてお話ししよう。
忘れられない面接の質問
私は RealNetworks でエンジニアとしてキャリアをスタートし、数年後には RealPlayer のプロダクトおよびエンジニアリングチームの責任者を務めていた。当時、RealPlayer は非常に意義深いコンシューマー向けプロダクトだった。数億人のユーザーを抱え、初期インターネットにおける音声・動画配信を支えてきたからだ。ビジネスサイドの人々と会議をするたびに、「プレイヤー起動時に毎回広告を表示すべきだ」といった提案が持ち込まれた。それが正しくないことは分かっていたが、収益予測を示す Excel シートに対して反論する術を持っていなかった。私は「本物の」プロダクトマネージャーになりたいと考え、ビジネススクールに進むべきだと結論づけた。
カリフォルニア大学バークレー校（Berkeley）のビジネススクールに入学した直後、かつて使っていた大学のメーリングリストで LinkedIn が採用活動を行っているのを見つけた。応募すると、Reid Hoffman との面接にこぎ着けた。彼は席に着くと、一生忘れることのない質問を投げかけた。
「プロダクトマネージャー志望とのことですが、プロダクトマネージャーが生み出す成果物（アーティファクト）は何だと思いますか？」
彼はさらにこう説明した。エンジニアの成果物はコードだ。事業開発の成果物は締結された契約書だ。デザイナーはビジュアルやグラフィックを生み出す。CEO には組織図、資金調達計画、そして全員を束ねるビジョンがある。では、プロダクトマネージャーの成果物は？
私は、プロダクトマネージャーにそのような明確な「成果物」があるかどうか確信が持てないが、私たちが根本的に行っているのは、あらゆる事象を集約し、仕様書（spec） に書き起こすことだと答えた。仕様書は設計図であり、要件とこれから行うすべてのことを定義する場所だ。だからこそ、各チームがそこから構築を開始するための鍵となる、社内でも最重要ドキュメントの一つになるのだと。
明らかに緊張していたのだろう。彼はそれを感じ取ったのか、「良い答えだ」と安心させてくれた。結果的に私はその職を得て、ビジネススクールを中退して LinkedIn に参加した。以来、ずっとあの問いを考え続けている。
仕様書からストーリーへの進化
なぜなら、私は 間違った答え をしてしまったからだ。
当時はまだソフトウェア開発においてウォーターフォールモデルが主流だった。LinkedIn では、ソーシャルプラットフォーム上で求人プラットフォームを再想像しようとしていた。採用担当者が相互のつながりという文脈の中で応募書類を確認でき、候補者は求人情報を見て、ネットワーク経由で直接アプローチできるような仕組みだ。この発見のプロセスの中で、私は体験全体と要件を定義した 120 ページもの仕様書を執筆した。
それから何年も経った今、そのことについて深く考えている。あの仕様書は、当然ながら最も重要な成果物などではないのだから。重要なのは ストーリー だ。
仕様書はシステムを記述し、何をすべきか、完了までにどのチェックボックスを満たすべきかを定義する。それはプロダクトマネジメントの本質ではない。 プロダクトマネジメントとは、その製品を使う人々の物語を語り、なぜそれが彼らの人生にとって重要なのかを伝える行為なのだ。対話相手であれば誰でも即座に理解できなければならない。しかも 再現性 がなければならない。あなたが部屋にいない状況でも、人々が忠実に内容を伝え合えるものでなければならない。
それは全く異なるドキュメントであり、全く異なる仕事だ。
10 年前、私はプロダクトマネジメントに関する講演を行った。今でも人々はその動画を私に送ってくれる。それは光栄なことか、あるいはこの分野が進化していないことの証左かのどちらかだろう。両方の可能性を検討してみよう。とにかく、その講演全体は一文に集約できた。「プロダクトマネージャーとは、チーム（そして会社）が正しいプロダクトをユーザーへ届けるのを助ける存在である。」私は講演の大半を費やし、この一文を単語ごとに分解して解説した。
- チームを助ける。 あなたはリーダーではない。多くの人はプロダクトマネージャーがリーダーだと誤解している。あなたは物事を成し遂げるのを 助ける 人間だ。つまり、あなたは……
- あなたの チーム と 会社 を理解しなければならない。チームはあなたの領域だ。完全に把握していなければならない！ そして、それがより大きな全体像の中でどこに位置するのかを理解し、あなた個人の目標だけでなく、会社の目標に貢献できるようにしなければならない。
- リリースする（Ship）。 いくら議論しても、最終的に重要なのは顧客の前に製品を置くことだけだ。
- ユーザーにとって正しいプロダクト。 ついに仕事の核心にたどり着いた。「正しい」とは具体的に何を意味するのかを研ぎ澄ますことだ。
AI 時代において、これらのうちどれほどが変わるのだろうか？
変化していること
明らかに 何か は変わった。実際にはいくつかある。一方で、コーディングの方法や、アイデアから動作するものまでの速度が変わった。他方で、ユーザーがプロダクトに期待する あり方 自体が変わった。特に消費者向け市場では、このポテンシャルはまだほとんど引き出されていない我认为。自分が何を必要としているかを記述すれば、エージェントがバックグラウンドで稼働し、ユーザーがインターフェースを学ぶことなく製品がそれを提供してくれる世界だ。
モノを作る コストが劇的に低下したことは疑いようがない。スコープを決めて試作することはもはや難しくない。これにより、極めて高い柔軟性が得られる。しかし、判断力 のコストは一切変わっていない。何を構築するかを見極めることは、かつてないほど重要になっている。
プロダクト開発はループだ。以前は誰かがアイデアを持ち、（必ずしもあなたである必要はない。優れた企業ならどこからでも生まれる）それを試すところから始まった。仕様書やプロダクトブリーフ、あるいは社内で呼ばれる名称whateverのドキュメントを書く。そこには事前のコストがかかる。スコープ設定、デザイン、議論——貴重なエンジニアリングリソースを消費する前に必要なすべてだ。これらはすべて、悪い決定からエンジニアリング時間を保護するために発明された儀式だった。なぜなら、年間でそのループを回せるのはせいぜい 6〜8 回程度だったからだ。
その後、モノ作りは 馬鹿げたほど 安くなった。少し安くなった程度ではなく、桁違いの変化だ。そして起きたことは非常に興味深い。古いループは依然として存在するが、新しい順序に再配置されただけだ。
古いループはこうだった：アイデア → 仕様書 → 見積もり → スコープ設定 → その他すべて → それから 構築。今は:
- まず、アイデアを受け取り、AI を使って素早く構築してみる。動作と感触を見るためだ。
- それをプレイし、全体の構想の中でどのように機能し、収まるかを把握する。プロトタイプは「もし〜だったら」という空想に常に勝る。
- それから デザインを行う。実際に触ってみて初めて、それが 何 であるかが分かり、単なるプロトタイプを超えるために何が必要かを語れるようになる。ここで言うデザインには二つの意味がある：視覚的・UX デザインと、エンジニアリングデザインだ。
- 最後にリリースし、学ぶ。
これは完全に逆転している：仕様書とスコープ設定から、構築とプレイへ。 私はこれが、現在起きている他のどんなことよりもプロダクトマネジメントを変革すると考えている。
ついに、仕様書は成果物ではなくなった。本当に。 長いドキュメントを書き始め、紙の上ですべてを完璧にする必要はない。以前は理想論としてそう言われていたが、今は文字通り明白な事実となっている。
ただし、注意したい。等しく反対方向の過ちを犯す可能性があるからだ。
デモはほぼ無料になった。動く製品はそうではない。 私はこの新しいアプローチの裏側をよく目にする。「素晴らしい、そのままリリースしよう」というものだ。それでもなお、それは機能しない。私たちは皆、プロトタイプから実用レベルのものまで到達するには時間がかかる ことを尊重しなければならないままだ。
プロダクトマネージャーには「スケジュールに収まるか？」と尋ねるのが主な仕事だというステレオタイプがあるが、その考えは完全に捨て去ろう。最も重要な質問はこれだ：それはプロダクトに収まるか？
私たちには誰もが素晴らしいアイデアがあり、今はコードを書いてくれるエージェントもいる。何を構築するかを決めることは、公式にはリソース配分の議論ではなくなった。それは インパクト の議論だ。「これかあれか」であって、「これかゼロか」ではない。世界のために何を成し遂げたいかというビジョンを持ち、本当にやりたいことが分かっている場合、センスとキュレーションが極めて重要になる。しかし、構築するシステムは依然として完成されたものである必要がある。
AI に対する私の最大の懸念は、スピードが上がることによって、すべてを詰め込みすぎてしまう点にある。コンテンツにおける「AI スロップ（粗悪品）」についてはよく語られるが、これはプロダクトにおける AI スロップの意味だ。すでにいくつかの現場でその兆候を見ており、私たち皆が多少なりとも心配していることだろう。誰でも何でも作れるようになったとき、何を構築するかを決めることが仕事そのものになる。 そしてそれはストーリーの問題だ。どんな物語を語りたいのか？ 顧客にどんな物語を理解してほしいのか？ 彼らの頭の中にどんな物語を残したいのか？
PM としての仕事は、製品が何をするかの仕様書を書くことではない。共有された 理解 —— 私たちが何をなぜやっているのかという共通認識 —— を創り出すことだ。ユーザーはなぜここにいるのか？ 各ステップで彼らは何を感じ、なぜそれが重要なのか？ どこが印象的で、どこが退屈なのか？ 製品が時折退屈なのは問題ない。どこが退屈なのかを知っていれば。しかし、良い脚本が書けなければ、製品はつまらないものになる。
AI があなたに与える贈り物は、このことを無料で、最初に見つけられるようになった点にある。素早く構築し、感触を確かめ、プレイし、たった一文を見つけ出すことができる：この製品は、誰かの人生において何を提供するのか？ もしそれに答えられれば、私の問いにも答えられるはずだ。「人々は本当にそれを使っているか？」 なぜなら、そこであなたは製品の機能を定義し、ユーザーがそれを実行しているかどうかを問うているのだから。
変わらないこと
プロダクトに対する「ビジョン」を持つとはどういうことか？
私がビジョンと言うとき、ミッションステートメントのことではない。それも重要だが、ビジョンではない。ビジョンとは、ユーザーにとってその製品が存在する理由 のエンドツーエンドの定義だ。これにはシンプルなフレームワークがある：
- 目的（Purpose）。なぜ誰かがあなたの製品を取り上げ、自分の人生に取り入れるのか？
- コアアクション（Core actions）。取り上げたとき、彼らは実際に何をしているのか？ 一つ以上あるかもしれないが、すべてを理解しなければならない。
- サイクル（Cycle）。それぞれの主要なコアアクションの想定頻度はどれくらいか？
キャリアを通じて、起業家や他のプロダクト担当者との面談で私はいつもこう聞く：人々はあなたの製品を使っていますか？ 彼らはほぼ確実にユーザーデータの話に飛ぶ。「DAU/MAU レシオは 50% です。サインアップ数が 1 万人を超えました。ウェイトリストに 100 万人います。ARR は 100 万ドルです。毎日 40 億トークンを処理しています。App Store で 3 位になりました。」
これらは私がした質問への答えになっているだろうか？
時々、私はもう一度同じ質問をするが、一語加える：人々は本当に (*really*) あなたの製品を使っていますか？ そうすると、たまに彼らが私が聞いていることに気づくことがある。
LinkedIn の目的は 見つけること と 見つけられること だった。おそらく一部のユーザーにとってのコアアクションは、誰かから連絡があったときに返信することだけだった。大多数の人にとってそれは毎日のことではなく、年に一度か二度かもしれない。
そのサイクルを見てほしい——年に一度か二度だ。これを理解することは LinkedIn が機能するために決定的に重要だった。なぜなら、ネットワークには「見つけられること」を望む非常に多くの人々と、少なくとも「見つける側」にいる一部の人々が必要だったからだ。
結局のところ LinkedIn はソーシャルネットワークなので、ユーザーに毎日アクションを起こさせようとしたくなるかもしれない。私たちはそうしなかった。代わりに、初期段階ではプロフィールの正確性を保つことに膨大な時間を費やした。年に一度か二度しか見つけられなくても全く問題なかった。その瞬間が訪れたとき、クリックして「誰かが私に連絡してきた、素晴らしい」と理解してくれればそれでよかったのだ。
製品が機能しているかを測定するとき、重要なのはこうしたコアアクションだ。ダイレクトトラフィックに注目せよ：文字通りあなたのもとへ来た 人々を探せ。アプリをインストールしてアイコンを押した人、またはドメインを手入力した人。彼らは自らの意志で あなたのもとへ 向かったのだ。その瞬間に人を呼び戻すための他のすべての手段と比較して、重要なのはこうしたトラフィックだ。
そして、コアアクションを実行した人々だけを真にカウントせよ。「アプリを一時的に開いた」ではなく、実際にエンゲージメントした人々だ。Discord で言えば、「ライブセッションに参加し、実際にメッセージを読み送信した」人々だ。
もしコアアクションを定義できないなら、あなたにはプロダクトがない ということだ。なぜなら、理解しているものを持っていないのだから。
さて、新しく、そして私が気に入っている点がある。AI 製品においてユーザーが製品と対話したり、プロンプトを入力したりする場合、ユーザージャーニーのリテラルなトランスクリプト（記録）が手に入るようになった。人々が自分の言葉で何を言っているかが見える。誰かが諦めて言い換えた正確な瞬間が見える。製品に期待したが実現しなかったことが見える。これを読め！ AI はこれまで見えなかったものを浮き彫りにするのに優れているが、すべてを要約させたり、AI に意見形成を任せたりしてはならない。意見を形成すること——実際のストーリーが何であるかを見極めること——こそが、プロダクトマネジメントの仕事であり芸術なのだ。
オンボーディング
オンボーディングは、顧客にストーリーを語るために最も重要な瞬間だ。彼らはあなたの製品を発見した——広告、バイラル招待、記事など、きっかけは何でもいい。あなたの存在を知っており、好奇心を持って試したいと思っている。 二度とこれほどの注目を彼らから得ることはない。
この時点で覚えておくべきは、全員が同じ動機であなたの製品に現れるわけではないということだ。 熱心な層（eagers） がいる。彼らはどうしても入りたい。準備ができている。明確にしておきたいのは、もしあなたがその会社の社員なら、あなたは「熱心な層」の世界に住んでいるということだ。社内の人間は全員「熱心な層」として扱われるべきだ。彼らは毎日製品に浸っている。オンボーディングの際には「やり方は知っている、これは退屈だ、なぜこのステップがあるんだ？」と思うだろう。
一方、 通りすがりの層（fly-bys） もいる。彼らはそれほどあなたに興味がない。噂を聞き、覗いてみたが、メッセージが届かず、去っていく。
この二種類のユーザーは分布の端にある。その間には、曖昧な中間層が大きく広がっている。彼らは理由があって現れたのだ：好奇心！ もっと知りたい！ そして、あなたは彼らを本当に製品のコアユーザーへと転換できる。彼らはあなたが軸にして構築すべき人々だ。熱心な層は放っておいてもついてくる。中間層こそが理解すべき対象だ。
ユーザーは意欲的で好奇心旺盛だと仮定せよ。時間をかけて、ステップバイステップで製品を紹介せよ。 複雑な少数のステップより、単純な多数のステップが勝る。 私は過去数年間、複数の会社での A/B テストでこれを証明してきた。各ステップが離散的かつシンプルで、何を求めているのか、何を教えているのかが明確であれば、ステップ数を減らすために単一の大きな画面や複雑な選択肢を用意するよりも常に勝る。毎回そうだ。
では、実際にそれをどう構築するのか？
まずコアメッセージを繰り返すことから始めよう： これはこういうものです。 コンテキストを製品内で明示せよ。基本的な情報——メール、パスワード、電話番号——を求めるのは構わない。それ以外については、なぜそれを求めるのか、それがどう関連するのかを説明せよ。そして、製品を主要な概念に分解し、それぞれに対してユーザーが取れる明確なアクションを設定せよ。
AI 製品はこの課題をより難しくしており、容易にしていない。 空白のプロンプトボックスが表示される。ある意味では、これまでで最悪のオンボーディング画面だ。魔法の箱だ。何でもできる。だから……何をやりたい？
最近の多くの製品は「こんにちは、お手伝いします。何でも聞いてください！」から始まる。私個人について言えば、その瞬間、私は最も雄弁で創造的な人間ではない。能力を概念ごとに教え込む必要がある。「こういうことを頼めば、私はできますよ」と。そして製品にそれをやらせる。ユーザー自身のデータを使って、迅速に少なくとも一つの価値あるユースケースに到達させ、実際に彼らにとって価値があると感じさせることが理想的だ。
時々こんな質問を受ける：フローが長くなると、途中で離脱する人が増えないか？ 増える！ しかし、最後まで辿り着いた人々は、あなたの製品を実際に使用する可能性が遥かに高い。異なるオンボーディングフローを A/B テストするなら、フローの終点に到達した人数を見てはならない。翌日、あるいは翌週に戻ってきた人数と、コアアクションを実行した人数を見ろ。その瞬間に「この製品は何ですか？」と尋ねれば、ほぼ正しい答えが返ってくるはずだ。ここからのリテンションデータが、あなたの成績表となる。
Twitter からの物語
最後に、Twitter での物語を通じて、これらすべてをまとめよう。
私は 2009 年末に Twitter に参加した。成長の問題を抱えていた——厳密には成長の問題ではなかった。Twitter は常にニュースになっていた。人々はブログで書き、メディアは話題にし、多くの人々がこう尋ねていた。「Twitter って何？ 調べてサインアップしないと」。そして数百万人が実際にそうした。しかし、彼らは二度と戻ってこなかった。
問題は、誰も Twitter が *何* であるかを説明できなかったことだ。 これを実証できる：
キャプション：「最終的には No.1 に到達した。」
当時のオンボーディングでは、ユーザーがサインアップすると、「友達を探す」か「ランダムな 20 人をフォローする」オプションが表示されていた。ほとんどの人はそれをスキップし、このようなページに到着した：
これはかなりひどい！ 巨大な空の箱だ。人々はそれを見て「...言うことが何もない」と思い、去っていく。その瞬間に「Twitter とは何ですか？」と聞けば、「世界に向かって何かを発信するツール？ それとも友達を見つけるため？ わからない」と答えるだろう。
そこで私たちは数年かけてオンボーディングを再構築し、機能するもの——Learn Flow（学習フロー）——を発見した。私たちは Twitter を、一つずつ概念を教えるストーリーとして伝えた。そしてそれは、その年にリリースした他のどんなものよりもリテンションを改善した。
Learn Flow、スクリーンごとに見る
まず、新しいホーム画面：「Twitter へようこそ」。そこにコンテンツを置こうとはせず、ただこう書いた：「あなたが関心を持つ人や組織の、今起きていることを確認してください」。正直なところ、これは Twitter の良い説明だ。
次に：これはツイートです。最大 140 文字の短いメッセージで、リンクを含めることができます。これで、ツイートがこのサービスの単位であることを知ります。
次はタイムラインを構築する必要があります。そこでタイムラインを表示しました。左側の人物をクリックして「フォロー」させました。フォローすると、右側にその人のツイートが表示されました。一つの動作で全体像が伝わります：フォローをクリックすると、ツイートが表示され、それが私のタイムラインになる。 これがまさに Twitter の概念——ツイート、フォロー、タイムライン——だ。
そして最後に、あなたのタイムライン。自分で実際にフォローしたアカウントばかりなので、すべて認識できるはずです。
オンボーディングは、あなたのストーリーだ。
ユーザーにとって正しいプロダクト
プロダクトマネージャーとしての仕事は、チームと会社がユーザーにとって正しいプロダクトを届けるのを助けることだ。AI 時代において、リリースすること自体は以前ほど問題ではなくなっている。正しい プロダクトとは何か、そしてユーザーが誰であるかを見極めることは、かつてないほど、あるいはそれ以上に重要になっている。
常に問え：人々は本当にあなたの製品を使っているか？ それが何を意味するかを理解せよ。目的、コアアクション、サイクルについて考えろ。妥当と思われる以上の時間をオンボーディングに費やせ。曖昧な中間層を転換するのはそこであり、製品のストーリーを実際に語るのはそこだからだ。
プロトタイプの加速には AI を活用せよ——しかし、判断力を急がせてはならない。判断力を手放すな。「まあ、テストして様子を見よう」とだけ言ってはならない。それは雑な製品を生み出す道だ。至るところで判断力を維持せよ。仕事の最も難しい部分は依然として、プロダクトマネージャーとしての創造性と、現在アクセス可能なすべてのデータのバランスを取ることだ。
幸運を祈る！
