讀完這章你要能回答：PM 工作的本質是什麼？產品思維怎麼幫我做更好的技術決策？

理解產品經理的角色，無論你是 PM 還是與 PM 協作的工程師。

什麼是產品經理？#

產品經理是「產品的 CEO」，負責定義「做什麼」和「為什麼做」，但沒有直接管理權，需要靠影響力推動事情。

寶玉在《矽谷產品 36 講》中定義了產品經理的角色：

產品經理的職責#

mindmap
  root((產品經理))
    ✅ 核心職責
      發現使用者需求
      定義產品方向
      設計產品方案
      協調開發上線
      跟進數據回饋
      持續迭代優化
    ❌ 不是 PM 的職責
      寫程式碼（工程師）
      做設計（設計師）
      管理團隊（工程經理）
      只是寫文件和跟專案
      老闆說什麼就做什麼

四個容易混淆的角色：PM / PO / 專案經理 / BA#

「產品經理」常被和好幾個角色混為一談。攤開來看，它們關心的問題、負責的對象完全不同。

維度產品經理（PM）產品負責人（PO）專案經理（Project Manager）商業分析師（BA）
核心問題做什麼、為什麼做backlog 怎麼排、做哪個怎麼準時交付需求到底是什麼
時間視角長期產品方向一個個 sprint專案週期隨需求
對誰負責產品成功backlog 與發布規劃進度、預算、風險需求的正確與完整
關鍵能力產品 sense決策與優先排序協調管理訪談與文件化

在許多團隊（尤其中國公司）這些角色是合併在一個人身上的。但它們本質上是不同的能力——一個人兼著做，不代表它們是同一件事。

產品負責人（PO）的定位#

在敏捷團隊裡，PO（Product Owner）對產品成果統一且完全當責：他扛起產品願景、維護並排序 product backlog、規劃發布，並在業務與開發團隊之間搭橋。PO 比較像「PM 在敏捷框架下的化身」——重心更靠近 backlog 與每個 sprint 的取捨。

  • 成功的 PO：握有完整決策權 + 得到高層支持，團隊有疑問當場就能拍板。
  • 失敗的 PO：淪為「橡皮圖章」（只負責蓋章、真正的決策在別處），或是兼著別的職務、永遠找不到人的「分身」。

設立 PO 前先做一次授權檢查：這個人能不能直接決定「下一個 sprint 做什麼、不做什麼」？如果每個決定都要請示上級，那他不是 PO，只是一個傳話筒——團隊會因為「等決策」而不斷空轉。

產品經理的一天#

邱岳在《產品手記》中描述了 PM 的日常：

典型的工作內容#

上午：

  • 查看數據報表，了解產品表現
  • 處理緊急問題和使用者回饋
  • 與工程師對齊開發進度

下午：

  • 需求評審或設計評審會議
  • 撰寫或更新 PRD
  • 與業務方討論需求

不定時：

  • 使用者訪談或可用性測試
  • 競品分析
  • 戰略規劃會議

大公司 vs 創業公司的 PM#

環境大公司 PM創業公司 PM
範圍負責某個模塊負責整個產品
深度深耕細分領域廣泛但不深
資源資源相對充足什麼都缺
流程流程規範隨機應變
挑戰推動困難方向不確定

產品經理的核心能力#

寶玉的能力模型#

mindmap
  root((PM 能力模型))
    🔧 硬技能
      需求分析能力
      產品設計能力
      數據分析能力
      技術理解能力
      專案管理能力
    🤝 軟技能
      溝通協調能力
      邏輯思維能力
      同理心
      學習能力
      抗壓能力
    ✨ 隱性能力
      產品 sense（直覺）
      決策能力
      影響力
      執行力

產品 Sense 是什麼？#

產品 sense 是一種對「什麼是好產品」的直覺判斷能力。

