Roles of Product Ops and Product Manager | Chris Butler

80

---

In this conversation, Chris Butler, a product manager and writer, discusses his professional journey and the role of product ops and product manager.

Chris Butler is a chaotic good product manager, writer, and speaker who excels in facilitating critical decision-making for teams creating innovative products. With a focus on bias, uncertainty, and randomization, Chris helps build robust and resilient teams. His extensive experience includes product leadership roles at Google, Microsoft, Facebook, Cognizant, KAYAK, and Waze. Chris is known for pioneering techniques such as Empathy Mapping for the Machine, Animistic Design Mapping, Confusion Mapping, and Analogical Innovation Mapping, which enhance cross-team alignment in AI product development.

Takeaways

• Product managers should be adaptable and have a broad skill set that allows them to take on different roles and domains.
• Effective product managers have strong communication skills and can facilitate decision-making in various modalities.
• Having an open mind and a growth mindset is crucial for product managers to continuously learn and adapt.
• Working with leaders who are resistant to change can be challenging, but it is important for product operations to drive change and help leaders adapt to the needs of the team.
• Product management is a complex and evolving field, and organizations should consider their unique context and culture when implementing processes and practices.
• Understanding biases is crucial for making better decisions.
• Balancing individual biases and groupthink is important for effective decision-making.
• The Uncertainty Project focuses on decision-making and strategy.
• Meetings should facilitate discourse and understanding, and eliminate those that don’t produce action items or decisions.
• The future of product management involves the impact of AI, human decision-making, and personalization.

Connect with

• Medium: https://chrizbot.medium.com/
• LinkedIn: https://www.linkedin.com/in/chrisbu/
• X: https://twitter.com/chrizbot 
• Uncertainty Project: https://www.theuncertaintyproject.org/ 

Connect with Vit

• Website: https://vitlyoshin.com/ 
• LinkedIn: https://www.linkedin.com/in/vit-lyoshin/ 
• X: https://twitter.com/vitlyoshin 
• Other: https://linktr.ee/vitlyoshin 

Timestamps

00:00:00 Introduction

00:06:15 Product Manager is a Combination of Many Other Roles

00:12:12 The Role of Product Operations

00:23:54 Qualities for a Good Product Manager

00:31:00 Challenges of Working with Resistant Leaders

00:34:09 Understanding Biases and Decision-Making

00:37:45 The Uncertainty Project

00:44:56 The Value and Purpose of Meetings

00:55:13 The Future of Product Management: AI and Personalization

01:05:49 Advice from Chris Butler

Transcript (Edited by Vit Lyoshin for better readability)

Vit Lyoshin (00:01.304)

Hello everybody. Welcome back to the Vit Lyoshin Podcast. Today we have a new guest, Chris Butler. He is, as he described himself, a chaotic good product manager, writer, and speaker. And he’s been leading product teams at Google, Facebook, Microsoft, and Waze, just to name a few companies. And now he’s a staff product operations manager at GitHub.

Welcome Chris, nice to have you here.

Chris Butler (00:32.878)

Great. Thank you so much for having me. I’m excited to be here and excited to talk about all things product and whatever else.

Vit Lyoshin (00:39.8)

Yeah, absolutely. Today I’d like to talk to you about product management and product teams, and also maybe touch a little bit on the future of product management, where we’re going and things like that.

But, before we jump into the topics, could you tell a little bit about your professional journey and the work that you do now?

Chris Butler (01:03.15)

Sure, yeah, I guess like, I’d say that overall I’m a product manager. Like I think that’s the identity that I associate with the most, but I’ve done a lot of other roles. Like I’ve been a co-founder for a startup. I’ve done engineering, I’ve done graphic design as an apprentice for my dad. I guess you could say for a little while I was like a gray hat hacker in high school or just like a person that computers stuff. 

I’ve done business development. I’ve done sales. So there’s just like a lot of different things. I do a lot of user research. So I think about myself as a very broad type of person that does a lot of different things. But I was even just having a conversation with my manager at GitHub earlier today, just about kind of like the future of my career. And it ends up being very weird, I guess. Like, you know, I sat on the podcast with John Cutler that I kind of have an octopus career. And I do believe that there’s a lot of different identities that I think of when it comes to the way I do my work.

But I think there is kind of like a centralized practice and that centralized practice ends up being an awful lot about how do we use kind of like the I guess lessons from other domains, other professions, other practices to be able to make really decision-making and building great products for customers as something that we can do really well. I mean, of course, I’m excited about a lot of other kinds of interesting and weird topics. But yeah, I guess the journey really has been varied for me, right?

So I apprenticed as a design person in high school to my dad, doing a lot of weird computer and phone stuff during high school, going into engineering during college, and then immediately afterwards going to Microsoft and joining as a program manager. And this was before product management was as popular as it is today. It kind of felt almost like at first that I was being shunted to a different less valuable topic.

I’ve told this story before, but I think the thing that really was interesting to me is being asked the question, during the interviews while I was in school for Microsoft, was how would you design a washer dryer combination for someone that was site impaired? And that type of understanding the context of the person, what problems they are dealing with, was really exciting for me. I felt like I was doing a lot of that while all of my senior projects were really about me trying to pull together what is the right thing to build.

And then I would kind of build it, it was okay. But I wouldn’t say that I was like an amazing engineer, you know, like I was an okay engineer, I could understand a lot of the engineering concepts, but I wouldn’t say that I was like the best coder necessarily. And so from that perspective, I think I went into program management, which at the time was like some weird combination of product and project management at Microsoft. We were dealing with a lot of Gantt charts and MS Project and also doing the work of a product manager.

But that really kind of set me on this path of just product management in general. And that idea of, you know, I think Marty Cagan, you have all of his books behind you right there. Like he talks a lot about this idea of customer obsession, which I totally agree with. And then I would say like, you know, how we make sure the team is making good decisions. How do we embrace the uncertainty of the world? And how do we do a good job of communicating and aligning the team? Right? Those are things that I think I really enjoy and love.

And as I’ve kind of progressed through my career, I’ve started to alternate back and forth between say product management positions and product operations positions, because I see product operations really as like PMing the PM experience. I think I was maybe the first person to point it that way. But, you know, why that’s valuable is that actually my product in this case is the organization. It’s the, you know, community of practice. It’s the individualized product manager experience.

And so I see all of the things that I learned and have kind of gained experience and skills in around product management as being applied to the way that product managers do their work. And so that’s maybe kind of brought us to now, at least as far as my journey. But yeah, it’s a lot of weird things. Like if you go and look at my LinkedIn, it doesn’t really make a lot of sense other than the fact that I’ve just been in the Bay Area for a very long time and other places doing weird tech stuff basically.

Vit Lyoshin (05:10.68)

Well, I guess with everything that I heard, I can make a quick summary that a good product manager is a combination of another 10 or 15 different roles, right?

Chris Butler (05:24.078)

