decision, people, product, alignment, strategy, product managers, decision making, organization, important, team, abstraction, spine, aligned, problems, talk, retros, roadmap, question, engineer, tasks

Intro (the incomparable Sandra Segrest) 00:03

Welcome to Product Voices, a podcast where we share valuable insights and useful resources. To help us all be great in product management. Visit the show's website to access the resources discussed on the show, find more information on our fabulous guests or to submit your product management question to be answered in our special q&a episodes. That's all at product voices.com. And be sure to subscribe to the podcast on your favorite platform. Now, here's our host, JJ Rorie, CEO of Great Product Management.

JJ 00:36

Hello, and welcome to Product Voices. So really excited about this episode, I've known my guests for several years, I always loved following him, learning from him seeing what he's doing next in this product management world. Chris Butler is here with me today. He's a real product master. He's currently a lead product manager at Google in the past, he's been the global leader of product offset cognizant, he's been a product leader at Facebook and Kayak and Waze and others. So I am so excited to talk with Chris and have him here today. So Chris Butler, thank you so much for joining me.

Chris 01:12

Thanks. Great being here. Again, really great to talk to you.

JJ 01:15

Yeah, I'm so excited about this. Okay. So you talk about this product, spine, and I'm so excited to learn more about this. I just love the way you think about things and the way you you kind of communicate and analyze different things. So I'm really anxious to hear more about this. Okay, so tell me what this means. The product is fine. And and product managers aligning to it. Tell me Give me a little bit of foundation there. What does that mean? Yeah, absolutely.

Chris 01:45

I think the what I've started to notice, my role at Google in the core machine learning group is one of them is to really help corral or steward the strategy that we have. And whenever we think about strategy, you know, I think about strategy is really a kind of a key decision making model for the organization. And just as I've, I've worked worked through a lot of different teams trying to not only create a great strategy, but you know, the things that end up being related to that are the decision making at various levels inside the organization, which could be, you know, say, resourcing at a portfolio level, it could be the actual roadmap for a particular product, or even the idea of like a task list. And so, just over maybe the last couple of months, I've really started to see the product spine as being this alignment. And using kind of the terminology of the spine is meant to be a biological analogy, that, you know, we want to try to keep a couple things kind of in alignment. And that that could be, you know, for example, the strategy, the roadmap and say, your task list. And I think about it, you know, if we, if we have a graphic in front of us, you know, I've been thinking a lot about it, that the vertical is really this like levels of abstraction, right? So as you're higher up in the level of abstraction, say the strategy, it ends up being very broad strokes about what we will do and what we won't do, ideally, right. It's what are some of the trade offs that we're going to make, you know, most often, and so I've used things like even overstatements to really help, like, drill in on that, which if you're not familiar with an even open statement, it's like this even over that. And so having a couple of these different, like, you know, we will choose this thing over that thing. And probably the the even overstatements that people have come across are most like in most in the past had been like the Agile Manifesto, for example, would talk about, you know, people over technology, or tools, right. And so you start getting kind of this, like interrelated set of way, we will make decisions at a strategic level, which is very high level. But when you start to get lower and lower, and levels of abstraction, you get down to like, we're gonna actually work on this one particular thing, which is a task, that's that some engineer is going to actually complete. And so that's, that's kind of like the vertical pneus of the spine. Now, when I started thinking about the idea of alignment within that spine, I start to think about the horizontal as being time where, you know, we go from the far past to the far future. But this gets back at my argument, I, you know, I made this in a medium article a couple of years ago about how really all strategic decision making models are about how do we do things, and today, right, and those common misalignment that I've seen within this product spine is really, we'll have some type of strategy, it may not be a great one, it may not be well articulated, but at least there's something there that's like, kind of here's how we're going to try to make decisions within this organization. But then we think about this plan that's like very far in the future. And it ends up being that we'll have like a five year roadmap that talks about like down to a month level what we're going to be releasing, and then we come back to this like point where there's a task list that is really about, like, what are we working on right now. And so that misalignment I think, comes down to the fact that there's like a temporality kind of mismatch between these different objects. And so, you know, I think this, this maybe has to get us into this, this kind of discussion about What does it mean, actually to have, say, a roadmap that is situated in the now? Right? I think that's like a really important question. But you know, I think this is what I think of when I think of the spine is I think about, like, how do we use this as an analogy to constantly talk about, and all of these different levels of abstraction, the thing that is most important for us to be working on today at all levels of abstraction. And so I would argue, you know, things like prioritization methodologies, or, you know, and I've, I've bristled at this fact that, you know, there's millions of these these articles about prioritization, they usually just referenced like rice Kondo, and Moscow. And the reality is, is like, none of those were actually in some way linked to the actual prioritization methodology that your organization should use to link their strategy, roadmap and task list, right. And so anyways, I'll, I'll stop there for a second. But that's, that's kind of the concept behind the product spine, whenever I've talked to people about it, they found it to be helpful as an analogy, because once you start getting in too much misalignment, there's a lot of like, weird tensions that start being created inside of, you know, the organization. And, I mean, I've had my share of back problems, and like, a quarter of an inch of scoliosis, that I just recently found out about it like a year or two ago, that like, you know, it causes like real problems inside my body to not always have like a well aligned spine. And so, you know, so this has been an analogy that maybe is like close to home, as well. But it's something that I think helps at least product leaders start to think about, like if these things are not attaching to each other. And that chaining goes back to even Richard rumbled with his like, good strategy, bad strategy, where if you don't have like a challenge guiding policy and your day to day actions, that are cohesive in some way, you get out of alignment as a strategy and a strategic decision making organization.