如何培養產品 sense：

  1. 多用產品：每天用不同的產品，思考為什麼這樣設計
  2. 多思考：不只是用，還要分析為什麼好或不好
  3. 多實踐：自己設計、上線、看數據，形成完整循環
  4. 多學習：讀書、看案例、向優秀 PM 請教

養成習慣，每次用一個新 App 時，先想「如果我來設計，會怎麼做」，然後對比實際設計，分析差異。

產品經理的成長路徑#

職級發展#

寶玉描述的 PM 成長路徑：

flowchart TD
    L1[📝 Level 1: 產品專員/助理<br/>執行、跟進、學習方法論]
    L2[📊 Level 2: 產品經理<br/>獨立負責功能模塊<br/>完成需求到上線全流程]
    L3[🎯 Level 3: 高級產品經理<br/>負責完整產品線<br/>產品戰略規劃、帶初級 PM]
    L4[👔 Level 4: 產品總監<br/>多條產品線<br/>產品體系規劃、培養團隊]
    L5[🏆 Level 5: 產品 VP/CPO<br/>公司產品戰略<br/>跨部門協調、文化建設]

    L1 --> L2 --> L3 --> L4 --> L5

    style L1 fill:#e3f2fd
    style L2 fill:#e8eaf6
    style L3 fill:#fff3e0
    style L4 fill:#fce4ec
    style L5 fill:#e8f5e9

從優秀到卓越#

邱岳提出的「從優秀到卓越」的標準：

優秀的 PM 能做出符合預期的產品，卓越的 PM 能創造超出預期的價值。

卓越 PM 的特徵：

  • 不只是滿足需求，而是創造需求
  • 不只是優化現有產品，而是開闢新方向
  • 不只是完成任務，而是產生深遠影響

技術人需要的產品思維#

即使不做 PM，技術人也需要具備產品思維。這能幫助你做出更好的技術決策，理解工作的價值。

為什麼技術人需要產品思維？#

喬新亮的觀點：

  1. 更好的技術決策：理解業務價值，才能做正確的技術選型
  2. 更高的工作價值：不只是實現功能，而是解決問題
  3. 更好的溝通：能和產品、業務用同一種語言
  4. 職業發展：向上走，必然需要理解業務

技術人的產品思維要點#

思維說明例子
使用者視角站在使用者角度思考這個介面設計對調用方友好嗎？
價值導向關注業務價值這個優化對使用者有什麼好處？
全局觀不只看技術細節這個系統在整體架構中的位置？
數據驅動用數據驗證判斷這個改動後指標有變化嗎？

下次開需求評審會時，不只是關注「怎麼實現」，也問問「為什麼要做這個」。

PRD 的閱讀與編寫#

PRD 是什麼？#

PRD（Product Requirements Document）是產品需求文件，是 PM 和工程師溝通的主要載體。

PRD 應該包含什麼？#

mindmap
  root((PRD 結構))
    📋 基本資訊
      文件版本和更新記錄
      需求背景和目標
      使用者故事
      成功指標
    🖥️ 功能描述
      功能清單
      頁面流程圖
      交互說明
      異常處理
      邊界條件
    📎 其他說明
      技術約束
      數據需求
      上線計劃
      風險和依賴

好的 PRD 的標準#

  • 完整：該說的都說了，不需要反覆問
  • 清晰：沒有歧義，不同人理解一致
  • 有理有據：說明為什麼要這樣設計
  • 可執行：開發看了就知道怎麼做

PRD 只描述正常流程，忽略異常情況和邊界條件。這會導致開發過程中反覆確認。

從 PRD 到 Product Backlog#

厚重的前置 PRD 假設「需求一開始就能想清楚、之後不太會變」。但現實是需求會持續演化。敏捷團隊用一份活的 product backlog 取代一次寫死的大文件——它隨著學習不斷被補充、重排、拆解。

PRD 不會消失，但它的角色從「開發前一次交付的聖經」變成「backlog 裡某些項目的補充說明」。真正驅動開發的，是那份持續梳理的 backlog。

