Lenny's Podcast: Product | Career | Growth - The ultimate guide to product operations | Melissa Perri and Denise Tilles

Starting point is 00:00:00 Do you want to hire 10,000 product managers and let them all do these things off the side of their desk and then concentrate on strategic work like 30% of the time? Or do you want them concentrating on strategic work majority of the time and then help build a product operations team around them that can create these shared systems and this infrastructure to allow them to work better? Today, my guests are Melissa Perry and Denise Tillis. This is a rare two-guest episode. Melissa and Denise are authors of an awesome new book called Product Operations, How Successful Companies Build Better Products at Scale. Melissa is a legend in the product management community. She's the author of the foundational P.M. Book, Escaping the Build Trap.

Starting point is 00:00:44 She runs a product management training organization called Products Labs, teaches product management at Harvard, and has worked with hundreds of companies on their product management function. Denise is a product leader, coach, and consultant, helping companies with their product vision, strategy, and execution, and works with Melissa at Products Labs. In our conversation, we get super deep into the emerging role of product ops. As you'll hear in our conversation, over the past few years, this role has gone from almost non-existent to something like half of scaling tech companies with at least one product ops person.

Starting point is 00:01:16 This new role is probably the thing that's most changing in the role of product management, and after this conversation, I'm convinced it's a great thing. We chat about what the role concretely is, how it differs from product management and project management, what to look for in your first product ops hire, how to roll out a product ops function, why product managers shouldn't be afraid of this role and how your life gets significantly better,

Starting point is 00:01:38 plus a case study on how they rolled out product ops function at a large company, and so much more. With that, I bring you, Melissa Perry and Denise Tillis after a short word from our sponsor. You fell in love with building products for a reason, but sometimes the day-to-day reality is a little different than you imagine. Instead of dreaming up big ideas, talking to customers, and crafting a strategy, you're drowning in spreadsheets and roadmap updates, and you're spending your days basically putting out fires. A better way is possible. Introducing Gira Product Discovery, the new prioritization and road mapping tool built for product teams by Atlassian.

Starting point is 00:02:16 With Gira Product Discovery, you can gather all your product ideas and insights in one place and prioritize confidently, finally replacing those endless spreadsheets. Create and share custom product roadmaps with any stakeholder in seconds. And it's all built on Jira, where your engineering team is already working, so true collaboration is finally possible. Great products are built by great teams, not just engineers. Sales, support, leadership, even Greg from finance. Anyone that you want can contribute ideas, feedback, and insights in Jira product discovery for free. No catch. And it's only $10 a month for you.

Starting point is 00:02:52 Say goodbye to your spreadsheets and the never-endings. and the never-ending alignment efforts. The old way of doing product management is over. Rediscover what's possible with GiroProduct discovery. Try it for free at atlassian.com slash Lenny. That's atlassian.com slash Lenny. Melissa and Denise, thank you so much for being here. Welcome to the podcast.

Starting point is 00:03:17 Thank you. Thanks for having us. You were the second ever guest duo I've had on the podcast. Melissa, this is your second appearance on the podcast. And you two have a new book. book out, which I have right here. It's called Product Operations, How Successful Companies Build Better Products at Scale. And what I want to do with our time today is to help people fully understand the role of product operations from every direction as much as we can get through in an hour.

Starting point is 00:03:43 How does that sound? Sounds great. Great. It's awesome. So first question, just to set a little context on this role, how popular and how common is the role at this point? I did a quick skim of just awesome companies and really successful companies, and every single one of them seems to have a product ops role at this point. Open AI, Uber, Stripe, Ramp, Deal. Those are just a few that I looked at. Is that what you're seeing? How should people think about how popular and how common this role has become?

Starting point is 00:04:12 Yeah, I think over the last few years, we definitely have seen product operations start booming. It did originate in a lot of big companies that you mentioned to, like Uber, the head of product operations at Uber and the person who started it, Blake Samick is a case study in our book, and he also did it at Stripe, and he does it at OpenAI. So it's pretty funny that you mentioned those three because that's Blake right there, who did that. And we have seen like a very good transition from people kind of whispering about product operations. And I know when I wrote my first book, Escaping the Bill Trap, in 2018, I mentioned it in there because we had just started doing it at Athena Health.

Starting point is 00:04:48 And I saw this as like a really big issue in trying to make a complete product management function there. And especially at scale, right? Like we had 365 product teams. We were trying to figure out how does this all come together. And product operations for me was a key part of it. So when I had first written it into that book, a lot of people were like, oh, what is this thing? I think we need it.

Starting point is 00:05:07 Do we need more? And that's what got us to start writing this book. And since then, I've seen a lot more companies coming out and either making more mature product operations teams that started probably before that or actually introducing them now. I guess maybe thinking about just tech companies, if you had to put a number on some rough percentage of interesting, fast-growing, hyper-growth-y startups, would you, is there a percentage you'd put on how many of them have a product opposite person at this point?

Starting point is 00:05:34 We don't have like a hard and fast number. I'll say that on this, but we have seen that, let's take a sampling of maybe something that I know better. When I teach like CPU accelerator, when I teach people in these cohorts, out of like the 20, 25 people that will have in a cohort, I'd say, at least half of them have somebody doing something product ops related. It might not be a mature function. It might just be one person on it, but at least half of them have somebody doing something. That's a good yardstick because I teach a product operations masterclass for products labs with Melissa.

Starting point is 00:06:13 And it's been interesting. I sort of do some pre-work and try to understand where folks are in the product's journey. And when we started offering this class in 2020, about 60% where products curious. And as time has gone on, it's really gone down and people have started to add it. They just want to understand what's the best way to optimize it. So I would say it's gone from that level to say, you know, probably 60% of them do have it now and then want to understand how to optimize it. Do you have a sense of when this started to inflect and become such a common thing? When I was a product manager, I had no product ops person. And so it's really fascinating to me to learn about this emergence. I know there's probably not a date,

Starting point is 00:06:52 but just like, it sounds like maybe after your last book was published, is there like a time frame of like this became a thing? Is it this guy you mentioned? That's now at OpenEI that started spreading it. Blake, I think, was one of the people at the beginning who was talking about it the most. And he's done a lot of work, I think,

Starting point is 00:07:06 to push product operations and tell people about it. So that was great. I know Pendo has been speaking about product ops a little bit more, and that's where I started to notice that it was picking up Steam. I think around like 2019 is when Pendo started talking about product operations. So it was like roughly right after my book came out that I saw more people speaking about it. And now they're trying to figure out like, do we standardize it? What do we need?

Starting point is 00:07:30 How does this actually look like in organizations? But I think it's been probably a good five years of now hearing people doing it in real time. Awesome. And it sounds like maybe just in the last few years, it started to really take off. And we actually had Christine from Pendo on the podcast talking about product ops about a year ago at this point. So this is a great follow up to a lot of that. Before we talk about what is product ops and what are the functions, what would you say are the biggest benefits to a company having a product ops role? And also just what's a sign that you should probably seriously consider bringing on a product ops person and starting to invest in that area?

Starting point is 00:08:07 It's really about helping the product managers focus on what they were actually hired for, right? The strategic work in my role and the operating side and managing teams and Melissa as well, more and more product managers are to, taking on the data harvesting, the data implementation, and just to get data to work with, they're spending 20, 30 percent of their time. So what would that look like if they were enabled and had all of those great inputs to actually focus on company growth, achieving the value, achieving the scaling goals that the company had? So it's really about helping them focus on what they were hired for. So again, when I was a PM, I had no product Opt-Ops person. And having read your book, like basically all the things Product Ops does is stuff

Starting point is 00:08:53 PMs historically have done. And to me, it's like scary to give up all those things and put them on someone else's plate. You know, there's the ideal of, oh, amazing, I don't have to do all these things. I'll focus on things I really get excited about. But there's also this new fear of, oh, someone else is going to take these things and maybe they won't do as well. There's this new process I have to think about. There's new lines of communication. So what's your biggest pitch to a product management? manager starting to hear about product ops and this fear of like, oh man, my job's going to, it's going to be weird. This new person I have to deal with all the time. I used to do all these things. How do you help a PM get excited about this? Product operations does not take away