JJ 06:46

Yeah, I love the analogy, I think it's spot on. And I'm sorry, that, that it's so personal to you. But yeah, I It completely makes sense. And, and again, sometimes we need something, you know, we need an analogy, we need something that to simplify what we could already know if you, you know what I mean? Right. And, you know, we we all kind of know that what we do on a day to day basis should align with our long longer term strategy, but in the practice, it gets out of alignment. So, you know, anything we can do to kind of keep the, the keep the clarity around what we're supposed to do. And that's right, it's great. So, so tell me how, how have you, you know, lead your teams and and, you know, kind of figured out ways that help organizations and teams keep that alignment between, you know, strategy, roadmap, path, task lists, so from so forth?

Chris 07:44

Yeah, I mean, I think like presenting, you know, at, let's say, a team level, these different things together, I think helps kind of force more alignment. So what I mean by that is, you know, not necessarily like bringing out this like, huge strategy document that you've written in every single meeting, but at least, you know, being able to write like a quarter page or a couple sentence summary of kind of what is the key thing that we're actually working on today? Like, why are we working on this? I think, as related to the roadmap, and then here's the list of tasks that we're also focusing on for this, like next week or for this for right now. I think being that broken record is really the key aspect of of like a great product leader. And so, you know, I've, I've thought about this a bit from the standpoint of whenever I would work with people to try to create a strategy and say, we use something like, again, the the strategy kernel for mature remote as as a way to do this. At first, you know, the strategy document ends up being very long. It's like pages and pages of kind of the reasoning why we need to do something, and how we think about kind of our customers, their problems, the headwinds, the challenges that we're going to have as an organization. And something that I got from Eugene Wei, who used to be a strategist at Amazon, he wrote a really great and kind of, you know, to me foundational article around strategy, which is compressed to impress, or JPEG, your strategy. I've seen both both titles. So I think he's been doing some SEO on that. But like, it's really about this idea that at Amazon, they would have, you know, say a two year long kind of way of making decisions or a strategy with a very particular goal in mind. And they would have, you know, a couple hour presentation where they would talk about the strategy to everybody, there'd be a long document, but there would always be this kind of single phrase that would harken back to the strategy. And so one of them, I believe the one that he brings up this article is really this, this idea of, how do you, you know, so there were all these different systems that were not connected very well at Amazon and so like, get our house in order was this shortened version of that, right? And even people like Melinda Gates in the Bill and Melinda Gates Foundation, she chooses like a single word for that year. That really, I think helps you know, it. The problem with like shortening, of course, creates more ambiguity. But I think there's also something very interesting about there's, there's like an important way to align when it comes to being a broken record, because you're repeating these things over and over again. And you're, you're turning that into something that you can at the beginning of the meeting, you can just open it with your statement that is like a sentence or two long about, like, what are we actually going to do with regards to the strategy this year? Or the next couple years? Or, you know, in my opinion, strategy should be timeless? Ideally, right? It should be a decision making model that you use, as long as it's appropriate. And so I think that's how you ended up getting alignment. I mean, there's some interesting problems where, if you're too future looking, trying to bring things back into, like, what are the actual day to day actions we'll take today, right? This is where I think a lot of products like product people, I've, there have been product people that I've met, where they think an awful lot about like how this particular work is going to take two years to get to the point that we feel comfortable releasing it, or even being able to learn from right and that and that is very much like a huge anti pattern. So you're, you're weighing way too much in the future, and you're very much out of alignment. But I've also seen the opposite, right like that, if you're just a collection, and there's something that I think our team is kind of thinking an awful lot about right now is that, you know, the core ml team is a pretty new team. And so when we first started putting together our strategy documentation, it was very much like, here's what everything we're doing. And so how we thread all those things together becomes really difficult. And that's where I think, you know, a big thing I'm working on right now is how do we actually have the spine lean a little bit to the future, when it comes to the vision or the inspirational statements? And you know, maybe that's something like speculative fiction, or, you know, there's there's like those sizzle reels that people will have about, like, what does the future look like with our stuff, but I think there's, there's like possibilities for also just being kind of like to kind of rooted in the past or, or even just today without that future. And so this balance, I think, comes into not only, you know, not just being in the moment, but also having the right type of understanding of the past. Right. So whether that's say goal, kind of like OKR grading, right is something looking to the past to see how well we've actually understood what we are able to make change in our industry or with our customers like what do we have autonomy and agency over, versus this idea of actually having something that's inspirational, that drives people the future, because I think that that anti pattern I was just talking about where the plan goes out five years, the reason why a lot of product managers or product leaders do that is because they actually don't have a vision, right, they, the only thing they can do to actually inspire the engineers, is actually show them all of this great work that we have to do sometime in the future, when the reality is we want to show something that's a vision that's maybe more ambiguous and amorphous, because we need to not only adapt, right, but we don't know exactly how to get there yet. Because we don't want our past cells to tell our future selves what to do. And that's that's what you know, whenever I see like an icebox or a backlog that's like millions of items. That's your past self thinking, it knows more than your current self, to do something. So and so is there's like a lot of really interesting tensions that end up being created. But it's about balance, right? That you're not looking too far in the past. You're not looking too far in the future. But you're making sure that you're kind of like aligning all these items into the current, the current point in time where you can make decisions because you can't make decisions in the past, you can't make decisions in the future. You can only defer them today. You can only make them today. You can only think about them today, basically.