DEEP：健康 backlog 的四個特徵#

字母特徵意思
DDetailed appropriately（適度細化）越靠近要做的，描述越細；遠期的保持粗顆粒
EEstimated（已估算）每個項目有大致的大小估計，才能排序與規劃
EEmergent（持續演化）backlog 是活的，會隨學習新增、修改、刪除
PPrioritized（已排序）由上而下排好優先級，最該做的在最上面

別在 backlog 最底層的遠期項目上花太多力氣寫細節——它們很可能在排到之前就變了或被砍了。把細化的精力留給「即將要做」的那一批。

Backlog 梳理（Refinement）流程#

梳理是個持續進行的活動，不是一次性會議。大致的循環是：

1. 發現並描述
   └── 把新需求寫成 backlog 項目（通常是用戶故事）

2. 排序
   └── 依價值、風險、依賴，由上而下排優先級

3. 拆解
   └── 把太大的項目拆成 sprint 內可完成的小塊

4. 估算
   └── 給出相對大小（見「用戶故事與相對估算」）

經驗法則：拿出約 10% 的 sprint 容量做 backlog 梳理。投資這 10%，換來的是「下個 sprint 開始時，最上面那批項目已經夠清楚、可以直接開工」。

非功能需求列為「約束」#

效能、安全、相容性、合規這類非功能需求，不適合寫成一則則用戶故事（它們沒有獨立的「使用者價值」可交付）。比較好的做法是把它們列為貫穿所有故事的約束條件，並納入團隊的「完成的定義」（見用戶故事與相對估算）。

賦能團隊：交問題，而不是交功能清單#

真正被賦能（empowered）的團隊，拿到的是「一個帶著 KR（關鍵結果）的問題」，而不是「一張要照著做的功能清單」。前者要團隊去想「怎麼達成這個成果」，後者只要團隊照單全收。

維度功能導向 Roadmap成果導向 Outcome / KR
交付給團隊一張功能清單一個要解決的問題 + 目標 KR
團隊在想怎麼把這些做完怎麼達成這個成果（含「不做某功能」）
成功定義功能上線了指標真的動了
創新空間幾乎沒有大——解法由團隊探索

賦能不是放任，有幾個配套：

  • 標示企圖心層級：這個目標是 Roof Shot（踮腳搆得到、該穩穩達成）還是 Moon Shot（登月級、就算只達成一半也是巨大進步）？講清楚，團隊才知道該保守還是該大膽。
  • 用測試打破僵局：團隊在兩個方向間吵不出結果時，與其辯論，不如設計一個小實驗讓數據說話。
  • 不同意但承諾（disagree and commit）：決策一旦拍板，即使當初反對，也要全力執行，不在事後扯後腿。
  • 依風險調整分析深度：高風險、難回頭的決策值得深入分析；低風險、可逆的決策快速試就好，別過度分析。

想檢查團隊是不是真的被賦能，問一句：「如果他們發現某個指定功能其實達不成目標，他們有沒有權力不做它、改做別的？」答案是「沒有」，那就還是交功能清單，不是賦能。

本章要點#

  1. PM 的本質：定義「做什麼」和「為什麼」，靠影響力推動
  2. 核心能力：需求分析、產品設計、溝通協調、產品 sense
  3. 成長路徑：從執行到負責，從功能到產品線
  4. 技術人也需要：產品思維幫助做出更好的技術決策
  5. PRD 是溝通工具：完整、清晰、有理有據、可執行
  6. PM / PO / 專案經理 / BA 是四種能力：PO 對成果統一當責，關鍵在完整授權 + 高層支持
  7. 活的 backlog 取代厚重 PRD：用 DEEP 檢查健康度，拿 ~10% sprint 容量持續梳理
  8. 賦能 = 交問題不交清單：給帶 KR 的問題、標明 Roof/Moon Shot、不同意但承諾
Backward 產品能力 使用者研究與需求 Forward