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 work with Claude and Airtable to accelerate how we, and our teams, operate. I really dislike the term 10x, but actually, I measured a new routine this morning, and it was actually 9 times faster... close enough! 🤣

If you are an Airtable builder or user, come join us to hear how we're using AI to streamline getting data into, and out of, our favourite platform, thanks largely to the new MCP they have built. 💪

And be the first to hear too about our co-located IRL event in London and Dublin coming soon. 🇬🇧 🇮🇪

Sign up (free!):

Sign Up

MXP London (MixPanel)

Who:

When: Thursday 21st April 2026

Where: London (attending only, not speaking)

Find out all the details and why I’m attending in my previous article:

Sign Up Here

“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

Martin Eriksson’s The Decision Stack addresses this with two words. ‘How’, and ‘Why’, as he diagnoses exactly why this happens.

Martin has spent over three decades building products, teams, and businesses, as well as advising more companies than I can count on strategic alignment. If you don’t already know of Martin’s work, he cofounded Mind the Product and coauthored the bestselling Product Leadership (O’Reilly, 2017). With this experience, I know this is based entirely on hard-won pattern recognition at all scales of business, from startups to global enterprises (including the likes of Novo Nordisk and Bloomberg), and every page reflects that depth of experience.

(BTW, if you get hung up on the word ‘cascading’ with OKRs, have a read of my previous review of Matt LeMay’s Impact First Product Teams, in particular with one-step or orbiting goals, which Martin also addresses)

Here is what I took from the book, and what Product Ops professionals can take away, too.

1. The Problem is not Execution, but Alignment

The central premise of The Decision Stack should make every product leader uncomfortable in the best possible way. Martin argues that most organisations do not have a problem with executing on plans, but are executing on plans that are not aligned across teams. Smart, motivated people are doing great work, just in different directions. The instinct to fix this is adding more structure (more OKRs, more alignment meetings, more strategy documents, more frameworks), but this only makes things worse.

Tell me in the comments below if you have NOT experienced this at least once!

I get it, it seems so simple on paper, beautiful trees of laddered objectives and rolled up stats. Excited executives get giddy with the idea of tracking progress, add in a few more layers of reporting and accountability matched with the organisational hierarchy, and before you know it, you are overloaded with outcomes without the strategic importance, priority or clarity to go with it.

The Decision Stack, Martin also makes very clear, is not another framework to introduce to an already framework-fatigued sector, but a mental model for connecting the decisions that already exist across your business. You already have most of the pieces. The problem is that they don’t connect.

2. How and Why: The Elegance of Connected Decisions

The model itself is beautifully simple. Vision and mission sit at the top, through strategy, objectives, and opportunities, all the way down to the principles that guide how teams work every day. Navigate downward by asking “How?” Navigate upward by asking “Why?” When these layers connect, teams move fast, make good calls without escalating, and the whole organisation builds momentum (points to the subtitle!). When they don’t? You get the pattern every leader recognises: priorities that shift every quarter, the same debates relitigated in every meeting, and a growing sense that everyone is busy but nothing is moving.

What was interesting for me is, before reading this, I’d used a similar version of the stack - VMOST (Vision, Mission, Objectives, Strategies, Tactics). So immediately, I could see how the layers help align people and teams around a common language and achievable goals. If you read my review and praise for orbital goals from Matt’s Impact First Product Teams, you might be confused at this point, but I genuinely see the two operating together. Ensuring there is a direct link between any layer and the Vision is super important. But there is a practical need for what is essentially reporting layers, too, in business, and the connection to these in the style of The Decision Stack is just as important. Like so much in our industry, it depends on your org culture and your colleagues.

Martin identifies strategy and principles as the two layers most commonly missing. Without a clear strategy, making real choices on the ground, without escalating every time and being able to make genuine tradeoffs, not aspirational wish lists, is difficult, and your objectives become disconnected from purpose.

And without codified principles, teams relitigate the same decisions week after week, particularly where there is not ‘true’ alignment (none of this smile and disagree nonsense!)

His “even over” approach to principles (”conversion, even over revenue” or “job seeker, even over recruiter”) is one of those beautifully specific tools that immediately shifts how a team thinks about priorities. These are not generic ‘values posters’. They are decision-making instruments, and the fact that they should evolve over time adds a pragmatism often missing from strategy literature. Case in point - the good book Agile!

2a. One Step Rule and Decision Stack

I wanted to share an important amplification at this point, which I am grateful to Martin for discussing with me between reading his pre-release copy and the publication of this review: The Decision Stack is compatible with the One-Step Rule, articulated by Christine Wodtke (Radical Focus) and amplified by Matt LeMay (Impact First Product Teams). The Decision Stack has layers, which provide some organisational grouping and directional focus, but each asset at each layer can and should clearly show how it connects to the organisational level. Having a relationship or flag to the layer above does not discount it from also having a relationship or flag to the Vision. The diagrams shared are a visual representation in two dimensions, as are the book pages. But these relationships are not.

You can split the stack at any level, and that split should at most be one level removed from the organisation level. Different team objectives? They map directly to the organisation's objectives. Different team strategies, They map directly to the organisation's strategies.

The Decision Stack - Martin Eriksson

3. Why Product Ops Professionals Should Be Reading This Right Now

Product Ops exists, at least in part, to be the connective tissue between strategy and execution. We are often the ones monitoring whether OKRs are well-formed, particularly at the more detailed layers of the stack; whether teams have the clarity they need, and whether the operating rhythm supports or undermines alignment. The Decision Stack gives us a shared language and a diagnostic model for doing exactly that. When you can see the stack, you can see where it is broken. You can identify whether a team’s confusion stems from unclear strategy, disconnected objectives, or missing principles, and you can have a far more productive conversation about how to fix it.

