產品經理基礎

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

什麼是產品經理？#

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

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

產品經理的職責#

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

PM vs 項目經理#

產品經理（Product Manager）	項目經理（Project Manager）
決定「做什麼」	管理「怎麼做」
對產品成功負責	對項目按時交付負責
長期視角	項目週期視角
需要產品 sense	需要協調能力

在很多中國公司，這兩個角色是合併的。但本質上是兩種不同的能力。

產品經理的一天#

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

典型的工作內容#

上午：

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

下午：

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

不定時：

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

大公司 vs 創業公司的 PM#

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

產品經理的核心能力#

寶玉的能力模型#

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

產品 Sense 是什麼？#

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

如何培養產品 sense：

多用產品：每天用不同的產品，思考為什麼這樣設計
多思考：不只是用，還要分析為什麼好或不好
多實踐：自己設計、上線、看數據，形成閉環
多學習：讀書、看案例、向優秀 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，技術人也需要具備產品思維。這能幫助你做出更好的技術決策，理解工作的價值。

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

喬新亮的觀點：

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

技術人的產品思維要點#

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

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

PRD 的閱讀與編寫#

PRD 是什麼？#

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

PRD 應該包含什麼？#

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

好的 PRD 的標準#

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

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

本章要點#

PM 的本質：定義「做什麼」和「為什麼」，靠影響力推動
核心能力：需求分析、產品設計、溝通協調、產品 sense
成長路徑：從執行到負責，從功能到產品線
技術人也需要：產品思維幫助做出更好的技術決策
PRD 是溝通工具：完整、清晰、有理有據、可執行