Starting point is 00:09:33 decision making rights from the product manager. It's there to inform them. So if you're judging your success as a product manager of like, hey, I do the SQL queries and I do the like, I have to spend the 50 hours to set up all these customer interviews and calls, right? That's, That to me is very operational process type work, but it's not work that's going to help you make a decision about your product. And that's why we're looking at the product operations team. Because what I've seen is product managers doing this off the side of their desk. Like me too, right? Like I got excited about this because when I was at Open Sky, you know, in early days of my product management career, I had to go learn MongoDB to get data out of a database.

Starting point is 00:10:12 Like I was sitting through a MongoDB class learning how to do this. I knew SQL, but we did not use the SQL database then. I had to go learn MongoDB so I stopped bothering the engineers to be able to actually just measure if my products and my features were doing anything correct. And that was a lot of time that I spent doing that instead of spending it on good feature work, right, and on understanding my customers and working with my developers and figuring out what we were actually going to build. Instead, I'm out here learning this programming language, which I never used again, by the way. Like, never used it again after that.

Starting point is 00:10:45 And that to me is the stuff that product ops takes away from the product managers. What I constantly hear from product managers, though, is like, I am so busy. I don't have time to do the things that I need to do correctly, right? I'm so busy trying to line up customer interviews or I'm so busy just trying to get data out of systems. I'm fighting these fights to get the things that I need to do my job correctly that I don't have time to do my job correctly. And that's what we're trying to help them with, right? So I wouldn't be afraid that product ops is coming in here. It's not supposed to be something that's providing more overhead.

Starting point is 00:11:20 It's supposed to be something that's a little more liberating and helps free you up from all the busy work. It's a great pitch. I always thought product management is an insane role with way too much going on. And that's why everyone's always burnt out and stressed. There's just like so many things you have to do. So I totally get how this is happening and why this is happening. and why this is happening. And I love that you're helping people figure out how to actually do it well. Let's actually get into what the role actually is. I think it's a really confusing role. A lot of

Starting point is 00:11:49 people hear product ops and that everyone know what it is. There's like maybe research synthesis, there's some data stuff. What's the simplest way to think about? What is the general, consistent roles of a product ops person and what they can do for your company? The way we think about it is kind of structured around the three pillars that we talk about in the book. So business and data insights, more of the quantitative side, making sure that the product manager has all of these sort of engagement and revenue inputs to make smart decisions. The customer market insights, so the qualitative. And we talked about this a little bit earlier in terms of finding folks to speak to making sure you're speaking more to more than one just customer. And finally, the third pillar is process and practices.

Starting point is 00:12:34 So it's really around those areas. and it depends on what your company needs and where the biggest opportunities and challenges might be. Awesome. So the three, just to kind of reshare what you just said, the three pillars of product ops, business, data and insights, customer and market insights, and the process of how you built product

Starting point is 00:12:56 and helping the business operate more effectively in the way they build product. Sounds great when you say it, yes. I'm just, I have the notes, and this is exactly a describe in your book, so well described. Yeah. Is there one of these three that you find most important impactful? Is it really dependent on the business and their needs or what the PM wants to do? How do you think about, I don't know, which of these three is maybe most important or is it super dependent? So we usually see that high growth companies start with business data and insights and make sure that they can actually monitor what they're doing and get the strategic inputs. We see larger companies and enterprises kind of go more towards a process and governance, especially if they're in, let's say,

Starting point is 00:13:36 a transformation because they don't have the infrastructure to run good product. Let's say it's that way, right? They're usually just starting out. They're just forming their teams. Let's say they just train product managers. And now they're like, what else do we need to do besides just training product managers to make this work? So they need an operating model. And they typically don't have a product operating model. And in that case, they're looking at like, even just how do we do roadmaps across the organization so that I as a chief product officer or VP of product, can actually just have transparency into what my teams are doing. And like, Jira does not work for that, right?

Starting point is 00:14:13 You need a portfolio tool to be able to roll that up into something that makes sense. But again, that helps me as a VP now or a CPO make strategic decisions. And it helps me monitor my teams and understand, are we actually spending money on the right things? Are we doing the right work? So they tend to do it more on the process and governance side. but it's all in service of being able to make rapid strategic decisions and get good products out there to the world. That's a really handy way of thinking about it. So just to say what you said, again, for high growth companies, you're finding of these three pillars,

Starting point is 00:14:49 generally where product ops can help most is the business and data insights, helping them understand what's happening and make decisions more quickly, which makes a lot of sense. For more established older companies going through digital transformation, oftentimes it's helping them with their process and making them more efficient in how they operate. Is there also bucket for the middle pillar of customer and market insights, or is that kind of spread across? That's a squishy middle. And when I do teach this class, ask people sort of like what their perception is of product ops and that people never think that. So it's an area definitely for growth. I think in a lot of

Starting point is 00:15:24 companies. How does that piece work with user research and that team? So we've seen a lot of the work that is done in that team, they work with user research. Now, in organizations where, let's say, this happens in a lot of organizations, but not all of them, right, where product oversees design as well and user research and it oversees UX, this becomes kind of seamless because you are going to have, let's say, a product ops person, usually with a user research background, who's going to be helping to do the stuff we talk about in the customer and market insights piece, which is kind of pulling all the research that's been done, like the customer interviews, all those things together into things like a findings database. So there's great tools out there like dovetail, but you can

Starting point is 00:16:10 also roll your own. And it's about aggregating all the interviews or customer research that's been done so people can query it and start to see what do we already know. So we're not going out there and duplicating a bunch of research. It's also about like finding participants who want to opt into research. So making sure that you have customers aware that, hey, we might contact you to do customer interviews, this is why. Do you want to participate in like alphas and betas? If so, this is what it entails. And if we can build a database of people and customers that we have who opt into those

Starting point is 00:16:42 types of things, it makes easier for product managers to go out and contact them and say, hey, by the way, we got a beta. Do you want to do it? They know what it is. They're expecting it. They know what the cadence is that people will reach out to them on to do research. And the user researchers can use that as well. Now, the thing about the customer and market insights piece is that that person who's streamlining those activities and building those systems, they're not usually the same person who's doing the user research.

Starting point is 00:17:11 So this is not about taking user research away from product managers or from user researchers. It's about like enabling them to do it more effectively, enabling the insights to be put out across a company more effectively and also helping them. get in touch with users and get that feedback. Another piece of this, too, that we talk about is, like, getting qualitative insights from sales and support. So we always hear from sales teams, and this is like the classic product management tension. Like, the product managers aren't listening to me,

Starting point is 00:17:42 or I've told them five months ago that I had this problem with the, you know, with these customers that were going to churn, and we didn't build those features. And what this function does with the customer and market insights here is that it helps get a lot of that information back to the, product team in an effective way, right? And then it also helps communicate back to sales, hey, let's be a little transparent about how we're using that feedback, right? So that's how we can communicate it back in strategy, let them know where we stand with working on those ideas or solving

Starting point is 00:18:12 those problems for customers. But usually there's like a wealth of qualitative information stuck somewhere in our organization systems, like whether it's in Salesforce, whether it's in support tickets, and somebody's Google Doc, you know, of their customer interviews that they've been doing. And what we're trying to do is get that out of these individual systems and into somewhere where a lot of people can take those qualitative insights and start to learn from them. People always ask me, what's changing in product management? Like, what's the future of product management? I'm always like, nothing. It's always going to be basically the same.

Starting point is 00:18:43 It's just never going to be fully defined. It's going to keep doing this weird role. But I feel like this is actually the answer of what's changing in product management is this product ops role is emerging, taking a lot of these things that PMs don't necessarily want to be doing or aren't amazing at and giving them more space to. do the things they really want to do. And so I think that's pretty amazing. And I think if you think about the timeline, you said five years ago, there was no real product ops. Today, half of companies essentially have a product ops role. And I'm guessing in the other few years, it'll be much higher. So this is really interesting. I'm excited about it too. I think what we saw before was that, you know, like you were saying, like product management was kind of this like squishy role for a long time.

Starting point is 00:19:21 But now we're kind of standardizing like what do product managers do. What's happening, I think, though, as product managers become more prevalent, and as people realize that this is a critical role for companies, whether you're a software company or a bank or something else, right? Like, we build businesses off of software in today's world. And if you're not building software, you're behind. With more and more software that we're putting out there, right, product managers don't have time to go do all these things off the side of their desk. And it's fine when you're like a small startup. Like I was doing it too. Like I said, I had to go learn MongoDB when I was in a smaller company. And then we start to scale and I've got more and more product responsibility.

