Chapter 02 - Digital Product and Service Management

本章目標

看完本章後，你應該可以回答：

• digital product 和 service 的差異是什麼？
• 為什麼 ITIL V5 不只講 service，也講 product？
• outcome、cost、risk、experience 和 sustainability 怎麼影響 value？
• utility 和 warranty 差在哪裡？
• PM 如何用 ITIL 判斷一個功能是不是「真的有交付 value」？
• 考試遇到 product / service / outcome 題目時要怎麼判斷？

一句話

Digital product 是組織提供能力的載體，service 是幫使用者達成 outcome 的方式；ITIL 關心的是兩者如何一起被管理，最後共同創造 value。

核心概念

Product

Product 可以先理解成一組被組織管理的能力。它可能包含 application、API、data、workflow、documentation、support model、monitoring、roadmap 和 commercial model。

對 PM 來說，product 不是只有畫面或功能。「核心服務能力」可能包含：

• checkout UI
• core API
• third-party external gateway integration
• transaction database
• retry logic
• data correction operation
• monitoring dashboard
• incident runbook
• customer support workflow

如果只有 API 存在，但沒有 monitoring、support、rollback、SLA 溝通和營運流程，這比較像「有技術元件」，還不算一個被穩定管理的 digital product。

Service

Service 是 provider 幫 consumer 達成 outcome 的方式。重點不是「我提供了什麼工具」，而是「使用者能不能在不承擔所有成本和風險的情況下完成想完成的事」。

例如 AWS RDS 的 product 能力包含 database engine、backup、replication、monitoring、security integration。對 客戶 來說，它消費的是 database service：不用自己管理硬體、OS patch、storage replacement，就能取得可用的 database outcome。

Service Offering

Service offering 是 provider 對外提供 service 時的具體包裝。它可能包含：

• access to resources
• service actions
• goods
• support terms
• service levels
• pricing

例子：同樣是 core service capability，內部團隊可能提供不同 service offering：

• 標準核心 API
• 高風險交易人工審核
• 客戶資料修正後台
• 月結報表匯出
• VIP 客戶支援

Outcome

Outcome 是使用者真正想達成的結果，不是系統輸出的功能。

錯誤理解：

• 「我們做了核心 API」

比較好的理解：

• 「使用者可以穩定完成主要操作」
• 「客服可以快速查到交易狀態」
• 「營運可以降低人工對帳時間」
• 「客戶能在可接受風險下完成主要操作」

Cost

Cost 不只是錢，也包含時間、人力、認知負擔、營運成本、維護成本和機會成本。

PM 要問：

• 這個功能讓誰省時間？
• 這個服務把成本轉嫁給誰？
• 使用者要不要學很多東西才能完成工作？
• 工程團隊的維護成本會不會太高？

Risk

Risk 是 outcome 不確定性帶來的影響。好的 service 通常會幫 consumer 降低部分 risk，而不是只把工具丟給對方。

線上服務例子：

• API timeout risk
• duplicate request risk
• abuse risk
• data correction error risk
• data leakage risk
• release regression risk

Utility and Warranty

Utility 是「功能有沒有用」，warranty 是「使用時是否穩定、可用、安全、符合需求」。

核心 API 的例子：

• Utility：可以建立交易、查詢交易、資料修正請求
• Warranty：99.9% availability、timeout 可控、資料安全、尖峰流量可承受、錯誤時可追蹤

很多團隊只做到 utility，卻忽略 warranty。從 ITIL 的角度，這會讓 service value 不完整。

PM 視角

PM 最需要避免的是把「功能完成」誤認成「服務交付完成」。

以 服務流程來看：

Feature: 使用者可以按下操作按鈕
Product capability: checkout + core API + external gateway + transaction record
Service outcome: 使用者可以可靠完成主要操作，客戶可以確認處理結果，客服可以處理異常
Value: 成交率提升、客服成本降低、收入可回收、使用者信任提升

PM 在寫需求時，可以多問四個問題：

1. 使用者真正想完成的 outcome 是什麼？
2. 哪些 cost 是我們要幫他降低的？
3. 哪些 risk 是 service 必須幫他承擔或控制的？
4. 只有 utility 夠嗎，還是 warranty 才是成敗關鍵？

Developer / DevOps 視角

工程交付的東西通常是 component，但 ITIL 看的最後結果是 service。

例如 React + Java + AWS 的 release：

