For some reason, it seems to be a bit of a triggering word these days inside and outside of product divisions. Sometimes we don’t do enough, and it gets blamed for bad decisions. Sometimes we do too much, and it gets blamed for making no decisions. And sometimes it gets used to validate an existing idea, and gets blamed when the research doesn’t support the crusade.

And then there is typically a big gap in understanding how research actually works, the mechanics and logistics of spinning up interviews, surveys, tests, and analysis.

I’m gonna say it. Research itself is not really the hard part. Interview techniques are well documented. Frameworks and textbooks on how to recruit users, ask non-leading questions, or run a decent usability test are sitting on shelves (virtual and IRL!) for anyone willing to crack them open.

What kills most research practices is everything that surrounds the research. Who knew to ask the question. Whether the findings reached the right room. Whether the answer arrived before someone in leadership had already quietly made the call. That is where good work quietly evaporates, and that is exactly where Julian Della Mattia has chosen to speak out.

Julian is the host of the Finders to Builders podcast, renowned user researcher, and author of Building the Research Engine; his codified version of years spent walking into companies where research barely existed and trying to leave behind something durable enough to outlast him.

Antonia and I recently chatted with Julian about his book and ResearchOps overall on the Product Opscast:

Best practice as a system, not a checklist

Write a good interview guide. Pick the right sample size. Validate before you build. That is Research 101, right? Do these and off you pop. But Julian asks a more useful question. What does it look like when research becomes a practice, not an activity that some keen designer holds together with personal heroics?

His answer is the CIC framework. Culture (do people here actually value evidence?), Infrastructure (do the systems exist to do the work?), Communication (do insights reach the people making decisions?). Every organisation is weak in at least one. Most are weak in two. These pillars stay stable across the entire book, and he uses them to walk readers through three stages of maturity (Build, Connect, Trust) without ever sounding like he has invented something nobody noticed before. It is best practice reframed as a system rather than a checklist. For anyone in Product Ops who has spent more time auditing process compliance than asking whether the process actually produced a better decision, this reframing alone is worth the price of the book.

And let’s pause on personal heroics for a moment, because this is where ops roles (Product, Research, Engineering, Design, Rev…) both uncover the fragility of businesses and create a robust solution that stops relying on individuals, who are fragile (sorry, I couldn’t find a better term!) and put in place independent systems. Heroes are created out of necessity, when things just needed to get done, when money was tight or speed was paramount. Nothing wrong with this, but it is not a strategy.

Strategic clarity through stages and gears

Julian frames research practice as a manual transmission with four gears (Interface, Feature, Product, Strategic) and is incredibly clear that the gear you can drive in depends on the political capital you have actually earned. At Stage 1 you stay in Interface and Feature work, because nobody has given you permission to touch existential questions yet. By Stage 3 you can shift up to Strategic, because by then the Engine has compounded enough trust to be allowed near the big decisions.

Strategic work is what you are building toward. Tactical work is what gets you there. The Engine, not the practitioner, decides when it is safe to shift up. That distinction is going to save a lot of careers from the trap of trying to be strategic in week one.

Tactical work often gets a rolled eye or a little sigh within the ops communities, and with good reason when professionals are permanently weighed down in the trenches of the tactical, the reactionary, sometimes the ‘busy’ work. But for most of us in teams of 1, or teams of few, the tactical is just necessary, particularly in the early weeks and months of tenure, almost exclusively, and then a mixture after that. And it is that work that earns the right, the political capital to do more, do bigger.

Minimum Viable Rigor and the Decision + 20 percent rule

Two ideas I will steal immediately. The first, credited to Carl Pearson, is Minimum Viable Rigor. Your research rigour should match the risk of the decision it informs. A quick scrappy test is fine for an icon choice. A market entry call needs evidence that holds up to scrutiny. Julian uses this to dismantle the false binary between proper research and good enough research, and lands a perfect line about not killing a fly with a cannon (as much as I now want to try this!).

The second is what he calls the Decision + 20 percent rule. When you scope a study, the decision it serves is your 100 percent. You deliver on that. But if you leave a small aperture, one or two extra questions in an interview, one extra thing you watch for during analysis, you will almost always uncover something nobody asked about but everybody needs. That is the difference between answering questions and raising the questions worth answering.

