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。