Does product operations enable value creation? | Melissa Perri

In Episode 12 of Talking Roadmaps, Justin Woods interviews Melissa Perri on the true role of product operations in enabling value creation. Melissa dives deep into the three pillars of product ops—data, research, and process—explaining how they connect strategy to execution and empower both teams and executives. Learn how orgs can scale, standardize, and truly support product managers.

Melissa Perri is a strategic advisor, author, and board member that works with leaders at Fortune 500 companies and SAAS scale ups to enable growth through building impactful product strategies and organizations. In 2018, she wrote the industry-acclaimed book "Escaping the Build Trap", and in 2023, she co-wrote “Product Operations”, the definitive guide on the subject. Currently, Melissa is the CEO and founder of Produx Labs, which offers e-learning for product people through Product Institute and CPO Accelerator. She is as a board advisor for Labster and Dragonboat, and a former board member of Forsta (acquired by Press Ganey in 2022). In 2019, Melissa was appointed to the faculty of Harvard Business School to teach Product Management in the MBA program. She has consulted with dozens of companies to transform their product organizations, including Insight Partners, Capital One, Vanguard, Walmart/Sam's Club. In her free time, you can find her trying to finish her house renovations before something else breaks.

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 product operations enable value creation? | Melissa Perri

Melissa Perri and Justin Woods

The next episode is a special bonus, we are talking to Nesrine Changuel, Author of Product Delight and Founder @ Product Excellence. So watch out for this bonus episode!