Well, yeah, I guess that’s an interesting way to put it, especially the Martens Venn diagram that we end up seeing everywhere about product management being between business, technology, and design a lot of the time. And so I’ve started to talk about this. I just did a three-hour session with Epic, which is the ethnography Conference. It was kind of a partial workshop, mostly a discussion about what is product management so that ethnographers, and user researchers can understand how to help product managers more, right? And, I guess what I keep on saying in those types of contexts is it’s not just these three things, but it’s like, we actually need to bring all of these different cross-functional groups together to be able to make good trade-offs and decisions as a product manager. And I think of it as like, not necessarily like risk reduction, like project management, TPMing, those types of things, which are really valuable.

In that idea of risk reduction, making sure there’s repeatability of process, things like that. But I think it’s like, how do we push innovation? How do we push on the trade-offs? And while I have experience in a lot of different domains, I still trust in those domain experts that are part of my team. So I believe a lot in qualitative user research. And even though I give talks on qualitative user research for PMs, if I have a qualitative user researcher that’s on my team, I leverage them as much as I can because they are the experts in this thing.

Now, it doesn’t mean that I don’t use common language that we might use. So maybe a good example, just honing in on user research. User researchers are really great at helping us answer really open-ended questions and very specific questions. And depending on the type of question, they use different types of research. And so I would not necessarily tell them to do a particular type of research for a question I had, but I would pose the question I really want to have answered.

I would say, is there a way for us to understand this? And then I would say, here’s analogies that I think of, here’s other places that people do this type of thing. And that ends up being really helpful for them. But they can then say, like, you know, I think we should do a contextual inquiry project, which is going and observing someone in their context, right? And I would then say also, you know, I think here’s the contexts that are most interesting to me. So being able to speak that language, I think is helpful for product managers, but we’re not always the expert.

Like legal is a great example of where things are constantly evolving when it comes to the patchwork of say privacy regulation. And I really came up against this at Facebook Reality Labs, we were trying to do biometric recognition for the portal device. Like there were a lot of issues that Facebook had with doing facial recognition, right? So we had to bring in a lot of experts that were really well-versed in the legal repercussions of risk around these things. And while I started to learn their language a little bit more, it was still them as experts. And so we would talk about the trade-offs there.

I think that’s what’s really important, I wouldn’t say necessarily I’m an expert in all these like 15 or N domains that we want to include here, but I try to at least build a common language with them. And sometimes it’s a language that’s closer to the customer, which I think is ideal. But other times it’s about me learning some of the terminology for their domain as well to be able to then, you know, like when I was doing business development, a lot of the time when I’d work with legal, it was slightly different. It was more about contractual terms, like are these contractual terms good or bad?

So we started to build an understanding that here’s a template that we are accepting, and then here’s common requests. And then some of those requests are acceptable, some of them are not. And so again, you build expertise when working with these different domains of practice as well. So anyway, I do think that there is a place for highly specialized PMs, but I’ve found that people that are more generalists tend to be able to have all these different cross-functional conversations much easier from a product management perspective.

Vit Lyoshin (09:01.464)

Yeah, that’s great. The ability to delegate and the ability to just organize the group of people around you and around the product and have them march into the goal and deliver user value. I think those are the best qualities or the good qualities the product manager should have. But if they have expertise in a specific field, that’s fine. That’s good.

Chris Butler (09:26.286)

That’s right. Yeah, and sometimes when we talk about marching towards a goal, there’s a time and a place for being efficient about that. We feel like we have all the information we need or evidence that something is right, and so we should just execute as fast as possible to get it out there. But there’s also times where I think product managers should be… When we talk about embracing or managing uncertainty for the team, it also could mean that we’re putting off a decision until the last possible moment, or we’re building experimentation to build evidence around something.

I think it’s like, you know, product management is a lot about making the right product decision and that rightness is really, really subjective. And so that’s why intuition is so important in product management. That’s why like tacit knowledge in the sense of like, how do people build tacit knowledge through their career, through experience? Like that’s something I constantly think about when we talk about, not only how do we help build better cohesion between teams, but how do we help more junior employees gain expertise from the people that are more senior around.

And I’ve done things like decision forcing cases, which is kind of like a type of case study that builds expertise that comes from the US Marine Corps, but actually is from the naturalist decision making community around expertise transfer. And so there’s all these types of things that I think a lot about how my role almost as a product operations person ends up overlapping, not necessarily in the traditional sense of a product manager, it’s like engineering design, legal safety, security, privacy, et cetera. But it’s like organizational design, HR, learning and development.

And so there’s like the tools that I start to think of as a product ops person. So there’s also this interesting thing about the domain that you’re in ends up requiring different cross-functional people too. So that’s very interesting to me from a difference between say product management and product ops.

Vit Lyoshin (11:09.688)

Yeah, that was kind of my question. You’re describing your role as PMing the PM experience and how is it really different from normal product management and why is it important to even have such a role in organization.

Chris Butler (11:28.494)

Yeah, I mean, I think the main difference is really the customer, in my opinion. So the customer to me is a PM, right? And sometimes it’s actually the leaders, right? So this is an ongoing discussion inside of GitHub, especially for our role, it’s called portfolio operations, which rather than like, they’ve taken usually an approach of more centralized product operations teams around releases, feedback, a bunch of those types of things. Ours is more embedded with particular senior leaders for a particular group of product managers.

And so, we’ve been thinking about and playing with this idea of is it the VP or the senior director that’s our main customer or is it the product manager that’s on that team? And we trade-off depending on what the thing is that we’re working on. But I think the customer itself, the end customer, in the case of GitHub, all of the product managers I work with should be obsessed with our customer, which is developers and development teams. I am not as obsessed with them. They’re a third or fourth or fifth type of customer to me.

A couple of layers of people that I need to make sure are being helped before I get to the end developer. And so that’s, I think, one of the things is this incentivization of thinking about the way the work is done rather than achieving whatever we can for the end customer. So I think that’s a key differentiator. And I think if I were to then take on what is the end customer as my customer, I think this is where product operations ends up doing a lot of the bullshit work that PMs don’t want to do.

And so I think that’s a bad pattern, because just because something is happening where product managers don’t have enough resources, that product ops should do it. I think that’s fine. We’re here to help. But if it’s something that is going to happen forever, we should hire another product manager. Or we should change the systems that are causing that bullshit work to happen. And so that’s where I kind of see this difference, is the moment I become a customer obsessed with the end customer, I think it changes the incentives for my type of role, which don’t allow me to be as effective.

And I think this is where the future of this is going is that there’s lots of different types of ops rules. Originally, this kind of came from financial ops or operations from a service standpoint, like a manager of an actual place, right? COOs, that type of thing. But there’s also DevOps, there’s research ops, there’s design ops, there’s product ops. And so I think what this is all pointing to, though, is that eventually right now we’re talking about how do we improve this practice.

But I think overall, there should be a cross-functional team longer term that includes all of these different ops plus HR, at least the good, the parts of HR that I think are supposed to be helpful to people rather than protecting the company. We need to be like one group that really thinks about organizational dynamics and builds things and not in a way that is like today. I’ve seen a lot of internal teams that end up doing tooling. They try to do this type of thing, but they end up just being like order takers, I’d say a majority of the time from internal teams to just build it the way that that person wants. And the reality is like, that’s highly, that’s like building a product for one person.

