Sign up to save your podcasts
Or
Share Product Roadmaps with Bruce McCarthy
Share to email
Share to Facebook
Share to X
Share to email
Share to Facebook
Share to X
Or
Product Roadmaps with Bruce McCarthy
Bruce's site:
https://productculture.org
Bruce's book:
Product Roadmaps Relaunched
The 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...
View all episodes
By George StockerBruce's site:
https://productculture.org
Bruce's book:
Product Roadmaps Relaunched
The 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...