Chapter 07 - Product and Service Lifecycle

本章目標

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

• ITIL Product and Service Lifecycle 是什麼？
• Discover、Design、Acquire、Build、Transition、Operate、Deliver、Support 各自代表什麼？
• 為什麼 lifecycle 不是 waterfall，也不是「上線就結束」？
• PM 如何把 lifecycle 對應到需求、開發、release、營運、support、改善？
• 考試遇到 lifecycle activity 題目時怎麼判斷？

Key Terms

• Product and Service Lifecycle：管理 digital product / service 從探索、設計、建置、上線、營運到支援的活動模型。
• Discover：理解 opportunity、demand、stakeholder、problem、outcome 和現況。
• Design：設計 product / service 如何創造 value，包含流程、資料、權限、體驗和支援方式。
• Acquire：取得需要的資源、技術、資料、工具、partner 或 supplier。
• Build：建立或修改 product / service capability，不只包含寫程式。
• Transition：把新能力安全移到可使用狀態，包含 change、release、deployment、training、rollback readiness。
• Operate：日常運行 product / service，確保持續可用、穩定、安全。
• Deliver：讓 consumer 真正取得 service value，而不只是功能已部署。
• Support：使用中遇到問題時提供協助，並把 feedback 帶回改善循環。

Related: Chapter 04 的 value chain activities 在 V5 會更常用 lifecycle 語言理解。Chapter 06 的 Four Dimensions 可以用來檢查每個 lifecycle activity 是否只看了單一面向。

一句話

Product and Service Lifecycle 描述 digital product / service 從探索需求、設計方案、取得資源、建置、轉換上線、營運、交付到支援的完整活動，而且這些活動會反覆迭代，不是線性一次走完。

核心概念

Lifecycle 不是 Waterfall

ITIL V5 的 lifecycle 包含八個活動：

Discover
Design
Acquire
Build
Transition
Operate
Deliver
Support

這八個活動不是固定順序，也不是每次都從 Discover 走到 Support 才能回頭。真實產品工作會反覆迭代：

Note: 考試如果問「下一步最像哪個 lifecycle activity」，不要用時間順序死背，要看題目描述的工作本質。例如理解需求是 Discover，設計服務體驗是 Design，把新能力移到 production 是 Transition，處理使用中問題是 Support。

• incident 可能讓團隊回到 design
• support ticket 可能帶出新的 discovery
• vendor API change 可能需要 acquire / transition
• AI chatbot 錯誤率太高，可能需要重新 build knowledge base

對 PM 來說，lifecycle 最重要的是：不要把 product 當成「開發完就結束」，也不要把 service 當成「support team 的事」。

Discover

Discover 是理解 opportunity、demand、stakeholder、problem、outcome 和現況。

要問：

• 這個需求從哪裡來？
• 使用者或 stakeholder 想達成什麼 outcome？
• 現在的 pain point 是什麼？
• 有什麼資料可以證明？
• 這是 opportunity、demand、incident 後改善，還是 strategy initiative？

例子：

• 客服每週收到大量服務狀態查詢
• 客戶抱怨不知道交易是否成功
• CloudWatch 顯示週五晚間 timeout 增加

Discover 的輸出不是「我要做查詢頁」，而是「我們理解了什麼問題和 outcome」。

Design

Design 是設計 product / service 如何創造 value。

要問：

• service offering 是什麼？
• 使用者流程怎麼走？
• 資料、權限、安全、監控怎麼設計？
• support 和 incident 流程怎麼設計？
• Four Dimensions 是否都考慮？

狀態查詢例子：

• 使用者看到簡單狀態
• 客服看到詳細交易資訊
• 客戶看到 reconciliation status
• 敏感資料要遮罩
• pending 狀態要有明確說明

Design 不是只畫 UI，而是設計整個 service experience。

Acquire

Acquire 是取得需要的資源、能力、工具、技術、資料、partner 或 supplier。

例子：

• 採用 external gateway
• 購買 observability tool
• 取得 AWS support plan
• 導入 LLM provider
• 取得資料權限
• 安排外部顧問或內部 platform support