The cadence model that Martin uses to articulate the rate of change for each layer of the stack (cadence of change) is something any product operations professional can immediately apply to audit how their organisation makes decisions.

• Vision is essentially static,

• Strategy is renewed every 18 months to 3 years,

• Objectives are set every 6 to 12 weeks,

• Opportunities are in constant flux,

• …all grounded in slowly evolving principles)

This is the expectation of change (it might not change, but you should be prepared for it to). Product Ops can also prompt for a review cadence for each layer (cadence of review).

Knowing how often things change is useful, but it is not the same as knowing how often you should check. Review cadences should be much more frequent than the change cadence. The whole point is to catch drift before it compounds

The Decision Stack - Martin Eriksson

Martin provides a practical rhythm for this review cadence in the book, too.

The Verdict: A Mindset Shift, Not Another Framework

The Decision Stack genuinely is a must for any product leader who feels like their organisation is busy but misaligned. But remember, this is not a whole-hog uprooting of process and approach to strategy; it is an essential mindset shift for both leaders and operators. You likely have every asset already at your fingertips, and now need to rethink the explainers for the How and the Why.

This is a guide to ensuring clarity of mission and outcomes across all levels of goal-setting and all levels of the organisational chart. So often, we focus on the upper levels for clarity, and then just blurt out the plans and expect everyone else to keep up. No longer.

If you are a CPO or VP of Product, this will help you understand why your teams are pulling in different directions despite everyone working hard. If you are in Product Ops, The Decision Stack will guide you on keeping appropriate tabs on said clarity and focus, and to embed a shared language for the alignment conversations you have been trying to have for years.

Stop adding more to the bloated stack, and start connecting what is already there.

Practical Applications for Product Ops Professionals

Because this is me, I love practical, tangible things over more theory. So here goes:

1. Run a Decision Stack Diagnostic Across Your Product Teams

Sit down with each product team (or team lead) and ask them to articulate each layer of the stack: What is our vision? What is our strategy? What are our current objectives? What opportunities are we pursuing and why? What principles guide our decisions?

Where teams struggle to answer is precisely where the stack is broken. Product Ops is uniquely positioned to run this cross-functionally and spot patterns. If three out of five squads cannot articulate the strategy, that is not a team problem. That is an organisational gap, and now you have the evidence to address it.

2. Surface Repeated Debates and Turn Them Into Principles

Martin identifies principles as one of the two most commonly missing layers. Product Ops sees the recurring arguments that eat up planning sessions and review meetings: Should we prioritise existing customers or acquisition? Speed to market or product quality? Asking these questions is not really the issue, but not being able to move forward (i.e. not being able to answer them) is, and ideally without needing to escalate every time. This is where principles will help, particularly for fast-moving, highly autonomous teams.

Track these repeated debates deliberately. Every argument that resurfaces month after month, quarter after quarter, is a missing principle. Work with product leadership to codify them using Martin’s “even over” format (”acquisition, even over retention” or “speed to learn, even over speed to ship”). Once documented, these become decision-making instruments that teams can reference without escalating.

3. Redesign Your Operating Cadence to Reflect the Stack’s Natural Rhythms

Most organisations review everything on the same cycle (typically quarterly), which flattens the distinction between layers that should move at very different speeds. Use the cadence model to restructure your planning and review rhythms. Vision should be revisited rarely (annually at most). Strategy every 18 months to 3 years. Objectives every 6 to 12 weeks. And having a quick review of each much more regularly, respectfully. Product Ops owns the operating rhythm; use that leverage to ensure each layer gets the right frequency of attention rather than cramming everything into the same quarterly planning circus - there are already enough elephants and clowns in these already!

4. Add the “Why?” Trace to Every OKR Review

Before tracking progress on objectives, build in a standing agenda item that asks teams to trace upward through the stack. Why does this objective matter? Which strategic choice does it serve? How does that strategy connect to our vision? If a team cannot make that connection in a sentence or two, you have found a break in the stack. This is a lightweight but powerful ritual that costs nothing to implement and immediately exposes misalignment. It also, over time, trains product managers to think in connected decisions rather than isolated deliverables. And remember to add these to your Initiative records for reference - wherever that happens to be.

5. Make Principles Visible at the Point of Decision

Principles that live in a forgotten strategy document are decoration. Product Ops controls the templates, the tooling, and the communication rhythms. Use that access. Embed your organisation’s principles into sprint planning templates, roadmap review agendas, and decision logs. When a team is choosing between two opportunities, the relevant principle should be immediately referenceable, not buried in a slide deck from last year’s offsite. The goal is to make the right decision the easiest decision, and that means putting principles where the decisions are actually being made.

And hey, in the age of AI, get your favourite LLM to ask you the questions - Claude, ChatGPT, Gemini (No, not you Grok…)

These are all actions that sit squarely within the Product Ops remit: diagnostics, cadence design, facilitation, tooling, and communication infrastructure. None of them requires permission from above to start, which is also where we sit best!

Graham

Martin will be joining Graham & Antonia on the Product Opscast soon to discuss the impact of The Decision Stack on Product Ops professionals. Look out for this episode!

Share Product Ops Confidential

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? You are not alone, as many conversations, interviews and survey results can attest to. A byproduct of building this newsletter and the Product Ops podcast is that both also act as a funnel for such information.

