AI 扩展计划 / Playbooks

AI Product Portfolio Rationalization / Capability Decommission Playbook

版本: v1.0

902 行AI_PRODUCT_PORTFOLIO_RATIONALIZATION_CAPABILITY_DECOMMISSION_PLAYBOOK.md

AI Product Portfolio Rationalization / Capability Decommission Architecture Playbook

版本: v1.0 日期: 2026-06-30 适用对象: CBAP、Senior BA、AI PM、Product Portfolio Lead、Business Architect、Enterprise Architect、Solution Architect、AI Platform PM、FinOps、Operations、Records、Legal、Compliance、Risk、Internal Audit、金融零售转型负责人

定位: 把 AI product portfolio rationalization、capability decommission、application portfolio management、feature/API/model sunset、vendor exit、records/legal-hold control、customer migration 和 architecture governance 统一成一套可执行的金融零售高级手册。

重要说明: 本文是学习、作品集和内部架构训练材料, 不是法律意见、合规结论、监管解释、客户通知模板、记录保留意见或诉讼保全建议。正式项目必须由 Legal、Compliance、Privacy、Records Management、Risk、Security、Model Risk、Operations、Business Owner、Procurement、Internal Audit 和相应管理层按机构类型、产品、司法辖区、客户群、合同、监管关系和事实场景确认。

1. Executive Framing

AI 降低了新增产品能力的门槛, 也提高了组合失控的速度。一个金融零售企业可能在一年内同时出现:

多个业务线各自建设客服 copilot。
多个团队各自做 RAG 知识库和 embedding。
同一 capability 由旧核心系统、新 SaaS、low-code workflow 和 AI agent 同时提供。
多套 prompt、模型、工具权限、日志和 eval 证据并存。
供应商模型、插件、向量库和 workflow 平台产生新的锁定。
旧功能、旧 API 和旧模型没有退出路径, 导致运营、审计、客服、培训和合规复杂度持续上升。

本 playbook 的核心判断:

Portfolio rationalization is not cost cutting.
It is capability architecture, risk governance and capacity reallocation.

中文表达:

组合瘦身不是砍功能, 而是把企业能力放回正确的位置, 让客户价值、风险控制、架构简化和组织容量重新对齐。

1.1 成熟能力要回答的问题

Question	Mature answer
企业到底有多少重复 capability	capability map + product/application/API/model dependency graph
哪些能力值得保留、合并、迁移或下线	risk-adjusted value and migration feasibility scorecard
AI 如何帮助识别重复和低价值能力	usage/cost/risk mining, semantic clustering, impact analysis, sunset draft
谁能决定关闭客户可见能力	portfolio governance forum, accountable executives and required control partners
legal hold / records 如何处理	no disposal or evidence deletion before authorized review and hold check
API / feature / model 如何 sunset	version policy, consumer inventory, migration cohort, deprecation evidence
客户如何迁移	cohort design, alternative path, communication approval, support readiness
下线后如何证明做对了	decommission certificate, evidence binder, benefit realization and risk monitoring

2. Source Anchors

以下官方来源作为控制语言和架构证据锚点。它们不自动产生任何机构特定的法律、合规或审计结论。

Anchor	Official source	本 playbook 使用方式
FFIEC Management IT Handbook	https://ithandbook.ffiec.gov/it-booklets/management.aspx	用 governance、enterprise architecture、IT responsibilities、planning IT operations and investment、risk identification、metrics、SLAs、control effectiveness 和 reporting 组织组合治理
FFIEC Architecture, Infrastructure, and Operations IT Handbook	https://ithandbook.ffiec.gov/it-booklets/architecture-infrastructure-and-operations/	用 AIO governance、asset inventory、data classification、data flow diagrams、business process narratives、change、resilience、capacity、log management、monitoring 和 continuous improvement 设计 decommission evidence
FFIEC Development, Acquisition, and Maintenance IT Handbook	https://ithandbook.ffiec.gov/it-booklets/development-acquisition-and-maintenance/	用 SDLC、quality、documentation、impact analysis、rollback/back-out plan、end-of-life、termination and disposal、exit strategy、third-party and supply chain risk 设计 lifecycle sunset
FFIEC Business Continuity Management IT Handbook	https://ithandbook.ffiec.gov/it-booklets/business-continuity-management.aspx	用 BIA、critical business functions、interdependency analysis、continuity strategies、communications、exercises/tests 和 board reporting 管理迁移和下线期间的韧性
NIST SP 800-160 Vol. 1 Rev. 1	https://csrc.nist.gov/pubs/sp/800/160/v1/r1/final	用 systems security engineering、trustworthiness、stakeholder requirements、life cycle、assurance、validation and verification 管理系统级可信停用
NIST AI RMF	https://www.nist.gov/itl/ai-risk-management-framework	用 Govern / Map / Measure / Manage 组织 AI use case、model/tool/vendor dependency、impact、measurement、monitoring 和 risk treatment
ISO/IEC 42001	https://www.iso.org/standard/81230.html	用 AI management system 的 policy、objectives、risk/opportunity、operation、performance evaluation、improvement 和 lifecycle governance 设计 AI capability 管理体系
Wardley Mapping / Team Topologies	Non-official conceptual context	仅作为 capability evolution、commoditization、team boundary、platform ownership 的思维工具, 不作为监管或合规依据

