產品經理 PM
連結顧客需求與業務目標，釐清問題、成果與優先順序。
3 分鐘掌握
PM 的協作難題不是「要不要讓大家參與」，而是「誰在什麼時候參與、帶著什麼問題參與」。太晚才加入會增加返工；太早把一群人拉進模糊討論，則容易失焦。
核心原則：PM 先把問題與商業脈絡說清楚；接著讓產品鐵三角共同探索需求，並持續協作到實作、測試與上線。
產品鐵三角，各自補上不同視角
設計師
檢查體驗是否直覺、易懂，協助驗證方案是否好用。
工程師
評估技術可行性、實作限制與資源需求，及早指出風險。
鐵三角不是排除其他利害關係人，而是凸顯數位產品需要跨職能共同探索；其他角色則依問題與階段加入。
產品開發五階段
架構問題
先定義問題、顧客與預期成果。
界定需求
三方共同研究、排序、設計並評估可行性。
實作
持續同步進度，及早處理需求與技術落差。
測試
共同檢查使用流程、介面與未驗證情境。
上線
協作發表訊息、支援內容與顧客溝通。
節奏拿捏：問題不清楚時，先由 PM 整理脈絡；問題值得解決後，讓設計與工程及早加入探索，不要等到需求文件或設計稿定案才交接。
需求探索要同時看三類風險
渴望度
顧客真的需要這項功能嗎？
檢查：需求證據與使用者問題易用性
使用者能找到並有效使用嗎？
檢查：流程理解與體驗測試可行性
以現有技術、資源與限制做得出來嗎？
檢查：技術評估與實作限制把框架放進團隊工作
階段 1｜對齊問題
PM 整理問題概述：受影響顧客、問題證據、商業關聯、預期成果與未知事項。先確認「為什麼值得做」，不急著指定解法。
階段 2｜共同探索
PM、設計師、工程師共同研究、整理使用者故事、排序需求、調整設計稿，並同步評估技術限制。其他利害關係人依需要加入。
階段 3｜持續參與
進入實作不代表 PM 和設計師退場。透過團隊既有進度檢視，及早發現偏差；需求或設計要改時，三方一起評估並留下決策。
階段 4｜共同測試
在適當測試環境走查主要流程，找出介面不一致、遺漏情境與尚未驗證之處；視情況邀請內部業務角色參與。
階段 5｜協作上線
準備發表公告、幫助中心與內部支援資訊，並由產品鐵三角檢查所有顧客訊息是否符合實際功能。
常見做法：前後對照
接力式交接
PM 先獨自定需求，設計師完成視覺稿後才交給工程師；工程限制晚出現，於是大幅返工、時程延誤，也傷害合作信任。
分階段、持續協作
PM 先說清楚問題與目標，再邀鐵三角共同探索；工程、設計與 PM 在實作、測試及上線仍保持溝通。
團隊討論檢核
我們描述的是顧客問題，還是已假定的解法？
設計與工程是否在需求探索早期參與？
需求是否同時檢查需要、易用與可行？
實作階段的需求／設計變更有沒有共同檢視？
測試是否涵蓋主要使用流程與易漏情境？
對外訊息是否與實際功能及已知限制一致？
這是依文章原則整理的討論清單，不是文章指定的組織制度或核准標準；團隊可按自身產品與權責調整。