How To Drive Better Product Decision-Making By Cutting Through The Noise

Read The Transcript:

 

We’re trying out transcribing our podcasts using a software program. Please forgive any typos as the bot isn’t correct 100% of the time.

 

Hannah Clark: Decision making—did you ever think it would be this complicated? When a team is constantly grappling with competing priorities, internal politics, and varying areas of expertise, there are virtually no easy decisions. But the show must go on, so how do we navigate the decision making process, avoid gridlock, and still land on the best way forward?

Today I'm joined by Chris Butler, Lead Product Manager at Google, working in the Core Machine Learning Group. Chris has spoken extensively about the complexities of decision-making in the PM role, and he started moonlighting as a product fortune teller. Just kidding—kind you'll see. Today, Chris offers us a high-level take on some of the factors that define influence and impede decision-making, how to understand and manage the tensions that exist within cross-functional teams, and some unorthodox tools to push past both recognized and invisible roadblocks. Let's jump in.

All right, listeners, thank you for joining us. I'm here with Chris Butler, Lead Product Manager at Google as part of the Core Machine Learning Group. Chris, thank you so much for joining us today.

Chris Butler: Yeah, thanks for having me. I'm excited to talk about everything we're gonna talk about.

Hannah Clark: So, we'll just get into some preamble here. So, can you give us a little bit of background about your role, how you got into product management, and how you ended up at Google?

Chris Butler: Sure. So my role within the team is I report into the vice president of product for the Core Machine Learning Group. And so he runs a team of product managers, designers, researchers, and customer engagement people. And my role is to really do three things. So one is to help corral or understand the strategy for the entire group. I do what I'll refer to as like product managing the product manager experience or PMing PM experience, and we can talk about what that means if you want.

And then just in general special projects. So my role's a unique one. I think people would refer to some of this as like product operations, external to Google. Product ops means something slightly different internal to Google. And then I've also recently found out that there's not really any lead PMs inside of Google as a term, so that's been pretty interesting.

I guess like my main thing is really just to try to help the product team be as effective as possible. And that's why strategy is so important is that being able to help people really make hard decisions easier, I think is what strategy is meant to do. And my role helping out the VP is to help him also be as effective as possible as a leader. And so that's the role that I do today.

Hannah Clark: Actually, I would like to hear a little bit more about product managing the product managers. If you can give us a little bit more on that.

Chris Butler: So, inside the world of product operations, which I think is fairly new today, it's really about this idea that there's a lot of, I've referred to it as glue work. This idea of really all the different things we do to work really well together. Not only PM to PM, but also PM to other cross-functional teams. We need to actually take care in those interactions, the way that we end up building alignment, how we help other teams understand uncertainty.

And so I think a lot of the time this is supposed to be what managers do, right? They're supposed to actually think about this type of glue work, but they end up being so busy not only managing their teams, but also doing the work itself. That it usually falls by the wayside and it's not something that's actually incentivized for them to do until there's actually a crisis.

And so this like PMing the PM experience is a very unique role in the sense that I'm incentivized around, really helping my main customer, which is the product manager. And my product is the experience for every product manager and the actual community of practice that's around product management.

And so, a lot of the time I usually break it down into really three different parts, but it's the people, process and tools. I think a lot about the people and process side. Usually people want product operations, people to just figure out the tools, but more often than not, it's not actually the problem.

Right? Like the issue is not that we don't have the right tool. The issue is usually the fact that we haven't figured out the way people should work together, and so that's where product operation really comes in. I would also say that the times that I've seen product operations not work well is usually when people mistake the end customer as their customer inside of the product operations role.

Because I, I think that then gets us to the realm that product operations people end up doing the bullshit work that product managers don't wanna do. And so I think that's really important from the aspect of product operations is really just thinking about what makes product managers lives easier.

I do think that lots of people do product operations that are not product managers, right? Or don't come from that background. I do think it helps though, and I think a lot of the skills that product managers bring to bear in helping customers solve problems is still very valuable for the way that say, product operations people do their job.

Hannah Clark: Yeah. So an aspect of that job that I, I wanted to talk to you a little bit more about is something that you mentioned in a previous talk with Enrich. So you introduced this analogy of the "product spine" more in terms of decision-making and how product managers can conduct their decision-making and align with a broader strategy.

So I'm hoping that you can give us sort of a cliffs notes version of that analogy and some of the takeaways that you've had just talking to other PMs about that idea.