JJ 13:24

Yeah, that's that's spot on. And actually a really good way to kind of remember and, and ground yourself. Right. I mean, you can only make decisions right now. So I have a question and love your insights on this. So so, you know, obviously, there's so much of this alignment, or at least the environment to create alignment is is at the leadership level and so important for leaders to get this right. But you know, there are a lot of product managers out there individual contributors and really critical parts of the team but not not the ones that are necessarily setting the strategy or, or even again, setting the environment for the the alignment. What What advice do you have for product managers who are in an environment? Like, are there indicators that they should be looking for, to find a misalignment? Or are there some things that they can do themselves to, you know, ensure that not only themselves kind of understand the alignment, and they're aligned across the spine, but the organization itself? What can product managers do?

Chris 14:32

Yeah, I think there's two major things I would want to talk about. So one, you know, I think, I think alignment is one of those things that is it can be very costly, right? Because you have to actually put in time and you have to, you know, really, really work at alignment. And so I would argue that alignment is one of those things that you want in very certain cases. But otherwise, you want to kind of try to avoid getting alignment. So what I mean by that is that there's a reason why we ended up constructing teams that are, you know, with like leaders or directors. And originally, you know, maybe like back in the 2000s, we would talk about when mobile was first starting to become a thing, right, we would talk about like the there would be the head of web product management. And they'd be like the head of mobile product management, right. So we'd be very channel oriented with it. But what we found is that, as people started to take up more mobile usage, they actually used kind of every channel available to them if they were a customer of like a service. And so I, I got a lot of experience at kayak when we were just starting to make the intersection between web and mobile. And we had, like, very few people actually working on mobile web, but it was, what a humongous amount of like, inbound people coming in, right, because they, they would find things via search, and our SEO team was doing an amazing job bringing people into the site. But then people felt uncomfortable, in some ways buying very expensive tickets via mobile web. Right. And so the question then, was that we shouldn't actually separate out these things, or at least we should resource them appropriately. That was one of the things that we we figured out that, but I would say that it then became became inappropriate to say that actually, it's not about say, a customer just coming in on web or desktop, right, or even app. But the fact is, is that there's different patterns of usage, you know, in the case that we made a main segmentation between say, leisure and business travelers, right. And the leisure travelers, they usually, you know, they had sometimes specific dates, but not always right, like maybe they were traveling for a wedding or an event or something. But other times, they just wanted to vacation, right? And, but they were more price conscious in some ways that were like limitations on the amount of time. There are a bunch of different things that were there, which were very different. The business travelers were business travelers were very focused on kind of how do we, how do we make the buying experience as easy as possible? rebooking a bunch of things where it's like, I have to be here for this meeting. So what does that mean? And so So anyways, I guess this is just a long way of saying that, it when you think about the way that teams are actually organized, you create natural alignment through the hierarchy, right. And Conway's law would say that you ship your org chart, which I agree with. But the part that people don't seem to remember about that, like 1950, something paper about Conway's Law is that whenever you start shipping, something new, you should also reorganize your team. And so I would just argue that, that alignment is something that's really important. So you need to get that right. And the part that's interesting is the inverse of what we're talking about, which is where are there actual gaps between product leaders? Or what is the tension between those? So for example, you know, if we then use this example of, you know, leisure travelers versus business travelers, right, what are the things that we should be aligned on that are the same? But within? How do we allow for the tension between those different personas or maybe job to be done? Because, you know, you could probably be a leisure traveler and a business traveler, right? Like, how do we how do we adjust between those different things and allow for the right type of alignment, and the right type of like, non alignment or tension between those things. So I think that's, that's a really important aspect I would mention about alignment in general is that we're always trying to make sure that we align with the teams that are most, like meaningful to our team. And so that's like, our cross functional organization when delivering a product, it's also that sometimes we'll take on dependencies with other teams, you know, inside of Google, there's lots of the way that dependencies are usually taken on or through OKRs. And so, you know, there's a lot that we need to do to make sure that we're in alignment, we keep keep updating each other, but that time investment, and the hierarchical like, you know, we're committing to this V OKRs, those signals end up being the really key aspect about the way we do live. And what I would say, though, too, is that when we talk about alignment, I think we also need to talk about things like decision making. And I would say like, in general, decision making is one of those topics, I actually just did a kind of a training internally to our product team, where I call it time management. And we did like, you know, a bunch of stuff around the calendar audit, but then it was kind of a secret decision making workshop as well. And the reason why is because probably you spent a lot of time in meetings, not only like talking about decisions, and I think like I kind of think of like decision making as being broken up into a couple of phases that are maybe not, you know, not as traditional as the decision making, like I've seen these charts from I think was like University of Michigan, where they had a decision making chart where it was like, first you identify that there needs to be a decision and that's that's definitely true. But then it's like now you need to come up with all the options. You need to weigh the options, look at comps, and then you know, there's like something about how you need to like weigh pros and cons and then make a decision or whatever. I think kind of glosses over the fact that inside of organizations where there's a lot of kind of like alignment or team interdependencies that need to take place is that the decision is is less about weighing the right options. then it's more about like the discourse that is required before that decision. And then who is actually the right decision maker? And that deciding how to decide, I think is, I think trips up teams all the time. Yeah. And I think ends up creating like, huge amounts of waste of time, where we don't even talk about who the decision maker is. And we just assume it's going to work the way usually does inside of an organization. And inside of Google, that's usually consensus driven, right? But there's like, at least five or or seven more decision making types that you could use besides just consensus. So I think that's where alignment comes in is like, where are the decision makers inside of this? And then how does escalation take place? Right? So if you have, say, a GM type of model, where a bunch of like if one product team, there's a GM of that product, and all the different kind of cross functions go into that one thing, that's one decision escalation point, but then when you start talking about now across different teams, that goes up higher and higher into the hierarchy, right. So anyways, I would just say that, like, we can't talk about alignment, without also kind of that disagreement of alignment, and that decision making that needs to take place afterwards. Yeah,

