Transformational Product Ops is Hard to Reach
Recently I had a call with Shannon Vettes the CEO/CPO of Usersnap, we hadn’t spoken before but early in the conversation she mentioned that most of the Product Ops people she encountered were focused almost entirely on tooling and process, and that hearing me talk about it differently was refreshing!
Why was that? What I shared with her was my thoughts on the two distinct kinds of work that sit under the Product Ops label, and the fact that conflating them can cause a significant problem for the discipline as a whole.
Technical & Transformational Product Ops
The first is Technical Product Ops: tooling, data pipelines, workflow standards, making sure teams have what they need to make good decisions without having to sort out the infrastructure themselves. That work, of course, really does matter.
Why? Because nobody wants a Product Manager spending half their week troubleshooting a roadmapping tool or working out why the data in one system does not match the data in another. There is a clear and legitimate mandate for Product Ops there.
The second is Transformational Product Ops and this is where I spend most of my time and focus. It is the question of whether an organisation actually has the capabilities it needs to build products in the best way.
That means looking at whether decision-making is genuinely evidence-based across a team, not just within a small group, and whether the conditions exist for people to act on what the evidence shows them. These are the questions more about how an organisation is set up to operate than simply tooling and process questions.
Fixing the Wrong is False Progress
To illustrate this point, a story from an online workshop I facilitated recently. One of the participants, a Senior Product Manager, explained how his team’s main challenge was with customer feedback loops.
They described a situation where only Product Managers and Designers ever spoke to customers, and even then mostly when something had already gone wrong. The Engineers, they said, simply did not care what the research surfaced. They could have misrepresented every insight and the team would have built whatever they told them to build regardless. Sound familiar? It happens all the time.
But as the workshop progressed it became clearer that even if the feedback loop process were improved, made it more proactive, brought Engineers into customer conversations, the team would still struggle to build great products.
What was actually missing was a shared sense of accountability for outcomes and the conditions for people to make decisions together
The Engineers were not empowered to care one bit and nothing in how the team was structured incentivised collaborative decision-making. If Product Ops improved the feedback loop process it would have been a reasonable thing to do, but it would not have changed the underlying problem, which was about empowerment and accountability.
That behaviour change is exactly where I see Transformational Product Ops having a bigger impact, but it doesn’t always appear on most Product Ops job descriptions.
What the Job Specs Reveal
Even though I work as an independent Product Ops consultant, to keep a pulse on the market I’m always looking through job specs and the ones I read most often are for roles like Director or Head of Product Ops.
On the whole, even at this level of role, the specs are asking for someone who can ‘configure tools and manage workflows’. A significantly smaller number are looking for someone who can identify what is preventing an organisation from building products in the best way and work on changing it.
Those two roles require different things, they attract a different type of people, and they will have a completely different relationship with product leadership overall.
The fact that this split exists even at the senior end of the discipline, where you would expect a more strategic and transformational orientation, suggests that the field has not yet agreed on what it is actually for.
Both kinds of work are legitimate and necessary of course. But if most senior hiring is weighted toward Technical Product Ops, organisations are not building the Transformational capability they also need to evolve how they build products.
🤔
Where does Product Ops sit in your organisation right now, and is that a deliberate position or something that has just evolved over time?
Why Is Transformational Product Ops so Hard to Establish?
For me that is the even more interesting question and the conversation with Shannon surfaced three areas that I think go a long way to explaining it.
1. Sequencing Problems
The first is that most teams are working in the wrong sequence. Shannon described how the conversations she has most often with her customer’s teams involve them arriving with lists of feature questions, looking for a tool to do a specific thing, when what they actually need is a different order of thinking altogether.
As she put it, what she tends to see is teams “re-architecting the feedback to align to a prioritisation they have already decided on.” The tool becomes a way of supporting a conclusion rather than a means of reaching one.
Research and listening have to happen first, not as validation but as the process through which you find out what is actually worth building.
When teams are oriented this way, they mostly care about efficiency which is where Technical Product Ops can have some impact. But the appetite for Transformational Product Ops, which asks harder questions about how work gets done and why, is naturally lower.
2. Individual AI Practices
The second is that AI is reinforcing individual practice at precisely the moment when collective capability should matter the most.
Engineers are using it to write, check and ship code, Product Managers are using it to draft documents, process notes and conduct basic research, some Product Ops teams are building lightweight tools for others to use internally.
But consistent shared adoption, where a function is using an AI-enabled process together and can point to real measurable impact, is rare in my experience.
Shannon observed that …
💡
“ The current moment is pulling people further into individual practice, and that runs against what most product organisations actually need. “
Using AI to generate solutions draws on what is already known, the work of product is often about finding things that are not yet obvious. Those two things do not sit comfortably together, and an organisation leaning into individual AI use without building shared practices around it is arguably less ready for Transformational Product Ops, not more.
3. Product Culture
The third is around product culture, I’ve found that Product communities of practice are consistently harder to build and sustain than Engineering or Design ones, and the reason is largely cultural.
Product Managers are often hired with the expectation, sometimes explicit, sometimes just understood, that they carry full accountability for their area.
Leadership treats the performance of a product area as the Product Manager’s responsibility alone and that often produces a defensiveness that is understandable but incredibly damaging. Information gets held in siloes and collaboration becomes a risk rather than a default.
Shannon described the version of the role she valued most from her own time as an individual contributor as being the person who converged information from inside and outside the organisation and made sure the right people had access to the same picture.
That is what the role should be, but it does not always end up that way when one person is treated as solely accountable for the success or failure of a product.
Bringing in a new function that aims to transform how product work gets done can be very intimidating for Product Managers that favour working in a certain way, or simply just want to focus on their own product, team and goals.
And Finally …
What I really want to see is more Transformational Product Ops roles and practitioners, those that are going to evolve the product organisation and shift these conditions and behaviour.
For those people the challenge is working against a traditional organisational culture and structure that was not designed to be operate in this way, to be responsive rather that rigid and reactive.