[On Demand] Product Management Webinar: Moving to Lean Roadmaps

[00:00:00] Megan Saker: Hi, everyone. Welcome to the ProdPad webinar. welcome to our webinar, “How to get your company to move to a lean roadmap,” with, Bruce McCarthy. Let me bring up our slides. Can everyone see those? Good, thumbs up. Okay, so yeah, to kick us off, let me just explain, unfortunately your usual host, Janna Bastow, CEO and cofounder of ProdPad, has an emergency, she can’t be here. But as I say, don’t log off, it’s fine. I am Megan, hello. I am the CMO here at ProdPad, and I’m joined cohosting by Kirstie, who is our head of product.

[00:00:40] Hey, everyone.

[00:00:40] So you’re in safe hands, two for the price of one. so we’re going to, kick off just with a bit of housekeeping. we will make sure that at the end we allow time for, a Q&A. So please use the question and answer box to submit any questions, you could add them while you think of them and we’ll come to them at the end. If a question is particularly pertinent to what we’re talking about, we’ll go ahead and jump in, and ask Bruce. just before I introduce Bruce, to give you, a bit of, background on ProdPad. So hopefully a lot of you will know ProdPad, will be customers. But for those of you who don’t know ProdPad is a product management tool, a complete source of truth for all of your product work. The platform combines, customer feedback gathering and analyzing, alongside roadmapping and your backlog management. ProdPad was invented by, Janna Bastow and Simon Cast, as a solution to the problems they were facing product people, as product managers. both the problems inherent in dealing with traditional sort of timeline roadmapping process, and just generally organizing their work. They wanted one platform, one single source of truth, they built ProdPad, and now it is used by thousands of product teams across the world.

[00:02:07] If it’s been a while since you have been in ProdPad or looked, I would, urge you to. There’s a whole bunch of new AI capabilities that are, really setting the bar, in terms of product management tools. and one of the things that I just wanted to flag is, is new sort of opportunity within ProdPad, to clear out an existing backlog. Let’s say you are running a backlog in something like Jira software and Trello is your devops. Those are project management tools, and you can get in a big old mess over there. What you’re able to do now with ProdPad is import very easily, a couple of clicks, import your backlog and then run our AI tools to help you, clean out the crap, help you dedupe. Also, you’ll get, advice, and suggestions on how to improve the content, improve alignment. and so a great backlog cleaner for the new year to, sort out, all your troubles. So that’s us, that’s ProdPad. Let me now introduce Bruce. So we’re thrilled to have Bruce here, Bruce McCarthy, as you all know, is an experienced product and indeed thought leader. He’s known for his expertise in product roadmaps, stakeholder management, team dynamics, he’s the coauthor of Product Roadmaps Relaunched, which is a book we love at ProdPad. He is the president emeritus of the Boston Product Management Association and also a head judge at the annual Harvard Business School New Venture Competition. And importantly, Bruce runs an organization called Product Culture that’s helping companies to achieve their product vision through advising, running forums, workshops private coaching. all of which makes Bruce, the perfect expert to help us tackle this topic and how to move to, lean roadmaps. So hello, Bruce, thanks very much for being with us today.

[00:04:02] Bruce McCarthy: No, thanks for having me. Always keen to talk about this sort of thing.

[00:04:07] Megan Saker: Great. what would be, great to kick off with is, for you to share more about yourself and to help us understand what your journey into product management was, and then what motivated you to specialize in roadmaps in particular.

[00:04:23] Bruce McCarthy: Yeah, it’s a good question. I feel like I played a lot of roles in, even just within being a product person. But I think my title has had the word product in it in one form or another for decades but, in practice I was officially or unofficially also in charge of engineering, agile enablement, partnerships, UX, marketing, business development, you name it. And it’s because product tends to be this very horizontal role, where you’re, not in charge of anything, but you are responsible for everything. If it’s required to make your product successful, you’ve got to know about it, you’ve got to have a hand in it. And you might, if nobody else is doing it, need to just do it yourself and roll up your sleeves. And so, that’s how that happened.

[00:05:12] And I, I feel like my journey to becoming a product person happened the same way. I didn’t, Janna tells the story about how someone said to her once, “Oh, you should be a product manager.” And she said, “That sounds good. What’s that?” And my journey is, was similar. I had been a marketing person and a sales person and, had developed software and done a bunch of different things. And I’d done a startup, where again I had to wear all the different hats. And when that, like many startups, crashed and burned, I started looking for a job and I applied for a job in a software company for product manager. And I didn’t know what the job was, I thought it was some sort of marketing job. But they saw that I had checked a lot of boxes of very related things. And they thought, he might not really know what the job is, but I’ll bet he can do it if he’s been an entrepreneur, if he’s developed software, if he’s done marketing, if he’s done sales, if he’s done all these things.” And that turned out to be true. Didn’t take me long to figure out that this was the best job ever as far as I was concerned. That, although I had no power, I had a lot of influence. Although I had no, one responsibility, I h- needed to do a synthesis job on all the responsibilities. And that’s my favorite thing to do. Is to look for the patterns, figure out the strategy, and figure out the path forward, and get everybody excited about the direction. So I hope that answers your question.