Chris Butler: Yeah, absolutely. The product spine is meant to be an analogy that helps people understand just the way that, say different artifacts and different types of meetings that people will have with as product managers actually connect together.

And so the trifecta that I tend to think about a lot is this idea of a very high level strategy, a roadmap, and then the tasks that are done day to day. And the big problem is that when we start to misunderstand how these things actually align with each other, we end up making, I think, poor decisions first of all.

And second of all, we end up creating incorrect understanding of the way that we should do our work. And so for example, when I think about the spine, maybe the vertical is this idea of like very low abstraction level things to very high abstraction things. And what I mean by abstraction is how much ambiguity is there, maybe how rough cut they are when it comes to, at the very high level, like a strategy is essentially do all of this type of thing and not this type of thing.

And it's meant to make that very clear so that people know where to work within. But it allows for a lot of variance, right? It allows for people to figure out things as they go, and then if something no longer makes sense, there should be a way for feedback to move up the abstraction level to say that maybe this isn't like a valid or valuable way to actually align our work anymore.

And then the horizontal inside of the spine is really the center is now, and then maybe to one side there's like the far future and see other side the far past. And I think we end up mistaking things like a very well articulated, but explicit plan is very far future looking. But it ends up just being fiction, right?

It's something that we write down. We want it to be true, but it's not really true, right? The things that really matter the most are how we make decisions today because we can never make a decision in the future. We can only ever decide today. And so I think the fact that we're connecting from very high level abstraction to low level abstraction is very valuable.

That connective tissue between the strategy and the tasks is incredibly important. But then we're also saying that we're not gonna look too far to the past. We're not gonna look too far to the future, and that we're gonna try to keep things within this realm of what, what can we do today or sometime in the near future?

I mean, there's definitely value for things like vision, right? Which would be a very high abstraction, but very future looking type of thing, as a way to, either inspire people to do marketing, to do hiring, and to get people to join our teams. But I found overall that if we have a high level strategy and a lot of tasks, but we have a plan that is incredibly specific out to the future, right?

We end up basically creating a system by which we will never do the right thing, because we will never be able to adopt to the fact that we're learning while we're building things. And this like very well-articulated, incredibly well-estimated plan that goes five years in the future is gonna be wrong in some way.

And then that ends up decreasing our credibility with people that are working at a higher abstraction level in some way. And so that's really what the spine is meant to do is build this connected tissue around today and in some way provide for the ability for like high to low level abstraction people to all speak something that is connected to each other.

Hannah Clark: Yeah, I think that's really well connected to another concept that you introduced about the product manager serving the role of the facilitator of decision making and playing that kind of crucial role. I wanted to ask you a little bit about some of the best practices that you've kind of either use yourself or heard from others in the field about facilitating decision making across stakeholders?

Chris Butler: Yeah, and I think this gets back to there's really three meta tasks that I think all product managers do. One is this concept of just like wrangling or managing uncertainty of the world. Like me being clear that we don't know everything were wrong in some way, and that we need to keep on adjusting the way we're moving forward.

The second thing is that idea of decision facilitation, and the third one is really just building alignment. And a lot of the time that's through communication. The facilitating decision making is really interesting because I think we overly mistake that product managers are making all the decisions when the reality is like the team as a whole should be making these decisions. And we're gonna be working with very, highly specific stakeholders or highly technical people or people that are just experts in their domain where we want to get the information from them, right?

We want them to be included in this decision making process, but it's really the product manager that's maybe like forcing the decision to take place either now or deferring it into the future. And so I did a talk recently at a product op summit in New York that was about really deciding how to decide.

And what that means is that it's not quite as simple as just gathering a bunch of options, weighing the pros and cons, and then deciding as a group. It actually should be more like we discover that we need to make a decision, and maybe where we need to make a decision that actually impacts other people.

Because every single time that I'm say saying something right now, I'm using intuition to decide what is the next word. And that's like a decision in some way. It's just like really small decisions that maybe have less of an impact on the entire team. But the moment that we realized that a decision will impact the team, that means we should do something special to make sure that we're not like missing information and we're making a decision the right way.

And that leads us into kind of, I think, a separation between two things that are very usually jammed together or muddied in some way. And that is this like discourse around the decision, getting everybody's feedback, hearing all the options, doing all that type of thing. Versus the idea of we're actually, who is the right decision maker for this thing after getting all the information?

And more often than not that decision making at least within Google, it's very consensus driven. And that means that like everybody has to agree when the reality is if you believe the fact that experts are good at what they do and they have lots of knowledge, that means that you should not just assume that everybody has to agree. Because when it comes to something like prioritization or something to do with which customer we should prioritize or something like that should be the product manager is deciding that.

