1.認識 PM 這個角色
產品經理在做什麼？
很多人進入 PM 職位後才發現，這個角色沒有固定的「標準工作」
你不寫程式、不畫設計，但你要讓整個產品往正確的方向走。PM 的核心職責可以歸納為三件事：
- 定義問題：找出用戶真正的痛點，而不是症狀
- 對齊方向：讓工程、設計、商業各方理解並認同要做什麼、為什麼做
- 推動執行：在資源有限的情況下，確保產品按時交付並達成目標
PM 的職涯路徑
PM 職涯通常從 APM（Associate PM）或 PM 出發，逐步往 Senior PM、Group PM、Director 發展，最終可走向 VP of Product 或 CPO。
在台灣的產業環境下，PM 職涯有幾個特別值得留意的地方：
- B2B 與 B2C PM 的思維差異很大：B2B 更重視利害關係人管理與採購流程，B2C 更看重數據驅動與用戶增長
- 技術背景加分，但不是必要條件：能和工程師溝通、理解技術限制才是關鍵
- 數據能力是現代 PM 的基本功：不需要會寫 SQL，但要能看懂分析報告並自己提出假設
選擇適合自己的 PM 類型
幾種 PM 類型，可以對照自身背景選擇發展方向：
- 平台型 PM:技術架構理解、API 設計思維 (適合背景:工程師轉職)
- 成長型 PM:數據分析、A/B 測試、漏斗優化(適合背景:數據/行銷背景)
- 體驗型 PM:使用者研究、設計感知(適合背景:設計師轉職)
- 商業型 PM:市場分析、商業模式(適合背景:商管/顧問背景)
2.產品開發的核心原則
了解產品開發流程
一個完整的產品開發週期通常包含以下階段：
探索階段（Discover） → 定義問題、用戶研究、競品分析
定義階段（Define） → 優先排序、撰寫 PRD、對齊利害關係人
開發階段（Deliver） → Sprint 規劃、與工程設計協作、QA
上線後（Learn） → 數據追蹤、用戶回饋、迭代規劃
這個流程不是線性的，上線後的洞察會回頭影響下一輪的探索與定義。PM 的價值很大程度在於能否有效管理這個循環，讓團隊持續學習和改進。
會議管理：讓決策真的發生
很多 PM 浪費大量時間在「沒有產出」的會議上。課程中強調，好的會議管理包含：
- 每個會議都要有明確目的：資訊分享、討論決策、或解決問題，三者不能混在同一個會議裡
- 會議前發送 pre-read，讓與會者有準備
- 會議結束前確認決策與 action items，並指定負責人和 deadline
- 定期的 retrospective 不只是形式，要真的找出可改變的事項
優先排序的方法
當需求多於資源，PM 必須做出取捨。幾個常用的優先排序框架：
RICE 框架（Reach × Impact × Confidence ÷ Effort）適合量化評估多個功能的相對優先級，在我們的資料智能產品中特別適用。
用戶價值 vs. 業務價值矩陣：把功能需求放進四個象限，優先做左上角（用戶價值高 + 業務價值高）的事，避免掉入「技術上有趣但用戶不在乎」的陷阱。
MoSCoW 法：Must Have / Should Have / Could Have / Won't Have，適合快速對齊 stakeholder 對 scope 的期待。
建立產品感知力（Product Sense）
Product Sense 是 PM 最難量化卻最重要的能力。
能否在面對一個產品時，快速識別問題在哪、機會在哪。
培養方式：
- 每週固定拆解 2-3 個你使用的產品：它的核心用戶是誰？North Star Metric 是什麼？最近的功能更新在解決什麼問題？
- 對用戶回饋保持敏感，不只看 NPS，要深入理解背後的情境
- 多參與跨產品的競品分析，建立「產品生態」的大局觀
3.產品策略的制定
產品策略的本質
策略不是路線圖，也不是功能清單。
產品策略要回答的是：在我們選定的市場中，我們如何贏？
一個清晰的產品策略應該包含：
- Where to play：我們要服務誰？在哪個市場？
- How to win：我們的差異化優勢是什麼？
- What to build：基於以上，我們優先建構什麼能力？
定義 OKR 與 KPI
OKR（目標與關鍵結果） 用來設定方向性目標，通常是季度或半年度的野心目標，例如「讓客戶能在 24 小時內完成首次 Segment 設定並觸發第一個 Campaign」。
KPI（關鍵績效指標） 是日常追蹤的量化指標，必須直接連結到業務成果，而非只是產出（output vs. outcome）。
常見的錯誤是把「功能完成數量」當成 KPI。這是 output，不是 outcome。好的 KPI 應該是「功能上線後帶動的用戶行為改變或業務數字提升」。
建立產品路線圖
路線圖的目的是溝通，不是承諾。幾個原則：
- Now / Next / Later 框架比精確的季度排程更誠實，也更有彈性
- 路線圖要隨時反映最新的策略優先級，不能變成「過去決策的紀錄」
- 對不同受眾展示不同版本：工程團隊需要細節，高層只需要方向
A/B 實驗思維
在做任何重大產品決策前，問自己：這個假設可以用實驗來驗證嗎？
好的實驗設計包含：
- 清楚的假設：「如果我們做 X，用戶的 Y 行為會提升 Z%」
- 明確的成功指標和護欄指標（guardrail metrics）
- 足夠的樣本量和實驗週期
- 實驗結束後的完整分析，包含次族群的差異
4.產品增長框架
增長迴圈（Growth Loops）
增長迴圈是比「漏斗」更準確的增長思維模型。漏斗描述的是線性流程，而迴圈強調的是自我強化的循環，用戶的行為如何帶來更多用戶或更多價值。
常見的增長迴圈類型：
- 病毒式迴圈：用戶使用產品的過程本身會引入新用戶（如分享功能）
- 內容迴圈：用戶產生內容 → 內容吸引新用戶 → 新用戶產生更多內容
- 數據迴圈：更多用戶 → 更多數據 → 更好的個人化 → 更多用戶留存
對我們的 CDP產品，值得思考的是：客戶使用平台積累的數據和 Segment 設定，如何形成他們的轉換成本（switching cost），進而構成平台的護城河？
用戶活躍化（User Activation）
Activation 是增長中最被忽視、卻影響最大的環節。用戶完成註冊後，如果沒有在關鍵時刻感受到「啊，這個產品對我有用」，就會默默流失。
提升 Activation 的方法：
- 找到你的 Aha Moment：用戶第一次真正感受到產品價值的那個瞬間
- 縮短從「完成設定」到「第一次成功體驗」的時間
- 針對未 activated 的用戶設計引導流程，而不只是讓他們自己摸索
Product-Market Fit（PMF）
PMF 不是一個要達成的狀態，而是一個要持續驗證的問題：我們的產品是否真的解決了夠多人認為重要的問題？
定價策略
定價是產品策略中最常被低估的工具。常見的定價模型：
- 基於價值（Value-based）：定價反映客戶獲得的價值，而非成本
- 基於使用量（Usage-based）：客戶按實際使用付費，適合數據平台類產品
- 分層訂閱（Tiered）：不同功能組合對應不同價位，引導客戶升級
對 B2B SaaS 產品，定價談判往往和產品功能同等重要——PM 需要理解客戶的預算結構和採購流程。
5.跨部門協作
與工程團隊合作
PM 和工程師的關係是整個產品成功的基礎。幾個關鍵原則：
- 清楚說明「為什麼」，讓工程師自己決定「怎麼做」：不要 over-specify 技術方案，除非有特定限制
- 保護工程團隊的時間：任何範圍變更都要走正式流程，不要「插隊」
- 建立技術債的可視性：技術債不是工程師的問題，是整個產品的問題，PM 要幫助它在路線圖中有位置
與設計師合作
設計師的最大價值不只是視覺呈現，而是對用戶體驗的深度思考。PM 要做到：
- 早期就拉設計師進來參與問題定義，而不是在規格確定後才交付設計任務
- 給設計師足夠的上下文：用戶是誰、使用情境是什麼、有哪些限制
- 對設計提出基於用戶需求的 feedback，而不是個人美感偏好
與數據團隊合作
在數據驅動的產品中，PM 和數據分析師的協作至關重要：
- 在功能規劃時就設計好數據埋點，不要上線後才想辦法追蹤
- 和數據團隊一起定義指標，確保計算口徑一致
- 學會閱讀數據報告，能提出第一層問題（例如「為什麼這個族群的留存率特別低？」）
與高層主管合作
向上管理是 PM 不能忽視的技能：
- 用業務語言溝通：高層關心的是市場機會、風險、和財務影響，而不是功能細節
- 提出選項而非問題：帶著建議方案去討論，而不是帶著問題去等答案
- 主動管理期待：如果預計會有 delay 或範圍變更，提早告知並說明理由
跨部門協作的底層邏輯
所有跨部門協作的問題，本質上都是資訊不對稱和優先級衝突。PM 的角色是：
- 確保所有人對產品目標有共同理解
- 建立清楚的決策機制：誰有最終決定權、哪些事需要共識、哪些事可以自主決定
- 創造心理安全感，讓各方敢於提出真實的問題和顧慮
6.PM 的心態
最後強調了幾個 PM 應有的核心心態，也是區分優秀 PM 和普通 PM 的關鍵：
- 對用戶保持真誠的好奇心：不是為了完成任務去做研究，而是真的想理解用戶的世界
- 對數據保持懷疑：數據告訴你「發生了什麼」，但不告訴你「為什麼」，兩者同樣重要
- 在不確定中做決策：PM 永遠沒有足夠的資訊，學會在模糊中推進是必備能力
- 產品思維 vs. 專案思維：不只是完成任務，而是持續思考「我們在解決對的問題嗎？」