The Verdict

Building the Research Engine is practical without being prescriptive. Opinionated without being dogmatic. Structured without ever feeling rigid. Which is the sweet spot for Ops roles in the modern workplace. The focus is not on doing the research, but what comes next to ensure the findings are shared where they can provide the most (or any) value.

The most expensive thing in your organisation is not the headcount or the tooling, but the assumptions you keep building on without ever testing. This is the leadership hook. For ops folks, read this book twice. The first time as a researcher. The second time as the architect of a system the company will one day quietly forget you built, which is, after all, the point. And the norm for us ops folks. Us heroes. And yet, the best research practices do not look like heroics. They look like infrastructure. An engine.

Great work Julian!

Practical Applications for Product Ops

Product Operations spends a lot of time talking about insights, data, and decisions (Just listen to Antonia on our podcasts!) and not nearly enough time talking about the machinery that turns one into the others. Julian is not writing for us specifically. He is writing for designers, PMs, founders, and first researchers. But almost every chapter contains a sentence that could have been lifted out of a Product Ops job description. Build the systems. Connect the signals. Become the organisational sense maker.

By Stage 3 of his model, the researcher is no longer running studies. They are the playmaker who sees the whole field. They connect analytics, support tickets, sales calls, NPS, and qualitative work into a coherent picture nobody else is positioned to see. That is, line for line, the senior Product Operations job most of us are quietly grow into.

The reality is, many businesses are not mature enough to have built/be building ResearchOps roles just yet, and so it is likely much of this engine building falls on us in Product Ops… and so ta daa, this IS for us. And is a great playbook to help extend our skills to an area not typically in our wheelhouse.

Graham

Share Product Ops Confidential

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.”

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:

The Product Opscast

Graham focuses on "Data In" workflows across platforms like Jira, Miro, and Slack to manage a single source of truth while keeping the right tools in the right places for teams.

Josh leans into "Data Out" solutions implemented at Airbnb, such as automated process deck generation, plain-English conversational AI chatbots for live base queries, and an automated PRD scanner that directly writes impact assessments back into your base.

Whether you are a builder, operator, or power user looking to optimise capacity planning and scale your operational insights, this will inspire you in the art of the possible.

Watch Now

• When everyone can build 10x faster, are we actually going anywhere, or just going?

• Where does a tool genuinely help a team decide, rather than create more for them to decide about?

• And when the AI hoovers the whole organisation’s data into one place, does that make us clearer, or just busier?

Side Note: getting to a conference about humans and machines collaborating meant crossing a city half shut down by tube strikes. A very human, very analogue act of resistance to a change people did not choose. I am not sure anyone on stage clocked the irony, but it turned out to be the truest thing I saw all day. Hold that thought…

AI scaled the creation. It has not scaled the decision-making.

Founder and CEO Andrey Khusid opened on the gap he thinks is the single biggest opportunity in business right now: individuals can now be 10x with AI, while their companies are still stuck at 1x. The organisation simply cannot absorb the speed of its own people. He has a name for the friction, too, the “collaboration fracture”: we now juggle three kinds of collaboration (human to human, human to agent, and agent to agent) with no shared place where all three happen and stay visible to everyone.

CPTO Jeff Chow took the idea up a level, pitching the canvas as the “decisioning layer” for the agentic era. One slide framed the ambition as a flip, from 80% doing and 20% thinking toward 80% thinking and 20% doing. Lovely in theory. But buried in the same section was the sharpest line of the day: AI has scaled creation, and it has scaled output, but it has not scaled decisions/decision-making.

Sit with that as a Product Ops person, because it is our entire remit in a single sentence. We are not in the creation business. We are in the alignment, prioritisation and decision quality business. If the rest of the company is now producing ten times the artefacts and the machinery for choosing between them has not budged, the bottleneck does not vanish. It lands on us, and it gets heavier. More decisions made faster is not remotely the same thing as better decisions. Faster building mostly just buys you the capacity for faster bad calls.