You would not do that as a product manager. You would think about what is this balance between generalization to maximize the possibility of TAM for something like that versus this idea of building one product for one person. This is the same thing for startups where they have one major customer. They try to actually diversify their customers because otherwise, they’re building for that customer as a professional services organization. So I think there’s something really interesting there about that, which internal teams should have more agency to be able to say that actually this is not the right way to do things.

So I’ve been starting to become very intimately aware of this instead of GitHub too, not only from a product perspective, but I recently took over the lead responsible AI champ role for GitHub. And so there’s a lot of interesting things about the way that we not only work in compliance, which is more about like, do we have the documentation for this type of thing versus this idea of how do we look forward and what is truly responsible AI in the domains that GitHub works in.

And so that’s a very interesting problem because we have to balance this compliance aspect of it, which is in some cases legally required, versus this idea of how do we actually help PMs make better responsibility decisions in general, which actually may be in conflict or tension with each other sometimes. So again, that’s a very interesting thing, but it is another layer to this thing, is how we build internal tools and process and compliance and stuff.

Vit Lyoshin (15:46.971)

Yeah, I actually never heard before about this product operations role which is very interesting.

Chris Butler (15:57.166)

Well, Marty Cagan says that it’s not a real role and he worries about it being like a very process-oriented role. So I’ve talked to him a couple of times in person. He’s a very nice person. But I think there’s been this battle between him and Melissa Perry and Denise Tiles about the way they think about the value of product operations. I think in the end, like we all want to make sure that product teams are doing the most effective thing possible. And I think everybody will agree about that. I think the way we go about it is where there’s like some nuance around it.

Vit Lyoshin (16:28.664)

Yeah, and it seems like it’s an enabling role and maybe teaching them or maybe putting some processes in place even though these days not necessarily everybody likes that word.

Chris Butler (16:41.102)

Yeah, or removing process, by the way. One thing we forget about this is that if you can’t remember why a process exists and what are the benefits of that process, it probably means that the process is no longer valuable. And it’s just there for bureaucracy’s sake. And so that’s where I think product ops people come in. We can say, should we dismantle this or reassess the goals of this process? And so, I mean, this is just one of those weird things.

But for inside my role, I’ve been starting to rethink, what is the documentation that I create kind of like a PRD or specification for doing this type of thing. And we’re starting to settle on a format that I think is valuable. It’s not wholly different from a PRD, but it’s different in the way that we specify the way that people and teams and technologies interact in this case to be able to talk about the…

And even things like enablement, right? We think much more about enablement, I think, than the average product manager about how does someone adopt this? And then we need to think about mental overhead and work in progress for PMs. How does this impact their cadence? So there’s all these things that we start to think about in a slightly different way that is nuanced for the way that teams adapt, change or remove processes in ways that are no longer.

Vit Lyoshin (17:49.944)

Yeah, and I guess it also becomes more or less standard across the organization, right? Because in the old days, each product manager may be driving their teams in their own way. And now you have some like a central person.

Chris Butler (18:03.214)

Well, sometimes, yeah. I mean, I think that’s like a very interesting point, right? Is that like, there are some things that are good for a team to kind of build in a grassroots way that is specific to their team and their context and the things they need to get done, even the personalities of the team. And so there’s value in that. So they’re like, that’s maybe one of the things that I try to put into all of these things is that there are potential aspects of this new process that we don’t want to specify.

And we want to let every team decide the way that they end up doing this. But there are key things. The reason why we either adopt a process for one part of the org or across the entire org is where are their efficiencies in reducing or removing tensions or gaps between things versus alignment versus sometimes actually having siloing in between teams is valuable because if you have siloing, that means you have less dependencies ideally and that every team can rush forward and there’s value for that.

But there are other times where if you’re trying to create end-to-end products that are really valuable to a customer end-to-end, you want less siloing and you want more dependency building. And so it depends on the type of thing you’re building and where you’re at with that stage and all these things.

And that’s why I think being more aware of that means that as a product operations person that is more focused on the complexity of organizations means you will not build all up processes for every single thing that you actually allow for effectively like sense making of that PM in their context with their cross-functional team versus sense making that we do as product operations people, which is how are they doing their work and situating it within the larger organization in some way. So there’s value in both. And I always want to just make sure that’s clear, is that’s why I keep on saying like, it’s not only dismantling, but it’s like, you know, organization is fractal in the way that it works and that like at higher levels, there’s rougher versions of this versus at lower levels, there’s rougher versions.

I mean, I just tweeted, or sorry, I just LinkedIn, I don’t use Twitter as much as I used to or X or whatever, but I just LinkedIn about this. I was reading this post about a kind of computation and what is computation and computational thinking. And it harkens me back to my days of doing O notation and learning what that was, right? Which is all about this idea of complexity and kind of resource usage of a particular algorithm. And it started to make me think about this work in progress limit that people have for change, right?

Like people can’t be changing their process every single week. They’ll get burnt out by that amount of change, right? And so then it made me think about the fractalness of this, like, say we have a new strategic kind of process that is about how do we build roadmaps, for example. What is the impact actually of updating that roadmap all the time? And how does that impact all the individuals when you have to fan out the work that comes out of that? And I started thinking about like, is there a version of this type of O notation for the way that like organizational dynamics and design ends up doing things?

I don’t have a good answer for that. It’s just like this type of analogy and cross-domain thinking is something I try to bring to my practice in some ways. So yeah, that was something that’s just like a thought today that’s been kind of eating up some cycles in my head.

Vit Lyoshin (21:07.48)

Yeah, that’s great. I think that’s a very interesting and good point that each organization should look at which process to adapt, which process to eliminate. Because it’s unique to their business, to their industry, to their people and team and culture and all these different variables. We can’t just take some process that works somewhere else, apply it and hope for a miracle.

Chris Butler (21:20.654)

That’s right.

That’s a good example of this is like everybody talking about pizza size, two-pizza teams and the idea of working backwards and the idea of PRFAQs and weekly metrics reviews, like all that Amazon stuff, like it works for Amazon because they have, you know, again, you can say has it drifted or not and there’s different major areas of Amazon, but like there was a lot of cultural influence that was created through like incentivization and punishment and like who you hired.

And how all these meetings were happening with Jeff Bezos and stuff like that, that created the cultural environment that allowed for these things to work. Now, it doesn’t mean that these things can’t work elsewhere, but if you’re just like, the answer to everything is a two-pizza team because it worked for Amazon, that’s the wrong way to think about it. You’re not adapting it for your cultural needs or context, essentially. And culture is also emergent.

We keep on talking about culture a lot of times as if we can just tweak culture a little bit, but culture emerges out of what is actually considered to be successful here? The only things that leaders actually have ownership over is their own behavior. How do they incentivize things or punish things? How do they hire people? And then what do they set as goals? All of that turns into what people consider to be success or failure at an org, which is basically the emergent thing we call culture, essentially.

