The ultimate guide to product operations | Melissa Perri and Denise Tilles

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 the 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 PM book *Escaping the Build Trap*. 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. She works with Melissa at Products Labs.

In our conversation, we get super deep into the emerging role of product ops. As you'll hear, over the past few years, this role has gone from almost non-existent to something like half of scaling tech companies having at least one product ops person. 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. Plus, we discuss a case study on how they rolled out a 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 imagined. 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 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, 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. 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 Jira Product Discovery. Try it for free at atlassian.com.

Thanks for having us! You are 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 out, which I have right here. It's called *Product Operations: How Successful Companies Build Better Products at Scale*.

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. 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. OpenAI, 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?

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 too, like Uber. The head of product operations at Uber and the person who started it, Blake Samic, is a case study in our book. 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.

We have seen a very good transition from people kind of whispering about product operations. I know when I wrote my first book, *Escaping the Build Trap*, in 2018, I mentioned it in there because we had just started doing it at Athena Health. I saw this as a really big issue in trying to make a complete product management function there, especially at scale. We had 365 product teams, and we were trying to figure out how this all comes together. Product operations for me was a key part of it.

When I first wrote it into that book, a lot of people were like, "Oh, what is this thing? I think we need it. Do we need more?" That's what got us to start writing this book. 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.

If you had to put a rough percentage on some interesting fast-growing hyper-growth startups, would you say there’s a percentage of how many of them have a product ops person at this point?

We don't have a hard and fast number on this, but we have seen that—let's take a sampling of maybe something that I know better. When I teach the CPO accelerator, out of the 20-25 people that we'll 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 master class for Products Labs with Melissa, and it's been interesting. I sort of do some pre-work and try to understand where folks are in the product journey. When we started offering this class in 2020, about 60% were product 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, but just like sounds like maybe after your last book was published. Is there a time frame of when this became a thing? Is it this guy you mentioned that's now at OpenAI 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, 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 2019 is when Pendo started talking about product operations. So it was 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? 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! It sounds like maybe just in the last few years it started to really take off. We actually had Christine from Pendo on the podcast talking about product ops about a year ago at this point, so this was a great follow-up to a lot of that.

Before we talk about what product ops is and what the functions are, 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?

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 in managing teams. More and more product managers are taking on the data harvesting, the data implementation, and just to get data to work with. They're spending, you know, 20-30% 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.

Again, when I was a PM, I had no product ops person, and having read your book, a lot like basically all the things product ops does is stuff PMs historically have done. To me, it's 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 manager starting to hear about product ops and this fear of, "Oh man, my job'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 decision-making rights from the product manager. It's there to inform them. If you're judging your success as a product manager on, like, "Hey, I do the SQL queries, and I have to spend 50 hours to set up all these customer interviews and calls," 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.

That's why we're looking at the product operations team. What I've seen is product managers doing this off the side of their desk, like me too, right? I got excited about this because when I was at Open Sky, in the early days of my product management career, I had to go learn MongoDB to get data out of a database. 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 correctly.

That was a lot of time that I spent doing that instead of spending it on good feature work, right? 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. That, to me, is the stuff that product ops takes away from the product managers.

What I constantly hear from product managers, though, is, "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. 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 so many things you have to do, so I totally get how this is happening and why this is happening. 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 people hear product ops and they don't know what it is. There's 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 the 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 to more than just one customer.

Finally, the third pillar is process and practices. 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 just to kind of reshare what you just said, the three pillars of product ops are business data and insights, customer and market insights, and the process of how you build product and help 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 described in your book. So well described!

Is there one of these three that you find most important or impactful? Is it really dependent on the business and their needs or what the PM wants to do? How do you think about which of these three is maybe most important, or is it super dependent?

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 right inputs. We see larger companies and enterprises kind of go more towards the process and governance, especially if they're in, let's say, a transformation because they don't have the infrastructure to run good product.

Let's say it that way, right? They're usually just starting out. They're just forming their teams. Let's say they just trained 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.

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 product, can actually just have transparency into what my teams are doing? And like Jira does not work for that, right? 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 into 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 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 a bucket for the middle pillar of customer and market insights, or is that kind of spread across?

That's a squishy middle. When I do teach this class, I ask people sort of like what their perception is of product ops, and that's an area definitely for growth, I think, at a lot of companies.

How does that piece work with user research in that team?

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

There are great tools out there like Dovetail, but you can 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 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."