Starting point is 00:20:01 And I'm like, I don't have time to go learn MongoDB now. And that's, you know, where people start to burn out and where they get frustrated, like you said. And we've got more and more systems. We've got more software tools out there that product managers are using. It becomes a lot to track. So it's either like for companies, do you want to hire 10,000 product managers and let them all do these things off the side of their desk? And then concentrate on strategic work like 30% of the time? Or do you want them concentrating on strategic work majority of the time and then help build a product operations team around them that can create these shared systems and this infrastructure to allow them to work better? I think that's such a powerful way of thinking about

Starting point is 00:20:41 this. I imagine PM's listening to you saying, I don't have to learn MongoDB and SQL anymore, would think like, that's actually, no, I think that's good. They should learn to do SQL and run their own data. But I think the important pieces here, yes, it would be great. But as you scale, it becomes harder and harder to have time to do all that because things you end up with other work that you need to be doing. So in theory, it would be awesome if your PMs could run their own queries and do their research and create the whole process. But it just becomes hard and harder. And it reminds me of a lot of companies that are trying to delay hiring a product manager in general and instead giving the role to engineers and designers. And my feedback is always like,

Starting point is 00:21:21 that's great as long as they want to be doing all these things that are not generally what they enjoy doing. Like an engineer doesn't necessarily love running meetings and writing one-pagers and strategy docs and taking notes. So I think it's a similar thing where, sure, it's great until you don't really want to be doing that or you don't have time for that. And you have like your actual job you need to be doing. That's your full-time job and you're being your OKRs and your goals are really around the outcomes for the company. But I wrote 20 scripts this year. So we need to help them focus on the things that they're being expected to deliver in terms of value. you. I also think it's funny, like, how many people want to be a product manager until they realize

Starting point is 00:22:01 what product management entails. And this happens a lot. And I, you know, I saw it with my MBA students at Harvard, too. We do a whole class. They'd play a product manager. I had a lot of people opt out of being a product manager at the end of it. They were like, I didn't know realize it was like that, right? Like, I did not realize I had to do so many things. And I think a lot of what gets them as well is a type of context switching that's required as a product manager. So you already just, with the basis of what we have to do, do so many different things of like, you know, user research, working with the designers,

Starting point is 00:22:33 working with the developers, working with executives, working with different stakeholders. You got a context switch to be able to relate to all them. You got to empathize with all these different people. You have to do all these different tasks to do this type of work. And then you got to go figure out what template to put your roadmap in, which is going to be different template than the other 80 product managers on your team

Starting point is 00:22:54 because somebody didn't come in and just say, hey, we're going to use this. Like that type of work to me is just distracting from it. And is it hard for a product leader to just be like, hey, this is a template we're using? No. But then if that product leader has to go out and train 80 other people on that template, make sure it's consistently updated all the time.

Starting point is 00:23:17 Make sure it's in the right formats. Make sure it's in the right software. That is where the overhead comes in, right? and a lot of product leaders are doing this right now. And what we're trying to do is free up individual product managers, but also those product leaders. So I work with all these CPOs, these VPs of product. And they're like, I see them just like not working on strategy. I'm like, why are you not working on strategy?

Starting point is 00:23:43 And they're like, I don't have time to do that, right? I'm in here like stopping all these fires. I'm figuring out like what template I should put my roadmap in. Like I said, it's not hard. They know what template it should be. in. But think about if you now can delegate that to somebody else and say, I want it in this template, go roll it out, right? Like go roll it out, go train everybody on it, find the right software for it, do it, right? It frees those people up, the leaders to go work on strategy. And

Starting point is 00:24:10 like, that's why you're spending so much money for a product leader anyway. That's why you spend so much money for a product manager anyway. So to me, it's these things are not impossible to do. It's just like, do we have the right people doing them? For PMs that are trying to figure out what remains on their plate, what are the kind of the pieces that a PM should keep and not offload on a product ops person? They don't want to offload decision rights. You should never be outsourcing your decision-making to a product ops person.

Starting point is 00:24:39 That's not the point. They're the product manager for the product managers. That's how I think about it, right? So their decisions should be around, how do I operationalize great product management here. But as a product manager, you shouldn't be delegating to them, to make any decisions about their product, right?

Starting point is 00:24:55 And that's not their job. And if they are coming to you and saying, like, you should build this, like, that's not their job either, right? That's not the right thing. So making the actual decision and then putting that decision into play with your teams, right? That's the type of work that you want to hold on to for a product manager.

Starting point is 00:25:12 So while a product ops person can help you point you in the right direction, let's say, to find customers, maybe even help you get in touch with the customers, like send out the email to invite them to a meeting or operationalize that. Hopefully, like, that's automated. I would love a product ops person to automate that type of stuff, right? You are going to be doing the user research. The product ops person you can go to and maybe say,

Starting point is 00:25:36 hey, this is the type of problems that we're understanding. And maybe they help you find other pieces of information around the organization on those topics and bring it to you. But they're not going to be the ones like reading through all this information and being like, you should build this, right? They're also not going to be the ones who are, like you say, hey, I made this decision about what to build, told the team about it, the team like got together. Can you go monitor the developers and make sure they're building it

Starting point is 00:26:01 on time? Like, no, they're not project managers. They're not the people who are going to be on top of your developers, like watching them build things, making sure that everything's out on time. That's not their role either. They're not going to handle hard stakeholder or conversations about tradeoffs for you, like all of those things that you are going to want to keep ownership of because at the end of the day, as a product manager, your job is to produce outcomes and you do need to make sure that you're monitoring those outcomes and moving towards them. You don't want to offload their responsibility. So I took a couple notes of just things that the PM continues to own, in quotes,

Starting point is 00:26:36 you know, no one owns anything. Strategy, vision, prioritizing, resource allocation, tradeoff decisions, hard conversations around tradeoffs and stakeholder input and things like that. Is there anything else in that kind of bucket of just like stuff, a product manager continues to be responsible for? Well, there's a big piece here we're missing. Go to Market. And that's where products could really make a difference in terms of, you know,

Starting point is 00:27:04 connecting those teams, but also being, you know, sort of the first point of contact for sales, first point of contact for product, and enabling just some efficiencies. You know, if we want to call it, process or method, but just trying to help break down the silos. A company I'm working with right now,

Starting point is 00:27:21 there's a big challenge with that. And it's a large enterprise level company. So how do we break down all of the different silos between departments and your team leads and whatnot? So it's really talking about like, here's how we're going to do it. Here's some sort of simple templates we will use it, training sales, training product, and then getting that into play. And doing the book and doing our research, that was a sort of consistent story point from a lot of people that we interviewed that go-to-market was a really big pain point. So I think, too, what Denise was saying, like, is product ops will take on a lot of the coordination of those types of things and make them standardized templates. But as a product manager, like, your role in informing what the go-to-market

Starting point is 00:28:02 is doesn't change, right? Like, you're still putting the inputs in there. So maybe product ops will provide, for example, like templates and help say, like, hey, here's the different pieces that we need to make a go-to-market plan, for example. Here's the templates. Here's what I gather from people, but like you as a product manager still have to fill out your parts. You still have to go talk to the salespeople. You still have to like work with the marketing people to make sure it's positioned correctly. But the product ops person can help with the kind of like program management around it of getting those people together, having consistent templates, creating the cadence for when you review those things, making sure that they all align and they're all in one place so you're

Starting point is 00:28:41 not going to find them everywhere. And then making sure that go-to-market process is consistent across the organization so that it's not like, you know, as Denise said, it's not like everybody's reinventing the wheel and somebody on a go-to-market team has to figure out how to go to market differently with a different product team. Awesome. That's a really handy and important addition. You mentioned project management. I imagine many people think product ops also takes on project management what's this good way to think about project management versus product ops? There's also program management. Do you have a kind of a way of thinking about those roles?

Starting point is 00:29:15 The way I like to think about it is however, whatever they're doing in terms of the three pillars, product ops is really thinking about, as I mentioned earlier, increasing the speed and quality of decision making and all of the pillars sort of play into that. Program manager, I think, is really thinking about larger company initiatives and, you know, the duration of their work is ongoing versus a project manager. responsible for a certain project that's, you know, got a time box and an end date. But it does get a little wifty for sure. I want to go back to the three pillars real quick and go one level deeper to help people understand what they actually entail and what are the jobs of a product

