Is Product Operations a system or a function? | Christine Itwaru

In Episode 15 of Talking Roadmaps, Justin Woods sits down with Christine Itwaru to explore whether Product Operations should be seen as a system or a function. Christine shares best practices like treating Product Ops as a product, starting small, iterating continuously, and clarifying roles to avoid overlap with product managers. She also dives into the value of process, scaling challenges, and how Product Ops supports the entire organization in delivering customer value.

Christine has been in Product Management for 15 years, and has held both individual contributor and leadership roles across Product Management, Product Operations, and Strategy. She’s done so across services, finance, fintech, and SaaS and has focused on not only delivering product and outcomes to customers, but strengthening product teams while doing so. She’s led and coached teams through product-led transformation and continues to do so while mentoring Product leaders on setting up foundations for strong teams, creating and delivering best practices, and standing up a system for PMs to do their best in. Christine enjoys giving back to the Product Community and looks at Product Management as a discipline rather than a role in technology.

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 Dr Satyavati Kharde, Product and AI Consultant @ Zühlke Group & Nobody Studios. So watch out for Season 2 - Episode 16!

• Transcript

  - Operate as if you're building a product. So you treat product operations as if you are a product manager. Best practise is to focus on the pain, start small, measure, iterate, and do it over and over again. So like that leads into second best practise, which is that nothing's ever done. And that is to me the definition, that's what separates the words product operations from programme manager and project manager. I often get that question too. What's the difference between prod ops and project and programme manager? Project and programme manager is check boxes. It's done, we're good, we're moving on. We product operations needs to operate as if they're continuously building this product and iterating on the system. There's no end.

  - Welcome everybody to The Talking Roadmap Show. In Series Two we're talking all things product operations. And today my special guest is gonna enlighten us on all of those areas. Christine, I'd love you to be able to introduce yourself to our audience please, hi.

  - Thank you Justin, I'm so excited. I'm Christine Itawaru and I am currently VP of product at Userflow and Beamer and I have been in product for about 15 years now. Have done all the things from individual contributor to figuring out how to operationalize excellence across companies as it relates to product and product teams and went back into building and leading teams again. So that's where I am today and I'm so excited to talk about product ops.

  - If you're enjoying the channel, subscribe, hit the bell icon and give us a like. Absolutely, yeah. And as we were talking off camera, there's kind of such a great and vibrant and close-knit community around product operations. So I'm really you know, happy to have found that and, and be part of that. And maybe we just jump in straight into, I guess the product. What is the purpose of product operations do you think?

  - Product operations is meant to stand up systems that can align folks to the right things. In its simplest form, that's how I distil it and it can come in the form of humans, it can come in the form of humans that are also doing other work. When I say form of humans, I mean somebody who's dedicated to doing product ops itself or as many of us have had to do and continue to do, be product ops as part of another role. But in its true form, it's meant to really set up a system that's going to allow everybody to focus on the right things and deliver value to customers faster.

  - Nice, yeah, I love that, a lot of people think that product operations is operationalizing just the product management team. It's not, it's about operationalizing product for the company, and that's a big mistake, I think, isn't it?

  - Absolutely, yeah. And that's one of the reasons it was questioned so much and it still continues to be questioned today. I think it's been beautiful, man, I've got so much to say about this. It's been so, it's been so beautiful watching it just evolve. I do think that there was an element of it in the beginning where people were like, how do we make sure that the product team is moving and that the work that they are doing is making the engineers move faster. And so it did feel a little bit isolated in the beginning when I started talking to companies that were trying to implement it. But the way I explained it to them was, product operations is something that the whole company uses to be able to make sure that whatever product and engineering and design are doing is completely amplified, understood and well articulated to customers. And when that was grasped by partner teams, they were like, oh, so I kind of play a part in this too. And I'm like, yeah, you do.

  - Yeah, yeah, absolutely. It just makes sense, then they get it, right? It's not a selfish subfunction of product management, it's a function there to serve the entire organisation around product. And I think that was a big unlock for me when I kind of had that clarified for me. I was like, okay, now, now I get it and now I can see the value. I guess for people that may not be familiar, what companies need product operations or why do they need product operations?

  - So I think if you are operating in a iterative development way, doesn't matter your company type, size, industry, as long as you have a product team that is focused really hard on customers and understanding their big pains and then constantly iterating, you are going to need product operations. And I'm gonna say this several times throughout our conversation probably 'cause it comes up a lot like product operations does not mean out of my mouth a human doing it of specifically, it could mean that and I love when companies do have that, but it truly means product operations as a system. And so every company needs to think about that, particularly in an environment today where every day we're seeing different technologies emerge, new competitors come out of nowhere because AI is empowering everybody to build tooling so much more quickly. And there's so many mergers and acquisitions happening, particularly in the product space. That's what I'm seeing these days. There's tonnes of baby companies that are popping up all over the place for B2B SaaS or just tech in general and people are merging and all this stuff. So this is just a period of massive change where there needs to be some system in place to allow you to pivot quickly and to deliver value to customers continuously. So every company to me again, needs product operations in some way, shape or form or human. And I made the distinction in the beginning, anything that's not waterfall, basically, if you are iteratively developing and changing your product, you need to do this. If you're waterfall and you're building to spec and you have 25 customers and you're taking case by case, which I don't know any companies like that anymore, but I'm sure that they're out there. You do you, you build however you wanna build, like I think that's fine. I'm sure you probably need a little bit of product ops flavour as well. It really empowers companies and teams that are very conscious that change is inevitable and we need to keep up.

  - Yeah, exactly, change is often the only constant. And in fact what you've shared there really resonates with me. You've been an early employee of many companies, I've worked with a company again where I was an early employee and now as myself running a very small consultancy, product operations or at least operations is still massively important to me. I write my own standard operating procedures for myself to follow in a month's time because it just makes it quicker for me to do it again. And so it's so important and whether it's a big team of people that are around product operations or it's just part of somebody's role, the importance is still there and the chances are it's being done even if not by name, right?

  - Yeah, the key is if it's being done well or if it's just being done and then kind of like for forgotten about, right? Yesterday I had a chat with my customer education lead and we were talking about a new process that we put into place that will help the PMs around launch excellence. And we were saying that, you know, there's oftentimes where people look at, you know, the word process and they're very afraid of it. I'm sure that'll come out of this conversation. Somebody will leave a comment saying, no, thank you. It generally happens, it's fine process is not bad. But what it is is a lot of people look at it as inhibitor when it actually is an accelerator. And so, you know, process is not good if it's too tight. So you do need, again, this always goes back to changes constant, like you said. So we always have to be flexible. But yeah, I think that's a really critical thing for everybody to look at is you mentioned you put your own SOPs in place and in a month from now and six months from now you're like, oh, I already have this. I'm actually just gonna refer to this and I'm going to go. It removes the cognitive load for you. And that's the goal is to remove cognitive load for not just product managers, but CS teams, sales teams, everybody who somewhat engages with the product team and helps them to build a better experience.

  - Yeah, massively important. I know that Marty Kagan has obviously said things around product operations and process, but I think it's how you look at it. You could, you could call it by something else. You could say, this is our recipe card or this is our approach or our formula, you know, changing it, 'cause I think process has quite a dirty, you know, is a dirty word in many organisations. And like you said, they see it as an impediment or something that slows down things. Actually it is just about having just enough process and then it can be a great thing. And so that's where I've really embraced it in my life. I love product management. So I apply product management principles to myself and it's just like, yeah, how can I make this easier for myself so that in a month's time, I'm not having to relearn it, I only do it 12 times a year. So when I just write it down, follow it, and when I'm not feeling motivated, it's just easy for me just to do it step by step by step and then I'm done and we move on. And I think that's really the point.

  - You know what I find too, it hit me a little while ago that a lot of people are versed to the word process and have this kind of like allergic reaction to it when they are hungry startup people and people that are just excited to get in somewhere and just go, right? And I think that's awesome because that's the type of folks like my company is like that Userflow and Beamer today, we are moving very quickly. We are trying very hard to just like go. However, what I notice is if you've got three to 10 employees, that's fine. You're actually able to communicate effectively and stay aligned. Now when you start to grow and you're still a startup and you're hitting 50 employees, 75 employees, this is the point of which, if you don't put some form of something in place, you're gonna set yourself up for failure. Because now those people are not all talking to each other at the same time. And now this is when you hit the point of putting yourself at risk for over communicating, under communicating or miscommunicating with customers.

  - Unpack that a little bit for me, there's a way, it sounds like it's important to kind of get that balance right.

  - Yeah, you don't wanna inhibit creativity at all when it comes to product and engineering. We had our hackathon yesterday that was beautiful. It was our first one here at Userflow. So I think it was just a wonderful thing to watch engineers, it helps you understand who actually has customer empathy from the engineering side, which is one of the most beautiful things for a product person to see. 'cause then you're like, I want you to work with me. This is awesome, we can go fast together. And I think early in a company's journey, you want every single employee, especially engineers and product in front of customers, product needs to be in front of customers table stakes. But this is the place where you are not worried about process. You're not worried about any of this stuff. So let's go back to like, let's call it under 20 employees. Your company's really small, you're excited to just get out in front of everybody and learn. Go, do it, this is how great ideas are born. Now when you start to get to a little bit more of a bigger organisation, let's call it like, let's hit say 50, right? You're looking at potentially, you know, two or three salespeople. You're looking at maybe a CSM depending on how your business model's going. You're looking at maybe two or three product managers and you're looking at maybe if you're lucky and a lot of folks are today with the advancements with AI, multi-product and different lines that you're offering out to customers. So your PMs are managing different areas of things. And what often happens is the consumers or the customers of the PM information internally, which is sales and customer success, are like, where do I go? Wait, what just came out? How do I learn about this? Wait a second, what can I tell customers? Where's your roadmap, I know you love that one. And this is the point of which chaos can happen because the product team and the engineers at this point are very excited and used to moving quickly in service of getting customer's value. The issue is internally, if you don't align all of the parties, your customers are gonna feel the chaos. So you wanna hit that moment early in your journey as you start to grow and you start to scale and think about, oof, okay, pause for a second. Where can we fall down if we're not intentional right now? And so I would say this is the point of which you're looking at like that higher number of employees, you definitely wanna do it before you hit 100. Like before you hit 50 maybe, like I would say just as you're 50, have certain things in place, what does a good, for me as an example, the first thing I did when I came here was show me how everything goes out in terms of launches, right? And it was like, oh, we have this and we have that and we have this. And sometimes I'm like, nope, here's what we're doing. Like Mama Bear has now just enforced Slack. I was like, here's what we're doing. You're going to put this in Slack, I'm looking over at my other monitor and you're going to have it in this format because this is how customer success and sales consumes information so that they can articulate it back to customers in a way that makes sense to them. Immediate change, just like, oh cool, now I know where to go, now I know what format it's gonna be in and now I know where to go get any launch assets and videos that I need to learn from. Right, so took that a little bit broadly, but you gotta try to get ahead of those moments because when customers start to fall in love with your product and you start to think about our world today, everything is a little tiny community. Look at product ops today, right? Like we're growing into a bigger community, when things start to go on LinkedIn or any sort of social, your brand becomes a little bit more front and centre. You wanna make sure that the people inside are ready to talk about it at any given moment.

  - Yeah, good point. That's a massive point right there. I guess something we touched on earlier, but I'd like to kind of ask you the question directly, which is who does product operations help in the organisation? I know what you're gonna say, but I need to ask the question.

  - Yeah, yeah, no, it's okay, I can say how, I truly think it helps everyone. So I've seen many different flavours. At one point I coached a couple hundred customers of mine at a previous company on how to stand up product ops, right? The best form of product ops is when they are advisors to leadership and product, right? And I say this as like, and you and I come from hardcore OG product backgrounds, right? And we understand that at one point, we were responsible for delivering features and oh, you pushed out six features with engineering this quarter. That's for less than what you were supposed to do. You're 60% right? And so then we moved into a world where the CPO or the head of product, VP of product, whatever it is, has that seat at the table and it's now for me, I'm responsible for X amount of conversions, right? Like from product led, right? And so it's like, okay, so you want to have product ops and this is when the human is involved. Be that kind of like right hand alongside your director of product or whoever's kind of overseeing everything with you to help you understand, I had a friend and a old director at another company, Stephanie, who said this to me one day and it was beautiful. She said, your team is my peripheral vision. And I will not forget that, it was a amazing, she was like, you guys are the peripheral vision where when my team and I have put something out, we have partners that we can trust who are going to be our eyes and ears across everything to help us understand what we need to do next. My team was not saying here's what you need to do. It's, hey, here's all this data coming in, here's like a recommendation that we have in terms of process stuff that can be changed. Sometimes it was content, sometimes whatever. But anyway, I think that was a beautiful moment because what she meant there was you are listening not just from usage data and customer feedback, it's your listening within the organisation as well. So that extends out now. So you have the advisor to your leads and product and then you have the partner to the rest of the org. So they do impact or we do impact. I'm not formally, I am product up still still doing it. Not titled but still doing it all the time. All the time, all the time. But you know, for me today as an example, I'm standing up processes with my head of sales and success and she and I are working on when they learn something, what are the pipes and how do we get that back to product in a way where we can validate and iterate on something or fix it or build something, right? So you're working with the heads over there. And then I would say, who else? There's even moments where I've seen teams partner really closely, depending on the product, with legal and compliance teams, right? Because yeah, like, like SOP is, you know, any of the official terms and conditions, there are many different little things where product ops has those, I always say little things matter, right? Like they have these little things that they need to make sure are in line. 'cause at any given moment you could be attacked by somebody externally who just wants to poke all in anything.

  - The stuff in our peripheral vision that we didn't see, right? So you mentioned this kind of this close relationship, the peripheral vision. How do we make sure that there's not any frictional overlap between product operations do and product management and or other departments? How has that worked?

  - Man, I would say that was a big question that I was not struggling, but I was conscious of how I would answer it when I first like officially started doing product ops a couple years ago because it was so new and the last thing I wanted coming from like I deeply empathise with CPMs, leaders of product. Like you feel this threat of like, wait a second, what's going on here? Who are these people? But very quickly, if you can alleviate that threat and make it a partnership, it's a very easy thing to do. And what I did, I have a blog and what wrote in one of the articles was pretty helpful for a couple customers, which was talk about what you're not doing. Say like don't go into an organisation or stand up product ops and say this is what I'm doing. Talk about what you're not doing first. You are not there to build the roadmap. You are not there to do customer research unless you're product manager. And there were a handful of times when RPMs leaned on the product ops folks because they were so close to customers to sub in if we were trying to move quickly and get some customer research, but not your core job, you are not there to prioritise work. You are not there to work with engineering on on like many things that PMs do. You have to say what you're not there to do. You are not there to define strategy. You're there to empower the leaders with information that will define the strategy. And so the more you talk about not my swim lane, the clearer it becomes and what it is that you need to do to empower those people to do the things in that swim lane.

  - Yeah, exactly, by saying all of the things that you're not, you're kind of, maybe there's a level of threat there. I can possibly see in some organisations that some product managers or product functions might even feel threatened by product operations and kind of like, what parts of my job are you taking away? Or I need to be closer to this. Yeah, you've seen that. Tell me a little bit more about how you've seen that.

  - Totally, I had someone who said that product ops was nothing more than tiny little programme managers who were causing pain across the organisation. And it was because their experience with product operations was limited. And what they had was something called a technical product manager role where it seemed like it was a little bit of a blend of product ops and that, they didn't articulate it very well. I think that it just boiled down to feeling very concerned about whether they would take over their role. And I was like, there's no way that this team is taking over that role. Again, here's what we are doing and here is like, or here's what we're not doing and here's what we're gonna do to service you. Right, we are the servant leaders to the servant leaders of the organisation. And so, yeah, no, I've definitely seen that. It gets a visceral reaction from a lot of folks who prescribe to the very traditional old school way of doing product. I would say old school in a very beautiful light. I come from that, right? Like I appreciate that customer love and that digging into the data and that like being creative and throw things and be iterative. I absolutely love it, but it doesn't mean that we haven't shifted to a place where there's too much for one human to do given the world of tech today. And it's gonna continue, this is how marketing ops was built. This is how rev ops was built and product, I will say this until I don't know when, we are the most fortunate humans in technology as product people and product people cast a wider net, like product managers, designers, product operations, right? We get to build and define and strategize and learn and empathise while the world is changing around us. And everybody's flailing and like freaking out about like everything in tech. It's a beautiful thing. And I think I saw a bunch of my customers I consulted with who were like, I'm having such a hard time. But that takes me into, that always took me into asking where did the ask, where did the pain come from that pushed product ops into your organisation? And what I found was there was more willingness to adopt product operations with a team or a human doing it when the product managers and the go-to-market teams felt enough pain that they realised that having a dedicated person to it was going to alleviate that pain so they can do their jobs better. Where I found that it wasn't working very well was when some leader got wind of it, thought of it as a buzzword and was like, I probably need to bring in a product ops person. And then it was like, product ops was born out of pain that the product manager has and if somebody's enforcing it and there's like not a tieback to that pain, there's less willingness to adopt and embrace product ops.

  - Yeah, totally, if you bring it in as a solution looking for a problem, you're going about it the wrong way. What you wanna be looking at it is where are we having some problems and then how can we bring some people in to almost product manage those problems internally. I mean I had someone reach out to me a couple of weeks ago and they thought they wanted an implementation of a roadmapping tool. And actually what I did said, let's take a step back a second. Let's just jump on a call for a little bit longer, you know, an hour or two hours. Let's go through it and let's take a step back and look at your challenges. And actually I think you've got more of a challenge around product management and prioritisation and strategy than you have a tool. And they were so grateful because they actually hadn't spotted that. And it might mean that I get clients in a year's time when they're ready to implement a tool, but the problem wasn't the tool at the time. And that's really important. Like you said, product operations, don't just bring it in 'cause it's a buzzword and then see where they can fit in, understand where your problems are. And actually that fits into kind of the last question I have for you in the core set of questions here. How do you justify having product ops? Well, by the time you've got product ops, they've pretty much justified themselves 'cause they've got a problem to solve.

  - Exactly, yeah. I mean you answered it there, and like, there's a very tactical way that I did that I coach teams on doing this as well. We did it back when I started product ops when I was at Pendo was, you know, we knew that there was pain, we knew we were skyrocketing in growth. It was a beautiful moment. It was like insane growth during COVID especially. And I was like, okay, if we don't put something in place, we're gonna have a huge problem across this company. And we are already at like 400 ish people, right? I think at that point, and I was like, you know what? We know we have pain, we know we have so much pain. It's about prioritising the pain now. So like you said, you have to PM this, you actually have to PM rolling out product ops across the company, whether it's a person or somebody's doing it as part of their job. So I just created this survey and I always mean to write the survey up and publish it, like I should do it. So we put out a survey and I don't remember all the questions, but it was around, you know, on a scale of one to five, how painful, how much time are you spending with customers on research and discovery calls, right? And then on a scale of one to five, or what was it? No, I don't think it was one to five, sorry, it was like quantifying five hours, 10 hours or something like that. And then it was how much time are you spending on firefighting and you know, so what we did there was, let's just say it was like 15 hours a week on firefighting and like three hours a week on calls, which is common. What we did was we set a goal as the product ops team that a quarter from now, we're gonna start to see this happen, right? And about two quarters out, this was higher. And so quantifying your value becomes easier when you can solve the pain of the product manager. When we realise that that was one set of customers, like you mentioned, who you asked, who does product ops serve and help before? This means that they are spending quality time with customers, which means that they are increasing the partnership element of the company on behalf of customer success and sales, right? So I put a survey out to the CS team and our sales team and I was like, on average, how much time are you spending in Slack or across our drives looking for product updates? And another thing, you just wanted to see, you know, like this stuff start to switch and then have everybody feel this alignment within I would say like I think we did it within a year it felt nicer, right? So it takes a bit of time.

  - I love that you did that and I think it's appropriate for me to start introducing into my business as well in terms of the way that I help my clients with work because it's very difficult to measure in terms of the things that are important to the business. It's very difficult to measure things like product management efficiency and you know, what it's actually doing to the bottom line of the company. We know that road mapping or road mapping processes is an important thing to do, but actually measuring the efficacy of it can be really difficult. And so I love that actually. It's just like, look, let's just measure what we can measure. Some of that might be a proxy to the overall good that we are doing, but we still know that you know, we're netting benefit to the company. So let's measure it in the way that we can and I should really do that when I work with clients to maybe ask them some surveys at the beginning and then after we've done the work together, ask some surveys at the end. And those are the bits that become much more tangible and imperial and you can measure, right? Because otherwise it becomes quite fluffy.

  - Yeah, it does. And one good measure I saw one of my customers implement was she looked at feedback like in the universe of feedback that was coming in and looking at it against current roadmap or quarter roadmap and then setting a goal for her product ops team and to be able to elevate and synthesise and sanitise the feedback product. So whatever, I forgot what tool they were using, but basically make it so amazing that it would heavily impact the roadmap. And it was cool 'cause it was like features delivered due to, you know, like direct customer requests, you know, 2% of the roadmap versus like, you know, 50%, two quarters out or something, which was beautiful and it shows the customer centricity and it highlighted for her, she said what was nice was that it made the CS team who was inputting feedback as well be that much more diligent because they knew that there was some sort of system and process in place to elevate feedback the right way.

  - It actually went somewhere, it was actually being measured, we were actually looking at it. So I want to go and talk a little bit in this next segment about the good and the bad of product operations. So what do you consider to be a best practise in product ops?

  - You have to operate as if you're building a product. So you treat product operations as if you are a product manager. Best practise is to focus on the pain, start small, measure, iterate, and do it over and over again. So like that leads into second best practise, which is nothing's ever done. And that is to me the definition. That's what separates the words product operations from programme manager and project manager. I often get that question too. What's the difference between product ops and project and programme manager project and programme managers check boxes, it's done, we're good, we're moving on. Product operations needs to operate as if they're continuously building this product and iterating on the system. There's no end. There's no end every, depending on the maturity of your organisation, you're gonna iterate either every quarter or every two quarters. That's just how it's gonna work, yeah. So start small, attack it like a product, iterate, well learn, measure, iterate over and over and over again.

  - It's no wonder that we've seen such an incredible rise in product operations with that level of approach and thinking to it, which is all around value. It's no wonder that then these teams grow quickly once they've been able to demonstrate their value, then companies want more and more of it. So I think that's why we are just seeing this grow so well, especially because you know, there's operations in other areas of companies as well, sales ops, DevOps and things like that. But product management especially that kind of, not everyone comes to product ops from product management, of course there's some fantastic people that haven't had that background, but to apply product management thinking to product operations just shows how successful that can be, I love it.

  - Ooh, I have a pro tip. I've seen very successful product ops folks make sure that they align very quickly, obviously, with their core customer, which is the product manager. But next with the other ops teams, because that is the point of which things can break down very quickly. Let's say for example, you're operationalizing something for product out of HubSpot or out of user, anything, any system that you're basically responsible for. If there's a change in revenue processes and HubSpot's affected or Salesforce is affected or whatever and the product ops team doesn't know that right away, that can lead to something very bad. So I would say another best practise is to obviously focus on your core customer, which is your product manager and the dev team. But very quickly, your ops teams if you have them. If not, then you're gonna move on to your partner teams.

  - Yeah, good call out. And I guess are there any other mistakes that you see people make or antipatterns or bad practises in product operations? I think we mentioned one which is obsessing about process on these things, but is there anything else you'd add to that?

  - Yeah, don't obsess over process because you need to be agile just like the product needs to change. So yeah, definitely that's the first one. Do not treat yourself or operate like a programme manager or a project manager. That is not gonna set you up for success because I always coach my product ops folks. I remember when we set up my first team, it was about 11 folks I think, each in different verticals of product ops. But the core was me sitting down with them and teaching them how product people think and how product managers build and telling them that you are extensions of these people. And so basically your title is product ops, in your head, you need to make sure you're operating the way product managers do. So that is a very good practise to have in the anti-pattern is you do not want to operate as if you're checking boxes. That's not how it works.

  - What a great piece of advice. I think our audience are gonna love hearing that because we, you know, we've got experienced people tuned into the channel, but also some people will have just heard what product ops is. It's been around for a long time either informally or formally, but it's still new to some folks. So hopefully some things that you guys have heard have really resonated there. I wanna talk about product operations involvement in road mapping. We talked about product operations and applying product management thinking to it. Do you need a roadmap for your product ops?

  - I don't know if we need a roadmap in general, and I don't say that in, I know exactly like who you, I think roadmaps are a strong but also loose form of communication with your customers. And when I say customers, I mean your internal teams and your external teams. And I go back to saying something a couple times in this recording, which is, things change so quickly in our space and you need to be able to pivot very quickly. So whether you have some sort of a roadmap layout or some sort of a roadmap communication tool that you're using, somebody needs to be responsible for keeping that updated. This is one of those moments where, you know, there was friction between the product manager and then like product ops, like, oh, like what are you doing? You know, what's your job? Blah, blah blah. And then it was like, can you please make sure my roadmap's like constantly, you know, whatever. And it was like funny because it's like there are these little things that you get bogged down with. And I'm not saying product ops is to catch all those little things, but this was one of those big things where it was systematising the way the product team got the information into the roadmap. So I would say there's one which is making sure you're standing up a system where the feedback's clean enough, it's getting into the product development lifecycle in a way that makes sense. There's checkpoints in between where you make sure you're communicating to the go to market teams what's coming. That's the point of which you have some sort of a communication tool, roadmap, whatever it is. And then a final kind of like, here's where we are, you can definitely communicate this stuff out. This goes to like product operating model stuff, right? Like there's so much more of a focus on product ops today because all of a sudden people are embracing product operating model and not tying it with product ops. I'm like, guess what guys, guess what guys? That's what product ops is doing. It's just systems, the ceremonies, the artefacts, the everything. But there's definitely magic when somebody is able to bring clarity to that chaos and everything that basically gets put on this pretty little like, you know, four or five line Gantt chart. How do you think that chaos got there? Like got to those five lines. I remember there was once I was sitting down and I said teaching my product ops managers about how product managers operate, built so much empathy and gave them different perspective. I decided why not show the whole organisation how product managers operate and give them empathy. And it was cool 'cause I just had this massive mural board and I put all the inputs on this, you know, one side and it's like huge and it keeps growing and then it goes, okay, and then here's our leadership meeting and here's where we define and we use blah blah and here's the product leadership meaning, and here's this and this is when everything starts to get smaller. And then I go, no, look at these tiny little lines like look these tiny little pretty lines like how did you think this all happened? But yeah, I think operationalizing or systematising that can come from a very strong, prod ops person or somebody who's just gonna focus on it for a core part of their month.

  - Absolutely, Christine, you've got a wealth of product operations and product management knowledge here. I'm curious whose advice you listen to in the product operation space.

  - Denise Tillis, I absolutely adore her. You mentioned Becky from Dragon Boat, another one that I often follow. Melissa Perry, Melissa and Denise wrote the product ops book.

  - It's in my little stack here.

  - I appear, I'm very proud of appearing. I love that very much. Pendo also, my former employer wrote what I think the first product ops ebook that's out there. So really great resource and it was nice, but it's actually a really good one because it shows you the different flavours and the way people were approaching it about eightish years ago now maybe. And then you can kind of like look back and think about, wow, look, the world has shifted so much, like this tells you again, we all need to shift along with it. I think those are some really great resources.

  - Phenomenal, and in fact, I'm thrilled that we've got, some of these people have been on the show already. Some of them are on the cutting room, in the cutting room at the moment and we're gonna put some episodes out. I wonder if there's anything about product operations that I should have asked you, but I haven't.

  - I think a good question to ask is, do we see product ops? Because there is a lot of synthesising of information going away or being minimised by the introduction of AI and to many, yeah, that's a hot topic. That's everybody, right, that's everything. So I would say, yeah, like I do get questions around, do you think product ops will become obsolete because AI tooling can take care of a bit of that work? AI tooling has definitely enhanced my ability to synthesise information. I mean if you're not using AI, sorry. You gotta do it, man. Like it is something that you need to do in order to stay not even ahead, but just stay current at this point. There are people just catching up. You and I started in product years ago and it's like, I'm sure you're like me, where you're like, whoa, like what's happening?

  - I know, but I don't see it as a replacement of me. I see it as giving an augmentation of what we're doing or giving you and I superpowers. I don't see it as, I don't feel threatened by it, but I do feel that you're right. If we don't embrace these things, we'll be overtaken by people that are.

  - So I think it's definitely enhanced the outcomes that a product ops team can drive or let's just say as an example, synthesising feedback was something that my product ops team was responsible for. We actually built a core part of the product around the fact that product ops was feeling pain. So we enhanced the product that we were building at the time to help take care of that. And did that make the team go away? No, was it freed up time to be able to focus on the whole product operating system? The product operating model, the thing that we talked about before, that continuously needs to be perfected and iterated on so the company can continue to do well. That's one thing, I will say though, and this is controversial hot topic. Your goal as a product ops person is to set up a system so beautiful that they don't need you anymore. And so there are going to be companies where they've hit their peak and they're sustaining and what they potentially need is you to consult at some point or for somebody to come in and just take a look at what they currently are. If you've set up that system so beautifully and they don't need you anymore, you've done your job very well and that means you have helped drive successful outcomes for that company and for customers in general. So yeah, that's like a hot take, but I think for anybody who's in sort of any ops role, you're doing your job very well when you've stood it up that way.

  - Yeah, I remember when I was working as a product manager a long time ago, and we had business improvement consultants which would come in, make some recommendations on people, process tools, make some changes, you know, do themselves have a job in that area and move on to the next thing. And I think we shouldn't, I think it's an absolutely the right way to look at this is like if we're doing a, you know, if we're doing it well, we don't have to do that piece anymore. There's always another problem to solve. And so I think we shouldn't be scared of that. We should be energised by the fact that we've left something better than we found it and we can now go and improve something else. And that's really important.

  - I love leave something better than you found it. Yeah, and I think if you are at an organisation where there's not problems to solve, you don't wanna be at that company regardless of the role you're in.

  - I'm gonna ask you a difficult question now. It's only difficult in terms of how we have to think about it, but take some time and I wonder if you had to distil your philosophy of product operations from all of the rich experience that you've had in your career so far into just a couple of sentences, but a few words are okay and a couple of paragraphs are fine too. How would you distil product operations?

  - I think very simply, product operations is necessary no matter if you have a human doing it or you embed it into the group of humans who are building product, it's a necessary good, not a necessary evil. If you have a human doing it, you need to make sure you focus on bringing in a human that has enough pain to solve. If you are distributing it across the team, you need to be able to appreciate and recognise that the team's not gonna deliver customer outcomes as quickly as you want them to. So one way or another, you have to pick your poison and figure out, you know, what you need. It's just table stakes though, so it's table stakes whether it's a human or it's a mindset that you adopt.

  - Incredible, yeah, that deeply resonates with me so much from the things I've experienced as well. So I'm nodding along and I think a lot of our audience will be nodding along as well. If that's been the case, how can they get in contact with you? How can they find you, how can they learn more?

  - I'm always willing and happy and able to teach, I love it. LinkedIn's easiest. The productheart.com is my site, so you can find content and stuff there. So yeah, definitely. Yeah, I mean, LinkedIn's probably your best bet.

  - Awesome, well look, Christine, all that leaves me to say is thank you so much for spending some time with us. I've really been looking forward to this one since we have to shift it from last week to today. So thank you for spending time with us. Thank you for sharing your expertise from your kind of your rich experience in product management world. You know, we've been doing this for a long time. We've seen the pendulum swing in a couple of different ways. It's really exciting to be part of product operations now and building things. So thank you for being part of that. And importantly, thank you for sharing that with our audience. It's been great to have you on today.

  - Thank you for having me, this is so fun. I love talking about this stuff.

  - Cool, thanks Christine.

  - All right, thanks, bye.