[00:06:42] It

[00:06:43] Megan Saker: absolutely does, it absolutely does. and look, I know you consult with businesses, extensively about the whole product management process. But what is it about roadmaps that, what led you to write your book, for example, on roadmaps and focus in on that?

[00:06:57] Bruce McCarthy: Yeah. it’s an extension of what I was just saying, is that’s where it all comes together.

[00:07:02] A roadmap, if it was just a list of, what we’re shipping and when we’re shipping it, that’s not even a roadmap in my mind. That’s just a project plan, it’s just a delivery plan. And sure, that needs to be in there somewhere. You need that. But that’s the last thing you put together after you’ve done all that integrative, all that synthesis work to decide, “Who is our customer? , How are we going to solve their problems? How are we going to differentiate ourselves from the competition and win that customer over and keep them? Where are we gonna play, how are we gonna win? And once you’ve done that strategy work, all of that needs to be expressed in your roadmap. so to my mind, a roadmap is that thing that everybody hates to do, but if they do it right, unlocks so much for everybody else in the organization. Makes everything really clear, and then people can connect their job or their project or their feature to the big picture through the roadmap. There’s another piece as an advisor, as a consultant I find roadmaps to be really helpful to diagnose what ails a company. If, I can look at their current roadmap or I can walk them through a process of developing a roadmap, I can find out, “Oh, they have no customer discovery process. Oh, they have no business objectives to guide them. Oh, they have no product vision about where they’re headed for.” All of these holes become really visible when you try to do a roadmap right. And so I started down the path of describing what a good roadmap looks like because I saw that it often wasn’t happening, that people were mistaking a delivery plan for a roadmap. And I kept with it because it’s been such a great tool for, A, communication when it’s going or B, diagnosis when it’s not.

[00:08:59] Kirsty Kearney-Greig: Nice, thank you. I think that leads us really nicely into the next part of this, in terms of what a good roadmap looks like. The title of this talk is like, How to move to a lean Roadmap. And I think, and the principles of what that is. Would be curious if you could maybe outline what for you are those key principles of a lean roadmap and how that differs from …

[00:09:22] … traditional roadmap approaches that are maybe more that delivery plan …

[00:09:25] That’s right.

[00:09:25] … that people are 

[00:09:25] Bruce McCarthy: quite used to. In my mind, and my definition might be different than anybody else’s, a lean roadmap is synonymous with, a thematic roadmap, a, problem oriented roadmap, an outcomes roadmap. These are all terms that kind of all are pointing at the essence of a good roadmap as a statement of strategy and direction, rather than as a schedule. So therefore it needs to include a few key elements. It needs to include a destination. It’s a roadmap to what? It needs to include some sort of product vision or mission or both. Some sort of “this is the future world we want to create, the value we want to bring to the world that will reflect back well on us and make our company successful.”

[00:10:15] And it, that needs to be not so much internally focused as customer focused, as market focused. The statement in my mind, the product vision is not, “We’re gonna become the number one,” something, or, “We’re gonna build this precise thing and here are the specs.” Product vision is the change we want to make in the world for the customer. It’s, the customer is gonna go from wasting hours on X, Y, Z to, the customer is going to be able to press a button and have it done for them. Huge benefit in that in terms of time savings or quality or something like that. So it’s got to start with that destination in mind.

[00:10:56] Second, it’s got to list the problems or obstacles or challenges or jobs that need done in order to reach that, or at least the first few of those problems or steps along the path toward achieving that vision. So if my product is a big time-saving product, what are the things that are sucking up the time? Let’s list them out, let’s try to solve them. This is where people get bogged down and they say, “Okay, I need a solution for every one of those problems, and that goes on the roadmap, right?” Wrong. You might have some solutions in mind, but a lean roadmap, an outcomes roadmap, lists the problem without getting stuck in the solution or the feature, so that you retain the flexibility to find the best solution for the problem for that customer. So that you give yourself the time and space to experiment and say, “we could do this or we could do that. Let’s try them both and see which one’s better. Or let’s try them in sequence and see which one solves the problem enough that we can move on to something else more important.” That freedom, I want to come back to this theme, that freedom and that inherent uncertainty in what is the right solution is where most of the friction comes in with the rest of the organization, with the other stakeholders that are looking for certainty. But then there is one other critical piece, component, I think, to a good roadmap. And that is the outcomes you’re looking for. If you’ve got that vision of a happy customer in the future someday and you know what problems you need to solve to achieve it, you also need to survive as a business between now and then. You need to make money along the way, enough to keep going. So therefore you need some business objectives to inform your roadmap and to help you prioritize, if we solve these two problems, they’re approximately of equal importance to the customer. Which one of them will drive our revenue or our conversion or our margin better faster? Let’s pick that one first and then we’ll solve the other one.”