JJ 21:05

I love that you brought that up and deciding how to decide is is so that's perfect. I mean, because that's I mean, and I don't think enough organizations actually do that upfront, right? And to your point of, you know, how do you actually make those decisions? Who makes those decisions? What data do you need? What, you know, all of those things, and having that set out? And, you know, kind of clear to everyone involved, I think, is really important. So I want to dig just a little bit more into this decision making, because I think it's so important. And, and, again, I think it's part of what we do, but I don't know that we there's enough clarity or visibility on it. So are there some ways, and you mentioned Google and kind of consensus based decision making? So every organization has their culture, right, and kind of has their way of doing things? But are there some best practices? Or, you know, again, that's it's kind of a buzzword, but are there some ways of organizations knowing the right levels of, you know, people involved decisions are involved involve, like the amount of data across the spider up and down the spine? Are there some places that product folks should be kind of, if we're in this place of the spine, we should be looking at decisions this way, if we're down here, we should be looking at any any kind of framework or anything you use there to help your team along?

Chris 22:28

Yeah, I mean, I think relating it to the spine is very interesting, because for each one of these things that I was talking about, say the strategy, the roadmap and the tasks, there are kind of specific ownership, or decision making kind of authority within those, I think, at least within healthy teams, right, like so first of all, I believe, you know, and I want to, like, throw my assumptions out here, because I think like, there are going to be different cultures around this, right? I believe in like a very much what used to be referred to as a balanced team approach, which is that inside of a cross functional organization, there are different experts that are within that organization. And they are the ones that need to make the decision about the area that they are experts in. And so it the traditional triad of people that would be product design and engineering. And that inside of that, you know, engineering makes decisions and their decision making authority as around kind of how do we build something that's longer term maintainable? That is something we can, you know, iterate on over time? Ideally, you know, I hate the concept of tech debt, because I just feel like, there's no bank receipt that you get, what I mean, like, it's one of those concepts that I think ends up creating more division between engineering and product than it does bring them together. But I think in general, like, how do engineers continue to build like a maintainable system? That is their decision making authority? Right. But like, when we then start talking about like, which is the customer segments, which are the customer segments, we're gonna go after? What are the problems we solve for them? Right? I think there's, I think that's the product managers domain. And I would say, like, you know, how does this experience work? How do people feel about that experience? And maybe even things like if we include, say, user research, right? What is kind of the evidence towards all of these things that we know, right? Like that evidence is something that user research would deal with? Or we talked about, like data science, it's, what are the behavioral, like, the questions that we can answer with the behavioral data? What does that mean? Like, can we answer these questions or not? And same thing with like, legal or safety or privacy or whatever, like, what are not only kind of, like, you know, I think of good practice, because, you know, to me best practice, it oversimplifies a lot of mastery and these things as well. I wanted to pick that word, though. Because I think again, everybody says best practice when they really probably mean like in this situation, right? What is the thing that we should probably do, right? And so I think like across that, that to me is where there are going to be cross functional owners at various levels. So like at the task level, right? When we talk about prioritization We have a set of things that we believe we need to complete, right, which are probably like roadmap items that have turned into a bunch of tasks that probably engineering design and product have kind of created, right. And some of those will be owned by each of those people. Probably a majority of them, though, are actually implementation by the engineer. And so I would just say that, at that, that kind of like that fractal level of just the tasks, right, that type of decision making is where they should be working things out based on their decision making authority that in the ideal, I believe, because I want the experts to be able to make the decisions rather than, you know, now, the types of discussions that should be taking place at that level are really important trade off discussions. And so that's where, you know, I think product managers should probably, I don't require them to have a technical background, but they should be able to talk to engineers in a way that it's like, the engineer says, this is going to be a very complex thing to implement, right? And the product person should should then be able to say like, Okay, well, if I, if I kind of prioritize these aspects of the experience over these aspects, because I think they solve this problem better, like, how does that help in with regards to this trade off around complexity, or time or effort or something like that, right? And then the engineer can say, Well, okay, and this is why like, planning poker is so interesting, right? Planning, poker, is really just this exercise of understanding differences in understanding of something, or belief, right? Or assumptions. And so I think that's like, at that kind of that level of abstraction, you end up having that kind of discussion. Now, ideally, whoever owns the roadmap from like, say, a product standpoint, right? I think they, if there's some type of feedback, and this is where I think like from a product spine standpoint, I think that organizations are good or okay at pushing down, kind of governing constraints and strategy and things like that down to the rest of the team. But they're much less good at actually getting feedback up, right? Because what we assume is that each one of these individual teams, that kind of the edge, where they're talking with customers that they're ideally talking to them on a regular basis, they're building things for them over and over again, they probably have more of the nuance and like specific, like examples of where the strategy may not be working. And so that needs to be pushed up in this level of abstraction. But that doesn't mean necessarily that like, they just get carte blanche to like disagree with the roadmap that is set, right. And so that's where we then talk about this, like escalation. And so you may have a product person that both owns the roadmap and kind of like that discussion around tasks that are prioritized. I think once you start getting up to like a strategy level, that usually ends up being kind of a senior leader in small startups, it could be just the CEO, that's product focus, it could be a CPO, inside of my world that ends up being like the VP of product, right? And so in those particular cases, right, the job there is for us to still talk about, like at a very like, like, broader level, right? Or broader view of, here's the customers that are most important for us across all of this, right. And inside a core machine learning, for example, we have a lot of products, like it's 10s of products, right, that we actually end up managing inside of our group. And so it becomes less about like a specific product meeting a specific need, and kind of how does, how do all these different products in an ecosystem, the way they interoperate with each other? How do they work together to be able to achieve a certain job to be done or to kind of like, you know, we think about different ways of the way we end up segmenting all these things. But I think that's like a really good example of where we need to take a broader view of all of these products, even though there's like prioritization fractally taking place at a lower abstraction level. And so now, going back to your original question about decision making, and I think I was talking about kind of, one of the problems I've seen that will come up is that say a more senior engineer disagrees with like a prioritization of a particular thing, right? That is where like, ideally ahead of time, inside that organization, you know, you can do it either through like roles and responsibilities. I mean, a lot of people do it through like RACI charts, but like, you have a bunch of different scenarios that are kind of, here's the type of scenarios that come up, come up. And here's who is actually the decider in this right. So that's, that's usually the first step for people is to, like start building these things. Now, in my opinion, I think once you've written down RACI, like it's out of date immediately, because I really I do believe in this concept that teams are constantly kind of evolving, people are constantly renegotiating the rules and and there's a Vaughn tan who wrote the uncertainty mindset, which I think is a great book. He also wrote a like a really interesting paper just about something called negotiated joining. And this is this idea that like when you join a team, he was talking about it from the standpoint of like, really high on restaurant like R&D arms, so like three Michelin star restaurants and how they like innovate. You'll join because you have maybe on paper the skills that are necessary to do this job, but you'll figure out inside this team, how you kind of fit there over time. And so you'll try something it will either work out or it won't and you'll negotiate continuous And I think product managers do this an awful lot, maybe even more than, say, designers or engineers, right? Because every team I've ever joined, they've needed something different when it came to like, like a specific artifact or a specific process or something like that. Right. So I think getting back to that point, though, is that usually people end up like trying to do a Rossi, this will solve all of our problems about decision making. It never does. Never the reason why is because of that kind of like outdated pneus. And the fact that you just can't capture every scenario, right? But I do think like, if I think about the phases by which you have to make a decision, like that identification that you do need to make a decision is usually at the point where you see? Well, you know, it's something that's like, kind of interesting to me is that we actually make lots and lots of decisions all the time. And we just don't tell anybody about it, right? Like, when I write a document, I'm making a decision, like word by word, what I put there now, it's very kind of intuitive, right? It's more about kind of a stream of consciousness type of thing, potentially. But there's still like a decision making process, I'm not checking in with everybody, every, for every word that I put on the page, right? Same thing with engineers, like usually, they're at the level of like a PR, or something like that, where they're writing stuff. Now, there's some interesting models, like, you know, pair programming and mob programming that I think kind of get inside this loop, and maybe also provide some value. And we can talk about that later. But I think that's like an interesting model. But I think like, there's lots of decisions that people make all the time that they just don't tell anybody about. Right, and they don't check in with anybody, they don't use a decision making process other than like a very intuitive one. Now, once you realize that the decision you're about to make could impact someone else or and that could be adversely, it could be even beneficially. Right, or it could change the way another team needs to do their work. That's when I think it's really important that you identify that you need to now have a discussion about this. And I would break it up into like, the next couple steps are like, you really need to have this discourse around decision making about that decision. And ideally, the first part of it is like, what is the type of decision we need to make right now. And who should actually be the decision maker versus the people that are like, you know, talking about it and giving feedback, because there's something really interesting about the way that and I think I've talked about this before, but you know, cognitive biases, and the way that like Kahneman talks about it, in Thinking Fast and Slow, are really just individual biases, right. So they're mental shortcuts that we use, because we have, we're low on time, or resources or ability to like, get information. And so we do a lot of these of these cognitive biases come about from the fact that we use a lot of personal shortcuts. Now, there's a lot there's another body of research, which talks about how the discourse of element of decision making is actually makes it so that we don't fall into those cognitive biases. And so there was an example that was given about this.

