Does ProductOps create team awesomeness? | Graham Reed

In episode 9 of Talking Roadmaps, Justin Woods interviews Graham Reed to explore whether ProductOps truly creates team awesomeness. Graham shares hard-won lessons on setting up ProductOps from 0 to 1, how to drive audience-centric communication, when to introduce the function, and why it's not just support—but a strategic enabler. They also discuss measurement challenges, cultural resistance, and tips for aligning product and commercial teams.

Graham is a seasoned, results-driven & strategic Product Operations leader. He spent over 10 years as a hands-on product manager/leader with international experience, leading teams to bring more than 15 SaaS & app products to market, resulting in revenues of £10m+ and millions of monthly users. Since 2021 he has pioneered Product Operations in Europe & the US, at market leaders in automotive, education & pharma, and revenues of £700m+.

Here is an audio-only version if that’s your preferred medium - and you can access it through your favourite podcasting platform if you prefer (Apple, Spotify, Amazon).

Does ProductOps create team awesomeness? | Graham Reed

Graham Reed and Justin Woods

In the next episode we are talking to Denise Tilles, CPO and Founder @ Grocket. So watch out for Season 2 - Episode 10!

• Transcript

  - My slight tweak on that is that we are doing all those things. But we are one stage removed from that. We are helping that. We are helping the product teams, the engineers to do that. And it's a reason why, actually, product operations is notoriously difficult to measure.

  - Welcome everybody to "Talking Roadmaps," the show where we talk about everything roadmapping. But in series two, we are talking about product operations, a really vital and growing function that supports the product management area and, indeed, the rest of the company. Today, I'm joined by Graham Reed, a person that I've been really excited to speak to for a long time. Graham, for the people that might not know you, please introduce yourself.

  - Thank you. Pleasure to to be here. Thank you for having me on. My name's Graham. I'm head of product operations at Helios. If you don't know Helios, you may know us in the UK as MedExpress. In the US, we are ZipHealth and RocketRx. And we provide various prescription medications, particularly in weight loss and sexual health. Outside of that, I've been involved in product operations for around about five years now when it actually kind of started to explode onto the scene. Prior to that, I've done a decade of being a product manager, head of products, director of product, those sorts of roles as well. So I've certainly gone through that journey of product from, in my terms, in its infancy all the way through to those leadership roles to now, absolutely, phenomenally happy at doing the product ops side of things as well. Almost a little bit on the other side of the fence to help, you know, those product teams that I work with to be as successful as as possible. If anybody does follow me, you know that I'm almost religious about product operations. I write about it. I talk about it. I podcast about it. So you'll be sick to death of my enthusiasm for the role and the function by the end.

  - If you're enjoying the channel, subscribe. Hit the bell icon. And give us a like. I think it's infectious, Graham. And I love speaking to that product ops guy. It's always a privilege. So Graham, let's get stuck into kind of the, right into the depths of it, which is why do companies need product ops?

  - I think, actually, one of the things to start with is what is product ops? And what I mean by that is how do we separate out the function from the role? Because, actually, when we talk about the function of product operations, it becomes actually very, very clear. Product operations has actually always been there in a business. So what is product operations as a function? It is how teams work, predominantly on the product, and ergo the technology side of a business. Whether you have a small product team that is an enabler for your business to sell other things, actually, like we are at Helios, or actually you're full and out SaaS platform, that that is your primary asset or what you sell, your teams, your primary, predominantly your product and tech teams have a way of working. So they go through the software development life cycle. They go from A to B to C. There's research that's done. We are communicating what we have done internally and externally of the business. We have metrics that we are monitoring and trying to hit. We have our OKRs. We have our planning sessions. We have our roadmapping sessions. All of these things are process-based. There's a way of doing things. And if we didn't have elements of that process and that way of working, then a business just fundamentally does not function. Even if they're not always aligned across all of the teams, there is a fundamental way of going from A to B to C. This is product operations as a function. This is, how do we operate? And so why does a business need it? Well, fundamentally, it needs it to function. Then we've got into, actually, the role. As I said, you know, in its current incarnation, fairly new. Although many people will possibly kind of identify as a programme manager, project management to a degree. You know, lots of different roles where we've kind of attempted to go at this in the past. And the role is then somebody dedicated to improving all of those elements. Improve those ways of working. Improve how those teams use data. Do their communications. How they do their planning, their regular planning sessions, et cetera, et cetera. And it's not always necessary to have a dedicated individual full-time for that. Only this week, I was talking to somebody else, and saying, actually, don't have to kind of dedicate a person, bring in a hire for this. Most of the time, you want to. But you can absolutely share this across, you know, good senior product people. The important thing is it absolutely does need some dedicated time to it. So if you are saying, "Okay, well, can we apportion one or several product people to this?" It has to be dedicated time towards saying, "How can we make this better?" Rather than how it has always been in many businesses. We'll get to it when we get to it. Or it sits on the side of the desk of a product leader and never gets worked on because people are just so busy.

  - Yeah, makes absolute sense. There's a few things that I want to pick up in there. It's been done implicitly anyway. And I certainly feel like that, you know. When I was a product leader at Vodafone, and implementing roadmapping tools, you know, that's very quickly started to become a full-time job or at least started to approach that level. People are doing this all the time. I work as a roadmapping consultant, helping teams to implement Aha! And often, the times is that the people I work with are product leaders or busy product managers themselves. And I'm taking some of that heavy lifting from them because we all know that it's going to be done by individuals anyway. But just making it explicit, I think, has been the visibility that product operations, and then formalising it more, has been what I've really enjoyed seeing over the last five years. And I liked your earlier statement about the difference between the function and the role. That completely makes sense to me.

  - And I think just, you know, just diving in a little bit to what you said there. Just because, you know, there is that, in any business where there is that, where there is software, we need that repetition. We need that schedule saying, okay, we're gonna look at our roadmaps. We're gonna update them. We're going to maintain them. But now, whether you go through, and that links up, obviously, into your, kind of your overall planning strategy cycles. And so whether you do that annually or quarterly or monthly or whatever you do, you still need kind of that cadence. And actually, all the organisation and the logistics that goes into that, you know, I'm gonna teach you to suck eggs, absolutely, here 'cause you know this far better than I do, that you don't go into kind of, let's say, your quarterly roadmapping session, and go, "Right, okay. So what should we work on next?" All of the prep work that goes into that, even if you are kind of having a round table and going, "Right, well, this is what we're gonna work on next," you bring in so much to the table about what has been successful. What are we gonna carry on doing? What are we not gonna carry on doing? What has all the research and insights told us? So all of that prep work needs to happen for that to be successful. And so just on that as a basis, all of that needs to be organised. And a term that, quite often, comes alongside product operations is logistics. We are the logistical side of this. To kind of go, hey, I'm not gonna do the work for you. I'm not gonna do all of that research for you. 'Cause that's your job. I'm not gonna kind of suggest to you what things should be in your next quarter for your roadmap. Product managers, design managers, research managers. But I wanna make sure that you've got all of this together. I'm gonna prompt you. And I'm gonna poke you. And I'm gonna help unblock you for where you can't do all of this sort of stuff. So you can bring it all to the table. And I quite often say as well. Once you've brought that to the table, to a degree, my work almost stops a little bit. Because then, actually, your job there is to kind of go, hey, make those decisions. Almost flippantly. And I always use this, and I think people sometimes look at me a bit funny, is I don't really care what it is we build or we deliver or we produce. I genuinely don't. I do care that we are producing and building the right things, the most valuable things, and that the people that are making those decisions are making the right decisions for the right reasons. They have all the information. You know, they looked at the quantitative and quality of metrics. That they are asking the right people. And if all of that information is on the table and it's all been discussed and people come out with what they feel are the right decisions, it's, firstly, not for me to say any different. You've made that decision. And it is the best one. And I don't care, really, what that decision is. Because, actually, that's your job to make that decision with all of that information. My job is to make sure that we've done all of that prep. The pre and the post work to make sure that right decision then happens and follows through.

  - Yeah, that makes sense. And, actually, that probably brings with it a nice clear differentiation between the role of product operations and product management there. And that means that you are less likely to be stepping on each other's toes or there for it to be friction or overlap. Very clear responsibilities there. You are an enabling function. And if you are enabling that function to then go and make the decisions that he's employed and is around to do. So I really like that. Talk to me a little bit more about the collaboration between product ops and product management. And is there or can there be friction and overlap? What you've just described is like, a clear differentiation. But have there been examples where there hasn't existed and you've needed to step in and provide some clarity?

  - I think the biggest area of friction that quite often comes up is how we're trying to kind of move from A to B in terms of our ways of working. I've tended to be the person that's setting up product operations for the first time in a business. You know, take it from absolute zero to one. I would say I've not worked in any business so far where there isn't absolutely the best intention there to want to improve. Absolutely. But product managers are very busy people. Like everybody. But I think more modern times than I certainly remember doing the role, there was a lot put on product managers to be communicating, to be collaborating, to be gaining lots of insight from every increase in sources of information to have a greater understanding of areas traditionally not in their wheelhouse. You know, the big financial areas of the business. Big areas of potential. External research. You know, areas of research that are not tied necessarily to the product itself. So as a consequence, naturally, they've all found their own groove, their own rhythm of how they want to work individually. And it largely works. So then the friction does come in say, hey, firstly, how can we help improve this? And there's a natural concern about that improvement. What is that going to mean? Ultimately, is it gonna mean more work for me? Am I gonna miss something out? And I think then as well, then having to kind of almost step out of oneself, and say, "Hey, I do have to change some of what I'm doing," or "I do have to do a little bit more work because now, I'm not just focusing on my work. I'm focusing on what's best for the business." And products operations can sometimes be almost a little bit of a friend to none in that respect. Because, actually, I'm not trying to help an individual. I'm trying to help an entire division. I'm trying to help the business. I report, ultimately, I mean, I report to the CPTO at Helios. I report to leadership and say how are we going to get the best outcomes and do the most valuable things in the product team? And I have a responsibility to make sure that they are working on those things, and they are producing, fundamentally, the best output possible. And so I'm quite often looking at these individual. I'm talking to these individuals saying, hey, what can we do to improve? What can we do to improve and align across all of the teams? And that's sometimes a little bit difficult for them to kind of want and have that time to put in and learn a new thing and learn a new tool and a new way of working. Do more work. Do another report. Do more valuable communications to the wider business.

  - Graham, I'm curious how you see product ops set up across different organisations. And is it always a separate team or reporting line? When we were first speaking, you said that sometimes, it can be intrinsic to some people's roles. And you've also had experience of coming in from naught to one from product operations. So in your experience, how is it set up across different organisations?

  - Yeah, it's a great question. And it's actually a very, very common query. I think, like most things, there's no set answer to this. My experience has said it's, well, firstly, it's not for a startup. You know, it's not your first product hire. It's not your second. It's not your third. It's not your fourth. A magic number, which actually kind of weirdly, and I'm not sure if there is a connection here, is the same as what's called Dunbar's number, which is 150. Dunbar's number says that, basically, 150 is the most connections or colleagues or whatever a person can have before those, all of those relationships starts to break down a little bit in terms of the closeness of it. And weirdly, I think that's the kind of, the roughly the sort of number that I always pick in terms of the size of business where product ops can then start to help. It starts to be needed. 150, 200, 250. Around that sort of size. Because in a business where you've got a product team, and, of course, if you are a SaaS heavy business, it could be earlier, absolutely. But you are looking for a business whereby 5, 6, 7 product teams, product squads, around that sort of number. Because what you then start to have is differences in how people work. Quite often, if you've gone from a startup to a scale up, that's very, very common. When you start to scale, you've got a mix of people that have been there from very early days. They've been used to just flying by the seat of their pants. Very scrappy. Doing everything. And they've just made that work for them. And then you've brought people in that have come from different organisations. Possibly bigger organisations. And they've got different ways of working. They've got different perceptions of what actually that scaling business actually is or should be. And so you've then got very different ways of working. So that's absolutely a time to start looking at this. Quite often as well, business, the product leaders will know that gaps are starting to appear. You know, teams are starting to work differently. People are starting to notice. An area that I focus on so much is on communication with product teams. I'm very passionate about good quality, valuable communication. Something that I call being audience-led. Actually tell the audience what they want to hear. Not what you want to tell them in terms of tech products. One of the things within that as well is when you start to get a bigger business, or become a bigger business, your colleagues around the business, particularly as they come in new, and as you are scaling as well, they don't see one squad, two squad, three squads, the individuals. They see a product team. They see a product division. They don't know, don't care who's doing what. They just know they want their products. And who does those things sometimes doesn't even really come into the mix. And so then when you're talking about communications, it's important that there's a consistency of what we're saying, how we're saying it. We can't have it whereby one team is absolutely going to town, producing reams of conversation, and another team is just going, "Yeah, here's our Jira tickets of what we did," and everything in between. That inconsistent approach is not helpful to the wider business. And what it does is it starts to break down the trust between the commercial side of the business and the technical side of the business. And that is such a key pillar of what product ops also does, is instils and maintain, or sorry, facilitates the maintenance of that trust between tech and the commercial side.

  - Amazing. Yeah, that completely makes sense. And you talked about the kind of the audience-centric communication. Having that. And I feel very similarly in the roadmapping space. I think too many product teams treat the roadmap as, this is what we are doing. And so we just want you to listen. And actually, the roadmap, really, is a communication and alignment tool. From my perspective, it should be audience-centric roadmapping. And the roadmap is there to invoke a conversation and tell your audience what they need to know so you get what you need from them. And it pleases me greatly to hear that, in a similar vein, you are kind of doing this audience-centric communication. Because that's what it's all about. But it gets missed.

  - Absolutely. It's exactly the same. You know, for me, the roadmap is a conversation tool. So it's absolutely just part of that. So when I'm looking at the communications that we want to make sure that are consistent, I'm talking about, you know, what's the roadmap? What are the initiatives that we're working on? What have we just delivered? What problems have we had in that delivery as well? What have we worked on? What are we working on next? All of it. What was our product demos that we do internally of the business? Very regular occurrences. All of these. And I'm doing this at Helios right now. We're aligning everybody to say, firstly, I want to hear what was the problem? What was the solution? What was the value? I always used to call, why is this awesome as well. When I worked at Cobalt two years ago, we embraced that so much every single time it went out. And literally, the headings were, what was the problem? What was the solution? Why is this awesome? Those were the three headings everybody ended up using. And I do that because I'm like, saying, look. Consistently, whether your demoing it, whether you are writing it down, whether it's part of a roadmapping product board, or what if you are using, I wanna see, if other people are using this, I want them to see what was the problem so that they can absorb the context of this. Whether they're brand new or they've been at the business forever, they need to absorb that context. What was the solution? That's obvious. And then why is this awesome? What's the value here? Because if you look at what the other end of the business needs, and this leads into audience, like communication. What does salespeople actually care about fundamentally? They care about what can I use to have more sales? What can I show off to customers? Similarly, with marketing, what can we put on our website? What can we market? What can we measure the impact of our conversion rates? Et cetera, et cetera. They need to know why is this important? And they need to know this because they need to take that in a context that they can understand. That they can regurgitate, almost word for word to say, "Hey, we've done this. And this is great. This is why you should buy our product." We need to think about that in a way that we are thinking about the audience and what can they absorb? So not be super technical about the what we have done. Actually go, sales totally aren't gonna understand that. What will they understand? What will they appreciate? What can they use? And this is a big shift for tech teams. It always is. Absolutely empathetic with that. About sort of saying, "Well, hey, how do we move from, you know, engineers previously getting on a demo?" And I'm all for that. I've got nothing against engineers doing that sort of thing. But the reality is they will like to want to talk about, they've done this. And oh, it's super exciting for this. Because they wanna share it with the rest of the engineers. And rightly so. Should be celebrating the work that they have done. Absolutely. But there is a middle ground to say, "Hey, we did this. It's fantastic. Do you know what? I'm not gonna go into the tech details of this. But it's awesome for everybody in the business because this is what it enables." Lovely. Absolutely brilliant. That's exactly what we should be doing.

  - That's such a good response. And it reminds me of some of the times when you post on LinkedIn that you've had a particularly engaging conversation with somebody who said, "You are awesome." When I see that now, I'm gonna pick up on that and bring that. And hopefully, that's useful for our audiences to say, "You know, what have we, what was the problem? What was the solution? Why was it awesome?" I'm gonna put that one in my pocket and reuse that one, Graham. Thank you. I guess the last question may be around, at least the core of product operations, is what are the key responsibilities of product ops? We've kind of talked about some of them already. But have you got more of a kind of a succinct way of being able to communicate to people what the key responsibilities of product ops are?

  - To a degree, yes, actually. It's always an interesting kind of elevator pitch. Fundamentally, it's an enable. It's the there to it enable and facilitate, predominantly the tech side of the business, in what it needs to do. Very good friend of mine, and my podcast host, Antonio Landy, she absolutely focuses slightly more on the strategic side. And it is absolutely a strategic role. But she really does like to hone in on kind of, look, we are there to do, make the business better. We are there to ensure that, you know, we are having a return on investment. That we are, you know, enabling growth. That we are helping with retention. And fundamentally, yes, we are. She's absolutely right with that. And leadership, you know, that's important for leadership to understand. My slight tweak on that is that we are doing all those things. But we are one stage removed from that. We are helping that. We are helping the product teams, the engineers to do that. And it's a reason why, actually, product operations is notoriously difficult to measure its impact. It genuinely is. Everybody I speak to in the product ops community have been doing it years and years and years. We've not got a good answer for this yet. Or we've not got a firm answer for this yet. Some people have metrics. And some people go down more the OKR route with this, and saying, "Hey, we did this project. You know, we built a product hub. And we can now measure how many people use that, for example." Absolutely brilliant. Yes, we can measure that on a project basis. If you're looking at kind of more KPIs, you know, much more, I guess almost intangibleness of what we do. It's so difficult. A framework that I've put together with this is basically a combination of NPS and CSAT scores where, because our customers are our internal colleagues. And so, actually, we can kind of measure a little bit through surveying and feedback to say, "How happy are you with what we've done? How more productive do you feel we are? How more efficient do you think we are from all of this?" Because ultimately, that's what we are there to do. We are helping people be more efficient, more effective. And how do you measure how happy somebody actually is? You know, in a really bonafide metric, it's actually difficult. So I realise I've gone off on a tangent there. I've kind of, you know, measurements and things like that. But fundamentally, my take on it is that we are there to help facilitate. We're there to help enable. And as a consequence, we focus on a variety of different things. Things that, actually, it's not always possible to predict. We are problem solvers as well. We are there to say, "Hey, we've got a problem. A problem being we are inefficient here. Or we want to introduce this there. Or is there a better way of going from A to B to C? Fantastic. Let's look at that. I don't know the answer. But let's attack that as a problem. And let's figure it out." Areas that we will absolutely be involved in. As I've said, communications, strategic planning, and enabling that strategic planning to happen. Have we got a calendar of events that go from weekly updates, monthly updates, planning quarterly, annual planning? Have we making sure the right resources are being pulled together at the right times? Metrics and analytics, dashboarding, absolutely, we'll be involved in. Again, not always the creation of these things. So at Helios anyway. And we've got an insights team that's involved in that. But actually, taking those requirements from what product need and what products should have. And making sure that the insights team are building that. That it's all aligned. In previous role, I did all of that myself as well because we didn't have any insights team. So it can absolutely be very varied in how much you'll get involved in these areas. And on the size of the business. Depend on the resources of the business as well. And that's what makes the role so super exciting, is don't always know what we're going to need to be walking into. But what we do know is we've been tasked with figuring it out. And we've got the backing to go and figure it out. Whatever you need. What tools you need. What support you need. Let's figure it out. 'Cause we know it has a positive purpose.

  - Brilliant. Absolutely great answers. And actually, it reminds me of my own journey where I've been a product manager at Dell. I was then a product leader at Vodafone. I brought in a roadmapping tool. Fell in love with it. Then joined the roadmapping company itself. But I really enjoyed the product operations side of bringing that tool in and making things better. And then when I worked for Aha!, I then did some of sort of side projects to keep my role interesting around product operations. How can we improve the support function? And how can we improve the tools that we use? That, for me, was very rewarding. And when I think now, when I left Aha!, and then I'm now a roadmapping consultant, I'm kind of, a part of that is product management. But also, the reason why I think I have a role and people hire me is because implementing a tool company-wide can be a massive burden on a product manager. And so where they don't have a product ops function, I'm kind of wearing that product ops hat in a way by coming in and helping them. So that was kind of one of the takeaways. And then the second one was, how do I justify the value that I provide when I do that for a client? And, again, that's been very difficult. How do you put metrics on the value? And so I'm actually gonna take what you've shared there, Graham, and try and build that into my business, which is actually, sometimes, we can't get empirical measurement on these things. It's just not possible, right? Sometimes, it's just a gut feel. So if you can bring that down to a CSAT or an ENPS score, and say, "How did you feel about roadmapping, let's say, before I worked with you? And then how did you feel about it after? Did I have a net positive effect? And can you say what that was?" I think I'm gonna find a lot of value in justifying what I do and why I do it without being tied down to metrics that potentially don't exist or be too dubious to measure that you probably couldn't attribute them to exactly the work that I've done.

  - Yeah, and that's the thing. There are metrics that you can absolutely kind of measure on, you know. How quickly did we adopt, you know, the roadmapping tool? How much time did we save? And time is quite often a factor here. It is certainly something that is more common to look at to measure because ultimately, once again, what are we doing here? We're trying to help people. We're trying to help them be more efficient in the jobs that we are doing. So actually, you're doing job A on day one. Actually, by month, end of month one, how long is that same job taking you to do? It might be minutes of time saved. It might be hours. And so, okay, look. You can attribute that. And then, okay, you can say, "Well, how many hours did I save? Okay, well we could match that to salaries. Okay, how much did we save?" That's a very common way of doing it. And valid. And then the, you know, very obviously, we then say, "Well, actually, then in those hours saved, I've been able to focus more on what I always call the primary reason why somebody is employed in a business." So engineers, for example, when you, the primary reason, the real, almost stereotypical view is, why are they there? To write lines of code. You know, fundamentally. Not to be offensive, but that's ultimately it. Why are salespeople there? To sell the product, you know. Why are finance there? To, you know, pay us ultimately, at the end of the day. And make sure money's coming in. Money's going out. All of those sorts of things. And product managers, you know, fundamentally, their primary role is helping build those great products, you know. What can we do to take them all, anything that we, so, anything that is taking them away from that primary role is something that we want to help them get more time back to do that with. And so, again, well, we can measure it on that respect. The big problem is it's ultimately, it's all a little bit, it always feels a bit amateurish. It feels like it's a bit too far removed. It's like, well, we did this over here, which saved your time here, which then allowed you to do that. And then you've got this metric that actually then fulfils the business. And it's so, it just always feels so far removed from that that it's a bit tenuous.

  - No, I get it. I get it. But no doubt the value is there. That's why product operations has had the surge in popularity that it's had. That's why professionals such as yourselves are active in that space. It is a very much needed function. And especially when it gets to, like you said, the Dunbar's numbers. Once it scales to a certain size, it's very much a required function, and probably gets done, whether it was formalised or not. So I love that. What do you think is a good practise in product operations that you see?

  - I think focusing on all parts of the product division. I mean, of course, actually supporting the wider business as well. And I think that's another area that sometimes gets a little bit overlooked. I'll talk about that in a second. Both common, and a common way of thinking, particularly from outside of our world, that we are just here to enable and facilitate the product managers, the people on the ground, okay? And just a little side note in case my friend Claire Hawthorne from America is watching this. I've tried very hard not to use the word support. She was on my podcast just last week when we were recording this. And when we first met, or started chatting on LinkedIn, it was because she doesn't like to use the word support for products operations. That we are supporting other functions. And fundamentally, she's right. It's not a supporting role. It's very difficult for me sometimes to not use that word because I think we are supporting. It doesn't degrade what we are doing. I'm trying hard, Claire, if you're watching this. It's a role that is there to facilitate everybody. And I include leadership in that. It is so important that we are helping product leadership. And I've seen some fantastic examples of myself and others, where we are there, helping that leadership to give them their time back as well. What a leadership, and product leadership, what do they bring most value to? Well, they're dealing with the board. They're dealing with the C-suite. They're evangelising across the business. They're bringing other very strong characters in terms of the other leadership around the business. They're bringing them on site. They are managing whole divisions, whole departments. As we know, that's a full-time job in itself. And so when they are wanting to kind of roll out something, they wanna push on something new, this is where product ops was always failing. Because that was then on their shoulders to do. They don't have the time to do that properly. So if we're wanting to roll out voice of the customer, or some new discovery processes, fantastic. They want it done. But actually, to do it properly, we need, who's gonna ask the, let's talk about customer interviews. What questions are we gonna ask? Who are we talking to? Where's all this information gonna store? We need a good database for it. We need the analytics to do it. Who's gonna review the analytics? On what case? There's a huge logistical element to doing all of this. And making sure that it's constantly happening. And product leadership don't have the time for that. So it ends up just being half-assed, put out the door. It gets put onto the product manager to say, "Well, go and figure it out." And they don't because they don't have the time. There's not that natural proclivity in all businesses to say we're all gonna just naturally work together and come out with a great answer here. So product operations then goes, "Hey, I know what you wanna do. I know what you wanna achieve. Leave it to me. And I'll go. And we'll just go and achieve it. And we'll basically report back when this is done." And product teams, product divisions don't have, traditionally, have that kind of logistical partner to go and do all of these things. And something to, you know, that I do with with my boss, Joe, at the moment is there's something that he's doing. And I'm like, Joe, why don't you give this to me to do? And a very, very simple example. We do our product demos after each sprint on a Friday. Gets recorded. And he really wants to kind of go, "Hey," to the rest of the business on Slack, "We've just done this demo. Fantastic. Here's all the value. Here's all the great stuff we've done." Really evangelising the business. This is why it's awesome. Absolutely. Coming back to that. And he's like, "I'm not always on those demos. 'Cause we can't be. We wanna put this out. We really wanna do all of this. But, you know, it's, take your time. I really want to do it." And I'm like, Joe, why don't you just let me take all of this because I've got the recording. I'm on these sessions. I can put all this. Why don't you just let me draught this, send it. You can put it out. It's right that you put this out because people will listen to you as the CPTO. That they will take notice of this much more than anybody doing it. So it still needs to be you to put it out from your name. But it doesn't necessarily need to be you to sit there for half an hour because it's gonna take you a lot longer to do than it does me to do. 'Cause it'll take me about two minutes to pull all this together. And he's like, "I appreciate that. But you are A, expensive. And B, you're not a PA. You're not an EA to kind do all this sort of stuff." And I said, I don't see this as that. I see this as an important function to make sure, as a business, we are properly evangelising what we do. And it's right that it's coming from you because you have more of a status to make people sit up and listen. So what I'm essentially doing is saying, actually, this is coming from me. And I want to use your status to do this. And he said to me, "This has saved me a huge amount of time. And we are actually getting some real good value out of this." He's having conversations with the leadership team and saying, "This is really, really helpful." And I'm like, then that's exactly what my job is to do here, is to provide value and facilitate the right most valuable things to happen, while giving everybody back the right amount of time. And I think that's a really important piece here. We talk about, the kind of the next conversation, which will be what is product operations not? That example is probably a slight more exception than a rule. Because product operations is not there to firstly, take away jobs from people, predominantly. It's there to remove jobs when they can be either automated or use AI or just aren't needed anymore. You know, we look at meetings that we want to take away because they're just not needed. We can combine them together. It's not there to do the low level work. It's not there to write PRDs because product managers either don't want to. Don't have the time. It's not to be first line triage for bugs and things like that, which is when products operations first started, what a lot of people were trying to push them to be is the... Yeah, so, again, gone off on a slight tangent here. But when products operations was first, you know, about four or five years ago, was first becoming a little bit more prominent, there was a real divide between, actually, product operations being this great logistical strategic partner, which is what it is and what it is now, and so being at kind of that director level, you know. It's a role. And I always have been kind of. I sit under the CPO. I'm on the hierarchy with the product directors, the design director, the engineering directors. Because it needs that level of, an element of level of authority. But also, that oversight across so many parts of the business. And the other side of it, sorry, the alternative view was, actually, this is actually lower than a product manager in the hierarchy. It's an assistant. It's doing the stuff that they don't want to do. It's the tea boy or tea girl. You know, to just go and do all of the little bits and pieces that the product managers wants to dump on people. And so you were seeing job descriptions that were like, "Yeah, you're doing first line triage support. And you are, you know, you're writing, you know, you're writing up meeting notes and bits and pieces like that." And I was like, that's not product operations at all. You know, that's not really a junior PM. That's not a PO. You know, that's not a BA's role. You know, it's a role that is part of product management. I'm sorry. And so what we need is to go and go, "Hey, how do we facilitate you doing all those things as efficiently as possible or automate and things like that?" It's been a journey, you know, to make sure that businesses understand where that real value of product operations is and where it isn't.

  - So Graham, I'm curious. You know, you've actually been one of the people in the community that I've learned a lot of product, about product operations from. But I'm curious. Whose advice on product operations do you listen to? And are there any resources that you would recommend? In fact, you mentioned your podcast, which we'll definitely put in the notes there. But who do you value in the community and what resources would you recommend people check out?

  - In terms of people, there's a incredibly tight-knit community. Oh, actually, not tight knit because we are very, very open to always sharing everything that we do. But we are an incredibly close community. We are very supportive community. And I'm actually amazed how close we are. And actually, it is that community of products operations that has absolutely shaped what it has become. It's not been business. It's not been somebody that's written a book per se. Although Melissa and Denise's book is actually very, very good. Really, really very good at a very high level. And so it's those community members that I learn most from. So people like Antonio Landy, my friend. Chris Compston, I know very well. Claire Hawthorne, who was on our podcast last week. She's incredibly experienced and well known. Deanna Salo, who I spoke to just yesterday. We had a great conversation yesterday about kind of some of the more common pitfalls we are now finding in both our businesses and how we address them. Jenny Wangerin. She's very, very popular. She has a lot of content herself as well. Mei Wong in Canada. She's fantastic as well. And we all learn from each other. You know, most of those people on that list have been doing product ops just as long. But we are all implementing it ever slightly different. And we're taking tidbits away all of the time, just in experiments that we've run and ways of approaching things. And I think what's important is we've all kind of got our own passions, areas of the, and mine is communications. Absolutely. You know, others are kind of really, like, you know, the data side of things. Others are really on the kind of the, you know, the organisation of the teams and the fluidity and the repeatability of processes and things like that. And, again, they all have, we all have kind of, I suppose our specialisms and our preferences. But there's so much that we can learn and we can, each of us are doing to just drag that part of the radar chart forward a little bit more. And then we're sharing all of that back into the middle. So some fantastic names. There are some fantastic communities out there as well. PLA has one. Product-Led Alliance has a subsection that's product ops. There is the Product Ops HQ, which is hosted by Dragon Boat that's dedicated. Really good. Ross Webb does Top Prods, which has really grown just recently in terms of product operations people and conversations that are happening there as well. In terms of resources, resources is always a very good one because, again, a lot of that is content that we've all produced. So I've got a newsletter. Jenny has a newsletter. Chris has got a newsletter as well that we all write to. Again, we've all have our own areas and specialisms. Because there isn't a great deal out there, I'd say, other than Melissa and Denise's book, which is very good. But it is kind of high level. What a lot of us end up then filling those gaps on is the tactical, the actual implementation of things and how we've done it. I'm writing a series at the moment that's my, each month for kind of what have I done in that month for the first year at Helios. So as I'm setting up product ops from zero, what have I done? What has worked? What hasn't worked? What areas have I focused on? And it's actually gone quite deep on those bits and pieces. Sometimes, maybe a bit too deep in terms of real tactical implementation of things and the successes or not behind those sorts of things. So in terms of resources, it is, again, finding those good people that are willing to share, that are sharing what they're doing. And, you know, and picking up from them.

  - Yeah, absolutely. Makes sense. And, in fact, you've shared some great resources there. A couple of the people you mentioned, we've got on the show already, and we've done some recordings with. So really thrilled about that. And we'll be sure to put a lot of your resources in the show notes. Graham, as we wrap up, I'm just curious. If you had to distil your philosophy of product ops into a couple of sentences, how would you describe it to others?

  - It is a role that is there to facilitate and enable people to do their best work is one. Two, the second, and it's actually an area that we we haven't touched on, is it's a people role. In the amount of importance, it's not about process. It's not about tech. It's not about tools and platforms and strategy. It's about people. It's about how do people work? And how do we help them work better, faster, stronger? And how do we embed new habits, new behaviours in them so that those new processes and new ways of working are very natural to them? It's about the people and how they produce their best work. It's not about just kind of going in and saying, "Well, there's a new way of working. And we're gonna all follow this step and this step and this step." It's about how do they individually and as a team do all of that. So it's a people role.

  - Thank you. That's been a bit, I think probably one of the most profound takeaways I can take from this is that recentering on what it means and why it's important and who it's doing it for. So that's brilliant. Graham, thank you so much for sharing all of that with me. If people wanna get in contact with you because they've really loved some of the stuff that you've been sharing, what's the best way for them to do that?

  - LinkedIn absolutely. I'm always on there. Would love to talk. Love to kinda continue to share. You know, hit me up on LinkedIn. I'm always on there, talking and sharing stuff, so. And from there, I publish my latest stuff on the newsletter, the blog that we have, sorry, the podcast that we have as well. It's all shared through there. So LinkedIn is absolutely the place to find me and get in touch.

  - Well, Graham, all that leaves me to say is thank you for being a friend. Thank you for being on the channel. And thank you for being so open with your learnings. I think that's what has made product operation's community so close. And it's people doing it for the people. So thank you for being with us.

  - Oh, thank you for having me. I absolutely enjoyed it.