本章深入展開 Product Owner 角色的描述，涵蓋其目的、主要職責、特質、日常工作、不同開發類型下的適任人選，以及角色組合與擴展為 Product Owner 團隊的方式。
概述#
Product Owner 是產品領導力的授權中心點（empowered central point of product leadership），是構成每個 Scrum 團隊的三個協作角色之一（另兩個是 ScrumMaster 和開發團隊）。
Product Owner 必須同時面向兩個方向：
Figure 9.1: The product owner faces two directions simultaneously.
- 面向利害關係人：理解組織內部利害關係人、客戶和使用者的需求與優先順序，充當他們的代言人，確保開發正確的解決方案
- 面向開發團隊：溝通要建造什麼以及建造的順序，確保驗收標準被定義且測試被執行
主要職責#
Figure 9.2: Principal product owner responsibilities
這是一個全職角色，職責範圍涵蓋六大面向。
管理經濟性（Manage Economics）#
Product Owner 負責確保在 Release、Sprint 和 Product Backlog 三個層面上持續做出良好的經濟決策。
Figure 9.3: The product owner manages economics.
Release 層面的經濟決策：
- 在開發過程中持續對範圍、日期、預算和品質做取捨
- 每個 Sprint 結束時決定是否資助下一個 Sprint
- 若進度良好且產品已可交付，可決定提前交付（例如原計畫 10 個 Sprint，在第 7 個 Sprint 後即可出貨）
- 若核心經濟條件改變（例如法規變更），可在進展順利的情況下仍決定取消開發
Sprint 層面的經濟決策：
- 確保每個 Sprint 都有良好的投資報酬率（ROI）
- 好的 Product Owner 對待組織的錢就像對待自己的錢：「我願意從自己的銀行帳戶開出一張等同於這個 Sprint 成本的支票，來換取我們計畫在這個 Sprint 中建造的功能嗎？」
Product Backlog 層面的經濟決策：
- 當經濟條件改變時，Product Backlog 的優先順序也要跟著調整
- 例如：某功能原以為對大量使用者有價值且開發成本不高，但後來發現實際成本很高且僅對少數使用者有價值——應重新排序甚至移除
參與規劃活動#
Product Owner 是 Portfolio、Product、Release 和 Sprint 各級規劃活動的關鍵參與者：
| 規劃層級 | 說明 |
|---|---|
| Portfolio Planning | 與內部利害關係人合作定位產品在 Portfolio Backlog 中的位置 |
| Product Planning | 與利害關係人合作進行產品願景構想 |
| Release Planning | 與利害關係人和團隊定義下一個 Release 的內容 |
| Sprint Planning | 與開發團隊定義 Sprint Goal，提供有價值的資訊使團隊能選擇可實際交付的 PBI |
梳理 Product Backlog#
Product Owner 負責監督 Product Backlog 的梳理（Grooming），包括創建與精煉、估算和排序。Product Owner 不必親自完成所有梳理工作（例如不負責估算，那是開發團隊的事），但須確保梳理活動以促進價值順暢流動的方式進行。
定義驗收標準並確認達成#
- 為每個 PBI 定義驗收標準（Acceptance Criteria）——Product Owner 感到滿意的功能性與非功能性需求條件
- 確保驗收標準在 Sprint Planning 之前就已建立，否則團隊對該項目的理解將不完整
- 許多團隊將「有清晰的驗收標準」納入準備就緒定義（Definition of Ready）
Product Owner 應在 Sprint 執行期間驗證驗收標準，而非等到 Sprint Review。及早測試能在 Sprint Review 之前發現錯誤和誤解，讓團隊有機會修正。
sequenceDiagram
participant PO as Product Owner
participant Dev as 開發團隊
PO->>Dev: Sprint Planning 前定義驗收標準
Dev->>Dev: Sprint 中開發功能
Dev->>PO: 功能完成，請求驗證
PO->>Dev: Sprint 執行期間即時驗證
alt 通過驗收
PO-->>Dev: 確認達成
else 發現問題
PO->>Dev: 回饋錯誤或誤解，Sprint 內修正
end與開發團隊協作#
Product Owner 是一個參與式、承諾式、每日投入的角色。許多剛採用 Scrum 的組織未能促進足夠的 Product Owner 參與，延遲了關鍵回饋。
Figure 9.4: Comparison of customer or business engagement over time
傳統階段式開發中，客戶參與呈U 形（浴缸曲線）：需求階段大量參與 → 技術階段幾乎不參與 → 最後使用者驗收測試時才重新參與，此時發現產品不符預期，但為時已晚。
在 Scrum 中，我們一次建造一個功能（非一個階段），因此 Product Owner 需要持續的高度參與。短期 Timebox 的密切互動大幅降低 Product Owner 和開發團隊脫節的機率。
與利害關係人協作#
Product Owner 是整個利害關係人社群的單一聲音：
- 內部：業務系統擁有者、高階管理層、專案管理、行銷、銷售
- 外部：客戶、使用者、合作夥伴、監管機構
Product Owner 必須與整個利害關係人社群緊密合作，蒐集意見並綜合出連貫的願景。
特質與技能#
Figure 9.5: Product owner characteristics
領域技能（Domain Skills）#
| 特質 | 說明 |
|---|---|
| 願景家 | 能綜合產品願景並領導團隊達成 |
| 知道無法預先掌握所有事情 | 願意在變革有必要時進行調整 |
| 具備業務與領域知識 | 難以在不了解產品領域的情況下有效設定優先順序 |
人際技能（People Skills）#
| 特質 | 說明 |
|---|---|
| 與利害關係人有良好關係 | 充當「客戶的聲音」 |
| 談判者與共識建立者 | 面對可能有衝突需求的多方利害關係人 |
| 良好的溝通者 | 願意發聲、有自信、了解主題、簡潔明瞭且有公信力 |
| 強力的激勵者 | 在艱難時刻提醒大家為何投入努力 |
決策能力（Decision Making）#
| 特質 | 說明 |
|---|---|
| 被授權做決策 | 組織指派一個沒有決策權的人當 Product Owner 是常見的阻礙 |
| 願意做困難的決定 | 在範圍、日期、預算等限制條件間做取捨 |
| 果斷 | 決策及時且不無故反覆 |
| 以經濟觀點平衡業務與技術議題 | 天真的 Product Owner 決策是系統累積不可接受技術債務的顯著成因 |
當責性（Accountability）#
| 特質 | 說明 |
|---|---|
| 為交付良好的業務成果負責 | 對確保資源以經濟合理的方式使用負有責任 |
| 承諾與可及 | Product Owner 是全職工作，兼職做是失敗的秘方 |
| 像 Scrum 團隊成員一樣行動 | 尊重開發團隊和 ScrumMaster，視彼此為夥伴，共享「三劍客精神」（Musketeer Attitude） |
一日之生活#
Figure 9.6: A day in the life of a product owner
Product Owner 在產品開發過程中的典型活動時間線：
- 第 1-2 週：參與 Portfolio Planning 和 Product Planning（產品願景構想），提交產品提案供經濟篩選並取得資金核准
- 第 3 週：進行初始 Release Planning，包括 PBI 撰寫工作坊、估算工作坊、初始 Release Planning 會議（通常不超過一兩天）
- 第 4-5 週（Sprint 1）：
- 監督 Sprint Planning
- 盡可能參加每日站會（Daily Scrum）
- 每日可及以回答問題並測試完成的功能
- 與內外部利害關係人會面確認優先順序
- 持續梳理 Product Backlog
- 參與 Sprint Review 和 Sprint Retrospective
Release Planning 是持續性活動，初始時不應過度投入追求精確——隨著更好的資訊到來會持續更新。
誰應該擔任 Product Owner？#
適任人選取決於開發類型和組織特性。
Figure 9.7: Example of a product owner on internal development
內部開發（Internal Development）#
應由受益方的授權代表擔任。例如：IT 部門為行銷部門開發系統，應由行銷團隊中被授權的人擔任 Product Owner。
Figure 9.8: Example of a product owner on commercial development
商業開發（Commercial Development）#
Product Owner 應是組織內部充當客戶代言人的員工，通常來自產品管理或產品行銷部門。
Figure 9.9: Pragmatic Marketing framework
關於 Product Owner 與 Product Manager 的關係：
- Product Owner 至少負責 Pragmatic Marketing 框架中「技術產品經理」相關的活動
- 但作者認為 Product Owner 的角色範圍可以更廣，視組織、產品和個人技能而定
- 一個簡單的手機單位轉換 App 所需的活動遠少於企業級 BI 產品的下一個主要版本
Figure 9.10: Example of a product owner on outsourced development
外包開發（Outsourced Development）#
Product Owner 應來自付費方（委託公司），而非承包商。更適當的合約模式是委託公司租用承包商的高績效團隊與 ScrumMaster，並由委託公司自行提供 Product Owner。
Figure 9.11: Example of a product owner on component development
元件開發（Component Development）#
元件團隊聚焦於技術層面，其 Product Owner 通常是技術導向的人員，能夠定義和排序技術性功能的 Backlog。
Product Owner 與其他角色的組合#
Figure 9.12: Same person as product owner of more than one Scrum team
- 若能力允許，同一個人可以擔任多個 Scrum 團隊的 Product Owner（通常在同一開發工作上更容易）
- 同一個人偶爾可以同時是 Product Owner 和開發團隊成員
強烈不建議同一個人同時擔任 Product Owner 和 ScrumMaster。這兩個角色互相制衡，由同一人扮演會產生利益衝突。
Product Owner 團隊#
每個 Scrum 團隊必須有一個單一個人被認定為 Product Owner，是唯一被授權且負責履行 Product Owner 職責的人。
何時需要 Product Owner 團隊#
- Product Owner 在特定情境下無法獨自完成工作，需要一群人提供意見和指導
- Product Owner 的工作量超過任何一個全職人員能合理承擔的範圍
建立 Product Owner 團隊時要小心：不稱職的 Product Owner 不需要委員會——他們需要換個角色。同樣，太忙的 Product Owner 可能不需要團隊——真正的問題可能是組織同時啟動了太多開發工作。
Product Owner 代理（Proxy）#
有些公司讓 IT 人員（如業務分析師）代行 Product Owner 職責，因為業務單位人員太忙。更好的做法是釋出足夠的業務人員時間擔任真正的 Product Owner，同時讓 IT 人員在特定互動中擔任Product Owner Proxy。
關鍵原則：Product Owner 必須真正授權 Proxy 做決定，且不應不合理地推翻 Proxy 的決策以致損害其信譽。
flowchart TD
A["PO 工作負荷過重"] --> B{"是能力不足<br/>還是工作過載?"}
B -->|"能力不足"| C["更換 PO"]
B -->|"工作過載"| D{"組織是否同時<br/>啟動太多工作?"}
D -->|"是"| E["減少在製品<br/>降低工作量"]
D -->|"否"| F["建立 PO 團隊<br/>或指派 PO Proxy"]首席 Product Owner（Chief Product Owner）#
Figure 9.13: Hierarchical product owner role
在非常大的產品中（例如涉及 2,500 人、250+ 個團隊），Product Owner 角色需要層級化擴展：
- Chief Product Owner——整個產品的 Product Owner
- 產品線 Owner（Product Line Owners）——中間層
- 功能 Product Owner（Feature Product Owners）——各團隊的 Product Owner
確保個別團隊的 Product Owner 仍被授權在其層級做絕大多數決定，而非將決策上推到更高層級。