• Transcript

  - Even if we start with the process side, we're not trying to end with the process side, right? We're doing it in service of being able to move on to bigger and better things, and sometimes that's just what we need to do first.

  - Welcome, everybody, to the "Talking Roadmaps" channel. In Series 2, we're talking product operations, and today's special guest is very much centre of that. Melissa, I couldn't be more excited to speak with you, but I don't wanna do a really bad job introducing you, so maybe you can tell our audience who you are, and what it is that you do.

  - Sure, I'm excited to be here, Justin. So I'm Melissa. I really help organisations set up their product operating models, and build great product managers and product leaders. So everything that I do, I try to do at scale. I run a company that's called Product Institute, and we usually get called into organisations that are trying to figure out what their product operating model is. So I might go in, do a little bit of an assessment, work with the executive team to explain what great product management looks like, or understand what parts of the organisation need help, whether it's, you know, defining roles, or getting the right talent upskilled, setting their product strategies, setting up product operations is a big part of that, and then looking at their culture. And then, typically, I'll advise executives around that transformation. Be the brainstorming partner to help implement those things, give them tactical advice on the roadmaps to actually get that change management going, and then we upskill people through Product Institute with our online training. So we have courses in product management foundations, and product strategy, and all the stuff around that. So we kind of go into organisations, help get people up to speed on what good looks like, and then we try to assist them in helping the executives build the system around them, so that they can succeed.

  - If you're enjoying the channel, subscribe, hit the bell icon, and give us a like. So important, and the product operations element of that, making it lasting.

  - Exactly, and that's been a big thing, I think, looking at my career and like the history of doing it, I very much started out when I was consulting standing teams. So I went in and I would train teams in Product Institute, introduce them to product management foundations, teach them how they should be experimenting, and working with developers and designers to roll things out and measuring success. And then what I found was I'd train all these teams and they'd like hit a wall. So they'd be like, "I'm ready to go, this is fantastic." And then the organisation wasn't really set up for them to succeed. So that's where I would start moving into things like product operations, what's the foundations we need, so that everybody can go do their job well? And if I'm telling them like they're measuring success, what tools are they using to actually measure it? Do we have that data? Are we actually tracking it? So there is the product operation pieces there, and then there's the educating the leadership as well, so that they can understand what they need to do to enable the teams.

  - Yeah, it makes sense. And I can see from your career history and your experience everything that's led you to this point, and, now, providing a platform where you can have the greatest influence to help people. You know, I'm a big fan of the books that you've written, and the information that you have on online. They've been, you know, certainly pivotal helping me. And so it's just like how can we understand this, and then how can we share this knowledge, so that most people can benefit?

  - Exactly, and that's what I've really been focusing on. I used to go super deep into consulting, and working with like one company, two companies at a time, where I'd get in there, and I'd basically be the person who would do the change management. I was pretty much the head of product operations, or the interim CPO, who was rolling this all out. And I did that for quite a while. But what happens is like if I leave as a consultant, who's there to keep it going? And that's why I really try to take more of an enablement perch, so I can help many companies at once, but also so that there is somebody there who's very knowledgeable, who can take that over, and keep running with it, and make sure that it just doesn't fall by the wayside.

  - Makes absolute sense. So let's maybe put the focus onto product operations, as we've mentioned that. I guess maybe we could start with what is the purpose of product operations?

  - The purpose of product operations is really to be the enablement around the product management team, so that they can do their jobs well. And that really comes back to can we define great product strategies? And then can we execute on them? And then how do we monitor it to make sure that we're going back and doing the right things? And then we know how to change course. So when I look at product operations, it's 100% enablement function. It's surrounding the product management team with the tools that they need, the processes, the capabilities, the data, and kind of the culture as well, right, to be able to have a product operating model that works really well to deliver value. So it's kinda optimising that value chain, and making sure that we can get our jobs done, focus on our customers, really focus on that value piece, and get that out the door to them as fast as possible.

  - Nice, yeah, that's a great answer. Makes a lot of sense. And I feel like product operations has been, if not done by name, done by its very function and purpose for way longer than we've talked about it.

  - Yeah, big time. And, you know, we were just talking about, you were doing product operations, and it may not have been called that, but that's what I found. And when I look around at teams, and I ask people, you know, "What's your biggest struggle?" Or, you know, "What's not working here?" I kept coming into these organisations, and everybody was complaining they didn't have time to do their function. And when you look at why don't you have time to do product management, like, "Oh, I don't have time to talk to the users. I don't have time to do this, 'cause blah, blah, blah, blah." Reinventing the wheel of all these things in product operations off the side of their desk to get things done. So, in many large organisations, and even smaller organisations, you know, there might be 7,000 different forms of roadmaps. There might be 18 different data repositories that hold the same thing, and then none of the data actually matches up. So how do you set strategy off that? So there's all of these kind of inefficiencies across the organisation that kind of prevent the product managers from just focusing on what they need to do, which is understanding their customers, really understand that value, making sure it makes sense, you know, viably for the business, working with their engineers, and designers, and the business teams to make sure that we're crafting really good products for our customers. And, instead, they're doing like all of these, they're creating templates, and they're like, "What's the best template to use?" And it's like, "That's not where your job should be focused, right? It's about what goes into the template, like how do you do the analysis to get stuff in there?"

  - Absolutely, and I think what you've started to describe is why companies need product operations. There's a lot of inefficiencies. There's a lot of challenges. You've mentioned some of them, how would you round out that question there? Why do companies need product operations?

  - I look at it in like the three pillars of product operations, and how they all come back to informing strategy, helping you set strategy, execute on it, monitor it. So one pillar of product operations, we talk about data and insights. So that's really the quantitative data that lives within your systems. And, in so many organisations, it's all siloed up into many different things, right? We've got tonnes of great win-loss analysis, and data in a sales system. We've got our product analytics, you know, locked up in an analytics tool. We've got our, you know, data uptime and stuff like that locked up in developer tools. So everything is siloed across the organisation. And when a product manager needs to go and start to measure success and evaluate it, like where do you know to go to pull that information out? So I think our like biggest hurdle in the past used to be I need the data, like I am not even instrumented for data, and some companies are still there. But, now, a lot of it's instrumented, and it's just all over the place, right? Like there's so much data, it's so siloed all over the place, that you're trying to figure out how do I put this into a picture that makes sense for us, right? So with that pillar of product operations, what we're really looking at is how do we aggregate data across the systems in a way that makes sense for product managers to actually measure it. So it's not just about product analytics. Like I also need to know my customer segmentation, I need to know like win-loss data from sales, I need to know... This connects back to the financials, right? I need to be able to tie all of this stuff together, and if it's all separated, or not even being measured at all, I need to put that in first. So product operations really looks at how do we get data into the hands of product managers that's valuable for them. And there's a piece of that as well about self-serving. So like what tools are we using, so that they can go in, and start to query the data, understand it a little bit better, and then make their own reports or make their own analysis for it? So, in some teams, we have geared the data and insights, you might be working with the data team, it's not just about setting it up yourself, but it's like that liaison that goes to the data team, and like advocates for the product managers. So it's like, "Hey guys, you're building data for the sake of engineering really, like let's bring this over here." Whereas going up to the sales op teams, saying like, "Hey, a lot of this stuff is relevant for us too. Can we API into it, pull it into this aggregation, so that we can start looking at it, and we know, ahead of time, like what you guys are gonna ask for from sales?" And you're building those bridges across the organisation to kind of centralise that, so that you can look at your analysis, and keep track of it, and do your dashboards and all of that stuff, so we keep the pulse. So that's like one piece of helping to inform strategy, and monitor it as well. Then there's the qualitative aspect, which is the customer and market research. And this aspect is not about taking away the responsibility of doing that, but how do you enable product managers with the right tools and frameworks to go do that? So, in many organisations, it kind of looks like, in the customer side too, I would say, there are research ops, so if you have a research ops team, this is what they do. I would just work with them to make sure like this is working out. But if you don't have a research ops team, you're gonna wanna go in there, and say, "How do we make it easy to get in touch with our customers? How do we make it easy to test with our customers? Do we have like, you know, ways that we can go out, and do beta testing with them? Groups of this, advisory boards?" How do we make sure people are not contacting the same customer over, and over, and over again? 'Cause they know that they'll say yes, which was a big issue that we had in many places that I worked at. And then, in really large organisations too, like banks, for example, this could also be the function that helps define the requirements and the compliance around going to talk to customers. So they're making sure that people who are talking to customers are doing it in the right way, doing it in a compliant way, they have many modes of doing research that they can offer to people based on the risk. So it's that type of system that sets it up, so that the product managers can go talk to customers, and they're unlocked there. So all that recruiting piece, all of those things, get more standardised, more efficient. And I usually suggest this is also about you automate some of that stuff, right? How do you do the work to set it up, so it's not a burden to go do customer research? And then, on the flip side, once you do that customer research, how do you aggregate data and information and then bring it back to the team, so it just doesn't get lost? So many teams go out, do customer research, and then it lives in a Google doc, or a Word doc, or something, and nobody sees it again. So I'm really excited about AI here, because there's so many tools popping up, where they're taking a lot of that qualitative information, putting it into big databases, and now you can start to query for insights, see, you know, who's done an interview on something similar, watch the interviews, be pointed in the right direction. And that's a huge part of this, and that makes me so excited, 'cause that wasn't around like six years ago when I was dumping things out of like 18 Google Drives, and stuff, and going through it.

  - Had to become an inadvertent MongoDB expert, right, just earlier on in your career, to try and find this.

  - Yeah, so when I like started out, we used MongoDB very early at OpenSky. We actually like were across the street from the MongoDB office, which was kind of funny, and some of our people had left and gone to MongoDB, so we had like a really close relationship. But I had to go take a class on it just to get any of the information out of the systems, because, otherwise, I'm bothering the engineers all the time and I wanted to track it, I wanted to measure stuff, and it took like a very long time to take that class. And I'm going, "I have got so much other work to do." I do think it's important to get the data, and I had to get the data, but I also was like, "Was it the best use of my time to spend the last 50 hours learning MongoDB?" Probably not, right? So that's like very much what we're trying to do in product operations is like take that work away, and automate it as much as possible, and just give people the tools to go do it. And then that's like the last part of the pillar as well, which is the system governance. And that's probably the most controversial for people. But this is where like tooling lives, a product operating model from like a process perspective lives. What do we do here? Like if we're in this company, it's about how you adapt it, so that nobody has to go learn how to make a roadmap five times as they change teams, right? And that's how I would look at it. It's not about burdensome process, it's about there are certain ways of working and certain ways that we name strategy, for example, certain canvases we use, certain templates we use. When are we gonna standardise to make ourselves all work better together, so that we can all understand what we're working on as well? You know, what are the tools we're gonna use to do that, and surface up that information, and how do we codify that? So that helps build out this product operating model, and helps say like, "This is the way that we're gonna do it here, and this is what it means for our company." So that's the last piece of product operations is really codifying the things that matter there, and then helping to get those tools, and those resources, and those templates and stuff out to the team, so that they know to use it, and everybody's kind of working consistently in the ways that will make a difference.

  - I love that you said that. Codify really resonates with me. I work with clients to kind of create their standard operating procedures around these things. But that's lit a bulb in my mind around often a misconception about product operations is that it's a process-type thing. I think, you know, many people in our sphere have criticised it sometimes as well, and that's not the case, right? What you've said is there's three different pillars to this. And what would your response be to people that might say that product operations is just unneeded process?

  - I think it comes from people working in, so that mostly comes from people watching how large organisations work. And I work with the largest banks in the world. And what happens to that is that, in some of those companies, when you come in, and you're saying like, "What do you need to just get this much better today?" Some of it might be process related, so that might be where they're starting, but not where they're ending, right? And I think it starts to get a bad rap, because we see a lot of people focusing on process first. And I do think it's gonna be worrisome if we just stay there. So like my job is to push them, and say, "This is not the end all be all, right? Like you're not just process people, you are product managers for product managers, right? And you might need to automate or templatize some stuff, because it's going to help you with the biggest burning issue right now. But then, next, I need you to go like look at the data stuff, I need you to go look at this other stuff." So I think there's like a lot of pushback, because people are worried about the stigma, especially with like agile coaches, and stuff like that, but if you look at any other role like sales ops standardises sales operating procedures. Like if you think a multi-billion dollar organisation that is doing like enterprise sales doesn't have a process for it, like you're kidding yourself. Like they are probably super rigid in their process, and they have a way to qualify leads to like define these things, they have metrics around it. Like that's kind of what we're talking about. So the idea with it is that, even if we start with the process side, we're not trying to end with the process side, right? We're doing it in service of being able to move on to bigger and better things, and sometimes that's just what we need to do first.

  - Yeah, that's such a great response. I love that. One of the questions I ask our guests is often how they see product operations set up across different organisations. We know that sometimes it can be part of somebody's job, or it can be an entire function. We also know that, sometimes, it can fit within product management, but, actually, it can report into different reporting lines. The slight difference on that question I'm gonna ask you is how have you seen product operations set up the best? When has it been set up to be the most successful?

  - Yeah, it depends the size of the company. So like let's take smaller scale-up companies at first, right? You might have a chief product officer, or a VP of product, with a head of product operations reporting into you. That might not be a VP, it might be a director, it might be just one product operations person to start, but let's say like we scaled it a little bit. We've got a small SWAT team of people who are basically like viewed as the platform, or internal tools team, for the product managers. And what they're doing is they're going out analysing what the product managers need, they're the customers, right, to work better, and then they are creating either, you know, a process, or an automation, or a tooling, or a platform approach right around it. So they are really looking at like all these aspects we've talked about, and then they're kind of building products for the product managers. So that's how they're looking at it. And I think reporting into the product role is very important for it, but we usually have a dotted line where these people will go work with other ops roles. So they're probably working with DevOps, or working with sales ops, you know, they are not just siloed, where they're doing this all by themselves, but they should be in data, they're working with data, they should be working across the organisation, and kind of building those bridges to make sure that we're not just reinventing the wheel. And I'm like, "If it's already been done before, like don't do it, right?" Just find out where it is, and maybe we have to tweak it just so product managers could do it, right, or use it, or make it a little bit more useful for them. That's fine. So they need to take that approach of like how do we scale it? Larger organisations usually have a bigger team of product management, not product management, product ops, but the product ops should cut across all of product management. So this is where I also think it is a function, even in like a super-large enterprise, underneath the chief product officer. And then this team might be much bigger, you probably have a VP there, but these people are looking at how we standardise it across the entire enterprise organisation, so that if you have different product lines, you're not just reinventing the wheel in each, and if you ever have to go across team, or platform, or anything like that, you don't have a whole new way of working with all of these different teams too. So I've seen teams set them up that way. They usually have a little more definition in the type of work that people will do. Like, in a scale-up organisation, you might have, you know, a couple product ops people. Usually, they're a little more oriented towards like let's say data, and the market research, and the customer research parts of it, like gathering the information, making sense out of it, doing the tools. They're doing a little bit of standardisation too with the frameworks. But, in the larger organisations, usually, 'cause just by nature of what they're doing, like if they're on a transformation journey, they're gonna be starting with like some of the basics, like we need to do operating models between us and, you know, other teams, we need like a product operating model, we need a roadmap tool, like some basic stuff to like set it up and get it going. And, hopefully, that's not where they end up at the end of the day, but it is the first way to do it. And they're servicing, usually, you know, I've seen teams of like 1,000 product managers, so like it's not a small group of people these people are actually servicing. It's a huge group. And there's a huge change management aspect usually involved in organisations that do transformations that the product ops people are taking on. So they are responsible for a lot of this change management, introducing stuff to the organisation. Whereas, in a scale-up, it'll be a little bit of that, but it's easier to adopt at smaller people, let's say.

  - Yeah, that makes sense. And I think that's how I've found product operations myself, as a consultant, is that, even though I've got the bias on the tooling side of things, I'm often brought in as the tooling aspect of a transformation. And so, then, you're starting to go, "Okay, well, let's understand the tooling needs to underpin the process. What is the process?" And so it is another way into that transformation journey, or that product operations journey. And, actually, that maybe opens up a question of how do you justify having product ops? You know, from being involved in it myself, and, obviously, you've built a huge part of your career around this. Many of our listeners will be thinking, "Well, Melissa, that sounds great, but how do I get started?" What would you say to them? How do you justify having product operations?

  - The one part I have not mentioned of this, that's probably the absolute key to get into here is that product operations isn't just servicing product managers, but also executives. So the biggest question I get from executives, especially in really large organisations, is that, "How do I actually connect all the stuff my teams are doing back to what it's gonna do for the business, right? That investment. I'm investing, I'm spending millions, and millions, and millions of dollars over here on tech. What do I get from it?" And answering that question is extremely hard, but that's where like product ops can help. So what we typically do is, if you were trying to justify it or do it, we would say, "Demonstrate it." So start by helping the executives get the transparency that they need into what people are doing, right? And not just like a monitor thing, but like what are they achieving, so that they can go do their jobs more effectively, set the strategy that we actually need, and then, once they see that value, they go, "Oh, okay, I understand like what this is supposed to do. Like yeah, we want more of this." That's usually like the best inroads way to do it. There are like baby steps that you can take to do it. Whenever I come into an organisation, they say, "Hey, I do not know how to connect this business value like back to my investment." I'll say, "Okay, you know, where's the team's roadmaps?" And this might sound like super basic, but like they don't exist, or they exist in different tools, or they exist in a tool, and everybody has dumped stuff in it that's in crazy different levels, right? It's like a story, and then like something ridiculously high, and like, "Fix my API bug," right? And nothing is codified in a way where you can go, "All of this stuff is like about customer retention, and by doing X, Y, and Z, we believe that we can increase customer retention in this segment by 20% by the end of the year," right? So there's no connection on it, but we also can't even draw a line around this group of stuff is supposed to do this. So that's also where, of course, OKRs and stuff like that come in, but, if you can't even scope it correctly at that level, you can't bubble it up to the next level. So there's a bunch of work in there to just like reconcile that, bring transparency, but when you bump it up to that level from the teams, and then you can roll it into initiatives for the executives, it's that portfolio-level piece where you say, "Hey, these initiatives are tied back to these company goals and here's what we're thinking time-wise, here's the progress towards them, here's what's at risk." That insight that they get there, they go, "Oh, wow, that's amazing. Okay, so I'm spending like 20% of my investment over here on this initiative, and that's actually not something that we have prioritised at all. Like why are we doing that?" And it's just like a disconnection from strategy, and that happens everywhere. Like it's not a abnormal thing, right? Like everywhere has problems like that, and it's just about getting the stuff surfaced up to see it. So that's a big part, I think, of the inroads to product ops. And every time I've come in and shown that in organisations, they're like, "Oh, okay, I get it." And I'm like, "Yeah, so, now, to do this well, right, we have to do X, Y, and Z, and your product ops teams will be doing this, and, now, they're gonna make sure that, to set the goals that you wanna see, to roll this up, the teams have the right data. Okay, so now we gotta go do some data stuff. Oh, you're not sure that we should be doing this." How do they validate it? Let's look at our experimentation toolkits. How are they actually going about this? So starting from the executive level, and trying to provide them into transparency of what's going on, kind of unlocks you to go do the other stuff that you need to work with the team.

  - I was gonna say, it's no wonder we've seen this, you know, meteoric rise of product operations when you are demonstrating value to the executives. I mean, it's no surprise, right? The people you're demonstrating what matters most to the people that need to see it most. And so it's great to see that. It's almost an unfair advantage, I think, having product operations do that, because they have this product management mindset, they know what value to stakeholders, or customers, or users looks like. And so we've got that in our back pocket. I wonder if, and, again, this isn't a question I planned to ask you, but people coming to product operations, you might think, "Oh, it's product managers turning to product operations." But I wonder if some of the best product operations people have come from roles completely outside of product management. What have you seen?

  - Big time. Like I've seen a lot of people transition from product management come into product ops for a while. I think it's a good path too if you're like on a leadership track, and you're trying to get broad experience on how to run like a team, let's say, or build an organisation. So I've seen people who've gone up to like director of product roles, maybe a VP, and then they kind of pivot into doing product operations, and it works very well for them if they have this operational mindset, 'cause now they have to make sure the thing works across scale, right? So that kind of rounds out your experience if you've been very heavy on the strategy side, which is fine. But that's about like, "How do I scale my team? How do I keep going?" But I have met tonnes of product ops people who are more just from operational backgrounds, and they've got this product manager problem-solving mindset, but they might not solve everything through software, which is okay, it might be solved through process, it might be solved through different automations, and things like that. And they're not so precious about it all being in like custom software or anything like that, they're out there exploring tools, or exploring different things. So it's worked really well for people with that. I think like operational backgrounds, people who love automating things, people love problem-solving in that way, and you can think about systems really thrive in a product operations role. So I don't think it needs to necessarily be a product management person, but I do think it helps. If you're hiring like, let's say, a VP director, like they should have pretty good experience with product management. They don't have to be a product manager, but they should have been working with those teams, they know how it works like there's a lot scope there. But if you're hiring more junior people onto it, and they can learn, I'd look for people with those problem-solving mindsets, help introduce them to it. I might not put them around the process-related stuff first, right, but I would put them around things like data, and things like, you know, operationalizing like our tools, and like how do we think about the cadences for our product strategy meeting? And they're usually working with the person who's the subject-matter expert, which is the chief product officer, or the VP of product, to take those things and then operationalize them. Which is actually interesting if I think about it. I've never explained it that way before, but we always talk about subject-matter expertise versus product management expertise in like product management, and I'm always the one who says, "Hey, if you have a bunch of subject-matter experts, and this person's willing to learn, like hire that person if they've got the attributes and the skills necessary, they can go learn from a subject matter expert." It's similar in product ops, where you have the operationalizing experience, you've got that change management experience, you've got that like analytical thinking and the system thinking around it, your subject-matter experts are the product managers on how they wanna do the process. So if you have somebody there who is great at that, then you can tap into them.

  - Yeah, nice. They've almost got this kind of the different pillars that you describe of product operations. You've just got different people specialising in that area, and I think that's, actually, I'm working with a large airline at the moment, and forming part of that team, and I think that's what we've found there as well. There's some people who are specialising into roadmapping and dashboards, other people specialising into the process side of things, other people into the tooling administration. And so it is great that you've explained it that way, and it kind of reinforces our approach as well into that.

  - Yeah, no, a lot of people are like, "Well, then there's not just one role for it." But if you think about product management, if I'm gonna go hire a product manager for like a B2B SaaS company to work on the platform side, that's gonna be very different than hiring a product manager that I wanna work on growth marketing for a direct-to-consumer brand, right? Like it's the same kind of rhythms, but it's not the same tool sets, right? It's not the same thinking in certain ways, but they're both product managers at the end of the day.

  - Yeah, exactly. Yeah, it makes sense. What would you consider to be a best practise? Well, I don't really like the term best practise. Let's change that slightly. What do you consider to be a good practise in product operations?

  - So signs that it's working really well is the product management teams are very excited to have them, right? Like leaders wanna engage with them, product management, like they're being asked to do so much, because people see the value like you know you're on the right path, and that does happen. If people are like, "Eh, product ops, I don't really like, I don't know what they do, I don't really care," it usually means that they're not looking at what are the problems that people actually care about that we solve too. So I think very much like product management, like you have to prioritise what you're doing. It's not just like go in, and roll everything out, and don't think about prioritisation on it. You have to be like, "What is gonna get me the buy-in and the support for me to keep growing this?" So, like I said, you usually start at the leadership level, but then you gotta go to the product managers like, "What's burdensome to you? Where are your issues?" And if you knock it out that way, and you start building systems from that perspective, you're solving a problem for your customer, but they're also gonna get very excited. So they go, "Oh, what else can you do? What else can you do?" And then, I think, the part here too, it's strategic, it's not reactive, and the people who don't do product ops well end up in this reactive mode, where like somebody will come over, and just be like, "I need this template, or I need this thing," but there's no reasoning why, and they're not setting up the framework and the structure for what they do to show how it actually is, like I said, product management for product managers. Like there is a whole roadmap here, there's systems that we build, there's things that we manage, there's a whole thing that we scale here to make it the most effective. And if you get into this mode where it's just like, "Hey, can you do these little things for me?" and you end up more like a project manager, what happens is the teams get way too big. There's value being happening in like one or two little tiny pockets over here, but it's not scaling to the rest of the org, and then everybody starts fighting over like product ops resources, and like, "I need to have mine, and you need to have yours." And then you just end up as project manager. So that's not like what we're trying to do.

  - Yeah, or a product operations feature team, right, where they're just trying, right, to just bringing it back, to escaping the field trap is just exactly that. We are not there to have a washing list, or a wishlist, of broken product management things, right? And I think that's really important. I love that you brought that into that question. So we talked about, you know, the good stuff, the good behaviours, and the bad behaviours there. I wonder what you see in terms of product operations involvement in roadmapping. And that's a selfish question for me, 'cause I love the roadmapping space. How have you seen that work?

  - Yeah, I think product ops, there's a couple different pieces of roadmapping, and it all kind of comes back into developing and monitoring strategy. So if you think of product ops getting into the roadmapping space, like most people will just immediately go towards, "Hey, they manage the tool. They select the tool, they set it up, they train the people on how to use it," but it's so much more than that. There's also what goes into the roadmapping tool. So, like I said, if we can't decipher what's in that roadmapping tool, it doesn't matter, right? Like why do you even have one in the first place? So I used to do this, like when I was at Athenahealth, this was one of the things that we ended up rolling out. So I had like trained all the teams, and this was the first place I started to get into product operations, and we're trying to make it transparent for the leaders. So we looked at our roadmaps, and everything was at 18,000 different levels. So I went back, and I said, "Okay, we did learn in here about scoping, so here's what we call this, like an epic or whatever you wanna call it, everybody changes it, I call it an option, for the teams, like let's go back to our training and pull that out. This is what this should be in our roadmapping tool, right?" Like this is the level it goes in. Here's how you write it. Here's how you know it's good. Let's make sure the right attributes are on it. And then we train all the teams to go back and refine them all, move things around into whatever level they're gonna be, and re-scope it. And then we said, "Okay, now we can pull this back up into the next level of strategy," which was initiatives. So then, at the same time, though, I was working with the leadership team, all the way from the CEO down to everybody else, saying, "Okay, what's the format? And what's the way that we're going to write our strategy?" So we've got, you know, visions over here, and some objectives over here, but it's not really bringing it back into how do we all get aligned. So we worked on like structure refinement, how we communicate it, and then that was a product options piece as well. I'm not building the strategy for them. I'm not like telling them what their vision should be, but I'm saying like, "Okay, you just told me what your vision is, let's make sure it's written in a way that makes sense." Here's questions that I would ask if I was a product manager. "Let's refine that. Like here's our standardisation. We're all gonna write memos like this, and the memos are gonna be two to three-pages long, they're gonna contain this, they're gonna contain that. These initiatives that are on the memo, that's what all these epics get rolled up into. Now, we can start to track them in our roadmap tool, and see if we make progress towards them. The goals are communicated there, we can instrument it out." So like here's where like the templates came in, here's where the tool came in. And then we built a cadence for actually reviewing it. So we were like, "When do we review roadmaps? When do we review how they make progress towards initiatives? How do we review the company-based metrics?" So we redesigned all the QBRs, we redesigned all the product, you know, meetings where we would do that, we changed the number of people in meetings, we made it for the right level of audience, we talked about what we would discuss, what we wouldn't discuss, and then we defined all of that to make sure that we were going on the right path. And like what happens if we're not? How do we change it? Who's responsible? What do we do? So we, basically, built that rhythm and that operating model around the roadmap, and, again, it's like not just the roadmap. They had a tool for roadmaps, it was Jira, I didn't love it, but it existed, right? But they did not have all the stuff around it that actually makes a roadmap valuable.

  - The hygiene of it, and the segmentation of the data, and the understanding of it. And, in fact, I'm really grateful that you mentioned that, and grateful that you went into detail in your book "Product Operations". We'll put links below, so that people can find this, and I'd be surprised if somebody hasn't read it. But you talk about Athenahealth there, and you break down that case study that you've just described, and I mentioned that, because that was one of the most useful ones that I found being more in the product roadmapping and execution tool-type space was just finding that, and seeing the clear segmentation was one of the most helpful in my journey. So thank you for that.

  - Yeah, you're welcome. And I think it's important to see that, you know, it's not just about tools and stuff. That's like where everybody gets naysay about product operations, right? They're like, "It's process, it's tools," but they're for a purpose, right? Like you can't operate a business without those things, so how do you just make sure they're super valuable? And that's what makes me excited, because that scales, right? Like that helps people at scale, it makes it possible to do the hard work of really like making sure we're building the right thing for our customers. And not that this is easy work, but it helps us like all focus around that, because, if we take that noise out at the end of the day, then we concentrate on value.

  - So I've got a couple of quick questions for you now, 'cause I wanna be mindful of your time. I wonder whose advice on product operations you listen to. Who really resonates with you in the area at the moment? I think it's a growing community of people.

  - Yeah, I've always learned a tonne from Blake Samak, who's been doing this for a very long time. So like Blake did it at Uber, he did a Stripe, he's at OpenAI now, and he's very open about like what he learned, and how he would do it differently in different organisations, and how the context actually shifts it. And I think that's really important. So I love his perspective, because it's very much about how do you go into the organisation, like figure out what they need? And what Uber needed was very different than what Stripe needed, and I'm sure like OpenAI needs something completely different, but there's all these principles that are underlying it, and the systems that he is already built, but then he designs it to meet the company where it's at, and then grow it from where it is. So I've always really enjoyed listening to him, and kind of understanding like his journey on it, what he's learned over time, what worked, what didn't work, and I think that's super valuable.

  - And I'd love you to share some of your resources here as well, but what product ops resources do you use or recommend to people? And absolutely some of your own are completely applicable here.

  - When I look at portfolio roadmapping, I recommend Dragonboat there. That is very much for leaders, though. It's for like leadership. It's how do you get the financial outcomes measured back to what we're doing on the portfolio level? So I think that's super important, especially at like scale, when you're doing that in a really large organisation. When I look at aggregating data and trying to get it, I recommend usually looking at like something like Dovetail. I think Pendo is doing a really good job now of aggregating a bunch of information, and pulling those streams together, not just in analytics, but they're also now getting the qualitative side into, and then branching it to analytics. So those two, I think, are doing really great jobs on bringing in more information, so that you can synthesise it better, and then make decisions off that. So I would set something up like that anytime I would go into an organisation and look at that. What other product ops tools that we're doing? There's so many emerging right now too that I feel like, every day, something else comes out. I've seen a bunch that I haven't tried. So I don't wanna like rattle off names that are not proven yet, but those I could tell you have worked really well for me. What else? Having some kind of analytics tool in there from a centralised data aggregation is really important. So whether that's a Tableau, or a Looker, or anything like that, but pulling most of those streams in is gonna be really important. I think, whenever you're looking at the tools, I'd also look for integration. Like if a product ops tool doesn't have an API infrastructure, or doesn't integrate with the different tools in your organisation, I would not touch it, because you will need to do that at one point. So I'd look at like what are the major systems that different departments are using? And does this system that we're evaluating actually integrate into some of those? I think there is a really cool pattern emerging with a lot of these companies in the product space, where they are getting more integrative into other stuff. Like they're plugging into sales tools like HubSpot, Gong, you know, like what you call customer support tool, Zendesk. So they're pulling the information in about customers, and starting to aggregate it, which is fantastic. So if you don't have something that does that, you're gonna like miss out on the next wave.

  - Totally, it's such an exciting time. It really is. Melissa, it's been incredibly enlightening speaking to you. As I mentioned off camera, it's great to actually speak to you rather than watch your videos. How can people get in contact if they've been inspired by things that you've said? How's the best way to get in contact with you, or get access to your resources?

  - Sure, it's been great. Thank you so much for having me. You can contact me. My online school and a lot of resources are on productinstitute.com. So there's a way to contact me there. Also I blog on melissaperri.com occasionally. I haven't been as great there. But LinkedIn is a great place to kind of see what's more up to date. And then I run a podcast called the "Product Thinking" podcast, and I answer questions on there from anybody in the audience and do that once a week as well.

  - All that leads me to say is, "Melissa, thank you so much. It's been an absolute pleasure speaking with you."

  - Great, thank you so much for having me.