Should ProductOps be centralised or localised? | Topher Fox

In Episode 7 of Talking Roadmaps, Justin Woods interviews Topher Fox, Director of Product Operations at Aerospike, to explore the trade-offs between centralized and localized ProductOps. They dive into empowerment, cross-functional alignment, tooling, anti-patterns, and why ProductOps is a force multiplier—not just a support role. A must-watch for teams scaling product capabilities with intention.

As a Product Operations professional, Topher’s focus is on empowering product teams with pragmatism, enhancing effectiveness and fostering collaboration across distributed teams. With his experience in Product Management and empathetic approach to operations, he has successfully improved ways of working at a variety of B2B product organizations.

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

In the next episode we are talking to Amit Godbole, Fractional CPO and Consultant. So watch out for Season 2 - Episode 8!

• Transcript

  - Through empowerment, it's not just the autonomy aspect, it's also accountability. So making sure they have strategic context for what they should be aiming for is also a responsibility of product operations. So working with product leadership, making sure the strategy is salient, making sure that it's easily accessible and understandable, well-documented and shared that we have good goals or OKRs or whatever framework you're using for those teams to action on, that's empowerment.

  - Welcome everybody to the second series of Talking Roadmaps where we're talking about product operations. And my special guest today is Christopher Fox, who is a product operations leader at a number of companies, but Christopher, why don't you introduce yourself. I think you'll do a better job than I could.

  - Christopher Fox and I'm currently director of product operations at Aerospike. We are the most performant realtime database streaming putting out there. We have a number of products to help you realtime access to your data, doing some really cool things. So keep an eye on our roadmap. Been in product ops for a few years now, just the normal sort of progression into the the function where I did product for a while and then I was like, oh wait, I really like systems and making things better. So what I do love the field. Just such an interesting thing and I'm super happy to talk with you today.

  - If you're enjoying the channel, subscribe, hit the bell icon and give us a like. Amazing, well, I can't wait as well. So Christopher and I actually met late, late last year on a collaborative article we were doing for a gentleman called Graham Reed, who's also well known in the product operation space. We are really lucky that we've got an episode with Graham being recorded as well. One of my first questions is why do companies need product operations?

  - This is a deeply philosophical question I think. It kind of relates to what is product operations, but from talking with folks out in the field, we often as product operations professionals that kinda liken ourselves to other operational functions within the organisation like sales ops or revenue ops or marketing ops or customer support ops. And they usually don't have to justify their existence. And so it's kind of weird to think about how we didn't have product operations before. And so I think that any company that's looking to sort of optimise how they do product, really corral the chaos that is product management work. You need product ops and I think it can apply to any organisation at any maturity stage. If you're starting out and you really want to be focusing on how you're gonna scale in the long term, it's a strategic choice. It's a really good choice to get a pro ops person in there. And if you're a late stage organisation, you find yourself slogging through all these meetings and everything's chaotic and nobody's aligned, then of course I would argue it's a little bit too late since you notice that. So I think companies need product ops just as much as they need product management.

  - Yeah, for sure, and from experience and you as well being both former product managers, it's one of the busiest jobs out there. It's not to say that other functions aren't busy, but product management has always felt like I've been pulled in 100 different directions. I'm surprised product operations wasn't one of the first operations types roles to materialise rather than one of the last.

  - Yeah, and again, this goes back to what product operations really is. And for me, product operations is about owning the product of the operating model within product and that touches every other part of the organisation. So you're already dependency managing across so many functions and you're doing really the same work that a product manager does. You're taking in feedback, you're doing discovery, you're doing research, you're experimenting with new tools and processes, you're launching things, you're teaching people about them, you're writing about them. That's a lot of work to do, especially if you don't have a development team. Imagine being a product manager for a software product and also being the development team and also being the sales enablement person. It's a lot of work, but it's super rewarding, especially if you have the right leadership, the right team, the people that are your champions to really push things forward, I think it's a really impactful role to be in.

  - Yeah, for sure, I'm excited by it. I think many product managers were doing operations if they... Well, if there wasn't a product operations function, a lot of product managers find themselves doing that by default, certainly. And for me, when I was at Vodafone as a product leader, I was bringing in tools and ended up becoming the implementation, the support, the guidance, the evangelising. I loved it by the way, I absolutely loved it. And I think if I'm wasn't doing what I'm doing now, I probably would go into product operations. But actually what I'm doing now kind of feels like product operations. I work with product operations teams to help implement tools and often that can be when they have a set product operations team there or it is just a couple of lead product managers taking on that role, although I do feel sorry for them because of course they're now trying to train users and things. So absolutely see the need of product operations and I loved what you shared earlier as well about kind of the buy-in and support and the organisational understanding of how important product operations is. And I'd love to talk with you about that in a couple of questions time. But I think what I'd like to understand maybe before that is how do you see product ops set across different organisations? Is there a separate team or different reporting lines? How have you seen it work well and from your experience?

  - Yeah, I think this is an interesting question that I would use a little bit of metaphor to describe. So if I were to ask you what is the equation for a business to be successful? Like what must you have on the left side of the equation and the right side being successful business, it'd probably be something like, oh, we need to have maximum revenue coming in at the lowest cost possible and providing value to be a successful business. If you start breaking this thing down, just like I was saying earlier, every function plays their part in this value stream. They need to sort of minimise cost, be efficient, maximise their value. And the way that this is traditionally done is by taking each function, each vertical. So product, sales, marketing, customer support, whoever that is, and they have their own ops functions and they kind of operate in their vertical. That's the traditional way that I've really seen product ops being set up. And if you read Melissa Perry and Denise Tilles' product operations, that's the traditional sort of org structure. But what I'm super heartened to see is new sort of org structures are being experimented with, particularly at Aerospike. What we're actually trying to do is centralise operations as much as possible so that we can strategize together. Because at the end of the day, I was saying earlier, a product ops person, for example, their product is the product operating model. And for them to be able to strategize with the sort of other product managers of other operating models and other functions is super impactful. If we have a business operations person that's working with executives to define that strategy and vision, and they're working with the product operations person and the marketing operations person, things can be much more fluid. We're not having conflicting ways of working, we're able to sort of strategize and manage dependencies together and time things well. And so I think there's a really interesting idea there where people will start experimenting with more sort of reporting structures are oftentimes the argument against that is, well they need to be within product because they don't need to be influenced by somebody else and they need to be very close with the CPO, but talk with my CPO all the time. He's a great guy and we're joined at the hip basically on how to run products. So yeah, I think it varies across organisations and is starting to change a little bit and be experimented with, which is super exciting.

  - Absolutely, and the lines of reporting don't have to be the same as the lines of communication. I think that's one of the important things there is that people might logically think that it fits under product management, but actually in some of the episodes and some of the companies I've worked with, operations actually has a seat at the table and it's treated as a completely separate vertical to product management for instance. And so I think really it's fascinating to see this role come out and see the benefits of who it provides. And I guess that probably leads me into my next question, which is who does product ops help in the organisation?

  - I feel like this is a very hot topic within the product operations community. I was recently chatting with Antonio Landy, Graham Reed and Chris Butler on the Product-Led Alliance dream cast product operations. And we were talking about this exact question, which is, is it the PM of PMs? Is that product operations? And I just could not help myself, but it's like, it depends, it really depends on your organisation, like hate to be that guy, but it really does. And I think that this is cause of the just variations and different permutations of how an organisation can function and scale and size and people and products themselves have to be flexible with that definition. And I think that ultimately my idea that, and this is shared by many others, that the product that we own is the product operating model. We help anybody that interfaces with that. The who is not really that important. It's the people that interface with that. And so product managers, yes, very directly impacted because they're the ones operating within that model. They're doing the discovery, they're doing the feedback triage, they're doing the roadmapping, all of that stuff. But we also help people across the business. And if we're not paying attention to our cross-functional partners, so product marketing, sales, sales enablement, the executive team, I don't think we're doing our job well. And so we help everyone.

  - Love that, absolutely. It's kind of like understanding where the need is interfacing, having those communications filling in some gaps. Yeah, that's perfect. So what would some key responsibilities of product ops be then, or ops be? What do they typically do for people that may not be aware?

  - I think you have to kind of think about the product development life cycle as a whole to really understand how product operations can help. If we think about a traditional sort of, let's call it like a double diamond framework. We've got our product discovery and our product delivery. I would argue there might be a little third one there about post-launch monitoring and measurement and how does a feedback loop, but think about the ways that people operate within that context. And this is really me borrowing from the product operations book a little bit, but I'll tweak it. Those are is the pillars that we have, the strategic pillars, so tools and practises. And so the things that we use every day maybe use are product board, maybe use Google Sheets template or slide deck template or something like that, the practises around those. So how we actually operationalize these tools, how we interface with them, how we do our business, our product principles, all of that. There's the business data and insights sort of pillar where we're interfacing with the rest of the business and we're looking at, okay, how are we doing on sales? What's our bookings, what's our adoption, all of those things. How do we make that visible back to product teams so they can make decisions faster, minimise that time for discovery. And then there's also customer and market, I'll call it literacy and empathy. So really understanding the market, having the business acumen to say like, oh, this is a headwind, this is a tailwind. Being able to understand how things change and how we should react or respond to those things. And then customer empathy is so important. I mean, we've had all of these ebbs and flows throughout the previous decades of, oh, we're gonna do scrum or we're gonna do CEO of the product, or we're gonna do design-led thinking. And I think customer empathy is at the core of all of this. We have to understand who we're serving and what they need to accomplish because that's the job of a product at the end of the day. So these three pillars, tools and practises, business data and insights, customer and market literacy and empathy. I think there's a fourth sort of foundational layer here, which is a culture of empowerment. That means accountability, autonomy, true empowerment of those teams. And so this can touch on many different things that might be the team topology. So working with your product and engineering leadership to staff appropriately, to make sure that we're serving those value streams. That making sure that it's not always top down, that there's always a bottom up sort of release valve for planning and ideas, making sure that we have good visibility on the metrics that matter. We're not tracking story points for every team, hopefully. And we're really trying to over index on what are the outcomes that we're shooting for, how do we measure those and how do we follow up and react, the reality that happens day to day. So it's a big answer, but it's a big product that we own.

  - It's big boots, it absolutely is. Have you seen times when product operations has helped product management teams to be more empowered? So I work with a number of clients and I still can even easily identify through even looking at the roadmap how product management is treated and operated within a company. The roadmap can be quite telling. Have you found times when product operations has been a really powerful ally for making product management changes and kind of the way that companies react to product management and to make them more empowered? Have you seen that kind of product ops providing that support and role?

  - Yeah, yeah, absolutely. I think that comes down again to establishing this culture of monitoring and measurement where it's more about the outcomes. If we're, we'll talk about anti-patterns real quick, like if you're constantly in inspection mode, if you're constantly just looking at the burn down charts and needing at business metrics and stuff like that and not really having a conversation, then there's probably some disempowerment happening. No, it's about the number of features that have been shipped, probably pretty disempowering. But if you give someone a bar to rise to, if you establish those roles and responsibilities, which a product operations person should be doing and saying this is what the product team is here for, it's not a bunch of feature requests, it's feedback and we action on that. Those are insights, those are signals for us to operate on. That's empowering because it allows them to come up with a solution. We also need to, through empowerment, it's not just the autonomy aspect, it's also accountability. So making sure they have strategic context for what they should be aiming for is also a responsibility of product operations. So working with product leadership, making sure the strategy is salient, making sure that it's easily accessible and understandable, well-documented and shared, that we have good goals or OKRs or whatever framework you're using for those teams to action on, that's empowerment. So roles and responsibilities, strategic sort of frameworks that you have, that's all something that a product ops person can help. And I've seen many organisations where product ops is kind of stuck in a culture where they can't do that. And that's really sad to see. They're mostly just working outta spreadsheets and doing project management. That's a waste of the function in my opinion.

  - Totally, I feel myself getting emotional there as you're starting to share some of the things that product operations were doing because I'm like, Christopher, I needed you at some of the companies that I was product manager at just to be able to be that ally, to be that support there. And it kind of makes me think about how do companies go about justifying having a product operations function? What would you say to them?

  - Ultimately, I don't think that product operations should have to justify itself. Like many different parts of the organisation have their own ops functions. But I think it comes down to what are the problems that people see? What is the trust in the product function? Is it nobody knows what the roadmap is or nobody knows what's coming out. Like there's something there for product operations to do. Do you want your product managers to be focusing on making the products better for their customers and impacting the business, or do you want them focusing on how to update this spreadsheet so that some exec... Or roll out a tool or something like that just so that we can feel a little bit better about ourselves. Those are wins, those are good wins and I love doing those things, but for me it's more important to enable those functions to impact the product, to impact the business. That's the most important thing. So we're an enablement function and so when talking about justifying product operations, there has to be that need or that problem to solve first before you go in and be like, you need product operations for all of these reasons that you haven't realised yet. And at the end of the day, there might actually be a reason not to have product operations at that time. I think everyone can benefit from it, but there might be a pragmatic decision for the business. They're super low on cash, they don't have right product market fit. Like they're not even at the stage where they need to scale communication at all or something like that. It just really depends. When you can look forward in five years and be like, ooh, this is gonna be a mess, you should probably start thinking about hiring some operational people. So justifying I think starts with that need. And then justifying can't happen without real buy-in from leadership. And I mean all leadership, I've seen it where the CPO is well bought in to product operations and the need for it, but the CEO is not, that can be a really terrible environment to work in. I've seen it where nobody's bought in and engineering was like, ah, you need your own operations function, also did not work well because that product operations person, like all of the product managers also needs to be empowered. They need to have the leadership buy-in to be able to affect change, to convince people this is the experiment that we're trying and trust me, like we'll make this better together. So yeah, it's a hard thing to justify it and there are many different techniques you can use to ask the right questions to get people to see the value of product operations. Again, Melissa Perry and Denise Tilles book is excellent at talking through the exact questions that you should ask. So go read that book 100%, not a paid endorsement. Really great book to jumpstart the product ops function.

  - Superb, well that's a great response on top of a great book, great starting point. And one of the things that I'm starting to think about is that personally I feel that a certain level of product operations will already be done, even if it's not in a formal function, I think it will be carried by some product managers. So maybe making that from implicit to what they do to making it a little bit more explicit and saying, look, these are the extra things that we are doing. I mean, I get this time and time again when I work with product managers to roll out new roadmapping tools or whatever, it's a big weight on their shoulders. I'm trying my best to help them, but you can see it on top of their existing workloads. And so I think if they make that more explicit and say, look, these are the operation stuff that we're already doing, and it would be really helpful if we offloaded that onto a proper operations function so we can focus on these and just kind of split out those roles a little bit more might help and even just testing and learning. Go and find a consultant or a contractor for three or six months and see the uplift that it gives in order to then justify that as maybe more of a permanent function.

  - Yeah, absolutely, and also do research on how other teams operate. There's been this, I won't call it an explosion, but there's been this trend of companies publishing their handbooks, which I think is really interesting and very, very cool and always begs the question of do they really work this way? But I think recently Duolingo just published one, there's a company called Post Hog that has a really good published handbook out there. GitLab is is pretty infamous for their stuff as well. But it's so interesting to read those and to sort of internalise these, I don't like the term best practises, but their sort of internalised pragmatic practises I'll say, the things that work well for them. And then trying to think about how would that play out at my organisation, what's my operating system like? And so you can really take these things and apply them to your own organisation and get a pretty decent start at a good scaled operations function. But to go back to the previous question, like if your product managers are spending I don't know, more than an hour a week on like updating a slide deck or like filling out a spreadsheet or they have a really hard time organising a market launch or something like that, those are things that we can optimise. They have been done before, those are cookie recipes. You ask ChatGPT and come up with a better way. Like that's easy stuff, that's low hanging fruit.

  - I love the thing you said about best practises 'cause my last next question is to ask you about them, but I'm actually a big fan of actually saying good practise. I think best practise is taking other people's good practises and making them work for you, not taking other people's best practises as your own, that's how it has to be. So totally agree with what you've said there. So let me ask that question. What do you consider to be a good practise in product operations? And I know that's such a wide question, but I'm wondering what comes to mind.

  - Identify the constants, identify the variables, and then respond. And just like the equation we were talking about before, if I look at scrum or OKRs, there are constants in there. Now, apply those to your organisation, do they match? If there are any mismatches, then it might not be the framework for you or you might have to do a little bit of retooling or thinking about it, but really come up with the problem statements. And I think this is back to product management philosophy. If you're leading with a solution, it's probably really risky because then you're gonna build it and then test it and then have to rework if it's the wrong thing. Start with the problem that you're trying to solve. So when it comes to good practises or pragmatic practises within an organisation for product operations, I think it's really using those pillars and starting out with that and then coming up with a list of like where you fail and then applying product management principles to this. Now there is a difference I think between an internal function and how they would operate and how a product team would operate. And it's actually a benefit because you have direct control over the product that you're asking people about. And you could say the same about a software company, but they have to launch something and like get other people to onboard and use it. Your journey is so much shorter. Like you're a mad scientist in the kitchen inventing the microwave and like you're cooking food while you're doing it. So like, it's so much easier for you to get feedback, which is a bit of a loaded term here. I'll touch on that in a second. It's so easy for you to get insights and feedback from the people operating within your model because they're right next to you. You don't have to go through an account executive and then schedule a meeting or whatever that is. And of course there are ways to do that better on that side too. But when it comes to understanding your operational model, that feedback is so accessible to you. And also don't discount the fact that with an operational model, if you're doing it well, you should have built-in measurement for yourself. You should have the ability to say, how much volume of things did we do in this process? For example, that's your starting point. You might also have an ENPS survey, an employee NPS survey that you sent out. Maybe pair with that person and start to get some questions in there that you might care about. Do product teams trust leadership, for example? Do leadership trust the teams? If you really dig into like how people are interfacing with each other, you might have some good leading indicators of where you should solve problems next. So developing your own roadmap internally for yourself. So there's so much to do there.

  - Yeah, absolutely, and in fact, I'm gonna jump ahead to a question there and then we might pop back again, but you've just said it, do you need a roadmap for your product ops function?

  - Not just a roadmap, man, you need a roadmap, but you also need a strategy and you need a vision. You need all of those things. You need a feedback channel too. People need to know who to go talk to. And in fact at Aerospike, we just onboarded a tool called Product Central and we built out a feedback intake system where there's a form for anybody in the company to fill out feedback for any of our products. They put in a description, a use case, pain points, all that stuff. We got some cool AI stuff in the background too. One of those products that they can pick is Product Central itself. One of those products is also the product operating model. So the higher level, like how we work. And so, yeah, exactly. And so I manage all of my feedback the same way that my product managers do.

  - So Christopher, I'm curious what sort of anti-patterns or bad practises you regularly encounter within product ops? What do you see?

  - Yeah, I think there are a couple of things that I've seen where just talking to other professionals, it's so apparent that this is probably the worst thing that you can do, which is doing too much at once. Too much too fast, all at once. The big bang transformation as we'll call it, that is a recipe for disaster. If we think about a product, if you launch a new product with no documentation, no enablement, no early adopters, no evangelists, you're gonna have a bad time. You're gonna find quickly that you've built up a lot of debt. And so when it comes to product ops, if you're launching an entirely new product development lifecycle, a totally new system all at once, there's a learning curve and in fact, many operational changes that you will encounter as a product operations person, you're not gonna really see results for some time because of that onboarding lag. So you may be defining success criteria for yourself where it's like, oh, we want this many people to use this system in this amount of time. We wanna see these metrics and stuff. You may actually see tanked metrics for a good quarter. Now if you're doing proper enablement and really following up and making sure that people have a channel to come back to you and ask questions, like that can be a really good way to accelerate that change plus leadership buy-in. But the number one mistake you make is thinking that you can do a big bang transformation overnight. It's not gonna work. The other thing that I will see is framework only, where people start with a framework and then they don't touch it or they don't do the proper amount of discovery and they're like, ah, yeah, scrum, that's what we need. We're gonna do scrum, everybody do scrum. And they don't account for the nuances of the organisation. Frameworks are useful starting points, they're useful templates for you to build on to make useful for yourself. But if you take them as dogma and implement them as they are, you're probably gonna find out pretty quickly that they become obsolete. So yeah, big bang change, framework only. It's usually a recipe for some bad times.

  - Yeah, and you hopefully wouldn't do that in the product management space as well. Again, you can't take the Spotify model and apply it to yourself 'cause you're not Spotify, you're not the same part of the company, the same ethos, the same internal culture, and even Spotify didn't do it the way that they described anyway. So there's kind of like, you're right, you have to take this framework as inspiration for your own work or your own working practises, but don't take it as as dogma. That makes so much sense. And is there a pet hate you hate to see with product ops? I know it kind of fits into that as well, but something where you're just like, come on, we're better than this. What pet hates do you have?

  - Yeah, I think it's really the framework thing. If I just see it's like we're just gonna do rice and we're never gonna change any of the prioritisation to mission of like, you can do better. Like that's not directional. Oh, here's one, probably not that hot of a take because I feel like most people have come around, but like only using NPS as an indicator of success for your product is like don't do that. Just like using one metric. Look, don't get me wrong, North Star metric is great. It gives you good and plus it has input metrics underneath, so it's not just one metric, but like, it gives you great directionality and alignment. However, if you're only focusing on that one thing after your sort of experimental period of measurement and you just keep going, you're gonna be shortsighted and you're gonna miss some other things because any change that you make, it's like the butterfly effect. When your product releases a new feature, it's probably gonna change something. You may not know what it is yet or immediately, but it is gonna change something. Same thing with operational models too, by the way. You change the way feedback submission works, you didn't account for the 20 other processes that you didn't know about. Now those things have to go away and you have to explicitly tell people that. So yeah, that's a pet hate.

  - Absolutely, no, it totally makes sense and thinking about it's what you would do as in product management as well. That's the thing that I'm thinking of. You mentioned at the beginning, it's like... We could describe it as the product management of product management. That doesn't mean it's superior to it, it's just apply product management practises to product management. And I'm a big fan of applying roadmapping practises to roadmapping. It's kind of just apply your own craft against your craft. And so that leads me to a question maybe talking about product ops and roadmapping, which is what is product ops involvement in roadmapping?

  - I hope I don't offend you when I say this, but I think that it's time for us to recognise that roadmap is a very loaded term and that it means something different to so many people. Roadmap is a class. It is a category of a thing that we can use to communicate intention. And so when it comes to product ops involvement in roadmapping, it's about recognising, okay, which roadmap for who, what information, when do you need it? What's the granularity? It's figuring out all of those requirements and then looking back at the broader system and saying, okay, how do we enable that? And how can we make this in such a way that our product managers don't have to spend an entire week or scramble before some QBR for a customer to build out that roadmap. How do we sustainably and dynamically update this roadmap on a regular cadence? And so that goes back to tool selection. How flexible is it for your needs? What types of roadmaps can you create? And then what levels can be enabled by that? One tool that I really love product board, they do this pretty well. Like they have objective based roadmaps that you can do now, next, later, you can do timelines. So whatever granularity you want there. And one of the biggest sort of complaints about it for a long time was, yeah, yeah, all well and good. It's in the tool, it's dynamic. I can even do a portal with customer friendly messaging. But what about slides?

  - I remember now from a previous conversation.

  - Executives really want slides. And so it's like, it's really cool. I think they announced this earlier this year, but like exporting to slides, like, come on, like, let's go, let's go, because that really allows you to make it flexible with the understanding that you're gonna have to tell people like, this is a snapshot, it's not up to date. We can't dynamically insert this into a Google slide. Like it's all of those caveats. But if you can find a way to automate the pain of creating a roadmap with the right information for the right audience, then you're doing great at product ops. Yeah, I think it's approaching it with the product mindset.

  - Totally, couldn't agree more. Roadmapping is a loaded term, it's a nebulous term. It means different things to different people. I'm not even a fan of creating roadmap templates because the classic product management, it depends. What does your CEO expect to see? What did you think that he meant or she meant. It's those things completely and I think it needs disambiguate. It needs defining better as a term so that people have that understanding because if a roadmap is there to communicate and align, you need to know what it is that you are managing expectations with and communicating and aligning for. So totally agree, I think that's a great answer. As we start to wrap up, I'm curious, whose advice on product ops do you listen to and are there any resources that you would typically recommend?

  - Well, we've already talked about Melissa Perry and Denise Tilles. That book is an excellent start to understanding product operations and I think to really understand empowerment and what it means. Also look at Silicon Valley product group. So I look at Cagan stuff like everyone else does, transformed, empowered, inspired, and even dip your toes into Loved. That one's about product marketing, but all of those books will give you really great insights into some of the ways that the best companies in the world operate now. Best practises, good practises that you need to account for context for. So Cagan, also John Cutler, oh my gosh, the guy is a sage, he's doing some excellent stuff. He just started a YouTube channel. Really great like five minute-ish videos on different concepts and frameworks that you can use and thought models. So I definitely follow his stuff, subscribe to his newsletter. You already mentioned Graham Reed. I would say also Mei Wong and Tony Landy, all those folks practising out there in the product ops space. I definitely follow what they do, but if I'm thinking about frameworks and philosophy, Melissa Perry, Denise Tilles, Cagan and Cutler, those are all really great voices to start with.

  - Yeah, and we are really humbled to have had a few of those on the channel already. Marty Cagan's joined us, we've spoken to Denise Tilles, who's actually gonna be on a product op episode later on in the series. So yeah, we're super thrilled to have them and yourself of course, as well. I'm wondering as we start to close, if you could distil your philosophy of product operations into a couple of sentences. And it's okay if you go over and it's also okay if you go under, but what would you describe it as?

  - I think that product operations is one of the most important force multipliers for making the product organisation more impactful for the business. It is a natural evolution of product management, of a product-led organisation to focus on maximising the impact of it. Yeah, I think that's really the heart of it and that should lead you into all of these different pillars that I talked about. But ultimately, you've gotta be a good product thinker. I think that you don't have to have been a product manager to be a good product ops person. You just have to be curious, you have to be empathetic and you have to be driven for change.

  - Superb response, yeah, I love that. And I'm wondering is there anything about product operations that I should have asked you but I didn't?

  - Yeah, I think one of the things that we don't often talk about in product operations is the metrics of success themselves within product operations. Because if we take the product analogy further, you have your own KPIs. Those can be very output focused, of course, just like a product, but you wanna focus on what are your indicators of success and how do those matter to the rest of the business? So not just the product organisation, but also other parts of the organisation. How do you know that you're succeeding as a product operations function? So your strategy and your vision and your KPIs, you gotta define those. And one of the things I often see people talking about in product operations is when they say metrics, they're talking about product metrics, like usage metrics, like adoption metrics, sales metrics. Those are all well and good and very important and you should drive those. But what about, how valuable is the feedback coming in to my product team? How much does it impact the roadmap? How valuable are the conversations that we're having with customers? How much time does it take us to go through a research or discovery effort? Those are really important things for you to be able to measure. Your product, that PDLC, you should be able to measure and optimise each stage, each step along the way and figure out how can we do better? How can we stop the swirl or the churn or whatever it is? How can we onboard people better? How long does it take for a product manager to get up and running in your organisation? I think we have to be more introspective sometimes as product operations people and that's not something I've often seen talked about.

  - So Christopher, it is been absolute pleasure to speak to you in today's episode. I've loved our chats beforehand. It's great now to be able to share you with the audience. I wanted to give you an opportunity just to let people know if they're inspired by some of the things that you've said or they want to get in contact with you, what's the best way?

  - Don't hesitate to reach out, find me on LinkedIn, give me a follow, gimme a connect, send me a DM. I will chat your ear off about product operations, I promise. Don't hesitate to set up time with me. Big things coming over the next year. I'm gonna be partnering with a few names out there, the Product-Led Alliance, doing some content for them as well as the great folks over at Product Board too. So keep an eye on the feed and don't hesitate to reach out.

  - Christopher, thank you once again for speaking with me. It's been an absolute pleasure.

  - Yeah, thanks Justin.