Should Product Ops aim to be redundant? | Hugo Froes

In Episode 14 of Talking Roadmaps, Justin Woods interviews Hugo Froes, Head of Product Operations at OLX, about whether Product Ops should ultimately aim to make itself redundant. Hugo shares why Product Ops adds value during scale-ups, how to avoid becoming a bottleneck, the importance of business sponsorship, and best practices for enabling teams rather than owning processes. This thoughtful discussion explores Product Ops as a force multiplier that empowers organisations to mature sustainably.

Leading Product Operations at OLX by day. Speaker, Mentor and Teacher by night.

With over 20 years in the field of product and design, Hugo has explored user centered methodologies, team topologies and change management, while working on creating scalable and sustainable product teams. His main focus is helping teams reach their full potential to build better products.

As a teacher in various institutions, a co-founder of UXDiscuss and previously a board member of the Global ResearchOps community, he strives to also contribute to the community and help shape young minds towards user centered methodologies.

He loves interesting challenges and spending time with family, reading a book, listening to some tunes or watching a movie.

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 Product Ops aim to be redundant? | Hugo Froes

Hugo Froes and Justin Woods

In the next episode we are talking to Christine Itwaru, VP of Product Management @ Beamer & Userflow. So watch out for Season 2 - Episode 15!

• Transcript

  - There are some folks who are consultants and they talk about the negativity of product ops. They don't understand the value of it, right? Because product organisations need to have culture and fit, and they have to do their own work and get there. And product leaders, we're covering for bad product leaders and stuff like that. And I actually like to flip it, which is, do all these consultants have jobs? Do they get hired to do work? You're like, yes, you've just justified how product operations is needed. It's like, as long as these consultants have jobs, the truth of the matter is product operations is needed, right? It's almost like you're hiring an internal consultant, right? Of course, you might look and say, I don't need a consultant for the next five to 10 years. Maybe I did need for a specific thing. So maybe an external consultant is enough, but other times, you'll just realise, I need someone who can keep con giving continuity to this. I can keep doing it, and the people build context and everything like that. But truth be told, it also only works if you almost give them the same amount of power you give to an external consultant.

  - Welcome, everybody, and welcome back to the "Talking Roadmap Show", where in series two, we're talking about product operations. My special guest today has got a background in UX, product management, the arts, and most importantly, product operations. So without further ado, Hugo, it's great to have you on the channel. Would you please introduce yourself?

  - Hi, Justin. Thanks for having me, and thanks for the invite. Yeah, I'm currently the head of product operations at OLX, which is a classified marketplace, right? And, you know, three different main areas, which is around goods, real estate and motors. And we've got a bigger team. The team has grown this last year. And like you said, my background comes from, you know, the arts going into design, then user experience, design thinking, then into the design operations, and then moving into product operations. And so I've been working in the product realm for roughly, oof, 15 years or so, before that, working in the graphic design space for another seven or so years, right? So, yeah, it's been an interesting journey and I think it's all culminated in this product ops role that I'm working now.

  - If you're enjoying the channel, subscribe, hit the bell icon and give us a like. Do you know what I think it really has? And we were talking about that just before we started recording at about how, you know, we are the combination of all of the past milestones and things that we've achieved previously. And the thing I love about product operations and product management is that it really can pull on all of our experience that we've used previously. That the creativity and the thoughtfulness of the arts, the process and the discipline from product management, it makes all of us who we are today. And kind of talking about product operations, which is a really exciting area for me. It is something that I've been doing for probably eight to 10 years and not even realised it formally. I always thought I was a tools implementer. It was actually, I'm probably more product operations than I am anything else these days. So we're really excited to talk about that in series two. And so maybe we should talk by, or start by talking about what do you think is the purpose of product ops?

  - Oh, that's a good question. And I guarantee every single person you talk to will give you a different answer. I have a way of presenting it, which is our purpose is to become redundant. Okay? That's my main purpose, which is I want to become reach a point where they don't need product operations. But if we look at what that means, right? It means we try and go in there and look and say, how can the organisation be more efficient, more effective, you know, more streamlined, make sure we're not, you know, doing more than we need to, duplicating work, wasting time, that kind of thing? Right? Are we helping the organisation, the people mature, the organisation mature? Are we enabling this, right? And we are supporting them in this. If we do a good enough job, we can start moving away from a lot of this stuff, right? It's not where, oh, now I'm gonna own more five things because it should sit under product operations. No, I actually try not to because it would be yet another role that has yet another ownership. It becomes a bottleneck, right? So the purpose is exactly how do we enable the teams? How do we create the space for them to be able to do their work more efficiently, more effectively, right? And look, there's some leaders will turn around and say, oh, I expect the product manager to be doing these 500 things, right? And you say, fine, but about 300 of those, I guarantee they don't need to be doing with the amount of effort and work they're doing every single day, right? We can reduce that or automate it if possible, right? Can we reduce that? And so it's about always finding those small little tidbits where we can improve continuous, you know, experimentation, trying out and enabling and getting the team that place where they turn around and said, you know what? Before I used to take three hours to do anything, this piece of work, I now take five minutes. Right? Perfect. They get more time to do the discovery, the strategy, the vision, you know, the figuring out what the programme, what, what the product should be.

  - Why do companies need product ops then? Okay, this is a controversial answer, but they don't. So I have this way of looking at it, right? Which is what do we need in terms of product organisation to build a product? Right? And as a start, we need engineers. That's a given, right? Ideally the other role you do need, because there is interface, there's, you know, there's design, right? So these two roles are the ones you really, really need. Almost every other role is a nice to have. Although those nice to haves bring value. I'm not saying they don't, right? And that's, and I've spoken about this in other places as well, right? Which is, for example, you bring in a product manager because, you know, organising things, figuring out the business acumen, figuring out a lot of where the organisation can go and the strategy, it becomes complex maybe for a team of two of a design and engineer, right? So you can bring that extra value, a data analyst, right? Maybe these people are good at looking at analytics and, you know, the general analytics and stuff, but it becomes very superficial, very light, right? So we add extra value. And I think it's about this, right? So it's about adding what you need when you need it. So there are organisations that have been able to figure this out really well, and they might not need product operations. But however, what I see is generally it, and, and especially the ideal phase for product operations is when we're going through that scale up phase, because when you're in a startup, you're all sitting in the same room, in five minutes, you say, Hey, we're gonna change the way we do this, fine, let's just change it, right? So you test out 500 things. When you start scaling up, we start seeing that there are some established ways of working, but it's still, you know, they, they now have to think, how do these things not break when we start adding more people, when it becomes more complex? Because now we have to line, you know, 200 people instead of just five people, right? All of these things. So that's where it brings a lot of value. Now, what generally happens is, I've seen that it's implemented in organisations that have already at that enterprise or that huge size, which does add complexity because they were trying to change something that is already, you know, established. There's a lot of ways of working, a lot of things that are already, have already been working. So the job for product operations is a bit more complex. But all of these, right? What they generally see is, you know, product organisations have grown exponentially, and that's what usually happens, right? They started off with three or four, then they got investment, they jumped up, and then they suddenly realise that between thinking about the strategy, the vision, figuring out what's going on, the trends in the market, looking at all these other things, managing their teams, managing their product organisations, aligning with other areas of the organisation, and then someone turns around and says, oh, you know what? You need to look at how your team matures, right? How at the training, like, okay, they'll throw a training at the team, right? And they say, oh, you have to think about how you do road mapping. And they say, okay, let's just implement this tool, or let's just do this, right? And, you know, a good product leader will also look and say, I realise I'm not giving this the full attention I need to. I can't. I can't deep dive on it, right? I can't geek out about roadmaps, about OKRs or about, you know, experimentation. I can't geek out as much as I would like to because I have to make sure everything's functioning. And so there they bring in someone else, and usually, and this is when it works well, is when they bring in the sparring partner, right? Which is someone who comes in, works together with them, and basically is a force multiplier, right? Where it's like, it becomes their thinking, their logic, their, you know, their direction, it gets amplified, and that person's able to take that and build on that. And then they come back with, Hey, here's a great way of approaching this. Let's, here's a plan to do the change, the implementation, the rollout, right? This is where I see the real value and the impact of how it can be. But at the same time, many people try to, you know, get, they try to build up five teams of 10 or 20 product operations, and you're looking to say, you don't need it in the beginning. In fact, sometimes it's even hard to justify a team above five or six, right? Because you get to a point where if I'm gonna fix everything, I'm gonna need less people in the future, so why am I gonna build a huge team?

  - Yeah. And it goes into what you were saying about, you know, you may not need product operations, or actually what it was is that you may not need us, or if you do need us, we're trying to do ourselves out of a job. That's no bad thing. Because once we've done ourselves out of one job, of course there's gonna be another job to go and pick up. But the philosophy is there and is important, if we start to own things in life, product operations will be, become encumbered, can't be agile, and will start to be part of the machine, part of the machine rather than the thing that's actually looking at the machine. And I think that's vitally important.

  - Okay. And it becomes a lot of those roles that exist out there, right? Which happened previously, which was, oh, we are now gonna own this part of the development process, we're gonna own that part of the development process, right? And what you've done is you've just added yet another layer to all the teams that you've got going on and everything going on, right? But even, and going back to your initial question, right? Product operations will always be needed not as an individual role, right? So product operations is something that, whether you like it or not, it happens because you will always have to figure out how your organisation works, how it functions, how it can be better, how it can improve, right? So you will always do that. Now, if you can't handle all of it, right? Because the organisation has grown, it's scaled up drastically, and we always know how it is, right? They always want you to do more with the same amount of people or with less people. Bringing in one person or as small group of people can help us sometimes unlock that and, you know, develop it further.

  - Yeah. Great, great response. I love the bit you're talking about being a force multiplier, about almost giving some of these other functions space to think, and you didn't directly say it, but in the conversation we've said earlier, you said that product operations is actually something that helps the organisation. I think that's vital. Too many people think product operations is the operations for just the product management function, and it is not. It is there to serve the entire company. So I'm really pleased to hear you to share that with us. I think a question I'd love to hear now is, is how do you see product operations set up across different organisations? Because you've mentioned that sometimes it can be a role, sometimes it can be part of somebody's role, and also we talked about sometimes a company might be so small that it doesn't need them, and it might be so large that it needs full-time resources. How do you, or how have you seen product ops set up amongst different organisations?

  - I've seen hundreds of different... I mean, I, dozens. Dozens, right? Hundreds is a bit much, but dozens of different ways, right? So there are organisations that product operations has suddenly become this role that everybody puts an umbrella under, right? Which is, it's everything, right? And so what I've seen is, for example, in some cases where they're hiring delivery managers, but what they want, they say it's product operations, or they hire, you know, agile coaches and they say it's product operations, or in some cases, I've even seen where they've got huge teams of product operations, but when you deep dive, they're actually product managers and the product managers are product owners. And you're like, you've flipped things a bit here. You're naming it the wrong way, right? You're creating some confusion here. But generally what I see is, you know, product operation starts from one of two places. One is either we see the process and practises are broken, and so someone turns around and says, we need someone to look at this, and this, what usually you have is someone with a background either in product, you know, business analyst, or in my case from a design background, right? Although there's a few of us and you come in and you're looking at the process that, you know, building up this whole structure. Whereas in other areas, what happens is they look and they say, we've got tonnes of data, tonnes of information, insights, but there's no curation of that data. And so what they do is then they hire, the first person sometimes comes from a data background, and it's about organising and structuring that data to be functional, to be useful, right? It's about curation of that data. But what happens is either one of them then usually grows and then starts including the other, right? And so this can happen because you then fix one part of it or you make it better, and then you realise there's an area that needs attention, which is usually the other. And so it grows into that. Now, in terms of the actual structuring, right? Like you said, it often is where you've got one person working, where you have people doing it as part of their full-time job, right? Where they can. In startups, when there's a product operations, often they actually seem more like a COO, chief operating officer, right? Where they take on all operations, not just product operations, right? But then what happens is usually it's implemented divided also by function. So you'll have organisations that have, you know, engineering operations, product operations, some have design ops, research ops, all these other ops showing up, right? What I have realised is that as the operations start developing and growing and the organisation matures, that it becomes more a waste of time having all those different operations. And so often they then come together, right? For example, right now, my team, we absorb both design and research operations, right? Because it touches on all, the whole product and everything like that, right? But we also have to collaborate with all these other operation roles, right? We've got engineering ops, or as you call DevOps. So we have to collaborate with them constantly. And we're working, you know, making sure we are not duplicating work and effort, but it's got all makes and models, right? It can go in various multiple ways. The way I see it is what does the organisation need? What do we have to make sure? And that's why I also tell my team, our scope sometimes is very defined, very clear. Sometimes we, there's a tonne of grey areas, which is, there's things that ideally we will not take on, right? Or they're not our remit, but if the organisation needs it at that time, and we are well equipped to be able to do that, guess what? Let's just jump in and do it, because it's what the organisation needs at that moment. Oh, but the other project and everything. I said, don't get me wrong, but this is the priority now, this will be the project we work on, right? And so it's about this adaptability, this constant change that we have to be very resilient and able to change depending on what the organisation needs.

  - That's a great response and actually a really nice lead into the next question that I had, which was, how do you maintain those boundaries or where there is... So, or the, we could call them boundaries between product ops and product management or collaboration, but you mentioned kind of sometimes there's some friction and overlap, sometimes there's a void that you need to step into. How have you found that you've managed that? Is it about just communicating with those other teams, raising awareness and stepping in? How have you managed that collaboration between your product ops teams and other areas within a company?

  - Yeah, it's interesting because, you know, I remember the first time we created this team and we started developing it and people said, oh, can you clearly define what is the difference between you and engineering ops? And myself and the engineering ops person sat down and in five minutes we were like, okay, it's clear right? There was no overlap, right? If you actually look at that, there's no overlap. Now what happens is sometimes we are dependent on each other, and that's where the, the magic comes in where they can help us with certain things. And it's like, if I recognise that earlier, we can get. But with my team, what we've been trying to do is constant planning and constant openness, right? So one of the things is we make sure we're keeping people informed of what we're working on, why we're working on it, what's important, right? We're making the right stakeholders. We try and do. So it's kind of like practise what you preach, right? What... We tell product managers, look, dependencies, how do you manage them? You talk about them before you commit to anything, right? Not afterwards. They're like, oh, you know, you, it surprises some people. I'm not saying all product managers, but some will be like, oh, that's interesting. I gotta try that, right? We try and do the same thing, right? If I'm gonna have a dependency on someone, I wanna make sure I can, you know, have that dependency guaranteed so that I can deliver that. Another thing we've tried doing in the recent times is where we look at any piece of topic and we actually build our own business case around the topic. So in my team, what we are doing is we're doing discovery on topics. So, you know, we don't know what it is, we don't know if it's important or anything like that. So we build that. And then what we do is we look and we say, okay, now I have to build a business case. And you turn around and say, why is the business case? Because if you as a team agreed it should be built, just do it. Right? It's like, that's not how it works. What we do is we build that business case, and what we try and do is try and make sure we get a sponsorship to justify that it's something worth working on, right? And this was a great idea for my manager. He turned around and said, oh, I want sponsors for things. And I was like, that's a great idea. So what we try and do is we say, if I don't have a sponsor for something, it's in the backlog, it's on the shelf, or it even gets scrapped completely, right? Because if it's not important for them, chances are it's also gonna be huge effort for our team and we won't see the results, right? So it's about having that sponsorship, but then it's also about, you know, we commit to something at the beginning of a quarter and we do quarterly planning now, and, you know, we commit to something and someone turns around and says, oh, you know what? This new thing came up, and we know how it is, right? Organisations are constant change, constant flux, and they come up with a new thing. It's like, great, is that more important than everything else I've committed to? And they say, well, yes, it's more important than this one. Okay, then this one's gonna stay on the backlog for the next quarter. And they're like, okay, it's a negotiation, right? We keep having this negotiation, and that's the best way we can do it. Have we optimised the completely? Not yet. Not yet, right? We're still working on it. There's still things we have to, you know, a few kinks we have to hammer out. But it's working well in the term, in terms of at least more and more the team feel more confident in what they have to work on, but also our business partners or our product site partners, they understand what we're working on and what we need to, right?

  - Brilliant response. We need to apply product management first principles to the way that we do our work. And that obviously helps if you have people that have come from product management into product operations. But that is not a necessity. You know, product operations can have people from all sorts of different backgrounds that add absolute value there. And I think that's the exciting thing about it, is it is accessible, because we bring our backgrounds to those roles. You bring a set of skills and experience to those roles as well be all right. I think overarching it makes sense for us to have a set of goals, some hypotheses around them, some business sponsors, because if the business don't care enough about it in order to say, yes, I care about this, then why are we doing it in the first place? I think often that gets lost from product operations and probably even gets lost from some product teams as well. And so I'm really happy to see that you've brought that in and much to the success of what it is that you are doing within the company. And maybe this again, ties into a, maybe the last question of the core group that I have here, which is, how do you justify having product ops? Surely that's now easy if you have business sponsors and business cases behind everything you do.

  - It's an interesting thing, right? Because justifying product ops, I don't think it ever ends, right? Like almost any support function, right? We have to continuously show our value and the impact we're bringing because, you know, at any time, at any given time, a person can look and say, well, they're not directly impacting the product. Does it make sense as a team? Is it just fluff? Is it just an extra and everything like that? So the thing is, what we have to try and do, and this is what we're constantly trying to do, is also add metrics, whatever possible to any piece of work, right? Looking at the actual impact that happened based on the work we did, right? Something we can share out, something we can actually present to people. And I think this is an important part of it, right? It's about making sure people are aware of what's being worked on and everything like that. But another thing I like to say is make sure your stakeholders know the value you're bringing, right? Your main stakeholders. If you do that, and sometimes, you know, people might feel like, oh, I wanna make sure the whole organisation knows what I'm doing, you know, everyone from the ground all the way to the top knows what I'm doing and everything. And, you know, it's what I realised when I was previously in one of the units, right? Before I was the head of, I was in one of the units, and because my main stakeholders knew the value I was bringing, you know, the rest of it was easy because they would be there and say, you going makes sense. Let's just keep them there because it makes sense. It creates impact, right? And look, product managers would be questioning all the time, oh, but what's Hugo working on? What's the, you know, what does product ops do and everything? And I'll occasionally have to jump in on a call and talk, because I'd be working with a lot with the heads of directors and working with them and, you know, they would see that the impact of the work, but then they would be the person responsible for filtering it down into their teams and then adopting it and everything like that. So occasionally I would jump in and talk with product managers, but it wouldn't be all the time, right? And it was because of this. It was about making sure that they understood the value and impact. But it's also about, and this is a key point, right? Which is, and it goes to, you know, Marty Cagan is talking about this, about the fluff of what, or, you know, of product operations or what it could or couldn't be and that kind of stuff. And it's, the truth of the matter is that even product operations cannot be successful if you don't have strong leaders. And what I've realised is that if you have those strong partners on the product side, on the engineering side, on, you know, the other parts of the organisation, that's where actually the magic happens, because they take it, they grab it, they also adjust it slightly. They'll come back and they'll even challenge us, right? But what happens is they work with us. They don't work against us, they don't battle and they don't say, here comes product ops suggesting stuff with me. No, they discuss it, they co-design, right? And then they almost take ownership for themselves and then take it to the teams. That's super powerful and super useful in that sense. And half of the stuff I did, I wouldn't be able to do if I don't have those partners in, on the product side.

  - Yeah, makes sense. And the way you describe it, it seems obvious, and yet I think that's one area where people are, or some teams are coming up against the problems because they're finding that product ops is seen as the lawmakers, the process creators, the things that are slowing things down. And that's not how it should be. Actually, product operations is the ally to the business. And actually what we're doing is we're identifying their problems and coming up with creative ways that we can solve those, and then letting those teams own those solutions and stepping away to get on the next one. I remember when I was at Vodafone, there was this role called a business improvement consultant, or a BIC, we used to call them. And I think that was probably some form of incarnate of operations at the time, which was they came in, looked at the business operations, saw how improvements could be made, created some recommendations, put them into a roadmap, helped them to implement those. They were never part of that function, but they were there to help drive those improvements. And I think there's massive value when companies can see product operations in that way and get the unlocks that you guys provide. So it's really good to hear that, you know, your success in that story and actually through, you know, the promotions that you've had with these companies demonstrating that product operations is a valuable and growing function.

  - Yeah. I believe it is. I believe it is. And look, it's like I tell people, this might not be the final version of where we're going with these jobs. There might be a new one coming up in a couple of years, right? In a year or two, and it's a new fad name or whatever it is, right? But I think this is what I think each one of these jobs is just taking one step closer to trying to get to that ideal. We're testing it out, we're evolving. And that's the thing, each one of them, hopefully, if we're doing our job right, is an evolution of the previous ones that came, right? So, like you said, product operations isn't new. It isn't new, and there are people who have been doing it in, you know, thousands of ways. And as a leader myself in the past, I used to do tonnes of operations, right? Which was, how does my team get better? How can we improve? How can we reduce the effort? How can we be increase the quality of our work? So we're always doing this work, it it has always existed, right? So it's not completely new. And yes, we do touch on topics that maybe agile coaches have touched on, scrum masters have touched on, right? I think there is an interesting thing that brings, and this is where I find that most product operations folks who have this characteristic have a bit more success is where they aren't so bogged down on their beliefs and their biases that they aren't adaptable, right? Because there's nothing worse if I come to an organisation, I tell them, now you are all gonna work in an agile way and here are the new methodologies, this is how you're gonna work, and everything like that. What happens is the change is gonna be crazy. And usually when something is so strict and so defined, we find that, at least in my experience, I find that in roughly two years it starts breaking down. And if you have this adaptability, if you look at it and you say, you know what? Today a process that came from engineering is my playground. Tomorrow, it's one that comes from design. Next, it's, it comes from business analysts, whatever, right? I play around with these different frameworks, with these different things, and I'm looking, I'm saying, what is the value? How can we unlock that value, that impact that we need with the teams? And that's what we try and implement, right? With our customers. How do our customers get more impact, have more value? Right? And it always goes back to the first principles. What is our purpose? And Chris Compston brings this up very often. He frames it better than I do, but it's to bring the value of our... Bring value to our customers that they're willing to pay for. And that's the simple truth. And you look and you say, okay, then let's add, you know, 500 layers, let's add 50 frameworks. Let's add, I don't know how many people. And you're like, why? Why are you adding all of that? Right? So it is, sometimes it's about taking away as much as possible as well.

  - Yeah, I totally agree. We've been fortunate enough to have Chris on the channel. So folks, if you haven't heard of Chris, please go back and look at an earlier episode here. Hugo, you've mentioned some of the, kind of, some of the mistakes that people might have made there. What do you think is some of the best practises that people can approach product operations with?

  - Like you were, it's a good question, right, Justin? I mean, when you were suggesting earlier that we're seen as the process people, we're seen as the people who are gonna, right? I think a lot of folks go in with that concept of, you know what? As a consultant, I'm gonna go in, I'm gonna analyse the organisation, then I'm gonna come with a report of how it has to change. And now basically I'm gonna do the change management of implementing that change so everybody adopts it and the world is gonna be 10 times better. And what I've seen often when it's done this way is that the change takes longer, right? Number one. And then what happens is people lose track of why they started the change in the beginning. And so they become the detractors of the value of the change, right? One incredible piece of value I like to do is, for example, in my first 90 days, right? I've usually got a plan. I've got my basic plan, which is, you know, month one, it's about getting to know the organisation, getting to know the people, starting to build relationships, which is key, right? You need to build these relationships, you have to get people's confidence that you know what you're talking about, 'cause there's nothing worse than, you know, you try and present something to a product leader or something and they turn around and say, Scott doesn't know what he's talking about, doesn't have the experience. So you have to convince them that they should be listening to you, they should be working together with you, right? But also what I start doing there is I start identifying some potential quick wins or potential patterns that I'm seeing, right? Then in the second month, I start fleshing this out a bit more. What is the long term, the big things we're seeing, but also I start testing out some small quick wins we can do. And sometimes it's a simple thing of, oh, let's just put this extra meeting in, or Hey, let's just change this presentation, or let's just, you know, adjust a small little thing. You spend a day or two on it, right? But the actual impact could be huge. And then you try and define where are we gonna go as an organisation? But what I love doing more than anything else is when I do a piece of discovery or do, you know, deep dive on these things, and then just play it back. Just play back. What my observations, you know, what I saw, what I realised, and the big things both good and bad that I saw. And you know, by doing this, sometimes it's enough where change starts happening, because, you know, I go to the folks and I present and I say, okay, I'm seeing here that people, you know, they're not aligning with their stakeholders, for example. They're gonna go back to their teams and say, folks, I want you to align these stakeholders twice every two weeks, or, you know, once a month at least you have to sit down with them in a meeting. I wanna see this happening. They've already, we're affecting change just by playing it back to them, because sometimes they don't realise, they haven't been able to see that it's happening, right? And then suddenly you spotlight this for them. And this is super powerful. I had someone from my team who did this programme. They ran this programme, then they did a retrospective. And the incredible thing is that then we were looking at, okay, how are we gonna improve things in the organisation? We wanted to talk back to the leaders and we said, oh, you know, there were these five points that we brought out, we presented to you last month and everything, and we wanna see how this is going because we're thinking it's a focus maybe for us for the next quarter. And you know, one turns around and says, we solved it. You're like, wait, what? And they said, well, when you presented that, we got into panic mode. We just solved it. We actually just stepped up and solved it. And you're like, your job is done. My job is done. Right? I think it's these little things so people don't have to assume that it's always I have to come with a full fledged process or way of working or things like that, right? Sometimes it's just about, you know, getting that little spark of interest from them and--

  - I totally agree. Yeah. It's not about coming in with the process, it's about knowing where to press.

  - Exactly. Exactly. No, and what I loved was, and you presented, you share a little story before we started, right? About a customer. You turned around and you said, I could, you know, you could pay me, we could do this, we could do this. But you turn around and you say, you know what? You're not there yet. There's stuff that needs to be done before you can get there. So, you know, let's actually just focus on that first. Let's, you know, let's figure that out first. And I like that sometimes, right? It's not always about jumping to the solution. Sometimes there's small things and even changes, right? Like you want to get to the place who author A or author B has described in their book. And you say, that's great. Guess what? That journey could take anywhere from two to five years. You have to lead people through that journey in a way where they don't realise they're going through it, and ideally at the end of it, they turn around and say, oh, I didn't realise it, but I've gotten there. How do we get here? Right? And they start reflecting on the value and impact that they're creating as an organisation where they've matured to, right?

  - I wonder if there's a pet hate that you see with product ops.

  - So, you know, one of the things that I love is the fact that there are some folks who are consultants and they talk about the negativity of product ops. They don't understand the value of it, right? Because product organisations need to have culture and fit and they have to do their own work and get there. And product leaders we're covering for bad product leaders and stuff like that. And I actually like to flip it, which is, do all these consultants have jobs? Do they get hired to do work? You're like, yes, you've just justified how product operations is needed. It's like, as long as these consultants have jobs, the truth of the matter is product operations is needed, right? It's almost like you're hiring an internal consultant, right? Of course you might look and say, I don't need a consultant for the next five to 10 years. Maybe I did need for a specific thing. So maybe an external consultant is enough, but other times you'll just realise I need someone who can keep giving continuity to this. I can keep doing it and the people build context and everything like that. But truth be told, it also only works if you almost give them the same amount of power you give to an external consultant, which sometimes I've also seen happening where they don't give the space for the folks to do the work they should be doing and then they become an admin role.

  - That's really valuable information. I'm curious what you would say to somebody, maybe someone's listening to this episode right now and they're like, we are doing product operations formally, or maybe as a part-time role, or maybe not even at all. What kind of recommendations or best, or how would you tell 'em where to get started? If they just think, yeah, Hugo, you are right, I think we need this, what would you tell them?

  - Well, it depends. If we're talking about just maintaining internally and where we know we won't get any head count or any specific person, the truth of the matter is, it's just creating a, a cultural habit around, you know what? I just improved the way we do this document, or the way we do this part of the process, I just improved it. Start having a central place where you can share that out, right? Where you can make sure that other, it scales out to other people where you can share with... The same way we do, you know, everybody talks about how we should share about experimentation, learnings, you know, but also mistakes we make or, you know, also impact we create. It's the same thing here, right? Like I've just, guess what? The product requirements document, I realised it was too big. I cut out half of the stuff and we're still working fine, then hey, share this up with the rest of the team that someone else could see value in that, right? I got to see a product manager recently who shared some stuff that they're doing with AI, right? Around optimising their process using AI. And I was like, this is incredible. I wanna share this out to the rest of the organisation, right? But they did it and they shared it in a session and you're like, this is incredible. It's a development session. It's a development culture, right? Where people are just doing this naturally and it becomes part. And I think that's it, right? It's just about making sure other people are aware of it. Don't keep it to yourself, 'cause if you keep it to yourself, your team will be incredible, but people forget, they're dependent on all the other teams having success as well, right? Because the whole product organisation, if it brings success, guess what? You have a job tomorrow. If it doesn't have success, your job, even if you're doing incredible, you could be in trouble, right? So I think everybody has a stake in this and you can help each other. Now, there are people who don't wanna listen, we can't do much about that, but we should be sharing these things out, right? So small incremental changes, record it somewhere, right? Oh, how did I do this? Let me just write a quick document with four, the five steps I did to do this, right? Simple things like this, we do. It's something I also tell my team, right? When we finish something, just write a how to so people know how to do it themselves and they don't depend on us, right? That kind of stuff. Now, if we want to try and actually implement product operations, right? Sometimes it's a type of thing of trying to convince the, you know, one of our leaders or something like that, that I need to dedicate a certain amount of time to problem. You're gonna dedicate to it, and then you show the impact of having improved that, and you look and you say, you know what? I think there's, I what, going through this process identified another five, 600 things that we could look at. I think it'll be justifiable to maybe hire someone to bring on, you know, someone who, or I would be happy to jump in that role. Sometimes people wanna jump into that role and they can create that themselves. If we do a good enough job, if we've got that confidence from the leader, the truth of the matter is, it's sometimes easier. Whereas if it's an external person who wants to try and convince them, it's usually harder. Right? Also, you can get them reading the books or watching a podcast, right? I mean, I know how I got this job in the beginning was to an extent because the director of product at the time had heard about product operations. He had kind of a notion of what it was, but he realised they needed to do improvements and things like that. And he brought me in, but he turned around, he said in the beginning, "I don't know where we're going with this, so I need your help defining it and shift it and things like that." That's perfectly fine, right? It's a playground where I can play around in and hopefully I can show that value and that impact, so.

  - Hugo, you're clearly well established in the space. I'm curious, and we mentioned about Chris Compston earlier, whose advice on product ops do you listen to?

  - I listen to... It's interesting. It's not an easy topic because there isn't a lot of incredible content out there, right? Stuff has started existing, right? I'm not saying it hasn't. So there, there's a few people I use as my sounding board or that I talk back and forth with. Chris Compston is one of them. Actually I often say he's my ChatGPT 'cause Chris and I worked together previously, so our product operations journey started together to an extent. But I also like talking to Denise. Denise Tilles, right? She's an incredible person to talk to because she gives me always these different perspectives on things, right? It's super rich chatting with her about these topics. Another person is Christine Itwaru, who was previously at Pendo, right? And I know she's not doing specifically product operations work, but again, she's super practical, right? She's super direct, super practical. And then, you know, there's the usual suspects, there's Antonia Landi, I also talk to occasionally. So another person is Diana Soler. It's interesting 'cause we, you know, I like to chat with folks online in the area and the space, and so I occasionally schedule some calls with them, but then you start getting, you know, these relationships with some of these folks. And it's interesting 'cause some of them I've never met personally and yet we've had these incredible conversations.

  - I've certainly noticed a tighter knit community within product operations. The people that we've spoken to, some of the names that you've shared, I'm thrilled that we're gonna be either have recorded with them or are going to be recording with them in the channel. But the one common denominator I've found is very close knit group of people that love to be very curious and thoughtful and open to feedback, very open about communicating that they seem like very important principles for people in product operations. And I'm really enjoying spotting those common denominators between you all. So no, it's great to see. And I think if people, so hopefully our listeners are curious to go and look those people up and learn more about them. Hugo, are there any resources that you'd recommend people go to if they need to find more information on product ops?

  - I would say that number one, there's obviously the new book that came up, Denise and Melissa last year, so from Melissa Perri, Denise Tilles, right? It's a super rich thing. And look, folks, you know, and you don't have to read and say, oh, this is my Bible and now I have to do everything that it says in here. But it gives a really rich baseline, and it also explains some of these things I was mentioning around, you know, how do you start from a data point of view, right? For quantitative data. How do you start from a qualitative data? How do you start... So the three pillars, right? Or how do you start from the practises? It gives you a notion of these three different areas and how you could start potentially from there, right? How you could set it up. And so it's a super useful content, right? But then there's obviously, there's a few podcasts out there. There previously was the "Product Operations Podcast" from Gerisha, but unfortunately she now put that on pause indefinitely, right? And, but then myself and Chris also, Chris Compston and I have also gotten our podcast, which is around Thoughts Unravelled. It's called "Thoughts Unravelled", and basically it's just loose conversations we have 'cause we realised we had these conversations around everything and anything, right? It's related to product operations, but also product development. You know, we grab aspects of our design background as well, right? And how this all fits together. But we try and take a, you know, a simplifying look at things. Like let's take, go, go back to the basics. What are these things about? And so we try to go there. There's also, you know, a podcast that Graham Reed and Antonia Landi present for the Product-Led Alliance that they have some stuff there, and then there's, you know, other content around there. It's loose content. I would say the only more structured one is really the book that came out, right? Hopefully we will get more structured content coming in the future, but it also depends on how the role develops, right? Because I've also heard it being called as, you know, some, for example, John Cutler was dividing it between the operations part and the enablement part, right? And it then becomes, okay, is there a new format to this? Is there a new direction this could go?

  - Yes, it is an interesting space, it's an evolving space and one where people are carving out, you know, carving out those roles. But like we've said, you know, regardless of what label you put on it, those things still need to be done by somebody. So yeah, completely agree. And in fact, Hugo, you mentioned also "Thoughts Unravelled". We're gonna put that into the show notes below and some of the people that you've shared. If some of the stuff that you've said already today really resonates with people and they wanna find out more, how can they best get in contact with you?

  - I mean, I'm available on LinkedIn. I just would ask people to actually give an intro message because I have to realise why I want to connect to the folks, right? There's nothing that I hate because I automatically assume someone wants to sell me something, right? So I'm always nervous about that. But also, you know, I have a newsletter, which is "Oh, The Practical Thinker" on Substack, right? I haven't done anything in a while there because of all the work, but yeah. But usually I, you know, on LinkedIn, it's a good place to contact me.

  - As we start to wrap up, I wanna give you the opportunity just to share something with the audience, only if you can think of something that we haven't talked about or you'd want them to know about product operations.

  - I just think the simple thing maybe I would suggest to folks is don't overthink it and don't overcomplicate, because there is this tendency to overcomplicate things, to overthink things and you know, and you look at the end of the day and it's always taking that first principles approach, which is what is the baseline of why are we doing something? Why are we here? What are we trying to solve? Right? It's almost like the concept of when you've got a, you're talking to someone from a new product, right? A product vendor and they turn around and say, oh you know, our product does this, this, this and that, and you turn around and say, okay, great, but does it do what I need, X? And they say, well it kind of does that, but it also has these other 500 features. And you're like, no, I needed to solve one problem. Does it solve that problem for me? And you know, and I think it's the same thing, right? Sometimes folks get all excited about all the potential, all the things that could happen. It's like sometimes it's one little change, you know? And one book I suggest always is read "Switch" by Chip and Dan Heath because it's about how one small change has, can have a ripple effect that can reap huge reward.

  - Great. And I actually haven't read that book. I've got a stack of books here to read, and including a couple of my favourites, which is obviously the "Product Operations Book" there, but a stack here and I'll add "Switch" onto that one as well. Hugo, it is been an absolute pleasure speaking to you today. My final question for you, which is often the hardest question that we ask people, so don't need to get too worried, but it's a toughie, is if you had to distil your philosophy of product operations into a couple of sentences, what would it be?

  - I would say it's about unblocking the blockers that are stopping people from bringing value to customers. And that's just off the top of my head. But yeah, I think that that's a simple truth.

  - Absolutely, brilliant. Well, Hugo, look, it's been an absolute pleasure speaking to you today. It's great that we've met for the first time. We'll be connected on LinkedIn here from there. Hugo, it just leaves me to say thank you so much. It's been a great time speaking with you.

  - Thank you for having me. It's been a pleasure.