Chapter 03 - Value Co-Creation
本章目標
看完本章後,你應該可以回答:
- 為什麼 value 不是 provider 單方面交付?
- provider、consumer、客戶、user、stakeholder 的差異是什麼?
- outcome、cost、risk、experience、sustainability 如何一起影響 value?
- PM 如何判斷一個功能是真的創造 value,還是只是完成 delivery?
- 考試遇到 value co-creation 題目時應該怎麼選?
一句話
Value 不是「我交付功能」就自動產生,而是 provider、consumer 和其他 stakeholders 透過合作,讓 outcome 在可接受的 cost、risk 和 experience 下被實現。
核心概念
Value Co-Creation
Value co-creation 的重點是:provider 不能單方面宣告 value 已經完成。Provider 可以提供 product、service、support、knowledge、automation 和 governance,但 value 只有在 consumer 真的達成 outcome 時才成立。
線上服務例子:
Provider: product / engineering / operations team
Consumer: 使用服務流程的客戶、使用者、客服、營運
Service: 操作、查詢、資料修正請求、異常處理
Outcome: 使用者完成主要操作,客戶確認處理結果,客服能處理問題
Value: 成交率提升、信任提高、人工處理成本下降如果團隊只上線 API,但客戶不會串、客服查不到狀態、使用者遇到錯誤不知道怎麼辦,value 就沒有完整被共同創造出來。
Provider
Provider 是提供 product 或 service 的一方。它可能是外部供應商,也可能是公司內部團隊。
例子:
- AWS 對使用 RDS 的團隊來說是 provider
- platform team 對客戶後台使用者來說是 provider
- Backend team 對 frontend / mobile team 來說可能是 internal provider
Provider 的責任不是只交付技術元件,而是讓 consumer 能透過 service 達成 outcome。
Consumer
Consumer 是使用、要求、付費或受 service 影響的一方。它可以再拆成 客戶、user、sponsor 等角色。
例子:
- Customer:決定購買或採用 service 的人
- User:實際使用 service 的人
- Sponsor:提供預算或支持的人
在內部產品裡,角色常常混在一起。PM 要小心不要只聽 sponsor,而忽略每天真正使用系統的 user。
Stakeholder
Stakeholder 是會影響 service,或被 service 影響的人或組織。它不一定直接使用 product。
線上服務場景裡的 stakeholders 可能包含:
- 使用者
- 客戶
- 客服
- 營運
- 財務
- 法務
- 資安
- external gateway vendor
- on-call engineer
- product owner
Value co-creation 需要看整個 stakeholder ecosystem,不是只看單一使用者。
Service Relationship
Service relationship 是 provider 和 consumer 之間為了共同創造 value 形成的關係。它不只是合約,也包含溝通、支援、使用方式、回饋、責任分工和改善機制。
AWS 的例子:
AWS provides RDS capability
Customer configures schema, access, backup policy, monitoring use
Both sides influence database service value如果 客戶 把 production database 開成 public access,不能說「AWS 沒有創造 value」。這是 service relationship 裡 responsibility 沒有被正確管理。
Experience and Sustainability
Value 不只看 outcome,也看 experience 和 sustainability。
同樣是「完成主要操作」:
- 如果使用者要重試 5 次才成功,experience 很差
- 如果客服要查 4 個系統才確認狀態,operation cost 很高
- 如果每次 release 都靠英雄式救火,team sustainability 很差
- 如果 AI chatbot 回答很快但經常誤導使用者,trust 和 risk 都有問題
所以 value co-creation 不是短期交付,而是長期可持續地共同創造結果。
PM 視角
PM 的工作不是把需求丟給工程師,也不是把功能上線就收工。PM 在 value co-creation 裡要做的是把不同 stakeholder 的 outcome、cost、risk 和 experience 對齊。
一個核心功能至少要問:
- 使用者的 outcome 是什麼?
- 客戶的 outcome 是什麼?
- 客服需要什麼資訊才能支援?
- 財務需要什麼資料才能對帳?
- 工程團隊能不能穩定維護?
- 發生 incident 時誰要知道、誰要處理、誰要對外溝通?
這些不是「PM 多管閒事」。這些是確保功能變成 service value 的必要工作。
Developer / DevOps 視角
Developer 和 DevOps 在 value co-creation 中不是單純的 build team。
例子:React checkout release
Frontend team builds checkout UI
Backend team exposes core API
DevOps maintains deployment and rollback
QA validates critical flow
CS team handles user issue
PM aligns scope and launch risk
Users complete the main operation
Merchants receive moneyValue 是整條鏈一起創造的。任何一段斷掉,最後的 service value 都會下降。
工程上常見的盲點是只看「我的 component 有沒有完成」:
- frontend merged 了,但 backend error message 無法被 user 理解
- backend API 可用,但 support team 沒有查詢工具
- pipeline deploy 成功,但沒有 business metric 看成功率
- alert 有發,但沒有 runbook
從 ITIL 的角度,這些都是 value co-creation 的斷點。
AWS 對照
AWS 的 shared responsibility 很適合理解 value co-creation。
以 RDS 為例:
- AWS 提供 managed database capability
- Customer 選擇 instance、schema、backup、network、access control
- Application team 設計 query、connection pool、retry
- DevOps 設定 monitoring 和 alarm
- Security team 管理權限與資料保護
- Business team 定義可接受的 outage impact
RDS 的 value 不是 AWS 單方面交付,也不是 客戶 單方面完成。它是 provider 和 consumer 在明確責任分工下共同創造。
實務對照
假設 團隊要導入 AI chatbot 處理服務問題。
表面上的 delivery:
- chatbot 上線
- 可以回答服務狀態
- 可以查詢 FAQ
Value co-creation 要看更深:
- 使用者是否真的更快解決問題?
- chatbot 不能處理時是否能順利轉客服?
- 客服是否看得到 chatbot 對話紀錄?
- chatbot 回答錯誤時誰負責修正 knowledge base?
- 法務或資安是否確認可暴露的資料範圍?
- PM 是否追蹤 deflection rate、resolution rate、CSAT、錯誤率?
如果 chatbot 只是 demo 很漂亮,但讓使用者更困惑,甚至提供錯誤服務資訊,它不但沒有創造 value,還增加 risk。
常見誤解
誤解 1:Provider 可以單方面交付 value
Provider 可以交付 product 或 service capability,但 value 需要 consumer 使用、回饋、配合,並在真實情境中達成 outcome。
誤解 2:只要 客戶 滿意,其他 stakeholder 不重要
短期 客戶 滿意不代表整體 value 成立。如果客服成本暴增、工程團隊不可持續、資安風險升高,value 可能只是被轉嫁成本。
誤解 3:Value co-creation 就是多開會
Co-creation 不是會議數量,而是責任、回饋、資訊、支援、改善是否讓 outcome 更容易被達成。
誤解 4:AI 自動化越多,value 越高
AI 能提升速度,但如果錯誤率、信任、風險、治理沒有管理好,自動化可能降低 value。
Interview Angle
可能被問:
- What does value co-creation mean in ITIL?
- How do you identify stakeholders for a digital service?
- How do you make sure a new feature actually creates value?
- How would you evaluate an AI chatbot from a service management perspective?
回答方向:
- 不要說「value is delivered by provider」就結束
- 要提 provider、consumer、stakeholders
- 要提 outcome、cost、risk、experience
- 最好用 production feature、cloud service 或 support workflow 當例子
Exam Tips
考 value co-creation 時,題目常會設計成「某團隊已經交付功能,但使用者還是沒有得到想要的結果」。
看到以下線索要敏感:
- 多個角色需要協作
- 使用者 outcome 沒達成
- 成本或風險被轉嫁給 consumer
- stakeholder 沒有被納入
- feedback 沒有進入改善循環
- AI / automation 上線但 experience 變差
答題原則:
- 優先選能促進 collaboration、visibility、feedback、shared understanding 的選項
- 避免選「provider 自己決定就好」的選項
- 避免只看工具或流程,忽略 outcome
Summary
Value co-creation 是 ITIL 的核心思維:value 不是 provider 單方面交付,而是在 provider、consumer 和 stakeholders 的 service relationship 中共同形成。對 Technical PM 來說,這章的關鍵是把「功能上線」改成「stakeholders 是否真的一起達成 outcome,並且 cost、risk、experience、sustainability 都可接受」。
References
Quiz
請見 Chapter 03 Quiz。