Starting point is 00:29:51 ops person. So just we could even keep this sort of brief, but just let's say with business data and insight, what are the functions and jobs and things that a product ops person would be doing for your company? You know, a lot of companies will have a data science team or business, you know, intelligence team. And you don't have to reinvent the wheel. You don't have to have your sort of internal product ops type of intelligence team. But it's about connecting those and making sure you're putting that sort of with a product lens and especially say with finance too. You don't want all the product managers sort of hitting up the CFO for that month's revenue or having questions. So it's about accessing all of these inputs and putting it, you know, putting

Starting point is 00:30:30 it through a product lens and then making sure that product managers actually know what to do with can action it. So it's essentially running queries for you, generating charts and graphs and recommendations based on what the data is telling you. Basically, it's doing all the data stuff that a PM, what would you be doing? Is there anything else there? Also helping the leaders, too, right? So we're talking about it from a product management perspective, but I think this becomes, this one especially becomes really critical for leaders and executives, right? A lot of times, and like I sit through board meetings where we, we talk about AR, we talk about retention, we talk about net retention, and we talk about all of these business metrics, right? And they're

Starting point is 00:31:14 great for monitoring the health of our business. But where product ops comes into play in business data and insights is how do we monitor the health of our product? So like as a chief product officer, ARR is interesting to me, but it's not as interesting to me as ARR by customer segment, right? It's not as interesting as AR by product line. It's not as interesting if I take that and then look at it by retention or adoption by product or feature set or adoption by customer segment byproducts, right? And when we start to put those lenses on it, they now become a really powerful strategy insight.

Starting point is 00:31:49 So what I think these people do and do really well is even at the executive level, they help you as a product leader or like, I need these types of insights. right? This helps me, this is how our business runs and this is how I want to set the strategy. These people make those dashboards, make those repeatable insights for you. And then ideally, they know the data so well and they know your business so well that they can surface up other opportunities for you as well to look at data that you didn't know was there or can find these interesting trends. So they are very much like the people digging into the data. They're just doing it with more of a product lens instead of like Denise said, an overall company metric lens. And it's not

Starting point is 00:32:28 just in service of the product managers. And I just wanted to like point that out because I think this becomes so powerful for leaders. Because if the leaders don't understand those types of metrics, they can't actually monitor their strategies. They can't go back and say like, oh, we decided to go upmarket into the enterprise. Look, we've got enterprise revenue. But are you actually looking at where the enterprises are like adopting different product

Starting point is 00:32:52 lines, right? Are you looking at how the enterprise uses different features? And if certain enterprises are using, you know, these types of features, are they less likely to churn? Right. It's those types of insights that I think are really important on this lens. As a PM hearing that somebody else will be doing this feels really weird. Like this feels like such a core job of a PM is to spend a lot of time with data, try to find opportunities, try to find things going well, not going well.

Starting point is 00:33:21 But I think the message, again, is not you shouldn't be doing that as a PM. And it's not bad if you are really good at it. it's you probably just don't have a lot of time to do it well. And if you can find someone that's really good at this and has time that doesn't have all the other thousands of things on their plate, you'll actually end up finding more interesting results, finding more interesting insights, you're probably missing a bunch of stuff because you don't actually allow

Starting point is 00:33:41 a lot of time. Is that generally the way you think about it? Yeah. And I think too, like the business and data insights people, they're not going to be experts on product, right? Like they're almost always not. Like we had a couple analysts at Products Labs, and they were, you know, ex-McKinsey, X Deloitte.

Starting point is 00:33:59 They didn't know anything about product. So we taught them the product piece. And we were the ones who were like, here's the interesting data I know I'm going to need to see, right? And they were able to pull those things together and views where we could actually dig into it. But that was a jumping off point on the quantitative research where we're like, okay, now we need to go do the qualitative.

Starting point is 00:34:18 And I think for product managers, you still need to be super comfortable with data. Like if you can't read these charts, if you can't see, understand trends. If, you know, and a lot of times, too, if you're putting this stuff in Looker or, you know, a BI tool, like ideally you can pull ad hoc reports yourself. It's just that you don't have to craft a SQL query to do it, right? You still need to understand the relationship between data and product.

Starting point is 00:34:41 And you still need to understand, like, what good data looks like. You need to understand, too, things like causation and correlation. You need to understand that if I put out this crazy, like, marketing launch on Thursday, that's why all of a sudden we got like a million signups on Thursday and we didn't get a million signups on Wednesday. They still need to understand all those things. And I don't think that becomes any less important. And I don't think understanding and interpreting trends becomes any less important as a product manager's job. I just think it's about putting data into the hands of product faster so that it's not about like you having to fight your way through bureaucratic processes at your company to get that data. Right. So like, product ops can help streamline things that we know we're going to look at repeatedly, right? Like there's a bunch of stuff that we know we should look at. So put them in a dashboard.

Starting point is 00:35:30 Like why should I have to go pull that report ad hoc every single time, right? Put them in a dashboard. Put them in a report. Same for like board slides. We had like one of my friends who's the chief product officer of Forsta, Brian, Brian Buda. And he said like I love product ops because when we prepare for board meetings, I know there's a certain set of information that I'm going to have to put together. for this board meeting, and then when we go do it manually, it becomes obsolete by the time the

Starting point is 00:35:57 board meeting's over, and then I got to start again and prepare for the next three months and do the board meeting again, right? So it's like you don't want your data to be obsolete. You want this to be in a repeatable fashion for things that you know are repeatable, but it doesn't get you off the hook of still looking for trends and looking for insights. You fell in love with building products for a reason, But sometimes the day-to-day reality is a little different than you imagine. Instead of dreaming up big ideas, talking to customers, and crafting a strategy, you're drowning in spreadsheets and roadmap updates, and you're spending your days basically putting out fires.

Starting point is 00:36:34 A better way is possible. Introducing Jira Product Discovery, the new prioritization and road mapping tool built for product teams by Atlassian. With Jira Product Discovery, you can gather all your product ideas and insights in one place and prioritize confidently, finally replacing those endless spreadsheets. Create and share custom product roadmaps with any stakeholder in seconds.

Starting point is 00:36:57 And it's all built on Jira, where your engineering team is already working, so true collaboration is finally possible. Great products are built by great teams, not just engineers. Sales, support, leadership, even Greg from finance. Anyone that you want can contribute ideas, feedback, and insights in Jira product discovery for free.

Starting point is 00:37:17 No catch. and it's only $10 a month for you. Say goodbye to your spreadsheets and the never-ending alignment efforts. The old way of doing product management is over. Rediscover what's possible. With Giroproduct discovery, try it for free at atlassian.com slash Lenny.

Starting point is 00:37:33 That's atlassian.com slash Lenny. We had a guest on Casey Winters, and he has this perspective that when you have ops, operational people, that's generally a sign that something is not efficient and it could be made more efficient with software and product.

Starting point is 00:37:52 Not everything can be productized, but do you have a perspective on that that ops is often a sign where software, hopefully someday could do itself? You still need people to oversee those programs. So I don't think they would fully be obsolete. It wouldn't be like this whole role goes away completely, right?

Starting point is 00:38:08 But they're the people who should be looking at, what can we do to optimize and streamline this and not do it with human components, right? I think that's why a product management mindset lends so well to a product ops function too, because you're like, how do I use software or tools or processes or frameworks to help fill in some of these gaps and standardize it and then let it run. And that's what I was meaning by like the shared services model, right? If you really think in that format, it's not like, hey, I need a team of 10,000 product ops people. I think you're doing it wrong if you're doing that,

Starting point is 00:38:40 right? Like it should be a well-run lean team who thinks about how to leverage tools for this or building your own or whatever and your products for the product team, right? And that's how it should be easy. So what I mean like it shouldn't be obsolete one day, if you are building, let's say, products for the product team, like you still need somebody to look over that product and make sure it's relevant. And at the pace of everything changing like it does today, you know, so many things are so different than they were five years ago, you want somebody to be looking over that and making sure they're still up to date. It's still relevant. It still works for our company and stuff like that. But you're going to have a smaller

Starting point is 00:39:18 subset of people doing that. It's not going to be like, oh, I need a product ops team for like every product manager that's on here. Like that that's not how it should work at all. I think that is going to make a lot of people feel better hearing that. Do you have any rule of thumbs or way of thinking about just like how many product ops people you want per product manager per team? What's like a simple heuristic for just like how many people you may need? I don't have a hard. I don't have a hard and fast role in that one. But I would say, like, if you're at a one-to-one ratio, like, you're doing it wrong. Absolutely. If you're the one-a-hundred, you're doing it wrong. Yeah, too. I also think it's like, so when we talked about it, too, with this hybrid-vers shared