3. Scope: Rationalization Objects

本 playbook 处理的不是单一系统退役, 而是跨产品、能力、应用、接口、模型和供应商的组合治理。

Object	Included examples	Typical owner
Product / product line	账户服务、信用卡权益、贷款申请、客服渠道、商户工具	Product executive / GM
Business capability	onboarding、KYC、case triage、dispute resolution、policy retrieval、offer decisioning	Business architect / capability owner
Application	core workflow、case system、portal、mobile module、analytics dashboard	Application owner
Feature	AI summary、document upload、legacy report、manual export、old journey step	Product owner
API / event / batch	public API、partner API、internal service endpoint、event topic、file feed	API owner / platform owner
AI model	LLM、embedding model、classifier、ranking model、fraud model、OCR model	Model owner / AI platform
Prompt / policy / eval	system prompt、policy pack、rubric、golden set、judge prompt	AI product / model risk / domain owner
RAG / knowledge asset	vector index、source document set、taxonomy、ontology、retrieval pipeline	Knowledge owner / data owner
Agent tool	CRM update、payment action、case note write、email send、ticket close	Tool owner / process owner
Vendor / SaaS	model provider、RAG platform、workflow SaaS、observability、annotation vendor	Procurement / TPRM / platform

Out of scope:

单纯预算裁剪, 没有客户、风险、架构和迁移证据。
法律或合规结论自动化。
仅通过 AI 生成关闭名单并执行。
绕过 product owner、architecture、risk、legal、records、operations 的客户影响决策。

4. Operating Principles

Principle	Practical meaning
Capability first	先看业务能力和客户任务, 再看应用和功能
Evidence before opinion	先收集 usage、value、cost、risk、dependency、records 和 migration evidence
AI assists, humans decide	AI 挖信号、聚类、草拟计划, 人类负责客户影响、风险接受和停用决策
Launch includes exit	新能力上线不算完成, 旧能力退出和容量释放也要纳入成功标准
No silent shutdown	客户、API consumer、运营和支持团队不能被突然切断
Records before disposal	数据、日志、模型证据、客户沟通和 vendor records 在删除前必须通过 retention/hold review
Critical controls may look low usage	低使用不等于低价值, 控制能力和韧性能力需要单独判断
Target architecture wins	合并不是把旧系统拼在一起, 而是迁移到明确 target capability
Measure after shutdown	下线后必须复盘客户影响、成本释放、风险变化和容量重分配

5. End-to-End Lifecycle

Trigger
  -> Inventory and evidence collection
  -> AI-assisted signal mining and clustering
  -> Dependency graph and impact analysis
  -> Rationalization scorecard
  -> Governance decision
  -> Migration and sunset design
  -> Customer / API / operations communication
  -> Controlled decommission execution
  -> Evidence binder and certificate
  -> Benefits, risk and capacity realization review

5.1 Trigger Types

Trigger	Examples	Required response
Strategic simplification	too many products, inconsistent journeys, platform consolidation	capability rationalization review
Cost pressure	token cost spike, SaaS renewal, support burden, low margin	cost-to-serve and unit economics analysis
Risk event	incident, complaint spike, model failure, control issue	risk-weighted shutdown or restriction review
Architecture debt	duplicate data, old API, EOL component, brittle integration	target architecture migration plan
Vendor change	model deprecation, price increase, contract concern, service degradation	vendor exit or replacement assessment
Regulatory / audit attention	weak records, poor evidence, unclear ownership	evidence and control remediation
New platform capability	shared RAG, model gateway, common case assistant	merge and legacy exit plan

5.2 Stage Gates

Gate	Decision	Minimum evidence
Intake	Is this rationalization candidate worth analysis?	trigger, owner, impacted domain, initial hypothesis
Evidence readiness	Is there enough data to score?	inventory, usage, cost, risk, dependency, constraints
Decision	Keep, invest, merge, migrate, freeze, sunset, archive, replace	scorecard, target architecture, residual risk
Migration readiness	Can customers/systems move safely?	cohort plan, test, rollback, communication, support
Decommission readiness	Can old object be disabled or removed?	dependency clear, records/hold review, approvals, runbook
Closure	Was the decommission completed and measured?	certificate, evidence binder, post-review metrics

6. Inventory Design

6.1 Product / Capability Inventory Fields