This article is, in a small way, also a reflection of the journey of Product Ops, as well as a reflection of the deep thinking Antonia published earlier this week on the creation of the Product Ops Manifesto. One of the great things we enjoy working together on this newsletter is the ability to curate independently, and yet riff off each other’s ideas!

We Are Still Explaining What We Do

This one stings a bit, but it is true. Despite the growth in awareness, Product Operations still lacks a universally understood definition. Now, this in itself is a nuanced issue, because as we all know, Product Ops is different in every business. Not different like ‘oh we do Product Management differently here' (you don’t, you just pick and choose what from Scrum you like), but in fact building on top of that to focus on what the business needs, needs first, and provides maximum value to a business selling its own USP. A standard definition is not applicable.

And yet, there are key and common pillars of the role that do apply more abstractly, more wavey-handy. This helps to align both operators on the responsibilities and measures of success, without being prescriptive and restrictive. Because a key aspect of the role is often problem-solving new challenges that have not been solved before. Which could literally be anything.

I’m not advocating for a prescriptive, fixed responsibilities list. BUT, a job description has a purpose in life still, and so when we call a role Product Operations, we should be talking about the same thing.

I monitor Product Operations job listings as part of the Roles Database we recently launched — and the variation in what companies mean by the title is staggering. One role is essentially a project manager embedded in a product team. Another is a data analyst building dashboards. A third is a strategic leader owning the entire product operating model. A fourth is a catch-all for “things the product team needs done that nobody else wants to own.” I refer you to ‘What Product Ops is NOT’ written 2 years ago and is still true today.

The inconsistency is not just a branding problem. It creates real pain for professionals trying to navigate the discipline. When the same job title can mean wildly different things at different companies, how do you benchmark your skills? How do you know if a role is a step forward or sideways? How do you explain to a hiring manager what you actually did in your last role when their frame of reference for “Product Ops” is completely different from yours? And how do you spot the ‘this isn’t Product Ops’ roles on the job boards?

For product management roles, leaders will typically want a product manager to add capacity. For Product Ops roles, leaders want someone to fill their specific gaps, which may or may not be what we, as professionals, identify as part of the role.

So do we have a role identity problem? I think until the industry converges more meaningfully on what Product Operations actually is, and what it is not, this will continue to create friction for the people doing the work. And until now, this has been down to the people in role educating their managers and their businesses on how Product Ops brings most value.

The Pillars Are Established. The Tensions Within Them Are Not.

The Product Ops Pillars: Strategic Support, Business Alignment, Data-informed Decision Making, Valued Communications, Iterative Improvement (of processes), Cross-functional Collaboration.

And underpining all of this is change management, of the people the role works most closely with. Because Product Ops is a people role first and foremost.

They appear in job descriptions, conference talk slides, and probably in most of our LinkedIn profiles. There is variation in the nonclamenture, but overall these are the role guardrails, the territory. Notice there is no mention of AI… because AI as a sticker is not a focus, but the application of it as a tool to make teams more efficient, is.

The pillars are not wrong. But the real story is not in the pillars themselves — it is in the tension between what those pillars promise and how the work actually plays out.

Let me walk through some.

Iterative Improvement (of Processes): The Pillar Everyone Sees — And the One Most Likely to Backfire

Process design and improvement is the most visible pillar of Product Ops. It is often where new hires are pointed first: “Can you sort out our planning cycle?” or “We need a standardised way to do roadmap reviews.”

And there is genuine, valuable work here. Designing planning cadences. Building templates that actually reduce cognitive load rather than adding it. Creating frameworks for prioritisation that help teams make decisions rather than just documenting them. Streamlining workflows that have calcified over years of “we have always done it this way.”

But process work is seductive because it feels concrete and deliverable. You can point to a new template and say “I built that.” You can show a streamlined workflow and measure the time saved. The danger is that Product Ops becomes synonymous with process, and specifically, with adding process. There is nothing inherently wrong with this if the overall improvement is a net-positive impact on value or effort or time taken to complete the task the process focuses on. Does it take 10 minutes to write a report for each squad vs 20 minutes per squad to go and find and unpick the information a leader needs.

The best Product Ops professionals I have encountered are as focused on retiring the process as they are on creating it. They ask “What can we stop doing?” as often as “What should we start doing?” They recognise that every template, every cadence, every reporting requirement is an expectation placed on someone else’s shoulders, and those expectations accumulate.

If the only thing your Product Ops function is known for is introducing new processes, something has gone wrong. You are not enabling the product team. You are burdening it with red tape. And in the age of AI, you will quickly become obsolete as Claude and co can take on those processes and either fully automate, to just provide the outcomes (who cares how it does it) or guide product leaders directly.

Data and Insights: Where the Strategic Potential Is Highest, And Most Underutilised

The data pillar is where Product Ops has the most untapped strategic leverage, and it is also where I see the widest gap between aspiration and reality.

At the tactical level, this pillar involves building dashboards, aggregating customer feedback, centralising product metrics, and making sure teams are looking at the same numbers. All necessary. All valuable.

At the strategic level, it means something quite different. It means being the function that connects the dots across the product portfolio, identifying patterns in customer feedback that no single Product Manager would see, surfacing insights about how different teams’ roadmaps interact (or conflict), and providing the data-informed perspective that shapes product strategy rather than just reporting on it.

The pain point? Most Product Ops professionals get stuck at the tactical layer. Not because they lack the capability, but because the infrastructure is not there.

Customer feedback is scattered across a dozen systems. Support tickets in one tool, sales call notes in another, NPS responses in a third, feature requests buried in Slack threads that nobody will ever find again. Product metrics are defined differently by every team; “active user” means one thing to the growth squad and something else entirely to the enterprise team. The data is dirty, incomplete, or locked behind access permissions that take three weeks to resolve.

