Bruce's site:
https://productculture.org
Bruce's book:
Product Roadmaps RelaunchedThe product Scorecard:
https://walkerux.wordpress.com/2017/08/21/notes-on-bruce-mccarthys-prioritizing-product-goals/
Transcript (powered by Otter.ai; please let me know about any discrepancies!)
George Stocker
0:00 Hello, I'm George Stocker, and this is the build better software podcast. Today we're talking about product roadmaps with Bruce McCarthy. Bruce, welcome to the show.
Bruce Mccarthy
0:09 Thanks, George. Nice to be here.
George Stocker
0:11 Now for people who may not know who you are or what you do. Can you tell us a little bit about yourself and your work?
Bruce Mccarthy
0:17 Sure. The way I always introduce myself is I'm a Product guy. I've been a product manager, Chief Product officer, an engineering manager, a design manager, business development, guy marketing, sales. I've done all these different things, agile, enablement, and whatever. But I always come back to my roots as a product guy. I like building stuff. I like solving problems. I like getting the team together and working on Alright, how are we going to tackle this folks? How are we going to make things better for the customer and for the business? So I always kind of go back to that product leadership kind of role and these days For the past seven or eight years, I really been teaching and workshopping and coaching teams how to do that stuff. After a long career of being fairly successful at it myself, I felt like I had learned the ingredients and how they fit together properly. And so I do workshops, public ones that you can buy tickets to, and private ones for companies. And I have a forum for invitation only for Chief Product officers where we get together and workshop each other's challenges. And I do consulting and speaking at conferences and things like that. I also wrote a book that I think you've seen called product roadmaps relaunched, and how to set direction while embracing uncertainty came out from O'Reilly a couple years ago, and it's become kind of the standard, the standard book on product roadmapping.
George Stocker
1:58 And you brought up solving problems from customers. And I'm glad you brought that up. Because at least in my career, when I've seen product roadmaps they have, well, we need these particular features at this particular time to grow. And you know, this particular outcome, and it was laid out in a calendar fashion with exactly what features the product team needed to build and what they needed to do. How does how you view a roadmap differ from that?
Bruce Mccarthy
2:23 Well, I kind of think that that, in my mind, old fashioned view of a roadmap gets teams into trouble a lot. Number one, it gets them into trouble in terms of broken promises. They are constantly finding that their dates were over optimistic and so they're constantly feeling behind. Also, those kind of optimistic roadmaps don't take into account. stuff you got to do to keep the old things the things the features you shipped last year still working for clients and updated and free of killer p one bugs and so on. And it doesn't take into account shifting priorities because you might make up a roadmap at a point in time, say just before the sales kickoff in January of a given year. And it might go for a whole year or even longer. But your process as a product person of learning what's going on in the market doesn't stop an end there. Even if you've done a ton of research, and you think you know exactly what's right on January 10. of that year, on January 11. Someone's going to come to you with some new information. And you're going to be like, Huh, I wonder if that really should change our priorities? And maybe on January 11, you're not sure yet. But by February 10, you're probably like, Yeah, yep. You know, that thing we were thinking about for the end of the year. It no longer seems as important as this other thing that's just clearly becoming a theme among our customers, or you got to respond to competitive pressures. are new and unpredictable. So this idea of committing in advance to exactly what features we're building on what dates is kind of a doomed effort, because you're going to change your mind and you're going to find that some things take longer than you expected them to. So my approach to roadmaps is to admit that upfront, and to have a regular process of updating the roadmap every month or every quarter with the latest information, and to say upfront, this is not a commitment. In fact, our confidence in anything beyond this quarter is increasingly low. Some teams I work with actually publish a percentage of confidence on each item and the roadmap or each timeframe in the roadmap say quarters or something like that. That goes down to something like you know, four quarters out, it goes down to like, we're 20% confidence that that this is actually what we're going to be shipping at that point. time. But there's one more critical point that I really want to hit on aside from unpredictability. And that is that most roadmaps, forgetting just about the time commitments. They are, as you said, a list of features. There are a list of things we plan to ship changes we plan to make, and those commitments to features and changes and tweaks and redesigns or whatever, are made well in advance of actually opening up the code and digging into it, or testing the idea with customers or producing a design and seeing if it works. And those commitments are made really prematurely. If you've got a problem to solve and you think you've got a good idea for a feature to solve that problem for the customer, like make them more productive or, or something like that. You really can't know in advance whether That feature will effectively solve that problem or whether that feature is the best way to solve that problem. You can measure it after the fact. But what if it turns out that you were wrong? What if you ship feature x? Because you're sure that it's going to raise your conversion rate or your retention rate or something like that? And you find out, it doesn't actually do that at all, or it does it but not half as much as you need to meet your business goals. What are you going to do? You're going to go back to the drawing board and come up with another feature, or another idea. And if it's six months before you ship that, well, that's a really slow way to improve your business, right. So instead, the in the book I described a different way to approach the core content of a roadmap rather than being features. The core content tend to have a roadmap is problems, problems to solve or customer needs that are Currently unfulfilled or under fulfilled. And so, you know, you would actually put on the roadmap productivity, customer productivity or some more specific example like that like something you could measure, like increasing their output
George Stocker
7:17 conversion rate for checkout or,
Bruce Mccarthy
7:21 yeah, if it were an e commerce site, for example, that's a good example. For e commerce websites, one of their biggest bane of their existence is abandoned carts. People pick out a product, put it into their shopping cart, and then never check out. And it's hard to know why. But if let's say that was the problem you're trying to solve is low checkout rates or abandoned cart rates that are too high. Well, there are a variety of things that you might try to fix that problem. Maybe the problem is, your checkout process is too confusing. And so you might read design it. Or maybe it's too long, there's just too many steps and people get tired and they abandon partway through. Or maybe it's not the design at all, maybe you just don't accept the credit card they have in their pocket. And the real problem is you need to accept American Express as well as MasterCard and Visa, or Apple Pay or whatever. Or maybe the problem is that they don't find out about the shipping charges until late in the game, and the shipping charges are much higher than they expected. wherever they are, or maybe it it's, you know, the list goes on and on and on. And any one of those is a reasonable guess. And any one of those might have a small incremental effect on your conversion rate, your checkout rate. But rather than put all of those are some of those and try to guess ahead of time, which ones are really going to work on my roadmap. I'm just going to put increase the checkout rate or decrease the cart, abandon And then rate, and I'm going to have maybe a list of things to test. And that that list of things to test is not a commitment to features and dates. It's a commitment to solve the problem. And these are the things we're going to start trying and prototyping rather than shipping to see what actually makes a difference in simulated situations until we can figure out which of those 10 ideas that I just rattled off, maybe three of them are really highly leveraged, let's focus on them. Now, when I'm putting this item of improving the checkout rate, on the roadmap, it could be nine months before we even start the research process to figure out which of those 10 ideas is the right one. So why am I going to put any of them on the roadmap at this point? I just don't know. And it's foolish of me. It's misleading, kind of fooling myself and it's misleading my audience about my certainty about what's the right thing to do them Makes sense?
George Stocker
10:01 It does. And what jumps to mind immediately is that leadership tends to be released from leaders that I've interacted with. It tends to be about projecting confidence and projecting certainty. But it sounds like your roadmap process focuses on accepting the uncertainty of product development. How do you get leaders? And how do you get product teams? We're used to the old way to adopt this way. Now, where you say, hey, the emperor has no clothes, and everybody can see it. Everybody knows it. Yeah. How do you help teams make that change?
Bruce Mccarthy
10:37 Well, the thing that I see with with leaders is, they are used to extracting commitments from their people in order to get things done especially this is true and to a degree of executives at many, many companies, but it's particularly true at early stage companies that are founder led where they're used to To extracting commitments and what they call high integrity commitments, right? You've heard those words probably. And they really are going to hold you to those commitments because they're trying to do way too many things. They're trying to do it all on a shoestring and they're trying to bootstrap this thing. And it's generally worked for them to put the pressure on people, and you can't change that tendency to want to hold people accountable for for what they commit to in a personality like that, nor should you try because a it's doomed and B. That's what got companies from zero to one, you know, that's what got the that's what got these people into a position of authority in a company. And so let's go with that instead of trying to fight it and the way I go with that, is gradually to get there trust that I can be held accountable for results rather than Then for specific features and dates, if I can convince them that if I get asked, and this happens all the time, right, for a specific feature, and when Can I have it? I can answer the question, but then I can answer it with this is the this is the real skill of a product manager, I can answer it, answer it with another question. Okay. Yeah, we could probably do that. But tell me if we do that. What is the hoped for result? What is the desired outcome from this particular output that you're asking for? Now, sometimes, from an executive, you'll get lack of patience. I don't have time to get into it, just do it. That's not a good answer. If you get that you still want to come back and say, Well, I want to make sure that we design this thing correctly in order to meet the needs. Yeah, I know, you told me this thing. And maybe it seems fairly simple, but there's 1000 little decisions that are Gonna go into the implementation. And if I can get just even 20 minutes of clarity right now even five minutes of clarity right now on the desired result, we can make sure that we're building the thing you actually want. Okay, so you've sold me on the idea that I can spend five minutes now and explain to you that if we do this, and the customer does that, then this will result in that this other thing for the company, we think, and as you say, an executive of that type will project confidence that this will definitely work. And then your analytical brain, whether you're a product manager, or an engineering manager, or a designer should come into play, and you should see if you can start playing out alternate scenarios, not just not to poke holes in the plan, because that'll just make them defensive, but to suggest alternatives. Well, what if we could get the same result quicker and easier with x y Instead, you know what if instead of redesigning the whole checkout flow, we just added American Express or consolidated, the two slowest steps, you know, as an incremental thing as an experiment to see if that actually improves the numbers. And then you can, then what you've set up as a conversation where you are together trying to cooperate on evaluating alternative solutions to the problem. And then maybe, maybe that person's mind is opened up to the idea that there might be two or three or four or many possible solutions to the problem. And even if you can't get them to stick with you through all of that, you've set the stage that the real. The real goal is to change the customer behavior and change the financial results for the company. And if you know exactly how to manage That will then just as good practice, you go back to the drawing board, and you say to your team, okay, we've been asked to to redesign the checkout flow to increase throughput to increase conversion rate. How can we test this idea and validate whether it's actually going to get the result that we want before spending months doing the work? Can we get some users in and do some mock ups? do some tests of mock ups and stuff like that? And see, what happens? Can we build a micro site and then in a totally non scalable way and do an A B test?
and just see what happens and then when you come back to that executive and say, so that thing where you wanted us to redesign the checkout flow? Well, we tried these three different options and because we're, we're always optimizing for the conversion rate, right? And we found that this alternative, which is turns out is no different than we realize. Thought is actually the best way to increase our conversion rate. Because you had the conversation about what's the real goal, because even you had to have an uncomfortable moment where you were pushing to get clarity on the desired goal. You've set up that later conversation about what's really going to get you the desired goal. And so if you're always trying to even on the roadmap, wrap, the project stuff in the product stuff, the the the wrap the output in the desired outcome. Then gradually, you get leverage and trust in those conversations that you are thinking, like they want you to think and as a responsible steward of the resources.
George Stocker
16:54 With the roadmap, we've talked a little bit about how it's set up, and how there are outcomes on the roadmap. And what you're looking to test during here, timeframes. Is it now near and later, is it quarter? next quarter? How is that set up? And then what else is part of the roadmap that you put together?
Bruce Mccarthy
17:15 Yeah, so you got to have some kind of time buckets, even if you said it's now next and later, just really broad, no dates, kind of buckets. And you've got to have the problem oriented themes that we discussed. And you've also got a for an internal roadmap, you've got to have those business objectives like, Okay, if we do this, what does that mean for the company? And I don't mean that you need to make a sales projection, but I do mean that you need to say the objective here is to increase the conversion rate. And if we can raise it by two points, then here's what the result might be. Or maybe the objective is, for a SaaS business renewal rates. We want to improve those So you want to build those business objectives? The reason why from the, from the point of view of the people who are funding this effort, right into the roadmap, I even there's an example in the book where this company actually gave a percentage of the resources that were placed against each different business objective. so that they could sort of take a portfolio view of what they were working on. CFOs love that kind of that kind of analysis. So business objectives, problems to solve, rather than features, timeframes. And I think it's all got to start with a vision of the value that your entire effort your entire product, your entire program to produce this product is aiming for, for the customer. Maybe it incorporates a piece of the business side to like, we want to we Want to make security foolproof for enterprises? And that's a, you know, hundred billion dollar market. So we want to be the number one vendor in that space. I don't love the we want to
George Stocker
19:16 that's the big hairy audacious goal,
Bruce Mccarthy
19:19 right A B hag for the product. And I like it to focus mostly on the benefit to the customer, like making security foolproof, or providing, you know, a better, faster, easier something for the customer and a little piece of a little dash of what's our differentiator Why Why should you consider us? It's like a Actually, it's really like a boiled down version of your value proposition as a product. It names the customer, the benefit to the customer and the differentiator. That should be like at the top of the page. If you have a roadmap like many do that's a timeline or it's a grid with hopefully not features, maybe themes, products. have problems to solve and timeframes. Above all of that is. And if we achieve if we do all of these things, here's the result. Here's where we're solving for this. As the constant Northstar reminder of why we're here. Though, all of those things are four out of the five components, I think that you must have in a roadmap. The fifth one is the disclaimer. Now, maybe that sounds like a while, of course, you know, sure. You gotta have weasel words down the bottom right? You gotta have the Safe Harbor statement. But I actually really like to lean on that when I'm talking to customers in particular, but any stakeholder pointed out and say, not only is the roadmap subject to change, but it is highly likely to change. It is a constantly evolving document, it is likely to change and one of the ways that it can change is if in this discussion, you convince me of certain things that I didn't know or wasn't really Thinking about you give me new information that changes my priorities or informs my strategy. Well, why wouldn't I change my roadmap? I should, I should change as a responsible product person trying to do the best thing for the customer and the company, I need to take advantage of that new information incorporated into my plan and publish it in the next iteration of the roadmap. There's sort of a, this sort of one other piece. It's not a component of the roadmap, but it's a component of the road mapping process. And that's the update. I think a lot of people forget this, that kind of like the roadmap is the thing we do in either the end of the year or the beginning of the year. And then we forget about it until the end of the year when we have to make a new one. And we pretty much ignore the old one because we didn't do any of that. And instead, what I want is to republish an updated version of the roadmap really regularly I have a friend Sam Clemens, who was head of product at a company called insight squared in Boston for many years. And the way he did it was, it was a quarterly roadmap with percentages of percentages of confidence going out for quarters. The confidence level for the last quarter was like 25%. And he published it in a one page document that the sales team was encouraged to pin up in their cube. So that when someone asked, Is there, is it on the roadmap, they could answer the question, along with the disclaimer. But here's the thing, it was a quarterly roadmap, but he updated it every month. He sent out a fresh version of it with an annotation of all the changes and explanation of all the changes and why all those changes were made every month. And you know, a lot of some of them were things like well, this has taken longer than we thought. Others were like, We tested this idea and it doesn't work and so what We're taking it off the roadmap, and we're putting on something that we think will work based on what we learned. Or we're reprioritizing, we're taking based on signal from customers, this thing that was four quarters out, we think is far more important. And so we've moved it up to next quarter and swapped out some other things to make room for it. And when you're that sort of radically transparent about the changes to the roadmap, it I think, begins to increase confidence that you are constantly updating your thinking based on the latest evidence of what's going on, with customers and in the marketplace, and what's the best thing to be doing, and you train all of your stakeholders to expect it. It's not, oh, the roadmap changed what went wrong. It's like, Oh, great, updated version of the roadmap. This is awesome.
George Stocker
23:51 So that brings to when the roadmap changes in an established marketplace, there are competitors and then those competitors have features, how do you guard against, we have to have this feature because our competitor has this feature.
Bruce Mccarthy
24:07 Right? Um, honestly, the fastest way to commoditizing your product and losing all of your margin is a feature war. You don't want to get into that situation where it's just me to feature after me to feature. That way, all the products eventually become the same, and there's no differentiation and the only thing you have less left to compete on is price. And that's where all your margin disappears. So why would you want to get into that situation? You wouldn't. So instead, what you want to do is figure out how you differentiate how you have something that a nobody else has, and B is difficult for them to duplicate so that they can't have it next quarter. And C is something that speaks to particularly to your segment of the market. So, if you if you want to have a red ocean strategy, referencing that book where you and a couple of other behemoths are just slugging it out continuously over the same customer, then Okay, you're stuck in a feature war and eventually a price war. And honestly, that that kind of that kind of situation is no fun. Instead, you can carve out a niche. Maybe it's big, maybe it's small, but one that you are uniquely able to serve and where you are the obvious answer to the customer's unique problem. You know, amazon.com is the answer to most commodity purchases right now if they're not super perishable, right? So why am I am I going to try to compete compete with them on selling books or going into the video streaming business? No, I'm not going to do that. But There are lots of products where Yeah, they sell them. But they aren't the best way to get the best version of that product out of them could could they get into the selling business of selling cars? Well, they could. But I'm not sure they'd be very successful because people want to touch and feel and test drive a car first. So that's not going to be a real great way to compete. I'll give you another example. Much more recent. Did you see that the guys that Basecamp came out with a new product called Hey, I did it's a, it's an email service. And you think, Oh my god, they're gonna try to compete with Gmail and outlook. That's crazy. Why would anybody do that? Those guys are enormous. But those products are commodities and they're mostly interchangeable and they're mostly free. Hey, has a subscription price and not a cheap one. It's like 30 bucks. A month. So it's a premium subscription price for a consumer to pay for themselves. How does that make any sense? Well, they're not expecting to have the number of users that Gmail has. And they're not expecting to have the profile of the typical Gmail user. They're expecting to have somebody who is very addicted to email but wants to be super productive on it. And who buys into their very opinionated way that we should manage our workflow. If you really like the way Hayes workflow works, it's the only tool of its type. And so it's the only option for you they have in that sense for that particular user, if they can identify them, they have no competition at all. There's another there's a sort of competitor called superhuman, which you may also have heard of, that's also a subscription based email client, but
George Stocker
27:59 they work on top of Gmail don't think they did or not their own email provider.
Bruce Mccarthy
28:03 That's right, hey, actually, because they wanted to really take control of the whole stack and the whole experience, you would get a Hey, calm email address, whereas with superhuman, it's whatever email address you have on top of Gmail. And so they just exist at that layer. And they're strictly about throughput and focus in the interface, whereas hay is much more about filtering out noise, and bucketing things in a very, very opinionated way that they think is the right way to do it. You know how you can set up rules in Gmail to put things into folders? And at some point, every nerd like spends all day one day making all these little folders and rules and stuff like that. I know I did. But, hey, doesn't allow you to do that. They just have three buckets. Well, four if you count the no you can't email me bucket. And you can't configure them. So you either love it, in which case, it's very low effort for you, or it doesn't fit. And you're going to go check out to superhuman, or you're going to go back to Gmail,
George Stocker
29:11 in the case of superhuman versus Hey, since superhuman exists on top of Gmail, they're dependent upon Gmail for their livelihood at gmail subsequently could copy their features tomorrow, but they could copy their features and they could send them out of business. Whereas Hey, it sounds like a tougher proposition for any competitor.
Bruce Mccarthy
29:30 Exactly right. Gmail could copy their features. It could also turn off their API or their forwarding or whatever it is that superhuman uses. And then superhuman would be out of business overnight.
George Stocker
29:45 Now, in my time on a product team, I've generally dealt with three or four interest groups in any product or product management folks, the sales folks versus the engineering team. Then of course, you've got the board of directors, you have upper management, and they all have different things that we're worried about. Engineering groups are worried about keeping the lights on and making sure things can actually be done. The sales group needs to meet their quotas. Upper management's looking at the health of the company writ large, and products is sitting there trying to hold it all together. Now, if there's just one group that had to adopt change for roadmaps, that would be tough enough. Now you've got four groups you're dealing with, when you're introducing your process into an organization.
Bruce Mccarthy
30:25 Oh, and it's worse than that. A lot of organizations, they also have marketing and partnerships and channel sales. And maybe they have to deal with external analysts and technology partners. And maybe they have enterprise customers who are used to having input on the roadmap, the list goes on and on and on. Finance also usually has a voice and in the roadmap, the list of potential stakeholders is quite lengthy. And there's a there's a big challenge. There, I find that the way to approach that is a couple of things. One is, at the highest level, at the simplest level, everybody should be hearing the same story about how this all fits together and how we all succeed together, everybody should understand the product vision that we described how a future world will benefit from the existence of this product or the success of this product, and how it serves the overall company mission. If those are different if it's a big enough company to have multiple products. Everybody should understand what problems are we trying to solve in order to achieve that what business results should we expect if we do achieve that? And that the timeframes and the disclaimer so the first you know, few slides of your PowerPoint presentation, if that's the form your roadmap is in should be the same for absolutely everybody. You don't want to have 14 different roadmap For all your different stakeholders, but within that deck, each different stakeholder like that kind of wants their own drill down into their own worries into their own concerns. So sales wants to know when am I going to be able to sell XYZ. And so for things that are close enough to delivery that you actually can give them a feature and a date, you should have that information, either in a delivery plan or on slide number four. And for engineering that wants a deeper dive into the features that are not yet being worked on, but are maybe on deck, if you will, up next. You should have a slide for what are the possible features under each theme that you'd like to discuss and go through the investigation and research process with engineering on but you don't show those that slide to anybody outside of that. Engineering, because it's all completely unbaked. At that point for, for investors, you know, you might have not revenue projections, but hope we might focus on the business objectives for the marketing team you might talk about, well, what sorts of things might you be able to demo at the next conference? Or should they be ramping up a campaign for in the fall or something like that. So for each one, you can imagine a deck that starts off with the same three slides for everybody that tells the high level story and then has seven or eight more slides one or two for each other stakeholder group, that give them just the information that they need. And then just having a roadmap is not enough. You've actually got to involve all those stakeholders in your process. If you want the buy in that you're looking for. You've actually got to go to talk to those stakeholders, not when you're done with the roadmap. But when you're in the beginning to middle stages of developing it, so that my favorite words are, hey, I'm working on my roadmap, and I need your input. Can you help me and being asked to help and give input early in the process is super flattering for those folks. And it makes them feel like they got inside access, and it makes them feel like they're helping you and you're helping them and you're collaborating on this. And even if you say no to them on some things, they feel like you gave them the opportunity to be heard at the right time and place. And so they end up feeling a sort of a sense of authorship, co authorship of the result. And I would do that as informally as you can don't like schedule a meeting and have a review of the roadmap and ask for their sign off. If if you're in an office with them, hang out at the coffee machine. Wait till they come by and say Hey, you got a minute, I want to I just, I'm working on this and I need your need your help. If you can't do that, slack them and ask them for five minutes, you know, and rather than
rather than try to make it super formal. And then when you do have the formal meeting where it's like the roadmap review, instead of them, like, trying to show how smart they are, but poking holes in a roadmap, they're trying to take credit for how great and insightful the roadmap is, because they see their fingerprints on it.
George Stocker
35:32 Now I had the privilege to be a part of one of your sessions. I don't remember if it was a two or three day roadmap engagement, where you came in to help us develop a roadmap at a previous employer. But for everyone who is not aware of what this process is, like, if a team wanted to call you in and say, Hey, Bruce, could you help us out? We need to produce a roadmap. What is your engagement look like?
Bruce Mccarthy
35:52 Well, first I do public roadmap workshops that are these four sort of four days have to Our sessions, but then we, we have people from all different companies and we use a made up product. And we put them in teams and I deliberately, even if there are multiple people from one company, I deliberately split them up, put them into teams, and we have a lot of fun with it that way. But if I'm, if I'm on the occasion that I'm working with a single company, and they're trying to produce their real roadmap, it takes a little longer. And so it's usually a several days process. And we get the key stakeholders into a room for several days, we get the folks from sales, we get the folks from engineering, we get the folks from marketing, maybe design as well as product, sometimes in the right size company will have the CEO in the room the whole time, or for strategic parts of it. And the whole idea is to get us all on the same page about those major components. What is the vision What does success look like? What are the business objectives? What problems do we need to solve? How do we prioritize this stuff? You remember from our engagement, we were like all writing lots of white yellow stickies, putting them on a wall, and arranging them seeing where the common themes played out and debating the priority of things based on how leveraged we thought they would be for the results we were trying to get. One particular technique that I like, in that kind of workshopping situation, is to sort of crowdsource the ideas and not let any one voice really dominate the conversation. Because often there's, you know, a few people who have very verbally dominant sort of behavior, you know, often they're in sales or they're the CEO or something like that. And then there's other people may be an engineering or design who are more thoughtful and introspective and they won't just blurt out The first thing that they're thinking, so to level that playing field, so that we get all those ideas on the table, because all of them are useful is I have people first write stuff down silently without talking to each other, so that we get everything on the table without anybody getting shouted down. Then we put all put all those stickies together. And we we look at them together without anybody's name on anything. And that tends to get a better result that sometimes you'll be like. Like, you'll have two or three stickies of ideas of how to solve a problem that at first blush, to maybe the to the CEO, or the head of sales makes zero sense. They seem to be coming completely out of left field. But then when you ask for an explanation, you discover that there's a really clever idea there that nobody else thought of, and that one bounced off of some of the other ideas. begins to really become a promising direction. And those nuggets aren't going to happen. If you don't, if you don't crowdsource like that.
George Stocker
39:08 We've talked a lot about product teams. And your advice seems especially centered towards product teams, what can non product software teams that maybe work on internal software, or teams that work in services based business with software? What can they take away from your process?
Bruce Mccarthy
39:25 I think a lot of these principles, although they were developed with software product teams apply broadly across businesses. I'll give you an example. I did a version of this workshop, a half day version of this workshop for a company in New Zealand, and it was just for their for their marketing team really, but they got all termed up about the method of thinking about the objectives and the desired outcomes rather than the solutions or at least before thinking about the solutions. And they brought me in to run their corporate planning process for their next annual planning process, that way to run it completely based on desired outcomes rather than outputs. And they ended up organizing and budgeting for the entire year this way. This was an electric power utility. This was not a software company, not a hardware company, not a consumer goods company, nothing like software. And yet they found that the principles really applied there. So I mean, if you think about it, there's the What's our vision? What are we trying to do that benefits the customer? What are the measurable business objectives that we need to meet? What are the problems we need to solve along the way? What are the critical timeframes in those are all universal business considerations? The one exception people might think be tempted to make is for internal teams like you said. But I don't think that's a real distinction because even though your product isn't sold to some external customer, it is used by internal customers for some reason, it is providing some kind of value to whoever is using the product, even if it's like a back end system that supports another product. Still, there are outcomes that are desired from doing any work to change or create in the first place that system. And if you can describe those desired outcomes, you can get a much more reliable result in terms of achieving them. Just because you frame the problem correctly. Does that make sense?
George Stocker
41:50 It does. Now there's one thing I want to talk about because it was revolutionary when I read the book. In the book, you talk about a way to prioritize work and you come up with a formula and it's scorecard that can prioritize work. Can you talk about that?
Bruce Mccarthy
42:03 Yeah. For me this, this comes from going back to what's the desired result. I always ended up with a list of way too many good ideas, especially through this kind of brainstorming process that I described. And all of them seemed like things that we should do. But we couldn't get even half of them done in any period of time. Like I, I started at this company, and went around to all the executives and asked them, What projects they thought we either should be working on this year, or maybe already we're working on this year. And the list was 75 items long. And we only had five developers. And some of these things were really chunky big things. And so it seemed to me like yeah, we could maybe get two or three of these 75 things done. How We pick. So over time, I've developed this method of scoring these things to decide which things are the winners. And the basic idea behind it is that you should score things based on the likelihood of getting a positive result with the least amount of effort, you should score them on ROI on bang for the buck, right? If, but you can only do that. If you agree on what the bang you're looking for is, you can only do that if you agree on what your business objectives are at that particular company. Fortunately, we have just gone for a round of investment and we knew exactly what the the business objectives we had sold to the board and the investors were so I was able to fill them into my scorecard at the top and rank every single idea as to how much I thought it would contribute to those objectives. Each each objective separately was given a score for each item And then added up. And then divided by a couple of other things. One was effort, our rough guess as to how hard a problem this was to solve. And then also confidence. Sometimes, two ideas look roughly similar in bang for the buck, but you just have a lot more knowledge about one of them than the other about whether about how to solve the problem, or about whether the customer will really get value out of it. And it will really drive the business results you think it should. And so that confidence becomes your fudge factor and you're your decider in those kinds of ties. And the confidence comes from basically your confidence that your scoring is correct that it will really work out that way in the real world. On the other hand, sometimes also you run into things that look really good before you put the confidence factor in. This should be really And I'll bet the customers will really love it. Awesome. It's at the top of the list. Except, well, we've never done anything like this before. So we don't really know what's involved. And it's kind of different than our usual value proposition to the customer. So we don't really know if they'll like it until we try it. So now you put the confidence of only like 30% in and it falls way down on the list. But that's just telling you not it's a bad idea, but that you need to do your homework, you need to go and actually do a design project or a research spike, or something that's going to get your confidence up where it should be before you attempt it. So I I love the scorecard method as a way of breaking those log jams and also of managing your stakeholders. Because if you This is the other thing I did at that same company, if you all agree on what the goals are, and you kind of go through and discuss your scoring on All the things even if you don't 100% agree on everything, what you're doing is you are unpacking the prioritization logic for all the stakeholders in exactly the same way and then a logical framework that they all agree on and buy into. And so it's very easy to bring a bunch of people who don't usually agree to alignment, if you can get them to go through this process with you.
George Stocker
46:23 Nice. Now, where can people go to learn more about you and to get in touch with you?
Bruce Mccarthy
46:28 Thanks for asking. My website is product culture.org. Because I believe that these things that we're talking about sort of come down to a culture of focusing on the product discipline of making customers successful and how that makes the company successful. on there, you'll find info about my book, product roadmaps, relaunched and a link to Amazon and I also have a weekly what I call it nano letter which is called one thing on product culture, and it's really short. It's meant to be read, you know, like while you're making coffee or the coffee line. It's just one thing on product culture each week. And you can also sign up for my public workshops on the website.
George Stocker
47:14 Wonderful papers. Thanks for joining me today.
Bruce Mccarthy
47:17 Thanks for having me, George. It was great talking about this stuff.
George Stocker
47:20 It was and we could talk about it for hours, but unfortunately, our listeners won't listen for that long. Alright folks, that's it for this week. I'm George Stocker, and I hope you'll join me next time on the build better software podcast.
Transcribed by https://otter.ai