Starting point is 00:40:00 services model, if you have a hybrid model, let's say, and typically this is a symptom that your DETA's not well instrumented, let me put it that way as well. Sometimes you need a stock. gap holdover until you can well instrument your data or something, right? And that could be as long as it takes for certain companies. In this case, like we said, you might have like a business data and insights person aligned to every director of product who oversees multiple scrum teams, right? You might have one aligned to every VP of product, depending on how much help you need to get the product out of, like the product data out of things. Now, if you have a very well instrumented data set like we were talking about at Doodle or something like that, you're probably going to have way less people,

Starting point is 00:40:47 right? Because the product managers are armed and capable of going in there and being able to pull the queries themselves, do their ad hoc research themselves, because they made it accessible and you made it possible for them to go do that. So I do think there's a balance there between how good your company is instrumented, both in like for everything, like for all three of these pieces that we're talking about relative to the size of your product ops team. And it might take some more manpower at the beginning to get it going. But ideally, you streamline this team and it becomes pretty lean and pretty small. And they're overseeing multiple programs or software systems that run themselves. Well, it gives me a lot of hope that this isn't going to become just like another

Starting point is 00:41:28 massive org within a company is looking at companies that are incredibly efficient, like ramp and deal, that have very few employees, very few product managers. And they have product ops people. And so that tells me there's a lot of leverage that you can find from just like there maybe I don't know one or two that's probably not a large team of product office people there we say too like get started with one person like we we describe these three pillars and you know repeatedly through the book we're like hone in on what's the most important part for you that's going to help you right now that we talk through and then just like take one person and throw that out there and usually you can get so much leverage from that that it frees you up to do a lot of the

Starting point is 00:42:09 stuff that you need to get done. And then when you're ready and you see the next hurdle, and it's not something that first person could take on, then you might add one more person, right? There are different expertise, I think, between the three different pillars and the people who would oversee it. And that's something to take into account as well. So like we said, in business data and insights, like that person typically is not an expert on product. Hopefully they get ramped up on it working with you. But they're typically not an expert on product. And a lot of times these people are not coming from a product management background. That's going to be actually a different person than I would look at to help with the governance and product pieces.

Starting point is 00:42:43 Like that person needs to be a product background person because they're usually helping, you know, roll out the roadmap stuff, coach people on how to do it, helping to define the different systems and processes that you need on your product operating model. And if they have no experience with product management at all, that's going to be really hard for them to do. And it's probably not going to be great. And we do see this trend of people throwing agile coaches out. this. And Agile coaches who have never been a product manager before in a well-run company

Starting point is 00:43:15 are going to struggle there because they're going to revert back to agile processes and optimizing for things like Scrum, but they're not going to do what that role is designed for, which is to help product management processes. Like, we don't usually need another agile coach telling us how to run a stand-up. We need people to come in and help us figure out, like, who's invited to these cross-functional roadmap reviews, what kind of inputs do we need on there? What kind of decisions do we need to make coming out of it? And how do we communicate it at the correct level to executives as well? So we're not digging into Jira at these meetings in front of a CEO. Right? Like CEOs don't care about what's in Jira. Well, they shouldn't. Let's put it that way. Shouldn't. And and they, but they want to know like,

Starting point is 00:44:00 what are the big pushes that we're doing to help us reach our strategic objectives, right? So it's helping, they know a little more about the right size of communication, the different cross-functional teams, what product managers do on a daily basis, and what's important to them. And that's really critical in that role. So that's where I think your teams might just be slightly bigger from a perspective of more than one person. I'm not saying hundreds of people, but like you might need a couple different people in this organization because the roles are slightly different. Like for the market research and the customer research thing, too. Like, you might need somebody with a user research background for that.

Starting point is 00:44:38 Somebody who did research ops is a great person for that. And it's pretty unusual, I think, to see companies start out with an entire team. I worked with Sam's Club, and they were planning to do it that way. But mostly we see it sort of starting organically. I think the way Christina Tuaro mentioned in her story of being a PM and feeling the pain and having the empathy of wanting to make it better. And that's typically sort of the generation of the, these roles and it might be someone, you know, being allocated part-time from their PM role and

Starting point is 00:45:06 finding out that they really do enjoy this sort of enablement aspect of it, and that's where it grows. Awesome. So let's just lean into this topic of just how to start rolling it out at your company, and you've already talked about a bunch of tips there. And by the way, if you buy your book at the end there, there's this like really beautiful little guy there you go in the camera of just like a little yellow brick road of all the steps that it takes to roll it out. Yes, Candyland. Yeah. Candyland. So on this topic of just who to start with, sounds like you recommend start with one person. And what I'm hearing is pick one of these three pillars that you think is most highest leverage, potentially, to take off your product management plate.

Starting point is 00:45:45 Is that, is that right? Yep. Okay. And then so what else should people be thinking about in starting to roll this roll out, starting to build this team? Yeah, that's a great question. So one of our case studies is Shantaro Matsui at Amplitude. and he created the role in Amplitude. And you think about it, it's kind of meta, right?

Starting point is 00:46:04 So they're creating a tool that helps in terms of product operations, but they're enabling it there as well. So he's done a really great job of getting that set up and really being a thought leader there. So the case study that we chat with him about was introducing it and how do you get it going and how do you build the momentum and show the quick wins? And that was his top tip was making sure that you set, you know, understand first of all, you may have a perception of what the biggest needs. are, but doing your listening tour and doing your user research, some research sprints, understanding, there may be a huge opportunity, but it also sounds massive and you're a team of one. Where can you make the most difference quickly? Where can you have the most impact? So identifying those, celebrating those wins, making sure everybody understands that, and then sort of

Starting point is 00:46:52 showing what's above the line with a person of one that, you know, the capabilities you'll have and then below the line, things that you may not get, but, you know, you could if we did think about building the team and sort of setting the expectations as well. Do you suggest they try to hire someone that has already been a product ops person? Is it okay to hire someone that hasn't? Then they just kind of become a product ops person. How important is that experience? I think if you find someone that's done the role of product management, awesome.

Starting point is 00:47:19 If someone's set it up somewhere, I mean, look at Blake Samick, right? Started from Uber to Stripe to AI, clearly, you know, he's got a model going that's really successful. So if somebody could get a Blake Samick, I would say definitely do that. Yeah, it'd be hard to pull him away from Open AI. Yeah, I think he's leaving there right now. Just started. Got a lot of work ahead of him. But I got a lot of LinkedIn requests right now. Yeah. It's like, poor Blake. Sorry, sorry for your inbox. I think too, it's it's about if you're going like all in. Right. If you're if you're just trying to get buy in for this and let's say it's originating from a CPO or like a product leader who's like, hey, let's start this out,

Starting point is 00:48:01 but the company is not ready to invest all the way. You might pull somebody from a different function, let's say, have them be the product ops person and try to rapidly demonstrate value. If you're like a CPO or a leader and you're like, I got budget, I know this is important, I'm totally bought in. Let's go, right? You're probably better off hiring. Let's say somebody who's done this before, somebody who's experienced, but also somebody who could be more of a VP or director of product ops, and then they can go do the hiring and figuring out, do we pull people from other functions and like streamline it? And that helps free up the leader as well from not having to go find 8,000. It's never going to be 8,000 people, but like 8 people

Starting point is 00:48:41 to do that function, right? So that would be a way to look at it as well. So if people are not quite sold on it, you might want to start with one function, figure out where the burning, you know, issue is, demonstrate that value, show that it's like something that you want to actually invest in and then you might want to hire in a leader or help build up the team from there. Feels like that first hire is so important because if they don't do great, the whole role of product ops starts to get a bad tinge within the company. And so there's a lot of pressure on making sure that first person succeeds. I guess more reason to buy your book and make sure that they do it right. If you feel like you as a leader can coach the product ops person and you have