[00:13:07] There’s another nuance we could get into too, which is, very often those business objectives, if you just go and you ask your business partners, your CEO, your head of sales, your finance person, they will say, “Okay, yes, business problems. Revenue, margin, conversion rate,” key things like that. And those are right, but they’re a little bit hard to attach a feature to, or even a problem to. How do we know that if we solve X, Y, Z problem or set of problems for the customer, that will automatically turn into revenue? We don’t know that. And we can’t know that until we build it and ship it and see if people buy it. So there is an art to creating product objectives that correlate to those business objectives but are easier to test and easier to manage to down at the, “What work are we doing on the product in order to try to move those numbers?”

[00:14:02] They usually come down to things like engagement and usage, or free to paid conversion. Things that move faster and are more in control of the product team, than revenue or even something like renewal rate, which could take a year to play out.

[00:14:19] There are a few other things, but those three components form the sort of essential triad, I think. I also like having a disclaimer in, and I’m a big fan of the, “Now- Next- Later” timeframe or other looser timeframes rather than, we’re shipping this feature on March 15th.

[00:14:39] Yeah, 

[00:14:39] Kirsty Kearney-Greig: I’m, also a big fan of that. I think that’s probably a whole, another subject we could get into a bit later down the line, but I think there’s a lot of, myths around the fact that if you’re working in a lean or outcome roadmap based way, there can’t be any date associated whatsoever. 

[00:14:54] Bruce McCarthy: That’s right. There are times and places where dates are the right thing to do. You’ve got compliance, there’s a date at which a new regulation, like a few years ago there was GDPR. We all need to comply by that date, and so it makes sense to have that date on the roadmap as a constraint. “You know what, we need to demo something at a conference in six months, so we need to be able to, if not release, at least announce a demo of that thing.” Or you, found yourself in the situation as a enterprise sales, led organization where you signed a contract with a customer and you can’t recognize the revenue until you deliver. So not my favorite scenario, but it’s a real scenario, and you’ve got to account for that.

[00:15:37] That’s the other thing, 

[00:15:37] Kirsty Kearney-Greig: Accountability is a big thing, I think, that people have a misconception that if you don’t have dates you don’t have accountability. But I think with lean roadmapping there’s other ways you can have accountability, right?

[00:15:48] Bruce McCarthy: I think that’s right. Sometimes it’s the date. But I would rather more frequently hold the product team accountable to results.

[00:15:58] Exactly.

[00:15:59] To outcomes rather than simply outputs. 

[00:16:03] Kirsty Kearney-Greig: Definitely, I’d agree with that. I think one of the things you said there, which I’m also a big believer in, is like the lean roadmap gives you that kind of flexibility. And part of that is to help you make better decisions as part of your product process, right? Like why for you do you think this is like the better way to work, as opposed to that kind of timeline out 

[00:16:21] Bruce McCarthy: based? It would be quite possible, and I’ve certainly seen these things happen to get so obsessed with the date that it doesn’t matter whether or not the thing you’re shipping actually matters to the customer or makes a difference in your business. I’ll tell you a story. I worked in an enterprise software company, and we had a release schedule for the entire suite to be released at once, on a certain date. And some months ahead of that date, my program manager came to me and said, “Okay, right now based on the work we have ahead of us, I can project that if we don’t make some cuts in what we plan to release on that date, we will be late. We can’t get all this work done in the time.” The program manager, he had a list of, things he suggested that we consider cutting that would get us back on track to ship with the rest of the suite.

[00:17:22] Now, I wasn’t super surprised by this because we were really redoing this product from scratch that was one of the products in the suite. We were recasting it for a new value proposition for a new buyer. So, that’s a lot of work and I had been ambitious. And “okay, we’re gonna have to cut some stuff.” Normal product manager stuff. One of the features though, on his list of cuts was, core to the value proposition to the new customer, to the revised value proposition of the new version of the product. And if we cut it, my strong feeling based on all the research I had done with customers was that no one would buy it. That there would be no reason for us, for someone to move from the old product to the new product, to the new version of it. Because we hadn’t fulfilled the core value prop at that point.

[00:18:13] And so I said, “I can’t cut this.” And he said, that’s a big chunk. If we don’t cut this, none of the other stuff really matters. We’re gonna be late. We can’t ship on time.” And I said, “Okay, we’re gonna be late.” And he said, “No, we can’t do that. That’s my job, is to make sure we ship on time.” And I said, my job is to make sure we ship something valuable, and this will not be valuable. It will be unsuccessful.” And he said I can’t support that.” So we had to go to our mutual boss, the effectively the seat. “Okay, you’re gonna be late, because I see why we need to wait for the value to be realized.” And that’s the difference between those two approaches to roadmapping, is, are we shipping stuff or are we making a difference for the customer and for the business?

[00:19:02] I think sometimes people feel like that’s stepping outside the bounds of product. To consider the value or the saleability or the rest of it. Because after all, we have a sales team who’s supposed to get customers to buy stuff. We have a marketing team that’s supposed to get stuff promoted in the marketplace. We have a support team that’s supposed to help customers implement and use whatever you make. All that is their job. But our job is product management, not project management. Our job is making the product successful. And if we can’t ship the stuff that will allow the sales team to successfully sell it, we haven’t done our job.

