What’s the shape of your Product Ops, and should it change? | Anna Prevo

In episode 23 of Talking Roadmaps, Justin Woods speaks with Anna Prevo about the evolving shape of Product Operations and when it needs to change. They explore scaling beyond 100 people, clarifying boundaries between Product Management and Product Ops, avoiding process dogma, strengthening experimentation and data loops, and improving product–go-to-market alignment to drive speed, clarity, and ROI.

Anna is the Head of Product Operations at Ceros and a Community Manager for TopProds, where she supports and connects product operations leaders around the world. With over a decade of experience across product, agile coaching, and operational leadership, Anna specializes in building the systems, tooling, and practices that help product teams scale effectively.

At Ceros, she focuses on operational excellence across product strategy, launch execution, and cross-functional alignment. Her work includes designing scalable tooling ecosystems and exploring practical AI optimization within product teams — helping organizations leverage automation and intelligent workflows to reduce friction and increase strategic focus.

Through her work with TopProds, Anna plays an active role in fostering community among product operations professionals — creating spaces for shared learning, surfacing emerging best practices, and advancing the maturity of the product ops discipline.

She’s passionate about building operational infrastructure that empowers creativity, enables better decision-making, and helps product teams do their best work at scale.

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 shape of your Product Ops, and should it change? | Anna Prevo

Anna Prevo and Justin Woods

In the next episode we have Jake Burghardt, Consultant and Author. So watch out for episode 24!