This absolutely mirrors the same sentiment from MXP (Mixpanel) two weeks prior.

A shared surface is a genuinely good idea. A new source of truth is not.

The thing everyone came to see was the agentic canvas itself. Mark Boyes-Smith demoed voice Sidekicks (conversational agents you brief and then literally talk to) and Flows: visual, multi-step AI workflows that live on the board, that the whole team can see and run, and that reach out into your other tools. One Flow pulled data from external systems (Jira was the example), shaped it into something like a roadmap, and posted the update straight back into Slack. There was plenty more in this vein too: Code to Prototype turning a description into a working mockup on the board, Mermaid and Markdown support, connectors into Claude, ChatGPT and Copilot so context is not trapped in one tool.

Here is the part I genuinely liked. Most automation today is invisible, owned by one person, and dies quietly the moment that person leaves. A workflow that is multiplayer, visible, and built to be handed off is exactly the thing Product Ops spends its life trying to create and almost never gets the time to. The direction of travel is sensible: bring the intelligence to where people already work, rather than dragging them into yet another interface. If Flows lowers that bar, I am interested.

But…

Here is the part that gave me pause. Underneath Flows sits a quieter ambition: bring all your data onto the canvas. Pull from Jira, from your analytics, from your spreadsheets, and build your backlog right there on the board. My margin note was blunt: why Miro for this, over an actual source of truth?

It is the same instinct behind everything Antonia wrote in Stop Buying Tools You Can’t Defend:

A whiteboard is, by design, a place for thinking. It is loose, expressive, and deliberately low-fidelity. The moment you treat it as a system of record, you have lifted your data out of the thing that governs it, and signed up for drift, duplication and the slow rot of “which version is right?” Product Ops spends years trying to shrink the number of competing truths in a business. I am wary of anything whose growth depends on adding one more.

And, the Miro canvas is unstructured data. Taking tasks that ladder up into epics and reports and initiatives and OKRs and sliced and diced and analysed, out of the structure and into text boxes… I suddenly got a cold sweat thinking about unpicking this.

I will also gently confess that the voice demo lost me. Talking to a Sidekick looked slick, but I could not work out what it solves that typing does not, and the claim that vaguer, more general instructions somehow produce sharper output went by unexplained. Happy to be shown. Genuinely.

When building gets cheap, thinking gets expensive.

The theme that kept surfacing, on stage and in the networking spaces, was that the constraint has moved. When building is no longer the slow part, the quality of thinking becomes the slow part. Daniel Hulme, WPP’s Chief AI Officer, put a number on the backdrop that stuck with me: 78% of employees are already using AI at work, most of them with no sanctioned tools and no training. The technology is already in the building. What is missing is the judgment to aim it.

That is a people problem, not a tooling one, and it is exactly where I kept wishing the day had gone deeper. Change management earned a passing mention, and then the conversation hurried back to features, which is precisely backwards. And, look, this was the Miro expo, to show off their features for us to drool over and spend more money. I get it. And I cannot deny, the location, setup, a staggering number of Miro staff, the pomp and high-fiving on/off stage - was all very impressive! But I’m in the business of practical answers to the real problems I have, or am going to have.

AI hands us focus and time for deeper thinking, but only if we actually use it that way, and there is a real risk of decision fatigue when suddenly every decision feels possible. Without clear principles for which decisions even matter, more capacity to decide just manufactures more noise.

Martin Eriksson’s Decision Stack, which I reviewed recently, is a great tool here.

So did I find what I went for?

I went looking for the new tools, and to get inspiration for how I could be better using the tool overall with my teams - we are fairly basic whiteboard users to date. So, for our money, what can we get out of it.

But I came out with some new truths about the AI-obsessed SaaS industry… chief amongst them is that the traditional lanes platforms have remained in are now blurring, which is fantastic news for their CEOs, sales teams and shareholders, but adding much more confusion than ever before to those tasked with choosing the best products for the right purposes, clouded by the vibe-coding mantra ‘It can be whatever you want it to be’ that is yet to be truely proven, and even less sustainable.

I also got AI-generated, machine-printed, human-handed-out stickers. Truly human-to-tech collaboration.