Field	Definition	Evidence source
product_name	客户或员工看到的产品/服务	product catalog
capability_id	business capability map 中的能力节点	capability model
owner	accountable product/business owner	RACI
customer_segment	affected segment, channel, geography, product type	CRM / segmentation
job_to_be_done	task or outcome served	research / journey map
value_metric	revenue, risk reduction, time saved, complaint reduction, conversion	metric catalog
usage_metric	active users, transaction volume, API calls, model calls, case count	telemetry
cost_to_serve	infra, vendor, model, operations, support, controls, records	FinOps / ops
risk_tier	customer, financial, compliance, privacy, security, operational risk	risk assessment
replacement_capability	target product/capability or no replacement	target architecture
migration_complexity	customer, data, integration, contract, training, records	impact analysis

6.2 Application Portfolio Fields

Field	Definition
app_id / app_name	system of record, system of engagement, workflow, analytics, AI service
supported_capabilities	mapped capability IDs
business_criticality	critical, important, supporting, convenience
lifecycle_status	strategic, tolerate, migrate, contain, retire
technology_health	version, EOL, patch posture, maintainability, test coverage
operational_health	incidents, availability, performance, support burden
integration_count	APIs, events, files, manual workarounds
data_and_records	data owner, retention, legal hold, archive, deletion constraints
AI_dependencies	model, prompt, RAG, tool, vendor, eval, trace
decommission_blockers	dependencies, contracts, records, missing replacement, customer exceptions

6.3 AI Asset Registry Fields

AI asset	Required registry fields
Model	model_id, provider, version, route, business use, risk tier, eval status, cost, fallback, EOL
Prompt	prompt_id, version, owner, policy boundary, linked eval, consumer apps, status
Eval set	dataset, source, coverage, rubric, owner, recency, release gate
RAG index	source systems, document owners, ACL, embedding model, refresh cadence, retention
Tool	tool name, action type, side effect, permission model, approval, audit log
Agent workflow	state machine, authority level, human handoff, rollback, incident trigger
Vendor	service, contract term, data rights, change notice, exit rights, deletion evidence

7. Dependency Graph Model

Rationalization 的核心资产是 dependency graph, 不是静态清单。

7.1 Nodes

CustomerSegment
Product
Capability
JourneyStep
Feature
API
Application
DataStore
RecordClass
Model
Prompt
RAGIndex
Tool
Vendor
Control
Team
Contract
LegalHold
Metric

7.2 Edges

Edge	Meaning
Product provides Capability	产品提供某业务能力
Feature supports JourneyStep	功能支撑旅程步骤
Feature calls API	功能依赖接口
API served_by Application	接口由应用提供
Application reads/writes DataStore	应用数据依赖
Model used_by Feature	模型服务某功能
Prompt configures Model	prompt 影响模型行为
RAGIndex grounded_in DataStore	检索索引来自数据/文档
Tool performs Action	agent 工具执行操作
Vendor supplies Model/Tool/App	第三方供应能力
RecordClass retained_in DataStore	记录保留位置
LegalHold applies_to RecordClass	保全约束
Control monitors Asset	控制覆盖资产
Team owns Asset	owner 关系

7.3 High-Value Queries

Query	Why it matters
哪些 products 提供同一 capability?	识别重复能力
哪些 features 使用同一模型但证据不同?	识别模型治理不一致
哪些 API consumer 仍调用旧版本?	判断 API sunset readiness
哪些 customer cohorts 无替代路径?	迁移分层和沟通
哪些 tools 有 write side effect?	防止 agent 下线或迁移造成业务状态不一致
哪些 records or holds 与目标资产相关?	防止证据删除或迁移违反约束
哪些 vendors 同时支撑多个 critical capabilities?	集中度和退出风险
下线某应用会释放哪些团队 capacity?	capacity reallocation

8. AI-Assisted Signal Mining

AI 的价值在于把分散证据变成可审查的候选项, 而不是替代治理。

8.1 Signal Sources

Signal	Source	AI use
Usage	web/app telemetry, feature flags, API gateway, event logs	detect low usage, cohort patterns, seasonality
Cost	cloud billing, token cost, vendor invoices, support time	allocate cost-to-serve by product/capability
Risk	incidents, complaints, QA defects, audit issues, model eval failures	cluster recurring failure modes
Process	BPMN, SOPs, case logs, process mining	identify duplicated workflow steps
Architecture	CMDB, service catalog, code search, API specs, lineage	build dependency graph and stale integration view
Customer	feedback, call transcripts, NPS comments, support tickets	map pain points and migration friction
Contract	vendor agreements, renewal dates, exit clauses, notices	identify exit windows and obligations for review
Records	retention schedules, hold registers, archive locations	flag disposal constraints for authorized review

8.2 AI Outputs