Chris 32:44

It's basically like a card, like you get four cards with, like, numbers and letters on it. And the question was, is like, which, how many cards would you need to flip over the set and the randomly generated to be able to prove that, for every vowel, there was also an even card. And so it's one of those cognitive tasks that like you have to look at. And even when I was doing it, with like, like, you know, people that are from Google that are like, again, very smart, probably not as like biased. Most people got it wrong. And actually only about one in five people get it right, individually. And the thing that's really interesting about that, is that now if you have you believe in something like argumentative theory, and you have a discourse where there's like a team of five people that come together to talk about the problem, you're 80% likely to get it right in that case. So you just basically like flipped the, the, the likelihood of getting it wrong, to getting it right, based on the fact that you had a bunch of people discuss it, essentially. So I think that's like something that's very interesting is like how you have the discussion, and I don't think like, with all of the async, and hybrid work and return office and everything. I don't think it's just like a Google document with a million comments in it that you have to address. I think there's got to be something different there. But I don't know what that is yet, right? But anyways, that discursive element is really important. And then after you have the discourse, right, you try to limit the biases, you try to do a bunch of things where, you know, now there's other biases that start to happen like groupthink piling on, there's a bunch of things that start to happen. And when people are like groups. At that point, though, you need to then say, Okay, we've done our discourse, we're now going to make a decision and that decision making should come down to either a person with a decision making authority, that could be like the autocratic way of making decisions. Consensus means everybody has to agree, you could do democratic, you could do consent, decision making, which is that no one objects or vetoes this decision. There's even the one that that my favorite is actually like stochastic decision making, which is like flipping a coin. And so groups that are in kind of a place of analytical kind of stalemate. This is one that if like, we can't figure out what the right thing to do is we might as well just like move forward in some cases. And so that's that's a possible decision making framework that you could use, but ideally, you know, you should make this decision beforehand because then you You make the decision. And then you have to communicate it. And then ideally, you get feedback, right? Because the last step is really just like to look back in some way at like our decision making processes overall, was this the right way to decide to decide, right? And that's where we get into like double loop learning. And I'm a big believer that retros are kind of a basic meeting that you should have in every one of your organization's at every level, because that helps you start to see the patterns in these, like complex systems that are human human organizations. Right. So is that that those are the things I would say like if you break it out that way, and I think the key aspect here is this discourse versus the decision making group, I think that gets you really far down this path to avoid all the problems you'll end up having, with like decision making ice today for a lot of teams.