Vit Lyoshin (22:48.92)

Yeah, that’s a great point.

Let’s talk about qualities for a good product manager and qualities for a good product team. What would be your thoughts about that?

Chris Butler (23:03.758)

I mean, I do think that kind of in general, there’s a lot about kind of keeping the decision-making cycle moving as appropriate or time-boxing it and kind of like, how do we make sure decisions are being made in a way that are helpful?

So I think being able to communicate is very, very important, right? Like being able to do that in a bunch of different modalities. So that means like one-on-one conversations, group facilitation of a decision meeting. The idea of writing documents or briefs, async com through Slack and email and that type of stuff.

So those are all things that I think the better the PMs are at that, I think the better, the more successful they’re likely to be, just because they’re getting across their point and their question and all that type of stuff.

I would also say that I think being very open-minded a lot of the time, because we’re, and maybe the idea of over-indexing on growth mindset when it comes to being a PM, because you’re not going to be the expert in a lot of things other than being a PM. And so in those particular cases, like I’ve worked with, you know, occasionally like engineering, either leaders or engineers that are just incredibly difficult to get along with. And they’re just kind of jerks, right? They constantly make you feel bad for the way that you are asking questions or trying to understand what they’re doing. And like, honestly, I wish we didn’t have to work with people like that, but it happens every now and then.

And sometimes it’s a communication style issue. Sometimes it’s just like a poor interpersonal skills issue. And sometimes it’s because they’re rewarded for other things than actually being part of a team and having team cohesion. And so I think like trying to do a better job of looking at feedback or communication back as something that we like, thanks for the feedback.

“Thank you for the feedback” is a really great book because It helped me understand that I can accept someone else’s point of view and I can think about it, but it doesn’t mean I have to change because of that. That’s actually probably the most powerful growth mindset is that you should always be open to getting feedback from people. And they may not deliver it in a way that is very helpful, and they may not do it in a timely manner, but you should always be trying to learn from other people.

And then from there, you can decide whether it’s more of a taste thing. Your job is not there to do things the way everybody else wants you to do them. Your job is to make the best product possible. And so that’s where I think there’s something about this kind of, and again, I think there’s a lot of paradoxical things inside of product management, but yeah, having an open mind to and a growth mindset of learning things, but then also being and figuring out what does really great product management practice look like inside your context, those can both exist at the same time and they don’t always have to agree and that’s okay. Right? Like, that’s totally fine.

And then the last thing, I think, like anybody who is overly certain about something, like I’ve dealt with this mindset an awful lot instead of different organizations, but like, especially in places where there’s a lot of smart people, people are very sure of what they’re doing. I think I’m always questioning whether the thing I’m doing is the best thing possible right now. And it’s not necessarily, I wouldn’t call it imposter syndrome necessarily. I mean, there is something like that in the back of my head, like, is the best way to do this.

But it’s because I’m constantly just trying to understand, like, what is it I don’t know about right now? Like, I would say, if anything, my motto is like, I am wrong today, I just don’t know how yet. And so from that perspective, I think the embracing of that type of mindset is really good for product managers usually, because it means that they can constantly be learning from the environment, they can be constantly discovering new things. Now, again, the paradox here is we also need to be confident in the way that we end up interacting with people.

And so there’s like this difference between being curious, taking a stance of curiosity, versus just being steamrolled by everybody. And so I think there’s something there about that too. So those are all things that I think help product managers be better at their role. But again, there have been lots of product managers that are very successful in large organizations because they’re just so confident and they are so sure that they’re right. Now, it doesn’t mean that they don’t fail eventually.

There’s a lot of, I think, worry that I have that the people that have made it to like very senior positions have kind of been lucky enough that they haven’t failed yet. And so they seem like they’re right. They’re very certain and they seem like they’re right because they’re a place of success, but that’s called survivorship bias, right? And that they’re actually there because everybody else that was around them ended up failing. It’s just that they were the ones that happened to put lotto into that right place.

And so there’s a balance here. Like there’s definitely people that are very talented that are leaders, right? Like I’m not going to say that.

Vit Lyoshin (27:43.448)

Yeah. Or, maybe they failed earlier in their career and they learned from that.

Chris Butler (27:48.558)

Fair enough. Fair enough. Like Steve Jobs is a great example where everybody points to someone that is incredibly confident about something, but he’s failed in many different ways, right? Like, and, but he is very, again, very customer obsessed, very, very influential in the way that he would run his organization, had a very high bar for kind of like taste in the way that things were done. But he’s also a real asshole to everybody that he worked with. And some people lived in that type, worked in that type of environment, others didn’t, right? So, but he’s an example of where Next is a great example of where he failed, right?

So that’s what I’d say. I think that that is something I see a lot of the time inside of these large organizations is that people are very certain. Now, the problem with this too is that it makes my job really hard as a product ops person when someone is very certain. Because more often than not, being really good as a leader means that you also need to change as a leader.

Most of the time, whatever you want inside that organization, it doesn’t always happen, but at least you can push people to do a new process that you want. And it may mean that they will still do it because if they don’t do it, they’ll get fired or they’ll get penalized or something like that. And you’ll either have people like leaving the team because they don’t believe in the way that you want to do things or they’ll create shadow systems that actually get the work done. But more often than not, my biggest issue is actually making change in the leaders I work with. And that’s hard for leaders that have been successful in the past. They’ve been rewarded a lot in the past. They’re very certain about the way they do things.

Those are the hardest people to change because they were at this point and it’s called dominant logic theory. If you want to look it up, there’s a paper from 1980s management science. And I met one of the authors a while ago about this, but like there’s a real issue with the kind of people that have been so successful. They believe that their past mental models that they’re very certain about should be applied to current situations, but the environment may have been different. And so they’re stuck in this kind of trap of that they feel like they need to do things a certain way when maybe they should be doing them differently. So I’d say that my hardest job is actually dealing with leaders that are very certain about the work they do.

Vit Lyoshin (29:57.048)

Yeah, that’s very interesting what you just said, because I have this analogy in my head. I’m working in a government organization with a lot of scientists and all of them are really, really smart people. And whether you’re really successful or whether you’re really smart, it’s really hard to break through and try to either motivate you or change your behavior a little bit and things like that. It’s really, really hard. And I can really relate there with what you just said.

Chris Butler (30:22.702)

Yeah, that’s right. And there’s something to be said for people that are incredibly stubborn, right? Like there’s a lot of, there are things that get done by being stubborn, right? But we also start to see that like there’s stubbornness that’s like successful stubbornness in some ways, right? Like this person has made it up through the ranks. Maybe their stubbornness has gotten them there. But then there’s all these stories about people that are stubborn in a very unsuccessful way for a very long time. But then we find that actually they were right, right?

And I say this in a scientific standpoint, people’s stuff is harder to do. It’s not as straightforward, I think, in some ways, as scientific stuff. So it’s the idea of the people that discovered the blood-floated tumors, or the people that discovered how ulcers were bacterial, or mRNA vaccines. These are all examples of people that have toiled for decades. And actually, even the idea of the person who, I’m blanking out his name right now, was convinced that washing your hands would decrease mortality inside of places. I’m blanking out his name right now. But he died basically in an insane asylum because no one believed him that this was true. But he probably was a major change in the way medical science was understood.