[00:19:45] That’s my feeling on these, actually.

[00:19:46] Megan Saker: Yeah. That’s really interesting. I think it also leads on to, the realities there of, stakeholder management around moving away from a timeline approach, where it’s feature, date, feature, date, and more to a lean approach where you are articulating a problem to solve. And then within that you have, it’s particularly stakeholders in terms of leadership execs. At ProdPad certainly personally, when I’m at conferences and events and I’m speaking to product people, I’m talking about lean roadmapping, I’m talking about now, next, later specifically, there’s a lot of, “I absolutely get it. I understand it’s more efficient, I understand that’s how we deliver value. But it’s just like pulling teeth. How on earth do I convince stakeholders?”

[00:20:33] Indeed, actually, what are the other challenges as well as that stakeholder management, when you’re looking at 

[00:20:38] Bruce McCarthy: transitioning? One big challenge is coordination, right? If nobody knows what’s coming when, and this is the, I think the picture of a lot of people outside of product when we say we want to have a lean roadmap, they say, “So features will just appear one day and we won’t know what’s coming and we can’t plan for it and we can’t train for it and we can’t, get ready for it?” I’ve been in lots of situations where a CEO or another executive says, “I demand a date because I want to rally the whole company around the release. I want to plan for a big splashy, webinar series, I want to plan, we need to train the sales team, the support team needs to be ready for it. We need everything in place for a proper launch, so we need to commit to a date well in advance.” And that’s logical, that makes sense.

[00:21:30] And once in a while, when you know what the solution is, it makes sense to say, “All right, let’s pick a date whe- and we’ll move heaven and earth to hit that date. We’ll give ourselves a little bit of room for whatever remaining uncertainty there is. But it’s critical when you’re, in that situation that you don’t bite off too much uncertainty. Businesses, my friend Matt Kaplan, who’s the VP of product for Toast here in Boston, says “businesses crave certainty”.

[00:22:02] Yeah.

[00:22:03] And yet we in product are constantly dealing with tons of uncertainty. We don’t really know how long it’s gonna take. Every bit of software that’s ever been written is the first time that software has been written, and things go wrong or take longer than you think. We are also dealing with the uncertainty of ” Are we solving the right problem and will our planned solution solve it well enough? Will the customer even care?” None of these things are certain until they actually have the opportunity to buy and use whatever you’ve come up with. So you need a process of reducing that uncertainty enough to the point where you can make what Marty Cagan would call a high integrity commitment. And that involves discovery process, that involves discovering the problems the customer cares about, discovering, what a good solution looks like. And it may involve prototyping, testing a bunch of things along the way.

[00:23:01] And if you imagine a process that plays out over months of doing discovery and prototyping and testing and validation, you’re gradually reducing the cone of uncertainty to the point where you can say, “Yes, I can give you an 80% good commitment for a date. And if you need it to be a 100 percent, then, let’s move it out another month or two and then I can guarantee it.” Or if we can be a little bit flexible on the scope, like I can deliver most of what we have in mind, and the rest of it in a follow-up release. But that most stuff is good enough for the early adopters. …

[00:23:35] Sorry, Bruce, carry on. 

[00:23:38] Bruce McCarthy: I just wanted to bring it back to the craving for certainty about a date that businesses have, because of that cross-functional coordination, aspect. And I want to say eventually you do need to tell people a date. Features should not just appear one day with no one in the company knowing about it other than you and your team. But that does, that’s not the same thing as black and white, “Okay, we’re gonna put dates on the roadmap out for 12 or 24 months.” And it’s also not the same thing as, I worked with this one company where the product team tried hard to put into place an extended process of discovery, validation, testing, and then development. But at the beginning of every quarter the CEO just said, “No, I need this feature and this feature. How soon can we have them?”

[00:24:27] And that disrupted the entire process, and everything took about a quarter to get done because they would cram as much– they would say, “Okay,” and cram as much as they could into the release. That didn’t work very well. Those, last-minute demands, tended to not be well thought out and not be well validated. And so they frequently flopped in the marketplace, as a result. 

[00:24:52] So the other thing that’s important to do is to bring your stakeholders into your [inaudible 00:32:07] and testing and validation process, and talk to them explicitly about where in that process new ideas about either problems or solutions fit. Does that make sense?

[00:25:07] Megan Saker: Yeah, absolutely. And that’s really interesting, because yeah, when you would … I often wonder the extent to which execs, leaders are creating certainty control, right? The sort of belief that– you mentioned that exec who was like, “We need this feature, we need this feature.” And it feels to me like it’s very important to build trust in your process and your ability to understand the customer, how you drive value. And like you say, take them on that journey. Would you say that in terms of convincing stakeholders, once you have explained, “Look, time, it’s a misconception that you can’t represent time on a lean roadmap. You can.

[00:25:47] But also to explain the wider process, the discovery process, to help build that trust, that “Let us explore how we solve this 

