很多公司說自己有產品團隊，但實際運作方式仍然很像功能工廠（Feature Factory）。
主管決定要做什麼，業務把客戶需求丟進來，產品經理整理成 Roadmap，設計師畫畫面，工程師照規格開發，最後大家用「這季上了多少功能」來衡量成果。
這種流程最大的問題，在於沒有人負責回答一個更重要的問題：
我們現在做的東西，真的能改善客戶與公司的結果嗎？
Marty Cagan 在《INSPIRED》與《EMPOWERED》裡一直強調，成熟的產品團隊應該承擔解題責任，而不是只負責接單執行。
功能工廠和產品團隊，差別不在職稱
一間公司可以同時有 Product Manager、Designer、Engineer，仍然是功能工廠。
判斷方式很簡單：團隊拿到的是「要做什麼功能」，還是「要解決什麼問題」？
| 功能工廠 | 自主產品團隊 |
|---|---|
| 收到功能清單 | 收到問題與目標 |
| 對交付日期負責 | 對結果負責 |
| 先寫規格再開發 | 先探索再決定方案 |
| 工程師最後才加入 | 工程師參與探索 |
| 成功＝功能上線 | 成功＝指標改善 |
這個差別會直接改變產品經理、設計師、工程師每天在做什麼。
自主產品團隊：團隊要有解決問題的空間
自主產品團隊（Empowered Product Team）通常是一個穩定、跨職能的小隊，至少包含產品、設計與工程能力。
它的任務是針對某個客戶問題或商業目標找到可行解法，而不只是照 Roadmap 完成功能。
例如：
- 不是「做一個推薦功能」。
- 而是「提高新使用者第一週的啟用率」。
團隊可以最後選擇推薦、導覽、內容排序、提醒、範例資料，甚至發現根本不需要新功能。
這種授權有清楚邊界：解法空間交給最接近客戶與技術的人，同時仍受到目標與策略限制。
使命型與接單型團隊，差在有沒有理解問題本身
《EMPOWERED》用使命型（Missionary）與接單型（Mercenary）的差異，說明兩種不同的團隊狀態。
使命型團隊知道自己為什麼做這件事，理解客戶與問題，也參與形成解法；僱傭型團隊則比較像接單，拿到需求後照做，做完就往下一張 Ticket 走。
這不要求每個人都要熱血。重點在於：當團隊理解問題、參與探索，遇到困難時更有可能主動找替代方案；如果只接到規格，最合理的反應通常就是照單完成。
產品經理不是專案經理
Marty Cagan 對產品經理的期待，比「管 Backlog、排 Sprint、追進度」高很多。
產品經理主要要承擔 Value（價值）與 Viability（商業可行性）的風險。
他需要深入理解：
- 客戶到底是誰。
- 他們現在怎麼解決問題。
- 數據顯示什麼。
- 公司的商業模式與策略。
- 市場、競爭與限制。
如果 PM 每天主要工作是催 Ticket、開會、整理需求，產品決策通常仍然在其他地方發生。
產品設計師不只是把畫面做漂亮
產品設計師要負責整體使用者體驗，而不只是 UI。
他需要和產品經理一起理解問題、建立 Prototype、測試流程、觀察使用者是否真的看得懂、做得到。
如果設計師只在需求確定後才接到 Wireframe 任務，Discovery 已經少掉非常重要的一塊。
工程師也不是最後才接規格的人
工程師往往最清楚「現在技術上能做到什麼」以及「哪些做法成本差很多」。
如果工程師只在方案已經決定後才加入，團隊會失去大量創新機會。
例如設計師想出一個需要三個月的方案，工程師可能知道有一個不同做法兩天就能驗證同一個假設。
這就是為什麼 Cagan 強調工程師要參與 Discovery，而不只是 Delivery。
產品探索與交付是兩件不同的工作
產品探索（Discovery）回答的是：
什麼值得做？什麼做法比較可能成功？
交付（Delivery）回答的是：
怎麼把已經值得投入的方案做成穩定、可維護、可上線的產品？
很多團隊跳過第一段，從需求直接進 Sprint。
這樣做速度看起來很快，但如果方向錯了，只是更快把錯的東西做完。
產品探索要先處理四種風險
Cagan 把產品探索的核心風險拆成四類：
| 風險 | 要回答的問題 |
|---|---|
| Value | 客戶真的想要嗎？ |
| Usability | 客戶真的會用嗎？ |
| Feasibility | 工程上真的做得出來嗎？ |
| Viability | 對公司、法規、營運、商業模式可行嗎？ |
任何一種風險沒有處理，都可能讓一個看起來很完整的功能失敗。
例如使用者很喜歡，但公司根本無法獲利；或商業模式沒問題，但操作流程太難，最後沒有人真的用。
原型的目的，是低成本發現錯誤
Discovery 階段不需要每個想法都做成正式產品。
可以用：
- 紙上草圖。
- 可點擊 Prototype。
- Fake Door。
- Wizard of Oz。
- 工程 Spike。
Prototype 的任務是用最低成本回答最危險的假設，不需要先把東西做得像正式產品。
如果你想進一步理解「先驗證再投入」這個觀念，可以延伸看Lean Startup：MVP 不是做一個很陽春的產品，而是最快驗證最危險的假設。
產品探索是跨職能工作
如果產品經理自己訪談、自己整理、自己寫 PRD，再丟給設計與工程，跨職能理解仍然沒有形成。
更好的做法是讓產品、設計、工程一起看客戶、一起看 Prototype、一起討論風險。
這樣團隊對問題會有共同理解，工程師也不會只看到最後一張需求單。
持續產品探索：不是專案開始前做一次研究
Discovery 不是一次性的前置階段。
產品上線後，數據、客戶行為、商業目標都會改變，所以探索也要持續。
團隊應該建立固定接觸客戶與驗證想法的節奏，而不是半年做一次大研究。
這一點可以搭配Continuous Discovery Habits：產品團隊為什麼要每週接觸客戶一起看。
機會評估：別讓最會吵的人決定產品路線圖
公司永遠有比資源更多的好點子。
所以在投入前，可以先用 Opportunity Assessment（機會評估）問：
- 這件事服務哪個商業目標？
- 目標客戶是誰？
- 他現在遇到什麼核心問題？
- 如果解決，成功要怎麼衡量？
- 現有替代方案是什麼？
- 現在是不是適合處理這個問題？
這種問法可以把「主管說要做」「業務說客戶想要」轉成一個可以被檢驗的機會。
利害關係人可以提問題，但不要直接把解法當成需求
業務、主管、客服、法務、行銷都可能看見很重要的問題，產品團隊不應該把 Stakeholder 當成干擾來源。
但「客戶一直抱怨找不到某功能」和「所以我們一定要做一個新選單」是兩件不同的事。
前者是問題訊號，後者已經是解法。
比較成熟的合作方式，是先把 Stakeholder 的要求翻成客戶問題、商業目標與限制，再由團隊去探索最合適的解法。這樣既不忽略重要意見，也不會讓 Roadmap 變成各部門願望清單。
產品願景是方向，產品策略是選擇
Product Vision（產品願景）描述的是未來想創造什麼樣的世界。
Product Strategy（產品策略）則回答：為了走到那裡，我們現在先服務誰、先解決哪個問題、先放棄什麼。
沒有願景，團隊容易只看眼前功能；沒有策略，團隊會覺得所有事情都重要。
自主不代表各做各的，而是大家在同一個方向與策略邊界裡做決策。
產品原則：讓團隊在沒有主管時也能做一致決定
產品原則（Product Principles）是介於 Strategy 和日常選擇之間的 Guardrail。
例如「優先簡單，而不是把所有進階選項都放給新手」「遇到資料不完整時，先保護使用者信任，再追求轉換」。
這些原則要能在兩個方案都合理時，實際拿來做取捨；如果不能影響決策，就只剩口號。
如果團隊每一個細節都要回頭等主管拍板，代表 Context 還不夠完整，也很難稱為真正擁有自主解題空間。
成果導向產品路線圖：應該寫問題，而不是先寫解法
功能型 Roadmap 常寫：
- 第三季上線推薦系統。
- 第四季增加社群登入。
- 明年第一季改版首頁。
問題是，這些都是解法，而且常常在 Discovery 之前就已經被承諾。
Outcome-based Roadmap（成果導向 Roadmap）會更像：
- 提高新使用者啟用率。
- 降低首次購買前的流失。
- 提高回訪與續訂。
這樣團隊才能對成果負責，而不是只對功能是否準時上線負責。
功能工廠最大的陷阱，是「很忙但沒有學到東西」
功能工廠最常見的狀態是：
- Sprint 每次都很滿。
- Velocity 很高。
- Roadmap 持續往前。
- 功能一直上線。
但上線後沒有人追蹤：
- 有多少人用了？
- 解決了原本問題嗎？
- 指標有沒有改善？
- 如果沒有，下一步要學什麼？
產出很多，不代表產品進步很多。
不要只量開發速度，要量客戶與商業結果
Velocity、Story Points、完成多少 Ticket 可以幫助團隊安排工作，但不應該直接等同產品價值。
一個團隊可能準時完成十個功能，卻沒有任何一個改善留存、營收、成本或客戶體驗。
更好的做法是先為每個問題設定 Outcome Metric，再決定用什麼方案改善。
功能發布之後，工作還沒有結束
功能上線只是開始收集真實證據。
上線後應該繼續看：
- 採用率。
- 成功完成率。
- 流失位置。
- 客戶回饋。
- 對核心商業指標的影響。
如果結果沒有改善，團隊要回到 Discovery，而不是立刻開始下一個功能。
自主團隊不等於沒有管理
「自主」很容易被誤解成主管放手不管。
其實高品質的產品管理需要更強的領導：
- 清楚的 Vision。
- 清楚的 Strategy。
- 明確 Outcome。
- 好的 Context。
- 持續 Coaching。
領導者要讓團隊知道為什麼、邊界在哪裡，以及最後要達成什麼；每個功能的細節不需要都由主管先決定。
如果主管已經指定解法，還能叫自主產品團隊嗎？
偶爾有法規、資安、合約等硬性要求，解法空間確實很小。
但如果大多數產品工作都是「高層先決定功能，團隊負責執行」，就很難稱為真正的自主產品團隊。
比較好的做法是把命令重新翻成問題：
「老闆要 AI 功能」可以改成「我們想降低客服成本，AI 是其中一個可能方案」。
只要問題和成功標準還能被探索，團隊就還有產品工作的空間。
一個簡單的 7 題診斷：你的團隊是不是功能工廠？
| 問題 | 如果回答否 |
|---|---|
| PM 能直接說出最重要的客戶問題嗎？ | 客戶知識不足 |
| 重大想法會先找真實使用者測試嗎？ | Discovery 太弱 |
| 工程師有參與探索嗎？ | 創新能力被浪費 |
| 團隊對 Outcome 負責嗎？ | 還在用 Output 管理 |
| 團隊能解釋 Vision 與 Strategy 嗎？ | 缺乏決策脈絡 |
| Stakeholder 提的是問題而不是指定功能嗎？ | 團隊仍是接單單位 |
| 上線後會量結果並回到 Discovery 嗎？ | 交付和學習斷裂 |
如果多數答案是否，問題通常不在 Sprint 流程，而在整個產品運作模式。
從功能工廠轉型，不要一次把所有流程翻掉
可以先選一個團隊、一個目標做試點：
- 給團隊一個清楚 Outcome，而不是指定功能。
- 保留一段固定 Discovery 時間。
- 讓工程師一起參與訪談與 Prototype。
- 只把已經有證據的方案送進 Delivery。
- 上線後追結果，不只追日期。
先讓團隊體驗一次「問題 → 探索 → 解法 → 上線 → 學習」的完整循環，再逐步擴大。
常見問題
產品探索會不會拖慢開發？
短期會多一些探索時間，但目的就是避免把大量工程時間投入到錯誤方案。對高成本功能而言，早點發現錯誤通常更便宜。
自主產品團隊可以完全不理主管嗎？
不行。團隊仍然要在公司 Vision、Strategy、商業限制與目標內運作，只是解法不應全部由遠離問題的人先決定。
小公司也需要產品探索嗎？
需要，只是可以更輕量。創辦人直接訪談客戶、快速做 Prototype、先測最危險假設，本身就是 Discovery。
產品路線圖還可以有日期嗎？
可以，但越早期、越高不確定性的項目，越不適合承諾精確日期與固定解法。日期應該配合證據成熟度與實際商業承諾。
怎麼知道團隊已經不再是功能工廠？
當團隊能清楚說出正在解決的問題、自己參與 Discovery、擁有 Outcome 指標，並能根據證據改變原本解法時，才比較接近成熟的產品團隊。
產品團隊的核心，是對問題與成果負責
《INSPIRED》與《EMPOWERED》挑戰的是公司願不願意把「解題責任」交給產品團隊。
如果團隊只能執行別人想好的解法，再好的 Sprint、Backlog 與 Roadmap，也只是把功能工廠管理得更有效率。
成熟的產品團隊會先理解客戶與商業問題，再用 Discovery 降低四種風險，用 Delivery 把有證據的方案做成可靠產品，最後對成果負責。
產品工作的價值，不在上線多少東西，而在於有多少問題真的被解決。
參考資料
Marty Cagan：INSPIRED: How to Create Tech Products Customers Love。
Marty Cagan、Chris Jones：EMPOWERED: Ordinary People, Extraordinary Products。