You end up spending 80% of your time getting the data into a usable state and 20% actually doing anything useful with it. This is not a skills problem. It is a maturity problem. And it is one of the reasons the data pillar consistently underdelivers relative to its potential.

Collaboration and Stakeholder Management: The Pillar Nobody Lists on Their CV — And the One That Matters Most

I have long said that so much of what we do in Product Ops is people-focused - not tech or even process-focused, but people. How do we help others, guide others, enable others, and improve the working lives of others?

This is the pillar that does not fit neatly into a framework or a slide deck. It is the work of understanding why a particular Product Manager resists a new process — not because the process is bad, but because of how they respond to expectations and change.

It is reading the room in a planning session and knowing when to push for alignment and when to let teams find their own path. It is building credibility with an engineering lead who has been burned by “operational improvements” that just meant more admin for their team. It is navigating the politics of a quarterly planning cycle where three VPs want conflicting things and nobody wants to be the one to say so out loud.

The pain point here is that this work is largely invisible. You cannot put “navigated three weeks of political tension between the platform team and the growth team to unblock the Q3 planning cycle” on a dashboard. But it might be the most valuable thing you did that quarter.

Product Ops professionals who excel at this rarely get credit for it in the metrics their organisations care about. And that invisibility creates a vulnerability, because when someone asks “What does Product Ops actually do?”, the answer “I spend a significant portion of my time on stakeholder relationships and change management” does not land the same way as “I built a dashboard that saved 200 hours.” Not just because it’s numbers, easily converted into money, but because it surfaces the unsavoury reality of the business.

Both are true. Both matter. But only one is easy to measure.

Change Management: The Pillar That Underpins Everything — And Exhausts Everyone

Every pillar I have described involves change. New processes are change. New data practices are change. New tools, new cadences, new ways of working — all change. Product Operations is, in many ways, a permanent change management function. This doesn’t mean we just change things all the time, but we manage colleagues through changes when they occur in the short, medium and long term.

And change management is exhausting. Not because the changes are bad, but because resistance is constant, varied, and deeply personal.

The same initiative, communicated the same way, lands completely differently depending on who you are talking to. One Product Manager embraces it 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. And understanding why people respond differently, and adapting your approach accordingly, is arguably the most important skill in Product Ops.

Most Product Ops professionals learn change management through trial, error, and the occasional bruising experience. Very few organisations invest in building this capability deliberately or provide any training or guidance to those on the front line. And yet it is the skill that determines whether all the processes, data, and tools you design actually get adopted — or just sit in a Confluence page gathering dust. Sadly, I will admit, I have a few myself right now.

I strongly recommend you review The Four Tenencies & Product Ops for a deep dive into how people react differently to change and expectations.

The Strategic-Tactical Divide

And then there is this…

You were hired, or you positioned yourself, to be strategic. To design the product operating model. To build the systems and feedback loops that help product teams make better decisions, faster.

And then Monday morning arrives, and you are chasing a Product Manager for their roadmap update, fixing a broken Jira workflow, reconciling two teams’ definitions of “active user,” and preparing a deck for a quarterly review that nobody will read properly.

None of that tactical work is unimportant. It is often where trust is built and where the function proves its value in its early days. But the gravitational pull toward the tactical is relentless, and if you are not deliberate about carving out space for strategic work, you will look up in six months and realise you have become a very expensive project coordinator. And here is the thing, the tactical work is always needed to some degree; if you are giving people more time and focus back onto their primary role, the part of their job that is most valuable at driving the business forward, then this is no bad thing. But, this can just push the less valuable work downstream

The organisations that get the most from Product Ops treat the tactical as a means to the strategic; you earn the right to shape the operating model by demonstrating that you understand the operational reality. The ones that struggle treat the tactical work as the entire job description and then wonder why the function feels replaceable.

The Organisational Pain Points

Beyond the work itself, Product Ops practitioners are navigating structural challenges, and I think we need to talk about them more openly.

The perception gap. Product Ops is fundamentally a people discipline, if I have not already made this clear! But the people who hire us, and the people who evaluate us, often see us through a purely operational lens. They want processes documented, tools rationalised, dashboards built, workflows standardised. None of that is wrong; it is all part of the job. But the hardest, most impactful work in Product Ops is almost always human. The organisations that recognise this get the most from the function. The ones that reduce the role to its most mechanical components eventually question why it exists.

The career ceiling. In theory, the Product Operations career path runs from Junior/Associate all the way through to VP. In practice, many professionals hit a wall at the Senior or Lead level. Our annual State of Product Operations data tells part of this story; the number of Director-and-above level Product Ops roles remains small relative to the mid-level. Many organisations hire their first Product Ops person, see value, but never build a team around them. No team means no upward path, no progression, and eventually, no retention. Businesses are losing experienced practitioners because the progression problem has not been fully solved.

The redundancy question. When we designed the Product Ops Confidential salary survey, we included a question about redundancy. Not because we wanted to be alarmist, but because the community was already talking about it behind closed doors. Product Operations roles, particularly in companies where the function is small or new, are vulnerable when budgets tighten. The logic, from a leadership perspective, is brutally simple: if it is not directly building the product and it is not directly selling the product, it is overhead. We know that framing is wrong. But knowing it is wrong does not make you redundancy-proof. And the professionals who have experienced it, sometimes more than once, carry that uncertainty into every subsequent role.