Starting point is 00:49:23 time to coach the product ops person, let's say, through being a good product ops person and getting started with it and directing them, you're probably good at taking somebody who doesn't not have experience, but has the right skill set, and then you can teach them. If you have absolutely no time to coach this person, and they're not super self-directed, let's say. So they're not going out, taking classes, reading the books, doing that type of thing. Probably going to want to hire somebody who's done it before, at least that portion of it. And then that person can help, you know, coach other people grow the function. It's the same thing with product management, right? Like, we look at these teams of a lot of, you know, especially in a lot of transformation companies,

Starting point is 00:50:01 we have a lot of product managers who've never been product managers before and a lot of leaders who've never been product managers before. And they ask me, do I hire in experience leaders or what? And I'm like, well, if those product leaders need to go coach other product managers, then you need somebody who's experienced in there, right? You need somebody who knows how to get that work done. If they don't have time to learn, if you're not on a timeline to actually like teach these people these things and get them up to speed, then you need somebody to hit the ground running. So I'd look at it for like how much time do we have to demonstrate value, how much coaching is available to get this person into the right mindset and the right skill set to do this and execute.

Starting point is 00:50:38 And I think that that's needed in almost every role, not just this one. Right. And one thing I wanted to mention was whether to hire products or product manager person for the role with the background of product ops or product management. There's not a ton of folks out there that have a products title. But as you're looking, you know, dig in because this person may have been doing a lot of the work, but as a product manager or within that title. So there's a lot of people out there that probably would fit that profile, but not with a proper product's title.

Starting point is 00:51:09 What are the key skills that you find are really important for finding this person, especially if they don't have this role? My guess is dependent on the pillar. if they're data focused, research focused or process focused, what do you suggest to make sure you're looking for it when you're hiring this person? With the business data and insights, like you're looking for somebody who's really good at interpreting data,

Starting point is 00:51:31 telling stories with data, somebody is good at communicating to many different types of stakeholders about the data and putting it into useful ways. What I wouldn't hire for that role as a first person is like a data, it's not a database engineer, right? Like, that's not what we're doing. We're not like sequeling, like turning things into the right SQL tables. Like, we're instead trying to get the information out of the SQL tables and make sense out of it. So we actually find people with consultant backgrounds are really good at this because they're usually churning

Starting point is 00:52:04 out these types of, you know, reports and stuff for PE firms, VC firms and whoever, you know, whoever were their clients to begin with, what would be ideal is if that person has a lot of experience with a BI tool like Looker or Tablo as well, and they could use it. That's not always the case. Sometimes those people are really good at Excel and PowerPoint, but they're not great at the looker and BI. Like if you could find that two things together, though, like home run right there, right? So this person's probably a data analyst background. We did have like a business intelligence background like you were talking about as well. Something like that for the business and data and insights role. It does not have to be a product manager.

Starting point is 00:52:46 I think you can help them steer them in the right directions for what questions you need to answer. They shouldn't be the ones coming up with all the questions you need to answer. It'd be great if they surface some insight. But like you ask them the questions, they can go get the answers. What about for the other two pillars? Well, in terms of the process and practices, I think, you know, this person really needs a super high EQ, right? Kind of understanding what the needs are, but also has a good sort of spidey sense of, you know, how much, sort of methods do we need to sort of think about bringing to the team and thinking about how those

Starting point is 00:53:22 things get introduced, that it's not a mandate, right? But it's like a suggestion of how we can work. And typically product managers will be pretty open to that, right? Because if they're like, I don't know what the roadmap template is, I don't know what the roadmap cadence is. Here's some guidance. Awesome. Now I don't have to think about how to do it. I'm just going to do it. So I think someone who has a lot of experience sort of understanding sort of the underlying tensions and opportunities. And then feels good and understands, you know, how to sort of implement the system's thinking and also understands it's not as set it and forget it, that they're sort of constantly

Starting point is 00:53:57 sort of reevaluating the processes, the tools, are these working for us? And then understands, I think, and more broadly, you know, as my CPO is getting ready for a board meeting, what are the inputs they're going to need? As we're getting ready for the QBR, are the PMs ready? Do we have a cohesive stories? Anybody taking the time to look at all of the different presentations to make sure that we're sort of giving the same perspective or sort of building towards a certain strategy that everybody's focused on? So that would be my advice. I think for customer and market research part, you're looking for somebody with more of a user research background here, but process oriented.

Starting point is 00:54:38 So I'd look for somebody who knows user research cold, knows really good tactics for that, right? it can help create the toolkits, get the right type of prototyping, usability software in there. They know what good interviewing looks like, that type of stuff. But they're also got this kind of need to make things better. So they're like, I need to create a system to do this, right? They're good at operationalizing stuff. I think that's a skill for everybody. They're like, I can build a system to fix this.

Starting point is 00:55:07 That's actually a really good interview skill that I would ask of product opsers. And I never came up with it. I never thought about that before, but it's like, tell me about some kind of process or some kind of thing that you had to do in your job that you really hated and that you ended up just trying to automate away or like build a system around it to make it better. That would be a great interview question for anybody in those roles, I think. With the user and Market Insights person, too, there's not a ton of people out there doing this, but there is a little research ops movement out there that I think could be really valuable here. So Jen Cardello, who is our case study on Fidelity, she runs. their user insights team there. And she's our VP of, I think,

Starting point is 00:55:47 is user insights. And she does oversee all their user researchers as well, but she also oversees a research ops team. And the research ops team is responsible for building their participant database. They also help build toolkits for people to do user research. They oversee any of the user research tools.

Starting point is 00:56:03 They also go out and train other people in doing good user research. So with them, that looks like not everybody's allowed to go talk to customers and financial firms like this because of compliance reasons, they make sure they certify people to be able to go do good research up to certain points and they get levels for how far they can go so that they can democratize the research and help put it into their hands. And then if there's compliant issues around different research studies, they come back to Jen's team and the user

Starting point is 00:56:31 researchers will help them complete it. So it's about how we, you know, there's a lot of legal things about what you can say and what you can't say to customers and stuff like that and what you can ask them and that they're navigating those complexities around there. So Jen, um, Jen comes from a research ops background. Like she comes from a whole UX background, but research ops is like her thing. And she's fantastic at like setting up that stuff. And she and I worked together at Athena Health and she did that there. So I watched her put that into place and it was amazing. And now she does it at Fidelity. So if you find somebody with that background, golden. But if you find somebody who, if you can't find somebody like Jen, because there's only one Jen.

Starting point is 00:57:09 You should look for somebody who has at least a user research background, probably some kind of UX background. They're really good at doing that, and they want to operationalize it. Jen's about to get a bunch of LinkedIn requests, too. Sorry for your inbox, Jen. I feel like the research team is going to hate people now for pulling your into product ops. Who would you suggest product ops report to, generally, at least to start?

Starting point is 00:57:34 Head of product. CPO. So such a clear, quick answer. I love it. And how do they find time to, you know, train and work with this person? Are they kind of like the right-hand person that helps them just make everything more efficient? What's that way? What's that relationship like? I think definitely like their right-hand person. And we say to a lot of CPO's, especially like high-growth companies, like make your first hire just a product ops person to help you get this data out and start looking at it because that helps them with forward meetings. It helps them set strategy. And usually when you walk into. a growth stage company, that's the first thing that you need to do is make sure that it's working, that you need to set it. Typically, when you're getting hired, there's usually a strategy problem. And that person is, they're like your right hand man, right?

Starting point is 00:58:17 Trying to operationalize that. So I definitely think that you're going to be guiding them there. I think this comes back to our question, though, about do you hire somebody with experience or do you hire somebody who's new to it? If you as a CPO don't have a lot of time to train up somebody on product ops, because you've got 8,000 fires to fight, then hire somebody with experience, right, who knows how to do it and operationalize it. If you're like, my biggest issue is business data and insights, for example, right?

Starting point is 00:58:47 And I just need to get my data so that I can do the strategy pieces and then I need to think through and work through what I want product ops to look like. Maybe then you just hire the data analyst. and it's pretty, if they're competent in the data analysis piece, it's pretty easy, I haven't done this myself, to teach them about what types of information you need to see. As a product person, they're going to need a lot more handholding at the beginning because they're not going to know all the different cuts of data. But it's not an investment of an inordinate amount of time, right, to be able to get something valuable back.

Starting point is 00:59:20 It's not like training for 40 hours a week and then waiting six months to see results. It's more about, I need you to go pull these types of cuts. here's why. Let me explain to you this so that you learn it and then you can think about it next time, but that's going to help you there too. So I think it really depends, though, how fast you need product apps fully rolled out and then how much time you have to train people and then where you're starting from there and how big and how much buy-in you have to grow this thing from the get-go. Awesome. Maybe as a last question, I'd love to go through a quick case study of a company you worked with and just kind of share how maybe how you rolled it out, what you ran into