Back with my Product Ops hat back on, what does this mean for us?

Tools have never been top of the priority list for Product Ops. In fact, we should always be making it one of the last things we change or promote. But we’re clearly in a world where tools are getting a lot of attention again, doing much more than ever before, handing over much of our busy work to them. There is excitement to be trying new tools again, whether home-made or off the shelf, with encouragement to be ‘trying them out’ all across the business landscape.

And yet, the responsibility to implement, maintain and scale those platforms still remains with the chosen few to ensure they are maintainable, scalable, secure, robust - all the things that drain the excitement from water-cooler conversations, and yet make them viable. And when we have platforms land-grabbing to replace a greater number of competitors or claim to be the right single source of truth, it makes the time we spend evaluating those potential solutions that much more vital. I’m already contending with so many vibe-coded solutions that sit as a support structure to core business needs. I built a good number of them!

And I am sure there will be those reading who are thinking ‘Lighten up, Graham, let teams explore, use whatever tools get the job done and ship faster!’. Please get in touch or leave a comment to dive into this more… because every fibre in my being says that thinking leads to some very expensive dead ends to unpick. I’ve seen it, I’ve been there, and it is really not pretty.

It is not just the technical unpicking either, but the behaviours and habits your teams have built up too that need unpicking, and if you have read much of my writing, you know change management is a whole new scale of problem to tackle.

So, your research evaluation and scrutiny of tools is as important as ever, as is your focus on the landscape of your business in 12 months+ living with your new relationship, not just the next few weeks honeymooning with the shiny new toys.

BUT, I want to balance this before I finish. I like Miro, its a great tool to make your ideas visual, collaborative, and at its heart, the new tools shown off at the show were in this vein still. The technology is impressive, and I love a shiny new toy as much as anyone. So I will be exploring Sidekicks and Flows. I have a really great Claude-powered sync with Airtable going great guns. And the Widget Creator, sitting right next to those Claude connectors, might just be the no-code home I have been hunting for to host the little internal tools my team keeps building.

I just struggle to get past this thought: Miro Canvas 26 sold the canvas as the cure. The longer I sat with it, the more I think the problem was never the canvas.

Graham

Did you attend the show? What did you come away with? Tell me your thoughts to all this.

Share Product Ops Confidential

As a thank you, and to tie in with our 21st Product Opscast episode, all about research, we’re giving away 1 copy of The Research Engine by our guest Julian Della Mattia.

To be entered into the draw for this, complete this survey by Friday 12th June (12:00 UK time) and include your name and LinkedIn Profile URL (used ONLY for the purposes of contacting you for the draw), and tell us what was your biggest takeaway from Julian’s episode of the Product Opscast - watch is here

You must be a subscriber (free or paid) to be included in the competition draw - so why not subscribe now!

Subscribe now

Graham & Antonia thank you for your continued support and for the feedback.
Good Luck!

Complete The Survey Now

Good research takes time, but quality matters

Highlights

• The Importance of Building Research Practices

• Navigating Research Challenges in Organisations

• The Role of AI in Research

• Research as a Validation Tool

• The Dynamics of Research and Decision Making

• Navigating Research Challenges in Product Management

• Building Effective Research Practices

• Creating a Research Flywheel

• Maximising Research Outputs

• Cultural Shifts in Research Practices

Check out more of what Julian does, and get his book now:

Julian's Website

Competition Time!
For the chance to win a copy Julian’s book, Building the Research Engine, complete our Product Ops Confidential Subscriber Survey, which includes telling us your biggest takeaway from this episode! Complete this survey by Friday 12th June (12:00 UK time). Even if you don’t want to enter the draw, please complete the survey and help us improve both the podcast and newsletter!

Complete The Survey Now

Watch here on Substack, or listen on your favourite platform. We’re on YouTube, Spotify and Apple Podcasts

What should the team discuss next? Share your thoughts about a future topic you love them to dive into… maybe you are even that guest to talk to.

Share Product Ops Confidential

Who:

When: Tuesday, June 2nd

Where: London

If you are going to Miro Canvas in London, I (Graham) will be there too. Say hi, let’s chat! I’m there to listen, learn, and continue to find out more about the future of tech in an ever-increasing AI world, and what this means for Product Ops.