[00:25:57] Bruce McCarthy: problem.”

[00:25:59] I think that building that trust is important. Because the people don’t appreciate all the under the waterline. It is sufficient to simply tell them about it. Because they’ll just be like, “Oh, I don’t care about your process. And besides, I thought you were supposed to be agile? That sounds like a lot of work. Too many moving parts, too much planning. Look, just do it, okay?” What instead I think is effective is to bring your stakeholders into your discovery process, tests. Take them on site visits and have them watch and listen while you ask your five levels of why questions. And then at the end of that interview, you’re chatting with your stakeholder and you’re talking not about, what I’m doing or what you’re doing, but what we observed from the customer together and what we learned, and how that informs what we might or might not do.

[00:26:55] If they begin to realize by experiencing it themselves that what seems like a good feature idea is not necessarily a slam dunk until you have seen it through the eyes of the customer, they’ll have a little more patience for your process. That’s been my experience. The same goes for the customers themselves. So sometimes, we talked about the scenario where a customer demands that you put something on the roadmap in order to sign a contract.

[00:27:22] And they want to know the date, naturally, and they want you to commit to the date. Because they feel like that’s their lever. and if you’re dealing on the customer side with someone who is a project manager who needs to implement your product once it is available on their end, they’re not gonna have a lot of patience for much beyond that. Few is the real consumer of the product that wants a good solution, not just a done solution, and bring them into your process, they’re gonna have a lot more patience for, “We want to get this right for you.” Rather than, we just want it done. That’s been my experience. I had I was talking to someone about, “Hey, you want to bring the customer into your process?” When they ask you to commit to a feature, you want to say, “we’re considering several ways to solve the problem,’ and try to engage them in a conversation about what’s the better way?”

[00:28:11] They said, “Yeah, I tried that and the customer said to me, ‘Look, I have already done all of that work. Here’s the spec. Just do it, okay?'” And the person was a business analyst/project manager who just wanted it done. But in my mind they weren’t talking to the right person on the customer side. They weren’t talking to the person who really cares about what the problem is and whether it is solved to the best effect. I think that’s, again, stakeholder management. Getting beyond the request to the real needs requires you to connect with the right person and have the right conversation with them. Your customer project manager, when faced with a vice president who really needs this problem solved, and answers that they didn’t expect coming from questions that you asked, will become more cooperative in that situation.

[00:29:06] Megan Saker: And then aside from the stakeholder management and, winning buy-in for the approach across other teams, what are the sort of other practical challenges that product teams have when they’re moving to a lean roadmapping approach? 

[00:29:23] Bruce McCarthy: Even internally I think there’s uncertainty about what we’re building, right? There’s the challenge of dual track development of, “We, want to be doing discovery, we want to be doing validation,” and that’s keeping the product team busy, and yet people talk about feeding the beast of the engineering team with work, specs. Things that they can be building. But we don’t necessarily know yet is the right solution. I think that can be a struggle. So I think that there are a couple of classic approaches to that. One is built into this idea of dual track. 

[00:29:58] You’ve got discovery going on while development is going on different things. You’ve got discovery going on things that will be in development in a few months, and the things that are in development now are things you already did discovery on. So that you were able to describe, what was necessary.

[00:30:16] That means a lot of contact switching for product managers. I’m doing discovery on A while helping with development on B. And that’s challenging, and sometimes people solve that by splitting the roles between product manager and product owner, for example. Or by just making sure the team doesn’t get too big so there isn’t too much work for a product manager to handle. The ratio of product manager to engineer– product role, whether it’s owner or manager or whatever, to engineer has shrunk over time as people have grappled with this. I think it’s more like five to one typically now, rather than ten to one like it was years ago, to enable that. And the other thing though — a couple things. One that is frequently overlooked is, engineers are quite useful during the discovery process. Building a quick prototype, asking the question you didn’t think of, thinking about alternate ways, easier to implement, and having that factored into the thinking early rather than once a solution is already described. 

[00:31:19] And some engineers really thrive on that kind of a, “Oh, let me throw something together in a few hours and see if it helps before we decide on a direction.” and then the last thing is, who said this? I think it was Melissa Perri said once when, she and I were on a panel, she said, “if you just leave the engineers alone, they’ll go off and fix a bunch of bugs and retire a bunch of tech debt and make the system more scalable and robust. Why don’t you just leave them alone and let them do that while you’re figuring out what the product strategy is and what features you should be building? You don’t have to be their babysitter all the time. That’s at least the first thing that comes to mind internally. Engineers, frequently, they want to know what they’re supposed to build. An engineering lead said to me one time that he was really frustrated with the product managers, trying to describe things indirectly through user stories and things like that, he just, in frustration just finally said, “If you know what you want to build, why don’t you just tell me?” I think, the answer to that is, “Help me figure it out.” 

[00:32:22] Megan Saker: And I think that was another question I had in terms of, say you’re a product manager, you want to move to working in this way, with a lean roadmap. To what extent do you have to make shifts in your team culture? Working this lean way, from everything you’ve said, feels like it’s a sort of step change in terms of collaboration.

