How to make product ops indispensable | Jonathan Sheffi

In Episode 22 of Talking Roadmaps, Phil Hornby interviews Jonathan Sheffi on How to make product ops indispensable. They unpack when product operations truly adds value, how it scales teams without turning into bureaucracy, and why treating product ops as an internal product is key. The conversation covers segmentation by product maturity, building trust with PMs and leaders, avoiding “process police” traps, and proving ROI through focus, insight, and enablement.

Jonathan is the VP of Strategy & Product Excellence for the Life Sciences & Healthcare division of Clarivate. Previously, he served as the first-ever Entrepreneur in Residence at Veeva Systems, a leading provider of SaaS to the life sciences industry, and was the product leader for life sciences at Google Cloud. He also cofounded Curoverse, which built an open source platform for managing and processing biomedical data (acquired by Veritas Genetics). His past leadership also includes roles with Novartis Diagnostics, Amgen, Accenture, and the Broad Institute. He holds an MBA from Harvard, and an MEng in computational molecular biology from MIT.

Here is an audio-only version if that’s your preferred medium - and you can access it through your favourite podcasting platform if you prefer (Apple, Spotify, Amazon).

In the next episode we have Matt LeMay, Product Leader, Coach, Advisor and Author. So watch out for this bonus episode!

• Transcript

  - As I talked, she was an outstanding product operations manager, she started to explain how she could run some of these programmes, how she could create a scalable way of managing a dozen partnerships we needed to launch, how we could plan the new version of the product launch, how we could plan that more effectively. And all of a sudden the light bulb turned on for me and I left the meeting having gone from, I started the meeting thinking, I don't know how I'm gonna work with product operations. I left the meeting thinking, this person's indispensable, and I'm not going anywhere without them.

  - Welcome to Talking Roadmaps season two. Today, I'm really pleased to be joined by Jonathan. Jonathan Sheffi from Clarivate. Jonathan, can you introduce yourself?

  - Happy to. And thanks so much for having me, Phil. My background is a mix of strategy, marketing, sales for life sciences early in my career. And then about a dozen or so years ago, I went into enterprise software for life sciences. I co-founded and sold a company in the genomic data management space. Then, ended up at Google Cloud where I was the product leader for life sciences. I then did some strategy work at a number of pharma SaaS companies before finding myself at Clarivate about two years ago, a little over two years ago now, leading the strategy team. And then about a year ago, taking over our product excellence function, which included product operations, user experience, partnerships, and pricing operations.

  - If you're enjoying the channel, subscribe, hit the bell and give us a like. Interesting. Yeah. And so obviously season two is all about product operations. We're diving into that subject. I think we're, you know, we're coming towards the end of the season now. We're gonna wrap it up at about 26 episodes is our goal. So, that's a year's worth of content for us. And we've had some great guests on from the likes of Melissa Perri in terms of the, should we say, the expert end of the spectrum, to also some great practitioners. Like, last week's episode that just went out as we're recording was from one of my colleagues at ZF, where I'm currently in-house, and where she's also got the title of head of excellence, interestingly enough, because product operations in a manufacturing company gets people very confused. So, excellence works really well in that function. I mean, I guess I'm just gonna go straight to it. Why does a company need product operations?

  - There's really three reasons why. First is about scale. As a product organisation grows, they get more products, more teams, more customers. The overhead of coordination, process, tooling becomes unmanageable for PMs and product operations provides that necessary scaffolding to scale across the entire portfolio. Product operations isn't really needed when you have only a couple of products. PMs can handle things themselves. But when you get to 10, 20, 30 products, or PMs, there's a scale problem. The second piece is around, I would call it efficiency and focus. So, taking what I call the non-core product activities. So that's, you know, process documentation, tool administration, owning the product tool stack, centralised reporting, especially for the executive team, taking all those things off of the PM's plate, which really allows them to focus on their high-value tasks. Discovery, solving customer problems, defining and solving user problems, and solving them for those stakeholders, the true core of product management. The third piece is what I call around insight and standardisation. So, building a single source of truth for all the product data. So, in our case, we own the Pendo stack for all of the products, and we make sure that Pendo is fully implemented in all of our products so that our PMs have a place to go no matter what product they're working on to get the product data they need. We help them implement metrics, experiments, and we help them standardise their processes. So, this is around launch checklists, managing their user research, and also reporting up to the executive team. So, that is meant to improve decision-making and consistency across the portfolio. So, a lot of those benefits are for the executive team, but also makes it easier for PMs to plug and play, especially when we have PMs who wanna grow in the organisation. It'd be nice if a PM can move from one product to another and kind of know how things are gonna work because their experience in one will be similar to their experience on another, because we've created a consistent environment for all of those PMs.

  - Yeah, I love that. And yeah, nice kind of way of thinking it. I mean, there's one that got me a little worried in there that felt a little bit like kind of doing a lot of the admin work as well. And I like that. I mean, I guess that could feed into some perceptions that other people have of product operations. What do other people think of product operations? What do they think it is and can that be problematic?

  - Absolutely. So, there's a lot of perceptions when people haven't had strong product ops experiences in their past, in their career. It can be easy to look at product operations managers as checklist experts or administrators or project managers. And when an organisation is looking at product ops that way, it's time for the product ops leadership to take a look in the mirror and say, why is that perception being created? Because that's not how we want to be seen. We wanna be seen as effective enablers of the business, effective enablers of our product team. And that's the time for us to start to have a conversation, to reach out to our executive team, reach out to our product leadership, reach out to the individual PMs as well, and say, how is this perception coming about? Are there things that we are doing that are creating that perception? And making sure that we're effectively designing our processes to support the PMs involved.

  - I think, interesting, one of the things you mentioned as part of kind of the third pillar, should we say, was the reporting up to leadership. Now, what I couldn't quite understand is whether you were saying the product operations take that reporting and do the reporting, or if they're creating the systems to enable the PMs to do that reporting. How do you see that working?

  - Sure, so, in our experience, certainly we do a lot of building processes that make it really easy for roadmaps to be built so that those can be easily collated, let's say, for sales, right? How do we create processes that make sure that the sales team, when it's comes time, right now, it's the beginning of a new year. Right around now we're doing our sales kickoff for the year. We need to make sure that our sales team is equipped with up up-to-date roadmaps that are for a sales audience and for a customer audience. That's the sort of thing that I look at, you could call that, I don't know if I'd call that reporting, per se, but it's certainly standardisation to make sure that each sales force, that we actually have multiple sales forces, each sales force has what they need to do their job, and we need to make sure that those things are brought together. So in this case, we are pulling all those things together on behalf of the PM team to sort of be that connective tissue between the product organisation and the go-to market teams. When it comes to executive perspective, our general managers and our executive team, they look at the roadmaps monthly. And so in that case, it's maybe a bit more about empowering the PMs to have those conversations, where we're helping them with the right tooling to build their roadmaps. And then when they're going into executive reviews, there's fewer things to reinvent. We're helping them keep them current, we're making sure that they have what they need to keep Jira up to date, things like that. So, sometimes it's about us doing some work on behalf of the PMs, like on the sales side, and sometimes it's about us empowering and equipping the PMs to do things that they're gonna do in their day-to-day.

  - I mean, because the thing, when I heard it, kind of that little concern for me and hence I wanted to probe it a little more, was because that time talking to the senior leaders I find super valuable as the PM, right? It's like that's when I get my real feedback from leadership and having those conversations. If they were being taken on by someone else, I'd be worried effectively as a product manager. Maybe also just because, you know, we're a bit of a megalomaniac. We like that access to power as well.

  - I think that product ops is not a place for people with big egos, I might say. It is about, we're meant to, if I borrow a phrase, sense and response to what the product teams are doing. We think of ourselves as owning a roadmap and for our own organisation, really understanding, hey, what are our PMs doing? And our executive team and our sales team and our marketing team and our engineering team. What's everyone doing and how do we look at what their needs are, the questions that they're trying to answer? Everyone's trying to answer a different set of questions. Our PMs are trying to answer questions about what's happening in their user analytics data, or other user research, or their financial data. How do we make sure that they have what they need? Our executive team wants to understand roadmaps, progress. Are we gonna be on time to deliver for certain launch dates? Are we gonna hit metrics? Our past launches, delivering on their promised business outcomes. Engineering teams have needs, to make sure that they understand what is it that we're gonna build. We see ourselves as responsible for helping glue all these pieces together across the different organisation. It's a highly cross-functional role, just as being a PM is, but it's a place where we have to basically, as a PM would observe users and try to come up with a solution that end users would value, we are trying to do the same thing except inside the organisation. We're looking at our end users, the PMs, the engineering teams, the marketing teams, the sales teams, the executive teams, and we're trying to watch them and say, what are the problems they're actually trying to solve? To make sure that we don't build too much and we don't build anything that people don't value and make use of. If we're really careful and thoughtful about that, we get the positive feedback. And when we're not, we don't. We've had it both ways. So, we've gotta get it right, and we've gotta be exceptional listeners, and humble ones. If we know that we're building something that people don't value, we need to stop.

  - I mean, yeah, that's, sometimes the phrase I've heard used is product management for product management, which is kind of what you just described there.

  - The analogy I like to use is, if PMs are building ships, then we are building the shipyard. We are creating the environment where they have all the tools at the ready. They know exactly where to go to get what they need to do. There's sort of no wasted movement around them. And if we're running our shipyard appropriately, in order to build a great shipyard, we have to be observing all these ship builders. We have to understand they're all building different kinds of ships for different purposes, but what do they have in common? And how do we create an environment where every PM can be maximally successful in this environment?

  - And so the problem is, that environment can be so variable, right? So, product management and product organisations, you know, it's probably the most variable role that I've come across in any organisation, which is actually what I love about it because no two days are the same. And that makes it interesting for me. I'm guessing that kind of follows through into product ops to some extent, so, how do we see different setups of product ops in different organisations?

  - Sure, so, I'll say even within one organisation, we have different needs and different setups. And this, actually, I think about as segmentation. The way we think about segmentation for a PM, I may have different products or different product lines for different sets of users and different customers. I think about product operations the exact same way. So, we're going through this right now. We have some products in our portfolio that are brand new. They have completely different needs. They haven't completely figured out their market yet. They really can't plan more than three to six months away because they know that the things that they're figuring out, they may throw away. What they're looking for is help with a little bit of road mapping. Not so much help with user analytics yet, a little bit, like, they want some, because some of their early versions, they wanna get some data on, but they're quickly looking at that and then pivoting. Compare that, we have products that are used by virtually every major pharmaceutical company and are very mature. We make improvements consistently, but their market's well-defined. They're doing well. They're sort of on a steady growth path. Those product managers have different needs. They are looking at analytics in a very different way. They're looking at it longitudinally. They're looking at, they're worried about churn. The early PMs, the early-stage products, those PMs are not worried about churn. The late-stage ones, the mature products, they think about churn all the time. How do we make sure that we're gonna be set up to renew? How do I get the right data from finance and others to make sure that our renewals are set up for success? I wanna do a different kind of coordination with the sales team. With the early-stage products, the PM may be the sales team. And so the types of collateral that they're building, the types of roadmaps they're building, are totally different. So, it's a great problem, but it's a thing that we have to think about in terms of what do we offer to one group and what do we offer to another group? I don't think about it as segmented so much by, oh, like, one business versus another. I think it's more about product stage and to some extent type of product. Like, we have some products that are purely data products and some that are software products, and those have slightly different needs. Some just involve engineering less than others. So, we need to build slightly different launch workflows. But regardless, I think the same principles apply of, how do we listen to each segment, identify clear segments, and then build a workflow for those segments?

  - So true, I mean, I'm just reflecting on my own experiences in the last few months. And there are four, I think sort of different products groups within the business I'm in. And I've got a very mature product. We are literally just re-platforming, like, we're mid-launch last migration onto the new re-platforming as we speak. And if I look across to the other team sat next to me, they're in the zero to one stage of this completely different product. And then their ways of working are completely different. We've got a long-term kind of like quarterly or two-monthly kind of planning cycle, where we've got a lot of stability and a large development team over here that's coming from multiple partners, in fact. Whereas they've got this tiny, move-fast product team, which has got like four or five engineers, or something in it. And maybe, I think, one designer. They're working through a Kanban-based model in terms of how they're delivering. And then there's a third team that's sat next to them that is kind of in that mid-market. They're kind of there, but they're really focused on growth now. They've launched, they've got a product, and they've got early traction, but they're really in growth and they're in more of a Scrum model. And one of the challenges senior leadership has had recently is how do I compare these teams and how they're performing and how they're doing? Because they're in this fundamentally different operational model that suits what they're doing, but then it's not comparable across the different parts of the organisation. Any thoughts?

  - Yeah, well, I think that you've laid it out well, and I think this goes to, how do we measure success in this type of a role? And also, how do you sort of justify it? How do you show that this role is needed and that will deliver ROI? I think, I'll start with sort of the end of one, and then scale it up. When I was a PM at Google, that was the first time I'd worked with a product operations manager and I was introduced by, my boss said, "Hey, I want you to meet this person. They're thinking about transferring into our team." And I said, "I don't really know what they would do. I don't get it. I don't know what this is about." And I had a one-on-one, her name was Sue. And Sue and I met, and we sat down for a one-on-one, and I said, "You know, honestly, I appreciate you meeting with me. I don't really know what you would do on this team." She said, "Okay, well, talk me through what you're working on." And so I unpacked everything I had going on and said, "Hey, I'm trying to do review of this. We have a launch that I'm trying to plan for several months out. I need to gather this and that data. Some other partnerships that we need to plan on getting executed." And as I talked, she was an outstanding product operations manager, she started to explain how she could run some of these programmes, how she could create a scalable way of managing a dozen partnerships we needed to launch, how we could plan the new version of the product launch, how we could plan that more effectively. And all of a sudden, the light bulb turned on for me. And I left the meeting having gone from, I started the meeting thinking, I don't know how I'm gonna work with product operations. I left the meeting thinking, this person's indispensable and I'm not going anywhere without them because I suddenly realised this was somebody who could help me get where I was going. I think that, so, to bring it back to your story and your conversation, product operations in some ways has to be all things to all people, because as you say, there are different teams that need different things, that are at different stages, et cetera. They have different problems. Some are heavily reliant on partnerships, some are not. Some are data products, some are not. Some are new, some are old. And I think that there's a need to look at, okay, what are the pieces, how do we understand every user really well and build, it's almost like a platform approach. What are all the pieces of workflows and modules and so on that we can build that when stitched together can address each possible need depending on the product, on the PM, how they work, what's the stage of their product, and so on. It's endlessly complex, but I find that the product mentality is the thing that I always find I come back to. It's how do we understand, we have a lot of different users. Some needs are similar, some are different, but it's our responsibility to understand our users' needs. It's our responsibility to understand the common themes between them. And it's our responsibility to develop a vision and a roadmap that gets them excited, that gets them to leave that meeting and say, "Gosh, I can't wait for all these things. I am so excited to engage with product operations. They've really understood my problems and what they're building for the organisation is gonna make my life a lot better." When we get to those moments, it's wonderful. It's one of the things that makes it all worthwhile. Just like being a PM and you see users excited, it's just the same for us.

  - Okay, and so you talked about listening a lot, but can we get a bit more concrete? How would you actually do that? Are we applying discovery techniques? Is it interviews? Are we looking at data? How are we understanding what those needs are?

  - So, there's nothing, as is with product management, there's nothing better than sitting down with your users. So that means, for us, we're sitting down with our PMs and we're trying to intensely understand, hey, where are you at in your stage? What are your priorities for this year? We're in 2026. What are your goals for 2026? Why? What are the questions you're trying to answer? Hey, you know, your boss, or the general manager of your area, what is the area? What are the questions that they always ask you? What are the problems that they create for you or the questions that they want you to answer for them? Tell us about that. And we're just listening. We're writing everything down. You can call it an audit, if you will. And we have to resist, just like every PM, we have to resist when one of our stakeholders says, "Just fill this, it'll solve my problem. I just need a report that says, you know, how many stories we got done in the past month," or something like that. And we say, and then we have to, it's so exciting when somebody tells us what to do, right? As product people. When we hear that, even in product operations, we have to take a deep breath and say, "I hear what you're saying. Can you tell me more about what problem that solves for you? Can you tell me more about what that's about?" "Oh, well, gosh, head of engineering has been asking about, you know, this, that and the other." And we say, "Okay, let me write that down." And we say, "Okay, what's the problem they're trying to solve," right? And a lot of this has to do with having enough access to senior leaders, as well. Because that's a lot of what the questions are, right? Yes, people are worried about their launches, we need to make sure they've got tooling for that, they've got access to their user data, things like that. But so many times, especially when we come to product operating models and processes, the things that people say are, "My boss, or my boss's boss, or my boss's boss's boss has a question. Solve that problem for me." And so we need to do a really good job of documenting those questions, and then as much as possible, going to the top and saying, first of all, validating, right? So, we say, "This ICPM told us that you have this question." And they're like, "Yeah, I do. That's sort of it, but it's actually more complicated. And this is sort of the bigger picture that it's fitting into. This is my real problem and my real question. And I'm really just worried about, you know, if we're getting consistent delivery, and you know, are we appropriately staffed in engineering and our content teams?" And, again, it's trying, it's getting back to the business, getting back to what's the business goals. And accessing senior leadership helps us a lot because when we can connect those dots, when the ICP, something that's filtered down to the ICP, do this, if we can go back to the source, and trace it all the way back to where did that request come from, sometimes that can be addressed in a way that the PM doesn't understand. It keeps us from either doing unnecessary work or solving the problem in a more elegant way.

  - Makes total sense. And I guess that would come to, you hinted it earlier and that kind of comes to it again, of justifying having product operations. Like, you mentioned ROI, how do we justify that it even exists?

  - It's a great question. I kind of talked earlier about how sometimes people have bad experiences, and that's when you get that question of, "Oh man, product operations, they're just the process police and they're just a pain in my butt." You know, one of the analogies I've heard is that people say, you know, "Product operations, it's like we pay a lot in taxes and we don't get much in government services," right? "They make us fill out all these templates and I don't even know why we're doing it. I don't know how it's helping us. I don't know why this advances the business. Why are these people doing this stuff?" And they haven't been able to justify their approach. And I think, so, part of this is, first of all, anytime we're making a request of the PMs, we have to be able to defend it is what I tell my people. I say, if a PM, just like anybody should be able to go to a PM in the company and say, "Why are we building this for our product?" Or, "Why are we shipping this?" And the PM should have a great answer based on data. We have the same responsibility. If a PM says to a product operations manager, "Why do you need this template?" I've seen this, and we are fixing it, but I've seen people on our team say, "Well, because an executive demanded it," which is basically the way of saying, "Because I said so." This is not effective and it destroys trust. So, what I've said is, if you can't answer on the face the business reason that we're doing this, just don't ask. You have to understand, because what it means is that if all you're doing is message passing and collecting some template on behalf of an executive, you haven't done the thinking. You haven't. What you should be doing is going back and talking to that executive and saying, "Help me understand the context. What's the problem you're trying to solve?" And when you have that context, maybe the request is perfectly valid, but at least now you can explain it to a PM and explain how it's gonna help them. Or maybe you'll learn something when you talk to that executive, that maybe what they want isn't what they need. And how much have we all had that experience in a product where what somebody says they want isn't what they need?

  - Yeah, I mean I've got the classic, now, I'm not saying this is a bad thing, but there's a demand at the moment for, you know, polishing the strategy, getting in better shape. But when we've dug behind the scenes, what it really comes down to is what big bets are we gonna make next year? It's not, they care about the strategies, like, what big bets that we think are gonna drive real revenue impact? That's what they want to know. Like, they don't care about the depth of the strategy, et cetera. It's like, but where do we wanna put our chips?

  - Yep, and I'll say that, again, how do you justify, there's a couple more things about that. So, first of all is, as we are doing the auditing, which is the thing we do all the time, it's uncovering the time that product managers spend on this non-core work, right? Data wrangling, chasing approvals, getting a launch fully approved so that it can go out and that product ops can hopefully reclaim, and then building some standardised processes. Like I said launch checklists, experimentation frameworks. So, we can point to, hey, we're freeing up the PMs to do more of what they're best at. And taking some of this work off their plate. I'll say one of the challenges that we have is we are in the process of moving what I think Marty Cagan calls a feature model to a product model. And we're going through this right now, and we've had some success, but it's a journey. And what that means is that some of our product managers historically have thought of themselves as project managers. They think of themselves as feature factories, what Melissa Perri would probably call escaping the build trap. As we start to reclaim some of that process work, it can be scary for the PMs. That's the other organisational risk. So, if there's other folks out there who are living this kind of journey, just be thoughtful in how you approach that. And one of the things you may have to do at the same time is redefine the product manager role to be more clearly about strategy, discovery, user insight, and not about project management. Because as product operations does their job, it will start to reclaim some of that work from the PMs.

  - Yeah, and I can imagine that also in some organisations will make the leaders feel threatened, as well. Because I know, for example, in my previous life, as the head of products, a lot of the ways of working, that sort of thing was something that I looked after, and maybe one of my team did a bit of it part-time as the PM. It was a part-time PM role, effectively, was to doing product ops because we didn't have it as a formalised separate function. And you can imagine some leaders that like shaping it feeling like they're losing something there. The argument should be that they can still shape, but not have to execute, I guess. But I can understand some being a little territorial.

  - It's a great point. In our organisation, thankfully, it's one of the risks we have not run into as much. So, our org is set up a little differently, right? So, I think I mentioned, under me as product operations, user experience, partnerships, pricing operations, and the strategy organisation. Our product managers themselves do not report into me. They report into our general managers. And we did that to enhance business alignment, that PMs would be forced to think about business outcomes in the organisation. The risk there is that the GMs start to imagine that they are PMs, and they're not. They're too far from the users, they're too far from the customers. Thankfully, our GMs for the most part are really good about being hands-off and being willing to be more bottom-up when it comes to product strategy. Which means of course it's now incumbent on the PMs to actually build convincing product roadmaps, convincing product visions. But you're right, it can be scary if there's an executive above who has their own concept of where a product should go. Thankfully, we've worked with our executive team and our GMs do a good job of laying off. So, we've avoided that so far. But it's a real risk for organisations that are set up that way, is you have senior people who are too far from the problem but don't know it.

  - And they probably have an opinion on how products should work even though they're not product people. And that's a common challenge I see. It's like, many people believe that they can do product work without having ever truly worked the craft, shall we say. It looks simple on the outside, and people, because we don't go to college or university to study it, we kind of come into it from other paths. People assume, "Well, I could just do that," as opposed to, when you've lived it, you suddenly realise there's a lot more to it.

  - Yes, and one of, so, I'll say that for other folks who are running into this situation where you have GMs who maybe have preconceived notions about what a PM is or don't even have any notions but don't know enough because they don't come from that discipline perhaps, one of the things I did when I came into this role about a year ago is I sent all of the GMs a copy of "Escape the Build Trap" and told them to read chapter six, seven, and nine, which if you haven't read the book, basically, it's like what are the prototypes of a good PM, a bad PM, and how do you build and align your product organisation, and what does a good product organisation look like? And it was great because it was clear, by the way, I highly recommend if you're ever gonna give a senior executive a book, highlight the chapters they should read first instead of waiting for them to read the whole book. Just made this much more effective. When I got the GMs to read those chapters, all of a sudden they understood. They had some sense in their head of what to look for from a good product manager and what were the sort of phenotypes of a good product manager, and what are the phenotypes of a bad product manager, and how to tell them what part. So, a little bit of training can go a long way if you have the buy-in and the trust of those execs.

  - Does phenotype not mean blood type?

  - Well, no. Phenotype means sort of like, what's the expression of a characteristic?

  - I was just thinking, has he just used blood type as an analogy for like an archetype? I was thinking it was an amusing possibly life sciences reference leaching in. If you had to kind of boil down best practise in product operations to something kind of punchy, what is it?

  - It is, as I've said a little bit up to now, about having that product mindset. So again, interviewing those stakeholders, defining problems, prototyping solutions, and measuring adoption and satisfaction. Actually, one of my things I wanna do in 2026 is measure our customer success team. We aren't doing that right now. Is our customer success team effectively understanding the products? Are they well supported in order to answer questions? Are they getting what they need from the PM team? I don't think we're doing enough to measure the success of our launches, not just for our external stakeholders, but for our customer success team. And so I'm partnering with our customer success VP to come up with a way of doing that, and I'm really excited about it. And then I would say the second piece is try not to do too much, right? It's the same problem that we see in regular product management. If you're over-engineering a solution, overbuilding because you're so responsive to every possible request, first of all, it gets expensive, harder to justify the ROI of, but people just hate it. People think that they're stuck in a bureaucracy. This is how people get stuck in saying, like I said, they're paying high taxes and not getting services. It's because we start to layer demand after demand after demand. And one of the things that we're doing this year is essentially resetting our product operating model in many ways where we're taking away a tonne of processes, and seeing, first of all, what people notice is missing. Obviously, we're telling them that these things are going away, but we're gonna see where the pain actually comes as we strip away a lot of our existing processes. And we're going to re-add some pieces, but we're gonna do it in a more thoughtful way where we're listening and only adding the things that are truly necessary, that truly drive business, and not going too far.

  - Yeah, I'm a great believer in just enough process for the stage and size of wherever we are right now. Like, too many people build for, I mean, I know Clarivate is a large mature company, but some people build for where they might be in 20 years today as opposed to building for where they are today, today. And that then just loads organisations down. Like, a lot of that comes, I find in particular, with scale-ups where they're looking at new people come in, and they look at the processes that are there right now, and they say, "Well, it's all broken, it doesn't work." It's like, yeah, because that process was designed for a year ago and we've now changed in that year, and we now need to fix that one to bring it up to where we are today. But we don't need to build it for five years time because we don't know where it'll be in five years time and what will be the right shape.

  - That's exactly right. And so we're working through interviewing our stakeholders and saying, "Okay, what are the right pieces that we need to add back in? What are the pieces that we need to preserve?" And being willing to get rid of stuff. And, let me tell you, my senior VP of engineering has never loved me more than when I said that we were about to get rid of a whole bunch of processes and see what actually is is necessary. They're very excited about funding a lot faster and having far fewer checklists in front of them.

  - I mean, even if it's a checklist, it's at least a lightweight way. I remember I was an ops manager many years ago kind of for a small company, and we went from having to have the meetings to, okay, we've got a checklist, if everything's already ticked, we don't need the meeting. Like, just simple heuristics like that took the process load through the floor, of saying, we know what we need to do. We don't need a gateway, because it was in the waterfall days. If we've already done everything, and we can just, and we've written down that we've done it, just something really simple. Because ultimately there is still quality management that we sometimes need to fulfil. And I like to find the nimblest way through a process possible, but sometimes you do have to do something right. But you started to hint at possibly the biggest mistakes. Are there any other mistakes that we come across in setting up product ops?

  - So, I've talked a little bit about being the process police. And this is just, again, creating processes and rules for the PMs without their input rather than working with them to really understand their workflow problems. We're not project managers. That's a big part of it. And if we find ourselves thinking of ourselves that way or other people thinking of us that way, then we're doing something wrong. I talked a little about over-engineering. I'd also say being sort of the PM cleanup crew. I don't like that either. Again, this is about, if PMs are just sort of throwing stuff at product operations and saying, "I don't like doing this," let's have a conversation. Let's understand whether that's truly appropriate for product operations to take on. Because product ops should have a really clear focus on how do we provide that connective tissue to the org, providing that data, providing the right operating model for products. I wanna make sure that we don't dilute our focus. And that gets, it's already challenging enough, as we talked about. Many different products to serve, many different product lifecycle stages to serve. How do we make sure that we stay focused? So, I think that's a big pitfall, or sort of sand trap to fall into.

  - Sounds like similar problems to what we have as PMs then. Because we can fall into that same sand trap, right? But I guess if we're product managing the product management, then that's gonna be a natural risk. So, okay, as we start to kind of bring ourselves to a close, Jonathan, whose advice on product operations do you listen to? You've already mentioned Melissa Perri. Anybody else we'd put on that list?

  - So, I mentioned Melissa Perri, her work has been really instrumental. Denise Tilles has literally written the book on product operations and has really defined it. Also, Marty Cagan, who I think everyone knows "Inspired" and "Empowered" and how important those books are for ICPMs and manager PMs. His book "Transformed," which came out, I think around two years ago-ish, is I think a must-read for product operations leaders. How do we think about operating models? How do we make sure that product operating models are set up for success? A lot of what I'm talking about here is, to be perfectly honest, highly influenced by the book "Transformed." So, I definitely recommend that book as well, in addition to Denise's and Melissa's.

  - Awesome. Yeah. I was lucky enough to be part of the coaches group that Marty brought together where he was testing that material about a year earlier, as well. So, I also very much recommend it, although it's really targeted at those leaders that you've got that need to understand what the heck product ops and a product operating model is gonna do for the your organisation to then get out of the way, to get those GMs on board that we talked about earlier. Sometimes product managers find it a hard read because it's like, "But this is stuff I've already covered." But it's because it's trying to get the point, the message into that leadership head, to get them to understand and get out of our way. I always like to save one of my hardest questions to near the end. If you had to distil your philosophy on product operations into one or two sentences, Jonathan, what would it be?

  - Treat your product operating model like a product with its own roadmap. Interview your stakeholders, bring together a vision for how products are built and brought to the market in the company, and commit to releases, which can be tools or processes. If you do that and you're serious about it, you can't go wrong.

  - I absolutely love that. So, I always have to bring my Steve Blank-ism in towards the end. What should I have asked you about product operations that I haven't?

  - I am really excited about how gen AI is going to change the discipline of product management, and I think that product operations is in a really special place to observe and leverage AI in the discipline of product management. I was meeting with someone recently who said, "Hey, can Jira write our user stories? I said, "I don't know, maybe Jira can write our user stories. Like, let's find out." And so we're starting to pilot a variety of technologies in product to say, okay, what are ways that we can accelerate delivery? Accelerate discovery, as well. We're already using tools to summarise our notes and create low-fidelity mocks with the UX team. But I don't know exactly where the future of product goes with it, like where the product discipline goes with the advent of AI. But I'm really excited about it. And I think there's a debate out there about how much gen AI shifts the expectation of product management to do more delivery. I think there's a, should PMs themselves be opening up Figma Make and doing those first draught mocks, or should they be working with UX still? Is it more efficient for them to just be in a conversation, a rapid set of conversations with customers, and just doing things, you know, building mocks themselves or not? Is that efficiency in communication or is that a waste of their skills? I don't think we know yet. We're still figuring out that balance of, now that PMs can do a little bit more of the initial delivery work, with mocks, with vibe coding, how much should they? Or should they really stick to their core of discovery and strategy work? And we're actively wrestling with that question. And I'll let you know when we have an answer.

  - So, I mean, I personally use AI a tonne, because, but the thing that took me a while to get my head around but is now the superpower is voice mode. Just talk to it. Have a conversation. Like, I don't actually write user stories anymore directly. I have a conversation with my AI, dumping all my ideas together. I tell it what structure I want my document to come out in. I tell it kind of what voice, I tell it all about my voice, how I speak. So the documents that come out sound just like I wrote them actually, but they take a quarter of the time. If I'm sitting in the car, I'm usually chatting to my AI, just talking about what's going on, what's happening today, what I've got on my plate, and helping it structure my day or the one-pager I'm writing, that sort of thing. And then, boom, I've got the actual artefact that I can share that communicates really well, but it's still all the content coming from me. It's just helping me structure it in a better way. And I mean, you talked about vibe coding, and things like that. As long as you treat that to me as a discovery artefact, it's therefore talking to customers and facilitating the conversation with the designer to do the real thing, I think it speeds up the conversation. But I think there's still, the disciplinary design is still needed to do properly. This is where I tend to land personally.

  - No, I think it's absolutely right. If we're talking about things like, and I just kind of take it for granted, things like helping me get a PRD written much faster, helping me, and I agree, it's things like vibe coding and mocks. If it's enabling a tight loop with the customer, or with the user, I don't think anyone can argue that that's not incredibly valuable, instead of trying to set up an additional meeting and slowing us down. I worry in org, where, and I think this gets to, again, making sure you're not in a feature factory. If you get to, this is I think where I see risk, is if the PM thinks of themselves as really a project manager who just gets features out the door, they may say, "Great. Hey, designer, I've already done like half the work for you. Just make this pretty and ship it." That is the thing I'm terrified of. And so this requires staying super disciplined, that this is about discovery, that you're really trying to get strong validation. And if we don't strongly validate it, basically, I guess I'll think about it this way. AI will let you do the right thing faster and the wrong thing faster. And so if we are not really careful about making sure that we're still using discovery for true market and user validation, we will just shift the wrong thing faster.

  - And what I also recognise is, it can make the wrong thing look like it's done really well and make it look really attractive, and make it harder to tell the wrong and the right things apart, as well. It makes it so much more polished, which is definitely a challenge. Jonathan, it's been an absolute pleasure chatting today. There's so many things we've unpacked. I can't wait to get this out to our listeners to share and get their comments coming in. All that remains really is for me to just give you the stage if there's any pitch you'd like to give about yourself, Clarivate, how people can get in touch, how they could be helpful for you.

  - Thanks a lot, Phil. It was an absolute pleasure to be here. For listeners who are in the pharmaceutical or medical device industry, you've probably heard of us, or perhaps our brands Cortellis and DRG. And we're always excited about improving our portfolio of data and software to keep up with the most exciting time in technology. And we're excited to work with you. We're also always looking for exceptional product talent. And while having a life sciences background is helpful, it's by no means required. We can definitely teach you about life sciences. We're looking for people who are strong product managers that wanna work in an industry where you get to make a difference in human lives. And we're making, and if I'm doing my job, we're making Clarivate a better and better place to be a product manager this year.

  - Thanks again, Jonathan.

  - Thank you so much. A real pleasure.