Is product operations a team of assistants to the product manager? | Antonia Landi
In Season 2 Episode 2 of Talking Roadmaps, Phil Hornby sits down with Product Operations expert Antonia Landi to explore the evolving role of ProductOps. They discuss how ProductOps enables product excellence, why it’s not just about tools and processes, and where it should sit in an organization. They also explore its role in roadmapping, decision-making, and cross-functional alignment—plus the pitfalls of treating it as a junior support function.
Antonia Landi is a Senior Product Operations Coach & Consultant, and a leading authority in the field. Committed to helping her clients transform from competitors into market leaders, she champions Product Operations as a strategic driver of Product Excellence.
Specialising in equipping organisations with the operating models, tools, and insights they need to thrive, her expertise empowers Product leaders and teams to align around measurable outcomes and deliver their best work.
As a prolific thought leader, Antonia’s work has been featured in multiple industry publications, and she is a sought-after speaker on leading stages worldwide. Known for her actionable insights and compelling delivery, she inspires audiences to rethink what they can achieve, establishing herself as a trusted voice in the Product community. She’s also one of the creators of the Product Operations Manifesto.
Here is an audio-only version if that’s your preferred medium - and you can access it through your favourite podcasting platform if you prefer (Apple, Spotify, Amazon).
In the next episode we are talking to May Wong, Product Operations Expert. So watch out for Season 2 - Episode 3!
-
It's seen as an entry point into product management. And when I started in product ops, it was so clear to me that this is something you do when you have some experience. This is kind of a senior level role. I mean, you're working at the organisational level.
Welcome to "Talking Roadmaps" season two where we are talking about product ops. And I'm really happy today to be joined by Antonia Landi, who I know is the author of "The Product Ops Manifesto." But I'm gonna get Antonia to tell you more about herself anyway. So Antonia, please introduce yourself.
Yes, thank you so much for having me. My name is Antonia, I'm a product ops coach and consultant and I am one of 12 co-authors of "The Product Ops Manifesto," amongst many other things that I do.
If you're enjoying the channel, subscribe, hit the bell and give us a like. Maybe tell us a bit more about what those other things you do then.
Absolutely, so my bread and butter is really helping companies get better at delivering outcomes. I also coach product ops leaders, product ops managers and product leaders tasked with the product ops. And generally I'm a huge community person. I love being at Meetup. I love speaking at conferences and the odd podcast.
Let's start with that really basic fundamental question then of why do companies need product ops?
I love that you're starting with this question because it's actually the wrong question to ask. I'm gonna tell you why though. Product ops exists at every company regardless of whether you have a product ops person or department, right? Product ops is a byproduct of doing product. How you create products is something that needs to be managed. Now whether you do that strategically or consistently or continuously, how much you actually focus on that, that is the question, right? So asking whether product ops quote unquote "should exist or not," right, is almost like a moot point. But talking about just how much we should be focusing on it, I think that's the real question.
Interesting, so that's essentially what I said about product management for the last 15 years. It's like even if there's no one with that job title, you are doing product management.
Somebody's doing it, right?
The work is happening and I think I reflect on how true that is. Like in my own career I did a bit of product oops as the head of product and I had other members of my team that were doing parts of it as well. And so it was something we just didn't have a name for, but it was there and it was taking place. If we assume that this work is happening and maybe there's a group of people doing it, what's its purpose?
Its purpose is to deliver value to the user in a way that benefits the business. And I am being very explicit about that. To me, that's the core of product management. But the core of product operations is to enable good product management, right? Our purpose is not to create processes, it's not to manage the tool stack, it's not to make sure people have access to data. That's not actually our end goal, right? We do these things in service of that higher purpose, which is becoming an organisation that can deliver better products. And I think that it's really a distinction I want to make very, very explicit.
And I think I fundamentally agree with you. Interestingly you said user and business. I tend to focus on customer and business and that can be an interesting, you know, fight within companies. Are we focusing on the customer or the user in product management in particular B2B and B2C, there can be quite a big difference there.
Yeah, absolutely, and so I've worked in both environments, right, in B2B and B2C, I've done product ops in both. And in B2B you have to be more explicit about there are these two groups and you do need to service both of them. But I think it's also a case of, I've seen some organisations, especially in B2B, right, focus very heavily on the customer. And you can get pretty far by doing that. But I think if you don't also think about the end user you will reach a ceiling, you will hit the ceiling that you cannot cross.
So I totally agree. And in product work I agree that all three groups need to be cared about. I guess I tend to kind of favour the designer is gonna focus on the user and the product manager is gonna focus on the customer. In that B2B environment and then that naturally, you know, those two agendas come together in the team or the trio for example. That can be a contentious discussion point. So it's interesting 'cause there is no one size fits all way of doing product and therefore I suspect there's no one size fits all of doing product ops. So how do you see them set up differently across different organisations?
Oh goodness, I mean there's as many product ops flavours as there are product ops managers and I think the reason for that is that we are there to remove barriers to product excellence. But what those barriers look like are so vastly different from company to company. I think broadly speaking, in the last few years we've come to three things most of us have in common, right? And that's data, tools and of working. I would say very broadly, every product ops manager and leader is probably looking at these buckets. But the specific themes within these buckets, right, whether it's you have a much more heavy tool focus 'cause that's what's been lacking. If you're actually going through a transformation and that's your bread and butter, right? Your specific focus area and your activities within these buckets differs wildly. And then you have product ops folks. I mean, you know, we can talk about are we doing work for product managers specifically or are we focusing on the product organisation more as a whole, which might include engineering, design, QA and so on. So there are many different ways to slice and dice product ops and yeah, there is quite a lot of variance. I think one thing I would like to highlight though, and something that I've been ranting about on LinkedIn is this difference between seeing product ops as assistance to product managers, right? Or product ops as strategic partners to product leadership.
Yes, in fact, if anything, I've seen that pattern a few times of the product ops being the junior person, almost an associate product manager that's brought in to be the assistant to the PM and I tend to look at that as an anti-pattern. To me it's sticking plaster that we're putting on to cover a problem that the product manager is overloaded that has a better solution probably somewhere else.
Absolutely, I mean we've rediscovered the business analyst really like these are people that are giving the wonderful tasks of writing all the user stories that at the end of the day, nobody really reads. And it's seen as an entry point into product management. And when I started in product ops, it was so clear to me that this is something you do when you have some experience. This is kind of a senior level role. I mean, you're working at the organisational level, you're working on the operating system of an organisation, right? You're touching how things get built, how decisions are made. That's not something you can do fresh out of college, right? And I think it's an anti-pattern, it's exactly like you say.
I mean it's an interesting one 'cause in the product management world for a long time I used to say don't hire fresh graduates as product managers. And I had that attitude because it was formed by my experience and when I entered the product management world, it was a senior job. Like you start teaching, you had 10 years of experience before you even could be considered to be a product manager because dealing with the CEO was a daily occurrence and maybe battling the CEO was a daily occurrence. And so you had to have business chops and experience to be able to take part in those conversations. Now over the last 15 or so years, I guess I describe it as we've seen another layer of product managers appearing, largely driven by the agile kind of ways of working. That has its benefits, right? And it's working more closely with the teams, more closely collaborating. You can't do as much of that and do all the old stuff that we used to do, the strategic work. So almost the work we used to do has kind of gone up to the directors and VPs 'cause frankly we didn't have that much hierarchy back then either. And then so kind of thinking about well do we, that product ops enabling us and I love that phrase you used earlier of taking away barriers to excellence. I love that phrase. Because, hold a second. Isn't that what I do as a product coach?
No, that's interesting, right? I get that when I talk about product ops in this way specifically. Some product coaches, right, ask themselves this question. Some product leaders ask themselves this question. I say, well hang on, aren't you just doing what I am doing? And I think especially with product leaders, what we have to understand is that yes, these tasks have always existed, right? And historically they have fallen upon the plates of product leaders. However, a limited number of these kinds of tasks require that deep leadership expertise, right? I would much rather do the quote unquote "admin stuff," right? I don't need a product leader having to try and wrangle mural licences. Like that is a complete waste of their time, right? Absolutely. Let me do that. Focus on the strategy, focus on developing team members, focus on the board, right? Working with the rest of the C level. That's what I need you to do. That's what you were hired for. That's where your expertise is so extremely valuable. Let me do the things that don't require your deep expertise.
Yeah, there's different classes of barriers, right? And I wholeheartedly agree. I was somewhat sarcastically saying isn't that what I do? 'Cause, yeah, I help one take away all the barriers, usually people barriers as opposed to kind of the sorts of things that you've talked about. So I think it sounds like a great marriage of kind of helping teams. Interesting, now, I think we've kind of said this already, but kind of reporting lines. Where does product ops normally live and is it always a separate team? Does it mix with somebody else in the organisation? How's it work?
Interesting, yeah, so typically what I recommend in terms of reporting lines is that the most senior product ops person reports to the most senior product person, right? So if you have a head of product operations, this person should report into the CPO, if there's a CPO, otherwise the director, you know, whatever the highest person in product is. Simply because that is a partnership that needs to be very, very close, right? I am there to enable also the product leaders to do their best work, right? Now I've seen product ops report into CTOs when there wasn't a product equivalent. Tends to work fairly well as well. I've seen some strange things with product ops reporting into chief of staffs and that's where it becomes a little blurry because product operations really does focus on the product organisation. I'd say it's fair to say that chief of staffs are a little bit more broadly looking at the company, the whole organisation as a whole. It has its benefits, right? It has its pros and cons. Another thing to consider in terms of reporting lines is whether you have a product ops team of generalists. So you have four product ops managers. Or whether you have specialists. So you have somebody doing product ops, somebody doing design ops, somebody doing research ops and all of these other flavours, right? And you become the sort of supergroup, right? That has a centralised view over what's happening in the organisation.
Interesting, yeah, I mean, so one of my clients for example, has combined it with agile delivery leads. So they've got the kind of the execution and delivery arm put together with product ops. 'cause it seemed like a... In fact it was more down to the leader being the right leader I think as opposed to necessarily organizationally it was the automatic sense. They had a separate product ops leader and then when they left it's like well actually this person would be a really good leader for that and he's looking after this so we're gonna bring them together for that reason. I mean, and I think going under the CTO, well I've seen product managers and product organisations under that. I'm generally not a big fan. I've seen a post not that long ago by, I think it was Ed Biden saying we only need one, a CTO or a CPO, because they should be absolutely aligned. I tend to disagree on that one. I actually want the healthy tension of the different perspectives and I don't want it to be a behind the scenes conversation where the CPO and the CTO have it out and then come out and talk to the rest of the C-suite as one voice. I want them to have an open conversation, including the rest of the C-suite, about the tensions between the delivery and the technology side versus the customer value part.
Yeah, I tend to absolutely agree. This advent of the CPTO is just, you're doing two jobs not as well as you can be doing one of the jobs, right? If you are a product ops leader under a CTO, I think you have to be a very, very strong partner. 'Cause I think over time you almost end up representing the product or the product managers. Not in strategy, right? Very, very explicit. Product ops does not decide things. Product ops gives the space and the time and the context for other people to make those decisions. But if you are under a CTO, you're kind of become by def facto, right, the product voice in that room.
Although I have seen some product people ask to take on the technology organisations. Well, I mean and many of us come from a technical background, right? Like a CTO's job if they're not building, you know, we're in a super small organisation and a CPO's job can be quite similar in terms of their scope and that strategic viewpoint. And I'm gonna say there are some normally good CPTOs out there. I might happen to coach at least one. But they are the rarity. Like I think the natural tension, being able to hold those two tensions in their head and make a balanced decision is hard. When it's two people, it's just easier for that tension to be then resolved through conversation. Who does product ops help and how do they help them then? I know it sounds really broad, but how?
Product ops helps the user. But let's maybe dial it down a little bit, right? I mentioned earlier I think our end goal should be facilitating great product creation, but at the end of the day, our primary sort of internal customers, if you will, are the people in the product organisation. So that's the leaders and the doers, right, the makers in the product org. I actually love it when product ops people start to build bridges with other departments, right? So once you've figured out, right, sort of the core essentials of doing product well within the product org, it's then time to think about how can what we do in product enable excellence in customer success? How can we facilitate better sales for our sales reps, right? How can we give them the data and the information they need to do their job better? And I think that's to me the highest order of product operations. That's kind of the end goal, right? To make sure we not only facilitate great work in our own little bucket, but we facilitate great work across the board wherever we're needed.
Interesting, 'cause that's what I consider to be the highest order of product management as well. Yeah, we're there to work together, yeah. So enabling like, so maybe yeah we can kind of focus on the content part as opposed to the how part. Yeah 'cause like working with go-to-market, like to me I consider the product manager, we talk about trios, we talk about product design, product management and development together. I consider that the product manager is part of another trio that's a go-to-market trio as well. Just we've seem to have forgotten that in the last 10 to 15 years and no wonder we're failing on revenue and commercial kind of understanding if we'd not been sitting in that group and having those conversations. So it sounds like a wonderful marriage of product management and product ops working together. I suspect in reality there's sometimes gonna be some friction where we actually both feel like we own these things. Any experiences of that?
Yeah. Oh, lots and lots of friction. You know what? Every so often I get really frustrated, burned out PMs in my DMs on LinkedIn saying, "Listen, I cannot do the product manager job anymore. I want out. Product ops looks easier. Is it actually easier?" And the thing is, we're not really beholden to those same stressors as having to, you know, make a specific deadline, having our managers or the board breathing down our neck, you know, failing to meet our OKRs, stuff like that. And yes, it might look less stressful in that way, but when we encounter problems they're typically quite deep interpersonal problems and they're the sort of thing that you might end up taking home with you, you know, because at the end of the day we can't achieve anything on our own. We need people to see the value in changing or in adopting something or experimenting with something that we propose. Like as a product ops leader, none of the PMs report to you, right? You don't have that explicit mandate that says, "No, you must work this way now." And that's actually a great thing. That's not something that should happen. But it also means that we need to go out there and advocate and change hearts and minds and expect pushback as well and work with that pushback. But as I said, if people are not in a place where they are able to change, right? If I dunno for example, they're fearing for their job 24/7 or they are so snow under that all they can do is survive and they don't have the capacity to take on any new information. There's nothing we can do, right? We buy the fact or fail through no fault of our own. And I think that's something that really needs to be said at length as well.
So feeling like... I'm feeling more empathy for product operations because I'm hearing them doing the same thing to us as we do to the rest of the organisation. It's that influence without authority. Like we have no authority over development and design. It's like, but we have to work collaboratively together and we have to encourage the organisation, let's just go this direction, let's just kind of do this thing 'cause it's gonna help this customer and that's can lead to better outcomes for us all. And you are trying to nudge us behind that saying, well if we put this system in place, it'll make your life easier. Which then makes you get... I like this.
Yeah, absolutely And it's the sort of thing that, you know, very early on when I started in product ops, my sort of elevator pitch was like, oh, I make your life easier. You know, why wouldn't you want to have me on your team? But actually sometimes I make it quite a bit harder, right? By asking you to stop doing something you've been doing for 10 plus years. And that really needs to be said. And I think that's what makes product ops difficult. It's the human variable, right?
It's change, and see that's the hard part, right? So it's going to be easier in the long term, but I have to go through this pain of this change, the ingrained habits, the ways of working, the way I think it should be done. And product managers tend to be a certain personality type that's a little bit megalomaniac and want to have control sometimes.
Yeah, very opinionated people for sure.
Yeah, so I can imagine that cajoling product managers could take some effort. So yeah, I can understand that. But I guess many... In fact here we go, you've talked about sometimes product managers saying it looks easier and kind of, it might be a path to go down. Where do product operations managers come from? What's their origin story? Because there is no one for product managers. So what's the origin story for a product operations person?
A lot of the time it is product management, right? A lot of the time, and then especially now with the advent of us actually talking about this role and giving these tasks a name, a lot of people, I've had this happen to me when I spoke at conferences, folks coming up to me after the talk saying, "I think I've been in product ops my entire life. I think what I've been doing is product ops." So a lot of them come from product, some of them might come from related disciplines within product. Some people are operations folks from completely different departments. So you may have done operations for customer support for example, or customer success. And you kind of made that move where what you really know is ops and you need to upskill on the product part. And now I've been a bit wishy-washy about this in the past, but I think it's time to sort of lay down what I believe at least are our sensible sort of guidelines. That you can be an excellent product ops manager from any background, from any discipline. If you are a company's first and only product ops manager, you have to have a product background. You need to have been there and done the work yourself and really deeply understand what it takes to bring a product to market to be able to make recommendations and decisions on how other people are supposed to do it, right? And I think it ties back into this seniority piece.
I mean I've kind of rightly or wrongly for a while formed the opinion that my principal product managers staff, or distinguished even need to be really, if they're not part of the product oops organisation, very tightly coupled with them. 'Cause they're the ones who can bring that best practise and sell it to the other PMs as well on how we're gonna work. Because again, it comes back to that point you made of, if you don't know what good looks like, how the heck do you create it?
Right, and if you don't have that, that's when you get these sort of kind of disempowered product ops managers who do revert into being admin assistants, right? And you can be an admin assistant to a product leader. That's still not exactly sort of the full scope of product operations. And it's very interesting seeing all these parallels with sort of disempowered product managers, right? And the very heavy delivery focus there.
In fact, I wanna just as you talked about that, it reminded me of something you said earlier about product ops reporting into a chief of staff. Now chief of staffs can live at different level. I've seen many chiefs of staff directly below the chief product officer for example. And so they're essentially a product chief of staff and there it kind of felt like it was a natural home to me for a product oops. 'Cause they're there about essentially enabling and taking roadblocks away for the organisation. Any thoughts there?
If you have a product chief of staff, I think it makes sense for product ops to live alongside or under that person. I think that makes sense. If the chief of staff is the chief of staff to the CEO, I think that's where it becomes a little harder to have that focus. 'Cause I mean the person you report into also needs to be able to guide you a little bit, to coach you, to give feedback on the strategy you come up with, right? And say this is the direction we're going, broadly speaking. So I think it's very similar to the CTO, CPO debate, right? The person you report to kind of inherently has a very specific focus and then you kind of live beneath that focus or you'll be constantly challenging it.
Yes, in fact, I can imagine if product ops was underneath the CEO's chief of staff, it would just become the avenue for skunk works and getting things pushed through. Okay so we think we need this function, how do we justify it?
Now I think a long time in the product ops community we're just kinda hand wave that question. I was like ah, it's hard to quantify. You know, we do people work, you know, our change is hard to measure. I actually think there are two concrete things we can target. One of them being time saved, right? So reduction of amount of time it takes to do task X. And the second one is attrition. So I think very broadly speaking, I'd almost go so far as to say almost anything we do either reduces attrition or reduces the amount of time spent on menial tasks.
So, and by that we might mean I know admin on booking interviews for doing discovery.
Exactly, or like how much time it takes from you having a question in your mind and wanting to dig into the data until you're actually there getting those insights, things like that.
And so does that point to perhaps data team enablement within product ops then?
This is very interesting. So my clients have gotten a stronger and stronger data focus lately, but what they are specifically looking for is people with this product ops profile. So people who have lived in product who have the operational sort of edge to then tie that into existing data, right? So that is helping product managers define KPIs or sort of understand what needs to be tracked, making sure that the data definitions that product managers come up with are actually what's reflected in how we collect and store the data, right? We're talking about taxonomy, we're talking about the user experience of going to a dashboard and finding those visualisations you need. That has become an increasingly important factor in product operations, absolutely. and with some product ops teams, you might have a data analyst on staff that works for product operations.
So, okay, let's switch gear a little bit. What do you consider to be best practise in product ops?
I really like returning to this principle of pragmatism. I think almost above anything else in product operations and almost above our own experience even. Because I mean we talked before about, you know, 10 different companies, you have 10 different product ops experiences. What worked in a past company is not gonna work in your current company, right? No matter how much you believe in. And I think to me this level of pragmatism is the most important thing because bad product operations managers exist, right? And sometimes the people that think of us as process for process sake, people have a point because that was their experience with a bad product ops manager, right? We have to understand that that is something that does happen in the world and we cannot prevent that. And I think by focusing on, you know, being pragmatic, really always thinking about is this helping our product organisation deliver better products, right? That should be our end goal, right? And if something is messy, but it works, leave it that way, right? And I think that's something, yeah, something we need to remember. And it's the same thing with frameworks, implementation, anything like that. What's this most sustainable change you can make today? If you're an organisation that speaks to a customer once a quarter and you read a book that says you need to speak to them every single week, you cannot make that jump, right? Focus on trying to get to once a month and then maybe once every two weeks and then once a week, right? Because this is all change management, right? And that is the most important thing. If you're asking somebody to change their behaviour a better have a really good reason.
And that might lead naturally onto what's the biggest mistake you see people making in product ops?
In product ops, actually a really common mistake is when you start as a new product ops manager or leader or you start as a new company, you almost immediately go into firefighting mode and delivering quick wins, right? Because this first couple of months, most people probably never worked with a product ops person before. Nobody really knows what your job description is or where the boundaries are. So you are just naturally feeling like, okay, I need to provide value, I need to sort of help people understand that it's good that I'm here and need to sort of help them understand what it is I actually do. And I think that's a great first step. But you cannot stay in this quick win mode for longer than two months maximum. 'Cause if you keep doing that, you have a million things on your plate that never meaningfully move the needle, right? And that's when people start going, it's like, yeah, great, she reorganised our confluence pages, but was that really worth it? Like is that all there is to this? That's when you really need to start thinking strategically because you need to understand the organization's priorities in the next year, in the next three years. And you need to understand what's required for your organisation to actually get there. If your big play is we want to run 800 experiments every month, right? You need to build the infrastructure to make that easy. And that's almost a cultural change.
No, so we are on a channel called "Talking Roadmaps." So I do have to ask you a couple of questions about that. So what's product ops involvement with road mapping?
Where to start? Honestly it starts with the goal setting, right? If you're using OKRs, it starts with the OKR definition and then it ladders all the way down to strategy to how people prioritise and to inputting all of these things in a road mapping tool, if you have one. And again, product operations is here to facilitate that work. We don't do the work for you. We certainly have no say into what goes on the roadmap, right? But we can, if you need one, help you select a road mapping tool. We can make sure the right people have access. We can make sure everybody that needs licences has licences. We can make sure that in the information that's in the tool is actually accurate and up to date. We can help train you on the tool and so on and so on. We can help you embed the information, right, into every single sort of team and all hands and company communication, that's what we are there to do.
Love it 'cause I remember going through that selection process about eight years ago. I'm getting my entire team to do the work 'cause frankly I didn't want to. And we made a decision, whether it was the right one, that's a whole different discussion. They were happy, they made the choice ultimately, but then we had to roll it out and then we had to get the IT buy-in as well. In fact, that was the hardest hurdle 'cause it was quite a large German organisation.
Oh yes, of course I'm well versed. But no listen, I mean tool implementation, successful tool implementation is so much work, especially the larger companies. The amount of compliance and legal and IT and getting everybody on the same page. And then you have to tool and then you need to populate it. You need to integrate it with your tool stack. It's an immense amount of work. Why should a PM be doing this?
I did ask that question myself. But the goal was that it was gonna save us time in the long run. I mean I did hope that execs might self-service when going actually look in the tool, I learned that that is something that they will never do. I will still have to take them to it and show them the information, but at least it was consistent. So here's a meta question then. Do you need a roadmap for the product ops function?
I think yes. Simply because if you want... So first of all, you need a strategy, right? I think that's where it start. You need to have a product operation strategy, otherwise you're bogged down with whatever comes across your plate by the person who screams the loudest whatever seems more on fire on any given day or all of these teeny tiny quick wins that don't really move the needle significantly. In order to have that strategy, you need to understand where your company is going. That's a discussion you need to have with product leadership, right? You need to be very clear on what do we actually want to enable? Do we want to upscale our product managers, right? Do we want to become much more data driven, right? Do we want to implement something like OKRs, right? All of these are longer term objectives. And then from there you need understand what needs to happen in the next six months. What needs to happen this year for us to get to that end goal, that end result. And yeah, you might end up having a roadmap, absolutely.
So, okay, we've talked a lot about your advice. Whose advice on product ops do you listen to?
Oh goodness, so many people, I cannot keep track honestly. I mean I love hearing from people in the trenches, honestly. The people who are there doing the work and sharing how to do the work. And I think... I love sort of Slack communities for this specifically because there is a kind of barrier to people starting to share their experience in places like LinkedIn. 'Cause people feel like, "Oh I can't, I can't be a thought leader. Like I don't have nearly enough experience or nobody's gonna care about what I have to say." And I love hearing from people that just go, "Hey, I've got this really weird challenge right now. How would you solve it? And this is what I've done so far." So like following all of these little threads on random Slack communities, that is where I thrive. But I love, love, love learning from my ops cousins, right? Folks in design ops, folks in research ops, anybody with a systems thinking hat on, right? People who are in that messy middle of everything kind of role. Those are the people that I actively seek out.
I mean are there any particular resources out there that you'd recommend or kind of places that people should go to find stuff?
So if you're into communities, definitely check out Product-Led Alliance. There's Product Ops HQ which also has some wonderful online meetups that are always really fun. And then, I mean, how could I not mention John Cutler? He is just like, in my mind he is an actual literal genius. Like I do not understand how his mind works. But I also don't really want to know, I just want to soak up everything. Yeah, I think start there and just go down the rabbit hole as far as possible.
It's definitely a rabbit hole with John. We had him on season one of the channel and I felt like I just about kept up with him for an hour. I think we've gone much longer I'd have struggled, yeah. Super, super, super smart. Lots of great thoughts and things I quote quite regularly. So now comes the hard one, Antonia, if you had to distil your philosophy of product ops into one or two sentences, what would it be?
Let's see, so I think honestly the two biggest things I would highlight is that product operations enables product excellence. And it must be pragmatically. I think if I were to reduce all my thoughts and all my feelings on product operations into two things that I would want people to understand about how I specifically approach product ops.
Is there anything I should have asked you about product ops that I haven't?
Something that people tend to struggle with a lot of the time is how to measure product operations, right? Either to make a case for more product ops staff or to make a case for keeping existing staff or simply to see the progression. How do we know it has worked, right? And that's, again, it's very similar to product management and it's because we're essentially the product managers for the product organisation, right? What you're trying to elicit is a change in behaviour, right? And the crux of the question becomes then what's the next best proxy we can measure to see whether that change in behaviour has actually happened. And sometimes it can be fairly easy, right? You can measure number of user interviews scheduled for example, right? But things like time to insight, how long, right? I mentioned it earlier, how long does it take for a PM to have a question about data and then find the answer in the data? Or at least investigate, right? That becomes a little bit more difficult. You could maybe do it with a few automations, a few labels here and there, right? Becomes a little bit more difficult. When you start asking yourself, how can I measure better decision-making? Then you get philosophical, right? And that's when we kind of start to hit our limitations. We have to start making some assumptions and going further, can you directly correlate good product operations to good product creation? I would say if anybody has any insights on how to properly measure that, I'd be very, very interested in having a conversation.
I mean, I'm sat here thinking, so when we are talking about doing product work as product managers, we're thinking about product outcomes that are a change in customer or user behaviour. So you are looking for a change in product managers behaviour. I'm gonna have to unpack that a while. I mean you also went down the decision-making rabbit hole, which I am writing a book about, product decision-making. 'Cause it is a hard space that's not very well served so very much. Yeah, I see product oops having quite an important part in that decision support space. Antonia, I think we'll wrap it up there though. It's been an absolute awesome conversation. Loved hearing everything from you. Really appreciate you taking the time today. Just as a last thing, can you give your pitch where people can find you, how you can help?
Absolutely, this is probably the part I'm absolutely the worst at. I love nerding out about product ops, gosh, what do I do? I coach people who need to do product ops, I do product ops work myself. So if you feel like getting product work done and your company is like walking through trickle, give me a shout 'cause it's very likely that we can do something about that.
And where might they find you then?
On LinkedIn is where I live 99% of the day. I also have a website. If you're interested in checking out "The Product Ops Manifesto," right, where we talk about the prerequisites of the role, what we're there to do, do check that out as well. And you can even co-sign it if you feel.
Antonia, it's been wonderful chatting, thanks very much.
Thank you for having me, it's been a pleasure.