But when we talk about like architecture or what's maintainable as far as code or that type of thing, that should be the engineer that makes the decision. And same thing with like experience, right? What is the right experience that we should be building right now? Or what are the right questions to actually ask someone?

Those are designers and researchers. And so I think this type of like at least acknowledgement that we should not be just making decisions where everybody's opinion is the same. It's not. And then I think the parts that we end up forgetting about this is generally like communication of these decisions.

And then finally, how do we learn from our decision making process? Because we can make a very well-defined decision. We could have used the best information we had available to us. We could have decided how to decide as good as possible as we could have. But we still, because of just the way the world works, things don't turn out the way we want.

And so from that perspective, we wanna then be able to go back and look and see, based on this decision making process, was there some information that we could have gleaned from the situation but we didn't, and I think what's really tough about this is like when I first start talking about what does it mean to be a product manager, I usually go back to the fact that like product managers want to ask "why". They wanna understand why something is happening, or why does this customer feel this way, or why is this the right solution?

And so I usually teach five why's as a like a, just a way to get at this thing. But the reality is it's probably more like 27 why's than just five why's. And beyond that, it's actually when we start to think about the way that organizations work together, it's rarely easy once we get to the actual root cause that someone could have made a different decision at that point.

And what I mean by that is that usually it's the way that systems are set up that are the issue rather than individuals making bad decisions, right? They're definitely a case of that, but I think we should always be looking at what are the incentives inside the system? What are the norms? Who is allowed to speak? Who is not? Who is ignored, right?

Like those are all things that are incredibly important to actually good decision making. And so I think we can always do the analysis of what the root cause is, but we may not be able to actually change the way that future decisions are made in this particular case without changing the way that the system works itself.

And so that's part of my job is working with my VP and all of the other directors of product is, sometimes it's my job to drag my feet and at implementing new process because we don't know if it's gonna actually be beneficial or not. Or it's my job to, try out smaller experiments because when we talk about complex systems, it's never as simple as just like one huge change will make all the world difference.

It's more what are a bunch of small changes that we can experiment with until we find out the ones that will work and then start to spread them through the team. And so that's, I think like that feedback mechanism of decision making is really important. But I think people forget about it a lot.

Hannah Clark: I'd like to hear a little bit more about that in term, maybe in the context of an anecdote about some of those systems that you've seen that needed to be dismantled or that required some of that process work?

Chris Butler: Totally. So there's a talk I gave that's called Making Learning Look More Like Work and this was at like Product World and Agile Alliance.

It was called something else. But the issue there is that when I was working at Cognizant, I was the head of product operations for a team of about a 100 to 120 product managers and business analysts. And we had a process that was called, basically it was a council meeting and this council meeting was meant to be for all of these consultants that were out at different projects or products, how could we understand what was going on, right?

So there were a couple different goals with this meeting. It was to understand what's going on with the project. It was to provide help and coaching if that particular product manager needed help by more senior product managers. And it was finally to get ahead of escalations if there was a problem.

And maybe to understand like if there was an opportunity for expansion of the project, basically, which was more of a sales BD type of activity. Now the problem was, is that the way that this process was being handled is that there was like a slide deck template that was a very long slide deck template, and it took an hour or two for someone to fill in and they had to do it every month.

And they would then just review the slides in the meeting. And by the time that the slides were done, there was no time for conversation. And I tend to want to talk to people that are either joining or leaving the team. And I do a lot of other discussions too, but I had started talking to a couple of people that were leaving. And one person had mentioned that this was like their least favorite thing and didn't outright say there was a reason why they were quitting or changing jobs, but it seemed like it was like a contributing factor at the very least.

And so what we did is we looked at the different goals there and we said, well, so status, there should just be an async way to do this. If you want the tempo of what's going on with this project, let's just create like a async status, probably a form or something like that, right? Something very simple that's more what's going well, what's not going well?

What do I need help with, right? And then we can get on some cadence. The second thing around coaching contextualization of help is really highly dependent of the problems that people are having inside that project. And so that's what we ended up focusing on the other one, which was like, escalations about to happen or we see a sales opportunity.

Those were things that should just happen ad hoc. Like the moment that you realized this, you should either talk to your salesperson or you should talk to your manager. Like you should get ahead of these things, right? Is really the thing. So we focused on that and what that meant was that we took a structure within this meeting that was five minutes upfront was really recapping what we had talked about last time, what happened.