AI output	Human review question
Duplicate capability cluster	Are these truly same customer/business outcomes or only semantically similar?
Low-value candidate list	Does low usage hide critical control, VIP, regulatory or seasonal value?
Cost anomaly	Is cost avoidable, allocatable and tied to a rationalization decision?
Risk cluster	Does this justify restriction, redesign, migration or full sunset?
Migration cohort proposal	Are vulnerable customers, contract commitments and operational exceptions handled?
Draft sunset plan	Are dates, owner, notice, support, rollback and evidence feasible?
Impact analysis	Did the graph miss manual processes, reports, controls or vendors?

8.3 AI Boundary Control

Control	Requirement
Decision authority	AI output is recommendation evidence only
Traceability	AI-generated clusters and plans link back to source data
Human sign-off	product, architecture, operations, risk, legal/records as applicable
Bias and blind spots	check long-tail customers, accessibility, vulnerable customers, low-volume controls
Data minimization	sensitive customer data is not overexposed during analysis
Prompt/version retention	AI analysis prompts and outputs are retained according to evidence policy

9. Rationalization Scorecard

9.1 Scoring Dimensions

Use 1-5 scoring, with written evidence for each dimension. Weighting should be approved by the portfolio governance forum.

Dimension	1 score	5 score
Customer value	unclear or negative value	clear, measured, customer-critical value
Strategic fit	peripheral or obsolete	directly supports target strategy/capability
Profitability / economic value	negative margin, no risk benefit	strong margin or measurable risk/cost reduction
Cost-to-serve	high and rising	efficient or strategically justified
Operational risk	high incident/control burden	stable, controlled, resilient
Architecture fit	duplicate, brittle, off-target	target architecture, reusable, observable
AI dependency health	opaque, high cost, weak eval	governed, evaluated, portable, monitored
Vendor / concentration risk	locked-in, poor exit	acceptable concentration, exit-ready
Records / legal-hold complexity	unresolved constraints	reviewed and manageable
Migration feasibility	no safe path	tested, low-risk migration path

9.2 Decision Bands

Pattern	Decision	Notes
High value + good architecture	Keep / invest	fund scale and migration from weaker duplicates
High value + high architecture debt	Rebuild / platformize	do not sunset value, reduce debt
Medium value + overlap + high cost	Merge / migrate	target capability and decommission duplicate
Low value + low risk + migration ready	Sunset	execute controlled decommission
Low value + unresolved records/hold	Freeze execution pending review	no disposal until authorized review
High risk + value unproven	Restrict / stop / redesign	protect customers and operations
Vendor EOL + replacement exists	Replace / exit	follow contract and evidence controls
Critical control + low usage	Retain as control	classify as control capability, not normal product feature

10. Decision Types

Decision	When to use	Key controls
Keep	Unique value, acceptable economics, acceptable risk	owner, metrics, roadmap, controls
Invest	Strategic capability needs scale	funding, target architecture, capacity
Merge	Duplicate capabilities can move to one target	migration cohorts, data/API mapping, communication
Migrate	Old product/app/API/model replaced by target	parallel run, rollback, evidence
Freeze	Stop new customers or new usage while existing runs	feature flags, sales/channel controls
Restrict	Reduce scope because risk or cost too high	cohort limits, permissions, manual approval
Sunset	Planned feature/API/model/product retirement	notice, migration, cutoff, support
Archive	Preserve read-only evidence without active operation	records retention, access controls
Replace vendor	Vendor risk, EOL, cost or capability issue	exit plan, data return, deletion, transition
Retain as control	Low usage but high control/continuity value	control owner, test, evidence

11. Migration Architecture

11.1 Migration Patterns

Pattern	Use case	Risk
Hard cutover	Low usage, internal-only, no critical dependency	operational surprise if inventory incomplete
Parallel run	API/model/workflow replacement needs comparison	cost and data reconciliation
Cohort migration	customer-facing capability with different risk groups	exception handling complexity
Adapter bridge	old API consumers need time	bridge becomes permanent debt
Read-only archive	old app no longer active but evidence required	access and retention governance
Dual model route	model replacement with eval comparison	inconsistent outputs during transition
Shadow mode	AI/model/tool candidate tested without customer impact	false confidence if traffic not representative

11.2 Migration Cohort Design

Cohort	Recommended handling
Internal power users	early pilot, feedback loop, training
Low-risk active customers	first live migration with support monitoring
High-value customers	account-team assisted migration
Vulnerable or accessibility-sensitive customers	enhanced communication and alternate channel
Contracted enterprise / partner API users	formal notice, test window, certification
Dormant customers	notification and sunset with reactivation path
Legal-hold / investigation-related records	no disposal or migration deletion without authorized review
High-risk AI workflow users	shadow, dual control, manual approval

11.3 Back-Out Plan

Every migration must define:

Element	Required detail
Trigger	metric or incident that stops migration
Owner	named business and technical owner
Time window	when rollback can occur safely
Data reconciliation	how to reconcile state changes
Customer handling	message, support script, exception path
Evidence	rollback decision log and post-incident review

