Skip to main content
Next Step PM
Back to the library

Plan and prioritise · Add-on

Map who depends on you and plan breaking changes

Other teams build on your platform, so a change you make can break their work. Know who uses what, and give them time and help when something must change.

About 3-8 daysEvergreenLast reviewed 5 November 2026

Who this applies to

Skills it builds
Technical and AI fluencyCommunication and influence
PM types
Platform
Product types
All
Starting points
All
Ways of working
All
Experience
All
Size of organisation
All

Steps, by experience

Beginner (under 1 year)

  1. List the teams and systems that use your platform.
  2. For each, note which parts they use.
  3. Learn the difference between a compatible change and a breaking change.
  4. Before a breaking change, tell every affected team and agree a date.
  5. Give them a guide to move to the new version.

Intermediate (1 to 4 years)

  1. Keep a live map of consumers and the features they use.
  2. Use clear version numbers so teams can tell what is safe to upgrade.
  3. Set a deprecation policy: notice period, support window and removal date.

Experienced (5+ years)

  1. Set versioning and deprecation standards across platforms.
  2. Measure the cost of breaking changes to other teams.
  3. Plan migrations as a portfolio, not one team at a time.

Who can do this

Owner: Product manager

Can be delegated to

  • Tech Lead or Architect or Backend Engineer: Find which teams call which features
  • Content Designer: Write the migration guide

Reviewed by: Architect, Tech Lead

Tool examples

Confluence
Publish the consumer map and deprecation policy.
GitHub
Tag releases with semantic version numbers.

Definition of done

  • Consumer map in place
  • Deprecation policy published
  • Next breaking change agreed with affected teams

Common pitfalls

  • Assuming nobody uses an old feature
  • Short notice for breaking changes
  • No migration guide

If you lead the team

What good looks like: Platform teams know who depends on what and give notice before breaking changes.

Ask your PM

  • Who depends on this, and how did we tell them about the change?
  • What's our notice period for breaking changes?

Warning signs

  • Changes break other teams' work without warning.
  • No one knows who uses which service.

Do these first

Sources