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。