PM 角色與 AI 時代協作
核心命題：AI 加速開發，但無法替代共識建立
AI 大幅提升工程開發速度，但跨部門協作、利害關係人對齊、組織政治的處理，目前仍是人類 PM 無可取代的核心價值。結果是：傳統科技公司可能縮減工程師需求，但 AI Lab 內部的 PM 角色反而可能出現反直覺的擴張。
「就算到了 AGI 時代，要讓 6 位 stakeholders 完全 align，可能還是不可能任務。」
來源：Lenny Podcast 訪問 Anthropic Head of Growth Amol Avasare，2026-04-07
AI 時代的工程/PM 產能不對稱
透過 Claude Code 等 AI 工具，一個 5 人工程團隊現在可以產出相當於過去 15–20 人的成果；但 PM 與設計的生產力並未同步放大。這造成：
- 一位 PM 實際上要承接更大規模的工程輸出與協作複雜度
- Anthropic 的應對策略：直接增加 PM，並正式授權具備產品思維的工程師，在兩週內的小型專案中扮演「小 PM」角色
來源：Lenny Podcast 訪問 Anthropic Head of Growth Amol Avasare，2026-04-07
CASH：用 AI 自動化成長流程
Anthropic 內部計畫 CASH（Claude Accelerates Sustainable Hypergrowth） 將成長工作自動化，涵蓋四個階段：
- 找機會
- 做功能
- 測試品質
- 分析結果
目前能處理文案修改與小型 UI 調整，表現大致接近有 2–3 年經驗的 junior PM，且進步速度快。
來源：Lenny Podcast 訪問 Anthropic Head of Growth Amol Avasare，2026-04-07
PM 工作流程：輕量 vs 正式
60%–80% 的成長專案沒有正式 PRD：
- 小型專案：kickoff 直接在 Slack 進行，靠 PM 與有產品 sense 的工程師來回討論
- 大型專案：必須有一場 30 分鐘正式跨部門 kickoff，把法務、防護機制與相關 stakeholders 先拉進來，盡早暴露風險
來源：Lenny Podcast 訪問 Anthropic Head of Growth Amol Avasare，2026-04-07
成長策略：押注 Big Swings，而非細粒度 A/B Test
傳統成長團隊常見配置：60%–70% 資源放小優化，20%–30% 放大膽嘗試。 Anthropic 的做法：反過來。
理由：若產品價值本身建立在 AI 能力上，模型能力提升後整體價值可能放大好幾個數量級，小優化的相對重要性會被快速成長的產品空間稀釋。
來源：Lenny Podcast 訪問 Anthropic Head of Growth Amol Avasare，2026-04-07
摩擦設計：Onboarding 不一定越順越好
在 Mercury、MasterClass、Calm、Anthropic 均觀察到反直覺現象：在 onboarding 中增加某些步驟，有時反而能提升轉換率。
關鍵原則：不是消除所有摩擦，而是刪掉沒有價值的阻力，保留能幫助使用者更快理解產品價值的摩擦。
來源：Lenny Podcast 訪問 Anthropic Head of Growth Amol Avasare，2026-04-07
AI Agent 用於組織內部對齊偵測
Amol 建了一個每週執行的 AI Agent，掃描 Slack 對話與專案內容，找出：
- 可能重複投入的工作
- 方向不一致的訊號
- 跨部門沒有對齊的地方
案例：企業團隊同事因此及早發現嚴重偏差，避免浪費數週時間。
這代表 AI 在組織協作上的真正價值：不一定取代人，而是降低大型團隊常見的溝通損耗。
職位邊界模糊化：Codex 團隊的實況觀察
OpenAI Codex 團隊（產品負責人 Alex、開發者體驗負責人 Romain）提供了 AI 時代跨職能工作最前線的案例。
設計師寫的 code 比以前的工程師還多
Codex 團隊的設計師，目前的程式碼產出量已超過六個月前一位工程師的產出量。工具（Figma Skill + Codex）讓設計師能直接從 Figma 稿生成 React 元件並部署，省去大量跨職能溝通成本。
來源：Peter Yang 訪問 OpenAI Codex 團隊 Alex & Romain，2026-04-06
PM 的雙重模式
Alex 將自己的工作分為兩種模式：
- 執行模式：用 Codex 掃 Slack 回饋、自動摘要 → Linear 任務、讀 codebase、直接送 PR。「自己送一個小 PR，比等工程師排進優先序快得多。」
- 思考模式：理解現狀、想下一步方向。Codex 在此更多用於溝通整理，而非寫 code。
來源：Peter Yang 訪問 OpenAI Codex 團隊 Alex & Romain，2026-04-06
Spec 精簡到極致：10 個 bullet 就結束
Codex 團隊的核心邏輯是「讓離金屬最近的人做最多決定」。只有兩種情況才寫 spec：
- 問題大到需要跨多人協調
- 有難以權衡的決定需要書面對齊
Codex Plan Mode 取代了部分傳統 spec 的功能：丟入模糊想法，讓 Codex 自動看 codebase 狀態、提出幾個方向、反問使用者偏好。但 Alex 坦言，他用 Plan Mode 的目的往往不是產生計畫去實作，而是幫自己建立心智模型，然後再把理解傳給工程師。
來源：Peter Yang 訪問 OpenAI Codex 團隊 Alex & Romain，2026-04-06
產品規劃節奏：短期 + 長期，跳過中期
OpenAI 內部流傳的框架（來自研究員 Andre）：
| 時間尺度 | 做法 | 說明 |
|---|---|---|
| 短期（≤8週） | 具體目標 | 能凝聚團隊一起衝的清楚里程碑 |
| 長期 | 方向感（vibe） | 如「未來是無限多個雲端 model 平行工作」 |
| 中期 | ❌ 不做 | 傳統 roadmap 被認為在快速變動環境中虛耗資源 |
Codex App 誕生邏輯：策略目標是「把產品從特定 workspace 解綁，支援多 agent 平行工作」。到真正開始做時，只寫下「為什麼要蓋這個 app」，沒有具體 app spec，決策在團隊內有爭議但最後邊做邊收斂。
來源：Peter Yang 訪問 OpenAI Codex 團隊 Alex & Romain，2026-04-06
PM 角色的重新定位
Alex 的觀點：PM 不是 leadership position，而是 fill-in-the-gaps position。偶爾需要 leadership 時才做，且那種 leadership 是幫大家 align，不是天才策略。
對 PM 升遷路線的批判：升到 VP 後整天在 product review 給 feedback、離用戶和實際 shipping 越來越遠——這被認為是錯誤的方向。OpenAI 最好的 PM 都是非常 in the weeds 的。
對 AI 時代的職涯建議：
- 若 PM 其實一直想當工程師 → 現在轉 EM 更可行（有 coding agent 輔助）
- 在 AGI 世界裡，最重要的人類特質是 interest（對什麼有興趣） 和 agency（會不會自己動手）
來源：Peter Yang 訪問 OpenAI Codex 團隊 Alex & Romain，2026-04-06
招人標準：Show me what you built
Codex 產品團隊（Alex）
- Agency 最重要：入職後不會有人給你任務清單，會有人 own 沒人負責的領域
- 應徵訊息優先序：有連結必點 > 對產品有具體想法 >> 只有 CV 和動機說明
- 學歷不重要：「Who cares, man? Just show me what you built.」
- 敢挑戰現有決定（因為那些決定很可能是偶然做出來的）
DevEx 團隊（Romain）
- 技術能力強 + 精通 Codex + 社群分享熱情（在開發者社群活躍、教學）
- 典型案例：Thomas 做了 Codex Monitor 開源工具，同時積極在社群分享怎麼 build
- 「很會寫程式，而且 Twitter 經營得很好的工程師」——但社群能力需因地制宜（歐洲偏 LinkedIn）
來源：Peter Yang 訪問 OpenAI Codex 團隊 Alex & Romain，2026-04-06
Collapsing the Talent Stack
Scott Belsky 提出的概念，用來描述職能邊界崩解的趨勢：以前需要一間房間裡坐好幾個不同角色才能做一個決定，現在越少人就做得越好，每個決定都更純粹。
AI 時代的具體體現：
- 設計師做 code、工程師做用戶研究、PM 做 prototype
- 工程師釋放出原本寫 code 的腦容量，用來做更多跨界判斷
- 小型 startup 在工程師不到 20 人時就有 PM → 被認為是 red flag（Stripe 250 人時都還沒有 PM）
來源：Peter Yang 訪問 OpenAI Codex 團隊 Alex & Romain，2026-04-06
反向連結
以下頁面引用了本頁：