So I would just say we need to be open to this kind of weirdos and the hotspots of success in different places. And that’s really hard to do when you’re very, very certain about things. And so maybe that’s my job. Maybe my mission overall, like I would say my multi-year mission is to get people to consider uncertainty more and to embrace it more. Because I think some of the worst things that happen in this world are because of people’s certainty about other people, about the situation, about what is right.

And so that’s where, I don’t know, I think that’s a very interesting thing. And so I would just say that gets back to leaders, right? Any leader that is so certain that you can never change them. It’s not actually worthwhile to have someone like me as a product ops person because part of my job is actually changing the leaders to adapt to the team and not just the team adapting to the leader, right? Which I think is a lot of what traditional disagreements with product ops as a role is about is that you’re just there to be the hatchet man for the leader to force the new status reporting format on the rest of the team. And if you just do that, if it’s not a two way street, then I think that product ops is actually just some type of process police.

That’s not how I do my practice. And that’s not how GitHub asked me to do my practice, by the way. But I think I’ve seen that every now and then. And that’s where I think my job is not effective if I can’t get some change from the leaders that I work with.

 

Vit Lyoshin (33:05.688)

Yeah, it also probably requires a lot of psychology and not in a way like to manipulate people, but to really understand where they’re coming from and help them out and help push through some doors and things like that.

 

Chris Butler (33:17.966)

That’s right. And I would say like, there’s a lot about just understanding the way that people make decisions. And again, biases are there because of the fact that we have limited information, we have limited time, we have limited resources. That’s why biases exist. But there’s other types of biases too. Like there’s, I was just reading through this paper that I can send you a link to, but it was all about how humans make stupid decisions in groups. And he’s using inflammatory language on purpose.

But like the way that we get out of that is that there’s this weird kind of middle ground that we need to find between all of the individual biases that we have, which cause us to not make good decisions as individuals because we’re not paying attention to all of the information that’s available that we should, right? Versus this idea of how we get into groups, think as groups, right?

So there’s a book by, I think it’s Cavaletti, it’s like Power and Crowds, which was from the 50s. And it’s all about this idea of the mob mentality and the reason why people end up really doing this type of thing is because we’re social animals, we don’t want to be outcasts. And so there’s like both sides of this cause problems for decision making.

The problem is that as a product ops person, I’d say product managers need to understand this too when it comes to adoption of their product. We need to understand both sides of that kind of equation. And it’s not even an equation. It’s more of just like, it’s a very, what’s soft system methodology and like complex systems type of thinking.

We’ll just think about this as like, it’s just like a wicked system that we need to deal with. And we need to constantly adjust and understand what’s going on. And I mean, the great example of this is that when I was at Microsoft, like the first time, I guess I’m now technically there a second time with GitHub. But when I was there the first time, the people in the office would talk about how the biggest competitor is not like at the time was not Lotus Notes or something like that, or Star Office or something like that. The last version of Office was the biggest competitor.

Because people don’t want to change, they don’t want to adopt new things, IT doesn’t want to roll out new software. And so that points to the fact that for product operations people, our big job is actually enablement of new processes. Part of it is designing the process. But the real thing is getting people to do the new process for the right reasons. And I look at whenever, if I’m getting my posts ignored, or people are not complying with the new process, I don’t see it as I need to do a better job of just bothering people all the time.

That could be part of it. But it really is like there’s something about this process that is not syncing or fitting with the way they do their work day to day. And so I look at that engagement as actually whether it is fit for them or not. Right. And it may be that they’re just dealing with too much stuff. And that’s a slightly different issue than just what I do as a product ops person. But it points to these issues that maybe they’re overburdened with other processes today or they have too much work or they’re owning too many products. So they’re kind of context switching all the time.

That is, I use that as a signal, not necessarily as like, hey, I just need to turn the screws harder on these PMs to adopt this process. But it’s like, I need to help them, maybe in a different way than what I’m doing right now. Maybe it’s just not the right product from my perspective, right?

 

Vit Lyoshin (36:29.336)

Yeah, that’s great. I mean, there are many different ways to influence people and if they’re busy, they do not pay full attention and they ignore stuff. So that’s not good. Yeah.

I wanted to ask you about the Uncertainty Project that you’re running or co-funded. What motivated you to start it and what are you doing with that company or organization?

 

Chris Butler (36:56.302)

Well, yeah, so the reason why Kyle and John first started doing this as part of kind of thinking a lot about decision-making and work, which I’m also an advisor for, is a startup that thinks a lot about kind of like how we track and understand decision-making inside of organizations. But the Uncertainty Project was something that we co-founded together essentially as a community, focused on decision-making and strategy and the way that we end up doing that type of thing.

It really started kind of as a newsletter at first. And so there’s a bunch of different tools that you can find there about different ways of making decisions, models for that. I mean, I think some of the things that I’ve written there are kind of like, how do I use randomness in decision-making to help make decisions more robust? Things like, you know, how we do things like decision rehearsals, which is basically like wargaming for the way that we understand things.

I’ve written a lot of posts about the meta stages of decision-making. How do we kind of separate things like the decision itself from the discourse of the decision? I’ve even talked about the idea of how virtual agents or agentive technologies as we talk about it today will actually impact decision-making in the future. And so it’s kind of a place for me to, I think, explore a lot of these thoughts, but also to try to build some like base kind of resources for how people should make decisions better inside of organizations.

More recently, we now have a Slack channel that’s very small, but with some of the people that are interested in talking more about decision-making, we’ve been doing some workshops about, I’ve been wondering an awful lot recently about how we visualize decisions and not only visualize them, but commemorate them and create artifacts longer term so that people can learn from those decisions, either from a thematic sense or from a, are the assumptions underlying this decision still valuable? And so should we rethink this decision?

Because I see a lot of orgs spinning their wheels on constantly re-litigating decisions that were already made and the assumptions haven’t changed other than someone’s opinion. And so I think there are some interesting things there that we start to talk about like what is the landscape and was very inspired by this, I’ve just been enamored with this concept of the memory palace, which I’ve heard of a long time ago, but as applied to this idea of like, how do I internalize the lesson of a decision as someone that wasn’t part of that decision.

I think it is a really key aspect of the future of how we actually manage decisions inside of organizations. So this is a place, again, very exploratory for me, but also to find like-minded people that want to talk about this type of stuff. And so, yeah, that’s the Uncertainty Project, but it’s been, it’s a really, yeah, it’s really interesting. It’s a newsletter. I definitely recommend you subscribe to it. I think we have close to 2000 or so subscribers trying to put out something every week. And John’s been doing a great job doing that recently. My stuff is more weird and experimental, so it’s not as frequent as John’s stuff.

But like I definitely try to post every now and then too. And then we do workshops and things, but I think there’s something interesting longer term. Just how do we help people in general do a more rigorous or better job, a more effective job at decision-making.

 

