Product Change Management Plan

Product / area: [Product or feature name] Change owner: [Name / role] Change type: [Breaking / Deprecation / Pricing / UX / Behind-the-scenes] Version: [v1.0] Drafted: [Date] Target release: [Date]

---

1. Change summary and rationale

[State plainly what is changing in one or two sentences, then explain why it is worth making — the problem it solves, the value it unlocks, and the cost of leaving things as they are.]

• What is changing: [Description]
• Why now: [Rationale]
• Cost of doing nothing: [Consequence of not making the change]

2. Impact assessment

[For each area the change touches, describe the impact and rate its severity. Be honest — this table is where you find the consequences you had not thought of.]

Area	Impact	Severity
[Existing users / workflows]	[How they are affected]	[Low / Medium / High]
[Integrations / API consumers]	[How they are affected]	[Low / Medium / High]
[Billing / contracts]	[How they are affected]	[Low / Medium / High]
[Support / documentation]	[How they are affected]	[Low / Medium / High]
[Adjacent features]	[How they are affected]	[Low / Medium / High]

3. Affected stakeholders and customers

[List who needs to know and who has to act, internal and external. Note who is most affected, because they should be the first and best informed.]

Group	Why they care	What they must do	Owner
[Support / success]	[Reason]	[Action]	[Role]
[Sales / leadership]	[Reason]	[Action]	[Role]
[Affected customers]	[Reason]	[Action]	[Role]
[Wider user base]	[Reason]	[Action]	[Role]

4. Approval

[Match the sign-off to the blast radius. Name who must approve this specific change before it ships.]

Approver	Role	Decision	Date
[Name]	[Product]	[Approved / Pending]	[Date]
[Name]	[Engineering]	[Approved / Pending]	[Date]
[Name]	[Finance / Legal — if pricing or contractual]	[Approved / Pending]	[Date]

5. Communication plan and timeline

[Decide who is told what, through which channel, and when relative to the release. Tell internal teams first; give the most-affected customers the longest notice.]

Audience	Message	Channel	Timing
[Internal teams]	[What they need to know]	[Briefing / internal note]	[Before announce]
[Affected customers]	[What is changing, when, what to do]	[Direct email / in-app]	[Lead time]
[All users]	[Release note]	[Changelog / blog]	[On release]

6. Rollout and rollback

[Describe how the change ships in a way you can watch and slow down, and exactly how to reverse it if the signals turn bad.]

• Rollout method: [Flag / percentage / pilot segment / phased]
• Signals to watch: [Metrics and the readings that would make you stop]
• Rollback trigger: [What condition triggers a rollback]
• Rollback steps: [How to reverse, and how fast]
• Who can call it: [Role authorised to roll back]
• If irreversible: [Forward-fix plan and communications response]

7. Success criteria

[Define what success looks like in measurable terms before you start, so the change can be called done rather than merely stopped.]

• [Adoption target — e.g., percentage on the new behaviour by a date]
• [Support volume — flat or falling, no sustained spike]
• [Churn / retention — no measurable increase in cancellations]
• [Migration — completed by the deprecation deadline]