If we can build a database of people and customers that we have who opt into those types of things, it makes it 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, and they know what the cadence is that people will reach out to them on to do research. 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. So this is not about taking user research away from product managers or from user researchers. It's about 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 getting qualitative insights from sales and support. We always hear from sales teams, and this is like the classic product management tension: "The product managers aren't listening to me," or "I've told them five months ago that I had this problem with these customers that were going to churn, and we didn't build those features."

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 back in strategy, let them know where we stand with working on those ideas or solving 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, or in somebody's Google Doc of their customer interviews that they've been doing. 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? What's the future of product management?" I'm always like, "Nothing. It's always going to be basically the same. 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. 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 wanted to do.

So I think that's pretty amazing. 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 another 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, like you were saying, product management was kind of this squishy role for a long time, but now we're kind of standardizing what do product managers do. What's happening, I think, though, is product management has 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? 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, product managers don't have time to go do all these things off the side of their desk. It's fine when you're 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. Then we start to scale, and I've got more and more product responsibility, and I'm like, "I don't have time to go learn MongoDB now."

That's where people start to burn out and where they get frustrated, like you said. 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 the 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 this. I imagine PMs listening to you saying, "I don't have to learn MongoDB and SQL anymore," would think, "That's actually good!" They should learn to do SQL and run their own data, but I think the important piece is 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.

In theory, it would be awesome if your PMs could run their own queries and do their own research and create the whole process, but it just becomes harder and harder. It reminds me of a lot of companies trying to delay hiring a product manager in general and instead giving the role to engineers and designers. My feedback is always like, "That's great as long as they want to be doing all these things that are not generally what they enjoy doing."

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 your actual job you need to be doing. If that's your full-time job and your OKRs and your goals are really around the outcomes for the company, you're like, "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. I also think it's funny how many people want to be a product manager until they realize what product management entails. This happens a lot, and I saw it with my MBA students at Harvard too. We do a whole class; they'd play a product manager. A lot of people opt out of being a product manager at the end of it. They were like, "I did not realize it was like that!"

I did not realize I had to do so many things. I think a lot of what gets them as well is the 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, like user research, working with the designers, working with the developers, working with executives, working with different stakeholders. You got to context switch to be able to relate to all of them. You got to empathize with all these different people. You have to do all these different tasks to do this type of work.

Then you got to go figure out what template to put your roadmap in, which is going to be a different template than the other 80 product managers on your team because somebody didn't come in and just say, "Hey, we're going to use this." That type of work, to me, is just distracting from it.

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, and make sure it's in the right formats, make sure it's in the right software, that is where the overhead comes in, right? 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.

I work with all these CPOs, these VPs of product, and they're like, "I see them just not working on strategy." I'm like, "Why are you not working on strategy?" They're like, "I don't have time to do that, right? I'm in here stopping all these fires. I'm figuring out 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. 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.

To me, 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 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. That's not the point. They're the product manager for the product managers; that's how I think about it, right? So their decision 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? And that's not their job. If they are coming to you and saying, "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. 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, "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 reading through all this information and being like, "You should build this."

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 got together. Can you go monitor the developers and make sure they're building it 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 conversations about trade-offs for you. Like all of those things that you're 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.

I took a couple notes of just things that the PM continues to own, what in quotes, you know, no one owns anything: strategy, vision, prioritizing, resource allocation, trade-off decisions, hard conversations around trade-offs, and stakeholder input and things like that. Is there anything else in that kind of bucket of just stuff a PM, a product manager, continues to be responsible for?

Well, there's a big piece here we're missing: a good market. That's where product ops can really make a difference in terms of connecting those teams, but also being sort of the first point of contact for sales, first point of contact for product, and enabling just some efficiencies.

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 has a big challenge with that, and it's a large enterprise-level company. So how do we break down all 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 are some sort of simple templates we will use, 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 product ops will take on a lot of the coordination of those types of things and make them standardized templates. But a product manager, like your role in informing what the go-to-market is, doesn't change, right? Like you're still putting the inputs in there.

So maybe product ops will provide, for example, templates and help say, "Hey, here are the different pieces that we need to make a go-to-market plan. Here are 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 work with the marketing people to make sure it's positioned correctly.

But the product ops person can help with the kind of 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 not going to find them everywhere, and then making sure that the 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 a 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?

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.