Starting point is 00:59:59 challenges you had to overcome and maybe the benefits and impact that adding this role had. When I was at Athena Health, we were doing a, Athena Health has always been a software company, so let me point it that way. But they didn't have a formal product management role. And they had just implemented it when I came in. So the chief product officer brought me in. He did not have an extensive product background. So he said, I need to train all these product people and like figure out what to do with this organization. So I came in to help him do that. We had over 360 product managers. We had 5,000 software developers there and it was a massive platform, like $8 billion in market cap, I think, electronic health record system. So this is where

Starting point is 01:00:43 I started to realize we needed product ops. Like this was me discovering this. So I'll tell you how we rolled it out and probably what we would do differently next time. But we had trained all the product managers. People were starting to use a lot of the things that we were teaching. We saw that the maturity was getting a lot better in the organization, which was fantastic. But then we started to run into these problems. And these problems that we found could not be solved by just training product managers. And that's where the concept for product ops came up. We also realized we had way too many product managers, like just way too many product managers. There was like one person reporting into one person all the way down. And we were like, this is not helpful.

Starting point is 01:01:22 So we ended up training everybody, teaching people about what the role was, and then thinking through as we encounter these other problems, like, what else do we need besides product managers? And product ops became one of the things. We also had people actually move out of product management into other roles. We had people become data analysts. We had people become user researchers. We had people, you know, go into other parts of the organization. But a lot of people after we trained them actually just self-selected out of product management. And some of them did come to us and say, what else is there?

Starting point is 01:01:52 And when we looked at the product ops role, we said, okay, what are the big fires that we have to, like, fight? That's just not from a lack of skills perspective. And that's a big part about product ops. It's not a replacement for product managers or product leaders not having product management skills. It's to help skilled product managers and product leaders do their job better. So this will never replace the fact that people don't have the skills to do their job. So where we ran into issues was, one, getting insights back to the executives on what the teams were actually doing. So the CEO and I were like sitting there trying to set strategy and set

Starting point is 01:02:31 the vision for the company. And I was helping him formulate it into like written forum and help him deploy it and think through like where we wanted to go. And he was like in Jira digging around in Jira trying to find information on what people were working on. And I was like, you're not going to find that in Jira, especially when we've got like hundreds of thousands of tickets for 5,000 people, right? Like, you're not going to find this in there. And that started to show me like, hey, he's looking for this. Like, what do you want to see?

Starting point is 01:03:01 He's looking for like a portfolio roadmap, right, of what everybody's doing. And he wanted to see what are the big pushes we're making from a feature perspective and how do they tie back to our overall strategy and our goals, right? Like, what's going to help our retention? What's going to help us get new customers? What's going to help us move into the enterprise, which was a big thing we were doing, going upmarket into hospitals. And we had no transparency into the allocation of R&D on that and also the roadmaps on that. So one of the things that we were

Starting point is 01:03:30 trying to do in product ops was build that view, right? Like try to figure out how we get people to put the right information into Jira at the right level. So we actually had to train people on how to write at the times we only had Jira. So like epics in Jira that were not just like build a button, right? Like, they were more substantial than that. They actually had some meat behind it so we could look at it. And then we had to go out and find the right software to roll that up into a portfolio view so the executives could get the insights they were looking for. We also had to build a way to track the OKRs that were deployed, right, and actually see where it was. So we had to build the dashboards for that. So we started there, and that became really important because that was a big

Starting point is 01:04:11 issue was just the executive visibility. How do we make consistent roadmaps, across the organizations, how do we get visibility into what's going on? And as we started to identify more and more things, we said, we're a huge team. We should actually have somebody overseeing this. Data and Insights was a really big issue in the company in general. And we knew we had to instrument things better. And at the time, they brought an amplitude and they were starting to put an amplitude everywhere in the organization. But it wasn't fully rolled out yet. So we had these people who are going around trying to help the individual product teams get the information out of amplitude. And we said, we need this to be more of a consistent thing, like a consistent

Starting point is 01:04:51 program. So that kind of sparked the need for having our first product operations leader. So we ended up creating a VP of product operations and somebody moved from the product management role into that. She was much more of a process type person. She wanted to really help arm the teens into being able to get good data out there, but she understood product management well enough where she knew how all this stuff worked, and she wanted to create the systems internally. So reporting into her,

Starting point is 01:05:19 we had a business data and insights team that was overseeing Amplitude Rollout, and they were also putting people around the director level, overseeing usually like five to, let's say, eight scrum teams on the director level, sometimes smaller, just depending on the product. We had a business data and insights person embedded at that level to help get the ad hoc reports out now because we weren't well instrumented.

Starting point is 01:05:43 We said we're still making the programs and the shared services at the top level, but these people need to make decisions today. So how do we get them to do that? So she oversawed that team. She had somebody directed there. And then we also had the people looking at the portfolio views and the governance and the rollout and the rollout of that getting put into that as well. So that helped us kind of get going with that.

Starting point is 01:06:07 And on the other side, so this didn't fall under product operations at the time, but like I said, Jen Cardello was doing research ops there and leading this team around the user insights and getting all, she got the participant database out. That was fantastic. She got out a bunch of different user research tools. They made a design systems database too that helped us be able to do prototyping a lot faster and have consistent design processes, which was amazing. The head of UX reported into the chief product officer. So it still fell under the, a CPO, but it reported into the head of UX on that side. And that was totally fine because we just collaborated with them like pretty much all the time. So that's how we started to roll it out and get going.

Starting point is 01:06:46 And that's where that need was. And it became so much better to get the insights that we needed out there. And then what happened was actually Athena Health at this time. It was really wild. It can private. So this is where I left and a lot of leaders left at the same time. But they ended up restructuring it. And they actually kept the product ops team.

Starting point is 01:07:05 So now to have. Davenport oversees product ops team. He was the chief of staff for the chief product officer at the time, and he's been building it again, you know, taking it, taking the stuff that worked and then building onto it. And they're actually one of our key studies in the book as well about what Tim's doing now and how he's kind of orchestrated as well to help with OPEX and CAPEX and accounting type issues that they were having to.

Starting point is 01:07:28 So Athena Health has been through many different restructuring since I've been there. But they have always kept product ops and their current chief product officer is said that he will never go anywhere else that doesn't have product ops. Like that's how much he believes in it. Wow. What a testament to the value of product ops, 100% retention on the role through all these transitions. One of the interesting things you said is within this product, this VP of product ops managed a bunch of different people in teams, which is really interesting because I always imagined product ops VP would manage product ops people. Is that common where they lead, say there's a data team you mentioned a few other

Starting point is 01:08:05 teams? Yeah. In this case, we did have her managing the business data and insights people, and they were kind of data analysts. I wouldn't say they were like data engineers or anything like that, right? But they were people who were really good at pulling SQL and analyzing data from a product perspective. We actually moved, I should say this as well. We moved a lot of people who didn't want to be product managers, but were good at that out of the role and into that role. So they had some product background. They've been trained in product. They were really good at the data pieces, but they were more suited for that than they were suited for product management. And like I said, a lot of people opted out. They were like, get me out of this role. I don't

Starting point is 01:08:39 want to do this. They wanted more of like a transactional type role or diving into data. And a lot of it came down to, I think people under anticipate how much they're going to have to deal with stakeholders. And once they have to, they're like, oh, God, I don't want to do this. And I see that like over and over again when it happens with product management. But so she oversawed them, But they did work closely with the data people on the CTO side. There was a whole data team on the CTO side who were doing more of the database administration and the instrumentation of things. And they were also helping to roll out like amplitude, instrument it correctly,

Starting point is 01:09:18 and building like the right views and things like amplitudes or the other product analytics or other tools that they were using. We did not have Tablo at the time. That was something that was like added later. But they were in charge of like kind of utilize. the data and trying to build those insights. Amazing. With that, we've reached our very exciting lighting round. I've never done this with two people. We'll see how it goes.