Find out more

Airtable UK Crew: London IRL001

Who:

When: Tuesday, June 2nd (evening)

Where: London

Later that same day, I (Graham) will dart across London to host the first Airtable IRL London Community Meetup.

This is an informal evening for Airtable Builders in London to mix, eat, drink, and talk shop — followed by a focused group session where the real magic happens.

​After an open networking hour, we’ll move into Lightning Strikes: up to four 15-minute sessions where attendees share something they’re building, a challenge they’re wrestling with, or an idea they want to pressure-test. The group responds — questions, experiences, riffs, half-baked solutions welcome. No slides required, no polish expected.

​Topics and speakers are submitted on the night, so bring whatever’s on your mind.

If you are an Airtable Builder, new or veteran, this will be so much fun!

Register here

How do we build data foundations for strategic insight?

How do we use AI to amplify judgment without outsourcing it?

How do we ensure customer voice genuinely informs decisions?

Refresh your memory here:

Honestly, I’m not sure I came away with neat answers. But I came back convinced the whole industry is asking the same things.

The speed problem nobody is ready for.

Mixpanel CEO Jen Taylor opened with both palpable enthusiasm and a particular stat that landed:

42% of engineering teams now use AI-assisted coding, up from 6% in 2023, predicted to hit 65% by 2027.

But also,

…faster building means the capacity for faster bad decisions.

This, above all, was the theme I was sensing from my conversations with fellow attendees.

Mixpanel AI, talked up a lot here, is a shift from product analytics to product intelligence - always-on AI that recommends what to do next, not just what happened. Teams moving 10x faster need context 10x faster too. The bottleneck is not dashboards; it is getting the right context to the right people before the decision window closes.

FaceIT’s Maria Laura Scuri’s brilliant session highlighted another important fact: democratising data is essential, but you still need people who know the data well enough to verify what AI recommends. Several organisations shared practical examples; using AI for compliance validation, checking documentation, branding consistency and regulatory wording. Useful, tangible, but still requiring human oversight. I know, because I’m building the same things!

And MCPs are still a hot topic. Vendor after vendor is building MCP integrations so their data feeds directly into AI tools like Claude or ChatGPT. The direction is clear: bring intelligence to where you work, not force people into another interface.

AI is not replacing judgment. It is exposing who has it

The exec roundtable I joined (honoured!) surfaced something I’m hearing too often, too:

PMs and designers are becoming the new bottlenecks, not engineers.

When implementation speed is no longer the constraint, the quality of thinking becomes the constraint.

This connects to a broader theme of role blurring between PMs, designers and engineers, though I wonder how prevalent this really is beyond the ‘top 1%’ of tech companies right now.

AI brings focus and time back to humans for deeper thinking, but only if they use it well. There is a real risk of decision fatigue when AI makes more decisions feel possible. Martin Eriksson’s Decision Stack framework feels relevant here; without clear principles guiding which decisions matter, more capacity to decide just creates more noise.

Re-read my review of the Decision Stack here:

So did I get my answers?

Not exactly. But a room of senior product leaders wrestling with the same questions - and honest about not having answers - tells me the sector is more aligned than it appears.

Few answers. But the right questions. And that is enough to build from.

And what does this mean for Product Ops, dear gentle readers?

(I’ve just won a bet with my wife that I could get this phrase from her favourite TV program into an article - answers on a postcard if you know it too!)

That we are in a prime position to enable these rapidly changing functions that themselves do not exactly know anymore how to define themselves. The tools are there for sure, but this is not about tooling and, once again, for Product Ops, it never was, and overall, my conversations with product leaders at MXP highlighted this like… well… a big yellow highlighter. This is about how people react to changes they are not in full control of. This is how we enable the right decision-making backed by the right data at the right time. AI is making this fast and fluid, but humans are anything but this, so more than ever, it is a reminder to be making the right decisions, not fast decisions.

Graham

Share Product Ops Confidential