Vit Lyoshin (40:02.968)

Yeah, I think I will subscribe for sure because my master’s degree is in decision-support systems. Actually, yeah, automating it, but it’s mostly for business purposes, like business intelligence stuff and analytics, that early stage of artificial intelligence and things like that. But yeah, that’s definitely something interesting.

 

Chris Butler (40:27.438)

Cool. Yeah, and I think one thing I’ve pulled, I’ve done a lot of, when I think a lot about AI and machine learning, I think about it more from an HCI standpoint. And so a very important paper, which I don’t know if you came across in your studies, but Parasuramans, Trust in Automation, Use, Disuse, Misuse, and Abuse is one of those papers that is just so foundational about how do we set up the right levels of trust with a technology so that people can either disagree with it or agree with it or disable it or whatever.

I think there’s so much for us to learn, especially for the way things are working today with agentive technology. I’ve been doing a lot of talks recently about, what does it mean to have a multi-agent system? And is an agent is kind of this new hyped up moniker when the reality is what we’re talking about is usually assistive or automated technologies, but what is agentic and how does that actually fit within human teaming I think is amazing and interesting thing to talk about, but we can get caught up on what is agentic or not as a terminology and a definition.

I think I’ve been struggling with that type of philosophical thing in my head for the last couple months, just trying to justify all of the hype around the terminology and the moniker of agentive and agentic technologies basically. So yeah, it’s very interesting.

Yeah, I think like decision-making and all these models that we talk about from the Uncertainty Project is decision-making inside of that, how will better automated systems enable humans to make better decisions? How does it set up the discourse for better decision-making? How does it identify that a decision needs to be made by a wider group of people automatically? And then how do we start to learn through feedback systems on this?

Here’s a theme of decision-making that we keep on coming across that causes a lot of problems. This sounds like this should be a strategic question that leaders answer and then provides an easier way for people to make decisions in the future, right? Like, those are all things that especially with the newest large language models and in general, this idea of translation from anything to anything type of stuff, maybe gets a little bit easier because the tripwires that we used to have were very analytically focused. But now we can start to say, rather than just Google alerts, tell me whenever there’s a keyword in this industry, it gets you a bunch of garbage. There’s something more about the way that I can actually provide context and prompt, like a prompt engineering or that type of thing to say, like, here’s the thing that I’m actually more interested in. So give me more of that information, right?

There’s some amazing things that are going to be coming out soon around this. And I think, like, internal to GitHub, I’m working an awful lot on, like, how do we do a better job of, like, meeting summarization automatically using a transcript? And some of the meeting summarization services are not bad, but they also miss a lot of context. So, like, what are the prompts we should be creating to do a better job of creating a succinct version of this meeting for people that were not there that then need to be decision makers based off of the thing that was covered, right? Like that’s a really interesting question and problem in some way.

 

Vit Lyoshin (43:25.528)

Yeah, I think with all the decision-making tools and frameworks and everything input is also very important. Which questions you ask where you’re coming from those type things because that’s what becomes like your thing that you’re working with where you’re starting with and if that’s not the right question or not the right information that you get it then after that it’s all false.

Another thing I wanted to ask you is about meetings. Just in general, in the organization, what is your take on it?

 

Chris Butler (44:04.462)

Yeah, I mean, I’m doing a talk at Agile Alliance this year that’s called basically Meetings are Good, actually. And I think that meetings have gotten really bad rep. And the reason why is that people feel it’s one of the biggest productivity-like problems that people have is being in too many meetings. And I think it’s intimately related to the way that decisions are made inside of organizations.

There’s a really great book that I’ve been reading. I’ve read that it is called the enigma of reason. And they try to make a case that communication is actually for discourse of reasoning rather than internal to our heads. Even though Kahneman would say that there’s system one and two thinking and system two thinking is maybe more about this deliberative logical process potentially rather than kind of not necessarily heuristic, but maybe a Bayesian way of calculating what is the thing I should be doing.

This group, or this you know, these authors talk about the fact that like actually the reason why we talk to each other is to do a couple key things. One of them is to understand what norms are at play right now. Right? So right now we’re in the norms of a podcast. I’m going to talk in a very particular way, probably going to talk a lot more than I would have otherwise if we were in a regular conversation, because it’s going to be less about back and forth because you’re interviewing me and a bunch of stuff like that. So there’s norms that are at play in this conversation.

But then it’s also like when we have a really good conversation it’s about how do we start to build better mental models of what each other actually thinks or believes. And then decision-making is actually something after that, which is about power. It’s about all these other things like this person is actually the decision-maker or we have to agree because that’s the norm of the way we make decisions and bunch of stuff like that.

But I think like when it comes to meetings, right? And the thing that I think is really valuable here, what I want to talk about at Agile Alliance is really just about if we take this approach that it’s all about establishing norms and mind reading is the term of the author, and not in the ESP way, but like through discourse, we learn about what each other cares about, right? If we focus on those times for meetings, it means we get rid of a lot of meetings that are actually bad for us, like status reporting, or going around the room and just talking about whatever we want to have.

Problem is, that’s the easiest thing to do. It requires little to no prep. It’s just the way people do things, quote unquote, right? And so they just sleepwalk through the creation of these meetings, which then creates basically, it’s like a tragedy. It’s almost like a tragedy that commons for attention, right? It’s probably the best way to put it because no one really thinks about this. So everybody thinks that everybody’s attention is theirs to take. And the reason why they see that they do that and they see that is because people in power, they don’t attend meetings that they don’t think are valuable, right? They would prefer to have a meeting where they’re the ones who control the agenda. They control the entire topic flow.

Because they just want information or they want to tell you something or they want to make a decision. Again, there’s a bunch of stuff like that. But then people see those people in power doing it that way. And so then we create basically the equivalent of a traffic jam because everybody thinks that they need to go when it’s their time to go somewhere. It’s like, I use that example of the fact that you’re not stuck in traffic, you are traffic. And I think it’s a really good example of the fact that we are the reason why meetings are bad.

I would just say that I think there’s a real value for good discourse and a really good kind of creation of understanding between people. But we can use async tools for a lot of this other stuff that doesn’t meet those kinds of socio-technical systems where we’re trying to understand the norms in a more nuanced way or trying to actually mind-read each other. Shouldn’t have meetings in those cases. And so that’s my argument at least.

I’m also putting together a game right now, which is more like a role-playing game that I think we’re tentatively calling it Agenda, just because it has a double entendre about like meeting agenda and personal agenda. And it’s basically this weird role-playing game about meetings. Everybody has some stats in the meeting, they have action points, and then we basically role-play out a meeting, different formats, different goals, and then different kinds of personal agendas inside those meetings. And so like, if anybody’s ever done like six thinking hats inside of a meeting, it’s kind of like that, but to like some weirdlike role -play improv version of that.

I think there’s something really interesting about just like we should be experimenting more with meeting types as product ops people. I try to constantly frame experiments in different ways of doing things. And so I think it’s really valuable for organizations to think about this. And so yeah, part of the talk during Agile Alliance also just talk about like how I decide what would be valuable and say like a team summit that goes over the course of like a couple of days and kind of how do we decide like the input and output of meetings and situate that inside of like the larger organization.

