Does Product Ops have an identity crisis? | Jenny Wanger
In Season 2 Episode 5 of Talking Roadmaps, Justin Woods sits down with Jenny Wanger to explore the question: “Does Product Ops have an identity crisis?” Jenny shares why product operations looks different everywhere, the risks of getting stuck as “tool admin,” and how a true product ops strategy can unlock company-wide impact. Real-world stories, practical frameworks, and advice on avoiding common anti-patterns make this a must-watch for modern product teams.
Jenny is an entrepreneur and product operations consultant who helps product teams trying to make dramatic changes and make it stick. She helps them through fractional VP of Product services, coaching, and her course, Product Operations and Infrastructure. Some past clients include the Linux Foundation, Cisco, CompTIA, and GE.
She brings over a decade of product management experience, having worked at and consulted for venture-backed startups, large enterprises, and nonprofits. She co-founded the pandemic-tech focused TCN Coalition and merged it with LF Public Health, as well as led the consumer product team at SpotHero, a top-ranking app that relieves the stress of finding a parking spot. Previous to that, she ran the developer experience team at Arity, a startup founded by Allstate.
When offline, Jenny is usually up in the mountains outside of her home in Colorado hiking and skiing with her family. She has an undergraduate degree from Harvard College and an MBA from MIT.
Here is an audio-only version if that’s your preferred medium - and you can access it through your favourite podcasting platform if you prefer (Apple, Spotify, Amazon).
In the next episode we are talking to Patrícia Cadete and Anabela Cesário, Product Leaders @ OutSystems. So watch out for Season 2 - Episode 6!
-
- Nobody else can sit on the executive team and talk about the product needs, right? That is something that only the product leader can do. The product leader needs to be deep in strategy. They need to be understanding what's going on with customers. Do they need to be the ones picking out a particular tool? Do they need to be the ones who are trying to fix this meeting? That's something that, like any and so then a lot of leaders say, "Yeah, I don't need to be doing that. I'm gonna delegate that down."
- And everybody to the Talking Roadmaps channel, the channel where we talk everything roadmaps. But in series 2, we are going to explore some other really important areas of product management and product in general. Product operations is a massively important thing, and it's something that's probably been as old as product management, but never really got a name and the focus that it deserves now. And my special guest today, Jenny, is gonna talk to us a lot more about product operations. Jenny, please introduce yourself.
- Oh, so much for having me. My name's Jenny Wanger. I am a product operations coach and consultant. And I partner with product leaders who are trying to build out a high performing product culture. So that's really where my passion lies.
- If you're enjoying the channel, subscribe, hit the bell icon and give us a like. We start with I guess a core question, Jenny, which is why do companies need product operations?
- And what alluding to your introduction, product operations has always existed because product management has always existed, right? Product operations is just the how you build your product. So as opposed to thinking about, you know, there's the strategy and there's the what we're building and then there's the how we're going to build it, and that's where product operations lives. So the answer is, every organisation that's ever had product management as a discipline also has product operations. It's just historically it's been considered part of the responsibilities of product leadership. What we're seeing now is the leadership going, "Oh my goodness, I'm totally overwhelmed. I need more time," right? Like, I can't do this and that and that, and that, and that. And one of the things that's easiest to pull out of the role and responsibilities of product leadership and give to a different discipline, to a different person is product operations. And so that's the pattern we're really seeing now is just a division of the role, a division of labour, to have some people who are focusing on the infrastructure that's going to be building out your product culture and other people focusing on the strategy and the what we're building.
- That makes sense. And I think as part of my job as a tooling implementer, I'm either working with product managers who are taking on the operations role of implementing rolling out tools, or I'm working directly with product operations teams. Again, it depends on the organisation, the scale of them. And as I start to work with companies and they are growing their tool adoption, they're starting to identify the need that actually sometimes that tool ownership as well as many other aspects of product operations deserve a full-time role or even a team. So it's really great to see that kind of evolving within the organisations. How do you see product tops set up across different organisations? In fact, is it a separate team or different reporting lines? What's been typical?
- And then typical, right? the vast majority of companies are still using the classical model of having product operations folded into the product management leadership and product manager's responsibilities, right? Where they're managing their own tools and just choosing on how, you know, thinking differently about that. We've to actually, you know, create the infrastructure versus the other work they're doing. And so it's that split responsibility. Well then there's the other, a lot of companies I'm seeing right now are sort of doing the product ops trial where they've brought on one person and said, "You're now product ops, good luck, go." And that one person then is sort of, you know, they don't have that team. And so these actually, I think, one of the most challenging setups to do because how does that one individual figure out what to do? They don't have, you know, they don't necessarily have colleagues in the same way, and they're having to make up the definition of the role as they go along. And then there are companies now that, you know, I'm seeing more and more of them that are actually building up full product operations teams as the company grows, right? The more product managers you have, the more complicated the operations get. And so having a team to support that can be a real high leverage investment for a company. But ultimately it's different strategies on how to get to the same goal of your high performing product team. And so that it's not necessarily, you know, that I would say every company should go with, you know, one path or another. It's much more about picking the right path for that particular thing in me and what they're trying to achieve.
- It makes sense. It completely depends if it's a small company versus a large company, how mature their product management operations is, how much change their product management function maybe needs to evolve to from a feature team through to an empowered team. I think it absolutely depends, but that role is important and is being done just in various ways and that is evolving. You mentioned around product operations, sitting within product management, have there ever been cases where product management has set adjacent to it and they've reported into different functions? How has that work within different companies? So what does that look like?
- Oh, that, so usually if product operations isn't reporting into product management, it's reporting into the COO. So it's on the operations side of the business, reporting companies will have, they'll call it S&O, a strategy and operations department. And so product ops will report in that way, success. That's another strategy that I've seen. It generally leads to a lot more cross-functional collaboration, right? Sales ops will also be in there, marketing ops, right? And so you've got all of the different, DevOps less often I think, into the COO because DevOps is actually a, you know, there's engineering ops, there's DevOps, there's SREs, and so it's sort of a little bit more complicated there. But the idea being that, and have different ops functions across the org, they're all trying to sort of smooth out the operations of the company and how people are collaborating. And so having them be all reporting on the same team and thinking about the same initiatives can sometimes be, you know, another strategy to take, one other model I've seen is actually tech ops, where you do put engineering design and product ops all together as one function times it's just the title is Tech Ops times the title. You know, you'll have sort of I've seen sort of a, it's like a trio, a product trio, but it's an ops trio that's, you know, there's huge variety across.
- That's really interesting. I mean, I haven't been close enough to product operations to kind of ask that question to an expert, but it makes sense to me because again, it depends on so much of the context of the organisation. You mentioned product operations, sitting, sometimes sitting under the COO. Is product ops helping the organisation? Is it just product management or is it much bigger than that?
- Really hard. I think the primary customer of product ops has to be product, right? But product doesn't work on its own in any way, shape or form. And product has a duty to serve the rest of the company, right? So as product is interfacing with the go to market teams, with engineering, with design. Ops needs to make sure that all of those lines of communication, all of those partnerships are working well. And so a great example is that product ops is often, I've actually seen quite a few people in product ops come in via customer support. And that's because a lot of times product ops is brought in because the product leader says, "Well, we've got all of this great data in customer support on how our product is functioning, and we're not doing a strong enough job of bringing that in to our own work. So can we bring in product ops and their initial function is just going to be to get that feedback loop closed." What are customers saying about our product? Can we make sure we're using that data? Can we then also reply to the customers and make sure that they know when we fixed their problem, right? Or that we can follow up for more research. And so that's a great example of where, you know, if product ops were just serving product management and they just tell customer support, now you've gotta do this and we expect that, and like it's gonna fall apart, right? So product ops needs to be serving the customer, you know, and customer support wants that too, right? So that two-way street and making sure product ops is thinking about the needs both of their primary user and then that secondary user is critical.
- Absolutely. Having been a senior customer success manager myself, I can absolutely relate to that. And ironically it was a road mapping tool that I was part of, the CSM team too. But yeah, it's keeping those things closer. I guess maybe even a wider question is, what are the key responsibilities of product operations? That's just one of them, but is is there an easy way for us to say there's four or five main responsibilities, or does that also depend?
- Four or five. So the way that I look at it is that product ops' primary responsibility is to help the product team move towards a desired product culture and to fix it. What the work of that actually entails is going to be huge variety across every company because this is a strategy question. It's, here's the culture we want and what are the things that are standing between us and that, and so then how do I as product ops fill that? Sometimes it might be that, yeah, we need a road mapping tool, right? Sometimes it might be we need to get better at synthesising customer feedback. It might just be like, we need to make sure that, you know, engineering doesn't spend an hour trying to figure out if these are the most updated design files or not. It could, right? Like there's, you know, the small things and the big things.
- And it feels like it needs to be quite a consultative role. If product operations starts to get involved in business as usual, then it's not a good thing. I understand it really needs to come in own improvements, but not be part of the process. Would you say that was accurate?
- I have seen product ops teams where they are embedded within an individual product team in order to help things move forward. I have seen this work, especially well, I would say in two different cases. So one is highly regulated, but so healthcare and finance and there, it's very helpful because those things, all of these boxes that you need to check in order to get through the regulation, right? You need to make sure that legal and compliance reviews have happened, that, you know, maybe you've run betas and you've proved this and you've got that going and a marketing review. Like there's just sort of all of this extra work that needs to be done such that the product manager cannot, there is just no way for them to accomplish it on their own here. So there, I've seen product ops used as an actual operations type role in a different sense, right? So as opposed to sort of the leveraged operation, you know, leveraged smoothing out the saying, but let's just like a, you know, we need more help getting stuff done. And then each of those operations people who are embedded across different teams are thinking also about how do we automate this away? How do we get this work? So they are still thinking at that level of how do we make this into high leverage? But at the same time, these teams just really need somebody who's able to help them get stuff done. So I have seen that, and that so highly regulated is one side of that. The other side where I've seen that be very helpful is on one of where there's a very high degree of real world to product operate, real world to digital world interaction. So food delivery is a prime example of this, where you have this huge operations side that's like literal, you know, I need to get your dinner from a restaurant into a driver's hands and then to your house, right? There's so many different things that can go wrong in the real world. And so the operations person is actually trying to preempt that. It's like, we know perhaps it's they're doing, you know, so as product changes happen, the product ops person is actually thinking about, okay, what are the implications for trust and safety with this? What are the operational implications, right? Like if we add this data and send it to the restaurant, are they going to get confused by it?
- Makes sense. There's a more when you expand on it like that to consider. What's the collaboration then between product ops and product management? Is there, can there be any frictional overlap? Because you've just described kind of sometimes product tops becomes embedded. Is it clear for them to be able to define clear roles and responsibilities?
- So there are definitely, there's a long and storied history of product managers who have heard that product ops is coming and gotten about it. I think that when the roles are defined correctly, there shouldn't be a lot of confusion, right? To actually when you have that product ops team thinking about in that enabling role, right? You've got the product managers should be thrilled that product ops has shown up because it's taking stuff off their plate. It's figuring out how to, you know, they're gonna make their jobs easier. Where the friction comes is when product ops becomes the process police in that side, right? And product managers go, Ugh, you know, here comes product ops and they're just going to make me fill out more forms and jump through more hoops and go to more meetings. That's the case then you're doing product ops wrong because there should always be value, a clear enough value to what you are doing and implementing that people actually want it to. And so that's one side of it. And then I think when you've got that embedded model, yeah, that's where I do see the danger of product ops can sometime, danger is probably too strong a word, but I see product ops sometimes becoming a shadow sort of a shadow second pm right? Because they're now starting to some companies, the product ops are looking at all the data that's coming in from the operational side of the business and they're starting to synthesise that data and say like, okay, well here's where a user need is, right? Or like, here's a, you know, and they're starting to pull together, you know, strategy and things. But I would actually then in those cases, look at it much more as like, great, you've got somebody else on your team helping you figure out a good product strategy and like thinking about a different side of the business that may be, right. Like you've got this very large mandate to handle and very complicated product, and they're there to help you as a product manager succeed. And so, you know, welcome the assistance, welcome the support. You know, I don't know many product managers who are like, "You know what I need, I need more work."
- That's so true. And that's why when you were talking about, you know, some of the ownership and things, some of the teams that I'm working with, especially when they don't have product operations and I'm showing product managers how to use this tool, how to train this tool, how to configure this tool. It can in large implementations, as you know, with any tool, start to become a full-time job and it starts to load them down. And so it's, I cringe a little bit when I'm sharing this with them. Obviously I'm trying to make their job easier, but I guess that might lead into a really good question next, I hope, which is how do you justify having product ops and where does that start?
- And comes back right to that idea of essentially how much work in progress can any individual person have going on, right? So as a product leader, adding to am worried about my, you know, the roadmap and the strategy, right? I am having to manage my peers across other departments and work with them and get, you know and that relationship building, I have my list of direct reports who I'm mentoring load and having to keep an eye on what all the releases are and know what's going on. And then, oh yeah, I've gotta also make sure that we've got the right tooling processes and in place so that my reports can all be successful. Like maybe the expectation is they can do it, right? Maybe they can, but juggling that many things in your brain, that many priorities, it's really hard for all of them to come out well. And so that's where we get these managers who are, right, they're firefighting and they're going over here and they're trying to fix that, and they're letting all of those things slide while that's going on. But because they let all those things slide, there's now a fire over here. And so lo and behold, if you can say, you know what, let's take one of these things off of your plate. We don't expect product leaders to also be working with product teams to build stuff, right? Even if they do, they're very talented at that, but do we expect them to also be handling the operational side of their departments and say, so it's really just costing, it's adding cognitive load. And the more that we can remove some of that from the leadership, the more that they're gonna be able to focus on the things that only they can do, right? Because guess what, nobody else can can sit on the executive team and talk about the product needs, right? That is something that only the product leader can do. The product leader needs to be deep in strategy. They need to be understanding what's going on with customers. Do they need to be the ones picking out a particular tool? Do they need to be the ones who are trying to fix this meeting? That's something that like any and so then a lot of leaders say, yeah, I don't need to be doing that. I'm gonna delegate that down. And so they say, hey, product man, and this is how I got started at product ops, right? Is that my CPO came to me and he was like, "We need a road mapping process that can actually allow us to have all of our, we we're trying to make allocation decisions for how many engineers to put across teams. And right now everybody's submitting a different roadmap and it's really hard for the executive team to understand that. And we can't compare things. I need you to fix this." And so he put this on my shoulders and that was my introduction to product ops and I loved it, right? Turns out I loved it and it was great, but it was also, I call it shadow product ops work, because guess what, when my performance review came around, there wasn't a, "Thanks so much for leading that road mapping initiative, that was really great." It was, "What's going on with your product? How did you deliver on all of on your user needs, on your KPIs?" And so again, it was one of these things where like I'd put in that work and I hadn't really gotten like full credit for it. So as a product manager, right, how am I supposed to prioritise the road mapping initiative if that's not something that I'm really gonna be getting that much credit for, right? And again, right here I am trying to work with my engineers and designers and talk to customers, and now you want me to also be doing this cross-functional thing with my peers. And again, right? Like it's adding that extra cognitive load, that extra work in progress.
- Especially if that doesn't necessarily translate to something strategic that then everybody's talking about. And that's the challenge I've found. It feels like it fits into the same sorts of things as technical debt and bug fixes and things like that. It's almost like this is essential work that we need to do, but because it doesn't align to strategy, it's missed off of your objectives or it's missed off of your end of year review, or it's missed off of us even recognising it as a business of the things that we've done. And so that's really hard to hear.
- Well, there, I'm gonna actually, so this is something I think that's actually like a massively misunderstood thing about product ops, right? Is when people say, "Oh, it doesn't connect to strategy." And so right. What I have here is, I have something called the product ops strategy stack, and it's built off of, Ravi Mehta built this, built out the product strategy stack for Reforge, and I took it and adapted it to product ops. But I think it's actually, if you don't think that product ops is part of achieving your strategy, then you're looking at product ops too simplistically, right? It's not processes and tools, product ops is actually a strategy enabler. So when I talk about the product ops strategy stack, right? It starts with the product culture you're trying to build, right? That's your vision, that's your mission. And mind you, right? Like all what I'm saying here is just simply, well, why don't we take a product mindset and apply it to product operations, right? That's what's going on here. And then the answer is that then the next question is, okay, and what's your product strategy? Because that's actually a critical piece to then deciding what your product ops strategy should be. Your product ops strategy shouldn't be just like, oh, well great product teams have this and so we should have it. It should be, what do we need as a company? And I'll share a story about this in a minute to illustrate it, right? So what's your product ops strategy and how does that help you achieve your product strategy? And your roadmap then comes out of that and you set your goals based essentially on the pieces of your roadmap, right? Did we actually solve the user problems, right? The company problems that we were trying to solve. And so if you are not looking at this in from a strategic standpoint, if you're not thinking about how is product ops actually moving the company strategy forward, then yeah, why would you have product ops? How could you justify that?
- That's such a great response and thank you for sharing that visual, but that was really powerful. So Jenny, please continue with that.
- Yeah, and so an example of what this actually looks like in action when product ops can be that strategy enabler is that I had somebody I was coaching and I'll call her Emma, and head of product came to her. She was running the product ops team and said, "I want to know, like, what's your vision? What's the future of product ops at this organisation?" And she had jumped into features. She was like, oh, well we could fix this intake form and we need to tweak that. And like all of this. And the product ops leader came back, or the product leader came back and was like, "No, but like, what's your strategy? Not the list of things you're going to do." Right? Very classic. You know, product manager jumps right into solutions. And so that was when she called me and she was like, "I need help doing this." And so we talked about it and I went to her and I walked her through the strategy stack, right? And that was what we did together. I said, "Okay, well what's the product strategy right now?" And she said, "Oh, well, here's what it is." Like we've got these three pillars and like these things going on. And I said, "Okay, and where in these pillars can you help? What problems are the teams facing where they're going to struggle to get this product strategy executed because they don't have the right infrastructure in place?" And one of the pieces of this strategy that was about customer sentiment, right? They were seeing sort of declining customer satisfaction scores and there was a sense of, their clients were sort of saying like, "Yeah, we don't know that you guys really have our best interests," right? Like, and they were trying to stop that and turn it the other way. And she said, "Oh, well, I could help with that because we have this, we've got one thing that's going this tool that customers can use to submit their feedback to us." And right now we're not doing a good job of closing the loop and taking that, right? Like, we're not using that data. We've got 3000. They actually had 3000 ideas submitted by customers and by customer success managers that had not been looked at. And she was like, "I could fix that." And I said, "Excellent." So what you are actually doing is you are creating the tool, right? You are putting in place the tooling needed to achieve this piece of your product strategy, right? To turn that customer satisfaction around, because that is a critical element right now of what they're trying to do. And you have the ability to do that. And you know, and it was this moment of connecting the dots that product ops is not just like checking in, it's not ticking things off a list, right? Product ops is achieving a particular strategy that you need in order to make sure your product strategy succeeds.
- I love that and just everything you're saying there and kind of relating to when I'm implementing tools, there are sometimes idea portals that are available and the product teams get really excited, but what ends up happening sometimes if the tool is only 20% of the problem, the rest of it is the processes and the behaviours around it. You can set up an idea portal or a feedback portal, but if you capture 3000 ideas or pieces of feedback and do nothing with it, you've actually created yourself more of a problem. And so I totally relate to that. So it's great to hear that, of that thinking and like you said, tying it back up to that product track. I suspect that was a light bulb moment.
- It really was. And I think that it got her product leader to trust her, right? Because it set, she was saying, "I see what you are most concerned about and I am most concerned about that too," right? And it wasn't her going off and being like, oh, bells and whistles and cool things here. And to your point about the tool being 20% of it, that's absolutely correct, right? Like they had configured this tool and it was beautiful and it had the right questions on it. And what they had forgotten to think about was in the product development lifecycle, where are the points where the product manager would ever log into this tool and look at what was in there and they hadn't actually built that out, right? And they hadn't actually thought about the processes. They hadn't actually thought about the workflows. How do product managers get alerted that they've got something to look at in the tool, right? You know, the final thing I'll say here is, is also of like, on these idea portals, right? One of the mistakes I've seen over and over again is the product ops person saying, "Oh, well I'll do the first pass and categorise everything and then that will assign it to the product manager so they know what to look at." And that's not scalable, right? That's one of these things where that traps the product ops person in doing a manual task that doesn't actually add that much leverage to the team, right? So it's much more, there's one of you and there's eight of them, so don't put it on your shoulders to be the one to do all of this work, right? Like, how do you make it so that they can figure it out so that it's in their workflows and they're actually taking lead on it, but you are making it easier for them to do so.
- Yeah. That's so good. And I think that sounds like that's probably a common mistake that people might make in product operations is to embed themselves into some form of BAU that's then taking extra time away from them, from being able to do the consultative improvements that they might be trying to do.
- Yeah, Christine calls it, automate yourself out of the job, right? That's really like the mindset for product operations. If you're always thinking about, okay, how do I make it so that this isn't my job anymore, so I don't have to be the one going in and tagging everything, right? So that's automated. How do I get out of the middle of it so that I can continue to, right? And every time you automate something in the organisation, that means that, you know, the work is less for everybody, right? So it's back to that high leverage, those high leverage activities that really add a lot of value.
- So good. So good. So let's talk a little bit about kind of the good and the bad of product operations. So what do you consider to be maybe a best product practise in product ops?
- The best practise in product ops is bringing that product mindset to it, right? That's to me, like the number one thing that I'm constantly saying over and over and over again is so one example of this is somebody recently asked me, they said, you know, "I'm trying to fix engagement at this meeting with, you know, it's a cross-functional meeting where we're talking about what's coming up for the company and engagement's just really low, so I'm trying to fix it." And I said, "Well, why do you need to fix engagement?" She said, "Well, people aren't coming and doing the work ahead of time." I'm like, "And why does that matter?" Right? And so like digging, like asking those whys, right? Like why is this a problem, going through all of those things. And you know, and then she was like, "Oh, well maybe I could do this." Or like, right, like starting to like ideate, right? And I was like, wait a second, "What did the meeting attendees say?" And I'm like, have you asked anybody why they're showing up and not engaging? Are they getting value from this meeting? Like, are they just showing up and like, oh geez, this is the product meeting again. Like, but I gotta show and right, like what's their attitude? What do they want to get out of it? And you know, and it was sort of the again, right, that light bulb moment of, oh yeah, like these are my users, I should go and talk to them, right? I should interview them, figure out what their needs are and then create a solution, right? I can redesign this meeting to actually fit their needs. And if I can do that, then yes, the engagement will follow because you have created something of value, right? We sometimes forget that with our coworkers since they're rather compelled to show up to stuff, right? Like with customers, they will churn if they don't like your product. Your coworkers don't have the luxury of churning, so they might hate your product, but they're gonna show up and they're just gonna grumble behind your back.
- So yeah, I'm laughing because agreeing with you 'cause it's so true. It's so relatable to some of the things that I've seen. So that was brilliant. I guess do you have a pet hate to see with product ops or maybe an anti-pattern that you can think of?
- The anti-pattern is product ops as tool manager, right? Where I'm sure you've seen this a tonne. Somebody comes to you and they're like, "We need a road mapping tool." And you're like, "Okay, why?" And they're like, "'Cause we need a road roadmapping tool," right? And then they say, "And this person's gonna be in charge," and right? And so now that person, that poor product ops person is now they are the administrator of the road mapping tool and Jira and you know, list out five different other things and that's the entirety of their systems administrator, right? And is that really adding much, you've shoved them back into the IT box and are they adding that much value if they're pretty much just managing configurations of workflows? Like not back to like where is the product mindset in that you have forced them into a position where they, you know, that like they have to really work in order to, you know, if slap their wrist every time, they say, "Well, but what about the workflows around this and what about this and that?" And you say, "Your job is the tool administrator," like that's a crappy job.
- Yes. Handcuff them from what product ops is about, right? It's going back to system admin and you're just looking after users and custom fields.
- That's not adding value to the company and that's not adding value to their career. So I would say that's one of the most concerning anti-patterns I see.
- Yeah, that makes absolute sense. Let's bring it back to a little bit about roadmap giving, 'cause we've talked about that as well previously. But what's product operations involvement in road mapping?
- Yeah, so I've seen again, right, it runs the gamut, in some organisations, product ops actually the one who is facilitating road mapping from the beginning to the end. So they are, it's planning season, let's go. And they're hosting the meetings and actually sitting down with product managers to make sure that they've got their roadmaps and chasing everybody and working through it and doing the whole shebang. And in other companies, they have nothing to do with it whatsoever. And that's right. Road mapping remains fully within the, it's one of the product operations tasks that remains fully within product leadership. So it really, there's a full range to it and I think it comes back again to what is your strategy, you know, what do you need? You know, what is the thing that's keeping you from having the product culture you need? And sometimes road mapping is part of that and sometimes it isn't.
- Yeah, it is. And I think I know the answer to this question, but I'm gonna ask you anyway, which is, do you need a roadmap for your product operations function? I think we've seen this already, but I'm gonna ask you the question.
- And this is another one of those mistakes I see product operations do is they're not thinking about, their roadmap is maybe just a list of like, well we're gonna fix this tool and then we're gonna go look at that meeting and we're gonna like it's, I call it the whack-a-mole approach. And this is something, this is actually usually that comes from product leadership because one of the things that I've seen, where product operations comes from. Product leadership says, "Oh, I'm overwhelmed. I've got too many things to do. And then there's all of this product ops stuff. So I'll bring in a product ops manager and I'll give them these things." And so the product option manager comes and the leader says, "Hooray," and I had somebody in one of my courses who is in this position and told me essentially this story, right? But I've heard it over and over again. And his manager said to him, "I'm so glad you're here, here's the list of everything I want to get done." And it was like a year and a half worth of work. I mean, it was just a tremendous list of all of the ideas that this leader had ever had. And so he's that product ops single manager, right? So he doesn't have peers and his boss is saying, "Here's the list of things I want you to do." And so he is like, "Okay, I'll start doing them." And about six months in he's getting through the list and he's like, "Okay, I'm doing well." And it sort of comes up to like, the managers are like, "Okay, so what are your KPIs anyway?" And he's like, "I don't know, I got these things done on the list," And the manager wasn't pushing back, but he was like, "It felt really unsatisfying 'cause I didn't have a good answer." And so he actually, then he, you know, and this was about when he was in my course, right? And so, and he was, you know, we were talking about exactly this and he put a pause on it. He said, "I actually, I'm going to go back and I'm gonna come up with my strategy and have my roadmap actually be, you know, what are the things that could move this strategy forward that's gonna support the product strategy?" And he went back and did that reset and went to his boss and he was like, ""So I know you had this whole list of things you wanted me to do, but I'm not going to do them 'cause they're not gonna help." And he was terrified that his boss is gonna blow up. I hired you to do these things and how dare you. And believe it or not, that didn't happen, right? His boss was pretty thrilled. Like, oh, this makes sense, right? Like, I see what you're thinking, I see where you're going. And so, yeah an ops strategy I think is critical. And the other thing I'll add to that is one of my biggest recommendations to product ops people is to put their roadmap in the same format and use the same systems and tools and whatever that the product managers are using. Don't be a special snowflake actually, you know, and it's a form of dog fooding, right? 'Cause product ops is usually in charge of the roadmap system. And so if you are struggling to build your roadmap, you know, if you're going through the same process they're going through and you're like, this is terrible, guess whose job it is to fix it? It's your job. And so I think it's really a lot of times product ops is like, oh, well, but I'm not product, like, I'm not gonna put my roadmap on their board because that's gonna be confusing. And the answer is no, you absolutely like, use the same systems because you need to make sure that you have empathy with your users. And one of the easiest ways to do that is to go through the same processes and steps and rules and everything that they're doing. So have a roadmap, right? If product's expected to have a strategy document, have a strategy document, whatever tool they're using for that, use it, whatever format they're using, like yeah, you might need to fund, like there might not be a clear ROI section, right? There might be some things that don't perfectly correspond because your product is different, but use all of the same tools, use all of the same systems they're using, have the same things in place 'cause you know, you have that product mindset and show it.
- Love that and I feel a passion coming through and I can feel it myself because it just absolutely makes sense to me. So it's such a great response. Jenny, you've got a wealth of knowledge. I'm curious, whose advice on product tops do you listen to? Do you listen to or are there any resources that you could recommend people listening to go and check out?
- The first resource I'll recommend is, I do have a newsletter and so I write about all of this stuff hopefully with the same passion that I have here. And you can subscribe to that at jennywanger.com. And so that's one thing that I do recommend people who are looking for product ops advice and wisdom. And then there's a couple of communities that I participate in that are really helpful in terms of their ability to just, the wealth of knowledge in them. So there's the product led alliance and product ops HQ, which are both really excellent Slack communities and active. And I'm involved with both of them. And then, yeah, I'd say there's a lot of fantastic product ops people out there who are sharing their thoughts. Chris Compston, Chris Butler, not all of them are named Chris. Mewong is fantastic. I mean there's a long list of great product ops people and I know I'm leaving a whole bunch out here.
- I guess I'd like to kind of wrap things up with maybe just a couple of questions, which is if you had to distil your philosophy of product operations into a couple of sentences, how would you describe it?
- Yeah, so this is funny because I actually recently wrote an article called "The Product Ops Identity Crisis" because I was sitting in a meetup and there was sort of this, well are, you know, similar to your questions, right? Like, does everybody do product ops the same? Should we do product ops the same? And so we went around the room and everybody said what their scope was for product ops and it was everything from like, I handle nothing but launch readiness, right? It's mostly just me making sure that the go-to-market teams know what we're building and know when it's coming. Other people who were like, yeah, I do everything from, you know, ideation and roadmapping and customer feedback to launch readiness to this, to that. Like, it was all over the place. And I was sitting there and I was thinking like, okay, so do we know what product ops is? Is that a problem? And so I actually, you know, I ended up sort of thinking through like when people ask me what is product ops? How do I answer? And right, even from this conversation, you can hear how many different definitions of product ops I used throughout the conversation. And so I actually came up with four definitions that I find I use the most frequently or hear the most frequently. And I think about, right? So product managing, the product management experience, right? Which we've talked a lot about that, right? Bringing that product mindset to the work you're doing and making sure that you're empowering and enabling the product managers. Denise Tillis and Melissa Perry in their books say it's helping product scale well, right? So how do you make sure the product function is growing and scaling successfully? I talked about product strategy enablement, right? That you've got a product strategy and it's your job to make sure that you're getting to the right strat, you know, that you are actually putting in place the right infrastructure to achieve that product strategy. And then I also talk a tonne about designing product culture, right? So making sure that you have a product culture that you think is going to make your company most successful and that you as product ops are actually the ones who are designing your way there, that are making that product culture a reality. And so there are a whole bunch of definitions that are also not on this list. And there's nothing wrong with other definitions as well, but the thing that I actually like about having multiple definitions is that you can sort of take whichever one you need at the moment and use that to guide your work. And then, right, this sort of gives you the full three dimensional view of what product operations is or could be at an organisation as opposed to saying like, product ops is this one thing, having multiple definitions, you know, I called it an identity crisis. I don't think it's an, that's probably more clickbaity than it needs to be or maybe that it's good that we have an identity crisis because if we knew exactly what we were and we could explain it in one sentence or in one simple way, then it would be really uninspiring, right? If I could explain product management in one sentence, it wouldn't be a very fun role for me. So I appreciate that. Product ops as well is hard to define.
- Yeah, for sure and it depends on the context and everything that the company needs it to be. Jenny, you've really helped expand my mind on the topic and I've loved speaking with you. I think a lot of what you've said and shown will have resonated with our audience. If they wanna find out more, how can they best get in touch with you?
- Yeah, so you know, I mentioned my website before, jennywanger.com, which is where you can find my writing and there's a contact form. And I would love to hear from listeners, our viewers and what you thought of this. I'm also on LinkedIn, which is a great way to find me. If you do wanna work together, right? There are several different things I do. So I do one-on-one coaching and advising. Oftentimes that's with product leaders who don't have product ops and are trying to figure out how to think about it in a structured way. How to develop a product ops strategy and actually move their product operations forward. Whether or not they have that team, but they want to level things up and invest in that in their own way. Or sometimes with product operations leaders who need that support on building out that strategy. I run product operations assessments so I can come in and say, here's where you're at on various levels. And then I teach courses on product ops and business case development and those, if you wanna learn more about those, I'll send the links over, but I also talk about them both on my newsletter and LinkedIn.
- All that leads me to say is thank you so much for speaking with me today. It's been an absolute pleasure and it just leads me to say thank you so much for coming on and talking product operations with me. It's been a real pleasure.
- Thank you. I'm so glad that you're doing the work to try and move product ops and move product management forward. 'Cause you know, every team deserves to operate at their full potential.
- Oh, do you know what? That might even be the title of this episode. Thank you, Jenny.
- Take care.