There’s a conversation I’ve had more times than I can count, and it usually goes something like this: An organisation wants to adopt a new tool. Someone has already done the research, maybe started a trial or two. There’s palpable enthusiasm - possibly a dedicated Slack channel. And somewhere in the middle of all that momentum, they ask me what I think.

My first question is always the same: what problem are you trying to solve?

Sadly, the conversation usually gets a lot quieter after that.

This isn’t a new dynamic. I’ve been working with product organisations on their tooling for years, and in that time I’ve watched the same pattern play out at companies of every size, maturity, and vertical. Most organisations treat tool adoption as a decision - do we buy this or don’t we? Completely ignoring that what should be a structured and nuanced evaluation has been reduced to a binary, thus bypassing all the questions that would tell you whether this is actually the right fit, for this team, for this org, at this moment.

Do this often enough and the result is an operating system that grows faster than anyone can manage, is maintained by nobody in particular, and was evaluated by nothing more rigorous than how enthusiastically it was onboarded.

Subscribe now

A Hammer Without A Nail

Most tooling adoptions usually start with a legitimate problem. Teams are struggling to communicate priorities, or discovery is getting lost before it reaches development, or stakeholders keep asking questions that nobody can answer quickly. Something is genuinely broken. But instead of staying with that problem long enough to understand it properly, the conversation jumps almost immediately to solutions. We need a roadmapping tool. We need a research repository. We need a better way to manage our backlog.

From there, the evaluation rapidly becomes a feature comparison. Someone pulls together the top ten options. Demos get scheduled. A spreadsheet appears, mapping capabilities across vendors. And somewhere in the process of weighing integrations and pricing tiers and UI preferences, the original problem drifts to the back of the room. Nobody asked whether the real issue was cross-departmental visibility, or delivery credibility, or that sales didn’t have anything that would help them close deals. The problem was never communicated with enough specificity to be evaluated against - so the evaluation becomes about the tools themselves, as if you were buying a toaster.

And thus success, by the end of it, becomes about finding a tool, not solving the problem that prompted the search. And because success was never defined in any more concrete terms than that, there’s no basis on which to run a real trial, no exit criteria if things go wrong, nobody accountable for whether this actually changes anything. The tool then gets dropped into an existing operating system without anyone asking what happens before and after it - where information comes from, where it flows to, whether it creates new decision points or removes old ones. Instead, the final questions are always the same: what’s the price, how many licenses do we need, and how many features do we get?

Applying The Discipline You Already Have

The frustrating thing is that product people know how to do this correctly. They do it every day.

Before a feature gets built, there’s a problem statement. Before a solution gets committed to, there’s a hypothesis. Before it scales, there’s validation. Ownership is assigned, success is defined, and at some point someone asks whether it has been achieved. This is the discipline that separates good product organisations from reactive ones, and most product teams know what good looks like.

Then it’s time to buy a tool and none of it gets applied.

There’s no discovery phase for the problem the tool is supposed to solve. There’s no hypothesis, no trial with defined success criteria, no accountability for whether it changed anything. The same Product Leader who would push back hard on a feature request that lacks a clear problem statement will approve a tool purchase on the basis of a compelling demo and a favourable price per seat. The same organisation that treats “we’ll know it when we see it” as a red flag in a product brief will accept it as a perfectly reasonable measure of tooling success.

The result is an accountability vacuum. When nobody owns the evaluation, nobody owns the outcome either. And when nobody owns the outcome, there’s no mechanism to recognise failure - which means no mechanism to course-correct, retire what isn’t working, or learn anything ahead of next time.

Tools accumulate. Costs compound. The operating system becomes the thing that slows everyone down.

The Tool Adoption Canvas

I created this canvas because I was tired of seeing companies make the same mistakes over and over again - especially as AI tool adoption has added a whole new layer of urgency and volume to the problem. The canvas is a single-page document that brings that discipline you already have to tool adoption decisions. It’s the same questions good product teams already ask, just applied to a place they’ve been ignoring.

It’s available below in two versions - one fancy, one black and white - each with three templates: one with guiding questions to help you work through each section, one completed example so you can see what good looks like in practice, and a blank version for you to use as you see fit.

If the canvas slows down your tooling procurement process, good - it means it’s doing its job.

