很多公司都說自己有產品團隊。
但實際運作可能是：主管先決定要做什麼，業務補幾個需求，產品經理整理成 Roadmap，設計師畫畫面，工程師照排程開發，最後大家用「這季上線幾個功能」判斷團隊表現。
Marty Cagan 在《INSPIRED》裡反覆指出，這種模式比較接近 Feature Factory（功能工廠）。團隊很忙，也可以準時交付，但最關鍵的問題一直沒被回答：這些功能真的解決了值得解決的問題嗎？
功能工廠的問題，不在工程速度，而在決策發生得太早
功能工廠通常不是因為團隊不努力，而是解法在工作進入團隊之前就已經被決定。
常見流程是：
- 主管或利害關係人提出一個功能。
- 產品經理寫需求。
- 設計師做介面。
- 工程師估工期。
- 排進 Sprint 或 Roadmap。
- 上線後再看有沒有人用。
這個流程最大的風險，是團隊在投入大量開發成本之前，沒有先驗證最危險的假設。
如果使用者根本不在意這個問題，後面做得再完整，仍然可能只是把錯的東西做得很漂亮。
產品發現（Product Discovery）先處理四種風險
Cagan 把產品發現的任務，整理成幾個非常實用的風險問題。
| 風險 | 要回答的問題 |
|---|---|
| 價值風險（Value Risk） | 使用者真的想要嗎？ |
| 可用性風險（Usability Risk） | 使用者真的會用嗎？ |
| 可行性風險（Feasibility Risk） | 以現有技術、時間與團隊能力做得到嗎？ |
| 商業可行性風險（Viability Risk） | 它符合商業、法規、品牌與營運條件嗎？ |
這四個問題如果有任何一個答不出來，直接進入正式開發都可能浪費大量資源。
Discovery 不是一個階段，而是持續發生的工作
有些團隊會把產品發現理解成「專案開始前做一次研究」。
做完幾場訪談、寫完一份報告，就回到原本的需求開發流程。
Cagan 的觀點不同。產品發現應該和產品交付長期並行：團隊一邊交付已經有足夠證據的方案，一邊驗證下一批機會與解法。
這個節奏和Lean UX：設計不是先做完整文件，而是先提出假設再快速驗證很接近：先把最危險的假設變成可以測試的東西，而不是先把文件做完整。
Prototype 的目的不是展示，而是用最便宜方式學習
產品發現裡的 Prototype（原型）不需要每次都接近正式產品。
如果要驗證使用者看不看得懂，一個可點擊原型可能就夠；如果要驗證技術可行性，工程師可以做一個小型技術實驗；如果要驗證需求強度，也可能先用簡化流程觀察真實行為。
關鍵是：這個原型要回答哪一個風險？
如果原型只是拿來做簡報，看起來很完整，卻沒有改變任何決策，它就沒有真正完成 Discovery 的工作。
訪談也不是問「你喜不喜歡這個功能」
使用者很容易對一個還沒付出成本的想法說「聽起來不錯」。
所以產品發現更在意過去行為、真實情境與已發生的問題。
例如不要只問：「如果有這個功能，你會用嗎？」
更有價值的是問：「你上一次遇到這個問題是什麼時候？當時怎麼處理？花了多少時間？最後有沒有真的解決？」
如果要更深入學怎麼避免得到禮貌性稱讚，可以延伸看媽媽測試（The Mom Test）：客戶訪談怎麼問，才不會只得到禮貌性稱讚。
被賦能團隊（Empowered Team）拿到的是問題，不是答案
Cagan 很重視 Empowered Product Team（被賦能產品團隊）。
這種團隊不是「想做什麼就做什麼」，而是在清楚的策略、目標與限制下，對一個問題和結果負責。
例如管理層可以給團隊一個目標：
「提高新使用者完成第一次核心任務的比例。」
但不直接指定：「做三頁 onboarding、加一支教學影片、再做一個彈窗。」
前者給的是問題與結果，後者給的是功能清單。
Missionaries 和 Mercenaries：團隊要知道自己為什麼而戰
Cagan 常用 Missionaries（使命型團隊）和 Mercenaries（傭兵型團隊）來描述兩種工作狀態。
如果團隊只收到票單、規格與期限，最合理的行為就是把票做完；一旦上線，責任也跟著結束。
但當團隊理解客戶問題、商業目標、產品願景與成功指標，就比較可能主動挑戰弱解法、提出更好的方向，也會在上線後繼續追結果。
這不是靠口號激勵，而是靠足夠的 Context（上下文）讓團隊知道什麼值得守住。
Autonomy 不等於沒有 Accountability
團隊擁有解法自主權，不代表不用負責結果。
真正的 Empowerment 同時包含兩件事：
- Autonomy（自主）：團隊有權探索與選擇解法。
- Accountability（責任）：團隊要對結果負責。
如果只有自主，沒有清楚結果，容易變成自由探索；如果只有責任，卻沒有決策權，就只是把壓力往下丟。
產品經理不是 Jira 管理員，也不是需求轉接站
在功能工廠裡，產品經理常被縮減成：
- 整理需求。
- 排優先順序。
- 追 Sprint。
- 寫規格。
- 協調利害關係人。
這些事情可能都需要做，但不是產品經理（Product Manager）的核心價值。
Cagan 對產品經理的期待更高：要真正理解客戶、資料、商業與市場，並和設計師、工程師一起判斷什麼值得做。
如果產品經理從來沒接觸客戶、也看不懂產品數據，就很難替團隊做出高品質判斷。
產品設計師不是最後把畫面變漂亮的人
在好的產品團隊裡，產品設計師（Product Designer）不是需求確定後才進場。
設計師要一起參與產品發現，理解使用者工作流程、問題、心理模型與互動風險。
因為一個功能有價值，不代表使用者一定能順利使用。
可用性風險如果等到工程做完才發現，修改成本通常已經很高。
工程師也應該參與 Discovery，不只是拿票開發
工程師往往最清楚什麼技術已經成熟、什麼能力其實可以快速組合，以及哪個想法看似簡單、背後卻有巨大技術風險。
如果工程師只在需求已經定案後才加入，團隊會失去一個重要的創新來源。
所以產品發現不是產品經理和設計師的前置工作，而應該讓工程師也參與關鍵訪談、原型與可行性驗證。
機會評估（Opportunity Assessment）：先判斷機會值不值得投資
公司裡永遠會有比資源更多的好點子。
所以 Cagan 強調機會評估：在投入設計與工程之前，先問幾個基本問題。
- 它服務哪一個商業目標？
- 目標使用者是誰？
- 使用者面對什麼問題？
- 這個問題有多嚴重？
- 目前替代方案是什麼？
- 怎麼知道我們成功了？
- 現在是正確的時機嗎？
這些問題如果回答得很薄弱，就不應該因為「主管已經提了」直接進 Roadmap。
Roadmap 不應該只是「功能＋日期」
傳統 Roadmap 常長這樣：
- 一月做會員等級。
- 二月做推薦系統。
- 三月做新版搜尋。
這種寫法最大的問題，是還沒做 Discovery 就先承諾了解法與時間。
一旦對外承諾，後面的產品發現很容易失去意義，因為就算證據顯示方向有問題，團隊也很難停下來。
結果導向 Roadmap（Outcome-based Roadmap）會更聚焦「要改善什麼結果」與「哪個問題最值得解」。
產品願景與產品策略，是團隊自主的前提
如果只告訴團隊「你們自己決定」，卻沒有共同方向，團隊很難做出一致選擇。
產品願景（Product Vision）描述的是較長期希望創造的未來；產品策略（Product Strategy）則回答現在先服務誰、先解哪個問題、先在哪個市場取得進展。
願景提供方向，策略負責聚焦。
有這些上下文之後，團隊才有可能在不必每件事都請示主管的情況下，自主做出合理決策。
產品策略的價值，是讓團隊知道什麼「先不做」
如果策略最後變成「所有客群都很重要、所有問題都要解」，那就沒有真正做出選擇。
策略要能讓團隊回答：
- 現在最重要的客群是誰？
- 最重要的問題是什麼？
- 哪一類機會先不做？
- 什麼成功訊號值得我們繼續投入？
這些界線越清楚，團隊越能真正自主。
產出（Output）和結果（Outcome）是兩種完全不同的管理方式
| 產出（Output） | 結果（Outcome） |
|---|---|
| 上線 8 個功能 | 新使用者啟用率提高 |
| 完成 40 個 Story | 完成核心任務的人變多 |
| 新版頁面準時發布 | 轉換率或任務成功率改善 |
| 交付新搜尋功能 | 使用者更快找到需要內容 |
Output 很容易量，也很容易管理，但它不保證產品真的變好。
Outcome 比較難，卻迫使團隊回到使用者與商業結果。
不是每個數字變好，都代表產品真的成功
結果導向也不能變成「挑一個指標，想辦法把它拉高」。
例如提高通知次數可能讓短期回訪增加，卻同時提高關閉通知或刪除 App 的比例。
所以團隊除了主要 Outcome，也要看護欄指標（Guardrail Metrics），避免用傷害長期體驗的方法換短期數字。
產品交付（Product Delivery）不是 Discovery 的下游工廠
產品發現不是前面的人想完，交付團隊再照著做。
Discovery 和 Delivery 應該彼此循環：
- 發現一個值得解的機會。
- 快速測試多個解法。
- 降低四種主要風險。
- 用小批次交付。
- 觀察真實使用數據。
- 把新的學習帶回下一輪 Discovery。
這樣產品才會變成一個持續學習系統，而不是一次又一次的專案。
小公司也能用 Marty Cagan 的方法，不需要先成立完整產品部門
如果團隊只有三、五個人，不需要硬湊 Product Manager、Designer、Researcher、Analyst 等所有角色。
真正可以先借用的是工作方式：
- 需求先寫成問題，不急著寫成解法。
- 重要想法先測最危險假設。
- 工程師不要等到最後才加入。
- 每個功能都先定義想改善的結果。
- 上線後一定要回頭看真實行為。
角色可以一人兼任，但價值、可用性、可行性與商業可行性這四種風險不能因為團隊小就消失。
一張表判斷你現在是不是 Feature Factory
| 現象 | 比較像功能工廠 | 比較像被賦能團隊 |
|---|---|---|
| 工作入口 | 收到功能需求 | 收到問題與目標 |
| 成功定義 | 準時上線 | 結果改善 |
| 工程師角色 | 估工、開發 | 參與 Discovery 與解法 |
| 產品經理 | 管理 Backlog | 理解客戶、資料、商業與市場 |
| Roadmap | 功能＋日期 | 問題＋Outcome |
| 上線後 | 進下一個功能 | 衡量、學習、調整 |
常見問題
Empowered Team 是不是管理層不能指定任何東西？
不是。管理層仍然要提供願景、策略、商業目標、限制與上下文。差別在於不要把每個解法都先指定好，再要求團隊為結果負責。
Discovery 會不會讓開發變慢？
Discovery 會增加前期學習，但它的目的就是在昂貴開發之前淘汰弱想法。真正要比較的不是「多花幾天研究」，而是「少做幾個沒人要的功能」能省多少成本。
每個功能都要訪談五個使用者嗎？
不一定。不同風險要用不同方法驗證。可用性可以做原型測試，技術風險可以做工程探索，價值風險也可能需要數據、行為測試或訪談。
Outcome 會不會比功能更難管理？
會，因為 Outcome 不完全由團隊控制。但它也更接近產品真正存在的理由。重點是選擇團隊可以影響、而且和使用者及商業價值有關的結果。
Stakeholder 的需求都不能直接做嗎？
不是。利害關係人的資訊很重要，但應該把「我要這個功能」轉成「這背後要解決什麼問題」，再判斷最佳解法，而不是把提出需求的人當成唯一解法來源。
產品願景需要多久改一次？
願景通常比季度目標穩定，策略則會依市場與學習調整得更頻繁。最重要的是團隊知道現在的決策要服務哪個長期方向。
Marty Cagan 的產品思維，最後是在改變「誰負責想」
功能工廠把思考集中在少數主管與利害關係人，團隊的工作是執行。
被賦能產品團隊則把問題、上下文與結果交給最接近使用者與技術的人，讓產品經理、設計師與工程師一起探索解法。
這不會讓產品決策變得比較輕鬆，反而要求團隊更懂客戶、更懂資料、更懂商業，也要承擔結果。
但它把最重要的學習移到工程投入之前，也讓「做了很多」和「產品真的變好」不再被混為一談。
參考資料：
Marty Cagan｜INSPIRED: How to Create Tech Products Customers Love。
Marty Cagan、Chris Jones｜EMPOWERED: Ordinary People, Extraordinary Products。