[00:32:42] And bringing people into the process in the journey. What are the other things? You talked a bit about how you bring the dev team into the mix. Like what else, what are the other considerations in terms of culture and working? 

[00:32:57] Bruce McCarthy: The biggest cultural shift that I see that really works in teams’ favor when they move in this direction is, is a shift from efficiency of execution on tasks to effectively making a difference. A shift from thinking about throughput how many features or Jira tickets did we retire? To thinking about results.

[00:33:25] And where that changes is, in a sort of more traditional like delivery oriented organization, the temptation of engineering teams is always to arrange everything for efficiency of task, execution for the engineers. And so they always want the most experienced person with a particular component or technology to do a task. And so they have teams that specialize in components of your product. And you feed them work through a ticketing system. It’s almost an ad agency where you have the people who do the storyboards, and the people who do the ad buys and the people who write the dialogue, and the people who shoot the … And they’re all specialists. But they don’t necessarily come together as a team, to have an ad that’s gonna be really effective for the client.

[00:34:17] And that, I think is something that I, frequently find that in changing the culture of a team, I have to correct. That rather than setting things up so that you always have the most optimal time usage of the expertise on the engineering team, instead you’re organizing for a particular customer or a particular set of problems for that customer in a cross-functional team with a few engineers, a designer, and a product manager. And that means those engineers may sometimes be working on parts of the code that they’re not that familiar with. That they aren’t the most expert on. And that sounds scary to some engineering leaders. It creates, in their mind it creates an inefficiency and risk.

[00:35:04] And they’re right. But what’s more important here? The best-written, most efficiently written code? Or a good understanding of the problem we’re trying to solve for the customer, and the ability to examine every technical decision that you make in terms of, is this the right thing for the customer? That’s more important in terms of getting results, in terms of getting outcomes, in terms of solving the problem well. And internally, those engineers can always go ask the advice of a more senior engineer who knows more about this particular component to keep them from making a dumb mistake. 

[00:35:45] That’s a big [inaudible 00:45:59] not interested in making, because they feel like their job is delivery. And it’s hard for us as product managers with a much smaller organization, usually five to one, like we said, to get them on board with that unless is a good mind meld between the heads of those functions. I don’t know if that made any sense. I hope so.

[00:36:11] It did, 

[00:36:11] Megan Saker: Yeah, it absolutely did. I am slightly conscious time. I’ve got many questions, and keep going, but Kirsty, I think you were hoping to drill into once someone has been successful, implementing it.

[00:36:24] Yeah, I think.

[00:36:26] Kirsty Kearney-Greig: You talk about a lot of the challenges to overcome. But let’s put our positive hats on and say someone overcome those challenges, they’ve got the buy-in from the stakeholders, from the engineering team, and gonna move to this kind of lean roadmapping approach. 

[00:36:38] Megan Saker: I guess from your point 

[00:36:40] Kirsty Kearney-Greig: of view, Bruce, what are like the ongoing kind of best practices for managing it on an ongoing basis? I think there’s a lot of stigma around Janna says it right? The way that this approach type fuels strategy, it should be flexible, it should regularly change. But a lot of people get stuck in that. Once a quarter, we update our roadmap, and that’s it. I’m literally speaking to- All this new stuff, and I was like, “Brilliant, that’s exactly what it’s about.”

[00:37:02] Yeah.

[00:37:02] And what are those kind of best practices from your point of view, in terms of how they can 

[00:37:05] Bruce McCarthy: get that right?

[00:37:06] I do think you’re right. Once we enter into a lean roadmap situation it is bound to evolve. And I think you’ve got to train your organization to expect that. And one way to do it is to be very proactive and regular about announcing the latest update on the roadmap. or April 27th or some random date. “Oh, we’ve had a change.” Because then that sounds like some sort of failure, some sort of, something has slipped. We made a mistake. And instead you want to be transmitting that the roadmap is always being updated and optimized based on new knowledge, based the reaction to the last things we released, based on what the competition is doing, based on changes in the marketplace. Have our feelers out continuously, and so we are naturally adjusting course toward the ideal.

[00:37:57] And that’s the essence of lean and agile, right? So if you release, for example, a new updated roadmap with a date on it every month, even if the changes are minor, then you’re training your organization to always look for the latest version and to expect that there’ll be another one soon and that there will be some changes. And you transmit that things that are further out on the roadmap are less certain through how you present your roadmap, that’s also a way of training the organization. So for example, some people will put percentages of certainty on timeframes, like quarters, or now, next, and later. Or they’ll say, that the essence of now, next, and later is a sense of uncertainty, that grows with time, right?