12. Feature Sunset Controls

Phase	Controls
Announce internally	owner, rationale, impacted users, support readiness
Freeze new entry	disable new enrollment, hide new purchase/configuration path
In-product notice	approved message, alternative, date, support channel
Usage monitoring	active users, failed attempts, workaround usage, complaints
Migration support	wizard, bulk migration, assisted service, training
Final cutoff	feature flag off, route disabled, access blocked except approved exception
Archive	retain evidence, configuration, communications and decision trail
Post-review	confirm cost, risk, complaint and capacity outcomes

13. API Sunset Controls

Control	Requirement
Version policy	define support window, deprecation status and cutoff date
Consumer inventory	identify internal apps, partners, batch jobs, reports and unknown consumers
Deprecation telemetry	track calls by client, endpoint, method, error and business process
Contract tests	ensure target API supports required behavior
Deprecation headers	machine-readable notice where appropriate
Developer communication	changelog, migration guide, test environment, support channel
Parallel operation	old and new version operate until readiness threshold
Rate and access control	progressive restriction after notice window
Final disablement	revoke route, keys or version with rollback path
Evidence	consumer sign-off, test results, final traffic proof

14. Model / Prompt / RAG / Tool Sunset Controls

14.1 Model Sunset

Step	Evidence
Identify model consumers	model gateway route inventory
Compare replacement	eval result, latency, cost, safety, refusal, citation quality
Shadow or dual run	output comparison and defect review
Update model card / system card	version, limitations, approved use
Freeze old route	route config and approval
Retain evidence	old model usage, eval, decision, incidents
Disable old route	gateway policy, monitoring proof

14.2 Prompt Sunset

Step	Evidence
Mark prompt as deprecated	prompt registry status
Link replacement prompt	version diff and owner
Run regression eval	golden set and negative cases
Block new deployments	CI/CD or registry gate
Archive old prompt	content, metadata, approval, effective dates

14.3 RAG Index Sunset

Step	Evidence
Map source documents	document owner, retention, ACL
Build target index	source lineage, embedding model, chunking, refresh
Compare retrieval	citation precision, permission filter, stale-source rate
Freeze old ingestion	pipeline config
Migrate consumers	route and feature mapping
Dispose or archive	records/hold review, deletion or retention proof

14.4 Tool / Connector Sunset

Step	Evidence
Identify side effects	write actions, external communication, financial action
Reconcile state	pending tasks, retries, idempotency keys
Revoke permissions	IAM and tool broker records
Replace workflow	target tool or manual process
Retain audit logs	tool call history and approval evidence
Disable connector	config, monitoring, final zero-traffic proof

15. Vendor Exit and Dependency Reduction

AI product rationalization often exposes vendor concentration.

Vendor concern	Rationalization response
Model provider price increase	route optimization, smaller model, alternative provider, use-case restriction
RAG SaaS lock-in	export index metadata, rebuild ingestion, standardize chunk/source schema
Workflow vendor EOL	process migration, API replacement, archive evidence
Observability vendor gap	normalize trace schema before exit
Annotation vendor quality issue	export labels, reviewer calibration evidence, replacement process
Contract lacks exit support	escalate before renewal, reduce dependency, negotiate transition support

Exit evidence:

contract notice and approval。
export manifest。
data return package。
deletion confirmation where applicable。
access revocation。
replacement validation。
residual risk memo。
final vendor dependency graph update。

16. Customer Communications

Customer communications are part of architecture execution because they affect adoption, support load, complaints and risk.

16.1 Communication Matrix

Audience	Message focus	Evidence
Retail customers	what changes, when, alternative, support	approved notice, send log, complaint monitor
SMB / commercial customers	migration steps, admin action, API or file changes	account outreach, confirmation
Internal employees	new workflow, support scripts, exception handling	training completion, readiness checklist
Partners / developers	API version, sandbox, cutoff, test evidence	developer notice, certification
Operations / support	scripts, escalation, manual fallback	runbook, QA sampling
Regulators / auditors if applicable	evidence and decision trail through authorized channels	exam/audit response binder

16.2 Message Requirements

Requirement	Meaning
Specific	name the capability and dates clearly
Customer-centered	explain service quality, consistency, security or product improvement, not internal cost alone
Alternative path	show replacement, migration, exception or support
Accessible	consider language, accessibility, digital exclusion and vulnerable customers
Traceable	retain notice versions, approval, send logs and complaint response
Coordinated	support, branches, call center, relationship managers and digital channels aligned

17. Records / Legal-Hold / Retention Constraints

Rationalization may involve deleting, archiving, migrating or freezing records. Product and architecture teams should not make legal conclusions.

17.1 Constraint Types

