How does productops create the right environment for product work? | Chris Butler
In Season 2 Episode 4 of Talking Roadmaps, Chris Butler shares how product operations can foster effective, sustainable product teams—going beyond process to shape culture, decision-making, and systems thinking. He explores AI's role in roadmapping, why product ops shouldn't become glorified project managers, and how speculative design helps teams prepare for uncertain futures.
Product leader that drives innovation at the intersection of technology, design, and strategy. With experience spanning GitHub, Google, Facebook, Microsoft, and startups, He has led impactful initiatives in AI, productivity, and responsible tech. From crafting speculative design fiction to mentoring future product leaders, his work bridges creativity and execution. As co-founder of The Uncertainty Project and a product operations leader in AI & Productivity at GitHub, he focuses on aligning vision with action to create ethical, sustainable, and impactful solutions.
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 Jenny Wanger, Product Operations Consultant and Advisor. So watch out for Season 2 - Episode 5!
-
Product ops is not here to just do the bullshit work that PMs don't want to do. That's not their job, right? Their job is to look at things overall systemically to say, this process is not working for this PM, it may not work for all these other PMs, and so now how do we evolve the process over time or actually remove a process?
Welcome to season two of "Talking Roadmaps", where we're here talking about product operations. Today I'm joined by Chris Butler. Chris, introduce yourself.
Absolutely. Well, I'm staff product operations manager at GitHub focused on AI products right now. But I'd say my background includes mostly product management. That would be at places like Microsoft, Waze, KAYAK, Facebook Reality Labs, where I worked on the Portal device and Google, where I was part of the core machine learning team. But I've also done my own startups where one was like, a Complete Seating, which was a OpenTable or TopTable competitor way back in the day. I've worked at design consultancies, I've worked at large consultancies like Cognizant. But more recently my kind of arc for my career has been really thinking about how do I start to take kind of the principles of product management and apply it to the way that teams end up doing their work? Which is why the last couple of roles that I've been at have really been focused on product operations. And I also do a lot of writing and speaking in the product operations community, mostly through the Product-Led Alliance, the Product Ops Summit. I've spoken, I think every single one that they've had so far. But yeah, so that's what I do. I'd say that I also have some other weird projects around kind of how do we use things like design fiction or speculative practise to start to understand where the future of work is going, where do these teams go? And then I use AI in my practise an awful lot just within a product operations kind of role within GitHub to help us do better work for the team.
If you're enjoying the channel, subscribe, hit the bell and give us a like. So I'm sorry, I'm super intrigued there, design fiction. So sorry, unpack that that for me before we even go anywhere near product ops. I'm intrigued.
Well, so design fiction is this practise, that it comes out of kind of like, the discursive design or kind of speculative futurist type of practises where what we're doing is we're basically creating some type of artefact from the future that then helps us have better discussions today about kind of the values, principles, things like that. And this comes from someone named Julian Bleecker who runs the Near Future Laboratory, which is kind of a group I'm part of. But it's kind of a hyper collab kind of group, so it's a bunch of people coming together to talk about this practise. But an example of this would be, if you remember in like "Minority Report", there's a cereal box where Tom Cruise like, pours some cereal out, it starts to play some music, there's like an animated cover. But that doesn't quite work right. Like, it keeps playing, he has to throw it across the room. That particular kind of design fiction, as we would call it, really talks about how cheap technology is in this world in the sense that you can put animated kind of not only screens and audio on an actual product box, but it's kind of starting to talk about like, what are some of the pros and cons about having technology everywhere in this world? And that was actually created by Kevin Kelly, who I've been on his podcast before, "Cool Tools". But he was kind of an advisor on the "Minority Report", like, feature. And what's really interesting about just "Minority Report" in general is there's lots of like, places where they start to really dive deeper into what is the technology and what are the implications of that technology inside of the world? And so I use this in a lot of ways. Like I'm working on something that's called the Employee Manual of the Future, which is where if you were to join a company in about 20, 30 years from now where, you know, AI agents are ubiquitous, where kind of return to office, what does that actually mean as we really understand it? And so it's kind of using that as an artefact from the future to be able to try to have better conversations today about the direction we want the technology or application of technology to go. And so I've used this kind of as a way to think about, you know, what is the future of work for us and how do we start to bridge to that future in some way?
Interesting. Yeah, I can see a couple of things playing together there, like how you can see how things like the iPad were inspired by some of the work in Star Trek, but it's now kind of formalising that and taking it and turning into a technique.
And even more "2001", right? Like, "2001" has many applications of that type of thing. And yeah, so it ends up being, I think the artefact itself inside of design fiction is meant to be something more mundane than say, a high technology concept like a tablet. But it would be kind of like, what is the user manual that comes with that, or what is the warning sticker that's on the box? And it's meant to kind of, it's called a diegetic prototype, which is really meant to just start a conversation. And it's meant for the person to kind of look at it and go like, "Huh, that looks like something normal. It's a cereal box." You're like, "Oh, why's it have like, a video playing on the front?" Or another example of the cereal box is one by Julian Bleecker, which was like, this one has a cricket on the front. It looks like it was just like a child kind of friendly animal, but it's actually because it's made out of cricket flour. And so what does the future of food mean in this world where cricket flour is so normalised that it's part of kind of children's cereal boxes? And so it's supposed to do that type of thing where we have discussions. And I've used this inside of like, product orgs to be able to start to talk about what are the future or the implications of what we're trying to build? So at core machine learning at Google, we talked about, like one of the themes we thought about a lot was like, accessibility to machine learning technologies. And what would that mean for it to be truly accessible by everybody, right? And so you start to get into this realm of like, what are the military applications of that? Like, I ended up creating a design fiction that was like a military manual for jailbreaking exoskeletons found on the battlefield. And like, there's a bunch of things that are all inside of that that make you question like, is accessibility the right direction to go? Is that a right value for us to even consider? And there's a bunch of other interesting practises that come outta that, like Moral Imaginations was a group inside of Google that would use speculative fiction to then set up a discussion where everybody would role play the government, the company, and journalists in kind of this interaction that would help us understand like, is accessibility the best thing for us to think about in this case or not? And so anyways, I always love this type of stuff 'cause futurism is not about actually planning the future. Speculative practise is not about planning the future, but it's about having better discussions today about where we want to go. And so that's how I kind of use this sometimes in my practise.
I've just discovered a rabbit hole I'm gonna find myself going down for the next month, I'm absolutely sure. Because I'm seeing that, yeah, I used to think about the kind of, how you say, mainstream science fiction was causing that thing. But now as a structured practise. And it kind of resonates a little bit with the Remember the Future Past Game that Luke Hohmann has in "Innovation Games", which is a technique I've used a lot for envisioning shorter term, kind of where should we go as our business? But I'm gonna lose some time to this over the next few weeks.
Well, I won't mention the Uncertainty Project, which is another thing that I also am working on that's about like, decision making and strategic thinking. But yeah, anyways, like there's, I guess what I would say is like my practise is varied. I try to pull things across domains a lot of the time because I think we can learn from the way that other people do things. Like another example of that is just like, product managers I don't think do enough when it comes to critiquing of their own content. And so pulling that over from like, code reviewing from an engineering practise or design critiques from like design practise I think ends up getting us these tools that we may not have the language for quite yet within the practise. So that's why I do a lot of this stuff.
And I'm gonna have to pick your brain on that Uncertainty Project at some point, 'cause the book I'm writing is all about product decision making. So it's close to my heart. But let's take ourselves a little bit into product operations with that, having gone down that rabbit hole for a second. Let's go to a fundamental question. Why do companies need product ops?
Yeah, I guess like I would say that the reason why we need product operations is that generally the people that are supposed to be setting the tone, the process, the culture in some way, and you can't actually set culture explicitly, but being able to set up the environment for the way that say, product managers do work is usually the leaders within those teams. The problem is though is that they tend to have a lot of other things to do. And so what ends up happening is that the times that they actually end up focusing on these types of things about the way that the work is done is usually when there's a crisis or an escalation. And so they come in and try to help fix it, but it ends up being kind of like a point in time rather than an ongoing review of the practises and trying to improve that. And I've often called it PMing the PM experience is what I think of as product operations. I would say that there's a huge spectrum within the world of product operations. I talk to a lot of product ops people, and so some of them tend to be more on the side of like, this is a kind of programme manager type of role but for product people's work. Sometimes it is very much about the culture, the team dynamics, the process. And so they're more like organisational consultants in some ways. But I'd say overall what we're really trying to do is we're trying to make product managers work as effective as possible, 'cause we believe that product management is actually a high leverage activity within the organisation. Now there is kind of, I just was on a podcast that was released about a couple weeks ago that was all about PMing the PM experience, is that the right way to talk about it? Or is it that we're actually trying to, as a product team, we're there as operational advisors or coaches or whatever to be able to like, make the product team work better? I think that ends up overlapping an awful lot with the technical product manager, the programme manager, the project manager type of role. And I think causes a lot of confusion sometimes. So if you wanna listen to that podcast, that's where there's a good argument between me and a couple other people about whether it is PMing the PM experience or whether it's more about like, the product team as a whole. So I would just say just like product management, there's variation in the way that this type of role happens, but in the end it's about how do we make product managers and the teams that they're part of as effective as possible? That's really what this role is for.
And that kind of rings a lot of bells with me when I think about the DevOps movement from a few, it was like 15 years ago, where there was a wide variation there from site reliability engineers all the way through to what I would think of as a true DevOps engineer that's kind of really creating that culture and way of working in the organisation and supporting the team to operate the products themselves. So yeah, I think it's, I can imagine we're gonna go through a similar evolution. And probably still have some spectrum even in 15 years time.
Absolutely. And I mean probably, product ops first entered the vernacular probably just a couple years to five years ago or something like that. And so there are these roles popping up everywhere, because we see that a product manager may not be able to see across all of the different things that are happening on their team to be able to understand like, how does the entire software development lifecycle, how could we improve that in some way? And so I would say that that's the thing that we're trying to do is we're trying to do that. Now inside of that role too, sometimes it's focused on making our leaders of product more successful too. And so there are different needs that happen for the leader versus the ICPMs or even leads on their team. And so inside of GitHub, for example, we have a separation between more centralised product operations groups that may own kind of overall release tracking, things like feedback, that type of stuff. I'm actually what we refer to as a portfolio operations manager. And so I'm embedded with a handful of leaders and their PMs to be able to help their teams. And in particular, I work on all of the Copilot stuff, essentially.
We've got these people who we're calling product operations managers. What makes a good one? What sort of background experience do they need?
I mean I think, just like product management, I've seen people come from all over into product operations, but they tend to be roles that are more like, focused on project or programme management. I would say that sometimes customer support managers, because they see this gap between the way that CSMs and the product managers end up doing their work. I would argue though that when we talk about kind of meta skills, like if product management is really about being able to wrangle the uncertainty of the world and interpret uncertainty for the team, if they're about decision facilitation, not necessarily decision making but decision facilitation, and then finally this like, idea of alignment and communication. I would say we take those same principles and we kind of apply it to the way that product managers do our work. I think being very organizationally minded, like how does this entire system fit together? So John Cutler is someone that's a friend of mine that I think does a really good job of trying to understand the systems of a team, for example. And so those systems, you know, if I'm putting on my consulting hat again, is that it usually comes down to people, process and tools. I've seen a lot of product ops people tend to be focused very much on the tooling. So in our case it's like how do we set up GitHub on GitHub for example, right? We use projects and issues, we use a bunch of stuff like that. But I would say that's usually just like, a very surface level application of the product ops role. I think the other two things you need to focus on is, you know, what is the process and how this fits into all the other processes within the organisation. But then the people, right? Because it really comes down to how does this leader do their work? How is it that the team interacts with that leader? And so I think, you know, being able to be very understanding of the dynamic of the team is really, really important in that case. And so I think that idea of like holistic views, dynamics, systems thinking, things like that. But I think there's like also a component of just like execution, 'cause there's a bunch of times where product operations people will be asked to come in and be a stopgap sometimes. Now I think this is problematic in some ways. And the reason why is that like, product ops is not here to just do the bullshit work that PMs don't want to do. That's not their job, right? Their job is to look at things overall, systemically to say, "This process is not working for this PM. It may not work for all these other PMs." And so now how do we evolve the process over time, or actually remove a process if we no longer know why it exists? And so those are the types of things that I think portfolio operations feel. Now having a background in product management is very helpful because, you know, over the amount of time that I've had, which I'm not gonna mention because that ages me in some way, being aware of product practise and the evolution of product practise over time I think is also very helpful. Because you bring, you know, I think not only a confidence but also people will trust you more if you have sat in their, you know, seat and walked in their shoes previously. So I think that is very helpful in this case, especially because whenever I think about all the different ways that we could solve a problem, there are many different ways, right? Like not only just like frameworks, but the idea of like, how have I seen processes work like this previously? So a great example of that is that every single place I've ever joined, every new leader I've ever started to work with, they wanted to have a new way to do status report. And that particular thing, it always fails, by the way. Like, it always fails at a certain point. It always breaks down because after a certain point the questions become stale, people don't see the value of it. And a lot of the time is because, you know, we're not looking at the system and the way it works around what status is actually for. And it's about this idea of not only providing information up to leaders so that they can then summarise and provide it to leaders again above them. But it's also this idea of the two way street of like, being able to get kind of ongoing adjustment, feedback, critique of the way that we're doing things. And so that's the biggest like failure that I see is usually the leaders themselves are not willing to adjust the way they do their work to be able to do a better job with their teams. And so I'd say my hardest problem is actually getting leaders to change, not necessarily instantiating some type of new process or getting compliance by the PMs to do that process, right? There's power structures at play that kind of do that. But it's the opposite way that is actually usually very valued. And so, you know, I've been also thinking a lot about this from the standpoint of like, what are the ways that we'll apply AI to these types of systems longer term? And so just looking at something like status reporting, I think there's something really interesting about how right now when we write status, it's usually because we're trying to interpret the mindset of the leader that we're giving the status to. When the reality is is probably they should be the ones that are defining what is really important to them. And so I almost think about the future of this type of thing is that there's some information that is kind of out in the ecosystem, the information ecosystem of the organisation, which is not only things like purities or specs but like, updates to like, issues or releases, a bunch of stuff like that. Which the leader then has a filter by which they're looking at certain pieces of information. So I would argue that actually the leader themselves should write a prompt in the way that they want to start to summarise information rather than requiring someone else to learn, over time by the way, it's not very easy to learn, but if they don't give you feedback you don't know what is valuable. And so I think there's some of this reversal stuff that we need to do about the dynamic of like, just that type of thing, just like status reporting. So those are the types of things I think that a product ops person needs to deal with, is it's not just do we have a place to put status? But how does this work with the PMs? Are they getting the feedback they need? Are the leaders getting the information they need? And all those types of constraints and kind of concerns.
So much to unpack there, so much to unpack there. So yeah, the product operations manager acting as the filling, like sometimes they almost seem to be set up to be assistants to the PM in an organisation, I find, like to do that work that the PMs don't wanna do. And yeah, the ways of working, if I think back before we had a term, product ops, me as the product leader and one of my team were doing product ops. Like he was doing the status reporting and analytics part and I was doing the ways of working part. And maybe that, actually from what you just described, was the right balance because I could see across, whereas he couldn't.
What's interesting here too is that I think, again, when leaders are asked to do this type of stuff, they may have kind of innate kind of belief in certain aspects of this, and so they'll then focus on it, right? Like someone who's like a new product leader that is really good at, say, like actual practises, they will fall back on doing the work during those times of like, stress. But I think what's important about the product ops role is that there's a separate person that is incentivized to be able to create better environment. Rather than just this idea of big bang change that happens when there's a crisis, we should be continuously evolving the way the teams are doing things. And that's the reason why I think that this like, idea of a separate role. Now I do think that like there's other people inside the community like Melissa Perri, Denise Tilles, like they wrote the book about product operations. I think that they tend to focus on things that are maybe more in a traditional DevOps sense, that there's like, these gaps between what a product person does and, say, the team that collects feedback, right? And their argument would be that the product ops person should be instantiating people, process, tools that are all about how do we get feedback to the PM better? And what I would argue is that I've worked inside of teams where we have a really great set of cross-functional partners that should be handling this type of thing. And so that could be like user experience research, that could be data scientists, that could be content strategists. And I'm kind of just talking about a team that I had at Facebook Reality Labs. Facebook does a really good job of having all of those different cross-functional people there, because it's not necessarily the product person's job to be an expert at user research or an expert in data analysis. And so it doesn't mean then also that the product ops person should just take over that role in my opinion, right? We should be working with people that are experts. It's just like, I use legal as an example of this. Like, product ops people are not gonna be experts in legal, but they may be able to help you set up systems for compliance or the right types of conversation around legal. Like, I was, for the last I think seven or eight months, I've been the Lead Responsible AI Champ for GitHub as well. And so a lot of that is dealing with the way that Microsoft wants to have auditability and compliance to the way we do responsible AI. That was a very specific role. I think it's more of a programme manager role with a little bit of like, kind of looking forward to the way we do responsible AI. But it was a stopgap in all honesty, right? And so that's what I would say is I think we do get in this realm that whenever it is, there's this gap here where there's a role that should be here, but it's not, sometimes product ops will take that on. And so I think that is a little bit of an anti-pattern for product operations. But I would argue that like, when you're in smaller organisations, you know, a single PM will do all types of things, basically.
PM has been that stopgap for forever, right? Like, I led the ISO 27001 infosec sort of compliance programme for a large company years ago because we cared about it as the product, it was important for our saleability, et cetera. Someone needed to take the lead. So we covered the gaps because product ops didn't exist. And so I guess it's a subtle shifting to a smaller group, but a group that I sometimes, I love the talk of making things better, the ways you work. I've kind of always used the analogy, product ops should be always trying to make themself redundant, I'm not needed. Because they're making so things are done better and they don't need to work on it anymore. However, there's always the next problem to work on.
Well, that's why like I think this balance of kind of strategy and execution is really valuable for a product ops person, because there's gonna be a time, to get a programme off the ground, there's a lot of just like, pure execution work. So that's fine, right? Like, that is part of getting a programme started and running. There's also the ongoing maintenance of programmes. So one of the things I do for example is every six months I do a listening tour with every PM that's part of the org that I'm working on. And just to understand kind of like, what is the lived experience? Like, I would argue that if I'm a PM, in general, my customer is the PM, the PM leaders, cross-functional partners. And then maybe the lowest rung on the prioritisation ladder as far as customers is actually the real customer, 'cause my job is there to enable that team. The product that I'm building is actually the community of practise. It's the lived experience of every PM. And so when I look at it through that lens, what it allows me to do is start to say, "Okay, well there's a problem that's right now. We need to figure out what's going on, first of all." And then based on that we need to then create experiments to see if we can improve it in some way. And I would argue that we're also trying to not do any harm. I think that the very like, ham-fisted way of doing product operations is we see a problem, we create a process-tool type of combination and just roll it out to everybody and everybody just has to comply. But we never check back in on that process, right? And so if we apply all these things that are from a product management perspective, we're gonna try experiments with like, one team to do different status reporting. And we're gonna see if that works, does it get the information that people need in all the different ways? Or if it doesn't, then we need to modify it. And then we also need to check in after a couple months. I've been starting to, it's like a really interesting study by NASA, I think it was in the '70s or '80s about this like, task load index that they call it. And so after an astronaut does something like a spacewalk or a maintenance, they fill out this like, questionnaire that has a lot of stuff about kind of how stressful was it? What was the cognitive overhead? How urgent was it? How well did you think you did this? And they use this type of information to then say over time, like, how do we make this so it's less and less cognitive load, so it's more natural? Is it becoming part of their routine? Like, all those types of things. So I've started to experiment with, you know, I usually hate surveys because they don't give you the why behind things. But sometimes it's easiest to kind of get that type of information. And so one of the things we did for status reporting was just check in, like, you know, how did you feel like you did about this? Like, how stressful was it? How urgent did you feel when you're doing this? And starting to understand that gives us kind of a view into the mindset around these processes that they're starting to take on. So that's why I'd say like, doing everything that a product manager would do is really valuable in this type of product ops role. But I do want to avoid the fact that like, we should never assume that the team is in a final state, right? I would say that the future of this type of work, I would almost argue like, we have someone on our team that, because we build a lot of stuff inside of GitHub, there's a lot of kind of reliance on actions and automations inside of GitHub. But that's an engineering task. And so we have someone that is actually specifically there to write automations. And so what this says to me is the future of this type of thing is that kind of where we had thought ideally like, centralised HR systems are kind of about like employee management, I think longer term we need to have cross-functional teams that are building tools internally. And there are teams that build like, a one-off tool, and they're like a product cross-functional team usually where there's engineers, maybe designers, maybe product people. But I think we need to be more kind of purposeful about this as time goes on, to say that the team is in a constant flux of change. And change is not always seen as good. Like, there's two books that I think are great like, product ops books that are not product ops books. But one is "The Problem with Change". I think it's actually Goodall. And he really talks about this idea of that any change is actually bad for the team, because what they're trying to do is they're trying to like, build out a way that they can understand what is going on. They talk about the blender and the way that we're constantly reorganising teams. And we should be doing that based on things like Conway's Law, because you ship your org chart. But like, we need to find a balance between pushing for change and not doing that. And then the second book that I'm just reading right now is actually "Under the Hood" by Slap. And this is where, basically treating the culture of the organisation as its own organism where it's constantly trying to just understand what is going on. And it gets scared. Like, when it sees too much change, it can't link the actions of the leaders to the way they do their work. Like, the organisation builds another narrative even if you don't like it. And so I think these types of things longer term I think are really where product operations should go. Now I've seen over and over again, though, that product ops ends up being relegated to a type of programme management, a type of chief of staff. And I think that you're underutilizing these types of people in those types of roles.
My reading list is growing by the hour, or minute even, because I've always been naturally a change agent. Like change just to me is, I believe that product managers break organisations as they go to set them up for the future because the old ways didn't work or won't work for the future, but they fix 'em as they go as well. It sounds like I've got some new partners in product ops in that journey.
Absolutely. Yeah, and I think product ops, like, you know, what I try to tell, like I try to, every time a new PM joins the organisation, I try to, you know, I get a one-on-one meeting with 'em and try to just be a guide to the organisation. 'Cause they're gonna hear lots of stuff from lots of different people. But being the person that sometimes understands a lot of kind of deeper cultural things that are going on, I think that the product ops person can be a guide for product managers as well. Now I think a lot of my job is also like connecting people. It's creating systems of record. It's doing all these things that allow for PMs to be able to like, get up to speed faster as well. Of course we don't always have time for all of these different projects, but I would just say like, generally the focus should be on how do the PMs actually build the best thing with their team and do something that is successful? But I would also say that like, you know, inside of an organisation, there are cultural values that we may espouse. And I actually have a talk that I'm giving at ProductWorld this year, where it's about kind of this difference between values and culture that end up happening. Like, and part of the talk is that I show people like, a value statement by a company and ask them to guess who it is. They never are able to guess even though it's a very well-known company. It's because the values themselves that are espoused are not the same ones that are actually the narrative inside the organisation. And so my job, as I see it, is to help actually understand the reality of what the culture is. And then that allows me to help set the leaders up for success from the standpoint of, and I kinda mentioned this earlier, like you can't set culture. Like, you can yell at people about culture as much as you want, but the things that you do to actually set culture set up the environment. Which means who are you hiring, firing, laying off, promoting, right? What are the behaviours, and that includes like, what behaviours are you then like incentivizing or punishing? And then finally, you know, what are the goals that we're setting and actually funding from the standpoint of like, attention? And so all those things actually create the culture inside the organisation. And I just hope to be kind of a guide for those leaders to understand what is the reality on the ground? And so I think of myself as sometimes as that person that can side channel feedback that maybe product managers are not feeling comfortable that they can give to their leadership. It doesn't always mean that leaders listen, right? Just to reiterate my point about this, but my hardest problem in product operations is getting leaders to listen to the feedback and change the way they actually do things. And so that's, I think, how product operations ends up being so kind of enmeshed in this culture conversation and the dynamics of that organisation.
Sounds like a similar challenge to how product management get enmeshed with being considered just technology as opposed to that broader cross-functional role, and that challenge of perception of the roles. So interesting. So in fact, maybe that's a good point to segue onto, okay, we're recognising the value of this thing, at least we are. How do we justify product ops?
I mean I think if you look at the way that employee satisfaction works, right, a lot of employee satisfaction ends up being about how people have the lived experience at work. And I would say that a lot of the time, like for very high functioning organisations, the reason why PMs fail is actually not usually because of like, what we would call performance issues, that they're not willing to do the job. Like I would say it's fairly rare in most of the teams I've been on that people don't want to do the best job they can. However, there have been plenty of times where a PM has been put into a particular type of role for a particular team, and then the environment itself does not allow them to be successful. And so I would just say like, one of the most important things that I think product operations can actually help with is actually reduce attrition. And when I say attrition, I mean people that you're getting rid of because you think that they're not in the right role. But because you can help understand like, what is the right role, how do we form this role and this team to be better? But also the idea of like, retaining people that are high value. They're more likely to churn when they're in an environment or with a leader that is actually not doing things that are helpful to them. And so that's what I'd say is like, this idea of retention and attrition is something that's at the core of the way that I think that product operations really helps the organisation.
So what do you consider to be best practise in product operations? Notice it's a loaded phrase, right? Some people hate the phrase best practise.
Well, I'm not gonna give you a maturity scale because I think that they oversimplify things too much. So I think when we talk about product operations, I think the most valuable way for us to think about things, and I actually think about Cynefin, and this is my interpretation of Cynefin, it's not exactly the way that Dave Snowden talks about it, but I think about each domain within Cynefin, which is basically like, I guess the way that I've seen it interpreted a lot of times is that problems fit into different types of problems that are either clear, where it's like very obvious what to do and people just do it. Complicated, which is there's like, some experts can do this, there is like a best practise in some way. Then there's complex, which is that there's a bunch of like agents interacting with each other. It's very hard to understand what's going on. You have to experiment to understand what is the current state of that system. And then chaotic, which is like, you know, all shit's breaking loose and you just need to like, get outta the burning building type of thing. And then there's like disordered in the middle, which is kind of, we don't know what's going on yet. I've interpreted as that every problem that a product ops person actually deals with can be viewed through any one of those lenses. So if we view something through the complicated lens, we think of it as that we just need to have the right process and tools in place and then things will work out well. And that's one lens, right? Like whenever we create a release tracking process or a go to market process or something like that, we're looking at that lens where all of these different things can be turned into a complicated process of some type. But I would say the other lens that we need to look at sometimes is that maybe we don't actually know what's going on with this team. And so we need to use the complex lens to then kind of probe, sense, respond, as he would talk about it, inside that lens. And so I guess my, like, I love his terminology around liminality between these different domains of Cynefin. And so I would say that like, and again, I won't use best practise as a terminology here, but I think the constant liminality for product operations people is looking at something maybe through the complicated lens, 'cause there's already a process that exists for that. And sometimes we need to then detect that a complicated process is no longer working for us. And that's usually when people don't remember why the process was there, people tend to build shadow systems around that process or they just completely opt out of that process. And if that's the case, then we need to say we're no longer looking at this as a complicated lens, we're gonna look at it through a complex lens. And we're gonna understand the people that are working on this, what is the actual process to take place? What actually works, what doesn't work inside this world? Like, where are there bright spots in the org? Where are there like, dark spots in the org? And start to use that to then do some probes or experiments and then eventually turn that back into a complicated lens process where we say, this is now a process that is across the org. So that liminality between complex and complicated is constantly happening. And so I think the ability to be able to shift your lens between those things is really, really valuable for product operations. 'Cause sometimes it's the execution work of the complicated process. Other times it's understanding what's going on with the team and figuring out how do we actually make them more effective? And sometimes it might mean we actually just keep our hands off of it, right? There's a real, I would say product ops goal sometimes to allow for grassroots kind of improvement of process, that inside this cross-functional team, they figured out a way for them to do this thing that is really valuable. And so we just leave them alone. Like for example, inside of GitHub we have a team called Next which does a lot of like, advanced prototyping type of stuff. And for them, like applying a lot of our release rigour to their process would be bad. And so in that case we just need to say that like, in this case, we're just gonna leave it. It's a complex lens. They have a team dynamic that makes sense. But we're not gonna apply this complicated lens to the work that they do because it will stifle the creativity that's supposed to come out of that group. And so that's where I kind of, I see that as like, that liminality and that dynamic is something that product ops people, when they really understand the way the teams are working, they're constantly going back and forth between those two things. And then sometimes we do drift into chaos. Like, you know, inside of GitHub, you know, we have a lot of competitive threats right now in the environment. Everybody's building a Copilot equivalent for, you know, code completions. It's a highly dynamic technology environment, right? There's constantly, like every week, like just R1 DeepSeek is crazy in some of the benchmarking it's doing for an open source model. So like, technology itself is constantly changing out underneath us. And so in those cases, right, we are sometimes pushed back into chaos when we have to make like, a revision in the direction that we're going as a team. And product ops needs to be there to help with that process as well. And sometimes it's like, how do we now think about our new goals, right? But sometimes it's like, how do we actually just get stuff done in a way that will help enable the team right now? And so those are kind of examples of how I think of the ideal mental model for product operations people to exist within.
Yeah, and I can even imagine that I'm sure there are some times where there's an existing complicated model where the world has moved on so much that we should just be taking it to a simple lens and a simple model, because we worked around the complexity, or the complication, I should say.
Like if it's a ritual that people are following, like that doesn't require a lot of complicated things. Like if there's communication that is naturally happening because of certain aspects of the environment, and that could be the way that people interact with each other, that could be who they're meeting with. It could even be just like as simple as like, here's a cadence for a meeting. Like yeah, I think it gets you into that clear kind of domain. But I would argue that a lot of the work we do rarely falls into clear. And the reason why is because there's a lot of like, because of cross-functional teams, because of the fact that ideally when product managers are involved, we're trying to build something new that hasn't existed before. That means that it's very hard to ever assume that anything is like, totally clear. And you'll realise this the moment you start talking to people that are brand new from outside the org coming in, like, how do we do release management here? It's not clear. Like, it's actually something we need to like, improve the onboarding documentation around and then give them the ability. But again, that's why like, I try to be a guide in that case sometimes, to just be able to bridge that. Like, how do you get up to speed on like, what is the most important thing? And what I've been telling people recently is like, the release tracking information that we have feeds into so many other places that that is the most important thing for you to do is to create release tracking issues early and maintain them. That is the one thing I will tell you you need to learn how to do right now, 'cause that is super important to the way we do our work. And so, but that's not easily found in documentation, right? Like that's not easily found until you've like, gone into one of these release tracking meetings and your stuff is not up to date and the CPO sees that, right? Like, so I do think that there needs to be some of these things that are, you know, even though most things won't be clear, I think, again, we can guide people as a product ops person into something.
Now I'd be remiss on a channel called "Talking Roadmaps" not to ask you a few questions about roadmapping. So here's the fundamental one. What's product ops' involvement with roadmap?
So inside of our case, like because there's the TPM group, which is basically organised under engineering in our case, they tend to focus an awful lot on de-risking the way that engineering does delivery. In our case, I think of the shearing layer for us as kind of releases and roadmaps up for product operations, and then epics, initiatives down for TPM and engineering, essentially. And so we are very much involved, like one of the artefacts that I help facilitate are the various forms of roadmaps that we may have. And so the one that people may be familiar with on GitHub is we have an external project that actually lists out things that are there. There's a whole process by which, how do we make it so it's not all the jargony stuff internally, but how is it actually valuable for people externally based on kind of customer value, outcomes, things like that? And so I help with that process, essentially. We also have internal roadmaps, which are all the different things we're dealing with. We also have this idea, and that's actually in a GitHub project. And then I would say finally we have this kind of constant tension between accurate information which is inside of the tools and then information that is easily presentable in a narrative. That would be to not only senior management, right, AKA slides. But also the idea of like, when we have a CAB meeting or when we have like, a public kind of talk or we're meeting with high value customers, there's this need for kind of different types of presentation. And again, I don't think that I've ever seen a tool really do a great job at this, because usually tools are focused on accuracy of information, slicing it in a million different ways, that type of thing. But it doesn't ever beat the idea of like, there needs to be a narrative that includes a vision that includes kind of like, a way that you should care about this. And so that is something that we help do over and over again. And so that's what I would say about like, for portfolio operations and product operations in general, I think that we are the people that try to at least set the people, process, tools for having not only great, highly accurate information that's tracked in these types of tools, but also how do we end up making sure that that narrative is not too far away from what's actually in those highly accurate tools, basically?
Yeah, I always end up coming back to slides, I have to be honest. 'Cause it's a storytelling tool and every audience is different. Like I'm literally, in the first 70 episodes, one of the things that my co-host and I spent a lot of time doing was thinking about roadmap visualisations. Like, we've distilled it down to about 14 different visual patterns. And literally, I was in a coffee shop this afternoon, I'm writing a short ebook about those visual patterns because I think there's more than just the board, the Gantt, and the table, the classic three. We can do so much more to tell a powerful story for those different audiences.
Well, it gets even more complicated too, because like, I work with other portfolio ops people across GitHub, right? And so there's actually a larger GitHub story that we try to tell sometimes, versus the story that is just for like, the AI stuff that we're building. And so yeah, I think that's a very hard thing to get right over and over again. I would say though that like, part of portfolio operations is that we, and also our centralised product ops group is really a lot about like, how do we enable the go to market teams in a way that is really effective? And so the release tracking and roadmap is the way that we end up making sure that like, what we call field sales, revenue, like, that they're enabled with the right type of information, especially in a fast moving world like AI stuff. I think one of the things that product ops also helps with is kind of the injection point for different initiatives from the standpoint of product. And so one of those I think that, you know, I'm kind of working on right now is how do we do a better job of, before something gets into the release tracking system, what are the things that PMs need to be doing? I would say that like a lot of teams, it kind of just comes from everywhere, right? Like sometimes it's a senior leader telling you we need to launch this feature, or it's grassroots where a product manager sees some problem that they wanna solve for their customer and then it kind of just gets like shoved into this process. Whereas I think there's like a real value for standardising the way that we do kind of approval or rejection of something that we're going to think about applying resources to. And so I would just say like portfolio or product operations in general is all about like, those injection points for PMs to kick things off and how they get out there. But then there's other points, like how do we make sure that the right types of like, cross-functional discussions and trade-offs are being leveraged? How do we make sure the right information is flowing up to management when it comes to the status of these things? And I do think AI is gonna change a lot of this, because if you are tracking everything in code on GitHub, through PRs, with issues, a lot of that actually give, there's status that you should be able to discern out of that information automatically. And I would argue that I'm guessing at least 1/3 to half of the work that I do should be automatable in the next little while. And I'm gonna put the timeframe of years here. But I think that like, anytime I'm able to write down a process, it should be automatable. That's really the thing. The times that there's a piece of something where a human needs to make a decision, that is something where we should have the human making the decision. But if you can write down a process today, you can probably automate it in the near term. And I think that's good because that means that I focus less on the program-managery parts of my role and I think more about the team dynamics, human aspects of the role. So I think that's good overall, but I think it will happen over the coming years.
So listening to what you said there, how would you respond if someone said, "That sounds like you're putting gateways in place. It sounds like you're going back to waterfall." Because like, I mean, I'm actually a believer that gateways done right are a good thing, gateways done wrong are a bad thing. But I heard kind of gateways without saying gateways.
I think like that it's very polite of you to say gated development rather than waterfall. Because waterfall was a thing 20 or so years ago that we just assumed was the way that things were working. Like, I was at Hotmail when Scrum first came out, and Hotmail was one of the first teams inside of Microsoft to actually leverage true 28-day Scrum, basically. Like the Scrum book, right? And so what I would just say is like, I think that there is a way for teams to iterate fast, right, based on building, prototyping, getting customer feedback very rapidly. I think that that's absolutely what the goal of agile was meant to be, if we talk about it like from a lowercase a standpoint. And I won't even mention things like SAFe and that type of stuff. But I do think that there's a certain amount of gating about, you know, when you get up to the level of kind of a, what I say, portfolio understanding of what's going on inside the organisation, teams can't move every day. People cannot move every day. There's context that's necessary. And so this idea of doing a better job of actually managing what is going on in the team and then where do we think we need to move over time, like, that is something where you shouldn't just automatically change everything every day or even every week, right? And so that's what I would say is like, I think everything is gated in some way. It's just that sometimes the gates are so small, like the idea of a PM creating a work item this week that will be delivered this week, there's still like, kind of steps here that are taking place. They just are very small. I think once we get into like very large organisations, we need to do a better job of understanding the overall portfolio management of resource allocation and where we need to be in the future. And that requires a certain amount of gating for us to consider, is this item something worth even bothering the mind share of the cross-functional team with, or is it not valuable? And if that's the case, like, that's fine if people are thinking about it, but we're not going to now say this is on our roadmap, this is in our release tracking system and things like that. Like, I think that is really important for us to do. Because it puts the onus on the product leadership to say what is actually important. And that is one of the jobs that they need to bring clarity about every single day, basically.
Deciding where to place our chips, where are we placing our bets and putting our efforts, that to me is the point of gateways. It's like, we've gone so far, we've learned so much, we can make a decision whether it's worth putting any more chips into that pot.
And gateways can absolutely include just like, learning opportunities, right? Like, there are plenty of gateways where they shouldn't be a full product initiative at that point. It should be like, is this even valuable? And so I see that all the time, especially in like early stage groups, like they wanna build out everything. And the reality is like, they should be kind of focusing on the assumptions they have, like a la David J Bland, assumption mapping type of stuff. And then they should build experiments for the things that they don't know enough about. And so I'd say larger organisations lose sight of that, right? They think of it as that there's some feature that we need to build now, and that basically just needs to happen. Whereas, you know, what is the right way for us to do something like this is actually a great question, and should be gated before we go into full development of something.
Love it. So we're gonna return to product ops, I think, now for the last few questions. Whose advice on product operations do you listen to?
I mean, I would say like John Cutler and his newsletter "A Beautiful Mess" is really great for kind of systems thinking, I would argue. I'd of course say that you should try to listen to me a little bit too, so I have a lot of writing and speaking about that. So I'll plug myself since we're the best people at self-promoting ourselves. You know, I think John Cutler. I do think though that, you know, this kind of discussion between Marty Cagan and Melissa Perri about what is product operations I think is an important one to be aware of too. Because I think Marty Cagan is making the argument that product ops in its worst case just turns into process management, which he's right. And then Melissa Perri talks about it from the standpoint of, you know, there are stopgaps in these teams that need a lot of help. And she's right. And so they're both right, I think that they just bring different viewpoints on what that is, right? And so I would say those are kind of the main people. I would say that like Product-Led Alliance, they have a lot of content about product operations, some of which I've written. Like I actually did the original Product Ops Certified Course for them. And so I would just say like, there's a lot of really great operational people that speak at their Product Ops Summit that is like, once in New York, once in the Bay Area. And so I would say those people as well. Those are probably the kind of groups that I would go off and listen to.
So if you had to distil your philosophy on product ops into one or two sentences, what would it be?
I mean, I'm going to fall back on my product operations as PMing the PM experience. That's probably the simplest way to put it. But I would just say that product operations is really just about helping PMs find, let me rephrase that. Product operations is about helping PMs be as effective as possible and do the best work of their life. That's what I would argue.
And I always have to end up with the Steve Blank question of what should I have asked you about product ops that I haven't?
Well, I guess maybe you should have asked about like, my belief about product ops in the future is I feel like we're at a crossroads. And I keep on seeing a lot of product ops roles be more like programme management. And what I worry about is that product ops may be a flash in the pan, where it just turns into a different type of project management. And so I guess I'm worried about the future of product operations based on that. So that's maybe the one thing I would say.
Yeah, does it turn into the new PMO?
Yeah, exactly, exactly. And we have programme managers that are part of our team because there is an aspect of this work that is about tracking execution, de-risking, et cetera. But I really worry about the way that I, I guess, envision the ideal, helping a product team to be as effective as possible. If it's overly simplified to just tracking execution work and de-risking, we don't actually ever imagine a team that is better at what they do today. And that I think is really concerning to me.
Chris, it's been an absolute pleasure having you on the show today. Love the conversation. Always like to give you just a last chance at the end to pitch yourself and how you can help people, how they can get in touch.
I always love to be connected to people on LinkedIn. And if you have questions about product operations or need like pointers to resources, I'm always just happy to be that guide to the product operations community as well. And then I'd also say check out the Uncertainty Project, which is basically a community of people that think a lot about decision-making strategy. And so I've done a bunch of writing there, but it's usually kind of like, how I think about strategic thinking and tools that help you do better strategic thinking. So I'd say go and check that out as well.
Been awesome having you here today, Chris. Thanks for your time.
Yeah, you're welcome. Thank you.