Just in general, I believe there is a real value to having conversations. And if we are not always clear about why we’re doing that, I think we end up getting to this place where just everybody’s in nine to five meetings and they have to do their work later at night. And that shouldn’t be the way things are. You should be able to actually do deeper thought from a product management perspective. You should be reading things that are outside your organization, because that’s another problem I see is people becoming so insular. When all they see is really just the organization that they’re in working rather than seeing how they might compare somewhere else. So anyways, I just think that meanings are good actually. And that’s what I would argue.

 

Vit Lyoshin (49:25.848)

Yeah, the meetings that are not good are actually the ones that don’t produce any action items or decisions, right?

 

Chris Butler (49:34.99)

That’s right. Yeah, and they don’t allow for true discourse, right? Like the idea that maybe one of the worst, not the worst meeting, but like a bad meeting that’s out there is the group PM meeting. And what that is, is the group PM gets in front of X number of directs or skip level directs and just talks to them for 30 minutes about the hand down. And what they should have done is they should have just written that down as a memo, probably. What people should be doing in that meeting is learning how that senior leader actually does their work, right?

That’s not actually just, it’s not even just the idea of here’s what we’re doing, here’s what I believe, but it’s like, here’s the decision-making process for this thing and Q&A around that. Or like, I even think that this idea of just like playing games or doing case studies together ends up helping you learn so much about that senior leader. And I would much rather that we have a role, like a strategic rehearsal about the strategy that we’re applying and how it might go in the future and the way that senior leader would make decisions based on some uncertainty in the future, right?

I would much rather learn that from the senior leader than just hear them give me hand downs that are basically status, right? And so I think that’s an example of where power has created certain types of meetings that are good for the leader, but not good for everybody else. I think that’s really what’s most important here is that we’re trying to make it so that these meetings are valuable for everybody that’s in them. And if they’re not valuable for everybody, they shouldn’t be.

 

Vit Lyoshin (51:03.32)

Yeah, if I think about analogy with Scrum meetings, for example, actually some of them are not even called meetings, they’re called activities. Like for example, refinement. When the team gathers together and they’re working on ticket by ticket or requirement by requirement, figuring out what and how to do. So those activities actually are really valuable, right? They produce a lot of decisions and people actually know what to do after that.

But I agree most meetings are just, and people refuse to cancel them like no, let’s meet, let’s just talk about something, will come with an open agenda, come with whatever and it’s a waste of time.

 

Chris Butler (51:42.766)

Yeah, totally. Like, I mean, I think this idea of rituals or activities is valuable in a lot of ways, because it forces you through some cadence to do some activities, like something over time, right? Like you should do refinement on a regular basis, ideally, right? But does it always need to be a meeting? Maybe not, right? Do you always need to do it the same way? Maybe not, right? Like, so that’s, I think where like, there’s still a place for ritual.

I have been thinking and reading a lot about like experience design and kind of transformation and that type of stuff. And so I think there’s something about the way that we actually fit within the human experience of doing this work. But I don’t think we think about it that way. Usually we think about it, that we have to do this because it’s part of the cadence when the reality is like, maybe we should be changing or trying new ways of doing this, right? Like maybe one piece of advice I give a lot of people is if you’re worried that a meeting type is actually not valuable, kind of manufacture a reason to not do that meeting the same way.

For example, during holidays, right, like it’s the 4th of July is coming up right now when we’re talking. Like there’s a lot of meetings this week that went to async because of the fact that there was like not a lot of people around. And so that’s a great opportunity to experiment with like, did this meeting just go just as well as an async documented process versus a meeting? And if that’s the case, then maybe we don’t need that meeting. Right?

Or like someone not showing up, like there’s the whole realm of like, chaos engineering is a really interesting field, mostly from like the SRE world, but like, how do we remove people randomly and see how decision-making still takes place, right? Or how do we alter this process in some way randomly that then helps us figure out if this is a valuable process or not?

I think that’s something I’m constantly wondering about. Now, sometimes this is outside like the Overton window of what is acceptable inside of organizations. People are like, why are you messing with our process like this? We could go out of business if we don’t do this process the way it should be. So there’s like, again, this gets back at the main thing I really rally against, which is like over certainty in what we’re doing. And so, but you still have to deal with the contextual content, like the actual cultural context of your org still. And so that’s why some of this stuff is harder to do in some places than others.

 

Vit Lyoshin (54:00.728)

Yeah, I can see that the corporate culture or whatever it is and it just has to be the way it is.

What about the future of product management? Do you see any trends or any… Well, we know that AI is kind of changing everything. So maybe you can also provide your opinion on that and what you see.

 

Chris Butler (54:25.358)

I mean, I think one of the things that we should ideally see more of, and this is stuff, or I think the things that GitHub is working on right now when it comes to not only code generation completion, but the idea of the opposite way too, where we want to start taking pieces of code and summarizing it in natural language. I think that bidirectionality of translation from anything to anything becomes really valuable for PMs.

And the reason why is usually we would have a PRD or a spec that there might be some mock-ups or prototypes that are created. There’s a bunch of code that’s written. Then there’s like an architectural design that’s written after the code is written to try to encapsulate that. And then there’s like a bunch of iteration that’s happening across all these things. All of them are out of date with each other. And so what I wonder is this idea of this type of technology being a connector where it’s able to do the translation from these different things and try to detect when there’s like a discrepancy.

And if there is a discrepancy that is a really important trade-off discussion to have. If it’s something that’s very simple, that’s like, in the code, it was written this way, and that has the impact on this type of customer impact or the architecture impact, which impacts privacy or security, we should then talk about that thing, rather than discovering it through some type of many-meeting process or being caught by it when we go out into the wild.

So I think that’s one way the product management, the future of it will be changing. I also, you know, I think this role of being kind of an arbitrator of decision-making and trade-off, I think it’s still valuable. But I think there’s a lot of pressure right now from other types of fields like product design, the idea of managers or senior leaders, engineering managers, like, can those people do the product manager job or not? I think there needs to be a third party, like another party that is building tension between these cross-functional teams.

But you know, I mean, you look at there’s always this like, hype thing that like a PM’s job isn’t anything and so everybody else can just take that job. I think we need to think holistically about the way we build tension between practices and between teams and between different things inside of the organization that I don’t think we do a good job of right now. And so I hope in the future, and again I’m trying to constantly ask about this, we do a better job of providing that tension and creating healthy tension between things to be able to make better decisions.

Because that type of diversity of perspective does actually create better products overall. So I think that’s another future thing, maybe we’ll be more aware of this type of tension. Unfortunately, with the tightening of the job market, it feels like people are thinking about how we reduce the type of work that’s being done and automating more of it. I don’t think that’s going to necessarily get the answers that people want, though.