AI is reshaping the landscape. The current narrative around AI and Product Ops tends to focus on automation: AI will build your dashboards, summarise your feedback, and generate your reports. And some of that is happening. But the more interesting shift is strategic. If AI can handle more of the mechanical, operational work, the data aggregation, the process documentation, the tool administration, then what is left?

The answer is the human stuff. The change management. The stakeholder navigation. The judgement calls about what to standardise and what to leave alone. AI might actually accelerate the transition of Product Ops from a process-centric function to a people-centric one. Which is where I think the discipline’s real value has always been, we are just getting better tools to prove it.

Where Does This Leave Us?

It would be hard to argue that I am anything but optimistic about Product Operations as a discipline. But I am also pragmatic. The pain points I have described are real, and they are felt most acutely by the people doing the work every day. But they are also, in many cases, the pain points of a function that is still maturing. Still finding its shape. Still working out what it wants to be when it grows up. We have to remember that the Product Ops role has pretty much been built on the fly by the people doing it - the ‘Build an Aeroplane while in Flight’ adage (which is ironically how we tend to approach Product Ops when evolving our product teams! Read about that here).

The pillars are established. We broadly agree on the territory. The challenge now is navigating the tensions within that territory: strategic ambition vs. tactical gravity, process creation vs. process burden, data potential vs. data infrastructure reality, people work that is essential but invisible, and change management that underpins everything but drains everyone.

This newsletter is always honest about the role. It’s not about blindly evangelising Product Ops, but takes a microscope to what we do. Not just celebrating the growth narrative, but interrogating it. Not just sharing best practices, but admitting where the practice is still uncertain, and learning collectively by sharing what others try out.

The message to Product Ops Professionals:
Your experience matters. The frustrations you feel are not yours alone; they are shared across a global community of people trying to build something that did not exist a decade ago. Talk about them. Share them. The more honest we are about where the friction sits, the better equipped we are to do something about it.

The message to Product and Business Leaders:
The Product Ops professionals in your organisation are probably carrying more ambiguity, more scope, and more existential uncertainty than you realise. Invest in their career paths. Define the role clearly. And recognise that the most valuable work they do is not always the most visible.

4 years ago, I pulled together the Product Ops pioneers of the time to recognise that the function is evolving, and the need to make sure it evolves in a direction that serves the people who chose it as well as the organisations that benefit from it. This is as true now as it was back then.

Graham

Share Product Ops Confidential

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 on it.

The reality for most of us: spending 80% of our time getting data into a usable state and 20% doing anything meaningful with it.

Not a new observation. But we can no longer just get on with it.

The infrastructure gap is the real bottleneck.

The tactical layer is well understood. Build dashboards. Aggregate feedback. Centralise metrics. All necessary, all valuable, and all harder than they sound.

Feedback is scattered across a dozen systems. Data is dirty, incomplete, or buried so deep it becomes a dark art. Product Ops professionals with genuine analytical capability end up spending their time on plumbing.

AI changes the conversation, but not how most people think.

The AI narrative focuses on automation: AI will build your dashboards, summarise your feedback, and generate your reports with the advent of MCPs and no-code API building. I’m doing this now.

But the more interesting question is what happens after the automation.

If AI handles the mechanical work: aggregation, summarisation, pattern recognition, then what is left for Product Ops?

Judgment. Context. Interpretation.

An AI tool can tell you 340 customers mentioned “onboarding” in negative-sentiment feedback last quarter. It cannot tell you which signals matter most given your strategy, which are symptoms of a deeper problem, and which are noise. It cannot navigate the conversation with a PM who does not want to hear that their onboarding flow is broken.

AI shifts Product Ops from a data collection function to a data interpretation function.

The questions I am left with.

The tools are changing faster than our practices. The potential is outpacing the infrastructure.

How do we build data foundations that make strategic insight possible, rather than perpetually firefighting the plumbing? How do we use AI to amplify judgment without outsourcing it? How do we ensure customer voice informs product decisions rather than just decorating them?

I do not have all the answers. But these are the right questions…

And so when Mixpanel reached out to see if I’d like to attend MXP London, this seemed like a perfectly timed opportunity to get some answers. Excited to hear again from speaker Debbie McMahon about the AI adoption gap; an incredibly relevant topic in stitching together the narrative of data usage by humans, by AI and what comes next…

So here I am herding other product and data professionals to join me on May 21 in London to answer these questions together, along with 300 other leaders in our field.

Want to join me?

Register Here

Graham

Share Product Ops Confidential

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 sitting when the website went live.

Every so often I get asked whether the Manifesto ought to be iterated on. Whether the content still holds true so much later. Whether a Manifesto is even still necessary.

I don’t claim to have all the answers - but for today, let’s explore together what the last 36 months have meant for our discipline.

Subscribe now

Why the Manifesto exists

The Manifesto was born out of frustration - specifically mine, but also that of every Product Ops practitioner I had spoken to up to that point.

I had just come out of one of the hardest professional experiences of my career. I had joined a company as their Head of Operations for Product and Engineering, and spent six months fighting for my seat at the table. I relentlessly advocated for my role, tried my hardest to justify my existence to my leadership peers, delivered every quick win I could think of while navigating internal politics, a broken roadmap, and looming layoffs everyone knew were coming.

Six months later, despite my best intentions, I was let go.

I’d like to tell you that this was unusual. But the more Product Ops people I spoke to, the more I realised it wasn’t. The details varied - some stories were bleaker, some more benign - but the throughline was the same. We were all spending enormous amounts of energy on the meta-work of being allowed to be full-time Product Ops practitioners in public: explaining what we did, why we were there, and what we needed to actually do it.