Tool Adoption Canvas

624KB ∙ PDF file

Download

Download

Print Version Tool Adoption Canvas

607KB ∙ PDF file

Download

Download

Highlights

• AI disruption and organisational impact

• Building confidence through practice and community

• The role of product ops in transformation

• Reframing identity and roles in the age of AI

• Strategies for learning and experimentation with AI

Check out more of what Caroline does via her website and published some great content on her substack

Watch here on Substack, or listen on your favourite platform. We’re on YouTube, Spotify and Apple Podcasts

What should the team discuss next? Share your thoughts about a future topic you love them to dive into… maybe you are even that guest to talk to.

Share Product Ops Confidential

Who:

When: Wednesday 20th April 2026

Where: Virtual

I am honoured to be co-leading the EMEA Airtable User Group Chapter, with a number of events being planned for 2026, alongside the brilliant Josh Childs.

To kick off this exciting development for our part of the world, we're hosting a virtual session to talk about our wo…

Read more

“Connect strategy to daily decisions”

Highlights:

• The five questions of the Decision Stack

• The role of principles in decision-making

• Communication and alignment in organizations

• Empowering teams through clarity

• The importance of continuous strategy review

Read Graham’s review of The Decision Stack too:

Watch here on Substack, or listen on your favourite platform. We’re on YouTube, Spotify and Apple Podcasts

What should the team discuss next? Share your thoughts about a future topic you love them to dive into… maybe you are even that guest to talk to.

Share Product Ops Confidential

Read more

Our role is more talked about than ever. More job listings. More LinkedIn posts. More conferences with “Product Ops” on the agenda.

And yet, it can still feel like an uphill battle in earning that trust, gaining that buy-in, for the work you have been asked to do.

Sound familiar? …

Read more

This has been on my mind for quite a while now.

Product Operations, in JDs and conference slides, sounds genuinely exciting when it comes to data. Connecting dots across the portfolio. Surfacing patterns in customer feedback. Shaping product strategy rather than just reporting o…

Read more

Three years and one day ago, on the 26th April 2023, the Product Operations Manifesto was released into the world.

A lot has happened in those three years. And somehow, it feels both very long and very short at the same time. Long enough that the discipline has changed and evolved since we published. Short enough that I can remember exactly where I was s…

Read more

Overall, the importance for both product and product ops professionals to carve out that time to pause, step back, breathe and really consider the value in what is being discussed, planned and worked on. Ask why you're doing this, at every step.

Highlights:

• First principles thinking as a foundational approach

• The importance of small, incremental changes over large overhauls

• Breaking organisational silos for better collaboration

• Aligning product work with business objectives and metrics

• The role of leadership and incentives in fostering innovation

Watch here on Substack, or listen on your favourite platform. We’re on YouTube, Spotify and Apple Podcasts

What should the team discuss next? Share your thoughts about a future topic you love them to dive into… maybe you are even that guest to talk to.

Share Product Ops Confidential

Last month, I gave the closing keynote at Design Ops London.

The talk was about operational disciplines - Product Ops, Design Ops, you name it - and the single thing that determines whether they survive and thrive inside an organisation, or get deprioritised and then laid off when budgets tighten. My argument was blunt: if you are in an operational role and you cannot articulate a clear, defensible strategy within your first three months, you should not be surprised if you fail your probation. And it would be with good reason, too.

The talk landed. People were nodding, taking photos of my slides, coming up to me afterwards - it was great. But there was one exchange I hadn’t predicted, and it’s one I still think about, even a month later.

One of the people I spoke to after my talk was a Design Ops Lead I know and respect. She’s smart, experienced, and clearly excellent at her job. She told me she’d really enjoyed the talk - great! - but then she also said the following:

“It made me kinda nervous. Because I realised I’m not doing any of the things you said I should be doing.”

I’ve been thinking about that sentence ever since.

Now, I know that this isn’t an uncommon problem. I see this in conversations with my coachees all the time. Being a strategic operator is a genuinely difficult thing to pull off, and it’s the single biggest issue in any transformation work.

But until she said it so openly I never really realised just how little accessible guidance is out there.

