Why Your Product Managers Resist Change (And What You Can Do About It)
Applying Gretchen Rubin’s Four Tendencies Framework to Product Operations
The common scenario for Product Ops professionals: You are proposing a change to the teams. The same change, communicated in the same way, but it lands completely differently depending on who you are talking to.
One Product Manager embraces a new process immediately and has it running by the end of the week. Another asks seventeen follow-up questions before they will even consider it. A third nods along agreeably but never quite gets around to implementing it. And a fourth seems to resist it purely because you asked them to do it.
This is not a failing of your communication, your process design, or your change management skills, although we can always improve those. It is, at least in part, a fundamental difference in how people respond to expectations.
I was recently made aware of Gretchen Rubin’s Four Tendencies framework, and right away, I could not believe just how accurate and applicable to our change management processes in Product Ops (and I suspect elsewhere, too). I’ve been deep-diving on this ever since…
The Four Tendencies
Gretchen Rubin is a bestselling author and researcher focused on happiness, habits, and human nature. In her 2017 book The Four Tendencies, she presents a personality framework built around a deceptively simple question: “How do I respond to expectations?”
Gretchen identifies two types of expectations we all face:
Outer expectations: deadlines, requests from colleagues, commitments to others
Inner expectations: personal goals, New Year’s resolutions, things we want to do for ourselves
How we respond to these two types of expectation determines our “Tendency.” According to the framework, everyone falls into one of four categories:
Upholders respond readily to both outer and inner expectations
Questioners question all expectations and only meet them if they believe they are justified
Obligers meet outer expectations but struggle with inner ones
Rebels resist all expectations, outer and inner alike
“To persuade someone to follow a certain course, remember: Upholders want to know what should be done. Questioners want justifications. Obligers need accountability. Rebels want freedom to do something their own way.”
— Gretchen Rubin, The Four Tendencies
It is worth noting, and Gretchen herself emphasises this, that you cannot identify someone’s Tendency simply by observing their actions. You need to understand why they are acting that way. A Questioner might refuse to meet a deadline because they think it does not make sense. A Rebel might refuse the same deadline because they want to demonstrate that nobody can tell them what to do. Same behaviour, very different motivations.
More than 3 million people have taken Gretchen’s free quiz to identify their Tendency (available at gretchenrubin.com/quiz/the-four-tendencies-quiz), and the framework has been widely applied in workplaces, healthcare, education, and personal development.
So why does this matter for Product Ops?
Why This Matters for Product Operations
Product Operations is, fundamentally, a people discipline. This is now my go-to answer whenever someone asks. In fact, I’m going to quote myself on this!
“Product Operations is, fundimentally, a people discipline”
— Graham Reed, ProductOpsConfidential.com
Yes, we work with tools, data, and processes, but the core of what we do is enabling others. Enabling product teams to work more effectively. Facilitating collaboration. Driving improvements. Achieving business goals.
Driving improvements is where things get interesting. Because improvements, by definition, mean change. And change means asking people to do something differently, and realistically build new habits in doing that new thing well.
Every time we roll out a new process, introduce a tool, refine a workflow, or adjust how teams communicate, we are setting an expectation. And how the people around us respond to that expectation is shaped, at least in part, by their Tendency.
Understanding the Four Tendencies doesn’t give us all the answers, but it does give us a lens through which to better understand why our colleagues react the way they do and, crucially, how we might adapt our approach accordingly.
Let’s look at each Tendency in turn, how it might show up in a Product Manager you work with, and how you, as a Product Ops professional, can work with it (them) rather than against it (them).
The Upholder
“What should be done?”
The Framework:
According to the framework, Upholders respond readily to both outer and inner expectations. They are self-starters, self-motivated, conscientious, and reliable. They thrive on clarity and structure. Their key strategy for habit change is the Strategy of Scheduling — give them a clear plan, and they will execute it.
Gretchen identifies their likely strengths as being thorough, eager to understand and meet expectations, and self-directed. Their potential weaknesses include rigidity, defensiveness when criticised, impatience with others who need reminders or supervision, and difficulty delegating because they suspect others are not as dependable.
She notes: “They’re self-directed, so they meet deadlines and run projects without much supervision. They’re eager to meet expectations (rules, regulations, performance targets) and may become uneasy when it’s not clear what’s expected.”
How This Shows Up in a Product Manager:
The Upholder PM is, in many ways, the dream stakeholder for Product Ops. Announce a new process? They adopt it. Set a deadline for roadmap submissions? Theirs is in early. Introduce a new tool? They have already watched the tutorial.
But there are pitfalls. Upholder PMs may become frustrated, even resentful, when their peers do not meet the same expectations they do. They can become the “process police” (rather ironic given we in Product Ops can be tarred with this brush if not careful!), holding others to standards that were perhaps intended as guidelines. They may resist changes to processes they have already adopted because they have invested effort in making the current system work. And they can become defensive if you suggest that something they have been doing diligently is no longer the best approach.
You might also notice that Upholder PMs can struggle with ambiguity. If a new initiative is not clearly defined, if you say “we would like teams to start thinking about X” without specifying exactly what that looks like, they may either struggle or fill in the blanks themselves in ways you did not intend.
The Product Ops Approach:
Be specific. When introducing a change, give Upholders clear expectations, timelines, and definitions. They want to know exactly what good looks like, or even how they might be measured.
Explain when expectations change, and why. Do not just announce a new process, acknowledge the old one and explain why the shift is happening. Upholders have invested in the previous way of doing things and need to understand that the ground has moved.
Use them as early adopters and champions. Upholders can be powerful allies in driving adoption across a team. If you can get them on board early, they will often model the behaviour you want others to follow. They will often appreciate being part of the journey, particularly when iterating on a process, and getting themselves embedded quickly.
Be careful with feedback. Gretchen notes that Upholders “may become very angry or defensive when you suggest that they’ve dropped the ball or done something wrong.” Frame feedback around the process or the outcome, not the person. Realistically, this should be a given anyway!
Do not assume they will flex easily. If you need a temporary workaround or a just-for-now approach, Upholders may struggle with the ambiguity. Be clear about what is permanent and what is interim.
The Questioner
“But why?”
The Framework:
Gretchen describes Questioners as people who question all expectations and will meet them only if they conclude that they are justified. They essentially convert all expectations into inner expectations — they will comply, but only once convinced.
Their strengths, according to Gretchen, include being data-driven, interested in creating efficient systems, and willing to play devil’s advocate. Their potential weaknesses include analysis paralysis, impatience with what they see as others’ complacency, and what Gretchen calls “crackpot potential” - the risk of going down rabbit holes of their own reasoning and arriving at conclusions that are disconnected from the wider group. I’ll hold my hand up and admit this is me on more than one occasion!
Critically, Gretchen observes that Questioners “follow an ‘authority’ only if they respect that person” and that “because of their persistent questioning, others may view them as uncooperative, obstructionist, disrespectful, or ‘not a team player.’” She also notes that Questioners often dislike being questioned themselves. They consider their own actions carefully and find it tiresome to be asked to justify their decisions.
How This Shows Up in a Product Manager:
If you have ever rolled out a new process and had a PM immediately respond with “Why are we doing this?” or “What problem does this actually solve?” then congratulations, you have probably met a Questioner. And my initial reaction: total pain in the SharePoint ass, I said ass…
But Questioner PMs are not being difficult for the sake of it… most of the time. They genuinely need to understand the rationale before they will commit. They are the PM who will push back on a quarterly review template by asking, “What decision does this information actually inform?” They will challenge a new tool adoption by asking for data on how the current tool is failing. They will not adopt a process just because “this is what the leadership team agreed”; they need to believe, independently, that it makes sense.
This can be enormously valuable. Questioner PMs will find the holes in your process before anyone else does. They will identify inefficiencies, challenge assumptions, and push you to make better-justified decisions. But it can also be exhausting, particularly when you are trying to drive change at pace, and one person insists on relitigating the rationale at every step. You may also find that if they don’t get a satisfactory answer, the same conversation will happen again, and again. The same rollout discussions, the same query on deadlines, the same pushback on writing x report.
You may also find that Questioner PMs resist anything that feels arbitrary. If you set a deadline that does not have a clear reason behind it. Roadmaps are due by the 15th. Why the 15th? They will push back. If a process has steps that exist for historical reasons but no current justification, they will call it out.
The Product Ops Approach:
Lead with the why. Always. Before explaining what is changing, explain the problem you are solving. Provide context, data, and rationale. “We are introducing this because X is happening, the data shows Y, and this approach addresses it by Z.”
Do not rely on authority alone. The framework is explicit: managers should not use “Because I say so” or “This is how we’ve always done it” with Questioners. Or let’s face it, with anyone. This isn’t the 80s! If your justification for a change is “the VP wants it,” a Questioner PM will not be moved unless they also understand why the VP wants it and why it makes sense.
Invite them into the design process. Questioners often make excellent collaborators in process design because they will stress-test your thinking. If you can, involve them early. “We are considering this approach, and I would value your critical eye on it”. They are far more likely to champion the outcome.
Set boundaries on the questioning. This is the tricky part. There is a point where questioning becomes a blocker. Gretchen acknowledges the risk of analysis paralysis in Questioners. As a Product Ops professional, you may sometimes need to say: “I hear your questions, and they are valid. Here is the information I have. We are moving forward with this approach, and we will review in X weeks based on these metrics.” Give them the data, set the review point, and move. There is a bonus here (depending on how you look at it) - they will keep you on your toes to track your success metrics!
Respect their expertise. Questioners resist being questioned themselves. If a Questioner PM has made a decision about their own domain, approach any challenge to that decision with evidence and respect, not assumption.
The Obliger
“You can count on me — and I’m counting on you to count on me.”
The Framework:
Obligers are, according to the research, the largest Tendency group. They readily meet outer expectations, commitments to other people, deadlines set by others, and requests from colleagues, but struggle to meet expectations they impose on themselves. These are your Yes people.
Gretchen identifies Obligers’ strengths as being reliable, responsible, good team players, responsive leaders, and willing to go the extra mile. Their potential weaknesses include resentment about what is being asked of them, difficulty saying “no,” being exploitable, and, critically, the pattern Gretchen calls Obliger-rebellion.
As Gretchen writes: “They must have systems of external accountability in order to meet inner expectations.” In the workplace, she notes that Obligers “put a high value on meeting commitments to others and going the extra mile” but “may have trouble saying ‘no’ or setting limits on others’ demands.”
Obliger-rebellion deserves special attention. Gretchen describes it as what happens when an Obliger has “met, met, met, and met expectations, and then suddenly snaps.” Warning signs include acting out of character, seeming listless and apathetic, becoming resentful or curt, and withdrawing. When the rebellion tips over, it can be dramatic: refusing responsibilities, quitting, or making sudden announcements. Gretchen notes that this can seem to come out of nowhere to others, but it never does. The resentment was there, it just wasn’t visible.
How This Shows Up in a Product Manager:
The Obliger PM is the one who always says yes. New process? Sure, I’ll do it. Extra reporting? No problem. Can you take this on for the team? Of course. They are often the backbone of any adoption effort because they respond readily to what is asked of them.
But here is the thing: they are saying yes to you, and to their engineering lead, and to the design team, and to their stakeholders, and to the VP who wants a special update. They are meeting everyone’s outer expectations while their own priorities, their own professional development, and their own capacity planning may be quietly falling apart.
As Product Ops professionals, we sometimes inadvertently contribute to this problem. We are, by nature, creating expectations for others to meet. Every new process is an outer expectation. Every template, every review cadence, every reporting requirement. These are all things that Obligers will absorb without complaint, right up until the point where they cannot.
And when Obliger-rebellion hits, it can be alarming. The PM, who was always compliant, suddenly pushes back on everything. The PM who never missed a deadline starts missing them all. The PM who was your biggest advocate becomes your biggest critic — seemingly overnight.
I remind readers at this point I am not qualified in any of this, and even more so, not qualified in therapy or psychology…
The Product Ops Approach:
Build accountability structures, not just expectations. Obligers need external accountability to meet their own goals, but they also need protection from taking on too much. When introducing a new process, be explicit about what it replaces or what can be deprioritised. Do not just add, help them subtract. This is a great lesson for all changes, regardless of Tendency, and something to flag at the strategic level for the roadmap of changes you are putting in place too.
Watch for the warning signs. Gretchen’s list of Obliger-rebellion warning signs is worth keeping in mind: acting out of character, seeming listless, withdrawing, and becoming curt. If your most reliable PM suddenly starts dropping balls, this may not be a performance issue; it may be Obliger-rebellion. The correct response is not more pressure; it is a conversation.
Make it safe to say no. Obligers struggle with this. You can help by framing options rather than requests: “We have this new process, would it work better for your team to adopt it this sprint or next?” gives them agency without making them feel they are refusing. Work with them over time to ensure they know “Saying No” is not going to reflect badly on them at their next performance review!
Be mindful of cumulative load. Every process you introduce adds to the Obliger’s sense of obligation. Regularly audit what you are asking of people and be willing to retire or simplify things that are no longer delivering value.
Create external accountability for their own goals. If an Obliger PM wants to improve their discovery practice, for example, they may struggle to prioritise it because it is an inner expectation. You can help by creating light external structures - a monthly check-in, a peer learning group, a shared tracker - that give them the outer accountability they need.
The Rebel
“You can’t make me — and neither can I.”
The Framework:
Rebels are the smallest Tendency group, according to Gretchen, and they resist all expectations, both outer and inner. They want to act from a sense of choice, freedom, and authenticity. Their key strategy for change is the Strategy of Identity: they do things because of who they are, not because someone told them to.
Gretchen identifies their strengths as being independent-minded, able to think outside the box, and placing high value on freedom, choice, self-expression, and authenticity. Their weaknesses include defiance, unpredictability, and a spirit of resistance that can be triggered by even well-intentioned requests.
In the workplace, Rebels “don’t respond well to supervision, advice, reminders, or directions, and they resist routines, schedules, and repetitive tasks.” Gretchen recommends using a framework of information-consequence-choice: give them the information they need, explain the consequences of different paths, and let them choose.
Interestingly, she also observes that Rebels “may be easy to manipulate by using their spirit of resistance”. The classic “You probably can’t do this” approach, and if they are in a long-term work partnership, their partner is probably an Obliger.
How This Shows Up in a Product Manager:
The Rebel PM is the one who does things their own way - always. They may be brilliant at their job, deeply creative, and capable of extraordinary output. But the moment you tell them to do something, you have lost them.
Introduce a new template? The Rebel PM creates their own version, which, annoyingly, might actually be better than yours. Damn them, showing us up!
Set a cadence for roadmap reviews? They submit theirs when they feel like it, if at all. Roll out a standardised process? They find workarounds, exceptions, or simply ignore it. But this is not necessarily malicious. Rebel PMs often genuinely believe they are doing the right thing, and sometimes they are. Their resistance to conformity can lead to genuine innovation. But it can also make standardisation feel like pushing water uphill.
Often, too, these will be the PMs that crave autonomy, in any capacity, but usually in what they are product managing.
The challenge is compounded by the fact that direct requests tend to backfire. The more you push, the more they resist. Reminders, escalations, and gentle nudges are all read as attempts to control, and the Rebel spirit kicks in.
The Product Ops Approach:
Use information-consequence-choice. Gretchen’s framework is invaluable here. Instead of “You need to use this template,” try: “Here is the template [information]. Teams that use it report spending 30% less time on roadmap reviews [consequence]. You are welcome to use it, adapt it, or propose an alternative that achieves the same outcome [choice].” Let them decide.
Appeal to identity, not obligation. Rebels respond to who they want to be, not what they are told to do. “As someone who cares about shipping great products...” is more effective than “The process requires you to...”
Give them ownership. If a Rebel PM wants to do things differently, channel that energy. “I can see this process does not work for you as-is. Would you be willing to design an alternative that meets these core criteria?” You may end up with something better (again, damn them!), and you definitely end up with buy-in.
Avoid surveillance and micromanagement. Gretchen is clear that Rebels do not respond well to supervision, reminders, or check-ins. If you have agreed on an outcome, trust them to get there. Follow up on results, not activity.
Pick your battles. Not every Rebel deviation is a problem. If a Rebel PM achieves the same outcome through a different route, consider whether standardisation in this case is truly necessary or whether it is just tidier. I know I have mellowed a lot in the past year or so on how exactly we standardise on some ways of working, favouring the outcome more than the journey. Quarterly planning is a great example - so long as your roadmap is done by x date and your stakeholders are (genuinely) aligned… everything else is a guideline.
Bringing It All Together For Us Product Ops Professionals
The Four Tendencies framework is not a silver bullet - nothing is when it comes to working with others. It does not capture every nuance of human personality, and Gretchen herself acknowledges that other traits — ambition, empathy, risk tolerance — shape how each Tendency expresses itself. A high-empathy Rebel looks very different from a low-empathy one. An ambitious Obliger and a contented Obliger will respond to pressure in different ways.
But as a lens for Product Operations, I think it is genuinely useful — and here is why.
So much of what we do involves setting expectations. We design processes (expectations for how work gets done). We create templates (expectations for what information gets captured). We set cadences (expectations for when things happen). We drive adoption (expectations for which tools get used). And we champion improvements (expectations for how things change).
Understanding that people respond to these expectations in fundamentally different ways, and that those differences are not deficiencies, is, I think, a meaningful step toward being better at what we do.
And I am sure we all know this. We can probably identify 2 or 3, or maybe even all 4, tendencies in our teams, and deep down we know roughly who we go to, with what change, at what stage - if at all - and how we present this to them. We know who will be an early adopter, and we know who to NOT surprise with a new process in a team meeting.
Here are some practical principles I take from this:
1. One-size-fits-all change management is a myth.
If you announce a change the same way to everyone and expect uniform adoption, you will be disappointed. Upholders will adopt immediately. Questioners will challenge the rationale. Obligers will agree but may be silently overwhelmed. Rebels will resist on principle. Tailoring your approach, even slightly, to account for these differences can dramatically improve outcomes.
2. Resistance is information, not insubordination.
When a PM pushes back on a process, our instinct might be to double down or escalate. But the Four Tendencies suggest that resistance often has a reason, and understanding that reason (Is this a Questioner who needs more data? A Rebel who needs more autonomy? An Obliger in rebellion?) leads to far more productive conversations.
3. The people who say yes most easily may need the most protection.
Obligers are the largest group and the most likely to comply with every new expectation we set. That compliance can mask the fact that they are drowning. As Product Ops professionals, we have a responsibility to think about the cumulative impact of what we ask of people and to make space for them to push back.
4. Your own Tendency shapes your approach too.
This is easy to forget. If you are an Upholder, you may have little patience for people who do not just do what is expected. If you are a Questioner, you might over-justify changes to the point where people switch off. If you are an Obliger, you might take on too much of the change burden yourself. And if you are a Rebel... well, you are probably already doing Product Ops your own way.
Knowing your own Tendency and how it might create blind spots in how you drive change is just as important as understanding the Tendencies of those around you.
⚠️ Warnings ⚠️
I want to be clear: I am not a psychologist, and the Four Tendencies is Gretchen’s framework, not mine. What I have tried to do here is take her research and thinking and apply it to the specific context of Product Operations, a discipline where understanding people, and how they respond to the changes we drive, is arguably the most important skill we have.
I am very cautious too, and urge anyone reading this to be cautious too, about labelling others or assigning definitions based on this framework. This is about possible approaches and common traits to look for in others to help you navigate conversations. People will not solely be one of the four groups, and possibly may meander through several over time, particularly as they mature in their careers. When I review the descriptions, I can absolutely see myself in one group earlier in my career (before pragmatism was beaten into me!).
Indeed, in my personal experience, the tendencies, or the strength of those tendencies, you see as you interact with an individual, can change depending on the strength of your relationship with them, the trust they have in you. And so, being vigilant of the reactions and responses you get regularly will help you continually craft that relationship.
I am also reminded about other personality and learning frameworks, types and fads over the years that ultimately were proven to be incorrect. One in particular, you may remember if you are as old as I, was on learning styles: visual, audio, kinesthetic (VAK), which was widely shared and pushed in education (at least in parts of the UK), and yet found to have no real evidence of improved learning. I am not suggesting this is the case - in fact, so much of this aligns with what I have experienced in my time in Product Operations. But the warning here is to use this as suggested guidance, and find your own path as you explore this.
Final Thoughts
If you have not read up on The Four Tendencies, I would wholeheartedly recommend it. And if you want a quick starting point, Gretchen’s Nutshell Guide and her Four Tendencies at Work one-pager (both available at gretchenrubin.com) are excellent summaries.
The next time you are rolling out a change and one of your PMs pushes back, or silently absorbs it, or immediately adopts it, or ignores it entirely. Take a moment to consider not just what they are doing, but why. The answer might change your entire approach.
But, use this as one resource amongst many in your toolkit, and avoid assigning permanent (or any) labels to your peers.
In my continued exploration of this fascinating topic, I’m keen to hear from anyone with experiences or thoughts - do they recognise these traits in others, how have you approached working with them, does anything seem off? I’d love for this to become a battle-tested blueprint for the Product Ops profession.
Graham
I’d like to specifically give a shoutout to my dear friend Caroline Clark for her feedback and insights on this topic prior to publication.
References & Further Reading:
Rubin, G. (2017). The Four Tendencies: The Indispensable Personality Profiles That Reveal How to Make Your Life Better (and Other People’s Lives Better, Too). Harmony Books.
Rubin, G. “Getting Started: The Four Tendencies.” gretchenrubin.com/four-tendencies/
Rubin, G. “The Four Tendencies Nutshell Guide” [PDF]. gretchenrubin.com/wp-content/uploads/2022/09/The-Four-Tendencies-Nutshell-Guide.pdf
Rubin, G. “The Four Tendencies at Work” [PDF]. gretchenrubin.com/resource/the-four-tendencies-at-work/
Rubin, G. “What is Obliger-rebellion? Signs, causes, and how to handle it.” gretchenrubin.com/articles/identifying-obliger-rebellion/
Rubin, G. “What’s the Right Mix of the Four Tendencies in a Team?” gretchenrubin.com/articles/whats-the-right-mix-of-the-four-tendencies-in-a-team/