How to hire a great product operations team? | Jessica Soroky

In episode 13, Jessica Soroky shares how to build and scale an effective product operations team. She explains when to hire product ops, the key pillars (tools, data, enablement, process), and why combining program management with product ops creates huge value. Jessica also dives into hiring best practices, common mistakes, and how product ops drives better go-to-market execution and roadmapping. Packed with practical advice, this conversation highlights how product ops can transform outcomes across stakeholders.

An experienced operations leader with 12+ years driving transformation, optimizing product operations, and leading global teams. At Pendo, Jessica led a major product lifecycle overhaul, saving $250K annually. She partners closely with executives to drive strategic change, with expertise across SaaS, Finance, and Insurance. Passionate about Agile, continuous improvement, and mentoring high-performing teams.

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 Hugo Froes, Head of Product Operations @ OLX. So watch out for Season 2 - Episode 14!

• Transcript

  - Do not post some nonsense looking for five plus years of product ops experience. They're lying, you're lying. Don't. What I would say is try to hyper focus on what are those pillars that you really need to move the needle on within your organisation and then look for folks that have critical skills to those pillars. So obviously, if analytics or data is something, finding somebody that has experience in those spaces is critical. But at the end of the day, I think all product ops people, no matter what their specialty is, need to have a proven experience working in-

  - Welcome to "Talking Roadmaps" Season 2 where we are talking about product operations. Today I'm joined by Jessica Soroky from Pendo. Jessica, you can tell the people more about yourself, so introduce yourself for us.

  - Hey everybody, I'm super excited to be here. I am an operations leader who has had a very long career in all things Agile, software development lifecycle, product development lifecycle, and have found myself into this wonderful, weird world of product operations in the last couple of years.

  - If you're enjoying the channel, subscribe, hit the bell, and give us a like. I'm sure we're going to have a great conversation. I mean, it's great to have another guest from Pendo because we had Hannah Chaplin on the first season talking about roadmaps. I mean, she's from my local market. Like I'm just down the road from Sheffield where you guys have an office and I knew Hannah and Dan from Receptive before you folks acquired. So I mean, let's get straight into it. Why do companies need product ops?

  - Oh man, I'm going to steal a quote that I heard, actually just yesterday that I really, really liked. If you're a smaller product organisation and maybe you've got a handful of product managers and you're thinking about adding one more, does it make sense to introduce product operations at that point? Probably not. But if you've got a dozen or more product managers and you have one headcount open or you have one, or two headcount open, you can take or make so much more value and optimise your existing product managers by hiring one or two product operations humans instead of just thinking, "Oh, I'll just add one or two more product managers." You're going to get more output for sure, but you're going to get tenfold much more if you invest in product operations. It's all about how do you make the PMs frankly, their job, their objectives, easier to achieve. Common misconception, it is not to do it for them. It is to make the systems and the processes that they work in easier, better, more streamlined so that they can be the great product thinkers and get amazing products out the door.

  - Love it. And as you know, just before we started recording, I mentioned that I've just started a new job and I was literally reaching out to a product ops leader that I found in another division of the business only today to say, "Can we have a chat? 'Cause we don't have it in our part. And I wanna see how you've got it set up over there to see if there's something we can benefit from over in our part of the business." Which is really interesting to see that one part of the organisation has embraced it and it's a big 160,000 person company. And so some parts have got it and some haven't. And some are very product-oriented and some are less, which is interesting to see. I remember having similar discussions around UX in the past as well. When I had headcount for product managers as a former head of product, there's days where I hired a product manager and I realised afterwards I probably should have hired a designer because it would have just filled the gap that actually the product managers were covering, but they weren't the world's best at.

  - Right, no, absolutely. I have this desire, this dream that product operations will be so synonymous with product organisations, similar to revenue organisations don't function without rev ops.

  - It's interesting because I know as the product leader, I used to own those in the previous life. So it was kind of a part-time job and one of my team was doing part-time some of the other bits. And I found myself landing in this organisation and looking saying, we're missing a tool or two. We haven't got the stack. And I'm onboarding, and how do I get access to all the right systems? And I'm actually having to go around all the product people and some of the engineers and say, "What systems do you use?" Instead of being someone there who actually can say, right, this is what you need as a product person. Joining the organisation, you need to access here, here, and here. These tools, this is how we use them. So I'm really reflecting on my unique experience of literally this week of there's a gap and I think product ops would help that, but I'm sure it's not uniform out there. How is product ops different from one organisation to another?

  - Love all my product ops people out there, but there's definitely, I think, some lots of opinions, lots of different variations. I think one of the most complex things about product operations as an emerging industry is that it's completely dependent on the state of your organisation and the maturity of your product organisation. So examples being, if your organisation was historically a physical product company, that is now in the last couple of years starting to get into digital products, your maturity as an organisation is probably not the same as like a tech startup out of Silicon Valley who has always been in the digital space from the minute that they were created. And so I think it's really natural to see in those two examples, your product operations implementation look significantly different. So I think some of the most simplistic differences are product operations being the body that educates and matures your PMs and their skill set. I personally believe that that fits in that first example that I was giving a company that is a little bit less mature on their digital product experience, matrix, roadmap, whatever you want to call it. More mature product organisations, I think it's not as necessary for product operations to be like that skill set builder. Ideally, those companies are hiring world-class PMs. They're hiring world-class product leaders. And so it feels a little bit less fitting in those situations. Like Pendo, for instance, we pride ourselves in hiring world-class PMs. If me and my team went and said, "Hey, I need to educate Pendo's PMs on how to be a PM," that would be a problem for us internally. So we don't take on that taste of it or that version of it. So I think that's one. The other, if you're not doing that, I think it's really heavily rooted in how do we bring data into every part of the product development lifecycle, how does product operations pick the right product data tool? How do they then learn to be the masters of that tool? How do they enable their PMs to use the analytics or to use other features like a Pendo has guides and other customer-facing features? That's to me, the two big differences. Either you're really, really heavy in the data and how to get your PDLC using the data or you're much more heavier in the, I'm still helping my PMs learn how to be PMs. And a piece of that might be analytics, but it's not as deep.

  - Yeah, it's interesting 'cause I find myself in one of those physical products going into digital and they are hiring some good people. I mean, I'm biassed, they're hiring me, but I know that one of the goals that the leader is hiring me is that I come as a trainer and a coach and I'm gonna help upskill some of the rest of the product people. So maybe I'm doing some of that product ops work. Again, in a part-time job.

  - I think it's more reasonable. I mean, look, do I think that there are product ops people out there that can educate and train PMs? Sure, absolutely. But do I think that in most corporate environments, a product manager is going to respond better to a CPO, a product leader title, somebody like that, giving them tips and advice 100%?

  - Well, you know what? I'm coming in as a super IC. I'm embracing that recent narrative because I do like the business side of things. And I feel like it's going to be interesting to go back to doing it for a while. But yeah, I like those kind of polar opposites. Now, what's the reporting line look like though? Because does that look different in those different variations? Does it look different in general?

  - In my experience, the vast majority of product operations leaders that have a product operations team, brought up to the directly to the CPO. I've seen very few variations on that. If it is a single human or they don't have a full product operations team and they just have an individual or they have even an individual without the title, but is starting to do some of that product stuff, there's all kinds of reporting structures, heads of products, SVPs, VPs. But typically, that only happens in my experience when there is not that prod ops team. And it's just that one human trying to figure out how to make it work in that company.

  - So what makes a good product ops person in those different models? What was the person look like? What's the profile of someone?

  - Yeah, so at Pendo we do prod ops slightly differently for a couple of reasons. I promise I'm gonna answer this question, but I feel like I need some background context. Our product operations team is actually made up of two different functions, product operations managers, and then programme managers. Our programme managers run our product delivery, essentially. So like think about it like a super souped up scrum master, but they own the entire PDLC from the very beginning of an idea through its go-to-market launch. So that's obviously a very specific skillset, right? You're looking for project managers, programme managers, Agilis, those types of humans that are detail-oriented. They can make a plan, follow a plan, coordinate the cats, right? On the product man or product operation side of it, because of the tool that build, because since our PMs literally build their product analytics tool, we don't have to go as deep into some of the serving up, if I can say it that way, to our PMs. So we find ourselves with a little bit of unique capacity where we're really hyper-focusing on communicating up and out to our broader organisation, to our executives, cross-product views. So our individual PMs are really good at looking at their data and their user experience and their analytics from what they build. But we're the only group that steps back and looks at the entire product suite and goes, hey, okay, aggregate, like this is what we're finding. Here's what results we're getting, where we should invest, not invest. So because of that, our world changes quite frequently day to day in what we're picking up, what projects. So I think a product operations person needs to have familiarity with how products are built, software products, digital products are built. Doesn't mean that you have to have been a PM directly. You could come from a technical background, you could come from an Agile background, but you need to be familiar with how software teams build digital products. You need to be resilient and not afraid to be bold and to frankly, teach executive leadership new concepts and a whole new role and a new value set. And you have to be willing to adjust and not be so stuck on, but I just got this project and I wanna finish this one thing. You gotta be pretty adaptable and be like, okay, it's now Tuesday, the wind is going this way, I'm going to go with it. Oh, now 10 hours later, it's going to go in a different direction. I'm going to go with that, which can be really frustrating since I get to own both of these houses. They're very different personalities. My programme managers would have heart attacks if I changed their projects as much as I change product ops' projects. So I think there is some interesting similarities, but there's also some really distinct differences in how they execute their day-to-day.

  - I mean, that sounds like the product ops people would be more akin to product managers again as well, because I mean, I always loved the fact that no two days were the same. That's what makes the role interesting, because there's always a new challenge. If it was steady state, same thing every day, then frankly, I'd be bored.

  - Yeah, I think the other thing too that I've learned probably in the last year or so on product ops is the criticality of them also having an understanding of your customer, which on the other side of that, like the programme managers that I run, it's added bonus if they understand what we build and our customers, but it's not totally required. They can execute any project I give them. Whereas product ops become incredibly valuable the more they understand what problems our product is trying to solve, understand the problems our customers have, and have a more of that empathy built up, they can execute their jobs a lot more effectively.

  - It's interesting that kind of double house, 'cause I know it's not that common to have those two functions together. But I do know that one of my coaches, a CPTO that I've worked with for the last year and a half, when his product leader left about 18 months, about a year ago, maybe, he debated where to put prod ops in his organisation. He actually united it with the Agile delivery lead team, very much through conversation with myself, because one, it was the right leader to put it under. Maybe that's true for yourself for because of those two houses, but also there was just a logical connection. These folks were making the machine run well. these people were actually executing within the machine and so the two kind of worked hand in hand quite nicely. I think we, I can't remember if we called it product execution or product enablement, or something like that. It was like, we needed a title of the department became quite loaded within some of the teams. Yeah, it's like there were product managers saying, oh, we can't put them next with delivery.

  - I'm a huge proponent of the marriage of putting these two things incredibly close together, whether it's under one leader. I actually was kind of poking on LinkedIn and trying to get people to debate with me about just this recently. And I do agree that I think it is incredibly important to have the right leader that can run both of those teams. But if you do have that person, combined them, you get so much benefit out of those two things, living side by side. The amount of crossover that my two teams help each other with is immeasurable. Like it is incredibly cool to see them learn from each other, play into each other, have their like establish their own boundaries. My programme managers get to improve day-to-day operations of their programmes, of their teams. We've got certain boundaries in place that they can't really cross over. And then as soon as we start to see groundswell where it's like, hey, these two programmes have tried this new thing and it's working really effectively for them. Then we pull in prod ops who again, can see across the entire product and now it becomes their job to do widespread change management, widespread process enablement and say, okay, how do we make this work for the entire product versus just your two programmes? And the lessons, it's almost like we created a kind of weirdly organic experimentation programme where like they get to experiment in their tiny programmes. Once the experiment goes well enough, then we get to bubble it up, which in my old Agile days, we never really had, like not that we couldn't run experiments, but it was never that clean and it was never that simple. And we definitely didn't have roles that could step back and go, how do we enable this across an entire engineering department or whatever, even if you had Agile coaches or consultants in place, that was still a really hard thing to do. So this marrying has been incredible. Plus the other benefit we get is that when prod ops is trying to communicate out across the product, something about analytics or a customer experience that we're trying to create, or got a guide path that we've established. They have a really simple, we have a weekly team meeting with both of them and they get to communicate to the entire product in one session every week, and it just streamlines and moves stuff so much faster. I'm clearly very passionate about this space. I know people like to argue with me about how it's not the right marrying, but totally disagree.

  - So I'm well known for replying to most questions with, "It depends." Now I know it's product manager's favourite answer, but it so does, like everything is contextual. Like we said, right leader, right organisation, right challenges in front of you. But I love that idea of, essentially, those programme managers, you've got a default pool of pilot teams to run to try things out. And I mean, if you read anything by Marty or anyone like that, like, all that change recommends, go through a pilot team, try it out, learn there, then roll it out wider. I'm definitely a big fan of that sort of approach. So that close collaboration is going to just make that easier. And the reality is we know that no organisation stands still. The processes of today are not going to suit you for next week or next year. And so having that view of continuous improvement, continuously getting better and the mechanism that organically allows that to happen, sounds powerful to me. It is very powerful. And I've learned firsthand that it's also really hard to learn to let go of things that you were married to in the past. Like I built up Pendo's Agile practise and I had moved into a slightly different role when we did this big transformation. But to be truly objective and look at what wasn't working in the past that led us to this transformation, it's a hard thing to do. Right now, we have some of our scrum teams actually actively starting some interesting debates about some new experiments that they want to run, and it's a daily practise for me to go, don't get attached. Don't get attached to the old, like be open-minded, like this change could be the right change for right now kind of thing. But it is a hard thing to practise.

  - Yeah, I mean, one of the product leaders that I met in Belfast when I was speaking at a product tank about a month ago, he described his organisation as working in a post-Agile way. And I found the phrase quite amusing, but essentially, they were using a fusion of shape up, so Basecamp's 37 signals approach with a bunch of Torres de Torres style kind of continuous discovery activities. And their teams were lean and mean and delivering kick-ass value, it's like, I can't argue with it, that's working for you. So I'm going to bring myself back to what I, you know, just a little bit of a thread of, so we've talked about it kind of making the organisation better, but let's get concrete. Who do we really help in the organisation as product ops people? So I'm going to speak from Pendo's point of view, right? 'Cause that's my experience. We are engaging with quite a bit of our enterprise-level customers to help them with their product operations journeys. I hate that phrase, but I don't know what else to call it. So from the experiences that I have had, I think the number one place that you are helping is essentially any stakeholder that's involved in your go-to-market. That was the biggest benefit that we have seen is our go-to-market process. For a pretty mature product organisation was really weak. It had very big holes. My favourite quote was I was talking to a customer success manager at one point in this big assessment and they were like getting really sarcastic and they're like, "Yeah, you know, I really love when I find out that we've built something new when I get a call from a customer telling me that it's already broken and I didn't even know it existed." And I was like, "Oh, okay. So go-to-market maybe isn't as effective as we thought it was if we're not even informing, let alone enabling and supporting our internal teams to be able to support our customers with it." So I think number one, it is whoever, what to me is a lot of people benefit from the go-to-market process being a, to use your phrase, lean, mean, kick-ass machine. That's number one. I think for my experiences, CPO comes next. I think enabling them and empowering them with a tonne of data at their fingertips to make incredibly educated decisions about where they're spending money, how they're spending their money. I mean, if you think about it, these folks have tens of millions of dollars in budgets that they are responsible for allocating every single year. And if they can have more and more information about where it's going, how it's going, how customers are using the thing that they just spent tens of millions of dollars on, why would they not want that? So I go to market machine first, CPO second, and then hot take, PM's third. I think we do help PMs. I think we make their jobs easier and better and more efficient, but for us, we've had to solve for the other two first.

  - I love it. And that might be a hot take, that might be a nice spicy take for people out there.

  - Maybe not. Maybe I am just late to the boat and everyone already knows this.

  - Yeah, I mean, I can see that. I mean, if I play devil's advocate, helping the PMs ultimately should be helping the CPO, for example.

  - I mean, chicken or egg for any of them, right? Even helping go-to-market helps the PM in the end.

  - Yeah, so it's more about where do we optimise for first.

  - Right, so you can do your own plan. It depends. It depends on where your problems are. We optimise for where our biggest problems were.

  - I mean, two of the first things I'm looking at in the new role is go-to-market or a product that's pretty much been developed before I've gone on board, that's a new product. And I'm hunting around saying, "Well, where's the data for me to start making decisions?" So you just hit two of my key, kind of my things I'm hunting for at the moment. We might have already started to enter this, but what are the key responsibilities of product ops?

  - Yeah, so for us, we've got four major pillars, which are not totally different than, I guess, the closest thing you could say to like what the industry has described as the pillars. So tool administration and management maintenance of any of your product department-wide tooling. So we have an internal admin who essentially covers all of our really critical tools, including Pendo and then all things data. So again, for us, like I was mentioning, I have seen lots of product ops organisations split data into two buckets, internal use, like internal data, meaning what are your employees doing? What are your team members doing versus customer data? They're obviously wildly different use cases and things that you would need to do. For us, we combine them into one pillar because again, we need our PMs using our data on a pretty sophisticated level. So our lift when it comes to our data pillar is not as significant as some other product operations teams that don't have that, but that creates a natural additional pillar that we call How We Pendo. So we have a really big lift and responsibility around ensuring that all all of our internal teams, not only understand what we've just built, but are using it. And that we are the pillars of data cleanliness, naming conventions, governance. If we're not using our own tools to the best of its ability, then there's a problem. So that falls on our product operations team to make sure that anytime we do a new rollout, all product and engineering teams know how they should be consuming their own tool and where they should be engaging with it and how. That's our third pillar. And then we have our fourth pillar, which is wide-scale process optimization. So I was mentioning earlier that we let our teams and our programmes kind of experiment within their sandboxes. Anytime that that experiment goes higher, that becomes our fourth pillar where product ops takes over and does whole product process rollout.

  - And I noticed there the obvious omission that you, because you talked about them not doing the work for the PMs. So they're not the assistants to the PM, because I have come across that. Personally, I think it's an anti-pattern, but I've seen that in a few product ops teams.

  - No, but I will tell you that I think that just a sign of where that product operations team is in their evolution. Our product operations team prior to me taking over, I would argue that that was a portion of their role when they were new too. I think it's totally reasonable when a team is trying to find its footing, especially in an emerging industry that hasn't exactly fully established itself either. And there's not this great guidebook yet. I know that it's starting to form and we're getting great resources like Melissa's book and a few others that are becoming these guiding pillars, but there still isn't a tonne. So it's not crazy to think that a new team is going to start by how do I just help solve whatever problems are in front of me? And that might mean, hey, these individual PMs are having these very specific problems. Let me go pick these up, these little tasks. Our product ops team started as a group of very randomised tasks to there for a while.

  - I mean, I know, for example, Ali in your team, I know she comes from a customer success background, for example, and so I can see that leaning into enablement. There's a chunk of working with product managers here and historically, product managers might have done some of this work. It might have sat there as that part-time thing. So how do PMs and product ops managers collaborate? And is there any friction there?

  - We haven't personally experienced any friction recently. When our product operations team was first getting its footing, there definitely was friction, not only with just product managers, but with a couple of different roles that all played in that product development lifecycle because it was so unclear, right? Nobody really knew how to engage with them, where to engage with them, what value they brought to the table. So naturally, you've got territories stamp putting walls up and going, "No, get out of my space. This is my team." But I think as we've gotten, especially in the last couple of years, way more clear on what it is that the product operations team does, how to utilise them, what value that they bring. We've really minimised, if not completely eliminated any friction amongst the roles. If anything, I think we've gotten a lot of gratitude from our product managers of the efficiencies that we've created and of allowing them essentially the space and time to focus on the things that they like way more, which is creative thought and playing in the data to figure out what's the next big idea, how do they solve the problem for the customer, I think it's really just been a positive experience for, I'm going to say most involved in the last couple of years. Not saying it's perfect, but pretty good.

  - How do you justify your existence as product ops? We're going to make a justification, maybe even a business case for this new function. How do we do that?

  - The really honest answer is that it'd be crazy if Pendo didn't have product ops. So I get to sit in a slightly more comfortable seat than other teams, but that is a little bit jokey. It is a little bit jokey. It would be nuts if we as a company did not have product operations, but we still have to justify the size of our team, the investment in our team, just like any other product operations team would have to justify it. And I think the biggest thing that we are proving value in is being able to measure the improvements of any process that we optimise or change, or impact. For instance, a recent project that we're getting some really good results on is automating a lot of our beta management. So product managers love to run a beta. It's an incredible, incredible tool that we need to have to experiment and get early feedback. But it's a tonne of work, if we're being honest to find the customer list, to get them signed up, to make sure that your communications are all coordinated, that the customer is having a good experience in the beta, that they're giving us feedback on it. It's a tonne of activities. So we have spent a significant time of the product ops team to automate as much of that experience as possible and to essentially serve up on a silver platter to the PM. You want to run a beta, give me your segment requirements. What kind of customers do you want? Do you have certain like special attributes that you're looking for in the mix of customers? How many do you want? Blah, blah, blah. And then once they give us a couple of quick answers, a tonne of that heavy lift is now being done for them. So when you have cases like that, it's pretty easy to opt to justify your existence. So we just do a really good job. I'm pretty obsessive that when we pick a project or projects that we start with what value are we going to achieve by doing this project? How will we measure it? How we know that we did it? And living in a very data, I would say data-driven company, the more I do that, the more positive response that we get. Even if the experiment goes poorly and it doesn't give the response or the results that we thought it would, we're still justifying our existence because we can prove from day one this is what we set out to do, here's what we found, and here's where it went left, and here's the adjustments that we would make or whatever.

  - Yeah, I mean, that kind of seems very similar to one of the other kind of activities I've often come across product ops teams taking on, of helping recruit people for any sort of discovery activity, whether it's interviewing or whatever else. So the PM's not doing the admin work there of finding, sourcing, et cetera. They can turn up 3:00 PM on a Tuesday, they've got a discovery interview in the diary, and they turn up and they do one, they're doing at least one a week because it's just there. And it's no longer the hassle of doing it. So I'm gonna use a loaded term here. What's best practise in product ops? Or good practise if we want to go for the less loaded version?

  - First of all that is a goal. In what pillar? That would be my follow-up question. There's so many ways I could answer that. I'm biassed because I love me some process. It's my bread and butter. But if I'm trying to be objective about it, I would say it's the analytics piece. It's best practise is in this world that is constantly evolving, that is constantly getting interactions with customers at your fingertips in such a different and unique way than ever before. If you don't help your product organisation as a product operations team, have easy, quick, constant access to what your customers are doing, how they're behaving, what they're adopting, what they're not adopting, then you're just not really doing product operations. Even if you're kicking ass at all the process stuff, which I also love. I think analytics has to be data, analytics, all that stuff has to be at your core. Otherwise, you're not really doing product operations.

  - So without using the opposite case, what's the biggest mistake or worst thing that people can do?

  - Not marry programme management and product ops together. Marry them together people! So worth it. Now, beyond that one, I would say the worst thing that they can do, I think the worst thing they can do is under invest based on the size of their company. So I'm not saying that you have to have X number of people just flat out for everybody, but you need to have a relatively sized product operations organisation to compare to your product organisation. So like I've worked with certain enterprises who I will not name, who have gigantic hundreds of PMs, large size organisations, and they have like one or two very sad human beings trying to be product operations for hundreds of PMs. So I think that's the worst thing you could do because it's going to naturally set them up to fail. And then you're giving this first experience from assuming the vast majority of these people who have never worked with product ops before, a not great taste in their mouth about the real value that it could bring. So if you're gonna either don't invest at all, if you're not ready to invest right, or make sure that you're giving it the right investment compared to the size of the organisation it's supporting.

  - Now, we are a channel that's called Talking Roadmaps whose heritage is roadmapping. So I'd be remiss if I didn't say, what's product ops involvement with roadmapping?

  - Okay, so at Pendo, our involvement with product roadmapping is not shocking, data-related. So we are woven into our entire operating cadence, especially since I have programme management, the executioners for lack of, that's a terrible phrase, but I've got them under my team as well as the product ops folks. So we kind of have all things about product delivery in my house, but we have a full blown operating cadence that one or both sides of the house are constantly involved in. But we try to do, we call it How We Pendo Data, because obviously that's the tool we built. But we do these monthly roadmap reviews where we deep dive into every part of our product every single month. We look at what's been built recently, how it's being adopted. We're in Pendo dashboards looking at what customers are doing. We might be watching a replay to see, hey, we're not getting the adoption in this one space that we're expecting. Let's see a couple of replays and see, are they just missing it? Like, are they not getting the point? And product ops gets to drive a lot of those conversations. They get to help prepare a lot of that material, but we are constantly talking about data, which is why I said I think it's the number one thing that you should do if you're product ops team throughout that operating cadence. That's our bread and butter for sure.

  - Now, you talked about there's a lot of change work in product ops as well. Do you need a roadmap for your products function or even the product management function?

  - Yeah, we actually do. We have a roadmap for our product operations team. We reassess that roadmap pretty frequently, probably every couple of weeks, because I was mentioning earlier, our focus has changed quite frequently. So we use it. We actually use our own tool. We use Pendo Roadmap. So we have a product operations roadmap in Pendo that breaks down everything that we're working on, measures of success, details of the project. It links out to any supporting documentation. But yeah, we roadmap our own stuff. My programme managers also roadmap their improvements. So when we're looking at how do we continue to up-level their skill set or anything like that, we also have a roadmap to make sure that we're on track for that work as well.

  - So one of my favourite questions towards the top of the session, if you had to distil your philosophy on product operations into one or two sentences, what would it be?

  - I think it's continuous and constant evolution based on data and measurable outcomes.

  - Is there anything else I should have asked you about product operations that I haven't?

  - I don't think so, I think you nailed all of it. I think the thing I'd be more curious about is, in your new role, I'd love to understand why they're only using it in one part of your org, but that's-

  - I haven't got the answers yet. It's going to be interesting. I only discovered the product ops person because I spotted that she was speaking at a conference that some other friends were speaking at. So I connected before I started and we have a call later in the month to kind of explore. So it's gonna be interesting to find out.

  - I did think of a question that you should have asked. So hiring is a big thing in the prod ops industry because it's not a long-standing industry. So how do you hire for prod ops is a question that I get asked a lot on LinkedIn or in other forums. That's one I would have asked. Do not post some nonsense looking for five plus years of prod ops experience. They're lying, you're lying, don't. What I would say is try to hyper-focus on what are those pillars that you really need to move the needle on within your organisation and then look for folks that have critical skills to those pillars. So obviously, if analytics or data is something, finding somebody that has experience in those spaces is critical. But at the end of the day, I think all prod ops people, no matter what their specialty is, need to have a proven experience working in cross-disciplinary teams. They need to be able to manage a lot of different types of stakeholders and a lot of different types of personalities in a really effective way, especially since some of the change management that we do is hard and uncomfortable and people don't love it. So stop this nonsense about five plus years. I see that all the time and it makes me crazy. And then you get people starting to do, "Oh, I've done this. I just never knew it was called that." I'm like, "Okay, this is Agile deja vu all over again."

  - So coming to the end of the session, Jessica, always like to give people a chance to pitch themselves, their business, their company, where they come from, how you can help, how they can get in touch, fire away.

  - So obviously I work at Pendo, so we, I would love it if anybody is in need of a product analytics tool, Pendo is, I think, by far, the absolute best solution out there, but beyond that, I do a lot of one-on-one conversations, coaching, talking to product ops people. We are all desperate, I think, to connect to each other because it is such a growing and learning industry. So if you ever want to just chat about all things product ops, you can always find me on LinkedIn and I'm happy to set up time and chat with anybody.

  - Jessica, it's been a pleasure having you on today. Loved the conversation, some great insights. Thanks very much.

  - Thanks for having me.