The Trap Is Structural, Not Personal

Here is what I have observed, consistently, across years of working with product organisations: the people who end up in operational roles are almost always exceptional at spotting problems. They walk into a room and within weeks they have a complete picture of everything that is broken, inefficient, misaligned, or missing.

This is exactly why they get hired. And in a cruel twist of fate, it is also exactly why they get stuck.

Because organisations don’t hire operational leads and then give them six months to think. They hire them and immediately point them at the nearest fire. Prove your worth. Deliver value. Show us this was the right call.

So they dive in. They fix things. They are busy - genuinely, productively busy. And six months later, they come up for air and realise they have been firefighting since day one, with no clear sense of where they were going or how to explain why any of it mattered.

Most of the time, this is not a personal failure - It’s a structural one. The organisation created the conditions for it, and nobody pushed back.

But here is the uncomfortable truth: Your organisation will not save you from it either. When budgets tighten and headcount gets scrutinised, “I’ve been very busy solving problems” will not be a defensible enough position. A list of problems solved is not a strategy. And without a strategy, you cannot demonstrate impact at the level that’s necessary to protect your role.

What Happens Without a Strategy

I want to be specific about the risk here, because I think it gets largely underestimated.

Without a strategy, your priorities are set by whoever shouts loudest. You are reactive by default, which means your work is only ever as visible as the last fire you put out. You have no framework for saying no, so you say yes to everything, spread yourself thin, and deliver nothing at the depth that creates lasting change.

Without a strategy, you cannot build buy-in. You cannot walk into a conversation with your CPO and explain, with confidence, why you are working on what you are working on, what it will produce, and how you will know it worked. You are always one reorg away from being the first team cut.

And without a strategy, Product Operations never gets to do what it is actually capable of. The function exists to multiply the effectiveness of the product organisation around it. That is a significant, strategic mandate. Firefighting wastes it - and gives it a bad rap, too.

Why Strategy Is Not a Luxury

I hear a version of the same two objections regularly: “I’d love to be more strategic, but I just don’t have time - there’s too much to do.”

I understand why it feels that way. I’ve been there. But I also know it’s backwards.

The reason there is too much to do is because there is no strategy to filter it through. Strategy is not something you do after you’ve cleared the backlog. Newsflash: The backlog never clears. Strategy is what tells you which parts of the backlog actually matter.

The other objection I hear: “I’d love to be more strategic, but I don’t even know where to start.”

This one I have more sympathy for, because strategic thinking is genuinely hard. It requires zooming out in a way that feels uncomfortable - especially when you are surrounded by things that need fixing RIGHT NOW.

I feel that discomfort in my belly. I feel it every time I coach someone new, every time I start a new consulting engagement, every time I hear or read or see yet another sharp, capable operator stuck in the same tactical loop who I know can do better.

And quite frankly I’ve had enough.

The Product Operations Strategy Playbook

In the past few years I’ve solved the strategy problem for myself - but I want to go beyond that. So I’ve codified exactly how I approach Product Ops strategy - every conversation you need to have, every question you need to answer, every artefact you need to create - into a playbook you can download for free.

It is not a quick fix. Done properly, the full process will take you six to eight weeks. It requires conversations with senior leadership, an honest assessment of your current state, and the discipline to translate all of that into a roadmap you can actually defend.

But by the end of it, you will have something most Product Ops practitioners never build: a clear direction, explicit alignment with leadership, and a strategy you can point to when someone asks why you are doing what you are doing.

Download it below. Use it, share it, adapt it to your context. Make it yours.

Your organisation needs you to operate at this level. So does the discipline.

And I know that you are capable of it.

The Product Ops Strategy Playbook

37.4MB ∙ PDF file

Download

Download

If you are interested in my journey into building with AI and why I am writing this series, I recommend you read the Prologue in the first article:

Read more

Who: Antonia Landi

When: Friday 24th April 2026

Where: Mobile.de Offices, Berlin

AI Camp is for product builders and professionals exploring AI’s practical impact on their work. Run like a bar camp, all participants are free to propose and lead sessions - the audience registers their interest, and popular sessions get assigned rooms and time …

Read more