JJ 35:42

Yeah, yeah, absolutely. I love all of that feedback, especially that last part about just kind of making sure that you're doing retros. And you're learning because, you know, as much as we want to set forth some sort of, you know, framework or, you know, deciding how to decide, and this is just the level that we need, and that sort of thing, you know, it's all dynamic, right? I mean, we're going to change at times, and the, the environments going to change, and what we need to do is gonna change. So we do do the best we can, with what we know at the moment. And then if we need to pivot, we pivot. That's awesome.

Chris 36:20

Well, and let's adding on to that point, too, right? Like is that the circumstances change? Right, like the fact that we exist within complex worlds means that something that may have worked in the past may not work in the future, and vice versa. Right. And so I think that's, that's important. And then also, the fact is, is that because we have imperfect information as product managers to make decisions, that means that we may make a decision today and find that we were wrong, but not because we followed a bad decision making process, but just because, like, there was the chance that this would happen. Right. And, and so I think that's another thing that we need to like we need to separate out is that, and I think this is the idea of the fallacy of like prediction is that we can predict how the world will react to every decision we make, and we can't, right and, and so we need to separate out the way that decision making takes place and the outcomes that actually happen. And so we may follow a perfectly good decision making process, one that took advantage of the information we had tried to be resilient to robust in like adverse possible outcomes. But it just turned out in such a way that like, it just was bad. Right, we failed. And so from there, I don't think we should be punishing people for good decision making, especially product managers. But we should be trying to see like, what can we do differently next time. And if it is maybe where like, five why's as a process? I believe in a lot because I think it gets it gets people that don't think about reasons like why things are happening in the world or like asking questions, I think five why's is the entry point to that. But the problem is, if you just assume that five why's is the way to go, we'll think about is that everything we do is actually our fault. Or the outcomes that happen is because it's our fault. And the reality is like, if you're back in that context, even if you could five why back to the context that happened, you may not have made the same decision. Right? Yeah, sorry, you you there's no way to tell that you would have harnessed the information differently than that person did. And that's the reason why the reason why I think that generally, when there's like performance issues, I tend to look at like, what are the systemic reasons that that is happening first, rather than that the person and and so I think that's the thing that we need to be aware of when we start talking about decision making, as well as like, how much power do people have inside of these hierarchies? Right? Could they have made a different decision in that moment or not? Right. And so I think that's, that's something we need to think about. And that's why I think like five why's even though tries to build context and ask questions, it doesn't actually take into account the fact that you were not in that moment making that decision. And this is where I, you know, I've been kind of experimenting with these things called decision forcing cases, which is kind of like a case study, but really tries to put you into the shoes of the person that was making the decision and writing some of these for like product managers, for example. I think it because you were not in that situation. And if you just read a case study, you'd be like, of course, I'll just like act this way, in this decision. When the reality is like, there was a lot of competing pieces of information, there was a lot of noise in the environment. And that actually trying to make a decision was incredibly hard at that moment. And this is what happened. And so the question becomes, like, What expertise can you glean from the fact that this person use this information, rather this information to be able to make that decision?