Constraint	Practical implication
Records retention	old outputs, customer communications, decisions, case notes, logs or model evidence may need retention
Legal hold	routine deletion or alteration may be suspended for scoped records
Regulatory inquiry / audit	evidence must remain searchable, explainable and producible
Contractual records	partner/customer contracts may define notice, data, audit or transition obligations
Privacy deletion request	may conflict with retention or legal hold; requires authorized handling
Model governance evidence	evals, approvals, monitoring and incidents may need archive
Vendor data location	vendor-held records may need export, return or deletion confirmation

17.2 Records Gate

Before disposal or irreversible deletion:

Check	Evidence
Record classes identified	record taxonomy and data map
Retention schedule mapped	retention class and authority recorded
Active hold checked	hold register search and authorized sign-off
Export / archive completed	archive manifest, checksum, access controls
Vendor records addressed	data return/deletion certificate or exception
Disposal logged	deletion/disposition certificate
Access retained for audits	read-only evidence binder or archive route

18. Decommission Evidence Binder

The evidence binder is the artifact that proves the decision and execution were controlled.

Section	Contents
Executive decision	decision type, owner, date, forum, rationale
Scope	products, capabilities, apps, APIs, models, tools, vendors
Evidence	usage, value, profitability, cost-to-serve, risk, architecture debt
Dependency graph	impacted customers, processes, systems, data, records, controls
AI analysis	prompts/outputs or analysis method, source data, human review
Legal/records review	review status and constraints without making legal conclusions
Target architecture	future-state diagram, owner, controls, SLO/SLA
Migration plan	cohorts, sequencing, tests, rollback
Communications	approved messages, audiences, send evidence, support scripts
Execution proof	feature flag, API route, model route, connector, access, vendor actions
Decommission certificate	final status, exceptions, residual risk, sign-offs
Post-review	benefits, capacity release, incidents, complaints, lessons

19. Decommission Certificate Template

Decommission object:
Decision forum:
Decision date:
Accountable owner:
Execution owner:

Scope:
  Products:
  Capabilities:
  Applications:
  Features:
  APIs:
  Models/prompts/RAG/tools:
  Vendors:

Evidence reviewed:
  Usage:
  Customer value:
  Cost-to-serve:
  Profitability:
  Operational risk:
  Architecture debt:
  AI/model/vendor dependency:
  Records/legal-hold review status:

Migration:
  Target capability:
  Cohorts migrated:
  Exceptions:
  Back-out plan tested:

Communications:
  Customer/internal/API audiences:
  Approved notice version:
  Send/completion evidence:

Execution proof:
  Feature flags:
  API routes:
  Model routes:
  Tool permissions:
  Data/archive:
  Vendor access:

Residual risk:
  Open exceptions:
  Owner:
  Review date:

Closure:
  Final approval:
  Date:

20. Governance Model

20.1 Forums and Decisions

Forum	Owns	Does not own
Product Portfolio Council	portfolio strategy, value, funding, capacity, customer impact tradeoffs	detailed technical design alone
Architecture Review Board	target architecture, dependency risk, migration design, sunset controls	business value decision alone
Risk / Compliance / Legal / Records	constraints, required reviews, risk acceptance path, retention/hold handling	product prioritization alone
Operations Readiness	support, training, manual workaround, incident and rollback	strategic product fit
Vendor / Procurement	contract notice, exit support, data return, deletion, renewal	model behavior validation alone
Internal Audit / Assurance	evidence quality, control testability, decision trail	management decision itself

20.2 RACI

Activity	Accountable	Consulted
Candidate identification	Portfolio lead	AI analytics, EA, FinOps
Capability mapping	Business architect	PM, BA, domain SMEs
Dependency graph	Enterprise architect	app owners, data, platform, security
Scorecard	Product portfolio council	finance, risk, architecture, operations
Records/hold review	Records / Legal authorized roles	product, architecture, data owner
Target architecture	Architecture board	platform, security, data, operations
Customer communication	Product / channel owner	legal, compliance, support, brand
API/model sunset	Platform/API/model owner	consumers, risk, security
Execution	Technical owner and operations	product, support, vendor
Closure review	Portfolio lead	audit, finance, architecture, risk

21. Product Manager Incentives

Portfolio rationalization fails when PMs are rewarded only for launches.

21.1 Incentive Failures

Incentive failure	Result
Feature count equals progress	dead features accumulate
Local P&L only	platform, support and compliance costs are externalized
Launch celebrated, retirement ignored	legacy never exits
Adoption without risk	risky high-use features appear successful
No credit for merge	teams defend duplicate capabilities
No capacity accounting	released teams are immediately consumed by ad hoc work

21.2 Better PM Scorecard