I do believe that a lot of these tools are more about augmentation than replacement or automation today. And so I think that’s something that there’s going to be a lot of fervor around how do we build more automation, but it’s going to fail in ways that they don’t want to fail. Right. And so, yeah, anyways, I think those are kind of like some of the things that are going to be happening. I mean, I do think like gigification or replaceability of people within an organization is going to come for these types of jobs as well, eventually.

That’s another thing. I mean, I’m working on this weird kind of design fiction project about what would be the employee manual of the future. And so what would it mean like 5, 10, 20 years from now when you join an organization that maybe has more robust AI agents and digital twins of you? What does it mean to have offices that are worth going into? What does it mean to have digital async properties that are more integrated with the way we do our work? Just replaceability in general of individuals.

Because everything that happens today when it comes to job requirements, interview processes, performance ladders, performance reviews, all that stuff is about making you as cookie-cutter as possible so you can be replaced eventually by someone else or something else. But there’s that balance against now, like I as an individual have an embodied experience that I think is very particular and my practice is very individualized. And so I think that is going to be constantly something that at least I just keep thinking about and wondering about when it comes to product management, too. So I’m not sure.

 

Vit Lyoshin (58:58.2)

Yeah, that’s a very interesting point. I haven’t thought about that. Everybody’s talking about replacing jobs with AI and essentially building some sort of model that can replace every single, let’s call it a sales representative. But every sales representative does it in a different way. So do you need to have a million of these models now or just one will do it? That’s a very interesting question. I never thought about that.

 

Chris Butler (59:19.086)

Yeah, that’s right.

This is the difference between building something from scratch that is for one use versus this idea of personalization or customization. And then also just when it comes to contextual awareness, those are all slightly different things. And we want to build products that are actually adapted to that person’s use. But it doesn’t mean that every interface is different for everybody.

There’s still things like when I was working at a company called IP Software, working on something, it was like, Amelia was like this kind of proto chatbot and IT kind of conversational agent. Like a lot of people would say like, well, so here’s like a great skill. It can give you the account balance. Like I know how to use my banking app. You know what I mean? Like on my phone, I can go and check my bank account balance. That’s not why I’m going to go to a conversational agent. I’m going to go to a conversational agent because I can’t figure out how to do something that I don’t usually do with this thing.

And then actually, I don’t even want to talk to one of these chatbots. If it’s a highly emotional, like I just got scammed by someone, I want to maybe report it through an app or talk to a chatbot to get it started. But I really need someone’s compassion and empathy towards me at this moment, because it’s like a highly human thing that I’m going through right now. So I kept on trying to make those differentiations.

I think that’s going to continue to be true, is that like, it’s not always about doing these simple-stupid cases with the AI. It’s about when is this appropriate when I can’t figure out what’s going on and I need to do something, right? Versus the times I need like human care and that human-to-human connection.

Now, it’s gonna get harder and harder to tell that and that’s why phishing ends up being a bigger problem over time. But like, that’s more in the way that like, I don’t think we want to do things, right? Like I think we want to have automation when it’s helpful and appropriate, but I don’t want it when it’s actually taking advantage of me. And it’s like some type of uneven power dynamic between me and the corporation.

I was just reading through TechDirt, which has this interesting article about robots.txt, which is the thing in the tech world since search engines started being around where people didn’t want or did want to have actually their sites indexed in some way. And it becomes a really interesting question from a technological standpoint is that right now agents are basically embedded inside of large organizations or corporations. But what does it mean for me to have a personal agent?

And so this robots.txt ends up being an interesting question. If it’s my agent doing this, but it’s automated, is that acceptable or not? And there’s going to be a lot of interesting Supreme Court cases, especially around scraping of websites that are already happening right now, but on an individualized basis. I think there’s something interesting about the power dynamic between large corporations versus open source projects that I control in some way longer term.

So anyways, I know we’re starting to get on our time, but I think there’s some really interesting questions longer-term about the way that technology is used by individuals rather than corporations.

 

Vit Lyoshin (01:02:20.535)

Yeah, I just had another episode recently with somebody who’s an expert in AI and we were talking about deepfakes and how people in the banking industry, for example, can fake the voice and steal money. And he was given an interesting, it’s kind of a bad example, or actually some company, I think somewhere in Asia, they created the fake Zoom meeting and they talked the CEO into wiring $25 million to them. It was completely deepfake. And he just lost all his money. And it’s amazing how crazy this technology is and how dangerous it is. So yeah, we have to be careful.

 

Chris Butler (01:03:01.23)

Yeah, and I think like, you know, who was it? It was actually, I think it was the CEO of Nvidia, or no, sorry, it was Zoom that was talking about how longer-term we’ll just send our agents to meetings and stuff like that. And I’ve been starting to write like a sci-fi short story about the fact that like, well, what happens if you’re the only human in that meeting? And so like, why even have that meeting? Why not just calculate the outcome of the meeting, right?

I think there’s some interesting things about maybe we’re just doing certain aspects of our work in a performative way and that we should really be focusing on what are the values that we end up doing in this. So again, there’s lots of very interesting questions to answer about this stuff. But anyways, I think we will always need people. People are the actual decision-makers because we have agency and we have an actual lived experience. And I think those things are most important.

That’s why I think product management tends to index on those things higher, I think, than more mechanized processes. That’s why we say it depends all the time, we’re trying to be as contextual as possible to the particular people that we’re trying to be obsessed about. And so that to me is really the future of product management, is really continuing to do this and continuing to do it in a human way, I think. But with the aids of all of these things, how do we actually use the entire body of knowledge that we’re collecting through customer research, customer support, to constantly remind us and actually as a reference for how we do our work, I think we could do a better job of that. And I think these types of tools will help us do that.

 

Vit Lyoshin (01:04:41.016)

Yeah, I agree. We’re coming to the end here. So the final question is, or rather ask if you have any advice for something we haven’t talked about yet, or in general for product managers.

 

Chris Butler (01:04:57.838)

Yeah, I mean, I would just say like, try to embrace uncertainty more, right? Like try to actually see the fact that we live in highly volatile environments today, especially if you’re doing anything with AI or machine learning. The environment is changing so fast that, I think, just getting better at how we deal with uncertainty and how we understand complex systems, how we constantly work through emergent behavior that’s happening that we can’t predict, right?

That is a skill set I would recommend that everybody just gets better at. And maybe it’s also kind of a mental comfort type of thing that we need to get better at. So I’d say I’d recommend that. And then, you know, I mean, if people want to get in touch, I’m always interested in getting connected via LinkedIn. Then I’d also recommend subscribing to the Uncertainty Project. And then if you’re at Agile Alliance this year, please come to my talk. I’d love to hear your thoughts about meetings. And then, yeah, I think the meeting game agenda is going to be kind of like a fun thing for people to try out.

Those are some things that I’ll just leave people with. And thank you again for having me here. I have really great questions and yeah, just excited to hear what people think.

 

Vit Lyoshin (01:06:06.008)

Yeah, sure. Thank you very much for your time. That was great conversation, lots of insights. I appreciate your time. All right, we’ll talk sometime soon. Thank you very much. Bye bye.

 

Chris Butler (01:06:11.566)

Thank you. All right, sounds good, bye.