[00:38:43] People sometimes put timeframes on them, or percentages of certainty. Or they sometimes call the later column, considering rather … To really transmit that “it’s on the roadmap but that doesn’t mean we’re necessarily going to do it.” So I, I think the first thing is really be in front of that process and training your organization to expect it. There was another thought I had. The question was, what are the best practices? A roadmap shouldn’t be an ivory tower thing that gets handed down even on a regular basis from product that emerges from some sort, like through a white smoke coming out of the top of the Vatican. It should be something where it’s a team sport, where it’s participative, where you get key representation from functions around the organization. Maybe it’s actually the executive team, or if it’s not, it’s some sort of product council. And in addition to going over the latest version of the roadmap, you’re gonna be talking about what you’re considering for the next update of the roadmap. Let’s agree on which things are fully validated here and which things we are uncertain about, and let’s make a plan together to go and reduce our uncertainty about the things that are risky. “Can, hey, sales person, can you help me get together with some prospects and customers to do some interviews?” “Hey, support person, can you help me talk to people who have experienced …” foots in front of them and, what makes sense to them.” Then to the roadmap here, people get to take credit for having helped with that, rather than being surprised by it.

[00:40:23] Kirsty Kearney-Greig: I think once those teams start to see the benefit of their participation, that’s where the success comes in. I think, as Megan said, I’m super aware of time, we’re coming to the end. I definitely want to, give people the chance to ask questions. I can see there’s some already coming in. One of them actually was something that I was gonna ask you to touch on myself. So there’s a lot of talk of where the future of product management and roadmapping ahead thing, AI is doing a lot and where is it going? What do you think Bruce?

[00:40:48] Is future looking of, product management and roadmaps gonna look like?

[00:40:52] So the 

[00:40:52] Bruce McCarthy: question is, what does the future of roadmapping look like? Like how 

[00:40:56] Kirsty Kearney-Greig: we’re doing product management on a day to day basis for a lot of people, like what other … He said it as a challenge, I don’t think AI is a challenge necessarily, but what are the other things that have you seen that may be coming through that are gonna be changing the way we think about product management as a practice, and roadmapping? 

[00:41:10] Bruce McCarthy: I’d love to actually address a misconception, I think, about that. I think, we all heard the headlines about AirBnB claiming to eliminate product management.

[00:41:19] We did.

[00:41:20] And just about that time I had a friend who was a CPO at a company who said that they were getting a lot of pressure to reduce staff, and people were questioning, what do those product managers do anyway? And so a reasonable person might look at those two data points and maybe a few others and say, “Oh, have we reached peak or- In some sort of trouble?” Because I put that together in my mind with the fact that product management’s, prominence and importance, has been increasing. And the recognition of those things has been increasing steadily for the past decade. And so the demand for good product people has gone up and up. And have we reached the peak of that? And I would say that my answer is a firm no. We have not reached the peak of that in any way, shape, or form.

[00:42:05] Bruce McCarthy: I would say, number one, that AirBnB didn’t eliminate product management. They decided to do it right. they had people they called product managers whose jobs were just being product project managers. They just were based on, focusing on delivery. And they said, “Yeah, we needed some people who could do delivery and focus on who’s the customer and what are the needs and how do we sell this.” And I’m like, “yeah, that’s the job.” And they just didn’t, and they just woke up to that finally. and they, in my mind it was misinterpreted, in the marketplace. Have almost two years now, the macroeconomic climate has seemed very uncertain to a lot of investors and to a lot of companies. And so they’ve been questioning their investments across the board. And product management can sometimes be vulnerable to the, “What do those guys do anyway?” sentiment.

[00:43:01] So it’s up to us to make the case for the value and the ROI of product management. It’s up to us to say, hang on or ensuring that all the time spent by engineering and marketing and sales is going to have a good ROI. That’s our job. and I think if you position product management as being essentially watchers of success of a product, and if you focus on outcomes, that is, we’re gonna make a difference ultimately in the success of the company in terms of revenue and margin and so on, you make a really good case for the job. If you focus strictly on, “I’m gonna ensure on-time delivery,” a much less senior, experienced, expensive resource can do that job.

[00:43:51] Yeah, 

[00:43:51] Kirsty Kearney-Greig: I couldn’t agree more. thanks for that, Bruce. We’ve got another really great question come in, actually, and I think, I see it lot with our customers. And the question’s around internal versus customer facing roadmaps. …

[00:44:01] Oh, yeah.

[00:44:02] Both have their own validity and serve their own purposes. Their question is what your view on, what your view is, sorry, on including discovery activities on those, if it’s a problem that hasn’t yet been validated.

[00:44:15] Yeah.

[00:44:15] And how you balance 

[00:44:16] Bruce McCarthy: that.

[00:44:17] I generally don’t think, I generally don’t try to expose the different phases of life of a problem or a feature in the roadmap so much. I think it’s, people don’t really … People outside of product and engineering that are actually working on the product don’t care so much about when your activities happen as they do when value will emerge. When some change to the product will emerge. So when I put something on the roadmap for Q3, that’s when we’re gonna ship it, in my mind. As opposed … But I might be working on it for many months or quarters ahead of that, but that’s not gonna necessarily be all that visible to marketing or sales. Why do they even care? they might care if they’re brought into the team and they’re going to participate in that early discovery. But they, but in my mind that’s still not on the roadmap per se. That’s on the things that you are putting into discovery.