Acquire 常被忽略，但很多 service 失敗是因為需要的能力其實沒有被取得。

Build

Build 是建立或修改 product / service capability。

例子：

• React checkout page
• Java core API
• RDS schema migration
• CloudWatch dashboard
• runbook
• AI chatbot prompt / knowledge base
• 客服後台查詢功能

Build 不只包含寫程式，也包含建立文件、流程、監控、支援能力。

Transition

Transition 是把新能力安全地移到可使用狀態。

它包含：

• release planning
• change enablement
• deployment
• migration
• training
• communication
• rollback readiness

例子：新版核心 API deploy 到 production 前，需要確認：

• DB migration 是否安全？
• feature flag 是否可控？
• 客服是否知道新版錯誤碼？
• rollback plan 是否可執行？
• 監控是否已就緒？

Transition 的重點不是「按下 deploy」，而是讓 change 進入真實環境時不破壞 service value。

Operate

Operate 是日常運行 product / service，確保它持續可用、穩定、安全、符合 service level。

包含：

• monitoring
• incident response
• capacity management
• security operations
• routine maintenance
• performance tuning
• availability management

例子：

• CloudWatch alarm
• RDS performance review
• on-call response
• external gateway health check
• recurring job monitoring

Operate 是很多 PM 容易忽略的部分，但它決定 service 是否真的可靠。

Deliver

Deliver 是把 product / service value 交到 consumer 手上，讓 consumer 可以取得 outcome。

它關心：

• consumer 是否能使用 service？
• service offering 是否清楚？
• training / onboarding 是否足夠？
• service level 是否被理解？
• billing / access / entitlement 是否正常？

例子：

• 客戶知道如何查詢服務狀態
• 客服有權限使用後台
• 使用者收到清楚的服務處理結果
• 客戶營運能看到必要報表

Deliver 不是單純「功能上線」，而是 consumer 真正能使用並取得 value。

Support

Support 是在 consumer 使用 product / service 遇到問題時提供協助，並把問題回饋到改善循環。

包含：

• service desk
• knowledge articles
• FAQ
• incident communication
• user support
• escalation
• feedback capture

線上服務例子：

• 使用者問操作是否成功
• 客服查詢交易狀態
• chatbot 回答 FAQ
• 支援團隊把高頻問題回饋給 PM

Support 不是 lifecycle 的尾巴，而是下一輪 Discover / Improve 的重要來源。

PM 視角

PM 可以用 lifecycle 把「需求到營運」串起來。

以服務狀態查詢為例：

Discover:
客服 ticket 顯示服務狀態查詢量高

Design:
設計使用者、客服、客戶看到的不同狀態與權限

Acquire:
取得 external gateway status API、資料權限、AWS logging access

Build:
開發查詢頁、API、DB mapping、dashboard、runbook

Transition:
灰度上線、客服訓練、release note、rollback plan

Operate:
監控 API error rate、gateway delay、查詢成功率

Deliver:
讓客服與客戶真的能使用查詢功能

Support:
處理查不到、狀態不一致、權限不足等問題，回饋到 backlog

這就是為什麼 PM 不能只管 backlog。PM 要知道功能如何進入 service lifecycle，最後才會變成 value。

Developer / DevOps 視角

Developer / DevOps 可以用 lifecycle 重新理解 release。

React + Java release 例子：

Discover:
使用者操作失敗後不知道下一步

Design:
設計 frontend message、backend error code、support mapping

Acquire:
取得 gateway 錯誤碼文件和 monitoring access

Build:
React error state、Java API mapping、CloudWatch metric

Transition:
PR review、CI、deployment、feature flag、rollback

Operate:
監控 error rate、latency、conversion impact

Deliver:
使用者看到清楚狀態，客服能查詢

Support:
客服 FAQ、incident escalation、feedback item

如果工程只做到 Build + Transition，可能還是沒有完整 service value。

AWS 對照

以「讓核心服務更穩定」為例：

Discover:
分析 CloudWatch、ALB logs、RDS Performance Insights、support tickets