React checkout page
        ↓
Java core API
        ↓
RDS transaction table
        ↓
CloudWatch metrics
        ↓
PagerDuty escalation
        ↓
Runbook and rollback
        ↓
Payment service

Developer 可能覺得「API 已經 merged」。DevOps 可能覺得「deployment 成功」。PM 要補上的問題是：「使用者的 outcome 是否真的被穩定支援？」

這也是為什麼 service management 不等於 ticket management。Ticket 只是追蹤工作，service management 要看的是整個 value flow。

AWS 對照

AWS 很適合用來理解 product 和 service 的差異。

以 Amazon RDS 為例：

• Product capability：database engine、backup、replication、parameter group、monitoring
• Service outcome：團隊能使用 relational database，而不用自行管理大部分基礎設施
• Cost reduction：少掉硬體採購、OS patch、manual backup、部分 HA 維運
• Risk reduction：managed backup、multi-AZ、monitoring、support channel
• Warranty：availability、security controls、performance options、recovery mechanism

但 AWS 也不會替你承擔所有 risk。你仍然要設計 schema、index、connection pool、access control、backup retention、DR strategy。這就是 shared responsibility 的現實版：service provider 和 consumer 共同創造 value。

實務對照

假設 團隊要做「服務狀態查詢」。

只從 product backlog 看，可能是一個功能：

• 使用者可以看到操作成功或失敗
• 客服可以查詢交易狀態
• 系統可以顯示錯誤原因

但從 service management 看，還要問：

• external gateway 回傳 pending 時怎麼顯示？
• 使用者重複提交操作會不會造成 duplicate request？
• 客服看到的狀態和使用者看到的狀態是否一致？
• CloudWatch alarm 觸發後誰處理？
• incident 發生時誰通知客戶或使用者？
• release 新版核心服務邏輯時如何 rollback？

這些問題都不是「多餘流程」。它們決定這個 digital product 能不能成為可靠 service。

常見誤解

誤解 1：Product 就是功能，Service 就是客服

更好的理解：product 是被管理的一組能力，service 是讓 consumer 取得 outcome 的方式。客服可能是 service 的一部分，但 service 不等於客服。

誤解 2：只要功能可以用，就代表 value 已經交付

功能能用只代表 utility 可能存在。若 availability、security、support、performance、operability 不足，warranty 不完整，value 仍然可能很低。

誤解 3：Managed service 代表 consumer 沒有責任

Managed service 只是 provider 承擔一部分 cost 和 risk。Consumer 仍要負責設定、使用方式、資料、權限、需求判斷和 business outcome。

誤解 4：PM 不需要懂 service management

PM 如果只管 feature，不管 outcome、risk、support、release、service level，很容易把「上線」誤判成「成功」。

Interview Angle

可能被問：

• What is the difference between a product and a service?
• How do you know whether a feature has delivered value?
• How would you explain utility and warranty using a production API?
• How does a managed cloud service reduce cost and risk?

回答方向：

• 用 outcome 說明，不要只講功能
• 提到 provider / consumer 的共同責任
• 把 utility 和 warranty 分開
• 用 incident、release、support、monitoring 補足 service 視角

Exam Tips

考題通常會把「功能」、「結果」、「成本」、「風險」混在一起。看到題目時先判斷它問的是哪一層。

快速判斷：

• 問「使用者想完成什麼」：多半是 outcome / value
• 問「功能是否適合用途」：多半是 utility
• 問「是否穩定、可用、安全、容量足夠」：多半是 warranty
• 問「誰一起創造價值」：provider、consumer、stakeholders
• 問「如何降低使用者負擔」：cost / risk reduction

不要被「我們已經上線功能」騙到。ITIL 更常問的是：這個功能是否真的幫助 consumer 達成 outcome，並且以可接受的 cost 和 risk 創造 value。

Summary

Digital product and service management 的重點不是把 product 和 service 做字典式區分，而是理解它們如何一起創造 value。Product 提供能力，service 幫 consumer 達成 outcome；value 取決於 outcome、cost、risk、experience 和 sustainability。對 Technical PM 來說，這章的核心練習是：不要只問功能做完沒，要問 service 是否真的能被可靠使用。

References

• PeopleCert - ITIL Foundation (Version 5)
• ITIL - ITIL Foundation (Version 5)

Quiz

請見 Chapter 02 Quiz。