And then a couple minute kind of discussion of what is a problem that's happening right now, or what is a challenge. And there were plenty of times where people would come to me and I just don't have any challenges right now. And it's well, so what are you doing to improve this project then, right?

If you're not improving the project, then that's also a problem, right? And so we would then talk about like where they maybe see opportunities or problems, then it would be up to the more senior leaders that were in the room to ask clarifying questions at first. We would not give advice. We were just like trying to contextualize.

And sometimes actually just getting those questions from really senior leaders or people that have been inside of these contexts more than the person will help unlock oh, well I had not thought about it this way or this framing. And then finally we'd give advice. And so it'd be like techniques, processes, even in the idea of maybe we should escalate something like this, right?

Or we should change the next project, or something like that. So that basically we turned around from a meeting that, well, a lot of people really hated to a meeting that people actually found incredibly valuable. So I think that's an example of where, we tried to do too many things with one process.

It was a process that was created by a senior leader where they had seen that work before, but it just wasn't working in the implementation. And so, breaking it apart a bit, looking at the different goals, deciding which goals were appropriate for a synchronous meeting versus asynchronous process.

Those are all the things that went into that kind of decision and discussion. And so I think that's a really good example of where more often than not, I think there are processes that already exist that we should be, I call it creative destruction, but we should be like blowing up these like old processes that are in place where if you ask the question and you're like, Why does this process exist?

And people are like, I don't know, we've just always done it. That's probably a prime thing to get rid of. And it doesn't mean that you get rid of goals of around that thing. It just means you have to rethink it a little bit. And I mean, the other thing I would say too is that I don't think teams do enough retrospectives.

It's been a real kind of struggle to get people inside of Google to do them because, we have lots of very smart people that are very certain about how they do their work. But we definitely need more people to be reflective on what is going on when it comes to the work. And so that to me is always an amazing tool is just to start doing retrospectives on some regular basis.

Now there's another part that if we keep think the same thing keeps on coming up over and over again, there may be a need for then systemic change to allow for that change to take place. But there's lots of other things you can do at retrospectives at higher like levels in the team cross-functionally.

This idea of like governance meetings, which I've started to steal from like Holacracy, but adapt for like hierarchical organizations. There's all these things you can start to do to allow for these like different containers of different types of, of like discussions. And from there then people start to actually wanna change the way they do things on their own, right?

Once you can start to tell them how to facilitate these things, they just run with it. And because they don't want their team to suck, right? Like they want to actually enjoy their work and they want to be able to succeed. And so I do believe that about everybody that's inside of these teams.

We just need to give them like the tools to do that sometimes, or at least the space. Like a lot of people feel that retrospectives are not worthwhile because they're like, we don't have any problems as a team. We don't have any issues that we need to process or anything like that.

And I'm a hundred percent sure that you're wrong about that. But I try to say it nicer whenever I talk to people. But I think that's something that is really important is like we just, we want to make things better. And so we need to have the space to allow for the time to do that. And I don't think a lot of the time people get that space.

Hannah Clark: I'm curious how you have been adapting those governance meetings, adapting that concept to your team and and making it more applicable?

Chris Butler: Yeah, I mean the original Holacracy kind of governance stuff is really about processing tensions, which end up coming up repeatedly through usually retrospective meetings, things like that.

But I would also argue, so basically like the way that I've started to do this, and again, it's not a solved thing at all. Like getting people to even want to do retrospectives is still a challenge. So the teams that have experimented with governance, for example, they have found that like they are likely to jump to the point that they want to build a process that is very longstanding.

The problem is that if you don't have regular governance meetings or you only do that whenever there's a really huge problem, for example, you end up feeling like you have to build process that will exist for forever. And so I think the thing about having some type of regular cadence for and I think like it's somewhere for like teams that are working together often, it's somewhere in the range of like once a month or every three months.

And the problem is that there's like a lot of pent upness with this stuff. So like when you do your first governance meeting, it probably lasts like hours because everybody has like something that they want to process as attention and it will take you 30 minutes, 45 minutes to process one tension, right?

And then from there, once you start to do this on a more regular basis, there's gonna be less of them. And so there'll be less like pent up like watershed moment type, or like trying to take care of everything at once.

Hannah Clark: It's like marriage therapy almost.

Chris Butler: Yeah. Everything comes out in like the first parts of like counseling. And so that's true for anything. So that's how I would say it's like it is super helpful and valuable to do these types of cadences because then people have a place they can expect to do it, rather than it having to be during a crisis. And so then from there, I think like the terminology of like tension is not really understood.