Metric	Why it matters
Outcome per capability	focuses on customer/business result, not feature count
Cost-to-serve trend	makes operating burden visible
Duplicate capability reduction	rewards simplification
Legacy exit completion	prevents endless parallel run
Risk and complaint trend	prevents cost-only shutdown
Platform reuse rate	rewards target architecture
Capacity reallocated to strategic bets	proves decommission creates optionality
Evidence completeness	makes auditability a product responsibility

22. Implementation Guardrails

Guardrail	Practical rule
No shutdown without owner	every object has accountable business and technical owner
No irreversible deletion before records gate	retention and hold review first
No API cutoff without consumer inventory	unknown traffic must be investigated
No model replacement without eval	compare quality, safety, cost, latency and evidence
No customer migration without support readiness	support scripts, escalation and complaint monitoring required
No vendor exit without export test	data/config/log/evidence export must be validated
No hidden capacity claim	released capacity must be measured and reallocated
No single-metric decision	usage, value, cost, risk, architecture and constraints all considered
No AI-only decision	AI recommendations require human review and governance sign-off

23. 30 / 60 / 90 Day Roadmap

First 30 Days: Build Evidence Foundation

Workstream	Deliverable
Scope	select 1-2 domains, such as customer service AI or onboarding workflow
Inventory	product/capability/application/API/model/vendor inventory
Metrics	usage, cost-to-serve, incident, complaint, model call and support metrics
Dependency graph	first graph with customer, product, app, API, model, data, vendor nodes
Governance	decision forums, RACI, scorecard draft
AI analysis	first duplicate capability clustering with human review
Controls	records/legal-hold review path and decommission evidence template

Days 31-60: Decide and Design

Workstream	Deliverable
Candidate scoring	top rationalization candidates with scorecard
Target architecture	target capability owner, platform reuse, migration design
Cohort plan	customer/API/user migration cohorts and exception groups
Sunset controls	feature/API/model/tool/vendor sunset runbooks
Communications	internal, customer, API consumer and support communication drafts
Evidence	decision packet for architecture board and portfolio council
Pilot migration	low-risk cohort or internal-only capability migration

Days 61-90: Execute and Prove

Workstream	Deliverable
Controlled migration	execute first cohort and monitor
Decommission	disable selected old feature/API/model/tool with rollback path
Evidence binder	completed certificate and proof
Benefits	cost, capacity, risk and customer impact measurement
Governance refinement	update scorecard, gates, inventory fields and templates
Scale plan	next rationalization wave and portfolio health metrics

24. Architecture Board Packet

Section	Content
Decision requested	keep, merge, migrate, sunset, archive, replace
Business rationale	customer value, profitability, cost-to-serve, strategic fit
Capability map	current duplicate capabilities and target owner
Dependency graph	impacted products, apps, APIs, data, models, tools, vendors, controls
AI analysis summary	signal mining, clustering and human review notes
Risk assessment	operational, model, security, privacy, vendor, customer harm
Records/legal-hold status	review completed, constraints, exception handling
Target architecture	future-state diagram and control points
Migration plan	cohorts, sequencing, parallel run, rollback
Customer/API communications	audience, timing, approved channels
Evidence plan	binder, certificate, post-review metrics
Decision log	approvals, conditions, residual risks

25. Financial Retail Example: Onboarding AI Capability Consolidation

Current state:

Retail banking, credit card and small business teams each built an onboarding document AI assistant.
Capabilities overlap: document classification, missing-doc checklist, KYC policy retrieval, application summary.
Models differ, OCR vendors differ, RAG indexes differ, operations QA differs.
Customers see inconsistent missing-document reasons.
Model and vendor cost is rising, while support agents still manually reconcile outputs.

Rationalization finding:

Dimension	Finding
Customer value	value is high, but fragmentation hurts consistency
Profitability	duplicate OCR/model/vendor spend creates avoidable cost
Operational risk	inconsistent KYC policy interpretation and manual rework
Architecture debt	separate indexes, prompts, trace schemas and workflow connectors
Model/tool dependency	multiple vendors with different evidence exports
Records constraint	application documents, decision notes and customer communications need mapped retention
Migration path	shared onboarding AI platform with product-specific policy profiles

Decision:

Keep onboarding AI as a strategic capability。
Merge duplicate document classification and checklist generation。
Migrate to common model gateway, OCR abstraction, RAG pipeline, eval harness and trace schema。
Preserve product-specific rules, customer disclosures, risk thresholds and operations queues。
Sunset old APIs after partner and internal consumer migration。
Archive old outputs and eval evidence according to records review。

Target architecture:

Digital onboarding channels
  -> Onboarding AI capability service
  -> Product policy profile
  -> OCR / document extraction abstraction
  -> KYC / credit / SMB RAG sources
  -> Model gateway and eval harness
  -> Workflow and case system connectors
  -> Evidence and records layer

26. Interview Answers

Q1: How would you rationalize an AI product portfolio in a bank or fintech?

30 秒版本:

