Product Ops: Is It Basically Change Management?
Three Frameworks That Explain Why Your Brilliant Process Keeps Getting Ignored
I’ve been taking a look back through our library of Product Opscast episodes to pick out some key and common themes, which I’ll be diving into in a series of new articles across 2026.
First up - Change Management
As always, much thanks to all of our wonderful guests on the podcast!
The most consistent theme in Product Operations is not process design, not data, not tooling, not even stakeholder management.
It is change management. There I said it.
This does not mean it is the most important per se, but it is constant in everything we do and deliver. And every guest we have spoken to acknowledges it.
And it is also the hardest part of the job…
Cindy Camacho described the painful experience of “parachuting in like the hero that was going to save the day with all of my cool task lists and workflows and processes - only to discover the organisation was not ready.”
Matt LeMay talked about product managers who respond to new processes with: “Go away. Never talk to me again. I’m busy. I hate you. Stop.”
Amy Rohan was honest about the personal toll: “It can be a tough and lonely job in product ops, especially if you take that stuff on personally.”
Antonia Landi has confessed to bulldozing organisations with best practices early in her career. I have my own stories too…
And yet, look at most Product Operations job descriptions. Look at most Product Operations frameworks, playbooks, and conference talks. Change management barely gets a mention. We talk endlessly about what to implement (the process, the tool, the template, the cadence) and remarkably little about how to get people to actually do it.
“You can achieve a hundred percent adoption of anything if you don’t care if it works or not.” Matt LeMay
That line has stayed with me. Because it captures the fundamental challenge: implementation is not adoption. Rollout is not change. An announcement is not acceptance.
So I want to do something we probably should have done a long time ago at Product Ops Confidential (and probably in the field of Product Ops too): take the serious, well-researched discipline of change management, a field with decades of frameworks, research, and wisdom, and apply it directly to what we do.
I am drawing on three established models, each created by professionals who have spent their careers studying how change actually happens. What I have tried to do is take their thinking and map it onto the specific reality of Product Operations: the resistance we face, the dynamics we navigate, and the practical toolkit we need.
Why Change Management Is the Product Ops Job
Before we get into the frameworks, let me make the case for why this matters so specifically for us.
Every time we introduce a new process, we are asking people to change how they work. Every time we roll out a tool, we are asking people to change their habits. Every time we refine a workflow or adjust how teams communicate, we are asking people to do something they were not doing before. And, quite often, to stop doing something they were comfortable with.
“Product ops is a people job. It’s first and foremost a people job. You’re really diving deep into the culture of the organisation, the aspirations of the organisation, making sure that you can achieve those aspirations by taking all of those people on that journey with you.” Antonia Landi
That journey (the taking-people-with-you part) IS change management. And research suggests it matters enormously. Prosci, the change management research firm, has studied over 10,000 change professionals and found that projects with excellent change management are approximately seven times more likely to meet their objectives than those with poor change management.
Seven. times.
The question is not whether we need change management skills. The question is how we implement change management, and which frameworks give us the most practical help.
I want to introduce three. They are complementary; they operate at different levels and address different parts of the problem. Together, they give us a remarkably complete toolkit for the kind of change Product Operations drives every day.
Framework 1: Switch - The Rider, the Elephant, and the Path
“What looks like resistance is often a lack of clarity.”
Chip Heath and Dan Heath’s Switch: How to Change Things When Change Is Hard (2010) is, in my view, the most immediately useful change management book for anyone in Product Operations. If you read nothing else on this list, read this one.
The Heaths draw on a metaphor from psychologist Jonathan Haidt: imagine a Rider sitting on top of an Elephant, walking along a Path.
The Rider is our rational mind: analytical, planning, logical.
The Elephant is our emotional mind: instinctive, powerful, driven by feeling.
The Path is the environment: the context, the systems, the defaults that shape behaviour.
The Rider looks like it is in control. But the Elephant is far larger and more powerful. And the Path determines where both of them end up regardless of intention. The Heaths’ central argument is that most change efforts fail because they only address the Rider, presenting data, making logical arguments, issuing directives, all while ignoring the Elephant and the Path entirely.
As they write: “If you reach the Riders of your team but not the Elephants, team members will have understanding without motivation. If you reach their Elephants but not their Riders, they’ll have passion without direction. In both cases, the flaws can be paralysing.”
This maps onto Product Operations with uncomfortable precision.
Direct the Rider: Give People Clarity, Not Ambiguity
The Heaths’ first insight is: “What looks like resistance is often a lack of clarity.” When people do not know exactly what to do, they freeze. The Rider spins its wheels.
How many times have we rolled out a change with language like “we would like teams to start thinking about outcomes” or “we are moving toward a more data-driven approach”? That is Rider-spinning language. It sounds clear to us. It is hopelessly vague to the people who need to act on it.
The Heaths recommend three techniques that translate directly to Product Operations:
Find the Bright Spots. Instead of focusing on what is broken, find what is already working, however small, and replicate it. The Heaths cite Jerry Sternin’s work on childhood malnutrition in Vietnam: rather than importing external solutions, Sternin found local families whose children were thriving and studied what they were doing differently.
In Product Ops terms: before you design a new process, look for the team that is already doing something close to what you want. Study them. Make their approach visible.
“You’re always looking for your champions in your change process. When you can find those champions who innately are a little hungry, maybe a little bit curious. It’s like light bulbs go off.” Fo Neale May
Script the Critical Moves. The Heaths are emphatic: ambiguity is the enemy of change. Do not say “eat healthier”, say “next time you are in the dairy aisle, reach for 1% milk instead of whole milk.” In their example, that single, specific instruction shifted low-fat milk market share from 18% to 41% in West Virginia communities.
This is Matt’s “three times rule” in action: “You are not allowed to share a template until you have filled it in three times.” Why? Because filling it in yourself reveals the specific, concrete difficulties. You discover the two questions that are genuinely hard to answer, the step that takes twenty minutes longer than expected, and the assumption that does not hold. Script the critical moves means: do not give people a template and a goal. Give them step-by-step instructions for exactly how to fill in the template, with examples, and tell them where they may/will get stuck.
Point to the Destination. Create a vivid picture of what success looks like. Not a mission statement but a destination postcard. The Heaths describe a first-grade teacher who told her students they would be “third graders” by the end of the year. That vivid, concrete destination was far more motivating than any list of learning objectives.
For Product Ops, instead of “we are implementing continuous discovery,” try “by Q3, every PM on this team will be able to walk into a planning session with three validated customer insights from the last two weeks, without it taking more than an hour a week.” Specific. Vivid. Achievable. A destination postcard. And this should not be hard, because this is SMART goals at its core, something we’ve had drilled into us with every goal-setting initiative for the last two decades and more.
Motivate the Elephant: Change Is Emotional, Not Just Rational
The Heaths’ second insight is: “What looks like laziness is often exhaustion.” Self-control - the Rider’s ability to override the Elephant - is a depleting resource. The more change you ask of people, the more their capacity for change erodes.
This is why the PM who cheerfully adopted your first three process changes starts pushing back on the fourth. It is not that they are suddenly resistant. Their Elephant is exhausted (I’m not calling any individual an Elephant here!)
“Once people have been through three or four failed transformations, they don’t believe it anymore. And they see their job as to wait it out. And those are usually the people who are the most credible within an organisation.” Matt LeMay
Matt (seemingly the font of all knowledge on this topic!) calls these “zombie beliefs”; the residue of past change fatigue that actively teaches newcomers to resist.
The Heaths recommend:
Find the Feeling. Change happens when people feel the need for it, not when they merely understand it analytically. The sequence is not Analyse → Think → Change. It is See → Feel → Change. The Heaths cite Jon Stegner, who piled 424 different types of work gloves on a conference table, each tagged with its price, showing executives that the same glove cost £4 at one factory and £14 at another. The visceral, emotional reaction drove change far more effectively than any spreadsheet.
In Product Ops, this means: if you want to change how roadmaps are communicated, do not present a slide about communication theory. Show the team the confused Slack messages from stakeholders who cannot find the information they need. Show them the email chain where three different people gave three different answers about the same initiative. Let them feel the dysfunction.
“If we don’t start talking about things like risk of inaction, opportunities missed, money wasted, then we are simply not putting the work we are already doing into the context it needs to be seen and heard.” Antonia Landi
Shrink the Change. Make the change small enough that people do not feel overwhelmed. Help them feel closer to the finish line than they think.
“[be pragmatic and empathetic and take baby steps] but where you don’t want to make compromises is on the sense of urgency and the willingness to change.” Malte Scholz
“Minimum Viable Process” is the Product Ops embodiment of shrinking the change:
“This is the minimum that we expect you to deliver.” Not the ideal. Not the fully-formed process. The minimum viable version that gets people moving.” Fo Neale May
Grow Your People. Cultivate a sense of identity that aligns with the change. When people see change as consistent with who they are, they adopt it willingly. This is why Stephanie Leue’s insight matters: the difference between an “educate” mindset and a “common ground” mindset. If you frame change as “I need to teach you how to work properly,” you are attacking people’s identity. If you frame it as “we are the kind of team that ships with confidence; here is how we get there,” you are growing their identity toward the change.
Shape the Path: Make the Right Thing the Easy Thing
The Heaths’ third insight is the one I think Product Operations underestimates the most: “What looks like a people problem is often a situation problem.”
The most elegant change interventions do not require persuading anyone. They change the environment so that the desired behaviour becomes the path of least resistance.
The Heaths cite Brian Wansink’s popcorn experiment: people given larger buckets ate 53% more popcorn, regardless of hunger or taste. The container drove the behaviour, not the person. To change eating behaviour, change the container. (Note, I am not advocating for eating more popcorn here!)
In Product Operations terms: instead of persuading PMs to update their roadmap status weekly, build the roadmap view so that it automatically pulls from the tools they already use. Instead of training people on a new template, embed the template into the workflow they already follow. Instead of reminding people to share updates, build the update into the existing ceremony.
I can speak first hand to the success of this in particular through a deep, extended review and implementation of AI tooling to automate and reduce the efforts for typical reporting, giving back literally 1000s of people hours a year.
“Tooling and change are intertwined. They are essentially the same thing. You cannot introduce a new tool without introducing change. And I think as a product ops person, I am so careful to introduce new tooling because I’m not looking at the cost of the tool. I am looking at the cost of the tool and the cost of the change that the tooling will inevitably bring with it.” Antonia Landi
Three techniques for shaping the Path:
Tweak the Environment. Make the right behaviours easier and the wrong behaviours harder. If you want people to use a decision log, put the decision log where they already make decisions, and not in a separate tool they have to navigate to.
Build Habits. Set up what the Heaths call “action triggers”; pre-decisions about when and where to perform a specific behaviour. Fo’s “muscle memory” concept is exactly this: “You should not have to think about this. It should be automatic.”. Building new habits in others has been core to my Product Ops career from day one.
Rally the Herd. Behaviour is contagious. This is why finding early adopters and making their success visible matters so much. As Fo said: “Change doesn’t start with the first one or two people. It’s the five, six, seven who jump on the bandwagon that get it to roll down the hill.”
Framework 2: ADKAR - Where Exactly Is the Person Stuck?
If Switch gives us the psychology of change, Jeff Hiatt’s ADKAR model - developed through Prosci’s research across hundreds of organisations- gives us the diagnostic.
ADKAR stands for five sequential elements that an individual must achieve to successfully change:
A — Awareness of the need for change
D — Desire to participate in and support the change
K — Knowledge of how to change
A — Ability to implement the required skills and behaviours
R — Reinforcement to sustain the change
The critical insight of ADKAR is that these elements must be achieved in order. You cannot build Knowledge effectively in someone who lacks Desire. You cannot build Ability in someone who lacks Knowledge. And you cannot sustain change without Reinforcement. Most failed change initiatives skip straight to Knowledge (training, documentation, templates) without establishing Awareness and Desire first.
This is a common mistake in Product Operations. We design a process, create the documentation, build the template, maybe run a training session, and then wonder why adoption stalls. We jumped straight to K without checking whether people had A and D. I have been guilty of this, often because I’m to hyped on the improvements this will bring, but also because I have a tendency to be verbose in my explanations… and the audience often WANTS to just go straight to the K. We need to give time for Awareness.
Let me map each ADKAR element onto a typical Product Ops change, say, introducing a new quarterly roadmap review cadence.
Awareness: Do they understand why this is needed?
Awareness means: do they understand the business reason for the change? Do they understand what is broken about the current approach? Do they see the consequences of not changing?
Not “do they know a new cadence is happening” - that is just communication.
“People don’t want to be told what to do. People want to know why they’re doing something. How is this going to benefit me? What’s in it for me?” Cindy Camacho
If your PMs do not understand why the current roadmap process is failing the business, no amount of training on the new cadence will matter.
Desire: Do they actually want to participate?
This is where most resistance lives, and it is the element we control least. A person can have full awareness of the problem and still lack the desire to change, because they are tired of transformations, because they do not trust the person driving it, because the change feels threatening to their autonomy.
“There are people who start at minus 10. And you need to do your hardest work to get them even to zero so that they’ll listen to you.” Antonia Landi
Building desire requires understanding what each person cares about and connecting the change to those motivations. It requires trust. It requires time. This is why you will hear me advocating for the quick wins and low-hanging fruit. Of late, this has been wrongly associated with ‘busy work’, and perhaps on an individual change level, the value/improvement is small. But cumulatively, they become significant. And an invisible outcome so under-appreciated is the trust this builds in you, in Product Ops, and in change itself.
But it cannot be mandated. As the Prosci research makes clear, desire is inherently personal and cannot be manufactured through authority alone.
Knowledge: Do they know how to do it?
This is where most Product Ops effort goes, and rightly so, once Awareness and Desire are established. But the trap is assuming that documentation equals knowledge. Back to Matt’s “three times rule” is an antidote to this trap: if you have not done the thing yourself three times, you do not yet understand what people need to know.
Ability: Can they actually do it in practice?
The gap between Knowledge and Ability is where many change efforts stall. People know what to do but cannot yet do it reliably in the real world. This requires practice, coaching, time, and, critically, the removal of barriers.
“To whom will the benefit of this process accrue and to whom will the cost of this process accrue? And if those are different people, it’s very difficult to roll that process out.” Thor Mitchell
If your new roadmap cadence saves leadership time but costs PMs two hours a week, you have an Ability problem. The people who need to change are the ones bearing the cost.
Reinforcement: Will it stick?
Without reinforcement, even successfully adopted changes can erode. People revert to old behaviours because the old behaviours are comfortable, especially true when times get tough or uncertainty creeps in (whether with the changes or more holistically, like company reorgs etc).
Reinforcement means: measurement, recognition, visible celebration of adoption, and, importantly, removing the old way of doing things so that reverting is harder than continuing.
The power of ADKAR as a diagnostic is this: when a change initiative stalls, you can assess each person or group against the five elements and identify the specific barrier point. Is it Awareness? Desire? Knowledge? Ability? Reinforcement? Each has a different intervention. And intervening at the wrong point is not just ineffective. It can make things worse.
Framework 3: Kotter’s 8 Steps - The Organisational View
John Kotter’s Leading Change (Harvard Business School Press, 1996) is the most-cited change management work in the world, and with good reason. Where Switch addresses psychology, and ADKAR addresses the individual, Kotter addresses the organisation - the structural, political, and cultural conditions that make or break change.
I will not walk through every step in detail, but I want to highlight the steps that are most relevant to Product Operations.
Step 1: Create a Sense of Urgency. Kotter estimates that if 75% of leadership does not share a sense of urgency, the transformation will fail. For Product Ops, this is the perennial challenge: making the case that operational improvement matters now, not “eventually.”
Step 2: Build a Guiding Coalition. This is not a project team; it is a powerful alliance of leaders who collectively carry the change forward.
“What I’ve seen be most successful is when product ops and leadership are really in lockstep. That’s when you can really see transformational change.” Amy Rohan
Without that coalition, Product Ops is pushing alone, and as Thor Mitchell also warned, without leadership backing, Product Ops will not survive the next round of cuts.
Step 4: Communicate the Vision. Kotter’s observation here is devastating in its simplicity: “The vision is undercommunicated by a factor of ten.” When you believe you have communicated it sufficiently, you are at 10% of what is needed. We know this intuitively in Product Operations - myself and Jake Brereton devoted an entire podcast episode AND book (The Product Ops Playbook) to the chronic under-communication of product teams - and yet we still underestimate it.
Step 5: Remove Barriers. Kotter identifies four typical barriers: organisational structures that contradict the vision, skills gaps, systems that reward old behaviour, and leaders who block the transformation. That last one is particularly relevant. Change fails when leadership exempts itself from the new ways of working.
Step 6: Generate Short-Term Wins. This is Kotter’s version of shrinking the change. Plan for visible, unambiguous successes within the first 6-12 months. In Product Ops, this might mean: before you overhaul the entire roadmap process, fix the one thing everyone complains about.
“Stop having that meeting for a month and see what happens. Then rebuild it around what you are missing.” Matt LeMay
Step 7: Sustain Acceleration (Do Not Declare Victory). Kotter argues that premature victory celebration is the single most common reason transformations fail. In Product Ops, this is the danger of the successful pilot: one team adopts the new process, leadership (at any level) declares success, attention moves elsewhere - and the other seven teams never change.
It is worth noting that Kotter’s model has been critiqued for its top-down assumptions and its sequential structure — and Kotter himself has evolved the framework in his later work Accelerate (2014), replacing sequential steps with parallel accelerators. For Product Operations, the specific steps matter less than the underlying insight: organisational change requires structural conditions (urgency, coalition, vision, barrier removal, wins, persistence) that no amount of individual effort can substitute for.
What Product Ops Has Learnt The Hard Way
Across 20+ episodes at the time of publication (close to 40 including pre-rebrand) and hundreds of practitioner conversations, some principles keep surfacing when it comes to change. They do not map neatly to any one framework; they are the accumulated, hard-won wisdom of people doing this work every day. Like every other guide, playbook, routine and advice created over the years for our profession.
1. Subtract before you add.
”You can’t just keep everything you have and throw agile on top of it. You can’t keep doing what you’ve always done and throw product ops on top of it. There are things that actually have to change, and some of those changes have to be subtractive.” Matt LeMay
Every new process adds cognitive load. If you are not removing something when you introduce something, you are part of the problem.
2. Baby steps, but with urgency.
Be pragmatic. Be empathetic. Take baby steps. But never compromise on the sense of urgency. Fo Neale May’s Minimum Viable Process. The baby step is not a concession. It is a strategy.
3. Every tool change is a behaviour change in disguise.
“You cannot introduce a new tool without introducing change.” Antonia Landi
The cost of a tool is not the subscription fee. It is the subscription fee plus the cost of the change that the tooling brings with it. Or, as Matt puts it: if you cannot ride a bicycle, you do not need a motorcycle that shoots lasers.
4. Resistance is data, not defiance.
“Everybody has some sort of transformation baggage. Maybe the resistance isn’t about you. Maybe it’s about something that happened to this person two companies ago.” Antonia Landi
This aligns superbly with my work translating the Four Tendencies into a Product Ops framework, specifically for Questioners who may appear to be blocking, but really want to know more to build confidence in the change.
5. Translate your work into business language.
I recall from an industry event, Marielle Velander ran a brilliant exercise: she asked practitioners to write a Product Ops metric on one side of an index card, then pass it to a peer who rewrote it as they would present it to a CEO. There are realities of business that are somewhat ‘icky’, but just a fact, and talking in the language of the c-suite, on the things they really care about, is definitely one of them.
6. Leadership backing is not optional.
When I have interviewed for roles over the years, and you get to ‘have you got any questions for us’… without fail, I always ask: “What is the appetite for change amongst leadership, and what backing do they provide?”
It is a unanimous feeling amongst Product Ops professionals, and for me a deal-breaker if that backing is not there, because I have worked where it is not there, and the role is virtually impossible to do well (more on that in another article!). Want proof:
“When product ops and leadership is really in lockstep, that’s when you can really see transformational change.” Amy Rohan
“Without leadership backing, product ops will not survive.” Thor Mitchell
“When you lose that executive support, your scope gets diminished, your potential impact gets diminished.” Marielle Velander
7. Role-model the change you are driving.
You cannot ask people to be vulnerable about their process struggles if you are not willing to be vulnerable about yours. Who better to illustrate this than Antonia to sign us off:
“A really good way of increasing psychological safety is to role-model it. Get out there and say, I made a mistake. We tested this out. It didn’t work. We’re going back to the drawing board.” Antonia Landi
Final Thoughts
I want to be honest about something: I did not study change management formally before I got into Product Operations. I suspect most of us did not. We learned it the hard way, through failed rollouts, resistant stakeholders, and the slow, humbling realisation that having the right answer is not the same as getting the right outcome.
The frameworks in this article are not mine. What I have tried to do is connect their research to the specific context of Product Operations: a discipline where, as I keep banging the drum on, so much of what we do is fundamentally about people, not process.
Change management is not a nice-to-have skill for Product Operations professionals. It is (a large part of) the job. And the sooner we name it, study it, and get serious about it, the better we will be at the work that matters most.
The next time a PM pushes back on your new process, or a team silently ignores your template, or a stakeholder nods along and then does nothing: don’t escalate, don’t get frustrated, don’t redesign the process - take a moment to ask: where is the Elephant? Where is the Rider? What does the Path look like? Where in ADKAR is this person stuck? And do I have the organisational conditions to make this change stick?
The answer will almost certainly change your approach.
Graham
If you have not read it yet, take 15 minutes to read my adaptation of The Four Tendencies to Product Ops, a perfect companion for this change management theme.
References & Further Reading:
Heath, C. and Heath, D. (2010). Switch: How to Change Things When Change Is Hard.
Switch Framework one-pager: heathbrothers.com/download/switch-framework.pdf
Hiatt, J. (2006). ADKAR: A Model for Change in Business, Government and Our Community.
Prosci ADKAR methodology: prosci.com/methodology/adkar
Prosci correlation research (88% success with excellent change management): prosci.com/blog/the-correlation-between-change-management-and-project-success
Kotter, J. P. (1996). Leading Change.
Kotter, J. P. (1995). “Leading Change: Why Transformation Efforts Fail.” Harvard Business Review, 73(2), 59-67. hbr.org/1995/05/leading-change-why-transformation-efforts-fail-2
Kotter, J. P. (2014). Accelerate: Building Strategic Agility for a Faster-Moving World. Harvard Business Review Press.
Kotter Inc. 8-Steps methodology: kotterinc.com/methodology/8-steps/
Product Opscast Podcast episodes referenced:
E1 (Cindy Camacho), E2 (Fo Neale May), E4 (Matt LeMay), E5 (Amy Rohan), E6 (Malte Scholz), E8 (Justin Woods), E9 (Jake Brereton), E10 (Thor Mitchell), E11 (Pippa Topp), E13 (Nesrine Changuel), E15 (Marielle Velander), E17 (Stephanie Leue). These and all episodes are available here: