Podcast: Play in new window | Download

Sean [00:00:18] Hi, welcome to the Product Momentum Podcast, a podcast about how to use technology to solve challenging technology problems for your organization.

Sean [00:00:28] Hey, Paul.

Paul [00:00:29] Hey, Sean. How’s it going?

Sean [00:00:31] It’s going well. That was a great interview with Bruce McCarthy, the one and only.

Paul [00:00:35] Yeah. What did you think about it?

Sean [00:00:37] I think he’s your people.

Paul [00:00:39] He is people. I like him a lot. I think our listeners are going to like what we get to too. It’s a great intersection of strategy and tactics.

Sean [00:00:48] We talk about prioritization and how you can’t make it objective. We talk about road mapping. We go deep on his book and his concepts. There’s a lot of high-level discussion, but a lot of good tactical, practical advice in there for product people.

Paul [00:01:01] Yep, and if you’re a car guy and a product person, this is the podcast for you.

Sean [00:01:06] And a sci-fi guy.

Paul [00:01:08] Yeah. All right, let’s get after it.

Sean [00:01:09] Let’s get after it.

Paul [00:01:09] Well hello everybody, today we’re excited to be joined by Bruce McCarthy. Bruce helps grow organizations and achieve their product vision through workshops, coaching, speaking at events around the world. Bruce’s cowritten Product Roadmaps Relaunched: How to Set Direction while Embracing Uncertainty and opines regularly about product culture. Bruce, welcome to the pod.

Bruce [00:01:31] Thanks very much, Paul. Glad to be here.

Paul [00:01:33] We’re happy to have you. So what’s on your mind lately? What are you observing in the product space that you think that our listeners should be thinking about and improving their practice around?

Bruce [00:01:43] There’s a lot of talk about tools and skills like outcome-based roadmaps, OKRs, Agile, Lean, experiments, and there’s a lot of great material out there about how to do these things. But I was really struck just last week by a new article by Marty Cagan where he came out and said, right at the start, “actually, I’ve stopped recommending OKRs for most companies,” and I thought, “Woah, OKRs is one of those key tools for managing to outcomes rather than output that I’m a huge advocate for.” And I thought, what is Marty saying? And what he was saying was not that OKRs are bad, which sounded like maybe what he was saying at the start, but there are prerequisites, that there are underlying cultural things about teams and about companies that need to be addressed first, that are necessary in order for all these tools that we read about: Lean and Agile, design thinking, OKRs, roadmaps done properly, etc.. Before you even start thinking about should I be estimating in story points, you’ve got to get straight the “why are we here?” Questions. And that’s what I think has been on my mind a lot and that’s why his article particularly resonated with me. I named my company Product Culture because I do think it’s about those cultural aspects of why we’re here, how we work together, how we think about the purpose of going to work every day that’s mostly on my mind.

Paul [00:02:16] That’s great. You know, Marty is a hero of ours. We follow him closely. And I think one of the things that strikes me in the way that you speak is distinguishing product culture from product management, and in a Venn diagram, most of those things, this is maybe my opinion, you can obviously push back on this, but I think in a Venn diagram, most of it is overlap. But culture is distinct from product management in key ways. What things embody this idea of culture, product culture versus product management, for you?

Bruce [00:03:49] Well, product management is a role and a discipline and a set of tools and a set of responsibilities, right. Product culture is, I mean, I don’t want to call it vague because I don’t think it is. I do think you can really point at things and say, “ah, that’s good product culture.” But one of the things is it starts with a vision. I think actually there are three elements, and I’ll talk about each one real briefly. You need to have a vision. You need to have a plan. And you need to have a team. And right there, that third one, the team, is the part where it goes outside of product management instantly. You need to have a vision, but not just any vision. It isn’t a vision of a product in the sense of, you know, this pen is a product. It’s a vision of empowering the customer, of elevating the customer to be more powerful, more capable, happier, more successful, to help them meet their goals. It’s about writing, to use the pen analogy. And then to take it further, it’s about communicating and making the customer feel like they are able to communicate powerfully. So that’s the vision, and the product is a means to that end, really.

Bruce [00:04:57] Then you’ve got to have a plan. Some of the most audacious visions for the future that you see companies like Tesla or SpaceX putting out there sound like science fiction. Tesla wants to accelerate our move to sustainable energy as a civilization and SpaceX wants to literally colonize Mars, and you think, “well, that’s crazy.” Well, maybe, if you try to do it all in one step, but maybe there’s, as Elon Musk calls it, a secret master plan to get us there one step at a time. And you’ve seen Tesla play that out with going from low volume, highly expensive cars to higher volume, more affordable cars over time. And then the third thing is that team thing. A good product culture cannot be done by product managers alone. It’s the combined collaborative effort of a team of specialists, product people hopefully, but also designers, engineers, testers, data scientists, whatever you need to get the job done. It’s an emergent property of all of those people working together toward a common vision with a plan of delivering value in incremental steps.

Paul [00:06:05] I want to come back to vision in a minute, but one thing that I want to tee up for you is this concept of what’s feasible and how that intersects with what product culture can do and where it moves the needle on our mindset and what is on the radar or even imaginable in terms of what outcomes could be foreseen by the team and by the impact of what we’re doing in the world. So what is it about product culture that intersects with this perception of what’s feasible, and how is it different than just product management?

Bruce [00:06:45] Right. Well, I’m gonna be a total nerd and use a Star Trek quote here. Captain Picard says, “things are only impossible until they’re not.” And that’s the history of innovation, right. Right there. We thought going to the moon was impossible until we proved that it wasn’t. Some people said that it was impossible. There’s a quote from a physicist saying that nuclear fission is impossible right before we proved it was possible. And you see companies today doing things that were previously thought to be impossible. I’ll go back to Tesla. Back in the 90s, I don’t know if you remember this, but GM had an electric car, the EV1. They sold it in the second half of the 90s for five or six years. Well actually, they didn’t sell it, they leased it. They leased it to thousands of customers in California as a kind of a proof of concept and they did it because of governmental regulatory pressure to come up with a clean sort of technology.

Bruce [00:07:44] And in the end, they decided that it was impossible to make a viable business based on electric cars, even though, actually, the technology that they had at the time was not that different than the technology in the earliest Teslas. They had a 200-mile range. They could charge overnight. They had more or less modern technology, but they concluded it was impossible. And yet, a couple of decades later, it’s now suddenly possible and we have the Chevy Bolt and the Chevy Volt, and what’s changed? It really isn’t the technology that’s changed; it’s the perception of what’s possible. And it was Tesla that changed that perception because they went about it with a different mindset. GM had an existing business and they were looking at it from the point of view of, what can we do with what we have? Where can we go incrementally from here? And they were like, “oh, this is hard, you know, we have to change up the design of the motor and we have to figure out what to do about the weight of the batteries,” and, “ugh, this is so much harder than just making small incremental tweaks to existing designs.” You know, “that’s going to hurt our quarterly profits, I don’t think we should be doing that.”.

Bruce [00:08:53] Tesla didn’t ask that kind of question. They said, not, “what can we do with what we have?” They said, “what must we do to bring about the future we desire?” And so they said, “I don’t care if it’s hard. I don’t care if nobody’s ever done it. I don’t care if it sounds crazy. We’re going to do it anyway.” And that’s the difference, is you start with the ultimate vision in mind and you say, “how are we going to get there in steps?” Tesla asked themselves, “can we, overnight, build a company that has the volume of GM and have cars where economy of scale kicks in and gives us an entire industry?” “No, we can’t do that in one step. We can break down the problem and we can do it in three or four steps.” And they did. The model three, maybe it’s still a little expensive, but it’s a whole lot more affordable than where they started with their roadster, which was extremely small volume and very expensive. To me, that’s the difference. It’s asking that question of, “how do we make our vision come true?” not, “what’s the next thing we could add incrementally improves our business?”

Sean [00:10:00] Yeah. These are big things we’re talking about, right. When we talk about ground level product, obviously we have to have some sort of grander vision for how we’re changing the world or making the world a better place. I think it’s easy to get caught up in, at the ground level, how do we translate that into something that we can feel success with now, like these incremental steps?

Bruce [00:10:18] Sure. That’s right.

Sean [00:10:19] Also, so you think of Elon Musk or Steve Jobs and the quote from Steve Jobs around, you know, “my customers don’t know what they want until I show it to them.” And the reality is, we don’t know if it’s going to work until we actually put it in the market and it works. So we have to have these feedback loops all along.

Bruce [00:10:33] We can’t know that, for sure, we’ve got to have feedback loops and we’ve got to do it in small steps. There’s another story that I really like about breaking it down into small steps. There’s this company, or there was this company called General Magic. I don’t know if you’ve ever heard of them?

Sean [00:10:49] There was a documentary recently about it.

Bruce [00:10:51] That’s right, and I watched the documentary and I was fascinated. They more or less invented the smartphone but in nineteen eighty-nine. They show, in the show, sketches that they had of something that you would call an iPhone if you look at the sketch, but in nineteen eighty-nine. It was a handheld wireless device with a touch screen and it had apps on the touch screen that you could launch and it was meant to be both a phone and a full time connected device. Before the Internet was even really a big thing, before most people even had email, they more or less invented the iPhone or something extremely like it. The mistake that they made was they had this grand vision. They had this seemingly impossible vision, and they got everybody excited. They signed up partnerships with AT&T, with Motorola, with IBM, and they took four years of R&D to come out with a product and it was a flop because the market wasn’t ready, the technology wasn’t ready, the partners weren’t ready.

Bruce [00:11:54] What they could have and should have done was to do what Apple did that led up to the invention of the iPhone. The iPhone came 18 years later, but they got there in steps by starting with the iPod. They came out with something that was possible to sell, to give people something they actually wanted at a price point they would accept that was a stepping stone on the way. The iPod came out and it was the necessary substrate for the iPhone. It went step by step, adding more capabilities, more smarts, more connectivity, a bigger screen, eventually a touch screen with the iPod Touch, and then that led to the iPhone. The critical bit that I think General Magic missed was, the iPod was valuable by itself, even though it was only a piece of their ultimate vision of an iPhone-like device. It was something people would buy, not because it was a step on the way to an iPhone, which they could not get envision, as you said earlier, but because it was already something that they wanted. And that’s the same thing Tesla did with the first electric car that they made. They made something that a customer would actually want as a stepping stone to eventually making the model three.

Sean [00:13:11] That’s a good distinction.

Paul [00:13:12] If I could recap just quick because I want to capture one thing before it slips. I think what we’re talking about is not the vision of the product. We’re talking about the vision using the product as a vehicle. Right, the product isn’t the end in and of itself. It’s the way that we want to see our vision manifest in the world.

Bruce [00:13:29] Vehicle is the right word. Radhika Dutt actually uses that term. Her definition of a product is a vehicle for making change in the world. And I would say, you know, that change hopefully works two ways. One is it makes the customer more awesome, more bada** as Kathy Sierra would say, more successful, but it also makes your business go. Hopefully, it’s a viable step on the way in your company’s growth so that you’re there to make the next innovation and the next one and to continue to add value to the world. But that’s exactly right. Product is a vehicle, a means to the end. I think that’s what killed BlackBerry, in my estimation. I don’t think it was that they failed to anticipate the consumerization of I.T.. I don’t think it was that they didn’t have Steve Jobs’ genius. I think it was that they never quite grasped, or maybe forgot, that they were a status symbol, that they were a device that empowered executives to feel powerful and act in a powerful way. And they thought they were a phone maker and that wasn’t really what they were. And then when somebody came out with something that made people more powerful but stretched the definition of a phone (Apple), they didn’t recognize it at first as competition because they were thinking about the problem wrong.

Sean [00:14:46] Yeah. There’s another interesting sub-thread inside of what we’re talking about here. It’s this concept of technology approach versus market pull. And I think that’s another place where General Magic may have gone… They just were ahead of their time. They had really cool technology that wasn’t quite ready yet and they are trying to push it into the market. The market didn’t quite yet exist.

Bruce [00:15:08] Yeah.

Sean [00:15:09] And they tried to do a little too much, and all the stories that are banged into our heads as product managers.

Bruce [00:15:15] Well, that’s right. And you do have to wait for the technology and the market to come into overlap, right. You have to draw that Venn diagram of what’s feasible, what’s desirable by the market, and what makes a viable business. I mean, probably everybody did; I drew what is essentially an iPad as an idea of an Internet-connected reading device in nineteen ninety-six, you know, a decade before the iPhone even existed. I’m no genius. It was just sort of obvious. And I’m sure Apple would have shipped one back then if they could have. But a device like that would have cost one hundred thousand dollars at that time, given the available technology.

Paul [00:15:59] So what I think we’re talking about without naming it quite yet is really the product manager’s role in road mapping and really turning road-mapping on its head. And I think what often I deal with in conversations is this conflation of what is the feature that will be released on the date and what order is it going to come out in. But really where you go is tying this vision to what problems are we’re going to solve. I feel like what our listeners are thinking about is the day in the life of a product manager. And what they hear from executives up is, “when am I going to have the feature and when can I go sell it?” And that kind of planning is necessary. But really, the product manager’s job is to speak vision into the roadmap. So how can you help people understand, what is the difference between these artifacts that we call roadmaps and release plans? What do they do?

Bruce [00:16:51] Right. And you’ve hit on it. This is what the Roadmaps book is really all about, is that distinction. And I don’t want to say that release plans are bad. You need them, as you said. It’s just that a realistic sense of, “what am I going to ship when?” is probably something that you can predict with 80 percent confidence no more than a quarter out, maybe less, maybe half that. Maybe six weeks is kind of typical from teams that I work with to reliably say, yes, this feature on this date. And there’s two types of uncertainty built into that based on those two things, the feature and the date, right. One sort of uncertainty is, how long is it going to take us to build this feature such that it actually works out in the market? And there’s enough uncertainty in that one to make me conservative about making promises outside of a quarter. But even more, uncertainty is whether that feature is the right feature. Yeah, OK. You’ll have something you can sell and we’re gonna call it this. But the question of whether something is the right feature goes back to, well, it depends on what problem you’re trying to solve. If the problem you’re trying to solve is, we don’t have a long enough list of features, well, that’s kind of an unusual scenario to be in, right? The real problem is our customers could like the product better because it makes them more successful. It solves problems for them. It makes them feel powerful. It makes them actually more effective.

Bruce [00:18:18] The real result you’re looking for is that the customer is successful in measurable ways like they are more productive or they are making more money or they are saving costs. They are getting more done with less and they are happy and satisfied. And you can measure those things. If it’s a SaaS product, you can measure their usage of the product, their throughput, and so on, and you can do NPS surveys and you can find out, are they more successful? And then the other measure is, does it drive your business? Does it increase conversion rate? Does it increase renewal rate? Does it increase your profit? Does it increase your growth rate, your win rate in deals, those kinds of things? Those are the measures that take longer to play out than, what feature am I shipping in the next six weeks? And that’s what a roadmap is about, is, what problems am I going to try to tackle in the market that if I tackle them, I believe they will make the customer more successful and make our business more successful as a result? And I can’t predict twelve months out, three or four quarters out, exactly what I’m going to ship when, because I have to do a bunch of testing, iteration, and R&D to figure out what feature is the right feature and how long is it going to take me to ship it. And then even after that, how long is it going to take me to iterate on it until it solves the problems well enough that I can move on?

Paul [00:19:44] Right. So it’s almost resisting the temptation, even though it takes a long time to go through feature requirements and UX, it seems like that’s hard work because it takes a long time, but it’s almost resisting the temptation to get into that waterfall PRD, 300-page binder.

Bruce [00:20:01] Oh yeah.

Paul [00:20:01] Because that takes a lot of time, people equate that with hard work. But really, the hard work is in the roadmap. It’s a level above that where we’re really trying to figure out what is the difference we’re making in the world and then laying in the features and the dates and the requirements.

Bruce [00:20:16] In a way, people focus, I think, on shipping features because it is easier, because it is more certain. They can say, “all right, I’m going to write a lengthy spec, and I’ve written plenty of them in my day, and then we’re going to build it, and it’s honest work and we’re going to do our best and we’re gonna try to hit the date and so on.” And that’s all conceptually easier. You know, it’s straightforward. It’s like, “OK, this brick and then this brick and then the other one on top of that. Great. I can do that. I can build a wall.” But what use is a wall? What’s the purpose of a wall in the first place? Is that helping the customer? “Oh, I don’t know, that’s kind of a tough question. I’ll get back to you on that.” That is the harder work and the less certain work. Like you say, it’s easy to fall back on that stuff. But in the long run, you’re gonna be out of a job if you’re not solving the customer’s problem effectively and driving your business. I’d rather put everything behind those two goals and not behind just shipping as fast as I possibly can.

Bruce [00:21:20] I’m working on, actually, a maturity model for teams, and level one is expert teams that do tasks. They’re essentially ticket takers, right. And then level two is feature teams that put out feature after feature as fast as possible. Somebody says, “build me this feature,” they say, “aye aye sir.” And that you can do with a project manager. And then the third level is what Marty Cagan would call product teams, which is, they understand the customer and the customer’s problems and they are out there to solve the customer’s problem so that they get more traction in the market, is the assumption. But the next level, I think, beyond that, the fourth level is outcome teams, teams that their job is to make a successful business. And I think that’s actually the evolutionary path of product management, too.

Bruce [00:22:13] Because if you think about it, often a junior level product manager or PO, I hear from them all the time. They’re saying, “oh, I feel more like a project manager than a product manager. I’m told what we’re supposed to build and given a list of features and I just have to make it so and I don’t have a lot of influence over whether these are the right features or not. I’m taking customer requests or I’m taking executives’ direction.” Right. And so they’re stuck in level two. And Marty wants, rightly, to get them to level three where they are understanding the customer and the customer’s problem and using the smarts of the entire team to try to figure out the best way to solve the customer’s problem. And that’s a real product team and a real product manager job. But the next level of evolution, I think, is I don’t know if you’re seeing this, but there are a bunch of companies that I’m familiar with that are adopting a GM role, general manager role, and they’re populating it with product managers. But they’re giving them, in addition to the usual product management responsibility, they’re giving them P&L responsibility. They’ve got to actually make a successful business or line of business or product line. And they’re giving them not just other product managers to work for them, as a senior product level person, but either solid line or dotted line, they’ve also got the engineers, the designers, even the sales and marketing resources in some cases, to make a successful business, to include the customer success metrics and the business success metrics.

Sean [00:23:45] That’s fascinating. I’m going to take a step back because you mentioned the wall analogy, which I love. And I believe that that is one of the problems in our industry, in general, is that we’re called software engineers and we’re related to every other engineering discipline on the planet, but software engineering is very different than traditional engineering.

Bruce [00:24:02] Yeah.

Sean [00:24:03] So the business looks at us as a team and says, “oh, you should know what it’s gonna take to build this thing; you know what the bricks are, put it together and, you know, go get after it and tell me how it’s going to cost and how long it’s going to take.” But the reality is, software engineering is a very human process and we have so much dynamic capability in the course of building these products. We can change everything.

Bruce [00:24:23] Yeah.

Sean [00:24:24] And it’s so important to motivate the team to come up with the best ideas. It’s so important to understand the motivation of your consumers and the users and how they’re going to get value out of this product, not just meeting the current needs that we think we’re meeting, but also meeting those higher-level needs, things that they care about as people like joy and learning, growing and all the thinks that software products have the ability to actually change.

Bruce [00:24:45] Exactly right.

Sean [00:27:47] So what are your thoughts on that?

Bruce [00:24:49] Well, I think you’re absolutely right that people frequently misunderstand the nature of software development. They think of it as analogous to building a wall or building a bridge. We think of it as it’s known science, right. They think of it as, well you design the bridge or the wall or the house or the car, whatever. And then you just go about building it brick by brick or board-by-board or whatever. And it doesn’t work that way in software for two fundamental reasons. One is it’s actually more of an R&D effort, a research effort in some ways, an experimentation effort than it sounds like. Because when you’re building software, you’re not building a bridge that’s exactly like every other bridge that you’ve built before of a similar length. Or, it’s not like manufacturing a car that you’re making one hundred thousand of this year to exacting specifications. You’re building a one-off every time and you’re building it for the first time. So there’s inherently a bunch of uncertainty in whether your initial ideas about the design are going to work. You’ve got to actually try it and see.

Bruce [00:25:58] And so there’s a bunch of inevitable trial and error and backtracking and, “oh, this is harder than we thought, oh, this is more complicated than we thought, oh, we’re building on top of some crusty old system that we didn’t realize did not have some of the underlying capabilities that we need.” It’s a little bit like the difference between, especially when you’re adding features, building a brand new house versus renovating. And if you’ve ever done renovation, you know that the budget always runs over because, once they open up the walls, they’re like, “oh, we have to replace all this electrical wiring before we can move forward,” or the plumbing is substandard or whatever. Right. So there’s that level of uncertainty. This is the first time and it’s a one-off so you’ve got to take that into account. But the bigger level of uncertainty is what you hinted at about joy. Maybe that sounds too airy-fairy, but joy or not joy can make the difference between people buying your product or not buying your product, right. So that level of uncertainty of, “did we build something that people will actually value enough to buy versus whatever alternatives they have?” is huge, is 10 times the uncertainty that I described in terms of the actual building of the nuts and bolts of the thing. Right. And that’s why most startups fail, is because they built something, not that was technically a failure, but because they built something that nobody wanted, at least not enough to pay for it.

Sean [00:27:25] All right. So if I could sum up some of the things that I’m hearing from your ideas here, because you talk a lot about serving the customer, serving the business, and this is the art of product leadership, figuring out what is the balance between serving the business and serving the user with something that we can feasibly actually do, right, through an engineering team and the technology that’s available to us. And this, I think, is another fundamental problem in our space, and that’s the problem of prioritization, which is producing a roadmap is all about. So the art of product leadership is really the art of prioritization…

Bruce [00:27:57] Yeah.

Sean [00:27:58] … and getting the right things out at the right time and building the right road map…

Bruce [00:28:02] Right.

Sean [00:28:02] …and making sure that it stays adaptable.

Bruce [00:28:04] Well, I agree. Prioritization is huge. In fact, other people have said, it’s like the fundamental skill of a product manager, is prioritization, and it’s hard and people struggle with it and people disagree about it all the time. Often the fights that you see about whether we should do a thing are not fights about whether we should do it at all, but whether we should do it first rather than something else.

Sean [00:28:27] Right.

Bruce [00:28:28] Right, so there’s a lot of struggle and importance there because you can’t do everything, so you’ve got to be pretty ruthless about your priorities, but how do you make those decisions? And again, I take it back to, what outcome are you looking for? You’re looking for success for a particular type of customer that drives your success as a business. And so if you can articulate the customer’s goals and your business goals, you can use those as a lens for, what things should we work on first? If you’re trying to prioritize features, well, do these features serve the customer’s need and will they drive the customer’s behavior in terms of buying or renewing or using the product? OK, that sounds like a winner. And this also drives the question of research. Do I have evidence to support my idea that this will drive the customer’s behavior more than that? So I described, in chapter seven, five different ways to do prioritization. My favorite one starts with those objectives. What are the customer’s objectives? What are your business objectives? And then uses an ROI score to compare different ideas: meeting objectives versus level of effort versus your current level of confidence in your understanding of the problem.

Sean [00:29:50] Right. And I think that underlies the whole problem of prioritization and why we need to keep flexible room as a proof for it.

Bruce [00:29:56] Yeah.

Sean [00:29:56] Because think of what you just said, right. First of all, we’re guessing at what the impact will be on the customer. We don’t know. And then you’re putting a fudge factor in front of that, like what’s the probability that it’ll have that, right? So we don’t know, until we put it in the market and see it change the world, we don’t know what impact it will have on the business until it’s impacting the business. So we’re guessing. And then we put a fudge factor in front of that. I’ve seen so many different attempts at objectively prioritizing roadmaps and the reality is it’s a very human process.

Bruce [00:30:27] Well, that’s right. If it could all be done just in the product manager’s head and if it were that easy that once the product manager had decided on the priorities, they just happened that way, maybe we wouldn’t need, actually, to go through these complex chains of logic or use that kind of mathematical formula or anything. But it’s not that simple. It is about getting the team on board, and not just the team that’s building the stuff, but the extended team: the executives, the salespeople, the marketing team.

Sean [00:30:57] The team that’s paying for it.

Bruce [00:30:58] Right. Yeah, because, you know, you’re not going to get to stick to your priorities if the CEO disagrees with them, right. So what I really like about using a framework that brings it back to goals is, not the mathematics of it, I think actually you want to keep the formula as simple as possible to be transparent. It’s not really doing the math that helps you come to alignment on priorities. It’s agreeing on the goals. Once you’ve all talked through, “well, what are we really trying to accomplish here? Why would we build a wall versus a bridge?” Once you’ve agreed on that, actually getting alignment on the what becomes much easier.

Paul [00:31:40] So I want to bring this back down from 30000 feet for just a moment.

Bruce [00:31:44] Great.

Paul [00:31:44] For that product person, that product leader, who is just above level two, trying to break into level three, and they’re in an agile world and they’re going from scrum ceremony to scrum ceremony and they’re trying to make a difference in their organization, what are some tactical tips that you could offer for overcoming what you’ve called in your talks road bumps, right. So you have these things that get in the way of this prioritization that we all, I think, are hearing the tremendous value in sparking joy, in creating value in the world. But it really takes this people process of negotiation and communication and teamwork. What are some tactical tips for the young, up and coming product manager that they can take and apply in their next backlog refinement?

Bruce [00:32:33] Right.

Paul [00:32:33] Today.

Bruce [00:32:34] So first thing, you know, agreement on the goals. What are we trying to accomplish here? So we discuss that. Second thing, you could probably, if you’ve got agreement on the goals as a product manager, you could probably take a shot at prioritizing things to do based on those goals versus some high-level notion of effort. But that’s really only half the battle. From there, it is about getting alignment, right. So I think there are a couple of really good tools that you can use to get your team and your extended organization to alignment around any set of priorities around your roadmap. One is, you do want to involve actually a bunch of the stakeholders, not just engineering, design, and data science, but marketing, sales, finance, and the executive team. And you could imagine having a group session where you get all of those stakeholders into a room and you walk through the challenges, the goals, and you make prioritization decisions as a group. And I’ve seen that work and it’s very powerful, sort of a workshop kind of environment.

Bruce [00:33:42] But there is one step that I think is really important to take before that and I call that shuttle diplomacy. It’s also called pre-alignment or pre-wiring by other folks, and that is that you meet with those key stakeholders one-on-one before you get them all in a room together. And there’s two things that it’s really important to do when you meet with them one on one. The gist of the conversation is not, “here are my priorities, will you sign off?” The gist of the conversation is, it’s just like a customer interview. “Tell me about your part of the business. Tell me what’s going on in your department and what is important to you and why.” I’m establishing that I actually care about outcomes for you, my stakeholder, and listen to that, and then dive into the priorities and ask for their help. Say, “I’m working on the priorities. I have a draft set of priorities. It’s a work in progress. I need your input before we can finalize this.” And again, I’m valuing the other person’s opinion. And then you don’t go over probably your whole list of one hundred and seventy-five different things, but instead, just focus on the ones that they care most about, the ones that they have some reason to care about from their functional point of view or their customers’ point of view. Either they think they’re great ideas and they should be prioritized high, or they think they’re stupid ideas and should be cut off the list and try to have a conversation that ties everything back to goals. And when they say, I really think that this is prioritized wrong, ask why in terms of the goals. What are you trying to solve by prioritizing this higher or lower, and have a one on one discussion that’s not exactly a negotiation, but it’s an understanding. It’s coming to alignment through an understanding of the other person’s point of view and maybe tweaking the numbers if they convince you that there were things you didn’t know that might change your mind about the priorities. Getting that empathetic conversation going is key. It also means that once they’ve had their fingers on it, they have co-authorship of the plan and by the time you get to that group meeting, instead of everybody trying to prove how smart they are by poking holes in your plan, they’re all going to want to take credit for it, which is great, which is the best possible outcome.

Sean [00:36:00] What you want…

Paul [00:36:01] Right.

Sean [00:36:02] … everybody to take credit for it, right.

Bruce [00:36:04] Right, exactly.

Paul [00:36:04] I first heard that pre-wiring concept from Mark Horstman on Manager Tools podcast a few years ago, and I’ve used that language specifically in doing exactly what you’re saying and it is magical. You get these pre-alignment meetings, these one-on-one meetings, and then you get to the group meeting and everything just clicks.

Bruce [00:36:21] Everything just clicks, right.

Paul [00:36:22] Yeah, it’s great.

Bruce [00:36:23] Exactly.

Paul [00:36:24] I have one more question in closing out. I wanted to ask what book recommendation you’d give, but you’ve already read our minds and shared a list of great books, which we’ll link for our listeners below, but one good thing you included is, I would say it’s a guilty pleasure of mine, Off to Be the Wizard.

Bruce [00:36:43] Oh, yeah yeah yeah, I love that book.

Paul [00:36:44] Narrated by one of my favorite narrators, Luke Daniels. But I’ve often thought that’s the kind of book a product manager would write if they sat down to write a book because it’s just so feature-specific. I highly recommend it for any product manager.

Bruce [00:37:01] He describes the actual mechanism by which you can do essentially magic by reprogramming reality.

Paul [00:37:08] Exactly. It goes back to Tesla and Elon and Steve Jobs.

Bruce [00:37:11] Right, right.

Paul [00:37:13] It’s really a word that we don’t use often in business and tech circles in building products, but it comes down to imagination. It’s this creative spark that I think is one of, I won’t go on the line and say it’s the only, but it is one of the defining characteristics of most successful product managers, imagination as a skill that you cultivate. What are your thoughts on imagination as a practice within product management?

Bruce [00:37:40] Yeah, I think that’s right. Remember I said that the three ingredients were a vision, a plan, and a team, and the imagination part is necessary for a vision. You have to be able to envision something that does not yet exist, envision a future state. Most people, like GM, are kind of like, “well, can we incrementally get from where we are building these kinds of cars to building electric cars? I don’t see it,” because they’re hampered by history. I could imagine maybe there was a product manager in GM saying, “no, we can do it,” but they weren’t listened to at the board level and GM ended up not only discontinuing the program but repossessing those cars and crushing them. They were so convinced that it was a bad idea. And it took Elon Musk and that group of people to say, “we can envision a future, and no, we can’t get there in one step, but we’ll figure out a way, step by step, to get there. We can envision.” And I find science fiction to be inspirational in that way. Again, I’m a huge nerd. I like the optimism of Star Trek. Always have. And the idea that they’ve always sort of tried to get across the idea that we will win by sticking to our values, that we have a vision that, why shouldn’t we have an egalitarian society? Why shouldn’t we have a society where material needs are not an issue anymore? I have a feeling that’s possible. Not just in the Star Trek utopian sense, but if you start thinking about where we’re going with technology and machines, things that were really expensive not very long ago are now super incredibly cheap, to the point where, once we get completely automated factories going, the costs will plummet to the point where is it even worth charging for it?

Sean [00:39:31] Well, as product managers, we’re here to make the world a better place through the products and services that we offer and that we build, so we have to be optimists.

Bruce [00:39:39] Yeah, I think that’s right. Sometimes product managers are asked to be the rational person and the adult in the room. I’ve certainly been in that situation where you’ve got other people being super optimistic. Salespeople, CEOs, and product managers have to say, “well, wait, let me break this down, we can’t do everything at once.” I think it’s about that level of imagination and optimism but combined with an ability to plan your way there and to lead a team. I think leadership is not just about articulating the why, the Simon Sinek sort of where we’re going, but also about being able to pull together the team behind the why and convince them that if we have the right plan to get there step by step, we actually can do the seemingly impossible.

Sean [00:40:28] All right, one last question for you.

Bruce [00:40:29] Yeah.

Sean [00:40:29] Define innovation for us.

Bruce [00:40:31] Define innovation, OK, that’s a tough one. Well, I mean, the simple definition is creating something that didn’t exist before, right. But I think I would narrow it a little bit further than that. It’s not really an innovation that anybody is going to remember or point at unless it turns out to be useful. And if I start to look at it through the product manager lens, the rule of thumb I always have of why someone is going to use my innovation instead of whatever it is that they use now to solve a particular problem, it’s got to not be just a little bit better. It’s got to be ten times better. It’s got to be, “oh, my God, of course, I want that as opposed to what I had before.” It’s got to be that, “I’m going to ditch my BlackBerry despite the fact that I can’t quite type very well on this touchscreen because the iPhone is just so much better as a way of getting stuff done and interacting more directly with the Internet, with software, and so on, that I’m I’m going to do that.” For me, that’s the difference, is something that makes a customer more successful, more powerful, more bada**, in some area, 10 times more than any other way before. And that comes with it a technically feasible and business-wise viable backbone. Yeah, I mean, I suppose General Magic’s device was innovative, sort of, but it died on the vine because it didn’t do enough. It wasn’t really feasible. It wasn’t really viable.

Sean [00:42:05] And the market wasn’t ready for it. It was a combination of things, right.

Bruce [00:42:05] Yeah. It was a combination thing.

Sean [00:42:10] Cool.

Paul [00:42:11] Well, Bruce, I want to thank you for the time that you took to spend with us today. I can honestly say I’m walking away inspired. You know, it’s easy to get bogged down in execution mode oftentimes as a product manager. But I think the way that you think in the way that you view the world by pushing strategy out into the roadmap and not using the roadmap as a tactical release planning tool and speaking the impact that you want to have using the product as a vehicle and really aligning people to that purpose is really something that is hard to stay in the mindset of. It’s easy to get bogged down in the weeds. But I mean it when I say I’ve been inspired listening to your view of the world and I really appreciate the chat that we’ve been able to have, and I hope our listeners will, too.

Sean [00:42:54] One more thing here, listeners, if you haven’t read the book, Product Roadmaps Relaunched, that’s largely the book we’ve been referencing throughout this pod, there’s a lot of really great tactical advice in there in terms of how to build your roadmaps, how to prioritize, how to communicate your roadmaps. Its a recommended read for any aspiring product leader, or person in general. So, again, thanks, Bruce.

Bruce [00:43:13] Awesome. Really great to talk with you guys and thanks for the opportunity to speak with your listeners.

Paul [00:43:18] Excellent. Have a great day.

Bruce [00:43:24] You bet. Thanks, guys.

Paul [00:43:24] Well, that’s it for today, in line with your goals of transparency in listening, we really want to hear from you. Sean and I are committed to reading every piece of feedback that we get. So please leave a comment or reading wherever you’re listening to this podcast. Not only does it help us continue to improve, but it also helps this show climb up the rankings so that we can help other listeners move, touch and inspire the world, just like you’re doing. Thanks, everyone. We’ll see you next episode.