Change Management for Product Ops
The Playbook I Wish I Had
👋 Hi, I’m Mat and whether you’re new or already following along — welcome to The Glue, a free newsletter about frameworks, tools, and systems for building product orgs that actually work.
You’ve probably seen this before:
A new process gets introduced…let’s say quarterly planning.
Leadership’s aligned. There’s a clean Notion doc. Maybe even a kickoff meeting.
The rollout goes live.
Three weeks later?
Half the teams are using it.
A few are doing their own thing.
One team asks, “Wait, are we still doing this?”
Someone’s recreated the doc in Google Sheets.
The idea wasn’t bad.
The intent was solid.
But the rollout? It missed.
And this is where Product Ops lives every day. Not just launching new processes, but trying to change how people work together.
That’s change management.
And most of us are doing it without a real playbook.
The Real Work of Product Ops Is Leading Change
Let’s be honest: Product Ops is a strange role…in the best way.
You’re expected to drive alignment, improve systems, and help the organization scale. But doing that usually requires changing how people behave, not just tweaking how things are tracked.
And we don’t always call that what it is.
We call it enablement. Or rollout. Or ops.
But it’s change management and we’re doing it constantly.
Most of the time, though, we lead change like it’s a task to complete instead of a thing people need to adopt. We ship a doc, post an update, maybe run a training.
Then wonder why nothing sticks.
Change Is a Product
This is the shift:
Every change you roll out new rituals, frameworks, processes, tools is a product.
It has users.
It has a launch.
It has a learning curve.
And it lives or dies based on how well you design it, communicate it, and reinforce it.
You’d never ship a product feature without:
A clear problem it solves
User onboarding
Feedback loops
Success metrics
Iteration
But we skip those things all the time when rolling out internal changes.
And then we’re surprised when people quietly revert to the old way.
This Is the Work (Whether We're Trained or Not)
Change management is at the heart of Product Ops. It’s how we drive alignment, improve how teams work, and help orgs evolve.
And while there are formal frameworks and certifications out there like Prosci, ADKAR, Kotter, the reality is most of us weren’t trained in them. We picked it up in the wild: learning through messy rollouts, spotty adoption, and the occasional Slack DM asking, “Are we even still doing this?”
And yet we keep getting handed more complex change to lead because that is the job.
Product Ops isn’t just process work. It’s behavior change work.
The Change Brief
Change often fails because the important stuff like context, risks, expectations, ownership is scattered across slides, Slack, or one person’s head. A Change Brief brings it all into one place.
Think of it less like a form, more like a conversation starter.
Use it to pressure-test your thinking, align key people early, and reduce rollout chaos.
Yes, it can be used as a template…just add or remove sections based on what your org needs. The structure is flexible. The thinking behind it shouldn’t be.
Here’s what to include and why it matters:
What’s Changing
Why it matters: Clarity upfront reduces ambiguity later. People need to know exactly what’s different from how they work today.
Example: “We’re replacing team-level Jira boards with a unified program board across all squads.”
Why It’s Changing
Why it matters: Without a compelling “why,” people disengage. Anchoring the change in real problems or opportunities builds buy-in.
Example: “Right now, leadership lacks visibility into cross-team dependencies. This change helps reduce delivery risk.”
Who’s Affected
Why it matters: Broad change messages get ignored. Tailoring by role shows respect and makes the change feel relevant.
Example: “Product Managers and Engineering Leads will need to update epics in the shared board weekly. Designers and QA won’t need to change their current flow.”
What Success Looks Like
Why it matters: You’re not just shipping the change—you’re aiming for adoption. Define observable behaviors or outcomes.
Example: “Within 30 days, 90% of squads are using the shared board and updating it weekly.”
Timeline & Milestones
Why it matters: Without milestones, the change feels abstract. People need to see when to engage and when it goes live.
Example:Aug 12: Announcement
Aug 19: Training sessions
Sep 1: Official go-live
Sep 15: First usage review
Key Roles
Why it matters: Change feels riskier when leadership isn’t visibly involved. Assigning roles drives accountability and trust.
Example:Sponsor: Head of Product
Change Lead: Product Ops
Team Champions: One per squad
Communication Plan
Why it matters: People don’t remember one announcement. A layered, repeated message helps the change stick.
Example:Slack teaser + email on Aug 12
Walkthrough during all-hands
Team leads share in weekly standups
Slack channel pinned for Q&A
Risks & Resistance
Why it matters: Ignoring resistance doesn’t make it disappear. Surfacing risks early helps you plan mitigations.
Example: “Some teams worry this will slow them down. We’re offering a 2-week grace period and lightweight tracking during onboarding.”
Support
Why it matters: Change fails when people feel unsupported. Give them the tools to succeed without having to ask.
Example: “We’ve created a Loom walkthrough, a short Notion guide, and open office hours for the first 3 weeks post-launch.”
Done well, the Change Brief becomes a single source of clarity not just for you, but for everyone involved in making the change real.
This isn’t project management.
It’s designing behavior change.
And this is how you do it with intention.
Why This Matters (More Than You Think)
People don’t resist change because they’re lazy or difficult.
They resist it because most change is confusing, rushed, or irrelevant to how they actually work.
Your job isn’t just to ship something new.
It’s to make it make sense, and to make it safe to try.
That’s the real skill set behind effective Product Ops:
Designing change like a product
Prioritizing adoption over delivery
Building habits, not just documentation
If you can do that, you’re not just running smoother rituals—you’re building an organization that can adapt.
And in the long run, that’s what actually scales.
-Mat 🤓
If you’re finding this newsletter valuable, share it with a friend, and consider subscribing if you haven’t already.
Good stuff Mat!