Because I also think as an aside, I think part of our job as product, like as managers, is to create teams that have appropriate tensions between them. And I don't mean this as like a tension, like there's an unmet demand or need, but it's just like idea that originally, we would build teams, at least in product management, where it'd be like channel based.

So you'd have the web team and you'd have the mobile team and you'd have whatever else, like maybe internal tools. What we start to realize though is that it's actually not that helpful to go by channel, right? Because people use both mobile and web, for example, or they talk with a customer service rep.

And so the question that becomes like, what are all the tools that we need to have, or all the software or systems we need in place for this like persona or job to be done or something like that. And so what you're looking at is like, where's their space? Where's their align, innate alignment, which is this person is like the innate alignment point versus where is their space retention with other things that should be in some way like away from that?

And this is why like engineering and design and product management, they exist within a space of tension because they all care about different things. They need to optimize or be concerned with different things. And all of those things together, maybe going back to decision making, the reason why the discourse or the argumentative part of this is so important is that as individuals, we suffer from lots of cognitive biases. Like hundreds of cognitive biases, which again are, because we've evolved to deal with like limited information, limited time, limited resources.

But we end up building teams of people because we don't suffer from the same cognitive biases together. And so that's why we want to have more tensions that are helpful within our teams. And so maybe that's, maybe going full loop, governance allows us to understand where there should be tensions, where there should be certain type of decision making. And then finally allowing for the place for these types of tensions to be discussed. And are they helpful or not, is the thing that we need to have.

Hannah Clark: Yeah. This seems to relate to us another talk that you did on randomness as a tool for decision making and kinda eliminating some of those, the cognitive biases or taking some of that outta the equation.

If you wouldn't mind, the talk is fantastic. It's available on YouTube. I'll, maybe we can throw a link into that. But if you could go into a little bit of how you've used randomness as a tool for yourself.

Chris Butler: Yeah. I mean, I think the biggest thing is that randomness doesn't care about your preconceived notions and all of bias is really just like you're stuck in this mode for some reason that is making me decide in a certain way.

And so, and that's the most insidious bias is like the blind spot bias is the one that you just don't even know is there. And so that's why we get into teams. That's why we like talk to our customers. That's why we do all these things is because it like helps us get out of our own head, in some way.

But the last kind of like place is this idea of just like pure randomness. And there's a couple other tools that I use here as well, but like randomness is a really interesting one. So I have a deck of cards called oblique strategies. And so those are very highly conceptual kind of provocations that if interpreted, will help you reframe in some way.

But I also think it gets at what are your assumptions? So it gets at not only this idea of what are the cognitive biases at play potentially, but also what are the assumptions you have that may not be helpful assumptions anymore. And I think another tool I use for that is just like asking what is the opposite of something a lot of the time?

And so that could mean like I've called it the Bazaro strategy. Like whenever I talk to people about their strategy, I'll say, so what is the strategy you use to make these decisions with your team? And they'll name it. They'll talk about what are some of the trade offs maybe. And then I'll ask, what is the opposite of your strategy or bazaro strategy?

What is a strategy that would be completely valid for another company with a different set of incentives, but with the same customers and solving the same problems, but they're highlighting a different aspect of this, what would that be? And if they can't think of one that says to me that they're not making actually hard choices.

It means what they're doing is they're deciding between this like very good thing and very bad thing, which is not a strategy. So even and this is something I did inside of a talk that is called Adversarial Product Management, is asking what is like a bad idea, right? Is a really interesting thing because during that talk, and there's like a lot of improv I think that goes into these talks about like bad ideas and randomness.

But I asked what would be like a bad idea for a meetup? And some of the ideas were like, maybe you don't market it at all. But the assumption we're making there is that we want to get as many people as possible rather than just the right people, right? Or that we're, we want, we don't want it to be exclusive.

Or the idea of being nice to people in the meetup, right? If we're there to actually struggle through some real issues, we may not be like mean, but we may not agree with everything that everybody's saying, right? We may actually give people certain roles to disagree specifically about things, to be able to move the conversation forward.

And so these are all tools that I think are just like to get at assumptions, to get at biases, and then most recently, I also, we had a summit for all of our product team last week. And so we did something called an Unconference. And an Unconference, if you've never done that, it's just like an open-ended, like people just basically suggest topics at the beginning of the day.

And we did a bunch of sessions, really great, like really great discussions about things that we would not have talked about at like in the earlier days of the summit where it's very much like top down talking about stuff and we're doing a bunch of other things too. That's part of my job too, is like help plan these summits.