A program manager, I think, is really thinking about larger company initiatives, and the duration of their work is ongoing versus a project manager. They're responsible for a certain project that's got a time box and an end date, but it does get a little wavy 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. What are the jobs of a product 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?

A lot of companies will have a data science team or a business 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, 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 through a product lens and then making sure the product managers actually know what to do with it, can action it. So it's essentially writing 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 would 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 really critical for leaders and executives, right? A lot of times—and like I sit through board meetings where we talk about ARR, we talk about retention, we talk about net retention, we talk about all of these business metrics, right? And they're great for monitoring the health of our business.

But where product ops comes into play and 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 as ARR by customer segment, right? It's not as interesting as ARR 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 by product, right?

When we start to put those lenses on it, they now become really powerful strategic insights. So what I think these people do and do really well is even at the executive level, they help you. You, as a product leader, are 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 just in service of the product managers, and I just wanted to 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, "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 adopting different product lines, right? Are you looking at how the enterprise uses different features? And if certain enterprises are using 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. 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. 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 have 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. We had a couple analysts at Products Labs, and they were, you know, ex-McKinsey, ex-DOA. They didn't know anything about product, but 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."

They were able to pull those things together in views where we could actually dig into it, but that was the jumping-off point on the quantitative research where we're like, "Okay, now we need to go do the qualitative."

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 and understand trends, and a lot of times too, if you're putting this stuff in Looker or a BI tool, 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, and you still need to understand 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 marketing launch on Thursday, like that's why all of a sudden we got a million signups on Thursday and we didn't get a million signups on Wednesday.

Like they still need to understand all those things, and I don't think that becomes any less important, and I don't think understanding 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 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. 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 Fora, Brian Budhub, and he said, "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. When we go do it manually, it becomes obsolete by the time the board meeting's over, and then I got to start again and prepare for the next three months and do the board meeting again."

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 imagined. 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 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, 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. 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 Jira Product Discovery. Try it for free at atlassian.com.

People, that's generally a sign that something is not efficient and it could be made more efficient with software and product. Not everything can be productized, but do you have a perspective on that? That ops is a sign where, like 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? 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 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, 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.

So when 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. 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, still relevant, still works for our company and stuff like that.

But you're going to have a smaller subset of people doing that. It's not going to be like, "Oh, I need a product ops team for every product manager that's on here." Like 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 say 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 and fast rule on that one, but I would say if you're at a one-to-one ratio, like you're doing it wrong.

Absolutely!

You're at 100, you're doing it wrong.

Yeah, yeah.

I also think it's like, so when we talked about it too with this hybrid versus shared services model, if you have a hybrid model, let's say, and typically this is a symptom that your data is not well instrumented. Let me put it that way as well. Sometimes you need a stopgap holdover until you can well instrument your data or something, right?

And that could be as long as it takes for a certain company. 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 product depending on how much help you need to get 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, 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. 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 massive org within a company. 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. That tells me there's a lot of leverage that you can find from just like there.

Yeah, we say too, like get started with one person. We describe these three pillars, and you know, repeatedly if you're the book, we're like, "Hone in on what's the most important part for you that's going to help you right now."

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 stuff that you need to get done. 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, 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.

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. That person needs to be a product background person because they're usually helping 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.

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. We do see this trend of people throwing agile coaches at this, and agile coaches who have never been product managers before in a well-run company 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.

We don't usually need another agile coach telling us how to run a standup. We need people to come in and help us figure out 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. And they want to know, like, what are the big pushes that we're doing to help us reach our strategic objectives, right? So it's helping it—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 you might need a couple different people in this organization because the roles are slightly different.

Exactly for the market research and the customer research thing too, like you might need somebody with a user research background for that, somebody who did research ops is a great person for that. 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 starting organically.

I think the way Christina Taro 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 these roles. It might be someone being allocated part-time from their PM role and 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. You've already talked about a bunch of tips there, and by the way, if you buy your book at the end, there's this really beautiful little guide there. You go, see on the camera, just like a little yellow brick road of all the steps that it takes to roll it out.

On this topic of just who to start with, it sounds like you recommend starting with one person. What I'm hearing is pick one of these three pillars that you think is most high leverage potentially to take off your product management plate. Is that right?

Yep!

Okay, and then what else should people be thinking about in starting to roll this out, starting to build this team?

