What's the roadmap for product operations? | Justin Woods and Phil Hornby

In Episode 26, Justin Woods & Phil Hornby reflect on the biggest lessons from Season 2 of Talking Roadmaps as they unpack the evolving role of product operations. From product ops as a “force multiplier” rather than process policing, to balancing standardisation with team autonomy, the discussion explores AI’s impact on product operating models, roadmap governance, tooling, leadership buy-in, and why product ops may become the team that “designs the machine” instead of simply running it. They also preview Season 3’s focus on go-to-market strategy.

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

What's the roadmap for product operations?

Justin Woods and Phil Hornby

That’s a wrap for Season 2. We’ll be back soon with Season 3. We already started recording but we are planning to move across to substack before we start publishing.

• Transcript

  - But it kind of all depends on what's the shape of the organisation and in particular the product management function or the product teams gonna look like. That's the thing that's gonna define the shape of product operations.

  - I think you're right though that we are gonna see product operations going from running the machine to designing the machine, using AI to synthesise that data. Welcome to the Talking Roadmaps channel, where in series two, Phil and I have been talking about product operations. We've spoken to 25 guests around the product operation space and in this series wrap up, we want to talk about what people agreed on, what they disagreed on, what stood out to Phil and I, and what we think product ops is becoming. Phil, would you add anything there?

  - I guess I'd just add that you know, we thought long and hard about what makes season two and we went for product ops 'cause it was roadmap adjacent. I mean, we're already planning season three as well and that's again roadmap adjacent. 'Cause we've gotta be honest to our sort of our heritage is talking roadmaps. It seemed like a key theme that we should be talking about for the product space because it's just growing and growing and there's only so much material out there. What I've loved, really loved is that we've not just had the experts, we've had so many practitioners in this season, like people really doing the job in real organisations and that's brought a unique spin to it for me.

  - If you're enjoying the channel, subscribe, hit the bell icon and give us a like. Yeah, I think so what I took away was really that season two felt like it moved beyond what is product operations and more into how product ops works in the real world. And I think that goes into what you were saying about bringing the practitioners there, that passion of all of them sort of talking about very similar things. But what really came through was their focus on their mission, what their value was, and really how tight-knit that community of product operations people was.

  - Yeah, I mean, and it's almost the philosophies of product ops that kinda came through to me. I'm a very philosophical person. Someone said that to me the other day in the real world and it kind of chimed correctly. I like to think deeply about things to kind of understand them and you know, there's a couple of mental models that came through for me. One is it's the product of management of product management. Like it's the people who maintain the product operating system of the organisation. The really simple mindset and I think it really trace back to a quote I remember from John Cutler, although he wasn't in this season, but he's something I've heard him say in the past. You like he would say like processes are there whether you recognise them or not. And so there was one that was product operations being done, whether it's implicit or explicit. By naming it as product operations and actually putting people into the role. That to me is just making it explicit and saying probably we're scaling and we need to find ways of doing things consistently and better and actually putting someone in the driving seat for that instead of it being something that happens off the side of someone's desk.

  - Yeah. Big time. Or you know, often sits with leaders. I know it's been with me whereas a product leader, I ended up looking at product operations elements and I know you for sure have done as well.

  - I'm even doing parts of it now in my day job. You know, I was only having a conversation about how are we going to use Jira the other day. And it's like, I don't even understand why I need to have the conversation at this point in time in product management, but I do. And so that's all part of how we gonna work and there's ways of working. But hey we're getting ahead of ourselves. Is product operations all about ways of working?

  - Yeah, I think just picking up on some of the things that you said, a big takeaway for me was that product operations is increasingly essential and like you said from John's quote, we're doing it whether we name it like we're doing it or not, but it's also becoming increasingly misunderstood and I think speaking to our different guests, they've provided some insights into what product operations is and isn't. And so yeah, let's dig into covering the big themes, some of the tensions and where think things are going next. We can talk about product operations as as being leveraged rather than than admin. What do you think about that?

  - Well it's interesting 'cause one of the anti-patterns I'd heard early on around product operations was that product operations managers were almost assistants to the product manager. And to me that always felt wrong. But that and then one of the other sort of patterns we see as they administer or run the tools, like they own the Aha! instance or the Jira instance and they're making sure that it's all set up and working and whilst there might be bits of it, if that's the be all and end all, frankly it's probably IT that should be doing a lot of that. But it's the definition of how to use them to make sure that it's effective and efficient. It's delivering that leverage that I think is the key part that product operations can bring. And sometimes disintermediates, you know, we're product managers, we have strong opinions that I doubt is sounding controversial to anybody out there. Well if you've got three product managers arguing about how to use whatever tool that's gonna be used or what tool should be used, you've probably got at least five opinions in that room and they're gonna be very strongly expressed. And so having someone who can try and dispassionately step back and think about what's best for the organisation, not just for this squad or that squad or this PM or that PM I think is super powerful.

  - And so what I'm hearing there is almost that product operations is the function that designs and maintains the product operating system rather than just admins the tools, right? That's a very, very important thing, if you just bring in product operations as the admins of the tools, there is little value there.

  - What about executing the operating system though? So one of the themes I remember coming through in some of the conversations was facilitating things like roadmap reviews, things like that. One of the most common things that project ops starts with is, we need a roadmap. And so that's the first thing they're asked for. And yet they probably shouldn't own the content, right? But they've gotta... If they need to get a roadmap, how do they do that?

  - I think the roadmap is one of the most common challenges for product managers I think. Mainly because it's a lens on how product management works within the company, but also how product management is seen within the company. And it's, you know, there's been studies around, you know, product management really struggle with road mapping because it encompasses the way that the product works. And so I think in sometimes it's a logical place for product managers to bring product operations into. We've also had some interesting conversations around whether product operations needs its own roadmap as well.

  - I mean, one of the things that I quite liked was the idea of essentially being almost the servant leader to the product management organisation. So they're not defining the roadmap, but they're making sure that the conversations happen. They're keeping us honest and making sure that the data's in the right place so that hopefully some of those leaders can self-service or other people can see what's going on. They're making sure we've got that roadmap or whatever other artefact or whatever other systems we need. Not telling us what should go in it, but maybe bringing us some of the data, some of the facts to go behind it. What's your thoughts there?

  - Yeah, I think so. I think that the danger is when product ops becomes that dumping ground of tooling, admin process policing, chasing updates, kind of the PA to the PMs, right? And I think that's a very poor way of looking at it. I think once they're aligned to value, and actually I wanna pick up something you mentioned there, which is where product operations sits. Because a misconception that I had when I went into this series was that product operations was there to serve the product management function and actually product operations is there to serve product management within the company. And product management encompasses so many other departments there. And that was quite a big realisation for me at the start. And an important clarification.

  - I mean I'd possibly even, we'd say it's there to support the operations of a product led organisation or a products operating model or whatever, however we want to phrase it, whatever's the buzzword way of saying it today. Which means that they're helping design, they're helping engineering, they're helping sales, they're, in fact, one of the things that really came through for me was helping make sure that for example sales have all the collateral and key data that they need as opposed to, 'cause it's usually a sat in the head of these products for people, right? But it needs extracting and putting into a consistent place and helping work with those PMMs so that we get it so everyone has that data instead of it being here, there and everywhere.

  - Yeah, very much so. And I dunno if I'm misremembering this, but also similar to customer success for instance as well, it's like what did each of these different functions within the company need to know? It comes into something that we are very passionate about around audience-centric road mapping and it's very much like, it's audience-centric communication is one of the things that product operations I think supports.

  - No, I think someone said during one of the conversations that product operations should aim to make itself redundant. What are your thoughts there?

  - Yeah, I think that was a Chris Butler quote, but actually I think many other people touched on it as well. And I think one of the things that that shows is it's around being able to come in, understand value, deliver the value, and then move into the next area. And this is again, why we shouldn't think of it as an admin function or a process policing function. This isn't a full-time job in that space and it neither should it be. I think they'll have some processes they own, but really it's around where is the value that we need to provide and they go in and make that thing happen. Which I think in some ways, and we'll talk about this a bit later, I think some ways they do need a roadmap in order to think about where their value is gonna go next, but other times maybe not so. So why don't we talk a little bit about, if we've understood then through that discussion that product operations is about leverage, then let's talk a little bit about when you actually need it. A lot of our guests implicitly describe like a maturity curve and triggers for when product ops becomes necessary. Some of them said it's not necessary until you've got many products. I think you interviewed Jonathan Sheffey recently and he talked about, you know, a certain number of products that are needed. I've spoken to some people about certain size product teams or even a team of one, right? With one of our guests talked about product operations being done as a team of one. But I think we've seen that typically as companies and product organisations scale, there does become a trigger point there. What are your thoughts on that? What have you picked up?

  - So I've picked up that there seems to be a few different ways it introduces like product ops is there all the time, right? We've said that earlier. So you find that it's the point at which the product leader is finding that it's taking their attention away from other more important things. So they're spending more time on this operational stuff and less time on the strategic stuff that they should be. That's the trigger and that should make the justification and the ROI really easy, we all know that headcount that's not directly delivering is really hard to justify. If there's one thing I feel many of the guests underestimated was that need to justify it, I think they may benefit from a little bit of survivor bias. They're already doing product ops so they're already in an organisation that's bought into it, whereas many aren't and don't have it. And it's that part-time job or that extra job, you know, a bit like Amazon 20% time that is really 120% time. Product tops becomes the extra 20% that the product leader is doing or delegates to some of their team to do parts of. And that centralising into one body becomes hard or into multiple bodies. I wonder, I'd really love to see the data on how it appears, but I suspect you'll see a lot of organisations literally jump straight to three people, not just one because they finally realise and are able to make that justification and it's like, well actually we've got 20 PMs here and they're all doing a bit of it. There's three head count across that, not just one. And if we only bring one then they'll only be able to deal with this one issue, not all the things that they're dealing with. And so I think there's, you know, I don't have any should say real data behind that, but that's just a hypothesis of my own that I think I feel like I've seen that a few times, but I can't put my finger on it.

  - Yeah, it's interesting. The thing that I've felt and seen, and maybe that's the bias for me as a tooling implementer, is that I see heads of product and CPOs doing administration of these tools. And you're just like, so you've basically got a very expensive tool admin that's doing this work. And so sometimes that's where it makes more economic sense to bring someone in like myself to help with those implementations. But I think you're right, it's actually again, formalising what exists today in the... I don't wanna say the spare time 'cause it's not in the additional time of these product managers and product teams of product leaders and just saying actually okay, we've realised to your point, this is bigger than one person that was doing it part-time. This is actually, you know, many people that need to do this full-time or if we're gonna make the investment, let's invest. And I think that's maybe another trigger that we see.

  - One of the other angles that I heard come through in a few sessions was the relationship to other ops functions. And I wonder if that's the... Really, when you start to see those in other areas like RevOps in particular, does that start to make life easier in that organisation because they've already bought into efficiency in this commercial part of the organisation, so why wouldn't we do it in the product part of the organisation and how those two can play together and create even more economies of scale.

  - Yeah, it's very true. And so going back to kind of the different, the roles that pick this up, I think at the exec level it's often better ways of working that drive them to need product operations or the roadmaps become incoherent and the leadership can't see what's going on. I think picking up what you were saying about the product teams is often, the PMs are just told to go and figure it out and they can't because they don't have the bandwidth. So really bringing together, there is this point in time when an organisation says, actually maybe it's time. And I think you're right, also learning from ops functions within other departments going, well if they've got DevOps or they've got RevOps, then maybe we need to make that investment in product ops as well.

  - But I guess there's a big risk, they're usually thrown at chaos, they're usually thrown at all these things that are not quite aligned. Then we start to hear that maybe evil p word of process and suddenly product people hate the word process. I mean I'm a great believer in lightweight process. Like just enough, just enough for the scale of the organisation, just enough of the things we're working on. Is there a risk it turns into lots of bureaucracy.

  - Yeah, big time. I think, you know, even in the first season when you spoke to Marty, Marty's famously on record for calling product operations kind of like the process police. Other people have got these functions as well, but the reality is, is that we're all following process or some form of process and even if you're not following explicit process, you're probably following an implicit process. So making it external, making it visible I think is really important. But I totally agree with you, you know, that level of standardisation can be important, but also that bureaucracy can really kill product teams when you're trying to standardise functions. And I get this again with the work that I do implementing a tool, you then try and roll it out to other teams and they work in different ways. I'm very much with you on just enough process there as well. I think what we found was that many of the guests weren't anti-process, but they did agree that some form of standardisation was important. Is that something you saw?

  - Yeah, and it's interesting you know outside of the interviews here, I remember a former sort of training colleague, I worked with, Eden Dunphy. And he used to work at a organisation called Hedgehog Labs, which is kind of an agency model but with a product approach built in. Kinda so they have product managers in the team. And I remember he was quite insistent that for their business model to work, they had to have consistent ways of working in all of their squads because they needed to be able to reallocate people between teams, people needed to be able to join teams. And I know we kind of talk, you know, in this ideal agile world of like every team should be able to work their way they want and this sort of thing. But the reality in most organisations is we flex teams. You know, we don't have exactly the right people over here all the time to work on exactly this theme. And yes, maybe it's a prioritisation call, but sometimes it's just saying, can I borrow these two people 'cause we need a bit more help over here and there's less to do in that area of the product. And if they've work in fundamentally different ways, that ends up being a net loss, not a net gain. And so I think there is a lot to be said for some of consistency and tool chain and ways of working. But even on the tool chain side, like it's also about reporting up. If you've got your data in five different tools, that's inefficient, ineffective, and your leaders are gonna look at it and see one thing in one form, one thing in another and just not be able to understand or compare and it becomes a much harder conversation in the organisation. So I think there's a lot to finding the right level of standardisation, like not everything, but the things that matter and the things that enable that quick collaboration and cross pollination.

  - I think kind of to summarise it, I think that the healthiest view is to standardise the interfaces and not the creativity. So maybe standardise on the language, the cadence, the definitions and the artefacts, but maybe how the teams get there can be unique to that team, let's say. And I think talking about process as a product, that was something that you spoke recently with Becky about, I think she said, that if you don't maintain it, you essentially accumulate process debt. So treat process as a product.

  - I mean you can apply that product lens to everything, right?

  - As a sad product geek, I pretty much apply it to my life and my relationships, so yes .

  - Oh, interesting, so far we've not even talked about data or analytics or anything. Yet often it's a big theme in the product ops world. I think it's one of the pillars in Melissa and Denise's book who both of which obviously we spoke to previously. Where do you think that fits?

  - The data and analytics side was is actually quite a common theme that I heard. There's a lot of synthesising that the product operations teams can do in order to support the interpretation for the product team. So product operations I've seen have done a lot of the collating of data, a lot of the analysis of that data in order to bring those insights not only to the product teams, again to the wider organisation. This was something I spoke to recently with Jake on the revenue op side of things. But it's essentially bringing that data, making it accessible, almost making it continuous as well. Product operations do a lot of that heavy lifting and I think we are seeing a proliferation of different tools that help those product operations teams to bring insights to people so that the product management teams can then do the most important part of their job, which is understanding the value of making the decisions. Is that something you saw as well in your episodes?

  - Yeah, it is. And just because we hadn't even mentioned it so far, I thought, hold a second, are we missing a theme? We should make sure we pull this one out. Definitely, and that's not just of the data, that's the, you know, or the quantitative, it's the qualitative as well, like helping ensure that we're honest about how often we're talking to customers and how we're getting those insights and making sure we have that stream of people we can interview so that we absolutely are bringing feedback loops into our products. But do we need feedback back loops on our product operations as well?

  - It's a good question. I think it depends on the organisation, but I certainly think that there should be, because they need to be continuously talking about their value, especially when product operations might be in this difficult phase right now where they're continuously having to justify their value. I think a lot of the way that they do that is through these feedback loops or insight flow for instance. So yeah, I think it's gonna be increasingly important for product operations going forward.

  - I mean if we are the customer or the user and the processes and the tools they're providing are the products, then absolutely. Like they should be treating like a product and doing discovery with us and looking at data on how we are working. That could be an interesting one with HR.

  - Yeah, it could, I mean sales and support were definitely mentioned a lot. But I think also the executive teams, again the synthesising of that information, sharing it with the exec teams became really important. So product operations really became the system owner if you will for insight to decision flow and not just internal product ceremonies that often they might orchestrate. They were much more integral and much more important. Let's talk a little bit about leadership and how important leadership is to product operations. 'Cause I think in many times leadership is the point in time where leaders go, look, we're too busy doing a lot of operational work. Now we need to make a dedicated team for that. And I think leadership is so important in many areas of product. I've worked for companies where leadership has kind of made or broken the product function as well. One of the interesting quotes that we had from Hugo was product operations cannot be successful if you don't have strong leaders. And I think that just shows how vital it is. Did you have any thoughts on leadership and product operations?

  - I wondered who the primary customer or user of product ops is. Is it actually all those other teams or is it actually the leadership? You know, are they actually who they're there to serve and they do that by helping us be more effective? It's you know, a little bit of a philosophical point again, but I think if we go back to how we justify, it's largely about saving leadership time and saving time so that people can do their work better. That's ultimately serving the leadership of the organisation, enabling them to have better, more consistent data, more consistent view on the work that's been done. More consistent roadmaps coming out. Now, yes, those are all the work products that help the sausage machine work, but they're ultimately serving the leaders.

  - Yeah, it's a good point. And I think they are or is it justification for that function? Especially when leaders are just trying product operations maybe. Product operations can often get seen as a cost centre, right? Until they can demonstrate their value. Again, we had one of our guests, Victoria, talking a lot about, you know, moving product operations from a cost centre to a growth engine. And I think it's just, you know, how a product operations function might have been brought in. doesn't always mean that's how it's gonna last within the company and often they'll have to justify themselves in that area.

  - Well if we come back to that point about making themselves redundant, that's always been a philosophy in my mind. Of generally, if I'm doing the same thing repetitively, then I'm gonna get bored. And I suspect that's true for many people in the product space. And so we're making ourselves redundant by automating or minimising the effort required to do many of these things, which means all of a sudden we don't need to do very much. But the reality is if you've just solved a problem, there's another problem waiting to be solved by you and you've just demonstrated that you are valuable in doing that problem solving. And but as you said, like if a leader's just experimenting with product operations, one of the risks it is that actually they're keeping their hand too tightly on the control, they're maybe micromanaging and it could turn into lots of busy work and that assistant type work as opposed to the truly delegating to a product ops person or team to really have that impact. And I worry that if people aren't fully bought in, but they're trying it, I'm trying to remember who it was, I think it was Jonathan Sheffey, who in our conversation said when he was first introduced to a product ops person in his role at Google, he started the conversation with, I really just don't know what you're gonna do for me. I don't understand, I don't feel I need product operations. And then after a very short conversation it all dawned on him about how much they were going to help him to be his best at what he was the best at instead of doing all the work around the work.

  - Yeah, totally. I think to summarise that, I think in healthy org's product ops becomes busy work central, which is kind of what you were talking to. In healthy organisations it becomes a force multiplier and that's really where Jonathan saw that. And I did smile when I when I read that, in fact that might have even been the upfront snippet of that episode because it was just such gold. Let's talk a little bit about maybe some of the key tensions and disagreements that we saw. 'Cause not everyone agreed in the episodes that we had. And I think the first disagreement was almost philosophical, which is, is product ops a strategic function or a service function? And that picks up some of the stuff we've been saying already. What are your thoughts there?

  - Yeah, I'm trying to understand the difference as I think about it's like if they're in service of the organisation, they're enabling them to be strategic? Are they a function that drives the strategy? Personally I don't think they do, but they make sure we have one. So they're strategic to have them to make sure we are being strategic, but they're not the ones who are driving the strategy. It's not their decision to make about the product strategy and the direction of the organisation, but they're gonna make sure we damn well have a clear one.

  - Yeah, I think both of those are almost important. You need the strategy but you also need the operating model. And so I think we've seen it in two modes. There's kind of an enablement, a workflow and a facilitation versus an operating model, strategic portfolio and decision design. And ultimately both of those are needed. It's just that maybe the team comes in with one and then it evolves into maybe doing the other or both together. I think that's definitely what I've seen. And maybe it explains why product operations has been so variable in the people that we've spoken to. Because often it needs to look different depending on the organisation. Frankly just like product management often does within the organisations.

  - But you know, if I look at those lists you just gave, workflow, well that is our operating model. It's just a slightly different hierarchy of how we talk about it or slightly different way we term it. Decision design or how we make it like facilitation and workflows again are the same sort of things. Like we're creating the space to help people decide and maybe we bring some good examples of good practise. Like only the other day I was running a workshop, a strategy workshop internally. And the first comment was, oh, we need to all decide together. I said, no, we need a participative decision making model. So everyone gets to have their voice, but there's the person who owns that decision and... 'Cause that allows us to move quickly and have ownership,

  - The disagree and commit, right?

  - Yeah, and that's the source of structure that a product operations person can bring. Essentially I'm doing bits of product operations there in that, if I think about it. You know, you can see that as a strategic capability or about facilitation and to me they're just different ways of phrasing it and maybe the different ways you sell it to the leadership in that particular organisation because maybe politically someone doesn't want to give away the power. So you'll talk about more facilitation and workflow and enablement. Whereas if someone is really wanting to see them as someone who takes them by the reins and drives things forwards, you'll talk about well, we're gonna define the operating model, we're gonna drive the decision making approach, et cetera, et cetera. They're doing the same things. It's just how you phrase it, it's communicating to the audience.

  - It is, and that brings up kind of maybe a side question here, which is where product operations fits. That was very interesting as well. You gave some great examples and personal anecdotes from your time experiencing it and certainly speaking to other people where product operations might have sat under a function that didn't make sense, but from a leadership perspective and the personal qualities the person it sat under, it made perfect sense. And that's another variance that we've seen that often it's not just reporting into product management. It might be a, its dedicated function in and of itself and I think that has some, you know, some political and organisational challenges but benefits there. And also sometimes it's just sitting under the right person. What do you think there?

  - I'd expect it typically reports into the top of the product tree, but then that's usually got design sitting there as well. You know, you tend to get a product manager at the very top of the tree and a product designer one level down. That's just the, what I see in most organisations. Sometimes you get engineering reporting in the same place if you've got, especially with the new hybrid CPTO type roles. And operations then sitting up, then you've got DevOps or EngOps and this sort of thing there as well. And do you bring those two together or as I think we had with one of the guests, they said they're actually reporting into one of the directors of product because that was the best place for them to be. They could advocate for them but they could also bring the structure. I think it was a relatively small product ops team within a much larger organisation. And so I suspect there's also maturity and the scale of conversation that happens there and seniority of the person leading. If you've got an individual contributor and they're reporting direct to the CPTO, it probably sends the wrong signals around the rest of the team. So politics kick in, it's. But that's my thoughts. What are yours?

  - I totally agree. I think a lot of it is down to leadership, right? And the advocacy of leadership and sometimes it might not make complete organisational sense for the function to live there. But actually from a strategy a direction, a advocacy, a sponsorship perspective, it makes total sense. I think again that's what makes the field so wonderful and interesting from organisational design perspectives. But I think it's around whatever's right for the organisation, wherever it's started from, there's a little bit of a kindling there and once that fire is going then you know, maybe it makes sense to change it over time but it probably makes sense for it to at least belong at initially where the need was because that's where your sponsorship and your advocacy is.

  - I mean, and obviously for putting it in with those other functions like EngOps and DevOps and this sort of, there's probably a lot of tools involved here 'cause they tend to own a bunch of things like the CICD pipeline and stuff like that. So do product ops really own the tools? Should they really own the tools?

  - Yes, it's a classic, right? And I think that was one of the biggest areas of divergence that we saw. It can be powerful because sometimes those tools underpin the operating model, right? That's what we talked about. That's one of the key frictions I see as a tooling implementer is that it's very easy to configure a tool. What's difficult is configuring it to your processes and the ways that your company works but actually also really how it works. A lot of tension I see is I come in to bring a tool in, but actually the processes and the operating model of the company is poorly defined and that's where the rubber hits the road is when you codify it into a tool and prove that you just didn't understand how the organisation works. So I think there's a big area of divergence there. I do think that it's also a tension and product operations have got this difficult role of not being the tooling admins, but they need to do enough oversight to standardise the way that teams work and also unify it. You know, the amount of times I work with companies where they're still using the system from two system migrations before because they didn't standardise it properly and you've still got a team using Smartsheets, you've still got a team using PowerPoint, then you've got a team using the new product stack. So I think there's definitely a lot of standardizations work there but the admin side is a trap I think for product operations and they need to do well to not just become the admins of a tool.

  - Yeah, I mean I think we had Chris Constance staying all the way back in episode one that if you're a small team, one or two people, you should be thinking far more strategically than tool management. I think there's maybe something to do with adoption curve here as well. Like in the very early days when you're a small team with one or two product ops, maybe you do do a lot of the setup but then you find you make yourself redundant, you figure out how to hand it over to IT. As you get bigger, maybe you've got IT partners you can work with to do a bunch of the stuff for you and you become more of a stakeholder driving it. The person who's kind of caring about the outcome, the adoption, the workflow, maybe the change management is your focus instead of the actual tool management. It doesn't have to be a one size fits all. It can be one stage of your organisation and the maturity of it and the size of it, but also the stage of adoption of a tool as well. Like maybe the right thing is to go really deep and hands at the early points and then gradually step back.

  - Yeah, I think so, go where it's necessary but also just be respect of the product operations mission, which isn't to do the, you know, the IT function there as well. So Phil, that's some great tensions there and we've spoken with guests about many more as well. But maybe let's just think a little bit and zoom out and think about the direction of travel. I think product operations has been round long enough where it's gathering its maturity. There's also a forward looking, many people are saying that product operations needs to mature in order to be able to sustain and validate itself as a function. Where do you think product operations is going next?

  - Era of AI right? Maybe it's gonna be a flash in a pan and disappear in a month, I don't know. In all honesty, I think the work will continue whether we call it a function or not, hey, they can be a great team to help us figure out where we can get benefits from using AI in our workflow et cetera, to can kind of experiment. But I struggle to predict the future here because we seem to be in such uncertain times in the product world. Like I don't fundamentally think that product management is going away, I actually think it's going back to a little bit how it used to be a bit more business centric. We're we seeing a number of challenges like some people talking about product builders and this sort of thing. I don't think I personally know many product managers who want to maintain the product at that level of debt. Or maybe our hands will be forced by the organisations who want lower head counts, et cetera. But it kind of all depends on what's the shape of the organisation and in particular the product management function or the product teams gonna look like. That's the thing that's gonna define the shape of product operations. Product operations might suddenly become the far more important function because it may well be operating and managing the whole agentic AI frame tool set that is actually replacing the entire products team or 90% of the product team. You know, that's one I guess extreme version of it. A less extreme version could be very much a continuation of what we see now. And on the other end of the spectrum we could have it disappears and we just say product managers do it again because they've regained a lot of time because they're being more efficient with AI. To personally think that if we regain more time then that gives us more opportunity to deliver and create more value. Therefore we should spend our time there and it's worth having those other people helping us do that.

  - I'd hate to see engineering become the IT function that supports the code and the functionality that the product management created, right? I think that would be a dangerous anti-pattern. I think you're right though that we are gonna see product operations going from running the machine to designing the machine. Using AI to synthesise that data to what we talked about before. You know, product operations may end up then doing a lot of the low leverage work of reporting summarization documentation powered by AI, which then allows product ops to be working on the facilitation, the sense making and the decision design that we've been talking about. I think that's gonna be very interesting. And like you said, I think ai, you know, is going to change the way that product gets built across all departments and functions.

  - But, one of the things you mentioned there is things like reporting using AI. Well why isn't the leader just gonna ask for the report they want to the AI? Like why does someone need to do that admin work? It's more making sure the AI is plumbed in and can provide that data. 'Cause every leader wants their data in a different format. Now I have a slight sort of issue with that. You know, people kind of very much see that. It's like, oh they can just ask for the data in their format. You know, we're about you kind of surfacing the insights that that particular leader wants. But I've seen board decks and things like that, they typically follow a very consistent format and you want every deck, every board meeting to have the same sort of format. You want every product presenting the same way. And all the leaders to be looking at the same data at the same time, not five different views because otherwise who knows what's right. And so I think, you know, there's a lot of kinks to be worked out around that. But making sure that the capability is there for leaders to get the data as opposed to being the secretary that asks for it or the PA that asks for it. That is really low leverage. And you use that word when you talked about they could end up doing it. but if we go all the way back to the start, we said it's about leverage. So we don't want them doing low leverage work, we want them doing high leverage work.

  - So we are coming to the end of season two. We've got some thoughts for season three. Let's maybe something to share with the audience.

  - What's the subject Justin?

  - We are gonna talk about go to market. Again another roadmap adjacent area of talking roadmaps. We are gonna be going into other seasons which I'm really looking forward to. But this one was particularly interesting to me because it's an area that as an internal tools product manager, I've not really been exposed to the go to market side of things as much as I maybe a commercial product manager. And Phil, you mentioned to me that there were kind of four areas within there that we can explore and I'm wondering, putting you on the spot now, but wondering if you can remember them. 'Cause I thought that that was particularly interesting and maybe you can unpack what go to market really means.

  - I mean, yeah and the term is loaded. Some people use the term go to market to be synonymous with launch. Like we are taking this thing to market and it's an activity for at a period of time. More often in the early stage space. I find the term used to mean basically all our commercial activities, like it's. Because the reality is we're always going to market, so we're gonna pack in a bunch of subjects. We wanna make it quite diverse like pricing, packaging, product-led growth, product led sales, metrics, product marketing. What else have I missed, Justin?

  - Gosh, I don't even know Phil, I do know that we've got some excellent guests that we've got lined up. We've got some new people in the space, we've got some aspirational people in the space that we're really trying to snag for that episode and maybe we've got some authors and some other people to bring in as well. That's the bit I'm looking forward to. We're gonna aim really high and try and get some big names. But again, we found a lot of golden nuggets in the practitioners and I'm looking forward to celebrating them as well.

  - Yeah, I mean I know for example, I've got lined up someone who's done the zero to one taking a product to market and then successfully been acquired by a large company. So, you know, they've gonna have some interesting stories to tell. So yeah, very much trying to bring the experts and the practitioners all together in this story and bridge that gap of an area that when I started product management we did a lot of, and so I have had that large amount of exposure to. But it's over the last 10 to 15 years become less and less common. But I think it's an area that's growing and growing 'cause it really ties directly to the commercials. Like what are we really here to do? If we're a product manager in a business, we're here to make money, which means we need to take our product to market, we need to market it and we need to partner with all these other teams to make ourselves effective. And they're not the teams like the developers and the designers. We've got another team that we're part of and what we work with with product marketing, sales, marketing communications. And we need to really kind of understand how they work because that's gonna drive success of our product.

  - Yeah, big time. And actually I wanted to kind of correct myself a little bit there is that even though I wouldn't see it as commercial go to market, as an internal tooling owner, it the announcement of new functionality, new things was, you know, go to market doesn't have to be commercially to your customers and your customers don't have to be paying people. Your customers can be internally as well. And so there was a level of go to market that we needed to do, but I always have this commercial bias in my head when I think of go to market.

  - Yeah, I think it's gonna be a super interesting, as you say, it's another roadmap adjacent and I know we wrestled with strategy as our other sort of potential subjects that's probably series four already in the can, but this one just felt interesting and I think we've already got eight or so people lined up to record with. So look, it's already shaping up to be an interesting season.

  - It is and I'm really looking forward to going on that journey with you into a new space. So Phil, thank you for again, another season of really enjoyable conversations. I've loved being the co-host with you on "Talking Roadmaps." Other than that I'm really looking forward to sharing this with our guests.

  - Likewise, I think it's gonna be a great season. It's, yeah, it's also been great partnering with you for the last season and the first season as well. And I mean, what I love is we've been lovely, nice and flexible as well. We've brought in some extra bonus episodes in the middle where you know, people like authors have reached out and said, can we come on and have a chat about our content? Because we know that's super interesting to our audience as well.

  - Yeah, absolutely. Awesome. Well Phil, thank you so much. Looking forward to what season three holds.

  - Likewise. See you in season three everyone.