So I think about them a lot. But one of the things I did was product tarot readings. And so in a product tarot reading, yeah, I have my beaten up deck right here of the writer weight. What I do is I do a cross pattern for the product. And so I have people describe what is the problem they're dealing with their product, and then we interpret the symbols to really just mean like, How could we reframe our understanding of this problem about this product?

And so I'm not very much into mysticism personally, but I do believe that a lot of these tools have been created to help people reframe the problems they have. So if you look at like a horoscope, right? Or you look at like the itching, or you look at even just the idea of flipping a coin, it's about using your intuition with some ambiguity and maybe some confusion.

Some confusion about what is being said to reinterpret and rethink things. And I think what's interesting too is that you end up actually maybe understanding better what you actually want to do, right? A technique I've used a lot is if people are suffering from analysis paralysis, I'll flip a coin and I will not tell them what the coin flip came out to be. But I'll ask them like, based on what you know right now, How do you feel about this?

And usually people know which side they wanna be on. And same thing with like even if you roll a dice, right? If you do the right type of decision making capability and come up with multiple options, even when you roll a dice and you don't show them what the result is, people are like, I will. I think this is actually the best decision.

And I think a lot of the time people are backing into a decision, like all these things where we're like creating huge documents about why we should do something. I think a lot of the time are just based on this fact that we have an intuition and that we need to find evidence to support it, otherwise we look ridiculous.

And so I think that's a really hard aspect of decision making as well, is there's something very valuable about the emotional intuitive side of this. And I think we can't get away from that if we wanna make good decisions.

Hannah Clark: And I think there's really something to be said about using these unconventional tools to get really out of that, the nuts and bolts and processes, and really introduce some chaos.

Which actually maybe we can end on that. Kind of a fun note, I did wanna ask you about something you've put in a number of your bios, which is describing yourself as a chaotic good product manager. I just, I love the D&D reference. I have to know what's the story behind that.

Chris Butler: It is like a little bit of an Easter egg for other people that play role point games, and so I still like GM and a couple different games.

Just because I see it as the idea of shared storytelling is actually a really valuable facilitation skill. So I find it very fun and I also just love doing that. But the other side of it is, I guess, I think all the really smart people that I work with that seem to be very certain about the work that they do, they're very buttoned up in the way that they think about things.

And I think the chaos part is that, especially if you use something like Cynefin, where it talks about like different domains of decision making, or actually just problems in general. There's like the, it's clear, complicated, complex, chaotic, and then disorder just in the middle, and it's like this kind of assemblage of domains.

I tend to do a lot of work in the complicated to complex domain, so I'm in the complex domain looking at how people interact with each other. I'm looking for patterns, and then whenever I need to do something like create a process, we push that into the complicated domain. And we need a sense whenever, if something's already in the complicated domain, that it may not be a valuable process.

We need to push it back into complex to be able to understand. But there's something really valuable about dipping into the chaotic realm, which is that sometimes when we need to get more variance of ideas, we need to do things like private ideation. We need to use these tools that provide for more randomness, but they allow us to actually expand what we're considering in some way.

And so I think maybe that's what I really mean by chaotic good, is that, not only should we be expanding what we're considering, we should be questioning what we already consider. And then we should really try to, I guess, do it in a way that tries to help not only the people that are our customers, but also us as a team and then the wider world.

So that's, I guess, the formulation of chaotic good, besides the Dungeons and Dragons reference.

Hannah Clark: I love that. It's just peaks a curiosity. It's fantastic. So, so Chris, thank you so much for joining us. If listeners want to keep up with you or follow your work, where should they find you?

Chris Butler: Yeah, so on Twitter, I'm @chrizbot. And then if you want to connect on LinkedIn, I'm always excited to hear that if there's anything in this kind of discussion that we just had that you try out, I would love to hear how it goes. And I, because I think like the collection of people's problems to a certain extent are really interesting to me because I think it helps expand my ability to do my job better too.

So I'd love to hear from people that, that are struggling with these things and and really if any of this helps out.

Hannah Clark: Awesome. Well, it's certainly been something for me to think about. I really appreciate your time today. Thank you so much.

Chris Butler: Yeah, thank you so much and great speaking with you.

Hannah Clark: Thanks for listening in. For more great insights, how-to guides and tool reviews, subscribe to our newsletter at theproductmanager.com/subscribe. You can hear more conversations like this by subscribing to The CPO Club wherever you get your podcasts.