That's a great question. So one of our case studies is Shintaro Matsui at Amplitude, and he created the role at Amplitude. You think about it, it's kind of meta, right? 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. The case study that we chatted 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. That was his top tip: 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 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 and 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! If someone set it up somewhere, I mean, look at Blake Samic, 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 Samic, I would say definitely do that, but hard to pull him away from OpenAI.

Yeah, I don't think he's leaving there right now. He just started; he's got a lot of work ahead of him.

But got a lot of LinkedIn requests right now.

Here they go!

Yeah, it's like poor Blake. Sorry for your inbox!

I think too, it's about if you're going all in, right? If you're just trying to get by 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," but the company's 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 are 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 streamline it?

That helps free up the leader as well from not having to go find 8,000—not it's never going to be 8,000 people—but like eight people 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 issue is, demonstrate that value, show that it's 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.

It 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. There's a lot of pressure on making sure that first person succeeds. I guess more reason to buy a 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 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 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, you probably want to hire somebody who's done it before, at least that portion of it. Then that person can help coach other people and 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, 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. They ask me, "Do I hire in experienced leaders or what?"

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 teach your 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? I think that's needed in almost every role, not just this one, right?

One thing I wanted to mention was whether to hire a product or product manager person for the role with the background of product ops or product management. There are not a ton of folks out there that have a product ops 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 ops title. What are the key skills that you find really important for finding this person, especially if they don't have this role?

My guess is it's 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 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, telling stories with data, somebody who's 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 SQL 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 out these types of 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 Tableau 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 or BI. 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. 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 have some insights, 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 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 the underlying tensions and opportunities and feels good and understands, you know, how to sort of implement the systems thinking and also understands it's not a set-it-and-forget-it, that they're sort of constantly re-evaluating the processes, the tools—are these working for us?

So, and then understands, I think, 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 story? Is 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, you know, 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. So I'd look for somebody who knows user research cold, knows really good tactics for that, right? Because 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."

That's actually a really good interview skill that I would ask a product ops person, and I never came up with, like, 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 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 their VP of, I think, 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. 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 in 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 research and help put it into their hands.

If there's compliance issues around different research studies, they come back to Jen's team, and the user researchers will help them complete it. So it's about how we, you know, there are a lot of legal things about what you can say, what you can't say to customers and stuff like that, what you can ask them, and that they're navigating those complexities around there.

So Jen comes from a research ops background. She comes from a whole UX background, but research ops is like her thing, and she's fantastic at setting up that stuff. 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. 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—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.

Jim's about to get a bunch of LinkedIn requests too! Sorry for your inbox, Jen!

I feel like the research is going to hate people now for pulling her into product ops.

Who would you suggest product ops report to generally, at least to start?

A product CPO!

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 a way—what's that relationship like?

I think definitely like their right-hand person. We say to a lot of CPOs, 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 board meetings. It helps them set strategy.

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 like your right-hand man, right? Trying to operationalize that.

So I definitely think that you're going to be guiding them there. I think this comes back to the 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? 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 to look like," maybe then you just hire the data analyst.

If they're confident in the data analysis piece, it's pretty easy, having 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 hand-holding 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.

It's not like training for 40 hours a week and then waiting six months to see results. 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 ops 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, 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 it. 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.

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 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 I started to realize we needed product ops. 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, and 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."

So we ended up training everybody, teaching people about what the role was, and then thinking through as we encountered these other problems, like what else do we need besides product managers? 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 go into other parts of the organization. But a lot of people, after we trained them, actually just self-selected out of product management.

Some of them did come to us and say, "What else is there?" And when we looked at the product ops role, we said, "Okay, what are the big fires that we have to 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 are actually doing. So the CEO and I were like sitting there trying to set strategy and set the vision for the company, and I was helping him formulate it into written form and help him deploy it and think through where we wanted to go.

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 hundreds of thousands of tickets for 5,000 people, right? You're not going to find this in there."

That started to show me, like, "Hey, he's looking for this. What do you want to see?" 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? 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 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.

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 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?

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.

At the time, they brought in Amplitude, and they were starting to put Amplitude everywhere in the organization, but it wasn't fully rolled out yet. So we had these people who were 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 program.

So that kind of sparked the need for having our first product operations leader. 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 teams 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, we had a data, 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 directory 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, we said we're still making the programs and the shared services at the top level, but these people need to make decisions today, right?

So how do we get them to do that? So she oversaw that team. She had somebody direct 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, 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 CPO, but it reported into the head of UX on that side, and that was totally fine because we just collaborated with them pretty much all the time.