[00:45:18] I do appreciate the distinction that the question asker made between validating, discovering the problem and validating the solution.

[00:45:30] Those are two different things. And you’ve got to do them in that order. There’s no use trying to do discovery on a solution if you don’t know what problem you’re trying to solve. So you start with the problem and make sure you understand that really well, and only then start thinking about what kind of a solution would make sense given our understanding of the problem. And thinking about it, once you have validated that there is a problem and it is worth solving and you think that it is at least feasible to solve the problem, maybe at that point you could put it on the roadmap and say we’re gonna do a bunch of validation work on our approach to the problem. I think If you were going to do that, I think, putting a problem that is not yet validated as a significant market problem on the roadmap is probably a mistake. 

[00:46:17] Megan Saker: But there might be some value as confidence increases on the problem, but you’re not yet, at, you 100% certainty, there’s value in it being on your customer roadmap in terms of your putting your customer roadmap out there and asking for feedback.

[00:46:35] So even, get, that could help, question mark? With the validation process by communicating your plans and getting the customer feedback on it. 

[00:46:43] Bruce McCarthy: I guess it depends on how far along you are on that. If you’re really not sure that something is a problem but you want to understand if something is a problem, if it’s really still very uncertain in your mind, I think I would, rather than putting it on the roadmap as a way of doing that discovery, I would just have the discovery interview, where I am asking, without biasing the subject, “What challenges do you face?”

[00:47:07] “What are your goals and what’s hard about reaching those goals?” And see if it turns up. And if after you’ve had an hour to talk to the customer and after 50 minutes they haven’t mentioned your thing, you could say, “What about this problem? Do you have this problem?” And if they haven’t brought it up on their own, probably not, but you could ask. if you are starting to see signs that this could be a problem but you’re still not sure of the magnitude of it, then putting it on the roadmap in the now, next, maybe column, the considering column or the exploring column, to get reaction, could make sense to see if you get hand-raisers. Especially if you’ve got a large number of customers, then you might, and it’s not always a one-to-one conversation like an interview. You could put it out in the last column of your roadmap as a way of seeing if some people will raise their hand and ask you … About it. 

[00:48:02] Megan Saker: We have got a, another question that’s come in. I’m conscious of time and we’ve run over an hour. I think what we can do with that question, it’s from Daria, is we can get that over to you, Bruce, and get an answer, and we’ll drop you an email there, Daria. The other thing, to say is that we will send round the recording of the webinar, so we can include the answer to that final question then. But yeah we are out of time. I wanted to thank you, Bruce, for what has been a great conversation. Really insightful, and so thank you.

[00:48:33] Thank you very much for joining us. 

[00:48:35] Bruce McCarthy: This was fun. I appreciated the questions, both from you, Kirstie, and from the audience. 

[00:48:40] Megan Saker: And who needs Janna, hey? Who needs Janna? 

[00:48:43] Everyone needs Janna.

[00:48:44] No, Janna’s great, I’m joking. What I did want to give everyone is just a heads up that we’ve got some more resources and more content coming on this subject. Janna is doing a webinar on the 31st, which is utilizing actually a presentation deck that you would be able to download, to help internally convince stakeholders to move to a lean roadmapping approach, and we’re also soon to launch a course that you can sign up for and work through in your own time, that again, will help step by step how you transition from a more timeline model to working in a lean way. So look out for those, they’ll be coming soon, and we’ll send you an email, when they are out.

[00:49:26] Bruce also has a great book 

[00:49:28] Kirsty Kearney-Greig: that’s all about convincing stakeholders, and building those relationships and stuff as well. So that’s always a good read on 

[00:49:34] Megan Saker: there as well. just finally, to-

[00:49:36] [inaudible 01:03:56].

[00:49:38] Kirsty Kearney-Greig: Oh, I forgot, I’ve forgotten the title, you’re putting me on the spot now, Bruce. Your second book, I can’t remember the title of it. What was it called? 

[00:49:42] Bruce McCarthy: Product Roadmaps Relaunched or, Product Manager Versus, Project Manager. I wrote that for O’Reilly. But the new one is called Aligned.

[00:49:51] That’s it.

[00:49:52] Stakeholder Management for Product Leaders.

[00:49:54] Yeah, that one.

[00:49:56] Megan Saker: Wonderful. And then just to give everyone a bit of a preview of our next, fast find expert chat, looking at the applications for AI in product management with, Christina Tamara Grigorie. Thank you very much, as always, we do urge you to, if you haven’t checked out ProdPad in a while, to go and have a look. And because we are product people, we would welcome all your feedback. So all that remains is for me, again, to thank Bruce, very much for joining us. Again, apologies for, Janna not being here. And apologies for the chat not working. But it’s been great. I hope everyone’s found it useful, and Bruce, again, thank you very much for your time.

[00:50:32] Bruce McCarthy: Thank you.

[00:50:33] Thanks, Bruce.

[00:50:33] See you