Should ProductOps work the same way everywhere? | Chris Compston

In Season 2 Episode 1 of Talking Roadmaps, Phil Hornby interviews Chris Compston to explore the question: Should ProductOps work the same way everywhere? They break down the role of ProductOps, its impact on scaling product organizations, and when a company truly needs a dedicated ProductOps function. Chris shares insights on how ProductOps supports product development, strategic alignment, and decision-making at scale. They also discuss how different companies structure ProductOps, the evolving role of product leaders, and common mistakes organizations make when implementing it.

Chris Compston is a Product Ops Consultant and Advisor who partners with product leadership to maximise the performance and impact of their product organisations. By ensuring teams are strategically aligned, value-driven, and outcome-focused he helps increase the quality of decision-making at scale, empowering product teams to deliver impactful results.

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

Should ProductOps work the same way everywhere? | Chris Compston

Chris Compston and Phil Hornby

In the next episode we are talking to Antonia Landi, Senior Product Operations Coach & Consultant. So watch out for Season 2 - Episode 2!

• Transcript

  - And I asked them, well, the first question I said is, "What is product to you here? What does it mean?" Because you have an app, you have a website, I can order things, but I also get ingredients and it comes packaged and there's a box and there's things in there with instructions, but I also have something that I make out of those. So what is the product to you? And to them, the product was the end, the end point, the meal, the thing that has been made, the thing that the person is gonna cook and eat was the product to them.

  - Welcome to "Talking Roadmaps," where I used to say, "We talk about the good, the bad, and the ugly of roadmapping." But this is season two. In season two, we're mixing it up. This is episode one. Today, I'm joined by Chris Compston and we're gonna dive into product operations. Just a secret. That's all what season two is all gonna be about. So, Chris, can you introduce yourself for us?

  - Thanks, Phil. Very excited to be here on the first product operations podcast I'm having with you folks. So, yeah, my name's Chris Compston. I'm a consultant and advisor focusing on, surprise, surprise, product ops and product operations within organisations. I work with clients to introduce effective product operations as a function essentially to maximise the performance and impact of their organisation teams and their people.

  - If you're enjoying the channel, subscribe, hit the bell, and give us a like. Okay, I love that. Yeah, so it's kinda product management for product management.

  - In a way. However, I would broaden out slightly, I don't think product ops focuses purely on product management, I think they focus on product development as a whole. And obviously that encounters many, many different functions, many different aspects and many different levels of product.

  - Okay, I've gotta unpack that before I even go anywhere else. 'Cause to me product management sits next to product development as a peer, but you talk about it as if it's part of product development.

  - Differentiating here, I'm saying this is a terminology thing, right? Product development being the development of products, the building of products, the deciding what we're going to build, understanding what customers may value, what kind of business impact we're kind of aiming for. So the development of products rather than the function of development or the action of development.

  - Yeah, and I guess, and here's my philosophy, product management is about more than developing. It's like often the right choice might be to change the marketing or change the pricing or the business model, and that to me is a part of product management, which kind of hence why it's to me it sits as a peer to development of a product. Well, it's interesting. It's often a conversation I have with people about that, that subtle difference of the, I guess the broader church versus the deeper church.

  - Yeah, I mean, overall it's doing product, right? Like what is doing product, what is defining, what is it we're going to build? I mean, you need to understand, the customers need to understand the business, you need to be strategically aligned in the development of products. If you're developing products, it could be services that you're building, you could be thinking more around what you're gonna be removing from the product, you could be doing nothing but changing something on the backend that has a customer impact terminology. I think this is like really important actually. And I talk about this quite a lot with clients at conferences, how we use certain words is really, really important. And the way that we define them, the terminology that we use. I talk about this a lot when I talk about high-performing teams. Well, how do you define that? What is high performance in your world? What is effective? What is efficient? All these different words that we use. Even when it comes to things like, "What do you call an objective? What do you call a goal? What does strategy mean to you," all these words have to be clearly defined within an organisation because they all operate differently. And we can't take up previous biases and previous experiences and apply 'em to new organisations, which is where the life of a consultant can be quite exciting, I think.

  - Yeah, I was actually having a conversation with someone on LinkedIn the other day where they were saying they were struggling to recruit product managers because they were finding that product managers with four or five years experience hadn't owned a product end-to-end. And in that company, a product manager owned a product. It was like one p.m., one product. And I said, "Well, it's not typically how you'd set up a product organisation today, but what do you mean by a product?" Because where do you draw the line? Like, to Facebook, search is a product and it has multiple people looking after it. To us as a user, it's just a feature.

  - I was speaking to, this was a couple of years ago now, actually during an interview, speaking to one of the food delivery service, you know, the package ingredients being delivered to your house for you to cook. And I asked them, well, the first question I said is, "What is product to you here? What does it mean?" Because you have an app, you have a website, I can order things, but I also get ingredients and it comes packaged and there's a box and there's things in there with instructions, but I also have something that I make out of those. So what is the product to you? And to them, the product was the end, the end point, the meal, the thing that has been made, the thing that the person's gonna cook and eat was the product to them.

  - Yeah, I mean I think the title product kind of does us a disservice sometimes. It's a historical footnote almost. I mean, if you go back even farther, it's brand manager as well. And really we're there to, I mean I like to use the phrase create customer and business value at scale. And the at scale is the important part. 'Cause if you're not doing at scale, you're definitely not applying that product mindset. But if you're not creating customer and business value, then what the heck are you doing? But yeah, I think it's time for us to dive into product ops a little bit. So tell us, Chris, in your opinion, why do companies need product ops?

  - So I think, firstly, what we should probably do is distinguish the difference between product operations, which is all lowercase, it's a thing that we do, and Product Ops, which is capitalised, it's a function, it's a team, it's a group of people, it's an individual that's been hired to do operational work. I don't think it's the case that organisations need product operations, they're already doing it. I was even thinking about this earlier today. Even a startup that has a couple of co-founders, they're still doing operational work. The moment that they say, "This is how we're gonna communicate together. This is how we're gonna make decisions. These are the tools that we might use to build our new product or service," or whatever it is they're looking to do, they're already doing operational work. They're already having those questions. The question is more when is the point where we decide that we need to hire product ops as a function, as an individual, as a team, at like what point do we make that decision? That question comes up a lot in the product ops community, usually from people that are either new to product operations or are interested in actually building a function of what it means for them in their organisation. We actually get quite a lot of product managers coming to the community and saying, "I'm doing a lot of operational work. How might I found a product ops function?" And it's not a question of scale. I don't think we can say when you get to 10 product teams, when you get to 20 product teams, you need X number of product ops people, product ops managers. For me, an organisation needs product ops when their people, the cross-functional group of people that are developing products, building services or doing everything that a good product team should be doing, they're spending more time thinking about how they're working and sharing how they're working with the organisation than focused on delivering customer value, sorry, understanding and then delivering on customer value that achieves business impact. If they're spending more time on the former, thinking about how they work and less time on the latter, what they're actually doing and trying to achieve it, that's the tipping point where you go, "Maybe we need someone in product operations to help us out here."

  - I mean, 'cause I reflect from my own career, like product ops was always there. It was usually a part-time job for someone in the product organisation or for several people in the product organisation. We didn't have a name for it. It was just something that got done. I remember, from the process perspective, that was a hat that I well wore within my last organisation. From analytics and data side of things, one of my team definitely was the person wearing that hat, and kind of bringing that to the broader team of how we worked, you know, the ways of working, and so on. And so it was interesting as I saw the title and the function emerge. It's like, yeah, that's who was doing it and a bit of me as the head of. Okay, so I can kinda see how that was part of what we were doing and I didn't know what to call it back then.

  - Yeah, I mean it's interesting that we say that, and I hear that quite a lot. It's like, "Oh, I kinda thought that was part of my role," or, "Isn't that what product leadership should be doing?" I think it was, I'm gonna age myself quite a lot now, but I think it was about 12 or 13 years ago I was a UX designer. And probably about five years before that, there were no UX designers. There was nobody with a specific role of focusing on designing the user experience of the products, the services, the websites, the e-commerce that we were building back then. There was no one doing that. It was a group of people that were doing it. It was the developers mostly and maybe someone that was more in a ownership, product ownership type role. They were the ones drawing the wireframes, deciding what the interactions would be and what the experience might be as you go through the flow of buying a product online. And then we found that we needed specific roles to do that because maybe the products and services we're building weren't quite as effective as we hoped they would be so we need someone that has some like real key skills and capabilities to do that work. That's now formed into what we now really call product designers who are doing a bunch of different things. You would never build a product nowadays without a product designer, you know? And, you know, obviously if you're building, if you're more in startup world, you're probably all mucking in together to do it, that's fine. But there's definitely a tipping point where you go, "Our product's not really that great anymore. We've maybe found a bit of product market fit, but the experience isn't great, the interaction's not great. It looks a bit crappy. Let's hire a designer." And from that point on, you never really get rid of a designer, that's like a major part of the product team nowadays and a product organisation. And I think we're just here in product operations now where in probably, and there's difference between UK and US, would I say probably Europe and US product operations a little bit more established out there. But maybe in like 5, 6, 10 years we'll see that product operations in certain types of organisations is more of a dedicated role that is an essential role like user experience design was finding 10, 15 years ago. Purely because of what I said, is we want our teams to be focused on customer value and business impact, not on the operational side. Not fully on the operational side.

  - Yeah, I mean it's interesting. I remember the first time I worked with a UX designer and had the epiphany of the value they were creating. Probably around 2012, something like that. And this was a startup event. And we called them the lesser spotted designers 'cause they were the least frequent to turn up at events. So when you were forming a team, you grabbed one quickly. And Simon was awesome, and he exposed me to so many kind of different tools and techniques that kind of opened a lot of my eyes. And yeah, so that power there was definitely there. And I mean this is one of my favourite books. I tried to look behind on my bookshelf, there's one called "User Interface Design" for engineers. And this is probably from the early '90s. And it talks about, for example, how Excel won the war against Lotus 1-2-3, not because it was really good at financial modelling, which Lotus 1-2-3 was streets ahead, but because it allowed people to keep lists and therefore became the thing that is now the greatest shadow IT product on the planet. But yeah, the crappy user interfaces you used to get 'cause just the engineers were doing it.

  - I mean the title of that book is interesting as well, because what do you want a product team to care about? I actually do want everyone to be caring about the experience and the interface and the interaction of the product. I want the product manager and engineers to care about customers and the way they experience the product, absolutely. Do I want them to be solely focused on doing that? Well, no, because we need engineers to build the thing and we need the product managers to do the work they're supposed to do. And it's the same on the operational side. I do want the product teams to care about operations. They're going to have to if they want to be an effective efficient team, like we hope they will become high-performing. But do I want 'em to spend the majority of their time thinking about it? No, not really. Now, in an organisation, you may have product leaders that are gonna be focused on that, and that's absolutely fine. If they think that, you know, 50, 60% of that time should be focused on the structure of the organisation, how they're strategically aligned, are we sure they have all the right data points they need and how can I streamline that, that's absolutely fine. They're doing operational work. But there will become a tipping point where a VP of product shouldn't really be doing that and you probably have to think about hiring someone.

  - Yeah, I totally agree. I mean, if I reflect on other functions, like we've had sales ops for a while, we've had design ops for a while, in fact. Heck, I remember IT ops back in the day that was the people you handed over the operation of the product to. Now obviously the DevOps movement has changed that a little bit as well. But kind of having that operational team or group of operational people, and maybe how they're organised, varies a little bit, where they're integrated or separated can be definitely super empowering for people focusing on where they create the most value. Okay, so that's fair. How are these product ops set up differently across different organisations?

  - It's a really good question. And, again, it's a question that we get a lot in the community of like, "How is your team structured? What pillars might you have?" Now I was actually speaking to the director of product ops at VistaPrint yesterday because their model is slightly different. And going back to your point around design ops, they actually have design and product ops under the same structure, management structure. So it's quite interesting. And I speak to a lot of product ops practitioners in leadership levels to ask them this question, and nearly every organisation is set up differently. Why is that? Because every single product organisation is indeed different. The product is different, the customers are different, the way their leadership is different. I mean, anytime you throw a load of humans into a room or into a remote room to work together, they're gonna have their different ideas on how the organisation is structured and how they work. Therefore, the operations of those organisations are quite different. In Melissa Perri and Denise Tilles's "Product Operations" book, they have outlined what they think are the pillars of product operations, which is internal data, external data, then like tools, practises, systems, et cetera, processes that are in there as well. And I've seen a lot of product ops teams set up in that way. But I do think to fit the need of a changing, evolving product org, product ops also has to be ready to be flexible. So you can come in with like a loose concept of how you may structure things and the work you may focus on, but very quickly that may have to be changed. You may have to be quite adaptable in that space. I do think the best product operations practitioners and leaders are quite comfortable knowing that they can focus on whatever the org needs, and they've got good experience to do that, but being comfortable with the ambiguity of, "Well, actually we may not know until we get in there. What we should be focusing on?"

  - So there's a number of questions I wanna unpack there. The sorts of people who are doing product operations, what background do you think they should have?

  - Again, it's a really interesting question and it comes up quite a lot. Do I need to have been a product manager to be in product operations? My answer to that is usually no, you don't. The first part of that answer is I, and like at the top of this call, I don't think we focus on product managers as a customer, I think we focus on the product organisation as a customer. And that involves many different teams, different peoples, different backgrounds, capabilities, experiences, job titles. So I don't think you need to have been a product manager, but I do think you need to have some really solid experience being in and around product development, the world of building products. I think that experience is what sets good and still learning product operations practitioners apart. I've never been a product manager. I don't actually think I'd be particularly good at being a product manager. I enjoy the operational side of it. But I've had like 15 years of being in and around, and in teams, playing roles where we were building products, understanding what customers wanted or needed or valued, what they might pay for, what kind of business impact we're aiming for. So I know what good looks like, and I think that's a real differentiator between people that are new to product operations and ones that are more experienced. Being able to identify what good looks like and then amplify that across the organisation. It is a lot harder than it sounds.

  - It's interesting 'cause I've generally taken the perspective of, essentially I'd love to have my principal PMs be the product ops team 'cause they then bring the best practise to everybody else. But I hear the point about that broader church of product people that they're supporting and driving. And it's interesting you said that some of your clients have kinda merged with design ops. One of my clients has merged it with the Agile Delivery Leads, for example. They've put it under that church and seems to be a nice fit there as well in their organisation.

  - Yeah, I mean just to your point around principal product managers, I do think they should be sharing best practise, absolutely. I think they should be almost the go-to, how are we going to improve our product organisation from a product management perspective? I think they're good go-to people, they can be coaches, certainly internal coaches within that. I think in those organisations that have that level and have a product operations function, they should be best friends. Because the principals are a little bit closer to the actual development of products and working with teams, working with people, they should be a really good source of feedback and insight into where we might improve. I think then the product ops team is a little bit more accountable for like spreading that knowledge, amplifying those good and best practises across teams particularly if you have, you know, an org that has like 50, 60 product teams. Okay, we may have like a good 20 principal product managers, but actually standardising some of that best practise and amplifying it shouldn't be on them. They should be able to identify and then share it.

  - I love that. So it's the identify and share, but the product ops team can take it and run with it and roll it out essentially.

  - Yeah, I mean it's about taking like more novel, interesting experimental practises, trialling, experimenting them within teams. And then if those practises seem like they're adding value, whether it's to make us more effective or to make us more efficient, we then start to move them into a place of, "Okay, this is now becoming like more standardised best practise," and eventually it becomes, "This is how this organisation does product. This is the foundational practises that we have." So it's been started by the principal product managers, and other levels by the way, not just the principals, other levels of leadership, or the members of teams. And then moving it down into, "Well, this is just how we do product here." Now it's gonna take a couple of years to kind of find that like balance. But when you've got product operations people in the org, that'll happen in a much more smoother, more streamlined and possibly quicker way because it's easier for them to have a much broader picture of the org and where practises like that may be experimented with or we can actually start to make it foundational.

  - Let's go to the zoom, to the other end of the spectrum then. There are some organisations that hire super junior people to be the product operations managers with little experience to what you talked about of what good looks like, sometimes almost putting as, dare I say, assistant PMs or assistant to the PM, if I use my office quote. Any thoughts on that pattern?

  - Yeah, a couple of things. Product operations is really here to enable product, right? And product being the broad product, not product management. The development of products, however you want to kinda phrase that. Product operations is here to enable that. Now if someone's been able to identify the way to enable our product teams to do their best work is by having someone with them on the ground maybe, as I was mentioning before on the "Product Operations" book and its pillars, maybe focused on purely customer data. And that's the only thing that person's going to do. It's very tactical. There's tools that help you to do it. It's quite process-driven. But that person can sit there and do that work and then enable the product team essentially increasing the quality of their decision-making, right? We now understand customers are a little better, we now understand what they're doing a little bit more, now we can build better products for them. If they're brought in to do very specific things like that, they can be successful. If they're brought in as a product ops manager to look at the broader product organisation to be able to identify improvements, optimizations, areas where teams may be struggling, that person is gonna struggle quite a lot and they probably won't be successful. I gave a talk at Product at Heart in Hamburg last year called Everything Everywhere All at Once and it was about a team of one product ops manager. I rarely see it work. And they have to have such specific focus at the beginning that people start to question why would they even need product ops because they're only doing one thing, but they're only one person. And I think any team of one, it's really hard to like have that impact. So if you're bringing in more junior people with less experience, get them into very specific things and say that's what you think product ops is. The function then maybe grow and you maybe get different levels of experience coming in.

  - So let's unpack that further as well. You said a team of one struggles. How big should a product ops team be then?

  - This is a great and easy answer 'cause it completely depends. As I said before, like because every product org is quite different, the needs are going to be quite different. And I think this is where myself as a consultant in the product ops space, the way that I can engage with a client is by coming in and quite quickly identifying the biggest challenges that they are faced with. Now, what tends to happen with product ops is that someone probably in leadership, so there's two different routes actually. Someone probably in leadership going, "I don't think our teams are effective or efficient as I'd like them to be. Let's hire someone in to figure that out." The other way is there's a bunch of product managers that are doing a lot of operational work and it kind of comes from the bottom up and they start to identify themselves that doing this operational work helps the teams to be a bit more effective and a bit more efficient. But either of those approaches, if you can bring someone in that can very quickly go, "Look, these are things you're probably gonna be most struggling with, let's bring in a team to focus on those," your team size can be quite different. Like I said, the director I was speaking to the other day, they have 60 product teams, they have eight product ops managers. But they're almost like internal consultants. They're in there identifying potential opportunities for optimization, for improvement. They're looking very high-level, they're looking at governance, they're looking at planning cadences, and working with leadership. So you don't need one per team. But then I've heard of other organisations that have like less product teams and more product ops managers because they're very embedded in the teams, very focused on purely enabling that one or maybe two teams max. So it can depend.

  - Yeah, I mean I always took the philosophy, or have taken the philosophy, that they should almost be trying to make themselves redundant. It's like they're helping improve and change the organisation in such a way that it doesn't, they're not needed to do the operational stuff 'cause they systemize, et cetera as they go. Ultimately, there's always another problem to solve. So they never actually make themselves redundant.

  - Yeah, it's interesting because I understand that concept from a consulting perspective. I understand that concept slightly from what we used to call Scrum masters and then turned into Agile coaches in that actually if your team is now operating quite effectively, quite efficiently under an Agile framework model of some kind, then maybe you do kind of make yourself redundant. I think product ops is slightly different in that, yes, there will always be more challenges to find, however, it's more about scale. So as the organisation scales, the practises, the processes, the procedures that you had in place when you had five product teams could be wildly different to when you have 15, 20, 25. Now your governance, now your planning, now the way that you bring that data and insight, and the way you communicate with the rest of the org, the way that you document and have standards around that are all going to start to shake a little bit as that scaling happens. And I think one of the huge benefits of having like product ops in place is those scary moments where you think, "Oh, actually we're scaling so fast things are gonna break," product ops are there to kind of support that scaling, scaling through, and make sure that things are still happening and teams can still be effective.

  - I'm gonna bring us back to a little bit of fundamentals then. So what are the key responsibilities of product ops? And I know you're gonna say it depends, and I love it 'cause that's the title of the book I'm writing. But kinda if you put it somehow almost like the core and the things that some places do almost.

  - I mean, for me, I always fall back to product ops should be in an organisation to maximise the performance and impact of that organisation. So how can we do that? Well, we can focus in so many different places. Like, again, every organization's quite different. There's three kind of key tropes that I think I talk to my clients about. We need to make sure that all the teams and the organisation as a whole is strategically aligned around the needs of the business. Like we've done in various different ways. We need to make sure that we have empowered teams, that we're customer-centered, that we have a good, not the vision and the strategy and the objectives itself, product ops is not gonna come in and write that for you, but structure it and to communicate it across the business so everyone fully understands it and is aligned is definitely an area of focus. To make sure that the organisation is value-driven. So make sure that our teams understand where their product fits in the market against its competitors, how it makes money, that we're data-informed, and do we have the right pipelines of both customer, external and internal data coming in. And that we have experimental practises, and that we can iterate on those practises. And finally, to be outcome-focused. So are we actually able to create objectives that are outcome-focused? Are we able to actually measure on those outcomes, understand when we've achieved or not quite achieved our outcomes and iterate on them? Do we have good customer feedback loops? And do we have an iterative and continuous learning practises? All of those areas can certainly be focused on by product operations. And the reason I say all of those, because it keeps it high level, it keeps it strategic. I'm not gonna sit here, and I know we're on the "Talking Roadmaps" podcast, but I'm not gonna sit here and say product operations will come in and introduce a roadmapping tool for you and make sure you communicate across the business. Now, if we go back to my statement of maximising performance and impact, does having a roadmapping tool that is accessible and is clear and is value-driven and is communicable across the organisation to business partners and stakeholders, and customers maybe, is that gonna help performance? Actually yes, because now as a product team I don't have to spend extra time trying to describe and detail and communicate with various different people. Is it gonna increase impact? You would hope possibly yes, because now we know how we're more aligned around some of the objectives that we have and the things we're building towards it. But having a tool around roadmapping and the practises around it, it fits within being strategically aligned, value-driven, and outcome-focused.

  - Yeah, it's interesting. I feel like some overlap with the CALMS model that comes out of the DevOps space. Not gonna dive into it, but I think it's something I'm gonna have to kind of do some overlaying when I and think about myself afterwards. So okay, you said there was the two roots of it coming in. We're gonna establish a, or we think we wanna establish a product ops function, how do we justify it?

  - Oh, yeah, I mean, again, I go back to if your product teams, if your product leadership are spending more time focused on the operational side, so how do we do product here? How are we structured? How do we share, how do we communicate, how do we document things? How do we talk and collaborate together? If you're spending more time focused on that than focused on delivering customer value and business impact, at that point, it's a tipping point of going, "Well, actually let's bring in some people to do that." Ultimately, product operations, like the ultimate goal, the ultimate aim is, and this is why I don't really subscribe to product operations as a customer, and that customer is product managers, for me, in product operations, the customer is the customer, the end customer. I'm trying to do everything within an organisation to make it effective, efficient, to ensure it's high performing to drive that customer value because I know that that's what's gonna drive business impact. So I think that the need for me is quite easy to justify. When you start to take away a lot of the focus on the teams, on the operational work so they can focus on the customer more, the expectation is that we actually see an increase in customer value being generated and business impact, whether that's revenue or whatever else we're aiming for. If that increases, product operation is doing a good job. 'Cause we're helping the product organisation to do that. We're enabling them to do that.

  - Well, you're not gonna get me disagreeing there because I consider product management and product work as a whole to be all about that creation of value. And I tend to preach a broader church than just the development side, as you heard at the top end. I started product management with a P&L. Like, that was how my life started. And caring about that commercial side is just a core part of product work to me. Caring about go-to-market, all the rest of it is fundamentally still part of product work.

  - Yeah, and I think with a lot of the teams that I see that are incredibly highly capable at product development, delivering products, getting things out there, and maybe even measuring the impact and the outcome of that work, there's often a lack of accountability for business impact, accountability for revenue, accountability for profit and loss, and the understanding of finance and how the business generates money to keep us all gainfully employed, to hopefully scale the organisation. That is often lacking. And I don't think product ops is accountable for ensuring that teams understand that. But, again, we can kinda play our part. If as a product ops consultant or a new team that we identify that actually some of our teams are lacking that, then we can bring in external trainers, we can bring in product leadership to explain it more. Again, because we're quite, well, product ops people are generally problem solvers. That's another problem that we can solve through operations.

  - There's potentially a natural tension, 'cause product managers are naturally problem solvers as well. So I wonder if we find ourselves fighting over the same terrain sometimes. But the value of who should focus on it is the interesting thing, I guess.

  - We should just be friends, like let's problem solve together.

  - So let's switch gear a little bit. What do you consider to be best practise for product operations?

  - Yeah, I mean I think I've touched on this a little bit already through what I've been saying. But I think generally keeping it high level, right? You are not going to help to evolve a product organisation if you're right down in the weeds right from the get-go. And I think the best product ops practitioners are the ones that can understand, again, as I was mentioning before, like, "How is the org strategically aligned, value-driven, outcome-focused?" When you start talking about those levels, you start to understand actually working with product leadership. And then sometimes, in some cases, business leadership as well to structure an organisation, a product organisation with empowered teams that is focused on outcomes and really cares about the customer. Keeping it at that high level is going to have way more success than, for example, joining and going, "Right, well, our documentation isn't standardised. Let's start there." You're gonna have such minimal impact that questions will start to be asked of why we even need product operations in the first place.

  - So what's the biggest mistake that people make?

  - There's a couple of things, and I think it all gears towards being in the weeds, being in the detail too much. The biggest kind of mistakes that I see very often the starting point for a product ops team that had maybe just been newly founded or is maybe even being built from within the organisation 'cause that often happens as well is overdetailing the product development lifecycle and spending a long time to draw every single box on whichever workshopping tool you like. Every single box, every single connection, every single role, every single output/input. It can be incredibly cathartic, particularly for a newly joining product ops team. And it can be incredibly good for onboarding. Don't get me wrong. If you have identified over the next, the course of say 12 months, we're gonna hire another 20 to 30 product managers, it's probably a good thing to just have a good understanding of the product development lifecycle and all the different connecting points and all the key people and processes. That's not too bad. But overdetailing it and getting really into the weeds is something I see happening quite often. It's an artefact that is very, very rarely looked at ever again because product development, as we all should know, is messy. The key building blocks are always the same. They're always the same. But all the little intricate parts, they don't always need to be detailed. I think that's a bad starting point. The second thing I would say is observing teams so closely and hoping that you're going to be able to identify gaps or optimizations and improvements within a specific team. The majority of the time those teams already know it, they're already struggling and they're already blocked by it. So getting in and just observing, sitting on calls, you're never going to unearth the real largest strategic challenges that the org is facing. You're only gonna solve the problems for that one team. That's why I say it always needs to be kept high level. If you want empowered product teams, it starts with product leadership. It doesn't start with the people in the teams.

  - Now obviously we are on a channel called "Talking Roadmap," so I would just like to explore how are product ops involved with roadmapping?

  - Yeah, as we just mentioned, right? If we go back to do roadmaps help us to maximise performance and impact? They do. And there's various reasons why that is the case. And a lot of them is about accessibility for the rest of the organisation to understand what we're doing. Roadmaps at different levels. Of course we don't want our business stakeholders to really be in the technical details and the steps we're going through. But those high level, value-driven roadmaps where they know, okay, these are the things that are going to land on a certain kinda time frame, it creates a bit of a barrier between the product teams and business. I mean barrier in like a positive way. There's no need to have that conversation 'cause there's a roadmapping tool and we're using it and we have a strong roadmap. You don't need to contact us. I think the role of product operations here is certainly on the operational side. So like what tool might we be using? How do we templatize these roadmaps so much that our product teams don't have to think every time about how they create and share, how do we document, communicate, what rituals might we have to collaborate on the building of the roadmap to share at certain points and to get it out and get business stakeholders involved in it. Like, what are the rituals, the processes, the documentation that we have around that? I think that's where product ops can add value. Of course the management of the tool or tools themselves, like for onboarding, for access purposes, a product ops team can certainly pick that up if it's a larger team. Again, if you're a team of one or two people, you should be thinking more strategically than tool management. That should be left to your IT department. As that group grows, as the organisation grows, you may bring the tool into the management of the product ops team.

  - It's interesting, as you described all those kinda like interfaces and stakeholders and forums and things. I'm thinking, mm, I do a lot of those sorts of conversations with clients in setting up their product organisations. So I'm having product ops conversations.

  - Absolutely. And there may be that there's someone in the org that they've identified and gone, "Right, you're a lead product manager, so you're gonna have to set up the tool to do all this stuff." Now, the setup of the tool is one thing, right? The building of the roadmap is a completely separate thing that the product people, the cross-functional group should be doing. Certainly in product ops I'm not going to be doing that. But the setup of the tool is one thing. The maintenance of that tool and the evolution of the, and getting the best out of that tool is a completely different thing. If all we wanted from a roadmapping tool was simply to show the now, next, later blocks, then we can just do that, as you've referred to before on Excel. We actually don't need anything for it. However, the roadmapping tools that are out there now, the product org tools that are out there, they're incredibly powerful. And actually if you want to get the most out of them, 'cause they're also not cheap, no tools are cheap, you need people in them monitoring, maintaining, and making sure we're getting the most, they're getting the most out of that. Do you really want your lead product manager to be doing 80% of their, their week is focused on managing a tool? Probably not.

  - Heck, I don't want 'em spending 80% of their time on their roadmap. It's like to me they want 'em doing the product work and the roadmap happens to be a result of that work.

  - I think that's an important point, right? Because we do want those people to be focused on, again, customer value, business impact. The roadmap is a tool within itself to enable that to happen. We have to be really careful because I've definitely seen product operations people becoming accountable for the roadmap, accountable for dependency mapping, accountable for making sure deadlines are hit. That is not the role of product operations. That is for the product teams themselves. And if they have delivery people in the organisation, they should be helping as well.

  - So, okay, coming towards the top of the session, Chris. If you had to distil your philosophy on product operations into one or two sentences, what would it be?

  - Again, for me, product operations is all about maximising the performance and impact of product organisations. Doing that by increasing the quality of decision-making across the product development lifecycle and trying to build the highest performing teams we can with helping 'em to be effective and efficient in delivering customer value and business impact.

  - And is there anything I should've asked you about product operations that I haven't?

  - I think one of the interesting things, particularly in the B2B, there is a difference between B2B and B2C product operations. And B2B being a more encapsulating phrase for like SaaS enterprise, internal products versus ones that are directly into consumers' hands. There is a difference in approach and structure and mentality, and therefore the people that might be hired into those roles, there is a difference there. Thus, we can definitely go into some of that. Maybe that's another episode.

  - Maybe what's the headlines of the difference?

  - The headlines is, on the B2B side, you just need a lot more structured processes in place. And the focus of the product ops team isn't to ensure like the interfaces between the people that are building, developing the products and the business are in place, and that interface is really strong, that in place streamline them, the communication is really good back and forth, but with a number of guardrails in place that the product org isn't inundated with requests from business stakeholders. I was actually having a really interesting conversation, again, with someone in the B2B space, that the like regional business units, again, they are not building the product. But they're almost like proxy product managers because they're so close to the product. They're using it day in, day out. They're trying to sell it to their customers, to their clients. They really feel like they're part of the product world as well. So now how do we actually enable them to feel accountable for the development of that product? That's a very, very specific B2B challenge that product ops can certainly help with. On the B2C side, it's much more around the practises of product. So like product discovery, product development research, how we communicate internally, those are more the focus on B2C.

  - So, Chris, it's been a pleasure having you on the session today. Always like to give people a chance at the end just to give their pitch of how people can get ahold of you, how you can help them.

  - Yeah, great. I mean, as I said, I'm a consultant and I'm an advisor focused on product operations. You can find out everything about what I do at chriscompston.com. Nice and simple. I do also have my own newsletter, chriscompston.substack.com, which you can obviously sign up to, where I share tools, frameworks, concepts, theories around maximising performance and impact of product organisations through product operations.

  - Been great having you on the channel today, Chris. Thanks for your time.

  - Thank you.