Does POps enable momentum? | Gerisha Nadaraju

In episode 25 of Talking Roadmaps, Phil Hornby speaks with Gerisha Nadaraju about how Product Operations enables momentum in scaling organisations. They explore when POps becomes necessary, how it drives alignment across teams, and why success depends on solving real organisational pain points rather than over-engineering processes. Gerisha also shares practical advice on adopting a product mindset, focusing on adoption, and balancing short-term fixes with long-term strategy.

Gerisha is an experienced Product Operations leader currently heading up the function at Bentley Systems.

Before this, she built and scaled Product Ops at UK fintech unicorn TrueLayer and payments scale-up Dojo. She’s also the founder and host of the Product Ops Podcast (POP) - a platform amplifying diverse voices and sharing learnings from across the community - and founder of The Other Half Podcast, empowering women in tech.

Gerisha holds an MBA from the University of Oxford, where she focused on social impact and entrepreneurship. Her earlier career spans investment and accounting in South Africa.

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

Does POps enable momentum? | Gerisha Nadaraju

Gerisha Nadaraju and Phil Hornby

After this, we will have a short interlude with a number of teaser-style podcasts for the Product World EU conference speakers and panellists, give them a listen!

• Transcript

  - But that idea of momentum really stuck with me because you are trying to get the ball rolling when it comes to the things you're putting in place. Your success or product ops success depends on creating this momentum with the things that you're doing, and getting people to adopt it. And so I just thought that's a really interesting way of looking at it as a function that is enabling momentum within a company, and that kind of shows you that you're being successful if you can get these things rolling and off the ground.

  - Welcome to "Talking Roadmaps" where we are on our final guest episode. Really excited here today to have Gerisha joining us to talk about product operations again at that final episode. Gerisha, tell everybody about yourself.

  - Yeah. Well, first of all, thank you, Phil, for inviting me onto the podcast. I'm excited to, I guess, make it in as your last guest for the season on product ops. So just a bit about me, I'm Gerisha Nadaraju, and I'm currently the senior director of product operations at a company called Bentley Systems. And prior to that, I also led product operations at both a startup and a scale up here in the UK that was in the FinTech space. I don't have a product management background, which I think a lot of people do who end up in product operations. My background in tech was more in business operations and chief of staff type roles. I came from, I guess, the ops side. But I'm originally from South Africa and in another lifetime I used to be an investment banker and an accountant at huge corporates in South Africa.

  - If you're enjoying the channel, subscribe, hit the bell. And give us a like. Interesting. I mean, so I work with a- or, yeah, in fact, I still work with a large cryptocurrency exchange where most of the people are in South Africa, and worked with their head of product ops for a while helping them with some stuff in my coaching practise. So interesting, kind of small world. I mean, you're in the UK, right? These days FinTech seems to be our biggest export. Yeah, it was huge. I think that was, you know, one of the reasons why I ended up pivoting into, well, tech but specifically FinTech, is 'cause I had a finance background and when I was thinking about which area in tech do I wanna go into, I ended up doing an MBA in the UK. So that was the reason I came here from South Africa and then pivoted into tech from there. But, yeah, fintech was huge. And I actually joined an open banking startup back when open banking, you know, had just started. We were on the cusp of it and was like the first company in the UK doing these open banking APIs, which was really cool. It was cool to be a part of it.

  - I mean, it's an interesting background coming from that other side of, you know, the operation side as opposed to the product management side, and I have seen an interesting mix of people coming from those different sides. Even in product management, you see people coming from the business or the marketing side or from the tech side. You know, there's no direct path into any of these roles but there's two dominant kind of sides to the house, I guess, of where people come from. What do you see the advantages of that different background from, say, not coming from product versus coming from product?

  - Well, I like you that you said what's the advantage and not the disadvantage. But I think the advantage for me is 'cause I went into business operations at an early stage startup, that was my first role, so I was in tech and I was in a 10 person startup. So business operations, like what does that mean at a 10 person startup? It means that you are kind of doing anything and everything to solve problems that are just gonna come up and you can't predict what those are gonna be. So, for me, that is probably the best type of product ops experience that I could've got when I think about it now because it was such an ambiguous role in a way. You don't know what it's actually gonna end up being day to day but you know that you're sort of rolling up your sleeves and trying to solve these problems that exist within the company. And I was working very closely with senior stakeholders, you know, our C-suites, starting to understand different areas across the business, and in that role I started looking at some of the problems we had as we were scaling, right. So as you start to scale, what are the problems that you see and how do you tackle those? So it gave me an overview, and I used many of those ways of thinking when I went into product ops, but it was a different focus that I needed to have. So I think that was probably very helpful for me personally.

  - What made you make that transition from business ops to product ops?

  - It was, again, super organic. You know, like there wasn't a thing saying, "This is product operations." So I was in an early stage startup that started scaling, had worked a lot with the C-suite and, you know, developed a relationship with them of being a problem solver and a bit of a fixer in the company and we started scaling our products internationally for the first time. So now we were thinking about, "How do we enter the European markets?" It's not just the UK, but going to France, Germany, Spain, Italy, all of these countries. And our CEO at the time sort of was thinking that maybe these product teams might need some operational support in how we did that, right, so it was very specific problem. And he sort of pulled me and two people internally in the company and said, "Okay, can you guys go and have a look at what's going on there, and see maybe where they need help and how we support them?" And so I was in this internal team called Catalyst. We named ourselves Catalyst and we went in there to work with the product teams, you know, the PMs, the devs, looking at how we enter these markets and ended up realising that that was product operations. And then sort of got the mandates to hire for product ops and define the team, and what we were gonna do. But to start with, I was just following the problems.

  - So it sounds like you could've just equally ended up in product and it could've been something just done by the product people, which is often how product operations starts, right, it's the product people doing it. And we're problem solvers as well, that's how I got into product management, in fact, being the person who turned up and solved, understood the customer problems and the business problems and dealt with them together.

  - One of my guests actually on the podcast, I had someone called Blake Samick, who I really liked the way that he thought about product ops, but he did it at Uber Stripe and now he's at OpenAI. And, you know, even his journey, he was sort of like right place, right time with these problems that were coming up. And he was a product manager that ended up moving into the product ops space and then leading it.

  - So we talked about you going into product op. What do you think, what is product ops in your world or in your definition?

  - I kind of have a standard or broad definition of product ops, which hasn't changed much over the years. This is my third time leading product operations and I've done it at a startup, a scale up, and now a much more large scale corporate company. But the way that I think about it is that product ops is there to improve the alignment and efficiency of scaling product teams by focusing on things like communication, processes, better access to relevant information and tooling, right. That is probably my bread and butter definition or broad definition that I would say for product ops, and it has stood the test of time in each of these three very different companies. But what you choose to focus on, like, you know, which bit of that to help with the alignment or the efficiency or the problems, like, are you looking at comms? Are you looking at data or information? Are you going into the tooling? Are you looking at the processes? That depends heavily on the context of the company that you're in and, like, their most critical problems. So what I always do when I go into these companies is figure out what are the key problems first and then look at what I focus on.

  - It's interesting 'cause as a product leader, when I reflect on what you said, the first one you said is the one that I feel like I'd have the most tension with, like, alignment. I spend my entire day, you know, making sure alignment is there, as a product leader, and so I can imagine butting heads with a product ops person trying to essentially drive the same agenda. Just wondering if you've got any thoughts there of how that works in practise in your organisations.

  - Yeah, I think that's an interesting thing. First of all, I love that you said that as a product manager that's what you're trying to do every day, day to day, is make sure that you've got that alignment. Not everybody thinks like that, right. So you, Phil, fantastic, you were thinking about that. So now you've got different types of organisations, I'm gonna think about a larger scale one. So that's top of mind 'cause I'm in one where I'm looking at like 60 different product teams or squads, right, so it's a huge scope. So when you've got 60 different product teams or product managers who each kind of are thinking about alignment maybe in a different way, and then I'm thinking about how do you create that alignment with, you know, you've got one stakeholder like sales or customer success, or support. They don't necessarily want to have to align or speak to 60 different people to get like one message across to the product teams. That's where, like a perfect example where you fill you're in a squad, you're thinking about, "Oh, I'm doing my alignment day to day for my roadmap, you know, my product." Like, multiply that across the org and I think probably the perspective of the alignment that I'm looking at or trying to help with is different. And that's where I think it's kind of like educating and just chatting to you as a product manager to say, "Hey, Phil, fantastic, you're doing that great work. Where are you putting this stuff? How are you dealing with stakeholders? Oh, Phil, did you know that actually Jane on this team is not doing that at all. It would be so helpful if you could share the way that you're doing that." Or, "By the way, can we take the way that you're doing it and bring it to the rest of the org so that stakeholder X is able to better understand?" So I think that's where, like as one PM working almost in a little bit of a silo, you don't see the alignment that's often needed across the business or the product organisation.

  - Sure. And I can see that. Yeah, and as you get to those sorts of scales I can understand where those challenges come in. Heck, even if you've then got a tribe type structure above that where you've got maybe 10 tribes across those 60, then there's still six messages to align with everyone. So yeah, I can see how that starts to become a scaling challenge. So is that the reason why we need?

  - I think that's probably, for me, that's like the key word in it because I was in an early stage startup, I guess, to start off with, right, and we didn't have product ops. You know, you didn't get a product operations person in that, or call it product operations necessarily in a 10 person startup, right. But as we started scaling, certain problems or cracks start to appear with how you're trying to work. And I think there's always need for a product operations person or team, in whatever form, 'cause some companies call it something different but, in essence, they're doing that type of work. So, yeah, in a scaling product driven business you would need product ops, but I do think scale creates these problems that start surfacing, and those are almost like your signals or early signals that, "Oh, product operations could benefit you," because, you know, you could end up having things like increased cross team dependencies. So all of a sudden, you know, now teams need to speak to each other in order to coordinate to figure out what they do. And, again, doing that at mass is difficult. You get communication issues, you get problems finding key information, everybody's storing the information in different places, they can't keep track, you can't give visibility about what's going on, your PMs can start feeling overloaded and not being able to do all the things they wanna do. So I think, yeah, I do think scale is one of the key things there that ends up creating those signals that you would benefit from product ops.

  - Okay, and so we're hitting some scale point. What are the sorts of inflexion points where we start- will you give us some of the symptoms, what are the flexion points where those start to happen then?

  - Okay, I'll give you two examples 'cause actually in my first two times that I did product operations, I wasn't hired into a product ops role. So as I said, like the first example was at the startup that I was at where we had these teams that were going international and the sort of catalyst or trigger inflexion point there was the pace at which we had to do it. It wasn't like we had a roadmap, and we had certain expectations from customers and investors in terms of when we were gonna do this. And so the teams needed to work really, really quickly in getting into these markets and also replicating it. And that was where it was a case of, "Well, actually, I don't-" you know our leadership was thinking, "I don't think the teams can do this 100% by themselves in terms of the logistics, the setup, understanding what information we needed, how are we gonna test these accounts, that is stuff that the devs and the PMs are not gonna have time to look at necessarily. Can we figure out a way to operationalize some of these elements?" And so that was a reason to say, "Hey, let's actually take some people and put them in there." And so in that company, it also depends on the leadership that you have, so the product leadership. I don't think the CPO at the time necessarily felt that we needed product ops in. And so, you know, I was quite happy to focus on what I needed to in a different area, but then we had an influx of hiring where that company was scaling up the product organisation really quickly. So we had a lot of new product managers join the org and suddenly it was like those new people were saying, "Well, how do I do this? Where's this? What's the tooling? How do we work?" Like, you know, there were all these questions. And so I think that was the trigger again to be like, "Oh, okay, do we have processes in place? What happened? Where do we find our information? What tooling?" And that was the thing that triggered it there.

  - Okay, and so that's interesting. Yeah, a scaling but a headcount scaling and a scaling in terms of delivery, should we say, like, not the development delivery but are they delivering to the market kind of being two key drivers. Interesting.

  - I'd just say a third flavour that I've seen, and this is more in established or I'd say like older school companies or more corporate and large scale, and you've probably heard this, is this like product transformation where they've been working in a certain way for a number of years, and now they want to adopt more modern product management and ways of working, and to almost come in and be a change agent and help set that up. You know, they brought in new leadership, they wanted to move towards, you know, empowered or whatever it is. That is the other scenario, also, where I've seen almost this need for product ops. Yeah. I mean, in there you mentioned agile sort of coaching organisations as well. So there's different shapes of product ops organisations, right, like different things they cover but the different types of people in there. Can you maybe kind of unpack some thoughts around the different shapes of a product ops org?

  - Yeah. I mean, it depends again on what the focus is, but there's different flavours of it in terms of structure and focus. So in terms of structure, you could have embedded product operations where a little bit like, Phil, you were saying, if you were a product manager you might butt heads or find friction with a product operations person if they were focusing on that. In an embedded model, you'd have the product operations manager working like within the squad alongside the PM, right, day-to-day in your standups, and doing all of that. And that's what I had when I did my first product operations. When I had my team, we had people embedded in those squads that were going international, so they were working alongside the PMs. And in some cases it is a bit blurred, like, what does the PM do, what does the product operations manager do? It can go that way.

  - I've seen that particular model almost turn into the assistant to the product manager, which is a bit of a dysfunction.

  - Exactly. Associate PM. It's also highly driven by how the product manager themselves perceive the product ops person and, you know, whether they want to give them some of their work. And I sort of learned how to create boundaries and better definitions when it came to that, from observing that. But then a centralised model is also one that happens, and it's often what happens when you're a team of one 'cause this is the other thing, you can also just be a team of one in product operations trying to solve some of these things. And a centralised is where you're working potentially more closely with your product leadership or you're reporting to your CPO and you're trying to tackle some of these problems, but you're tackling them through things potentially like working groups, cross-functional working groups, partnering closely with product leadership or product managers on the ground to drive some of these changes 'cause you don't really have the ability to, you know, take on these initiatives yourself. That can also change the model and the way that it operates. And then on one of my episodes of my podcast, I do run a product operations podcast and on one of the episodes with Stripe, so Blake Samick, he uses a mixed model. So it's embedded and centralised, where you have some product operations people working on the ground in these teams where it's needed, and then you have a centralised function that's thinking more broadly about, you know, tooling and processes and systems that we need overall. And there's almost this feedback loop between the teams on the ground surfacing insights to the central team and then the central team creating things that can be used, and then the embedded product ops kind of helping with adoption of those methods on the ground, which is a really cool sort of flywheel of how it could operate.

  - I mean, it sounds a little bit like sometimes you get a regional and central product management organisation as well. Sometimes works, sometimes don't 'cause you've got people more, you know, out there in customer facing, should we say, people more building. I'm generally not a fan of it on the product management side 'cause I think it creates too much distance, but I've definitely seen it on other functions internally where it's worked. So yeah, it just made me think of that model, you know, as we see every- you've used my favourite phrase, it depends many times already 'cause it's the only answer we can ever give in the product world, 'cause everything's contextual. Okay, so we've kind of talked about some collaboration, different models and so on. How do we justify even having this thing?

  - I like that you've asked that question. It's, again, very relevant top of mind question within product operations. I thought about, you know, figuring out how to understand that better also through my podcast. So in season three the theme was listening to customers, and I didn't talk to anybody who worked in product operations for that season. I spoke to our product ops' internal customers who are people like product managers, CPOs, engineers, UX, you know, UX managers and customer facing people within customer facing roles. And I just spoke to them about what are some of their top three challenges in how we do product operations on the ground in companies. So it wasn't product ops specific, but every single one of them was able to come up with three challenges that they face in their day-to-day in doing product work. And all of those challenges and pain points were things that product operations could technically help solve, right, and they all felt like we needed somebody to be tackling that in order to do it. So I think that's kind of the biggest justification, is that the way that we actually do product in startups, scale ups, many of these companies, is very different from the theory or like the optimal way of doing it. That does not exist. It's so messy, it's so messy and everybody spoke about this. And so, for me, real pain points exist in a company in how they do product. I haven't heard somebody who said it works perfectly. Now, you would bring in product operations if nobody else is looking at this, right, and it's becoming such a pain point that it's potentially impacting your, and when I say your I mean leaderships like their ability to do their job, the bottom line, negative impact on customers, right, because some fires can always burn but there'll be this turning point where it's burning too much and that will make them think that they need it. And so I think that's probably the key.

  - One of the philosophies I always had about product management is that one of the reasons we're always running around like crazy people is because we're one of those teams that's empowered to do pretty much whatever it takes to make the product successful. And that empowerment is great but it leads to that messiness. It's like you're not staying in your lane and doing the same thing all the time, but I think that's what attracts many of us to the role is the fact that there's a different fire every day and the key thing is knowing which fire's just gonna smoulder in the corner and which one's gonna burn down the building, and know which ones to run to and deal with. And I guess what I'm hearing is I've got a partner and, you know, that I can actually call the fire department at the product ops and say, "That's one that needs dealing with, and I'm gonna deal with this one, 'cause this is more customer facing and this is more internally fit or organisational." And so that can give us another layer of, you know, dealing with the fires. Although I don't wanna get rid of them all because, to be honest, I like firefighting.

  - My favourite meme is obviously the this is fine one, right, and I often put that up even with my own team, like, you know, "This is the backdrop that we're working in. We don't have to put out all of these, but we need to just choose one or figure out which is the one that we tackle." Yeah.

  - So okay, so I'm gonna switch angle a little bit. What do you consider to be best practise in product ops?

  - Yeah, I think best practise in product ops, and this is through learning it almost the hard way myself, and maybe because I don't have the background, is taking a product minded and, you know, product management style approach to how we do our work, right. I actually think how we approach and do our work in product ops is so important. And by that, I mean, all of these things in like a product development life cycle, what you would usually do as a product manager or, you know, a product team, you need to think about in how you do product ops. Which is, you know, identify your internal customers, understand their pain points, listen, like actually listen to the problems. Do not go solution first into what you think it should be. You know, figure out which thing you're gonna prioritise and work on because you can't have everything on the go and lots of whip like work in progress, nothing's gonna get done. Have your backlog but know what the priority is and align that and have some justification for why you're picking that thing to work on. And then most importantly, which I speak to my team about and I now do also, is figure out an MVP, right, to start with. Start small, don't create an end to end solution that you haven't, you know, put in the hands of your actual customers to see if that works. You need to get the feedback on it, we need to see what's happening with it before we do, you know, the most polished version. Rather get a scrappy version one in their hands, see if it's creating friction, see if this process is helping them or whatever, if it's a framework. And then iterate, iterate on it, and also measure adoption. So one of the things I speak to with my team is that, you know, if we create this dashboard for analytics that is really fantastic, has amazing insights in it, but nobody is using it, right, we've put it out there and now nobody is using it. We need to find out why, right, why was it not helping them? It doesn't mean that we're successful because we just put that dashboard out there, they need to use it. So I think, for me personally, that's been like one of the best things I think you can do in product ops. And then also, it's a really great way to relate to product managers or the people you're working with, 'cause you're taking the same approach to work.

  - Totally agree. And yeah, the adoption part of tools, I mean, there's an interesting side question there of, should product ops own the tools and operate the tools?

  - So I am tool agnostic. Like, so definitely first of all, I don't have no tool of choice anymore, like at all. You can tell me that we're gonna use anything, I'm like, "Okay, that's fine. Like, we'll figure out how we work with it." And obviously some things are merits, but I think it's not about... Oh, I think it's more about thinking about how best to use the tools, right, and how to enable others to unlock the value that we need and helping them to, yeah, just figure out best practise in how you use it. So I guess some guidelines around what we do and how we use it, but we can't be going in there to do the stuff for the people that need to use it day-to-day. That is not something that I think we should be doing. But I've also seen tooling that has just been left in the wild, you know, with no sort of governance and nobody can get anything that they need from it, you know, and sometimes in companies this is a huge investment. So in every company that I've been in, I have worked with the tooling, tooling stack, to see how can we help our product teams use that in a better way and create some sort of system of record for visibility and transparency.

  - Yeah. I mean, I'm well known for being generally a tool hater. I know I need them but, to be honest, my favourite tool is still a pen and paper, or... I mean, I quite like working with an AI agent in terms of just a thought partner, and then it's just words. You know, generally it's like relatively long term, long form writing that I tend to find is my most powerful tool, which then just means that Wiki gives me most of what I care about. And then I have to derive things into tickets in Jira or Ado, or whatever else it is, but that's the bit that I absolutely detest.

  - Or actually putting it in. Yeah, I think maybe this is where like my biz ops, that higher level view of working with stakeholders, you know, so much of this is around transparency at scale in an organisation. You and your team, you know, or I keep saying you, Phil, but a product manager or someone in their one team just running it could probably do it without very much tooling, or whatever. You could choose anything.

  - If you're in product you can even do it all on the wall. I'm old enough to remember doing things that way.

  - You say that, but actually one of the companies I was at, they called it a plan on a page and they literally put it up on a wall, like a physical wall. And we were quite a big company, but they were trying to make us, you know, go back to it. But yeah, you could do that but I think more and more, at least in product operations, one of my biggest customers, internal customers, is leadership at the moment, you know, is that leadership team and the squads and then customer facing teams. And so much is trying to figure out how you get the right reporting to satisfy the needs of certain stakeholders with the least amount of friction for PMs. So how can you automate it that we don't have to keep knocking on their door? And so I think that whole architecture and structure is probably where the tooling comes in.

  - So we said best practise and we took us down a rabbit hole on tooling. What about the biggest mistakes people making product ops?

  - Probably it relates a little bit to what I was saying about this taking a product minded approach to how we do our work. But I think one of the biggest mistakes is when, you know, some you know, product ops can come in and you can be quite like process heavy and you can over engineer the answers or the solutions that we need for certain problems that exist. And I think this means that you're in a way like not listening to your internal customers or working with them and thinking about adoption, and, you know, people... I'll use an example, so one of the companies I was at I got pulled into like a post-mortem, but it was on a GTM launch because the product team had apparently not notified marketing about that a product was going out. And so it launched, but marketing had not heard about this at all, okay. So came in, facilitated this postmortem with the different stakeholders, and at the end it was said, "Oh, Gerisha, can you help us put to together an end to end go to market process for this company so we have best practise on what we should be doing and following?" Okay, I was a team of one at that stage and so I said, "Let me partner with two product managers to see what's going on, you know, why weren't people informed what's happening?" And so instead of it being an end to end go to market process that I was asked, you know, to put in place so that came out from this postmortem, when I spoke to the PMs on the ground they said to me, "Well, okay, yes, we might need that end to end process but, Gerisha, right now we just don't know who to speak to. We would go speak to them, but we don't know who to talk to in this organisation. You know, who is even the product marketing or the marketing person that we should go to when we know that these things are happening?" Okay, well, there's different areas but also I'm saying besides marketing, well, you, you'd be surprised Phil, that's just one example. There's many other things that happen but there's also a whole bunch of stakeholders that when you're releasing a product you actually need to think about. You know, legal, compliance, risk, whoever, they often get forgotten. The people who deal with incident, oh my God, incident management, they often get forgotten in terms of alerting them to who needs to be spoken to, but anyway. So what I mean with this is that instead of going to that GTM end-to-end process, the beginning point was, "Well, can I just create a stakeholder guide, an internal stakeholder guide for the PM so they at least know who to speak to?" And that was step one, you know. So I think over engineering and going into too complex solutions when we need to like crawl, walk, run, fly. You need to start crawling first.

  - And there's also the stage of the company, right. I'm a big fan of just enough process, like, don't engineer your process for the multinational when you're a 10 person startup.

  - Yep, and it also relates to maturity. I'm saying maturity but I mean actual like, you know, product maturity and where you're at in terms of your- you know, like all of those factors play a part, but I use the term minimum viable process actually, so I said MVP but in terms of process. So what is the minimum viable process? Yeah.

  - I just avoid the MVP term generally because it's become the crappiest thing we can sell as opposed to the smallest thing to learn. It's just a phrase I chose to drop from my vocabulary a few years ago 'cause sales basically took it and turned and twisted it into something less useful in many cases.

  - Well, you just highlighted another problem that I often have to look into or try and solve in product operations, which is often this tension or this lack of trust or distrust sometimes between the product organisation and the sales organisation, right, these customer facing teams. We go off and speak to customers, there's roadmaps involved, all of these things, and then product, and so much of it is figuring out how do we get these teams to communicate better. That's a great example.

  - And there's a perfect segue into, I mean, we're a channel called Talking Roadmaps. What's Product Ops involvement with roadmapping?

  - You're catching me at a good time this week, I have got like three meetings talking about roadmap. It relates to tooling also, you know, to visibility or transparency and how we communicate the work that we do. My involvement with Roadmaps is thinking about, "Where do we keep them? In kind of what format do we show them? Like, how do we surface what the teams are doing or roll it up, often in terms of tying it to our OKRs," you know, companies, we have our objectives and key results and all of these things at the high level, but then teams are working day-to-day, you know, thinking about their backlogs and, you know, Jira, whatever it is. Their epics, their features, their releases. And so I'm currently looking at it in thinking about what level of granularity do we need to see from the teams? Where does everybody keep their roadmaps? Do they have roadmaps? And how do we then surface it at the right level for leadership, but then also internal stakeholders who need to see it to plan. So, like we were mentioning, product marketing or when we're doing go to market, they wanna see things ahead of time. And so in order to have like a now, next, later view, that would be super helpful for them.

  - You may even find the 14 different visual patterns we've identified in series one to be something interesting 'cause it's more than just a tabular view that you can find. In fact, my current personal favourite is a radar view because it breaks the left to right time horizon, makes people stop and read it a bit more to understand what it really means. And from a strategic roadmapping perspective or what's on our radar, you end up having the conversation, it can work quite powerfully. I also tend to drop them now, next, and later in favour of deliver, discover, and explore, because if you think about later your salespeople or even your senior leaders will say, "But that means you're not working on it." Whereas if you actually tell them, "Now I'm exploring that space, I'm understanding it," they're usually a lot happier.

  - Oh, I love that. That's a really nice way of framing it, also, when we think about delivery and discovery and also just... And you, again, great point Phil because one of the things I- whenever I've worked on roadmaps I always, not always but you sometimes get a little bit of hesitation from product managers around putting things on the roadmap, sometimes, because of this very thing of like, "Oh, are we gonna make it transparent? Is everybody gonna be able to see this?" But then sales is gonna go and take that and potentially sell it to a customer without having a conversation with me.

  - Yeah, I mean, to me, it's an alignment, communication, and storytelling tool. And the story part is very important for that communication and being able to- so I make sure there's a clear story behind your roadmap and, I mean, you know, we've done a bunch of work on, essentially we have a design sprint for the process and the actual artefact, the visualisation, the storytelling, all sorts of things. But product ops, you know, you're changing things over time. So if we're treating the function and the things you guys look after, like applying product practise, does that mean you need a roadmap for product ops?

  - I think so. You mean for like the work that we do? Yeah, definitely. I think I've had that like quite organised previously, I think in terms of like forward looking and having my backlog and thinking about what's coming up next, later, you know, or in your case, like discover, explore. But at the moment I am keeping track of it but just the now, which is, you know, almost like quarter by quarter, what is the work that we're doing? And then sort of an informal backlog of things that are potentially there for next, but we're not working on it yet because of capacity, because of priority. But, yeah, I think you have to be organised with that. And I think the other thing that it helps you with if you have a roadmap is when I speak to stakeholders, or I speak to people all the time who tell me their problems or their fires, which is great, but it's being able to say, "Well, these are the things that I'm looking at right now. Your stuff is there, but it's just not now," right, or, "I'm still in discovery or exploration with that." So important as a team also to just be able to say no, because product ops can often become like a catchall thing and you could say yes to everything, and then you get nothing done.

  - That's why often, from a strategic view, I have also a fourth column, never or trash.

  - Exactly. Never, not in scope, not touching that. Yeah.

  - So whose advice on product operations do you listen to?

  - I listen to the advice from all my guests. So one of my biggest sources of help is speaking to guests on my podcast, product operations podcast and learning, learning from them. And often I'll revisit episodes, you know, when I encounter something or I'll message one of the guests and say, "Hey, you know, I'm now looking at this in more detail. Can we unpack it and speak?" And then I guess maybe from those guests, some people to call out would be like Kevin Sakamoto who was actually a co-host with me on the last season of "Product Ops" podcast. He was a season one guest. I really value his opinion and also he comes from a product management background, and so I think we compliment each other very well so I can always get advice from a PM perspective on some of the things I'm doing. And then somebody called Kiara Gardner, who I'm sort of in an informal, I guess, group of product ops leaders, women who meet every two-ish weeks and chat about some of the challenges that we have, and because we're all kind of in leadership positions it's really helpful. And Kiara's one of them and I definitely tap into her and speak to her. And then I also follow maybe earlier on when I was trying to understand Product Ops better, I often looked at what Christine Itwaru was doing. I think maybe she was a guest on your podcast, Phil. Yeah, I've had her on my podcast twice, I really like Christine. So her thinking, especially in the early days when I was looking at product ops helped me. And also Blake Samick from Stripe and Uber and OpenAI. I just liked the way that he thought about it, it resonated with how I thought about it too. And so, yeah, those are some of the people that I speak to.

  - So I like to save, you know, the hardest two questions for the end. If you had to distil your philosophy on product operations down to one or two sentences, what would it be?

  - Yeah, I'd say two things. One thing immediately just popped into my mind with that. And it was something that one of my guests on the podcast mentioned to me, and it was just from a recent season so it's something, you know, new. And this guest, Shabnam Osman, she said this wonderful thing about product ops enabling momentum. I thought that was such a great way of thinking about it because, number one, I do already believe that this is an enabling function where a lot of what you're doing is trying to enable the organisation or people to be able to do things in a certain way. In a way, you don't wanna be there. You wanna take yourself out of the equation, but allow others and the company to run in the way that it has to. But that idea of momentum really stuck with me because you are trying to get the ball rolling when it comes to the things you're putting in place. Your success or product ops success depends on creating this momentum with the things that you're doing, and getting people to adopt it. And so I just thought that's a really interesting way of looking at it as a function that is enabling momentum within a company. And that kind of shows you that you're being successful, if you can get these things rolling and off the ground.

  - Love it. I think you said there was a second thought that came as well.

  - So the second, I think this maybe is more like definition specific, but if I think about how I've done product operations now startup, scale up, large corporate, three different times, having to set up and think about the definition and how you do it. I think that I always come back to that broad definition that I mentioned around alignment of an efficiency of scaling teams by looking at comms, processes, access to information, and tooling, number one. Number two, figure out the problems. Go to the problems, you have to understand what are the most critical and important problems of your leadership or the organisation. You have to distil those, maybe pick your top three. And then the third thing is approach it in a product-minded way. So almost like a bit of a blueprint or, you know, if I think about product ops, that's what I've done three times. And the definition changes a bit, the way you do your work changes but that helps you have value in product ops, by focusing on that.

  - So the hardest question, the Steve Blankism, is there anything else I should have asked you about product ops that I haven't?

  - Maybe like what's the hardest thing about the job. I think the hardest thing about the job is the number of like different dimensions to it, especially as a product operations leader. You're constantly flicking between the short-term solution and the long-term solution to these problems, right. Yes, there's this longer term thing but they need to fix now, "What are we gonna do in the interim?" And the other thing is the number of different hats you wear, you're constantly almost in a way context switching depending on who you're speaking to and, you know, what you're doing there. So it requires almost this highly strategic mindset, but you also have to be able to go extremely tactical on the ground, talking to people and knowing the detail of what there is. So I think it's almost like you're operating on all these different dimensions and with so many different stakeholders that it can be very, very draining. And I spoke to John Cutler about this and he was saying that, you know, he has, I think, a thing up on his wall which is like, you know, which hat is he wearing at the moment. Just to remind himself, like, in this meeting what kind of role is he playing there 'cause, you know, you could end up being like a therapist or an investigator or, like, whatever. It's so big and exhaustive. And then, yeah, it's really draining, so you you kind of also have to rest hard or figure out how to fill your cup up to keep going in a role like this.

  - So true and, interestingly, very close to also what it's like to do product management, I think. Which is probably why we find people with similar backgrounds or similar skillsets doing both. Interesting. So, well, Gerisha, it's been an absolute pleasure talking to you today. Always like to wrap up just with the opportunity to give your pitch, how people can get in touch with you, how they can help you, how they can be useful to you, or just maybe tell them about your podcast.

  - Yeah, especially as I did not include it in my introduction at the beginning. So, yes, I think probably just first of all if you wanna speak to me about anything related to product operations, find me on LinkedIn or send me a message. I'm not as good with responding to people 'cause it's just so busy at the moment in my current role. But I will try and get back to you, that's where you can find me. But also listen to "Product Ops" podcast. So I've been running it since 2021, I set it up because I did product operations sort of all on my own in the first startup that I was at, defining it, and I kept my head down in that role. I didn't really pick it up. I think a lot of people just are in their companies doing their job and forget that there's this whole community and other people doing the role that they can reach out to. And I ended up doing a talk at what was, I think, the first product operations summit. I was speaking to a void because it was virtual, I didn't know anybody was listening. And then after I ended that talk I had like 75 people message me on LinkedIn or send me requests, and it was just so many of them was like, "Oh my gosh, your talk resonated so much. I'm doing product ops, I'm facing these challenges." And so I wanted to spotlight those conversations to see if they could help other people, and so many of my first guests were people who came to me from, from listening to that talk. And so that's why I run it, to try and help share learnings, and also share diverse voices across this function. And so, yeah, you can listen to "Product Ops" podcast, there's four seasons, each one has a different theme. And season five is coming out this year. So, yeah, look out for that.

  - Gerisha, it's been an absolute pleasure having you here today. Thanks very much.

  - Thank you very much, Phil.