Design:
設計 timeout、retry、idempotency、queue、observability、rollback

Acquire:
取得 AWS support plan、必要服務權限、observability tool

Build:
建立 dashboard、alarm、queue、API changes、runbook

Transition:
灰度 deploy、DB migration、feature flag、rollback rehearsal

Operate:
on-call、monitoring、capacity review、incident response

Deliver:
核心服務穩定支援使用者與客戶交易

Support:
客服處理服務問題，ticket trend 進入 improvement backlog

AWS 工具會出現在多個 lifecycle activities 裡。CloudWatch 不只是 Operate；它也支援 Discover、Transition、Support 和 Improve。

實務對照

團隊導入 AI chatbot 可以用 lifecycle 防止「做出 demo 但無法營運」。

Discover:
找出高頻服務問題、客服成本、使用者痛點

Design:
設計 chatbot 回答範圍、轉人工規則、資料權限、錯誤處理

Acquire:
選擇 LLM provider、取得資料存取權、確認法務資安要求

Build:
建立 knowledge base、prompt、API integration、客服 handoff

Transition:
先小流量試行、客服訓練、監控錯誤回答、建立 rollback

Operate:
監控 resolution rate、handoff rate、錯誤率、latency、cost

Deliver:
讓使用者真的能透過 chatbot 解決服務問題

Support:
無法回答時轉人工，並把問題回饋到 knowledge base 改善

如果只做到 Build，就會變成「demo 很漂亮」。Lifecycle 要求你把它變成可營運、可支援、可改善的 service。

常見誤解

誤解 1：Lifecycle 是固定順序

不是。八個活動可以迭代、並行、反覆。Support feedback 可能回到 Discover，incident 可能回到 Design。

誤解 2：Build 就是開發，Transition 就是 deploy

Build 可以包含 runbook、dashboard、knowledge base。Transition 也不只是 deploy，還包含 training、communication、migration、change risk。

誤解 3：Deliver 和 Support 是客服部門的事

Deliver 和 Support 都影響 product / service value。PM、engineering、operations、CS 都需要一起設計。

誤解 4：上線後 lifecycle 就結束

上線只是 Transition 的一部分。Operate、Deliver、Support 和 feedback 才決定 value 是否持續。

Interview Angle

可能被問：

• What are the ITIL Product and Service Lifecycle activities?
• How is lifecycle thinking different from waterfall?
• How would you map a production release to the lifecycle?
• How would you use lifecycle thinking for an AI chatbot?

回答方向：

• 先列八個活動
• 強調 non-linear / iterative
• 用真實 service 例子，不要只背清單
• 說明 Build / Transition / Operate / Support 的差異

Exam Tips

Lifecycle 題目常問「某個情境屬於哪個 activity」。

速查表：

題目線索	最可能的 activity
研究需求、痛點、opportunity、stakeholders	Discover
設計流程、service offering、architecture、experience	Design
取得工具、資源、vendor、資料權限	Acquire
開發功能、建立能力、文件、runbook	Build
release、deployment、migration、training、change risk	Transition
monitoring、on-call、maintenance、availability	Operate
consumer 實際取得 service value、onboarding、access	Deliver
service desk、FAQ、incident communication、escalation	Support

考試陷阱：

• 把 Transition 當成只有 deployment
• 把 Support 當成 lifecycle 結束，而不是 feedback 來源
• 把 Build 當成只寫 code
• 把 lifecycle 當成固定 waterfall

Summary

ITIL Product and Service Lifecycle 是 V5 的核心更新之一。它用 Discover、Design、Acquire、Build、Transition、Operate、Deliver、Support 八個活動，描述 digital product / service 如何從需求、設計、建置、上線、營運、交付到支援持續創造 value。對 Technical PM 來說，這章最重要的練習是：不要把「功能完成」當成終點，而要確認整個 lifecycle 都能支援 consumer outcome。

References

• PeopleCert - ITIL Foundation (Version 5)
• ITIL - ITIL Foundation (Version 5)
• ITIL - Foundation Version 5 What's New

Quiz

請見 Chapter 07 Quiz。