• Transcript

  - We want a formula. We want a set definition. We want to know how to make the split and move on. That's not a thing. We just need to let that concept go because just like product, really defining out your product ops function and sort of building out, you know, different departments and roles within your company as it scales is an iterative development, and it's a bit of trial and error. You have to have an understanding of the bigger goals, just like your company, but ultimately it's okay if your first attempt at implementing product operations isn't perfect.

  - Hello, everybody, and welcome to the Talking Roadmaps channel. I'm one of the co-hosts Justin Woods, and, in season two, we're talking all things product operations. Today my special guest is Anna Prevo. Anna, welcome to the show. Please let us know a little bit about yourself.

  - Yeah. Thanks. So, my name is Anna Prevo, as was stated. I'm head of Product Operations at a company called Ceros, where we're working on martech. I kind of have a bit of a meandering road into product operations. I spent most of my time in somewhat product roles but only some of it and specifically product management. I've also been a Scrum Master, Release Train Engineer Consultant, and so on and so forth, and it all kind of mapped out into the space where it made sense for me to work on the operative functions behind product, and here I am, and I love it still.

  - If you're enjoying the channel, subscribe, hit the bell icon and give us a like. Amazing, it's a bit like myself. As we were talking a bit before we hit the record, kind of like my career makes sense looking back, and joining all of the dots has made me be really effective where I am now, but we didn't plan it that way. So you mentioned that you're head of Product Operations at Ceros. Tell me a little bit about why companies need product operations.

  - Yeah, so that's the golden question, right? So, I'll say it. I hope we all already feel it. Product operations is already happening. It's kind of like asking why do we need plumbing in our house? It's there. Maybe it needs replacing. Maybe you have some rerouting for some of your pipes because they're just not good. Maybe you need to change a wall because you want to change the layout entirely. But you still need it, and it's already there. So the question is, "How are we optimising?" or, "Why do we need to optimise product operations?" And that's the question where we start to talk about, "Well what are you paying your product people for?" You're getting these really talented folks coming in to think about the vision of your product, to think about what your customers need, to build and work with your engineers to make something fabulous that's ultimately going to make your company money and keep you striving and solving great problems. That can't happen and also build all of these systems that need to happen to support all of those functions, to deal with your tech stack, to deal with the various team organisational pieces, the development cycles or connecting with your go-to-market teams, or maybe you don't even have good data yet. All of that needs to be built out, and you're paying these people. They're already running here, and then you're asking them to also work down here. But if you cut all of that off, and put that in charge of another person who is highly focused on that, all of a sudden, the people that are working up here can do so much more. That's my opinion on why we really need to be thinking about product operations as a, this is an imperative function as your company starts to scale. You might not need it when you're 20 people. You still have product operations when you're 20 people, but that many people can manage it, but when you start to get to 50, 100, 200, 1,000, your product teams expand. That mountain under all of that molehill expands, and you need so much more to support it. So it's great to have a person or a couple of people who are really honing in on it.

  - Totally, yeah, and I think I've seen that totally within my career as a product leader. I ended up doing some of the product operations for my team as kind of an enabling function to help them do what they need to do. And I love the analogy you used around plumbing. It's kind of like, look, product operations is being done, whether it's implicit or explicit, and so that conscious decision to say, "Right, now we need to make this an explicit function. "We need to dedicate capacity, "a capacity or even roles to it, "and that's a bit being the important bit to scale, "and then make that an explicit function "so that we can improve it and make it visible, "I think is really important." It's a lot like when people say, "To not have a strategy is a strategy," or, "To have product operations "without calling it explicitly product operations." You still have it, but making it something that's explicit is really important. So I love the way that you frame that.

  - It's empowering too. And if you think about it like the evolution of how product teams and product management has kind of come over the last 30 years, maybe even 50 years if you want to go back that far, we've had a lot of different spaces where operative functions have happened. We started to think about tech stacks. We started to think about product data. We started to think about development life cycles and agile and all of these things. And we had specific people that we hired, where we tried to encompass these various aspects of product operating models. But if you start to give this house of product operations to a couple of people where they can look at that whole picture, it's the same as giving a house to product management where they can look at the whole picture of where your product and your product strategy and your customers are kind of going. No longer are you saying, "Do I have to have an agile person? "Do I need to hire an agile person? "Do I need to hire a data engineer?" You have a function, a house in a sense, that can think about where all of the problematic areas are in your product operating model, and hone into one of those pillars. It doesn't have to be all of them. All of them are there, but one of them might be more problem-causing than another, and they can actually specialise in finding the right people or solving the problem themselves.

  - Very nice. Yeah, that makes sense. So I wonder what some of the key responsibility of product operations are, because there's, you've mentioned a few already, but how would you describe that kind of in response to that question. What are the responsibilities?

  - It's wide, and it does, I do think it kind of, it morphs depending on the company that you're talking to and even their sales model that they're working on. All of those pieces will really dramatically change what product operations is functioning on. I think, no matter what, there are a couple of main pieces that they focus on, but where the weights are really heavily depends on, again, where the problems are, but you're gonna have data and insights. So think about your customer success teams and your call recordings and your event to data and your account to data. How is all of that coming together so that your product owners can actually understand what their users are doing within their applications, have a means in which to connect with those users and ask them questions and therefore solve the right problems. So, your understanding of your users and a means in which to house and collect that data is a big part of product operations. Having a process governance. How's your whole pipeline being managed when it comes to product management from ideation all the way to deployment? Do you have a space for experimentation and to look at that data from, you know, different aspects and try different things. Do you have a way to productize that? Do you have a way to get that out into the go-to-market teams? Are you connecting with the other teams that are involved with that like your enablement teams, your support teams, your educational teams, depending on how big your company is, of course. And then, in addition to that, you're gonna have your tech stack, right? You don't want your product managers to be trying to figure out when Productboard or Jira needs to be renewed and, you know, how many different admin pieces need to be finagled the next time you realise you need to fix a automation that happens with all of those. Like you want some people dealing with that and not your product owners. And then I kind of overlapped it a little bit because sometimes that can happen, but your process governance also kind of wheedles into your go-to market connection, and that can be your launch operations, that can be your roadmap, that can be your communications cross-departmentally, and then all of the in between. It's a very connective tissue from product to go-to market, but it's really important to think about it as an undercurrent that supports the vision and makes it possible to happen. And then, of course, depending on how your company is laid out, you might have more of a focus in different places. So, if you're a sales led, you probably have dedicated marketing teams, enablement teams, support teams, all of that kind of stuff, and they're very focused on getting a lot of support. I'm gonna say support. There's another word that I was gonna use, and it's probably not a good one, but support to your go-to market-teams, right? They're gonna have a big infrastructure there. So product ops is probably going to be more centred within product, maybe higher in on the pipeline, maybe more in the ideation-to-productization phase, but you're still gonna have some connective tissue to make sure that those teams have what they need to get the go-to-market teams ready to go. If you're more product led, you have less weight on that side of the house, right? Like it's more the product is doing the work. So a lot of product operations might be more essential nucleus to the entire company because you are thinking about, "What are all of these things that need to happen in order for the customer to be successful, in order for the product owners to be successful in what they're building, and how can I make sure that those infrastructure pieces are at hand, readily available, and organised appropriately for people to take what they need and for the product to do the work. So you can even have, like, I've seen some bigger teams where they even have enablement like within the house of product operations, and those are product-led companies, right? The enablement looks very different. You're not necessarily enabling go-to-market teams as much as you are enabling the product, some go-to-market, and a lot of support.

  - Yeah, absolutely it does. I think it depends on the company, the size of the company, the types of products, the maturity of it. I think that's why product operations can be quite difficult to define fully because it goes in, and it's the connective tissue, and, at different points, that connective tissue needs to look different, but I think you touched on the big ones which was the data and insights, the process governance, the tech stack, the go-to-market and the enablement of that. Go-to-market, in fact, is gonna be Series 3 for "Talking Roadmaps," so we're actually gonna be going a lot deeper into go-to-market as a really important part of road mapping but of course product management in general. And I think what was nice is that you talked about that connective tissue and that it helps almost all of the departments within an organisation. Is that typically what you've also seen as well, product operations helping almost all of... It's not there just to serve product management, right?

  - So I think that the best way that I would say this is, on some level, you're gonna have your team one, and your team one is still most likely going to be your product owners, but that doesn't mean that they're your only team. I've spent much of this year working with go-to-market enablement-type teams. I've worked a lot with marketing teams. I've worked a lot with enablement and a lot with support. My product owners are still my go-to, but, ultimately, I'm building all of this infrastructure for those teams to be able to tap in to what is happening with product and get what they need. So it's a very cross-functional role, and I think it's imperative that people who are moving into this role, if you don't have the experience working with a lot of stakeholder management or a lot of cross-departmental sort of experience, you may want to start laying those grounds to get into that because it's really necessary for this role to be successful. You're not gonna spend all of your time on data. That's gonna be one thing that you'll build for a little while, and eventually you'll outgrow it, and these other parts need to be taken care of. And those teams, I think we'll find historically, looking at most companies in most places, there's always a little bit of a tension between go-to-market and product, and a lot of that falls on people like product operations folks to sort of bridge that gap and make it manageable and successful for both teams.

  - Anna, it sounds like a lot of your rich history and experience from it being in the agile world, Scrum master business analysis has really set you up for success in your role at the moment as a product operations leader because it sounds like it's given you that empathy to understand those different business units and what they need. Would you say that was accurate?

  - Yeah, I would. And I would say that's a grown muscle. Like a lot of people, I started off in one area of the company, and I didn't understand other parts. So if you had asked me to move into and do the things that I'm doing now in product operations at Ceros when I was a business analyst at Aprio 10 years ago, I wouldn't have really understood the pain that customer success people feel when they're trying to deal with: talking with customers, expanding an account, and then asking product to make a feature that they think that they need that may or may not be a good idea. Like, it's hard! It's a hard life over there, and, equally so, it's a hard life when it comes to product and trying to understand what customers actually need versus what people think they are already problem solving for and being able to build out those lines so that everyone can have a great understanding, including the customer success teams, so that we're all bought in, and what we're building on our roadmap makes sense, and everybody can sort of support it from their various lines of communication. So, you know, I think that my having a foundation in product helps me to be a great support for my team one, for my product teams, but spending the time that I have, over the past several years, being deeply connected with the customer success teams, with those leadership there, and starting to understand how account churn and all of these other things happen, how those conversations happen, how do we start to get more connection from product to the customers in a way that is both meaningful for saves, for renewals, as well as learning for what we're building and those kinds of things. Like it's really created a better story both in terms of what I need to be building for those teams and also starting to be able to change how product and those teams work together and how we even deploy so that it makes more sense for what we're building. We've made so many changes in Ceros, for example, on how we build, both to build faster, to build more sensibly based on business goals that make better sense for what we're trying to build. Sometimes that means saying no, but because of the data infrastructure, because of the customer insights, because of the better connectivity that we have, we're better to able to explain why and incentivize and help to support the go-to market teams where they have to support those decisions, or when they have a great idea, they have a place to talk about it.

  - I love the kind of the commitment to team one. I think that's really important to know who we're not the only team that we serve, but kind of the main one or the important one. How do you ensure that there's no friction or overlap with the product management function?

  - So I would say that when we first decided to truly define product operations in Ceros, there was friction. It's sort of natural when you're trying to teaser out. Like you've gotta imagine like, yeah, yeah, exactly, you're splitting it out, and so you have to sort of help people understand they don't have to do this anymore, and it's actually not value add for their time. They'll be much better spending their time doing A, B, or C. And so you have to have a lot of those conversations. I would suggest a lot of one-on-ones with your product owners, a lot of listening, because I don't think that there is a good set definition of product operations versus product management. I think what's important is the mindset, right? What you don't want is two different factions within a company trying to control the direction of the company. What you do want is people who are really great at vision and building and connecting with customers. You want them to be supported to be able to do that as quickly and as fast as possible and with high quality output. And then you want people who are really great at building systems and thinking strategically about systems. So you've got two different product owners, right? You've got product owners for the customers, and you've got product owners for the product owners and for the business, and if you start to teaser out that mindset, then it gives clarity for the product ops folks on what they really need to be focusing on. Even when they think that they might be helping something, and it's causing friction, they can have better conversations on what they're trying to solve for. And same with product owners when they're trying to figure out, "Okay, well this was my job. "What do you mean you're doing this, this, and this. "Okay, but if I don't have to do this, "then that means I get to spend more time "talking with customers, "I get to spend more time running tests "if that's how we define it out, "I get more get to spend more time "like looking at the bigger picture "and sort of taking all of the insights "that I now have access to "and working with my engineers "to build out a great next quarter." Like there's, I think it takes a lot of conversation, and it takes an understanding of the pillars that I'd mentioned before, and it takes that mindset, like, you really have to be thinking about it as supportive leadership versus visionary leadership and then separating those out.

  - Right. Very well said. I agree, and I think that honest communication, constant communication to drive clarity, to reduce ambiguity, to know when that there's overlap, and that what we can do about that so we're not working on the same thing or against each other on the same thing, I think makes a lot of sense.

  - I think it's important, and this comes from my experience with all the agile stuff as well. I think a lot of times we want a formula, we want a set definition, we want to know how to make the split and move on. That's not a thing. We just need to let that concept go because, just like product, really defining out your product ops function and sort of building out, you know, different departments and roles within your company as it scales is an iterative development, and it's a bit of trial and error. You have to have an understanding of the bigger goals, just like your company, but ultimately it's okay if your first attempt at implementing product operations isn't perfect. What you really need is to just have that great line of communication with your team one and with the business to make sure that you are solving for the right problems and you can dodge and weave when it makes sense to pivot on a different and that's okay, it is 100% okay, but don't expect a quick fix or an easy application for any of this stuff because, as we went over earlier, what product ops looks like is gonna be very different in different companies, and it's just important that you understand what are the problems that need to be solved within the general realm of what this role is supposed to be focused on.

  - And because of that high degree of variance, and I think you may have already said the answer to the question I'm gonna ask, which is, "How do you justify having product operations?" And I think a big part of that, to tee you up, is knowing what problems we need to solve, and the value is in the solution to those problems.

  - Yeah and I would say like we should always be looking back at the ROI for it. That can be as much of a reason to wind down as much as wind up. It really depends on what your company needs. But I would say, on a general level, when you get plus 100 people, you probably need to be talking about having some sort of focus on organised product operations because, at that point, you've got scale and with scale comes problems, and then when it comes to your ROI for that, I would say that, think about it like having laundry service or a clean house or somebody that helps you cook when you have like a bunch of different things for a massive party. Like, it just makes things move so much smoother. Your product owners can be faster, your engineers can be more coordinated, your go go-to market people might be a little less pissed off because they actually have the answers that they need and a means in which to solve their own problems. Like things just move a little bit smoother, and, because of that, we can build better things. Ultimately the worst thing in the world is when you spend all this time weaving back and forth because you can't make the right decision. You're going on on what you need to be building for product, and ultimately what you put out there, you say, "Oop! The feature is done!" But did it actually solve a customer problem? Either you don't know, which sucks, or you do know, and it wasn't as good as you thought it was because you didn't have a means in which to experiment or validate in the first place because that wasn't built into your system. Having somebody who's really focused on that makes all the rest of the stuff, it's like target practise but like with a scope. You've got a scope now, and you're far more likely to hit a bullseye every time and much faster.

  - Amazing. Yeah, great analogy, and totally agree. I wonder if we talk a little bit about some of the good practises that you've seen in product operations and also maybe we can talk about some of the anti-patterns there as well. From your experience, and the people you speak with as well, 'cause I wanna talk a little bit about the community that you work with, what are some of the best practises that you've seen or heard others talk about as well in product operations?

  - I guess, first and foremost, you really probably need to centre in on the mantra that you are not there to be a product owner. You are there to ensure the success of product owners. So what that means is there's often some friction that can happen, even around roadmaps. Who's owning the roadmap? Who's driving the roadmap? I'm in the camp of product owners should be driving the roadmap. You are there to make sure that they have everything that they need so they're making great decisions on that roadmap. So a best practise would be, for what my recommendation for product ops people, is to be thinking about like, as you're going into something where you're driving change, what's the rationale behind it? Are you there to be making people more successful, or are you there to try and control something because you're gonna have to segregate yourself away from that. This role does tend to attract people who like organisation. We like to be able to sort of have things in different boxes and know where to go afterwards, and we want other people to follow the same rules that we laid down, which means that we can often fall into the trap of trying to control the output, whereas it might actually be better to accept some variance on your output, know that there is one goal that you're trying to achieve, and make sure that that goal is gonna be supportive towards the success of others. So, I'm speaking in concept, but an example might be that when we first started trying to lay this out in Ceros, we were trying to figure out how we would organise the product owners and sort of separate out the different teams so that they had the right people, small groups, you know, to talk through their various problems. And we created some management teams with the product owners leading, and then, you know, dev leaders and so on and so forth. So they had like a problem-solving group that they could work with. But then, on top of that, we tried to set up sort of a visual aid for what was going on across all of the teams, make sure we understood any of the blockers, any of the dependencies, any of the other things. And it turned into, "Well, Anna's gonna tell everybody "when there's a problem" "that might turn up in another team, " and you can... We're laughing now, but it was not great then. But what we'd learned from that is having some visual aid on what was happening across the board in a way that people could consume and having the right people in the room worked, but having one sole person be the only person who was responsible for calling that out, that didn't work. Making sure that people were bought in, they could use the process and the system that you put together, and they had connection with everyone else. They knew what was going on with everyone else. So, you know, product owner A could say, "Hey, this team over on this other product "is working on a feature "that's actually going to impact mine, "and they need to be ready by this certain release "because we have dependent releases on this," they could do that without me having to step in, and, frankly, they're a better person to do that because they have the technical know-how on those pieces to call it out. So it was an iterative process. and trying to control it, from my standpoint, that was a fail, that did not work.

  - But we learn quickly, right? And so it it sounds like principles in guardrails is much better than very distinct processes.

  - Exactly. Exactly. And I would really harp in on that for people who get into this because it's very tempting to try and, you know, make everything clean and pretty, but that's not how it works in product. We know this, and we're just going to have to adapt to the fact that there is, you know, if we can get this one piece in and continue to learn and iterate on that going forward, that's a win, that's a win. If we're making people faster, if we're calling out some of the issues in better ways... Better yet, if you've got people who are buying into this and saying, "You know what? "I have an idea of how to make this even better," and they start to implement that, that's awesome. I would encourage that because then you're no longer a team of one. Then you have, you know, champions that are around in your various teams that can start to ideate. That started to happen with us as well. We had one person who, their teams were, the product teams on that end were organised a bit differently. They were all feature teams, right? They had some full stack for the most part, but everybody was kind of working along the lines, and they would sometimes share features, so they found that organising things by naming the teams, it didn't work that well. Like it worked for their general conversations, but it didn't work that well for fast communications. This was also global teams. They were all across the areas trying to figure out how to talk to each other. So they organised Slack channels based on the feature that was happening, and whoever on whatever team could jump in and see everything that was going on in the narrative of that particular feature, and we also used some of the canvases on Slack to name which Slack channel was where, so that if you weren't already in the Slack channel, you could see if a new one had popped up, and you could jump into it if you needed to be a part of that conversation. It was super fast. It was not my idea, but I thought it was great, and we built on it. And I think stuff like that, that's a huge win. That's another thing that I would call out for product ops folks. You don't have to do it on your own. You might champion it. You might make sure that it's happening. You might help to have some ideas and some problems that you can surface, but you don't have to be the person who solves it, and you might not even be the person who spotted it, but you do need to be the person who can support it when you see something good happening.

  - Be the spotlight sometimes, right? Just shine it on an area of excellence, and just say, "Right, that's something "that we need to standardise more as an entire company "rather than just a single team." And what about some of the, let's say, bad practises or anti-patterns that you've either experienced or heard from others? What are some of those where product ops has not really done well in that regard?

  - We shouldn't go in, as product ops people, trying to tell developers and developer teams exactly how they should work. We shouldn't be on the Scrum dogma or any other sort of development practise out there. Our job, and this is what's incredibly enabling about product operations, once you kind of get to that mindset, you don't have to marry yourself to any one practise. You get to look at all of them and figure out which tools might be helpful to your team. Show them the tools. Tell them how they work. Help them to try them, and then help them to change them when certain things don't work. So I would say like a not great practise that I have seen is having a product ops person or even agile functions that come in under product operations and be really religious about how all the teams should be functioning across the board. I think we've learned as an industry as a whole the hard way that that doesn't necessarily work all that well. There are a lot of great things about all of these practises, but trying to, you know, trying to waterboard people into making them do a specific thing, it just doesn't work that well, and we have so many really cool things that are happening in our companies globally now, and we have remote work all across the board. If you think about it, Scrum specifically was designed for localised teams. It wasn't really designed for remote teams. So there's a lot of really cool new things that people are trying now that I think are awesome, and you've got things like Shape Up that have come out that's not explicitly agile, but it's a very cool, interesting way of working. We've tried different variations of that as well, and that's worked out really nicely, and it's a great way to draw attention to your leadership on spending time doing bug fixes and spending time doing foundational work outside of feature development and giving space to like look at the data that's coming in from your customers using that new thing that you just put out. So I would say like bad practise is: don't marry yourself to a specific idea; don't try to control what every single dev team is doing; try to take a step back and think about how they can work together, and give them some tools to try; and make sure they have the communication lines that they will need, not more, less is more, just what they need in order to figure out what they need to solve for.

  - Love that. Anna, that's so useful, and I think great advice to folks that are listening, especially if you're just getting started in product operations. I know that you stepped right into that role within the company, and many other people will be part of product management teams that are scaling where product operations is needed. So I think that's really sage advice for them to consider as they start to take that role and grow product ops from 0 to 1, maybe. Tell us a little bit about the community elements of product operations at the moment 'cause I think what I've found through season 2 and speaking to people, is product ops people are very committed, they're very driven, they have a really strong sense of community. Talk to me a little bit about your experiences there.

  - Yeah, it's funny that you say that. So I am in a smaller company at this point. We're roughly 200 people. So I am now a team of one. I used to have a little bit more people, but I've sort of aggregated a guild-like function in product at this point. But it's mostly a team of influence. It's not a team of report. And that's okay, but what that means is that I am the only person in my company who is explicitly product operations. And I think that that's a relatively normal story. I think that a lot of people are in that space even if the company is a little bit bigger, definitely if the company is a little bit smaller. You've got the behemoths out there that have big teams, but for the most part you've got, you know, relatively isolated groups of product ops folks in their own companies, and what that means is that we want friends. It's nice to meet new people and hear about other people who have the same trials and tribulations in their own companies, and different ideas especially right now with AI and what it's doing to, especially our roles, which it's a really cool space to be in. There are so many things that are happening even faster now with that particular enablement, and there's also a lot of crap that's coming out too that we don't want any part of, and we need to be able to identify that and stop that from sort of dirtying up what we've built. And there's some people who have some really great ideas out there. So what I would say is, generally speaking, from a community perspective for product ops folks, we're a chatty bunch. At least that's what I've found so far. I've reached out to people, just cold calling essentially on LinkedIn, and just said, "Hey, looks like we're doing a similar job here. "Do you want to chat?" And it's been really gratifying. Most people will respond, and say, "Yeah, I want to connect. "What are you up to?" And I've spoken to people all over the globe at this point, and it's been really, really nice for me, and I would highly recommend others doing the same because you'll be amazed how many other people are out there doing these kinds of things. They have questions. I've had people help me. I've helped other folks in their own teams as well. And there's also communities that are starting to build up around this as well. So I know that "Talking Roadmaps" sort of has a little bit of that aspect going on. I have also been working with Ross Webb on his community with Top Prods, and we're focusing 100% on product operations folks. So it's just people coming in. It's a free community, and it's just people sort of in that mid to senior level who want to connect and learn what other people are doing and, you know, what's happening in the industry on a regular basis and how can they apply that to what they're doing in their current companies. And it's a great group of folks. So I would say reach out to people on LinkedIn or reach out to our community as well.

  - Yeah, fantastic. And so that's a really nice segue into maybe whose advice on product operations you listen to. Who gives you inspiration? Who has good resources out there that maybe, again, someone listening who's just getting into product operations, they're not too sure about who's great in the community, where have you learned and got your resources from?

  - Ah, it's such a good question, and it's a long-winded answer I have for you. First, I would say, is that there is a growing community of people who are talking about product operations, which is awesome. I wouldn't say that product operations is totally new, but it's relatively new in comparison to like most of the things that are relatively established in product management. So we're still sort of growing our podcasters, our books out there, and all of those resources. I would say that I, of course, listen to "Lenny's Podcast." That should be a given for anybody in product. Gerisha has actually come up with a product ops podcast on Spotify. I would recommend that one. It's very good. And then I would say Ross Webb also has a good one as well. He's parsing out some great sort of tidbits on product and product operations. So those are the podcasters that I generally listen to, but when it comes to like resources, I would recommend looking at the pillars that I mentioned before and then finding books within those pillars. I don't think that there are very many explicit resources out there that are like, "This is product operations, the lay of the land, "and this is what you should do." There's the one product operations book, which we all know and well, but then, after that, yeah, but then after that, what do you do? So, I would say, look at the pillars and then find a couple of books in those areas. One I would recommend, which might be a bit of surprise to folks, is "Lean Startup." So, "Lean Startup," you know, why am I picking a startup book when I'm in a scaled company, I'm talking about product operations. "Lean Startup" is awesome because it talks about product experimentation, it talks about product data, it talks about honing in your delivery model so that it can get things out to market faster, and mostly is really focusing in on, "How does my feature or my product perform in the market? "Did I do the smallest best iteration possible, "and am I learning something from that every time?" Those are the kind of loops that you're trying to build into your system regardless of how big your company is, and just the emphasis on the product data and then experimentation models is huge. It's a great learning for anyone doing product ops. So I would look at "Lean Startup," and I would also recommend, so we all love Marty Cagan, but his "Transformed" book explicitly talks about the product operating model. It's a really great foundation for people trying to understand, looking at how that works within the organisation as well. I find that I am talking to C-Suite personnel and VPs across the board and departments all the time when it comes to how product functions, so being able to understand how that operating model works, how it works within the business model, and how it comes all the way down into product management is huge. So I would highly recommend that book; it's great. And then the last one, I would say "Smart Brevity" is a good one. It's a little one. Great. So I just handed you all these really heavy books. You're probably tired of reading all the heavy books. "Smart Brevity" is brief. It is a book that my CRO actually recommended to me, and I've loved it. It is mostly around how you structure written and speech context so you get exactly what you need to say when you need to say it, and you have sort of further divulging points down below. What we find is that, in a remote world, where things are moving faster and faster with AI, where we're also trying to push things faster and faster when it comes to product, people don't have that much time to read context, the same when you lay something up, when you're trying to deliver an argument in a meeting or you're trying to get people to focus in on a collaboration that you're trying to get groups across departments, you need them to be able to focus on exactly the problem that you're trying to solve. So being able to understand how to tap into how people's minds work, how you can lay up, "This is what we're focusing on. "These are the points you need to know and nothing else." No distractions because people get distracted so fast. It really helps with your stakeholder communication, and that is a huge point when it comes to product operations.

  - Amazing. Thank you for sharing that. I think that's great, and that's one that I haven't heard myself. Love the fact that "Smart Brevity" is in itself a smart brief book, makes a lot of sense. I wonder if there's something about product operations that I should have asked you but didn't, and if you want to take a few moments for that as well. Is there anything I should have asked you?

  - For me, like the thing that has changed me the most, that has evolved me the most, in the past couple of years working in this sector is actually my involvement with the go-to market teams and how that plays into product, and I would say the more I talk with product operations folks, you can sort of start to see how different it is all across the world and how even America sort of focuses in on sort of a different faction of product operations than Europe does. It's really, really interesting, but, in all aspects, there's still that cross-functional play that I think sometimes is not talked about enough, and really the empathy that you need both from how go-to-market people have on their daily lives and how they have to talk to customers and how they need to deliver in their own way as well as what product does, it's a huge aspect of product operations that I think can get missed, not because you suddenly need to be an advocate for the go-to-market folks to product but because this is a centrally-located role. Yes, team 1 is product, but ultimately you're far more in the middle of everything than you ever were before just working on product, so you need to understand how the business works, and you need to understand how the commercial teams are functioning as well, the customer-facing teams are functioning as well. Those are systems in and of themselves that will impact product, and product impacts them. Being able to understand that, the pain that they go through, will help you be much stronger in the problems that you solve as a product operating model for the business.

  - You've shared some really great stories, some really great anecdotes. A lot has resonated with me and I'm sure a lot with our audience as well. How can people best get in contact with you, so have that coffee chat, to have that talk about product operations. What's the best way to reach you?

  - Yeah, so I'm on LinkedIn, Anna Prevo. Find me. Contact me. I love it. I will talk to anybody. Like, I would love to hear some outreach. And also if you want to hear more about the community and sort of have a space to touch base with more of the product ops folks that we've sort of collected into "Top Prods," feel free to reach out to me on that as well. Typically, we like to talk to people before we pull people into that community, so it's best to just find me on LinkedIn.

  - Well look, Anna, I think that wraps up today's episode. Thank you so much for joining us. Thank you for chatting through your experiences, some of your scars, some of your success stories within product operations. I think doing my role as a roadmap tooling implementer over the last 10 years or so, product operations has been probably one of the most closest roles to what I do now with a bias on tooling implementation but very much looking at process, looking at the road mapping within product as well, so I feel very happy to kind of feel like I'm part of this product operations community as well. But thank you so much for joining us, and to folks at home, if you've loved what Anna and I have said, please give us a like, consider subscribing, share something with a colleague that you think might benefit from hearing what Anna's said, and drop us a comment, and let us know what you found useful. Other than that, if you'd like to get in touch, feel free to reach out to us at talkingroadmaps.com. We always love to speak to practitioners, experts, authors, just to share those stories, and as we come to the end of product operations, which is our series 2 topic, series 3 is going to be in go-to-market which is some of the things that Anna's mentioned already. So if you'd like to hear from us there, drop us a line, tell us maybe who we should be speaking to. We'd love to hear from you. Otherwise, thank you so much for listening today, and, Anna, thank you so much for joining us.

  - Thank you.