The soul of product ops: 4 Lessons I have learned building Product Ops teams from scratch
My interview with Airfocus: November 2025
“Product ops is not necessarily solving new problems; it’s solving the problems that nobody was ever solving properly before.”
As product managers are pushed to deliver more, better, and faster, the need for a dedicated function focused on the craft of product management has become essential.
I [Graham Reed, Head of Product Operations at HeliosX], have built product ops teams from the ground up in five businesses. This interview extract tells the lessons I have learnt along the way.
1. Communication: Sometimes, less is more
Effective product ops relies on strong communication frameworks. However, Graham’s years of experience have made him aware of the risks of overcommunication. His advice?
Not everyone cares: “The trap I’ve fallen into is assuming that businesses should be communicating left, right, and center, and that every part of the business is equally interested in what’s being shared – and the reality is, that’s not the case.” In Graham’s words, “It’s a wasted effort.”
Understand the business: A deep understanding of the business’s structure, employee roles, and actual communication patterns must come before implementing any solution. In one of his product ops roles, Graham strived to establish a wide-reach communication framework, only to find out it was “incredibly underused.” Between warehouse employees and customer service agents, “actually, half of the business never even interacted with product.”
Target your content: Instead of expecting everyone to be curious, push specific, easily consumable assets. TikTok-style videos have been successful for Graham. “They allow for async consumption, but with targeted information for specific audiences, from operators to senior leadership. A library of shareable, specific assets, pushing that to audiences rather than expecting them to be curious and discover for themselves.”
2. Avoiding the bureaucracy trap
“It’s about understanding whether teams don’t want to do something because it’s more work, or because that something is taking three steps when it should only take one.”
Product ops should oil the product team’s engine, not add sand to it. To Graham, it’s about asking, “How do we embed these ways of working so that people don’t even notice that they’re doing it?”
Don’t be the process police: This is exactly what product ops teams can be mistaken for when they fall into the trap of overengineering or bureaucracy. Graham has been there, “trying to solve six problems with the same tool, and not managing to solve any of them particularly well.”
Be your stakeholders’ advocate: The key is making sure stakeholders know you are on their side. Graham does this by holding “very honest, informal, feedback sessions with stakeholders where I ask them what’s working, what’s not working, what areas I’ve missed, where I’ve overengineered.”
Empathize with friction: Understand if teams are resisting a process “because it’s more work, or because that something is taking three steps when it should only take one.” And then, work to remove that friction.
Read the full interview, covering ‘Bridging gaps with leadership’ and ‘The delicacy of change management’, here: