この記事の要約
- 起点はP&Gの「ブランド・マン」（1931）。以降は“顧客価値と事業成果をつなぐ”ための組織OS（意思決定の作法）の更新史
- 2000年代にアジャイル／顧客開発／リーンで検証速度が跳ね、2010年代にPLGとPRFAQで合意形成が標準化
- 2023年以降はLLMが「作る対象」と「作る方法」の両面を刷新。PdMは“作法を選ぶ・検証で語る・物語で合意する”へ
僕自身、プロダクトマネージャーとして5年以上働いていて、その歴史が気になったので調べてみました。調べてみての結論はシンプルで、プロダクトマネジメントの本質は顧客価値と事業成果の橋渡しであり時代により変わっているのはそのための作法です。
- 最初に結論としての”プロダクトマネジメントの歴史”
- 起源（1931）：P&G「ブランド・マン」— 単一ブランドに責任と裁量を
- 1990年代〜2000年：マイクロソフトのProgram Manager—“仕様で合意”の時代
- 2001：アジャイル宣言— 変化に“応答する組織OS”へ
- 2000年代：顧客開発とリーンスタートアップ— 仮説は“外”で検証する
- 2010年代前半：PLG（Product-Led Growth）— 体験そのものが成長を駆動
- 2010年代後半：スクワッドという運営知—自律チームの標準形
- Amazonの「Working Backwards」：PRFAQで合意形成を速く、強く
- 人材のプロ化：Google APM—若手PdMを体系的に育てる
- PMF（Product/Market Fit）— 何をもって“ハマった”と言うか
- 2023年以降：LLM時代— 作る“対象”と“作り方”の同時アップデート
- まとめ
- 今日から実践できるアクション
- Q&A
- 参考情報（一次情報中心）
最初に結論としての”プロダクトマネジメントの歴史”
以下の記事を1枚でまとめています。
起源（1931）：P&G「ブランド・マン」— 単一ブランドに責任と裁量を
1931年、若きニール・H・マッケロイが社内メモで「ブランドごとに責任と権限を持つ“ブランド・マン”を置く」ことを提案しました。
広告・販促・販売結果のトラッキングまで一気通貫で担う役割の明文化。これは意思決定の焦点を“製品単位”へ寄せる設計でした。
https://www.mindtheproduct.com/wp-content/uploads/2015/10/McElroyBrandMan.pdf
背景として、大量生産とマスマーケ時代、組織は機能別（生産・営業・広告など）に分断されがちでした。そこで「ブランド」というビジネス単位でPL責任と裁量を与える――今日のPdM（製品単位での意思決定のハブ）に直結する思想が生まれました。
1990年代〜2000年：マイクロソフトのProgram Manager—“仕様で合意”の時代
PCソフトの複雑化とマス配布の前提では、開発前に仕様で合意する作法が強力でした
マイクロソフトのProgram Managerは「要件を集め、仕様（Spec）を書き、関係者を束ねる」役。Joel Spolskyの記事に当時の実務が少し書かれています。
この時代は、配布媒体（CD/箱）が主流で頻繁な更新が難しい時代。だから「仕様の完全性と合意」がリスク最小化の最適解でした。Joelの“Painless Functional Specifications”は、シナリオ・非目標・UIスケッチ・エッジケースまで固める型を提示。現代でも外部制約が強い領域（医療・金融・組み込み）では有効です。
現在でも金融システムなど仕様漏れなどのリスクが大きい業種では仕様を細かく作り込んでからリリースする文化はありますよね。
2001：アジャイル宣言— 変化に“応答する組織OS”へ
2001年、17名の実践者がアジャイル宣言（Agile Manifesto）を掲げました。「個人と対話／動くソフトウェア／顧客協調／変化への対応」。重厚な事前合意から、短い学習ループと検証可能性へ舵を切る合図でした。
変化としては、価値観の中心を「文書」から「動くソフト」に移し、週単位でのデリバリーを標準化した点。これにより小さな失敗の早期回収が可能になり、PdMは検証設計と優先順位付けが主戦場になりました。
アジャイルソフトウェア開発宣言（4つの価値）
- プロセスやツールよりも 個人と対話 を、
- 包括的なドキュメントよりも 動くソフトウェア を、
- 契約交渉よりも 顧客との協調 を、
- 計画に従うことよりも 変化への対応 を価値とする。
アジャイル宣言の背後にある12の原則
- 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
- 要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。
- 動くソフトウェアを、2–3週間から2–3ヶ月というできるだけ短い時間間隔でリリースします。
- ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
- 意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。
- 情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。
- 動くソフトウェアこそが進捗の最も重要な尺度です。
- アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。
- 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
- シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
- 最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
- チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。
2000年代：顧客開発とリーンスタートアップ— 仮説は“外”で検証する
スティーブ・ブランクは顧客開発（Customer Development）を提示し、探索→検証→開拓→組織化の反復で市場と解を同時に耕すことを体系化しました。
また、エリック・リースはリーンスタートアップでMVP（Minimum Viable Product：最小実用）とBuild–Measure–Learn（B–M–L：構築→計測→学習）を普及。学習の速度をKPIに据え、仮説の当たり外れを早く知ることで資源配分の質を上げました。
要点としては、オフィスを飛び出して外で顧客と仮説をぶつけ続けることにあります。
2010年代前半：PLG（Product-Led Growth）— 体験そのものが成長を駆動
さらに流行ったのが「プロダクト自体が獲得・定着・拡張の主因」という構え。用語としてのPLG（Product-Led Growth：プロダクト起点成長）は2016年にOpenViewのBlake Bartlettが提唱しました。
具体例
- Dropboxの紹介ループ（使うほど得をする追加容量）＝価値と報酬の一致。紹介は獲得とアクティベーションを同時に押し上げる設計でした（ケースの概説はOpenViewなど多数）。
- Slackは「1人→チーム」の組織内伝播で内在的バイラルを形成。初年度でDAU50万（Time報道）と早期に臨界を超え、以降S-1提出時点の指標にもネットワーク性が色濃く反映されます
PLGの3点セット
- アハ体験（Moment of Value）を言語化し、到達時間（TTMV）を短縮
- プロダクト内誘発（招待/共有/テンプレ配布）を価値の一部として設計
- 拡張の自然経路（席追加、連携上限解除、権限/監査機能）を体験の延長に置く
2010年代後半：スクワッドという運営知—自律チームの標準形
Spotifyのスクワッド／トライブは「自律と整合」を両立させる運用知として広がりました。動画＆解説が一次資料です。
要点：小さなミッション完全体（デザイン/開発/データ/QA）で価値ドメインを担当し、章（Chapter）が横断の質を担保。PdMは課題の定義と発見の牽引に集中できます。:contentReference[oaicite:6]{index=6}
Amazonの「Working Backwards」：PRFAQで合意形成を速く、強く
Amazonは2004年ごろから、まずプレスリリース＋FAQ（PRFAQ）を書き、顧客価値→差別化→リスクを文章で詰める作法を制度化しました。公式の解説と、著者らのサイトにテンプレート・事例があります。
この手法は未来時制のPRで体験を鮮明化し、FAQでコスト・リスク・代替案を先回りするため、文書での厳密な合意形成により後戻りと政治摩擦を減らすことが可能です。
PRFAQレビューの運用
- ドラフト→赤入れ10往復を前提
- レビューは無言読書→質疑の順にし、声の大きさバイアスを抑える
- 承認はFAQの反論潰し完了を条件にし、次の投資段へ
人材のプロ化：Google APM—若手PdMを体系的に育てる
GoogleのAPM（Associate Product Manager）は2002年に始動し、ローテーションとメンタリングで若手PdMを鍛える仕組みです。プログラムの発案と運営にマリッサ・メイヤーが深く関与したことは複数の一次記事・公的プロフィールで言及されています。
PMF（Product/Market Fit）— 何をもって“ハマった”と言うか
2007年のマーク・アンドリーセンのエッセイ「The only thing that matters」は、PMFを「良い市場に、満たすプロダクトで臨む状態」と端的に定義しました。原文はアーカイブに残っています。
現場の判断基準
- 定性：ユーザーの“代替不可能”発言の増加（競合比較で自発的に優位点を語る）
- 定量：アクティベーション到達率・翌週/翌月リテンション・紹介/拡張の自然発生
- 資源面：獲得効率の改善（CAC回収が短縮）
原典で「市場（Market）が最重要」という主張に触れ、市場定義→ICP確定→価値仮説の順で検証すべき文脈が理解できます。
2023年以降：LLM時代— 作る“対象”と“作り方”の同時アップデート
GPT-4以降、調査・要件化・UIコピー・検証の前後工程が自動化され、探索コストが劇的に低下しました。
https://cdn.openai.com/papers/gpt-4.pdf
実務面の再定義はSVPGなどが継続発信。PdMは「AIを組み込む製品」を設計しつつ、「AIで自分たちの探索プロセスを短縮する」二兎を追う段階に入っています。
マクロ視点でも、AIの波をPC・スマホ級の変化と捉える論説があり、経営判断の前提が更新されました（Bill Gates “The Age of AI has begun”）。
このサイトでも、プロダクトマネジメント x LLMの手法は多く書いています。
まとめ
1931年の“ブランド単位の責任設計”から、仕様で合意→検証で学ぶ→体験が売る→文書で合意→AIで探索短縮へ。
短いながらも、この歴史の中で変わらないのは「顧客価値を、事業成果に橋渡しする」責務です。すなわち、僕たちPdMがやるべきは、プロダクトの文脈（市場・組織・リスク）に応じて作法を選ぶことですね。
今日から実践できるアクション
- PRFAQをA4一枚で書く
見出し（未来のプレスリリース）→顧客課題→主要ベネフィット→差別化→FAQ（反論3つ） 参考：Amazon公式／テンプレ。 - MVPの仮説を一句化
「誰のどの行動をどれだけ変えるか」。B-M-Lで週次の学習ループを回す（Lean Startup）。 - PLGの北極星を一つ
アクティベーション指標＋“到達までの時間”をダッシュボード化。Dropbox/Slackの一次資料・報道を短く読み合わせ。OpenView／Time
Q&A
Q1. 歴史上のプラクティスは全部やるべき？
A. いいえ。組織OSと事業の文脈に合う“核儀式”を1〜2個に絞る。たとえば「PRFAQ＋リーン検証」。
Q2. PLGはBtoBでも効くのか？
A. 効きます。Slackのようにチーム単位での立ち上がりと拡張で効果を出す設計が鍵。
Q3. LLM導入はどこから始める？
A. 調査・要件定義・検証ログ整理など前後工程から着手し、判断は人間が保持。技術の一次情報と運用知の双方を読む。
参考情報（一次情報中心）
- P&G「Brand Man」メモ（1931）：PDF（原典の複写）
- Manifesto for Agile Software Development：公式／PDF
- Customer Development（Steve Blank）：ブログ
- Lean Startup：原則
- PLG定義・由来：OpenView
- Slackの初期成長（報道）：Time
- Spotify Engineering Culture（Part1）：公式
- Amazon「Working Backwards／PRFAQ」：公式解説／テンプレ
- Google APM Program：公式（メイヤー関与はWiredの言及）記事
- PMF：Marc Andreessen「The only thing that matters」：原文
- GPT-4 Technical Report：PDF
- SVPG「AI Product Management 2 Years In」：記事
- Bill Gates「The Age of AI has begun」：記事
コメント