What I wanted - what I wish I had had - was an artefact. Something I could point to. Something I could hand to someone and say: this is what I do, this is why I do it, and this is what I need to be successful. Not as a way of winning an argument, but as a way of starting a conversation on a level playing field.

But such an artefact didn’t exist.

So I decided to create one.

Then and Now

The Manifesto was co-created by twelve Product Ops practitioners, entirely asynchronously, in twenty-two days. Deliberately done on a tight schedule, I wanted everyone involved to part with their opinions fast - so that we could discuss them with vigour, create something tangible, and share it with the world.

Whether and to what extent the Manifesto aided the establishment of Product Operations is hard to say definitively - but I’ve heard from enough people who’ve used it to start conversations with their managers to know it at least made a mark. And of that, I am incredibly proud.

But here’s the part I want to be honest about: Three years on, Product Ops practitioners are often still fighting the same battles.

The conversations I have with my coaching clients sound remarkably similar to the conversations I was having with practitioners before the Manifesto existed. The two most common challenges I hear are: I’m overrun with tactical work and cannot get to a strategic level, and I know exactly what I need to do, but I’m not allowed to do it.

Ironically, both of these map directly to two of the prerequisites defined in the Manifesto - the need for Product Ops to be understood as a strategic discipline, and the need for the mandate and trust to actually effect meaningful change.

Why our Discipline Matters More than Ever

I think it’d be easy to look at all the folks in operational roles today, see that they’re still struggling with the same issues they were struggling with a few years ago, and conclude that nothing good has happened. But I believe we are a lot further than we think.

Yes, some companies are still undervaluing the impact their suboptimal operating model has on their bottom line, and yes, not every company with operational staff knows how to make the most use of them - but collectively, we’ve all gained a ton of experience.

We can now point to things that have supercharged how organisations operate. We can clearly articulate the tangible impact we have. We can draw lines. We can communicate trade-offs. But most of all: We know the value we bring, and we’ve learned to differentiate a failed implementation from an organisation that was never ready to begin with.

And while many people in tech are re-thinking their place, their role, and whether there’ll still be a job for them by the end of this year, I genuinely believe that Product Operations is right at the precipice of a new era.

Looking Ahead

It’s undeniable that a shift in how we create products is upon us. New tooling and capabilities means the bottlenecks are not where they once were, and what we optimised for in the past is no longer what will propel us forward.

AI is here - but it has yet to be operationalised. Companies are scrambling to make use of it, but so far implementations are disjointed, hyperlocal, and siloed, where what is truly needed is context-driven, collaborative, and holistic. And I can’t think of a better discipline to make that happen than Product Operations.

The emergence of agentic AI and the opportunities that lie in human-machine teams as a genuine operating model is going to demand exactly the kind of work Product Ops practitioners excel at. And right now we are standing before a future where setting our organisations up for success means thinking through how people and agents interact with our operating model.

Agents, unlike humans, don’t adapt to dysfunctional systems out of politeness, politics, or self-preservation. They naturally expose gaps by delivering substandard output. They amplify the inconsistencies people have always worked around just to get things done. And organisations that don’t have clear systems, clean data, or a shared and codified understanding of how decisions get made will find that agentic AI makes those problems significantly worse, not better.

This is not a far-future concern. The companies already experimenting with AI-augmented product teams are discovering that the bottleneck isn’t the models - it’s the organisational infrastructure around it. Who owns the company-specific context that the agent needs to operate? Who decides which systems connect to which? Who builds the custom tooling that makes any of this usable in practice? Who makes sure the humans and the machines are actually set up to do their best work?

It’s us.

Onwards and Upwards

When I sat down to write this, I thought I’d feel more reflective. More inclined to look backwards, see just how far we’ve come, and take stock.

But the truth is, the more I think about where Product Operations sits right now, the harder I find it to look anywhere but forward.

The Product Operations Manifesto was never supposed to be the final word on anything. It was merely a starting point - a shared set of values and commitments that twelve people agreed on, and that nearly 200 more have since put their names to. It gave practitioners something to point to when the words weren’t coming. It gave organisations a mirror to hold up against their own assumptions about what Product Ops is and what it needs.

That job isn’t finished - not by a long shot.

But if there was ever a time to double down on what we bring to the table - it’s right now.

Happy birthday, Manifesto - now, let’s get back to work 💪

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:

A couple of things you will notice from these articles on AI:

• I affectionately say ‘we’ a lot - Claude and I - because it really does feel like a partnership to solve these problems. Claude may not have feelings, pride or an ego - yet - but I’d not be able to achieve this without it.

• In the spirit of that partnership - and my rapid use of AI - I do get Claude to review the journeys we go on with each project and do the first draft of these specific articles. I am happily upfront about this - largely because it has the details, it remembers the details better than I do! While I don’t do this elsewhere (I do more often ask AI to review post writing - who doesn’t!), I have zero problem with this partnership if the output is accurate, truthful, informative and useful to the reader.

The Problem(s): Jira’s long-term reporting is lacking, and key information is not exportable

Cards on the table, and I make no secret of this - I really do not like Jira. Don’t get me wrong, it is ubiquitous, and it does the job engineers need. But it really is not for product teams (Jira Product Discovery goes some way towards this). This article is not about my list of complaints about the platform - Substack character limits would hit me…

This is about some specific limitations around reporting that led me to solve this need with Airtable, utilising the data in Jira. Similarly, my love for Airtable would break article character limits… for another time.

Over the past year, I’ve built out our divisional reporting covering per squad, per sprint, per sprint time period, to provide high-level velocity-centred performance reports and initiative progress updates, as well as a deep dive into each squad and their improving performance, we hope, over time. Jira just doesn’t do this (well), or covering everything we want to follow, particularly given that not all information is sourced within Jira.