I would not start with an application list. I would build a capability and dependency graph across products, applications, APIs, models, prompts, RAG indexes, tools and vendors. Then I would score each candidate by customer value, profitability, cost-to-serve, operational risk, architecture debt, AI dependency health, vendor risk, records/legal-hold constraints and migration feasibility. AI can mine signals and propose clusters, but accountable governance decides customer-impacting shutdowns.

2 分钟版本:

In a financial retail environment, the biggest risk is shutting down the wrong thing because usage looks low or cost looks high. I start with business capabilities and customer journeys, then connect them to applications, APIs, data stores, records, models, prompts, tools and vendors. I use AI to mine usage, token cost, support tickets, incidents, complaints, model eval failures and architecture metadata, then cluster redundant capabilities. But every cluster is reviewed by product, architecture, operations, risk, legal/records and finance. The decision may be invest, merge, migrate, freeze, sunset or retain as a control. For execution, I require migration cohorts, customer/API communication, records/legal-hold review, rollback, decommission certificate and post-review benefits tracking.

Q2: What is the difference between application retirement and capability decommission?

30 秒版本:

Application retirement is about shutting down a system. Capability decommission is about removing, merging or migrating a business ability across products, processes, systems, APIs, models, tools, vendors and operating teams. In AI, capability decommission is broader because prompts, models, RAG indexes, evals and evidence may outlive the application.

2 分钟版本:

For example, retiring an old case management app does not necessarily retire the capability of complaint triage. The capability may move to a shared workflow service with AI summarization, policy retrieval and human review. I need to map customer journeys, record classes, API consumers, model routes, prompt versions, tool permissions and vendor contracts. Only after migration, evidence preservation and support readiness can the old app be technically retired. This is why capability decommission belongs in enterprise architecture, not only IT operations.

Q3: What role should AI play in decommission decisions?

30 秒版本:

AI should accelerate evidence work: mining usage, cost and risk signals; clustering overlapping capabilities; enriching dependency graphs; proposing migration cohorts; and drafting sunset plans. AI should not own customer-impacting shutdown decisions, legal-hold decisions, records disposal or risk acceptance.

2 分钟版本:

I would use AI as an analyst and drafting assistant. It can read product descriptions, API specs, support tickets, incident records and cost data to identify likely duplicate capabilities and high-cost low-value candidates. It can also propose migration cohorts based on usage and risk. But there must be traceability back to source evidence, human review for false positives and governance sign-off. The final decision affects customers, contracts, operations, records and risk appetite, so it belongs to accountable product and architecture governance with legal, compliance, records and risk partners.

Q4: How do you avoid harming customers during product sunset?

30 秒版本:

I use cohort migration, clear alternatives, support readiness, approved communications, complaint monitoring and rollback. I also check long-tail, vulnerable, accessibility-sensitive, high-value and contractual customers separately instead of using average usage metrics.

2 分钟版本:

I segment customers by activity, dependency, risk, value, accessibility, contract and support needs. Low-risk internal users may migrate first; high-value or vulnerable customers get enhanced support; API partners get a test window and certification. Every communication explains what changes, when it changes, what alternative exists and where to get support. I monitor complaints, failed attempts, support volume, conversion and incidents during migration. If thresholds are breached, the back-out plan pauses or reverses the migration.

Q5: What evidence would you show an architecture board before decommission?

30 秒版本:

I would show the capability map, dependency graph, usage/value/cost/risk scorecard, target architecture, model/tool/vendor dependency assessment, records/legal-hold review status, migration cohorts, API/customer communication plan, rollback plan and decommission certificate template.

2 分钟版本:

The board needs to see both why and how. Why: customer value, profitability, cost-to-serve, operational risk, architecture debt and strategic fit. How: impacted products, apps, APIs, data stores, records, models, prompts, RAG indexes, tools, vendors and teams. I would include controls for feature flags, API versioning, model route changes, tool permission revocation, archive and disposal evidence. I would also include residual risk owners and post-decommission metrics so the decision is not just a one-time approval.

27. Quick Reference Checklist

Area	Check
Inventory	Product, capability, app, API, model, prompt, RAG, tool, vendor mapped
Evidence	Usage, value, cost, risk, profitability and debt collected
AI analysis	Clusters and recommendations traceable to source data
Governance	Decision forum, accountable owner and RACI clear
Architecture	Target state and dependency graph reviewed
Records	Retention and legal-hold review path completed before disposal
Migration	Cohorts, tests, support and rollback defined
Communications	Customer, internal and API notices approved and retained
Execution	Feature/API/model/tool/vendor controls executed with proof
Closure	Certificate, evidence binder and benefits realization completed

Final mental model:

Inventory tells you what exists.
Signals tell you what hurts.
Capability mapping tells you what overlaps.
Architecture tells you what should replace it.
Governance tells you who may decide.
Migration tells you how to avoid harm.
Evidence tells you whether the decision was controlled.