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 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 Perri and Denise Tilles.
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 handbook, Escaping the Build Trap.
She runs a product management training organization called Produx 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 Produx 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.
This new role is probably the thing that's most changing in the role of product management.
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, 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 Perri and Denise Tilles 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's 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/lenny. That's atlassian. com/lenny.
Melissa and Denise, thank you so much for being here. Welcome to the podcast. Thank you. 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. Let's do it. 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 the 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?
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 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.
We have seen a very good transition from people whispering about product operations, and 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 Athenahealth.
I saw this as a really big issue in trying to make a complete product management function there and especially at scale.
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. Do we need more?"
and 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.
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, these startups, is there a percentage you'd put on how many of them have a product ops person at this point?
We don't have 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 CPO accelerator, when I teach people in these cohorts, 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 masterclass for Produx Labs with Melissa, and it's been interesting.
I do some pre-work and try to understand where folks are in the products journey.
When we started offering this class in 2020, about 60% were products curious.
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, 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.
So it's really fascinating to me to learn about this emergence.
I know there's probably not a date, but just it sounds like maybe after your last book was published.
Is there a timeframe of 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, "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 realtime.
Awesome, and 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 is a great followup 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?
It's really about helping the product managers focus on what they were actually hired for, the strategic work.
In my role on the operating side and managing teams and Melissa as well, 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 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, 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.
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 like, "Oh, man, my job is 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.
So if you're judging your success as a product manager of, "Hey, I do the SQL queries and I have to spend the 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 because what I've seen is product managers doing this off the side of their desk like me too.
I got excited about this because when I was at OpenSky in 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 would stop bothering the engineers to be able to actually just measure if my products and my features were doing anything correct.
That was a lot of time that I spent doing that instead of spending it on good feature work 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.
Never used it again after that.
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.
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.
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. That'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 everyone 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 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 engagement and revenue inputs to make smart decisions, the customer market insights, so the qualitative.
We talked about this a little bit earlier in terms of finding folks to speak to, making sure you're speaking to more than one just 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 the three, just to 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 build product and helping the business operate more effectively in the way they build product.
Sounds great when you say it. Yes.
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, 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 a 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 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's that way.
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 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?"
Jira does not work for that.
You need a portfolio tool to be able to roll that up into something that makes sense.
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 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 a 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 spread across?
That's the squishy middle.
When I do teach this class, I ask people what their perception is of product ops and people never think that.
So that's an area definitely for growth I think at a lot of 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.
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, where product oversees design as well and user research and it oversees UX,
this becomes 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 and the customer market insights piece, which is 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
So there's 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 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.
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.
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 the 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.
So we always hear from sales teams, and this is 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."
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.
Then it also helps communicate back to sales, "Hey, let's be a little transparent about how we're using that feedback."
So that's how we can communicate it back in strategy.
how we can communicate it back in strategy. Let them know where we stand with working on those ideas or solving those problems for customers, but usually, there's a wealth of qualitative information stuck somewhere in our organization systems, whether it's in Salesforce, whether it's
in support tickets, in somebody's Google doc 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? What's the future of product
People always ask me, "What's changing in product management?
What's the future of product management?"
I'm always like, "Nothing.
It's 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 you more space to do the things they really want to do.
So I think that's pretty amazing.
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 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 this squishy role for a long time, but now we're standardizing what do product managers do.
What's happening, I think, though is 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.
We build businesses off of software in today's world and if you're not building software, you are 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 and it's fine when you're a small startup. 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 and I'm like, "I don't have time to go learn MongoDB now," and 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, and it becomes a lot to track.
So it's either, 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 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 this.
I imagine PMs listening to you saying, "I don't have to learn MongoDB and SQL anymore," would think.
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 own research and create the whole process, but it just becomes harder and harder.
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.
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," 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 your actual job you need to be doing.
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 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 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 of 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 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 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, make sure it's in the right formats, make sure it's in the right software, that is where the overhead comes in, 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 not working on strategy.
I'm like, "Why are you not working on strategy?"
and they're like, "I don't have time to do that.
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.
Go roll it out, go train everybody on it, find the right software for it, do it."
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.
So to me, these things are not impossible to do.
It's just do we have the right people doing them?
For PMs that are trying to figure out what remains on their plate, what are the 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. That's not the point.
They're the product manager for the product managers.
That's how I think about it.
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, and that's not their job.
If they are coming to you and saying, "You should build this," that's not their job either.
That's not the right thing.
So making the actual decision and then putting that decision into play with your teams, that's the type of work that you want to hold onto 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, send out the email to invite them to a meeting or operationalize that, hopefully that's automated.
I would love a product ops person to automate that type of stuff.
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 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?"
No, they're not project managers, they're not the people who are going to be on top of your developers 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, 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, whatever, in quotes, 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 bucket of just stuff a PM, a product manager continues to be responsible for?
Well, there's a big piece that we're missing, go-to-market, and that's where product ops could really make a difference in terms of connecting those teams, but also being 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, there's 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 team leads and whatnot?
So it's really talking about, "Here's how we're going to do it.
Here's some simple templates we will use at training sales, training product," and then getting that into play.
Doing the book and doing our research, that was a 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 is product ops will take on a lot of the coordination of those types of things and making the standardized templates, but as a product manager, your role in informing what the go-to-market is doesn't change.
You're still putting the inputs in there.
So maybe product ops will provide, for example, templates and help say, "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 gathered from people," but 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 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 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 go-to-market process is consistent across the organization so that it's not like, 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. 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 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 of product ops is really thinking about, as I mentioned earlier, increasing the speed and quality of decision making and all of the pillars of play into that.
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 certain project that's at a time box and an end date, but it does get a little wiffy, 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 ops person.
So just we could even keep this brief, but just let's say with business data and insights, 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 internal product ops type of intelligence team, but it's about connecting those and making sure you're putting that with a product lens, and especially, say, with finance too.
You don't want all the product managers 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 that product managers actually know what to do with it, can action it.
So it's essentially running queries for you, generating charts and graphs and recommendations based on what the data's 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.
So we're talking about it from a product management perspective, but I think this one especially becomes really critical for leaders and executives.
A lot of times, and I sit through board meetings where we talk about ARR, we talk about retention, we talk about net retention, and we talk about all of these business metrics, and they're 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 as a chief product officer, ARR is interesting to me, but it's not as interesting to me as ARR by customer segment.
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.
When we start to put those lenses on it, they now become a really powerful strategy insight.
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. 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.
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.
It's not just in service of the product managers.
I just wanted to point that out because I think this becomes so powerful for leaders because if 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?
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?
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, it 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.
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 a lot of time.
Is that generally the way you think about it?
Yeah, and I think too, the business and data insights people, they're not going to be experts on product.
They're almost always not.
We had a couple analysts at Produx Labs and they were ex-McKinsey, ex-Deloitte.
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," and they were able to pull those things together in 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."
I think for product managers, you still need to be super comfortable with data.
If you can't read these charts, if you can't see or 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.
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, that's why all of a sudden we got 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.
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 you having to fight your way through bureaucratic processes at your company to get that data.
So product ops can help streamline things that we know we're going to look at repeatedly.
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?"
Put them in a dashboard, put them in a report. Same for board slides.
time?" Put them in a dashboard, put them in a report. Same for board slides. We had one of my friends who's the chief product officer of Forsta, Brian Bhuta, 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, and then 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
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 roadmapping 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's 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/lenny. That's atlassian. com/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.
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, 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.
I think that's why a product management mindset lands 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?"
That what I was meaning by the shared services model.
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.
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, and that's how it should be seen.
So what I mean it shouldn't be obsolete one day, if you are building, let's say, products for the product team, 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, 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 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."
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 thumb or way of thinking about just how many product ops people you want per product manager, per team?
What's a simple heuristic for just how many people you may need?
I don't have a hard and fast rule on that one, but I would say if you are at a one-to-one ratio, you're doing it wrong. Absolutely.
If you're at one-to-hundred, you're doing it wrong. Yeah, too.
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, and that could be as long as it takes for certain companies.
In this case, like we said, you might have a business data and insights person aligned to every director of product who oversees multiple Scrum teams.
You might have one aligned to every VP of product, depending on how much help you need to get the product data out of things.
Now, if you have a very well-instrumented dataset like we were talking about at Doodle or something like that, you're probably going to have way less people 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 for everything, 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 another massive org within a company.
It 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.
So that tells me there's a lot of leverage that you can find from just maybe, I don't know, one or two that's probably not a large team of product ops people there.
We say too, get started with one person.
We described these three pillars and 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 take one person and throw that out there.
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 can take on, then you might add one more person.
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, 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.
We do see this trend of people throwing agile coaches at this, and agile coaches who have never been a product manager 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 inputs do we need on there, and what 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.
CEOs don't care about what's in Jira. Well, they shouldn't. Let's put it that way. Shouldn't.
They want to know like, "What are the big pushes that we're doing to help us reach our strategic objectives?"
So it's helping that 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.
For the market research and the customer research thing too, 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 [inaudible 00:44:53] 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 the generation of these roles, that it might be someone being allocated part-time from their PM role and finding out that they really do enjoy this 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.
By the way, if you buy your book at the end there, there's this really beautiful little guy, there you go, I think, on the camera of just a little yellow brick road of all the steps that it takes to roll it out. Yes, Candyland. 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. Is that right? Yup.
So what else should people be thinking about in starting to roll this role 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.
When you think about, it's Meta.
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 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 was making sure that you set, 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 in your 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 showing what's above the line with a person of one the capabilities you'll have, and then below the line, things that you may not get but you could if we did think about building the team and 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 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's set it up somewhere ...
Look at Blake Samic, started from Uber to Strike to AI.
Clearly, he's got a model going that's really successful.
So if somebody could get a Blake Samic, I would say definitely do that.
It'd be hard to pull him away from OpenAI.
I don't think he's leaving there right now.
Just started, got a lot of work ahead of him.
We have a lot of LinkedIn requests right now. Here they come. Poor Blake.
Sorry, sorry for your inbox.
I think too it's about if you're going all in.
If you're just trying to get buy-in for this and let's say it's originating from a CPO or 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're 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," 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.
It's never going to be 8,000 people, but eight people to do that function.
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.
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 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 does not have experience but has the right skillset 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 coach other people grow the function.
It's the same thing with product management.
We look at these teams 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, and they ask me, "Do I hire in experienced 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.
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 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 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 skillset to do this and execute.
I think that that's needed in almost every role, not just this one.
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, dig in because this person may have been doing a lot of the work 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 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 when you're hiring this person?
With the business data and insights, 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 it's not a database engineer.
That's not what we're doing.
We're not SQL-ing, turning things into the right SQL tables.
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 who are really good at this because they're usually churning out these types of reports and stuff for PE firms, VC firms, and 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 and BI.
If you could find that two things together though, home run right there.
So this person's probably a data analyst background.
We did have 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 surface some insights, but 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 this person really needs a super high EQ, understanding what the needs are, but also has a good spidey sense of how much methods do we need to think about bringing to the team and thinking about how those things get introduced that it's not a mandate, but it's a suggestion of how we can work.
Typically, product managers will be pretty open to that 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 understanding the underlying tensions and opportunities, and then feels good and understands how to implement the systems thinking and also understands it's not a set it and forget it, that they're constantly reevaluating the processes, the tools, "Are these working for us?"
Then understands, I think, in more broadly, "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 giving the same perspective or 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.
So I'd look for somebody who knows user research code, knows really good tactics for that because it can help create the toolkits, get the right type of prototyping and usability software in there.
They know what good interviewing looks like, that type of stuff, but they also got this need to make things better.
So they're like, "I need to create a system to do this."
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."
That's actually a really good interview guild that I would ask a product ops person and I never came up with it.
I never thought about that before, but it's like, "Tell me about some process or something that you had to do in your job that you really hated and that you ended up just trying to automate a way 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 our VP of, I think it's user insights and she does oversee all the 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 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.
Then if there's compliant 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 ...
There's a lot of legal things about what you can say and what you can't say to customers and stuff like that, what you can ask them, and 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 her thing and she's fantastic at setting up that stuff.
She and I worked together at Athenahealth 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, you should look for somebody who has at least a user research background, probably some 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 you into product ops.
Who would you suggest product ops report to generally at least to start? Head a product. CPO.
Such a clear, quick answer. I love it.
How do they find time to train and work with this person?
Are they the right-hand person that helps them just make everything more efficient? What's a way?
What's that relationship like?
I think definitely their right-hand person, and we say to a lot of CPOs, especially high growth companies, "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, they're like your right-hand man 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 who knows how to do it and operationalize it.
If you are like, "My biggest issue is business data and insights," for example, "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.
If they're confident 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 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.
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.
So 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 share 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 Athenahealth, we were doing a ...
Athenahealth has always been a software company, so let me put 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 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, $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, just way too many product managers.
There was 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 encounter these other problems, "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 and some of them did come to us and say, "What else is there?"
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?"
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 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 want it to go.
He was 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.
You're not going to find this in there."
That started to show me, "Hey, he's looking for this.
What do you want to see?"
He's looking for a portfolio roadmap 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.
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, 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 time, we only had Jira, so epics in Jira that were not just build a button, they were more substantial than that.
They actually had to meet 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 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, and at the time, they brought in 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 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, a consistent program."
So that 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 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 business data and insights team that was overseeing Amplitude rollout and they were also putting people around the director level overseeing usually 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.
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 oversaw that team.
She had somebody directed there.
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 get going with that.
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.
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, actually, Athenahealth at this time, it was really wild and 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 product ops team.
He was the chief of staff for the chief product officer at the time and he's been building it, again, 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 orchestrated as well to help with opex and capex and accounting type issues that they were having too.
So Athenahealth has been through many different restructurings since I've been there, but they have always kept product ops and their current chief product officer 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 VP of product ops managed a bunch of different people and 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 team? Yeah.
In this case, we did have her managing the business data and insights people and they were data analysts.
I wouldn't say they were data engineers or anything like that, but there 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 had 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 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 over and over again when it happens with product management.
So she oversaw 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.
They were also helping to roll out Amplitude, instrument it correctly, and building the right views and things like Amplitudes 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. We'll see how it goes.
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.
I thought you would say that.
Another one that I recommend is called Traffic.
It came out this year by Ben Smith, around the invention and growth of HuffPo and Gawker and whatnot.
I was in media at Condé Nast then, so peripherally part of it.
It's an exciting ride that has an ending that we all know, 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 out of the realm.
There's a lot of great product management books out there too, but I like this one because it's 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'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, "Yup, 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 Theresa Torres' 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've really enjoyed? Deutschland 82, 86, 89. It's on Hulu.
Highly recommend it, about East Germany. Like Pedal. Yeah, really great. I am going to go ...
I just watched the House of Usher on Netflix. I love the ...
It's Halloween right now.
Well, it was just Halloween. Perfect.