For the past year, this has been a fortnightly (2-week sprint) export into a spreadsheet (using the Sheets Jira applet), a little data tidy, a copy/paste into Airtable, a little more data tidy, some manual tasks to snapshot aggregate performance stats, spot-check validations.

So problem 1: How much of this can be removed, automated or reduced?

If you were wondering, this information needs to be a snapshot so that reports do not change. If it were a sync (which there is a facility for in these platforms), as tickets change over time, so would the synced information and potentially the report stats historically too. So it has always needed to be a snapshot and export.

As part of this reporting, we have always wanted to keep an eye on unplanned work creeping into sprints. Historically, this was a big issue, those sneaky C-suite colleagues throwing stuff into the mix! We track this to understand both the scale and reasons for it, to reduce where we can, but where there is a legitimate reason for it (a great example, the sprint after a big release, fixing issues that arise quickly).

This feeds into the wider discussion and monitoring of ‘What did we plan, what did we deliver, how successful were we in this?’

I’m sure the Agile purist mafia reading this will do their nut over the mere concept of unplanned work 🖕🏻 but I digress…

It’s a simple question. Jira makes it remarkably hard to answer when it comes to the raw data, which I want to export. And this is a well-documented limitation and a common ask in the product community (just go search for this topic!). It’s buried in changelog data that no built-in report surfaces cleanly.

Our workaround to date has been for our squads to manually mark tickets (using labels) as unplanned, something I can export and use as a flag to report on. It works, but it is clumsy, prone to human error, prone to interpretation, and gosh darn it - another job for them to do.

Problem 2: Can we get the data we need to identify unplanned work, as data, from Jira?

Why not just use Jira reports?

I’ve had this conversation enough times to pre-empt it. Jira’s Sprint Report does show “issues added during the sprint” — but it’s a UI-only view. You can’t export it, you can’t query it via JQL, and you can’t pipe it into a database where it becomes part of a bigger picture alongside initiative progress, sprint goals, and team health metrics.

The Jira API doesn’t offer a neat addedDuringSprint flag either. To reconstruct this, you need to pull the changelog for each ticket, find the history entry where the sprint field changed, and compare that timestamp against the sprint start date. It’s doable — but it’s the kind of work that only an automated process will do reliably, sprint after sprint, across a dozen squads. Plus, I cannot write API calls, so I’d need an engineer to help me!

Note to the reader: I did consider adding in here a solution I tried that involved an automation and a field to record when a ticket enters a sprint. It is, however, long, boring and ended up not being scalable… 🙄

Enter Claude - again

What do I know Claude can already do?

Read (and write) to Jira, utilising the Atlassian MCP.

Read and write to Airtable, utilising the Airtable MCP. Additionally, because I have had Claude work with the Airtable MCP a lot, it now understands the database I have built, how it hangs together and where data should go.

With this in mind, I set about asking Claude IF it could extract the information that, to date, was being exported to the spreadsheet. Replacing this step. Spoiler - it did. ✅

Because this alone would one-touch do a chunky job for me, my next step was to then write that information, using a field map I produced to map the Jira fields to the Airtable ones, into Airtable. Along the way, a few additional contexts and understandings were needed from Claude, like who our squads were and how to construct our fixed sprint naming conventions (so that things all link up inside Airtable). Took a little longer, but Claude did a great job here, too. ✅

At this stage, I’ve removed the need for the export, data tweak and import into Airtable.

The hard bit: detecting unplanned work

In the Jira universe, an unplanned ticket is one that has a change log record showing the ticket was added to a sprint with a date of that change being after the start date of the sprint… who knew! There is no shortcut to this; Claude potentially needs to go check for this for every ticket for every squad’s sprint for that reporting window. This is, on average, around 400-odd tickets. But Claude had a great idea on this.

The unplanned detection uses two rules, applied in order.

The first is cheap: if the ticket was created after the sprint start date, it’s unplanned by definition. A bug raised on day three of the sprint was never in anyone’s plan. This resolves a chunk of tickets without any extra API calls. Remember, this is only concerned with tickets added after the sprint starts. Everything pulled in from the backlog or created new and added to the sprint during planning is just fine.

The second rule handles the subtler case: tickets that existed before the sprint started but were pulled in after it was already underway (likely from the backlog). For these, Claude fetches the full changelog and looks for the moment the sprint field was updated to include the current sprint. If that change happened after the sprint start date, it’s unplanned.

This is the part that makes the skill worth building. The changelog calls are the most API-intensive step, but they’re the only way to distinguish “planned from the start” from “added on day four because something caught fire.” Without this, you’re just counting tickets and not understanding what happened to the plan.

Once classified, the label gets appended to any existing Jira labels on the ticket, and the data is then posted to Airtable, so a ticket tagged with ‘tech debt’, it becomes ‘tech debt, Unplanned’. The original labels are preserved; we’re adding signal, not replacing it.

Maintenance

So very geeky of me, but I get a great deal of satisfaction from asking Claude to self-evaluate the skills it produces, to try and make them faster, more efficient and definitely less costly in tokens. Simply by asking ‘Review this skill and identify ways for it to be improved, use fewer tokens and/or fewer calls to platforms.’

Almost always, it will identify that it made 20 calls to Jira (for example) when actually 1 will do the job, saving silly numbers of tokens. It will sometimes write routes to scripts as well, and often commit static information to memory (for example, our Squad names) to reduce a cycle of calls to Airtable, only making that call if something is missing.

The Bigger Picture