Starting point is 01:09:39 So you can pick the question you want to take or both answer. Here we go. What are two or three books you've recommended most to other people? I'll take that. Of course, escaping the build trap. It's true. Okay. I see that. Another one that I recommend is called Traffic. It came out this year by Ben Smith, kind of around the growth and invention and growth of Huff Po and Gawker and whatnot. I was in media at Condi Nass then, so kind of frifferly part of it. It's an exciting ride that has us, you know, an ending that we all know.

Starting point is 01:10:12 But it's a good story. Good tale. The Art of Action, I think, is a fantastic book on strategy. And I always recommend this to people. And it's kind of like out of the realm. It's a lot of great product management books out there, too. But I like this one because it's like a sleeper hit, I think, in the product management. community. It is a fantastic description of deploying strategy and how you can tell if strategy is well

Starting point is 01:10:34 deployed in organizations or if there's gaps that you need to fill. So I find that when people read it, they go, oh my God, we have all of these problems. And I'm like, yep, that's a strategy deployment and strategy creation problem. That's pretty apparent. So that's my favorite book to recommend to people. I love Teresa Torres's continuous discovery habits, fantastic book as well, just to give a shout out in the product world, too. Next question. Favorite recent movie or TV show that you really enjoyed? Deutsche.

Starting point is 01:11:02 Land, 82, 86, 89. It's on Hulu. Highly recommended. About East Germany. Yeah, really great. I am going to go, I just watch the House of Usher on Netflix. I love the,

Starting point is 01:11:19 it's Halloween right now. So, well, it was just Halloween. So I was watching all the scary movies, but I love the Netflix genre of everything from the haunting of Hill House. Those were great. Amazing. I started watching that and then I gave up quickly, but I should give it another chance. My wife and I have been stuck on Love is Blind.

Starting point is 01:11:37 Classic. Same. Good one. What a terrible, wonderful show. It is. It's the high-low. Next question. Do you have a favorite interview question that you like to ask when you're hiring people?

Starting point is 01:11:49 When was the last time you changed your mind about something really important and why? So do they have sort of a learning mindset? Do they have self-awareness? Can they acknowledge sort of where they were and how they evolved? So that's usually a pretty insightful question. Yeah, mine's probably tell me about a time that you failed and what happened. That one's like an interesting one too, because if nobody has an example of a time that they failed, that right there is a interesting sign. Two, I feel like everybody tries to turn it into a positive story, right?

Starting point is 01:12:23 Like, they really try to spin it. And I'm like, I don't even want you to spin it. I just want to tell me what you learned. Right? Like, just like, it's fine to say what you learned at the end of that. I think that's okay. But they're like, oh, but this happened. And all these things were great afterwards.

Starting point is 01:12:36 And I'm like, I'm not looking for a fantastic outcome. I'm just looking for. Did you fail and did you learn something from it? Right. Do you have a favorite product you've recently discovered that you really like? Well, there's like one I'm going to have to plug. It's not that I recently discovered it. But I talked about.

Starting point is 01:12:53 all the issues that we had at Athena Health with the portfolio management system. And after that, I discovered Dragon Boat and I'm now on their advisory board. But it helped me solve that problem. So much of like rolling up everything that was in Jirut sits on top of it and being able to look at it in a great view. So like that was so, so good. Another one that I have not been involved with, but that I just really love because I think they're doing great things with, again, in the product ops world is dovetail. And they are. are a research repository out there. And they're also putting AI on top of it

Starting point is 01:13:26 to help generate insights into all the research that's been done. So I have no affiliation with Dovetail, but I really love what they're doing because I've had that problem of us rolling our own research repository like over and over and over again, and now we've got a tool out there to do it. I guess the one I would mention is Vistoli. And some product later

Starting point is 01:13:48 as I'm working with right now, we're sort of playing around with it. And it's kind of an interesting tool that's kind of a single workspace that you can connect your strategy and discovery and delivery visually and kind of guides people along those paths as well. So interested to play with it more, but it piqued my interest. Do you have a favorite life motto that you often repeat yourself, often share with someone, come back too often to help either with work or with life? Mine's both, especially with teams that I'm working with or cross-functional stickholders,

Starting point is 01:14:21 is that if you try to serve everybody, you serve no one. So it's about honing in on who you're actually building your product for, who your persona is. And then with my children in terms of, you know, try to be everyone's friend, but it may not happen. So it kind of goes both ways. What's the worst that can happen with most of the things that I've done? And to me, when I get scared about something or trying to do something

Starting point is 01:14:48 or even like interpersonal reactions, right, where I'm like, God, I have to have this hard conversation with this person. Like my brain, I try to tell myself, like, what's the worst that can happen? And usually when you sit down and start to think about it, it's not as bad as you anticipate. So for me, that's always helped me manage my anxiety around difficult situations or we're taking a leap and trying to get out there. And I think in my younger days, I was a little crippled by overthinking and by being too anxious about things and not taking big leaps. So I've tried to stick by that and keep asking myself, what's the worst that can happen? And it's usually not as bad as you think it is.

Starting point is 01:15:27 I love that. Final question. Since there's two of you will end in a really sweet way, what's one thing you really admire about each other? Melissa is kind of a legend, right? But behind the legend, she's just a really great collaborative person. So, of course, we got to know each other really well, writing this book together. We worked together before that, but it was a really great way of staying connected to, you know, a former colleague, someone in the industry. And especially during COVID, it was a really great way of sort of building towards something that was bigger than the both of us.

Starting point is 01:16:04 So what I love about her is that she's really revered by so many folks, but really approachable and really truly wants to help people. Oh, thanks Denise. What I love about Denise is she's really this calming patient presence. And she approaches everything with so much professionalism, but also can really get to the meat of the problem, help calm down certain situations, right, where they've escalated, turn them around. And she's got this like patience and calm about her and everything that she does

Starting point is 01:16:41 that helps you focus, helps you concentrate on the, big issues and she can really steer people in the right direction. So to me, she's always, I've always admired watching her, like, coach and lead people. And she, she led her analysts at products labs as well. And when things would go, you know, slightly awry or a situation would go out of hand, Denise was always like, nope, we'll just fix it. And dove in and was able to, you know, to make it better. And I always really appreciated that. Oh, shacks. We might have had a few of the what's the worst, what's the worst it could happen moments. Yeah, right?

Starting point is 01:17:16 Always. Amazing. You two are awesome for folks listening. Make sure to grab their book, Product Operations. You can find it on Amazon, I imagine. Share where else people can find it. But two final questions, where can folks find you online if they want to reach out? And how can listeners be useful to you?

Starting point is 01:17:33 Product Operations.com, we've got some downloadables that are available for folks and questions if you want to get in touch with us. How can they help us? I'm trying to think here. Tell us your stories about product operations. Yeah. We want to hear like how people are implementing it, what's working, what's not working. Like we're always learning about this too.

Starting point is 01:17:52 And I think we said in this book, it's still, it's taking off now, right? But it's by no means standardized. So we want to hear about what's happening. How is your company, you know, been successful or not successful with it? What have you seen work? What have you seen not work? So definitely reach out and let us know about it. Also, you can help us by buying the book and leaving us an Amazon review if you do read it

Starting point is 01:18:11 because that does help authors. And we self-publish this one. too. So that always helps us on there. You can find both of us on LinkedIn Perry, I think, on there. But if you look for Melissa Perry, I usually pop up and Denise Tillis. And then if you want to contact us, yeah, product operations.com. We got a forum on there to reach out. Product Operations.com. And is that the best way to find where to buy the book or there are other sites you recommend people go check it out? Yeah. And we do, we just got it. Self-publishing has been fun. But we just got it where it is distributing now to like Barnes & Noble and other bookstores.

Starting point is 01:18:46 So you can usually find out on anything. But if you go to the website, it will have the most up-to-date information on where you can find it. Then if you go to your bookstore and if you, some people are against Amazon. So if you go to your bookstore and ask for it, they will be able to order it for you. Amazing. Thank you too for being here. Thanks for having us. Thanks for having us. My pleasure. Bye, everyone. Thank you so much for listening. If you found this valuable, you can subscribe to the show on Apple Podcasts, Spotify, or your favorite podcast app. Also, please consider giving us a rating or leaving a review, as that really helps other listeners find the podcast. You can find all past episodes or learn more about the show at lenniespodcast.com.

Starting point is 01:19:28 See you in the next episode.

Lenny's Podcast: Product | Career | Growth - The ultimate guide to product operations | Melissa Perri and Denise Tilles

There aren't comments yet for this episode. Click on any sentence in the transcript to leave a comment.