JJ 39:33

Yeah, I love that. And I think this is such a fascinating topic. It's what I love the product spider, again, it's just the analogy of it and all of that, but But again, the the practical application that we can take into, you know, from, you know, from these abstractions from these areas to the actual decisions that are made, right I just, I just think it's it's such a practical way of Looking at things and so, I mean, you know, decision making is just fascinating. And I love, love, love the way this this conversation is kind of kind of wrapped to this point because it is so important to divorce the outcome of decisions with the process we went through. But it's so difficult to do. I know very few people and very few teams that are really good at that. And it takes an intentionality to do it. And again, back to your point about retros. And kind of looking back and really analyzing what we did and learning from what we did, in that being part of the team DNA and having very thoughtful retros. And, again, not what happened, but how we went about it, and how could we potentially do things differently, right? We disregarded this, this what we considered noise, but maybe it wasn't noise, maybe it was something we put it right. And it's not that we're going to find like to your point, it's not like we're going to find, oh, we We absolutely did that wrong, and we should have done this. And that would have been right. It's not necessarily that that cut and dry. But we still need to have those conversations and those discourse and continuously think through that.

Chris 41:07

Yeah, and maybe like, the other aspect of the product spine that I think I'm advocating for is just more kind of connective tissue between these different levels. Right. Like, I think that's the other thing is that when I think decision making goes bad is when you end up like having to reinvent context for each one of these decisions, right. So at a at like, say, a task level, or, you know, there was there was a time where I would read a bunch of different PRDs. And every PRD had like a different set of principles that were actually being applied when the reality is like, there probably should be one set of principles that we all try to like, you know, go by, which is our culture, right as a team. And we shouldn't have to, like reinvent new principles every single time that we write a PRD, for example. And so if we don't have that capability, and I think John color has talked about this a lot as well, because he talks about like the one to three, kind of like levels of things, right. So like one to three hours, one to three days, one to three weeks, all the way up to like years or decades. And each one of those should probably be a separate document. Again, I still feel uncomfortable about saying like three decades when the reality is like what is like the biggest mission that we're trying to achieve today. But we're like working towards like, I think that temporality is still kind of an interesting thing to, to, like be concerned with. But inside of each of these levels of abstractions like like strategy, roadmap and tasks, if these things cannot reference each other, they don't have that connective tissue, I think again, you you end up having like, a lot of problems because your, your your spine is just like floating around in three different places, right. And you could add lots of other things that are inside of there. Right? So you may end up having things that are even more high abstraction, like the idea of a portfolio roadmap, right? You might have things like a system or process and procedures or, like the way that we end up doing our work could be very high abstraction, right? You may even, you know, we start to go like to the lower levels, right? Maybe you have like prioritization rubrics that you end up using that help you do this. But I think my main point about like a lot of this product spine is that it's not just about the fact that they exist there temporarily aligned, but it's that they're actually interconnected with each other in some way. And so if you see that you keep on having to like write a couple page preamble to your like specification for a feature, right? Every single time, that probably means you don't have the right documentation to reference that or these other higher levels of abstraction. And I see a lot of people suffer from this. And so that's, I think, another aspect of this, like, of the product spine that I think is really valuable or important is that it needs to be connected in some way.