Once this data lands in Airtable, it connects to everything. Sprint goals, initiative progress, and squad health metrics — they all live in the same base. A PM reviewing their end-of-sprint report can now see exactly how much unplanned work their squad absorbed, right alongside whether their sprint goals were met and how their initiatives are tracking.

That’s the real point. The value isn’t in the import itself; it’s in what becomes possible when sprint-level ticket data stops living in Jira’s silo and starts living next to the rest of your product data. The unplanned work percentage becomes a trend line. Patterns emerge across squads. Conversations shift from gut feel to evidence.

Now, all of this was already in place for me; the big difference now is that this routine is about 95% automated, saving around 30 minutes every 2 weeks. The Unplanned work needs zero input from the squads, saving that little bit of time individually, as well as the cognitive load (never underestimate this) and 100% accuracy.

But as with so much with AI, the hard work isn’t the AI part. It’s knowing your data well enough to tell AI what to do with it.

Graham

Next up in the series is related to this, on how we’re about to assist our PMs even more with the things they DO need to enter for their reports (stuff that lives in their heads), and how Claude will prompt them for the specifics and only that.

If you have a great skill or routine that solves some product or product ops problems, and would like to guest publish in this series, reach out to Graham via LinkedIn

Share Product Ops Confidential

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 slots. Expect talks, discussions, workshops and more.

Antonia will join as an attendee - and might lead a session on responsible AI tooling implementations 😉

Find out more about AI Camp here, and if you’re interested in joining, DM Antonia on LinkedIn.

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.

Share Product Ops Confidential

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/

But… MCP integrations are powerful, but they…

Read more

In that spirit, for the last couple of years, Antonia and I…

Read more

But now we’ve gone further and deeper with the analysis, with a little help from HyperAgent, to produce a comprehensive analysis and report of what those figures actually mean for us as professionals and our careers.

For ease of use, we have produced a version in USD ($) and a version in GBP (£).

Report (USD)

Report (GBP)

Enjoy, and please comment with your thoughts on the findings.

Graham & Antonia

Share Product Ops Confidential

“Product leaders are herding cats on steroids!”

Highlights:

• Product leadership is influenced by multiple competing forces.

• Self-confidence is essential for effective leadership.

• Frictions exist at all levels of leadership, not just CPOs.

• Product Ops plays a crucial role in bridging gaps between teams.

• AI introduces new challenges and opportunities for product leaders.

• Collaboration is more effective than trying to educate stakeholders.

• Product leaders must adapt to reactive and chaotic environments.

• Establishing strong relationships is key to successful product leadership.

• The mindset of product leaders must shift from being a bottleneck to enabling teams.

• Understanding the unique dynamics of each organisation is vital for success.

PS: Graham had a couple of technical difficulties during this episode (he blames the inter-web!), which resulted in a couple of jumps in editing. Our apologies… You would never believe we worked in technology!

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

I’ve made no secret that until early 2026, I was well behind the times on all things AI. Sure, I could ask Claude a question, do a little research, or rewrite an email for me. But doing deep analysis, complex data work, and in particular creating and running customised routines between platforms - I was honestly both scared and lost. I didn’t qu…

Read more

Instead, we’ve built Best Practice Factories. We are shipping code faster than ever, yet we’re often farther away from actual business value than we were a de…

Read more

They examine the importance of establishing Product Ops as a strategic function within organisations, the evolution of the role over time, and the necessity of building trust and effective communication with leadership. They also delve into the challenges of navigating transition points in product operations, the significance of using C-suite language (‘nicely’ put by Graham in the episode!), and the responsibilities of Product Ops in relation to strategy ownership.

“Product Ops needs a seat at the table.”

“We need to safeguard the strategy.”

Highlights:

• Product Ops must establish itself as indispensable.

• Building executive trust is crucial for product operations.

• The role is evolving and becoming more recognised all the time.

• Navigating transition points is a key challenge in Product Ops.

• Effective communication with leadership is essential for success.

• Product Operations should think ahead to align with the company strategy.

• Using C-suite language can enhance communication with leadership.

• Trust and accountability are vital in Product Ops.

• Empathy is important in building relationships across teams.

Be sure to read the Product Ops Manifesto, mentioned in this episode

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: Antonia Landi

When: Friday 13th March 2026

Where: The Gallery @ Techspace, London

Antonia will deliver the closing keynote at DesignOps London 2026, detailing how her experience building and selling Product Operations to senior leaders has helped her position the discipline as essential to organisational growth instead of optional. She’ll describe what it takes for operational roles to remain relevant as organisations grow and change, and how to prove that good operations isn’t just a nice to have.

Read more about DesignOps London and see the full programme here.

If you’re interested in joining in person, reach out to Antonia on LinkedIn for a special discount code.

Free Webinar: Hosted by Tekkr

Who: Antonia Landi

When: Thursday 26th March 2026

Where: Online

Join Antonia and Philipp Römer in a candid chat about why the biggest companies fail to scale successfully, and how to avoid the most common mistakes holding organisations back from reaching their fullest potential. Having scaled Forto and Parloa to unicorn level, Philipp is intimately familiar with the challenges of scale, while Antonia has spent years figuring out why product orgs that should be winning are actually stuck. Look forward to a no-holds-barred event where they both lay out what they learned.

Register on Luma

All change is hard. But some change is the hardest.

I’ve had a hand in quite a few transformations over the years - from introducing goal-setting frameworks to overhauling discovery practices, from implementing new tooling to fundamentally reshaping how decisions get made. And I’ve noticed something that most transformation playbooks don’t talk about:

The…

Read more