So that's how we started to roll it out and get going, and that's where that need was, and it became so much better to get the insights that we needed out there. Then what happened was, was actually Athena Health at this time—it was really wild in 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. So now Tim Davenport oversees the product ops team. He was a chief of staff for the chief product officer at the time, and he's been building it again, you know, taking the stuff that worked and then building onto it.

They're actually one of our case 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 too. So Athena Health has been through many different restructurings since I've been there, but they have always kept product ops, and their current chief product officer has said that he will never go anywhere else that doesn't have product ops. 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 managed a bunch of different people in teams, which is really interesting because I always imagine product ops VP would manage product ops people. Is that common where they lead, say, there's a data team you mentioned and a few other 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'd 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.

Like I said, a lot of people opted out. They were like, "Get me out of this role. I don't 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 underestimate how much they're going to have to deal with stakeholders.

Once they have to, they're like, "Oh God, I don't want to do this." I see that over and over again when it happens with product management. But she oversaw them, but we did have—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 instrumented correctly and building the right views and things like Amplitude or the other product analytics or other tools that they were using.

We did not have Tableau at the time; that was something that was added later. But they were in charge of utilizing the data and trying to build those insights.

Amazing! With that, we've reached our very exciting lightning round. I've never done this with two people, so we'll see how it goes! 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! One that I recommend is called *Traffic*. It came out this year by Ben.

Smith kind of around the, uh, you know, gross and invention and growth of, um, HuffPo and Gawker and whatnot. I was in media at Condé Nast then, so kind of peripherally part of it. It's an exciting ride that has us, you know, an ending that we all know, but it's a good story, a good tale.

The Art of Action, I think, is a fantastic book on strategy, and I always recommend this to people. It's kind of like out of the realm. There are 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 deployed in organizations or if there are 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? Deutschland 83, 86, 89. It's on Hulu; highly recommend it about East Germany. Yeah, really great. I am gonna go—I just watched the, uh, House of Usher on Netflix. I love the—it's Halloween right now, so, uh, 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 are 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—classic, same, same. Good one. What a terrible, wonderful show it is. It's a high-low.

Next question: do you have a favorite interview question that you like to ask when you're hiring people? 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, you know, 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 an interesting sign.

I feel like everybody tries to turn it into a positive story, right? Like they really try to spin it, and I'm like, "I don't even want you to spin it. I just want you to tell me what you learned." Right? 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," 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 all the ISS issues that we had at Athena Health with the portfolio management system. After that, I discovered Dragon Boo, 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 Jerett.

It 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 getting in the product ops world is Dovetail.

They are a research repository out there, and they're also putting AI on top of it to help generate insights into all the research that's been done. So, uh, 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 Visist, and, um, some product leaders that I'm working with right now are sort of playing around with it, and it's kind of an interesting tool that's kind of a single workspace. You can connect your strategy and discovery and delivery visually and kind of guide 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 to yourself or often share with someone? I come back to often to help you either with work or with life. Mine's both, um, especially with, you know, teams that I'm working with or cross-functional stakeholders. 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, 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, "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 taking a leap and trying to get out there.

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.

I love that. Final question: since there's two of you, we 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, um, collaborative person.

So of course, we got to know each other really well writing this book together. We worked together before that, but, um, 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.

So what I love about her is that she's really revered by so many folks but really, um, approachable and really truly wants to help people.

Thanks, Denise. Um, what I love about Denise is she's really this calming, patient presence, and she approaches everything with so, so much professionalism but also can really get to the meat of the problem.

Help like calm down certain situations, right, where they have escalated, um, turn them around. And she's got this like patience and calm about her in everything that she does 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 meet people. And she led her analysts at Product 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. Asha, we might have had a few of the "What's the worst that could happen?" moments, right? 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? Productoperations.com. You can—we've got some—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 has 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 because that does help authors, and we self-published this one too, so that always helps us.

On there, you can find both of us on LinkedIn as well. I'm, uh, Melissa Jean 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, productoperations.com. We got a form on there to reach out. Productoperations.com.

And is that the best way to find where to buy the book, or are there other sites you recommend people go check it out? Yeah, and we do, um, we just got it—self-publishing has been fun, um, but we just got it where it is distributing now to like Barnes & Noble and other bookstores.

So you can usually find it 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, uh, 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 two 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 LennyPodcast.com.

See you in the next episode.