JJ 43:38

Yeah, well, I love it. I love this conversation. And I love the the way you think one of the reasons I love following you and you know, reading your your work and your resources is just because you you bring together these really important topics and thoughts around products. So Chris Butler, thank you so much for joining me telling us all about your products. Fine, I know you're gonna be talking about it at some, some different product events. And so we'll definitely link to your articles, your resources and some of the other resources that you've mentioned today as well, because I know they're, they're great learning experiences for everyone. Chris, thank you so much for sharing your wisdom with us.

Chris 44:15

Yeah, thank you so much. And of course, I'm always happy to connect with people either on Twitter where I'm Chris bot or on LinkedIn where it's just my name, but I'm always looking to you know, I think one of the reasons why I keep on thinking about this stuff is really just things that I end up learning on the job, I want to help other product managers get good at their craft, right. And I think there's so much tacit knowledge that is related to being a great product manager, that really any leg up I can give other people I think we'll you know, just improve the overall like capability of us building things that people actually, you know, they need and help solve real problems for them. So, you know, thank you for the time today to be able to explain this concept and, you know, again, we'd love to connect with people if they're interested in either trying to apply this to their world. And I would love to hear how it works out, right? Because I think that contextual illness is really, really important when it comes to the way that we do our jobs. So thank you for the opportunity. Great to talk to you again.

JJ 45:10

You bet you bet. And everyone go to productvoices.com. We'll have this episode on its own page, you can find links to Chris's LinkedIn and Twitter there as well. So, again, Chris Butler, thank you. And thank you all for joining us on product voices. Hope to see you on the next episode.

Outro Intro (the incomparable Sandra Segrest) 45:28

Thank you for listening to product voices hosted by JJ Rorie. To find more information on our guests resources discussed during the episode or to submit a question for our q&a episodes, visit the show's website product voices.com And be sure to subscribe to the podcast on your favorite platform.

The Product Spine - Aligning Strategy, Roadmap, and Tasks for Better Products

SHOW NOTES:

Connect with Chris:

Resources mentioned in the episode:

Episode Transcript:

Recent Posts