Is ProdOps the product manager of product management? | May Wong

In Season 2 Episode 3 of Talking Roadmaps, Justin Woods interviews May Wong to explore the evolving role of product operations. They unpack the idea of ProdOps as the “product manager of product management,” discuss how org context shapes best practices, and reflect on how trust, team culture, and process design intersect with scaling. A must-watch for those navigating change, tooling, and communication in growing product orgs.

May Wong is a product operations expert. May grows the aligned product organization and infrastructure that you need to build and launch your vision of your scaling product portfolio better and sooner. As a product community builder, May runs ProductTO and co-produces Product Conversations. In their non-product-life, May is a Toronto foodie, the Chair of the Board of the Open Digital Literacy and Access Network, dabbles in promoting local democracy, and knits socks.

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 Chris Butler, Staff Product Operations Manager @ GitHub. So watch out for Season 2 - Episode 4!

• Transcript

  In order to really talk through this, we have to talk about process. So one of my favourite topics, 'cause I hate process, the way I like to describe it is everything I learned about what I do, it's really what not to do. Learn from IBM and all of their massive, massive, massive amounts of process.

  Welcome everyone to the "Talking Roadmaps" channel, the show where we talk about everything roadmaps, but also some other topics which I'm gonna share with you in a moment. We are gonna talk about the good, the bad, and ugly of product operations. Product operations is really quite a critical role now supporting the product management function. And my special guest today, we're gonna talk about product ops, product management, road mapping, and the intersections of all of those as well. And so that really leaves nothing more for me to introduce the fantastic May Wong. May and I first became, well, I first became aware of May last year on the "Product Conversations", which is a podcast that she co-produces with Grant Hunter and Steve Johnson, who I'm big fans of from product growth leaders. And I've really appreciated May's funny yet on point LinkedIn posts. I've been watching those, May. About product management and product operations. Just puts a comedy angle on some really interesting and poignant points. Late last year I was fortunate enough to be a guest on "Product Conversations" alongside May, Grant, Steve, my friend and former colleague, Elliot Golden, and of course my talking products, "Talking Roadmaps" co-host, Phil Hornby. So it brings me great pleasure, May, welcome. Please give us an introduction though for people that might not be aware of you.

  Thanks, Justin. Hi, I'm May and I am based out of very cold and snowy Toronto, although it's getting slightly warmer. And I do product operations. Usually I define myself more as a product nerd first and then that kind of evolves into product operations, but also many different aspects of product as well. So if you ever see me or come across me and you wanna talk product, we might be at it for hours. So what I do is I work with product leaders, really, I think of it as a partnership, but I usually get employed full time and we work out what better product management looks like in that context of the organisation. So it's going to vary drastically. And the three things that I think makes it vary are your organisation, your product itself or your portfolio, and the market that it's in. And anytime any of those things changes, like, everything changes about how you have to work. So yeah, what better looks like looks very different from, forget from company to company, even from, like, quarter to quarter.

  If you're enjoying the channel, subscribe, hit the bell icon, and give us a like. Right, or even team to team, right? Sometimes we get these different pockets of progress and excellent within them.

  Yeah. The way I like to think about product operations though, it's more the scale of product. So like, even if you have multiple product teams, they have different ways of working. You still really wanna think about, as a whole, how your org works together, right? Because having to reinvent the wheel every time you have a new team or every single team has to do it every time you have a new system on the other side, like, it's going to be really hard to figure that out. So that's kind of what it is. It's that thinking about scale at pockets above and beyond the different teams, if there is some.

  And so would you say that's, yeah, we hope there is. I'm sure there is. There definitely is. Well, so does that feed into kind of your definition of the purpose of product operations then? Or how would you define product operations?

  I would define product, there's two ways I define product operations. One is two product leaders and product managers. I define it as I product manage the product management discipline and the context in which it exists, right? So the discipline is how do we do product and the context is the org and the market that we're in and the product that we're building. But like, that's complex. So what you're doing is you're looking for problems in this space and then you explore it and then you prioritise, you know, it's product management. Half the time you're doing the things 'cause you don't really have a team. I've seen places where they have a whole, like, product ops engineers and product ops, like, product ops ops. I've seen that. Like, it could be anything.

  I guess sometimes they're doing product operations and not even knowing it sometimes. Let's look at this from maybe a slightly different angle, which is why companies might need product operations.

  So the way I think about it is that everyone's doing product operations, right? If you think about any job you've ever done, have you ever been stuck, right? Like, what percentage of time would you say you've been stuck?

  I think sometimes it's, I don't know, 20% of the time, 10% of the time. It's not often, but sometimes it's just, like, second guessing yourself or what's the best way to do this? Or researching what other people have done. I think sometimes there's the doing and then there's like, "Am I doing it right?"

  Yeah. But half the time, your job is not to figure out how do I do it right. Your job is to do it right.

  Right.

  And so the time you spent on figuring out how do I do it right in the context of what you can control, it's pretty minimal. So what ends up happening is this works gets dumped on the product leader. And the way I think about what a product leader does, to put it really, really simply, a product leader has five jobs. One is people management, 'cause you're a people manager now. Two is your product or portfolio strategy. So everyone who reports to you, what's the strategy there? Three is stakeholder management up, down, and sideways constantly. Four is the layer of strategy above you, does your strategy fit into that and/or does it exist? Because if it doesn't exist or it doesn't align, you have to either force that alignment top down or force that alignment bottom up. And, like, that's a whole new job on itself. And number five is what I call how does my team work together within the context of all this? And that's product ops, right? And so out of those five things, everything's on fire, what's the lowest priority? How does my team work together? So over and over again, you see like really great people become product leaders with the aspiration to build a great product, organisations with good strategy, and they kind of get stuck in the same trap over and over again 'cause they just don't have time for it. Because as a product leader, your number one priority is your people and the strategy and how that happens within the larger context, within, like, how you have to work with all your other peers and really do that really hard work of understanding, like, why is everything terrible right now? Like, it's not necessarily terrible, okay? But, like, sometimes it feels like that and often it feels like that. Like, that's a lot of work because most likely what happens is you put in bandaid solutions, right? So if say you're working with a difficult leader on another team, what people try to do is protect their team. So they say, "Okay, if you wanna talk to us, you go through this channel", right? And that's how silos start to form. There's, like, retaliatory silos. There's, like, people who are like, "Oh, I see what they're doing and I wanna protect my team as well." And then, like, everyone just starts building these walls and then a year later, you can't actually talk to each other anymore.

  Not unless you throw a ticket over.

  Yeah, but the ticket has to go like up, up, over, down, over, up, up, down or whatever it might be, right? Like, and so it's just, like, not having the time to intentionally plan what your organisation could be, to think about how do we do, and with the lens of what does good product, what does a good product organisation look like? What does a good product organisation that is designed, and not necessarily designed, but like, cultivated to collectively build good products, what does that look like? And from there, you can grow, right? Like, but without doing that work, it's really, really hard. And some people have that, right? Some people have done that work, but how does it transition to scale? And so that's kind of the next part.

  Yeah, or sometimes it happens by accident and it wasn't intentional and that's great, but then how do you recreate that, right? If your teams might happen to be self-forming and self-aligning and that's great, but if it wasn't intentional, it's not repeatable. And it's a really good point actually because when I've worked with companies in a product management road mapping perspective and obviously interfacing in with engineering, there's a lot of legacy configuration of those teams even, right? Operationally, they're set up not necessarily in the right way, they're set up in terms of components or these types of things. And they're not engineered in order to solve problems. They're just to look at different components of a system. And so do you find that the product operations looks into the elements of how we build product as well and steps into the development side of things?

  It depends on the organisation. Like, does it exist on the other side is what I look for, right? Like, so if someone is taking very clear ownership of their domain, either in design or in engineering, like, if there's a strong SRE team that's thinking about these problems or a strong, agile team that's doing that, the first thing I do when I meet either a new leader or the person doing it or I'm coming in is we sit down and we talk about what do we think our boundaries are and where and how do we work in the grey areas? Because it's not, like, it's the way I like to think about, okay, in order to really talk through this, we have to talk about process. So one of my favourite topics, 'cause I hate process, the way I like to describe it is everything I learned about what I do, it's really what not to do. Learn from IBM and all of their massive, massive, massive amounts of process.

  I'm a former IBMer as well.

  I became the person at my company who learned, who knew how to ship new products at IBM. It is a lot. It's a lot. And so the way we think about process is this thing happens. So you do A, you do B, you do C, and once all of that due diligence is done, then D can happen, right? But nowhere in there do we talk about the why. Nowhere in there do we talk about what is the actual thing that this process is supposed to accomplish? And when was this established? Like, how long ago and how many systems ago and how many other systems that are adjacent to this have changed since this was put in place? And how do you change that, right? And the way I like to think about process is process exists where you don't want people to be creative. Yeah, and so, like, a lot of companies, as they grow and scale, their instinct, because that's what we've been exposed to all our lives, is what systems do we need to put in place so, I'm sorry, what process do we need to put in place so that we can scale? And my answer to that is always, well, the second you scale, your process is broken. Because anytime you change any factor by, like, 20 to 20 to 40%, you're done. Like, you have to think-

  Start again.

  Yeah, exactly. So the way I like to think about process really is that you have these bubbles of, you have these teams, like, these small, interdisciplinary teams that work together. Some people call it a pod, some people got a squad, whatever it might be. Like, these teams of people who work together, usually a product manager, a bunch of developers, some QA people, designers, and whoever else might be involved in that. Like, be it long term, short term, whatever it might be. And they need three things to be successful in order to do their thing, which is autonomy to make decisions, alignment with the overarching goals. So each of these teams are working together. And access to information to make decisions, better decisions, right? So all of these things come together and they can do the thing, you just give them the thing. But how do these teams work together beyond that? And that's where process kind of need to exist. But the bigger the process, the harder it is to change. And if you tack on more and more teams as you rapidly scale, like, how does that change? Like, they won't work. So really the way I like to think about, the best kind of process is micro process that does one thing. You need a series of microprocesses that are modular and they act kind of as either decision points or really like human APIs that feed into them that gets the larger organisation to where it needs to be. And really anything above that exists to support the smaller teams doing their things, including like, you know, sales needs to have that autonomy to do what they need to do, but they also need ways to connect back to us to let us know what they've learned and also, like, what are the challenges and also what they need, right? So it's that constant stream of communication and all of those lines on this map of, like, where does information need to go. So in terms of, like, going back your question of, like, who owns what? I feel like when we talk about the layers of ops, we sit in the grey area between those teams, the independent individual teams that need to do their actual work. And we need to figure out how to best help those teams. And it's not about us or our egos or whatever it might be. It's about you have your domain expertise, I have mine, like, let's talk about what it is that we're advocating for and what's the best solution in this context. And it's just like, you know, in product management we say, "Okay, well, bring your problems and talk to the teams." Well, I'm not the expert in SRE, like, I don't know anything. I don't know anything about design systems. Like, I think it's cool, but like, I'm never going to be the person building your design system, right? So like, I bring these people together and we're like, "Okay, this is a problem. I don't even know who solves this, but like, let's talk about it. Let's work it out. Let's figure it out."

  Nice. So there's a level of rigour there that's important, but also open-mindedness. There's a level of process and repeatability, but also autonomy. It's a careful balance. And I'm curious, what is the collaboration between product ops and product management? Is there any friction or overlap? And I think that ties into what you were saying there is sometimes it's just about having a conversation. It's not going in with a rigid set of this is what we do, this is what you do. It's kind of understanding what each other does and spotting the grey areas in between. Is that right?

  It's a little different when it comes to product ops and product management. So product ops, as a function, so it could be nobody, it could be one person, and it could be a team, right? So product ops, if it's nobody, then it's usually either a delegated part-time person or an individual just carving out time trying to figure out better. But like, the scope of what better could be is limited by your power mandate and influence, not even capacity 'cause a lot of people who want to do this work or feel like it's absolutely necessary to be able to do what they wanna do, they'll do it, right? But that's how people burnout out. Like, Jenny Wanger calls it a shadow product ops where people do all this work and they don't get recognised for it because people are like, "Oh, this is just a part of product management", right? This is why product management is terrible, but we're gonna make you do it anyways. And it doesn't have to be this way, especially if your company is growing, you know, like, you really have to think about what scale looks like from that angle.

  Awesome. Awesome. And, yeah, I get excited by it because there's been elements, you know, I've been in product management since 2006, I think, in and out and in and around it, and it's been great to see it grow. When I first joined, it was more strategy and commercial, then it went to sweep and now the pendulum's coming back the other way again. But it's great to kind of see that growth. So I'm excited to speak to her and get her feeling on it. I guess, do we need to justify having product ops? So you mentioned about some people just doing the do because they need to, it needed to be done. How does that work within organisations? 'Cause I think you've played a part in that as well, demonstrating to companies why product operations is important and needed.

  So it's one of those things that, like, often don't get recognised because we're talking about incremental change when we talk about measuring success and generally speaking, that's how product management is measured. And if you're talking about improving that, it's really, like, product management is, I'm gonna be a nerd here, is, like, the first differential. It's, like, the first order change where you're steering the company towards progress, whatever the progress might be. And if you have someone who can say like, so if this is your curve and if someone can do this or someone can do this or someone can do, like, even just like a little bit, you know, that makes a lot of difference over time because a graph that looks like this in terms of speed, like, the actual output kind of goes like this.

  Right, it's compounding.

  Yeah, it compounds because, like, the way we think about, the way we think about it, it doesn't humanly really process. But when we think about the actual mathematical interpretations of like, and if you go back into your, you know, calculus course in high school, like, thinking about how all that compounds. Okay, I am a licenced math teacher.

  Oh, amazing. Okay, I'm in safe hands then because I wasn't great at maths at school. You can go calculus if you need to. I love it. But I can resonate with what you're saying because I come in, you know, I'm known for being a tool implementer, certainly around roadmaps, but roadmaps is really just, you remove the cape and it's product management, right? I put myself in the road mapping side of things. But where I was going with this is that one of the challenges I have is demonstrating the benefits of road mapping, right? It's like people bring me in because they have identified they're not doing roadmaps well or they're using a certain road mapping tool that they want to implement. But being able to demonstrate the benefits of that becomes a lot more subjective. It's really difficult to say I have increased the efficiency of the product function by X or decreased it by Y or increased efficiency of creating roadmaps, often because the companies themselves don't know that. And, you know, they bring me in and I'm having to make sure that we are providing a benefit. I deliver the goals that they've wanted, but making that actually measurable becomes really difficult. And I guess that might be something similar to product ops. Is this difficulty in making to demonstrate the empirical change that you make.

  It actually happens the other way around. So most people I've talked to who were the first product ops person in their company, and this happened to me as well, the first thing they get asked to do is to build the roadmap. It is an expectation of someone coming into a product op, a product management discipline as a product ops person.

  Product management. 100%. Yeah, show me the first word. Show me the roadmap.

  No, if you are the first product ops person going into a product management team, the first thing they get asked is to build the roadmap. I'm not talking about, like, the individual PMs building the roadmaps, I mean like the portfolio roadmap. And because every time they've tried it before has been a struggle. And so you go in and you look and then you realise, you know, these requirements are coming from sales, these requirements are coming from engineering, these requirements have been living in the backlog for three years. You know, and it's just like what is a road map? And I think most product op people who, and we've talked about this on product conversations, like, most product ops people who go through this thought process of, like, what even is a roadmap, hits that point as they are going through this for the very first because the, like, especially if you've been a product manager before, you've, like, worked near product before, you've seen a roadmap and you're like, "Okay, this thing kind of sort of works." And then you come in and you're asked to build a roadmap and you bring everything you know, and it's not enough because the problem is not the roadmap. The problem is product management. I don't have to tell you this, but like, the problem is product management. And so you have an absolute dilemma. You're being asked to put in a roadmap. The roadmap's not going to be successful because it's never been successful. And you are being asked to put in an artefact that represents and will show product success in a place that, like, has traditionally not been able to pull it off.

  Totally. And the behaviours mean it's not even possible anyway.

  On top of that, you're being asked to put in a roadmap, which means that they don't wanna use sheets anymore or like, a spreadsheet anymore and PowerPoint to manually do the roadmap. They want a product management tool. And you know what? They've even allocated budget for it, which is great. So without this knowledge, you go and look for tools. This might be describing my own personal experience and like, countless others.

  Like to me too.

  Right? Like, so you go and look for a tool and you find all these tools and all these tools are whole product management platforms. They don't exist as a roadmap. And you're like, "Okay, well, I guess I have to buy into their philosophy." And so the first thing the sales person asks you is, "What is your product development lifecycle?" And you're like, "My what?" It doesn't exist. We are starting our transformation and we started with the one thing that's needed to communicate what it is that we're trying to do in order to start the rest of it. And now you're being asked to define your product development lifecycle in order to feed your roadmap, in order to produce this one artefact. And the artefact is what people actually want right now. And you can get to the rest later, but you can't generate that artefacts with the tools.

  I mean, you're describing life for me. I love this. I'm living cathartically. That's why I love "Talking Roadmaps" as the show. 'cause I get to geek out with, you know, great guests like you. But like, it's so true. And actually what I find is that the tip of that iceberg is kind of the roadmap, but everything else is the scaffolding that needs to get us there. And what I find is that when I go into these companies and work with clients, May, 20% of my job, maybe even less, is configuration of the tool that they've brought me into. The rest of it is process, politics, bureaucracy, power structures, everything else within that. And that's the thing is, and often it's even worse than that. Like, "Justin, can you train us on this tool", and then you are even higher up because I can't train you until I know what your processes are. You can't know what your processes are until you know the story, right? So what you're sharing with me is deeply resonating and it's so true.

  And at the same time, right, when this is happening, because this usually happens at a time of great change, which means either scale, acquisition of another company, or getting acquired, and transformation looks really different depending on, like, what's happening. Like, if you're a legacy company trying to become a agile company, you've implemented a lot of changes. Like, all of those changes aren't happening on the product side. Most of the time they're being pushed into development and developments going through their own agile transformation. And the reason why you wanted this roadmap in the first place is because their agile transformation demanded it. And so this interface is broken because, fundamentally, building a roadmap to serve another team's very specific function so that they can transform. And then from there, they tell us what to do. Because that's how product management operates. Like, that's not really feasible because agile is not a product management framework. Agile is a development framework and it works really well for development and product management needs to be able to interface with that. But it's not defining product management, right, like-

  Your PMLC is not your SDLC.

  But it's your product development lifecycle.

  Right.

  Even the roadmap vendors will ask you for your product development lifecycle because your product management lifecycle is heavily dependent on product development, right? Like, they're not separate. They can't be separate, right? And it's really about thinking about those interfaces. So kind of going back to thinking about, intentionally thinking about how your organisations are set up and designed and like, how do all these teams work together, especially as you scale. You know, I had a company come and ask me what it is that they could do to do things better. They're gonna scale. They've already doubled in the past year. They wanna add another 40% this year. And all they need is just process to make it work. And it doesn't work like that because as you scale and change, everything changes around you, right? Like, you can't just tack on another team and pretend like everything's gonna be okay. So the question I ask is, "Okay, say a year from now, you hire all the people you need and you know, your teams are that much bigger to what the size you think you need is, can you do everything the same way you work today?" And they're like, "Well, yes. We just implemented safe." And I said, "Okay, well, you've just implemented it so that means it's pretty, like, it's early but it's established. How you work today, is that going to happen at that same scale?" And then they think about it and then they go to the next question, right? Because it's a terrifying thing to think about because you've just gone through so much change.

  Oh man.

  And you're talking about change fatigue now.

  You are. I worked with one of my clients who'd implemented scaled agile because leadership wanted, let's face it, more delivery, more speed, not really understanding everything else that safe was incumbent across the entire organisation. But anyway, they'd implemented it, it'd taken a while in order to bed in because your velocity will drop probably initially whilst teams are learning new ways of working and everything else. And then what had happened is after 18 months, they didn't get the velocity that they wanted. New leadership came in and reversed the scaled agile transformation. And you talk about, you know, change fatigue and the absolutely right there. I think, you know, this is a whole conversation you and I could go down into for hours, I'm sure, but it absolutely resonates. Right? Exactly.

  Right. Like, this is product ops, it's, like, what happens when change happens and the change happens all comes almost always from the top.

  And a function that outlives the tenure of the leadership is also helpful because otherwise, we just keep making changes.

  And so, like, kind of really digging down to what we're talking about, right? What's the most resilient part that stands the test of MNAs and leadership changes and like, direction changes is team culture. And when I say team culture, I don't mean company culture, I mean, team culture, the individual blocks of people actually doing the work and what ties those teams together on top of that. Because if the individual teams already have a very strong bond with each other in a way and like, just feel strongly about what a good way of working, then they can push back against things that they feel are unnecessary. But it's not necessarily about pushback, it's also about, like, you know, here's a really good way of working and we are actually working really well and we have ways to talk about our successes and what we've tried and what we've learned and grow with that, right? And it's all those systems around it that feed and sustain these healthy teams to become successful. To stand a test of, like, attrition and market pressures and like, a whole pandemic or like, the great resignation, you know, all these things that come in and happen, they're gonna happen. Like, big changes are going to happen. It's almost always out of our control. But what we can control is the kind of environment we build for the people who work here.

  Yeah, I'm just basking in that, what you've just shared with me there 'cause it makes so much sense and I think with our audience, it will as well. It's what I see within companies, you know, it's the teams that do the work, make it work. And that's really important. So yeah, I was just taking some time there just to reflect on what you were saying. Why don't we switch gears and do a couple of quick fire questions here 'cause I'm curious to understand some of the good and bad of product ops. So what would you consider is a best practise, or I'm not a fan of best practise, a good practise in product ops. What's a good practise?

  I'm gonna talk about not a good practise in product ops, but a good product, how product ops is successful. What makes product ops successful is having a seat at the leadership table. Because we're fundamentally talking about how the product management discipline exists. And without someone with a voice advocating for that in product leadership, it doesn't usually work out well, right? So the way we have to interact. I think there's three things that are necessary to make any kind of change in an organisation successful, especially with the person leading it. One is you need the power, you need the mandate to do that change, and you need a lot of luck. Like, those circumstances around you matter, right? And if you see everything against you, hey, don't bother, try something else. Build the foundation to get to the change that you want. But you know, you can't go from zero to one, right? Like, if you just had an incredible leader join, they wanna make their mark. Like, you know, if everything's aligned, then great. That's the way into it. Yeah, and that was the perfect set of circumstances I found myself in. And like, we were able to basically turn an organisation that was told what to do to, like, we built our own roadmap. We took dates off the roadmap. Like, we had a single, we had a single prioritised list of big bets that was agreed upon by the whole organisation.

  You didn't have a strategy as well, did you, May?

  We did. The big bets is kind of, is the trade off.

  Strategically placed. Yeah, exactly. I love that. What about some of the big mistakes that people might make in product ops?

  It's really easy to get caught up by the small things, right? So one of my personal rules when I do product ops, like, everything you take on is a project because it has to end, otherwise, you own it forever. The only thing that you end up owning over that duration is tooling. You can't avoid it. You own the tools, but any kind of change, the goal is to make the people who are impacted by the change and the people making decisions on that change, they own it going forward.

  So you are consultative, but you're not BAU.

  Like, you might be involved for a little bit, but you have to see yourself out of that process 'cause after five changes, you don't have time. But it's so easy to get caught up in it because you're like, "Oh, it's still changing. Like, I need to see this through." And it's like, no, the goal is to train the people to do the changes themselves, right? Like, I tell people that my job is to work myself outta the job 'cause if you don't need me there, you're good.

  And I feel the same way about as a consultant in the way that I like to work with people as well. Because otherwise, I will just be employed by that company to do the BAU. That's not what I want to be doing. I'll not have a wider influence, but I love that, you know, it's like the project based approach is great thought.

  I mean, like, it's project based, but your product, like, I think of them as, like, features you kind of build on top and then you keep an eye on them. But ideally you have someone else keep an eye on them so it's someone else's problem.

  Yeah, exactly. So talking about multiple changes and bringing those in, but never really being the in-life owner. Does product ops therefore need its own product ops roadmap?

  Most people have one, mostly because they need to justify our existence. It's important to think about what's coming next 'cause then you also, like, while you are doing the discovery for whatever you're doing, you might wanna do partial discovery for the next thing as well, right? It's a continuous process of learning. Your priorities are going to shift. And it's really about, the way I think about prioritisation of, like, what's most important in product ops. The way I do it is three tiers. One is is something stopping us from shipping today? Because delivery is actually the most expensive thing and therefore, the most important thing to untangle. Two, is something causing conflict? And conflict is what slows people down. But it's like a second order slowing. So the more conflict you have, the, like, quadratically slower, exponentially slower people work.

  Cue maths teacher. But I'm with you. I've got enough math to understand that. But yeah, right? It's exponential.

  Yeah. Yeah, and so it's really important to look for those areas. And then the third thing is just, you know, standard strategy. What's important, what's quick, what's-

  Yeah, absolutely. How does product ops get involved with the road mapping process?

  Communication is what's broken. It's not the roadmap. The roadmap is a symptom. The lack of a roadmap is a symptom, but the communication is so much more than that, right? A lot of the times, like, when you do your first month of interviews, everyone's just like, "I don't hear anything from product. Or all I get from product is things I don't need. I don't care about that."

  What I asked for, it wasn't on the list. I'm not happy.

  And then you talk to the PMs, they're like, "We're trying so hard, but we're so burnt out. Like, I got so many things on the go." And then you look and you see like, there's 20 meetings they're in that there shouldn't be in. And like, it comes back to role clarity. Like, this is role clarity. This is about really, like, what do you want product managers to be doing here, right? So for me, when I look for, when I look for a product leader to work with, it's our understanding and like, just basic principles behind product management have to be at least spiritually aligned. We don't have to use the same words, we don't have to use the same frameworks. I don't really believe in frameworks, but whatever. But it's just, like, all of these things together. Like, we need to be able to work together and I am here to build the team that can get you to your strategy and your vision faster, right? That's what I do.

  Yeah, I love that spiritual alignment. And maybe that goes back to the teams that you were talking about earlier. It's like they just need to be spiritually aligned, or even more so, but spiritual alignment, gosh, that's a great concept for me to take away and think about a little bit more. I totally agree. Totally agree. It's about that trust.

  You can't do product management without trust.

  No, you can't. Some of the best relationships I've had are with product managers because you're in it together.

  You're in it together. But like, in terms of organisational trust, leadership trust, right, like, if you really wanna do product management well, people have to trust you to make the right decisions. People have to trust you to, like, give you, entrust you with more information to tell you what's going on, to give you access to data, to give you access to the customers. There's so much trust involved. And then the developers need to trust you to tell them the right things and like, that they have the whole thing. And also to trust you to give them access to whatever they need and want to do things better. Same with the designers, same with, like, everyone in the ecosystem. And then you need sales to trust you and marketing to trust you and services to trust you and ops to trust you if it's complicated, right? So all of these things come together and it's all about trust. You are at the centre of trust and if you don't build that trust, you can't do it. And so, like-

  I love that.

  Think about that operational infrastructure that allows you to build that trust easier, that allows you to hire a brand new PM and let them build that trust.

  Do you know what, May? I can't wait to listen back to this episode and make some notes myself 'cause I'm gonna nod my head off in a minute. I know I love that. And actually when I talk about roadmaps and what they are, it's about communication alignment, but I think it's also trust, I wanna throw in there, and level of confidence. I don't think confidence and trust are the same thing. Confidence for me would be how confident are we that we can do something and then trust would be, you know, we trust that the roadmap is gonna reflect reality and trust that the teams can talk about it. But I wanna throw those four words in there now for roadmaps, just from what you've said 'cause I think it's so important. Love that. May, you've got some great ideas and I've thoroughly enjoyed listening to you share those in today's podcast, but also in some of the formats that you co-host and run yourself. I'm curious whose advice on product ops do you listen to and are there any resources that you'd recommend either myself or our listeners within "Talking Roadmaps" to go and check out?

  My favourite people are Jenny Wanger who writes a brilliant newsletter. I also just published a meeting audit on her newsletter back in December, so check that out if you're struggling with meetings. There is Graham Reed who writes about practical product ops and like, he's generally a lovely, lovely person. I really like Chris Thomson's work, obviously there's John Cutler, and then who thinks about organisational design and scale and-

  He's put some good stuff out recently about that.

  I don't even know how to describe his work, but it's a lot of the inspiration behind what I do. And then there's Chris Butler who just, who also exists on a different but practical but also interesting plane. So all these people think about things very differently. There's also a lot of, like, obviously voices of people who talk and I think it's always interesting to hear what they have to say.

  Yeah, I do too. So I'm thrilled that we've got a couple of those folks on the podcast as well. But also it would be great to shine a spotlight on people that have got different backgrounds and at different companies to do that as well. So we'll be looking to do that on the channel. But thanks for sharing. I mean, that's a great list for us to work from. And so as we start to wrap up, I'm just curious if you had to distil your philosophy of product operations into a couple of sentences, and by the way, it's okay if you go over, how would you describe it?

  It's about building the right product discipline in that specific context by giving individual teams the autonomy, the alignment, and the access to information that they need to make better decisions. And then connecting those teams together so you're working together to build the same thing.

  That's not the first time you've said that either, is it? That was very well articulated.

  It might have, like, changed a little bit throughout our conversation, but I tacked the things together.

  What I love is it pulled the pieces from our conversation into that, which was really good. May, before I let you go, thank you so much. It's been a brilliant pleasure talking to you, but I wanted to give you an opportunity just to pitch yourself. If people have really enjoyed listening to you today, which I'm sure they will have, how can they get in contact and just let us know.

  If you're a product leader who's thinking about how your team can work better, if you are coming up against a big change, whatever it might be, legacy products, trying to move to something better, or large organisations, if you're about to hit rapid scale through an investment, if you are, whatever it might be, MNA, that kind of change is where product operations allows you to build a strong foothold and that really strong product management discipline within your organisation. So if you're not thinking about, it's not about now, it's about what you need to be to really push your organisation forward during and through and past that change. So that's what I specialise in. Complex operations, I love complexity. And so whatever it is, B2B specifically, it's usually B2B to B2C.

  Is it Mary or Marie Kondo of product ops and messy company processes?

  No, no, no. I'm a little more heavy handed. You know, every time I talk to someone who, they're like, "Well, what's your special ability?" And I say I get large groups of people to do what they think that they don't wanna do, but actually enjoy doing it.

  Amazing. I mean, surely that's magic for a lot of companies. Super. Well look, May, I'm gonna end it there for us. Thank you so much for joining us and so for people at home, again, thank you so much for joining us on this podcast and on the YouTube channel. We love having you here. We love having you sharing your comments and reach out. We've had some great comments over the years. If you wanna learn more about May, please do and check out her on LinkedIn and get in contact that way. If you wanna understand more about what we do here at "Talking Roadmaps" and certainly from a product ops and road mapping perspective, then talkingroadmaps.com is where to go. You'll see previous episodes and details of workshops and some other things that we're gonna be doing this year, but that just leaves me to say, May, thank you so much. I hope we get to speak again in the future. I really enjoyed that.

  Me too. Thanks, Justin.