Do roadmaps need to tell a story? | Bruce McCarthy
In episode 9 of Talking Roadmaps, Phil Hornby interviews Bruce McCarthy. Bruce discusses the essential elements of effective roadmapping, emphasizing the importance of storytelling in conveying a product's vision. He shares insights on common challenges faced by product managers and practical solutions derived from his extensive experience. Tune in for valuable advice on creating compelling roadmaps that inspire and guide product development.
Bruce is Founder of Product Culture, helps companies like Grab, Vistaprint, Camunda, Genomics England, and Kaleyra achieve their product visions through advising, workshops, forums, and coaching. He is President Emeritus of the Boston Product Management Association and a head judge at the annual Harvard Business School New Venture Competition. Bruce co-wrote Product Roadmapping Relaunched: How to Set Direction While Embracing Uncertainty.
“The most important thing for a roadmap is that it’s got to tell a story”
Have a watch and if you enjoy the video don’t forget to subscribe to the channel, like it and maybe sign up to our mailing list!
Here is an audio-only version if that’s your preferred medium - and you can access it through your favourite podcasting platform if you prefer (Apple, Spotify, Amazon).
Our next guest is a big one! We have James Mayes he’s one of the founders of Mind the Product and an Evangelist for Product-led Organisations at Pendo. So watch out for Episode 10!
-
Welcome to Talking Roadmaps, the YouTube channel where we explore everything on roadmapping, the good, the bad, the ugly, talking to practitioners, experts and anyone who wants to talk about them really. And today we're privileged to be joined by Bruce McCarthy, who I think is the single most named person we've had in any of the interviews so far. Bruce, great to having you here. I'd love it if you'd introduce yourself.
Oh, thanks and thanks for having me. My name is Bruce McCarthy. I'm the founder of Product Culture. We're a small company that we provide advisory services, coaching, training, workshops, et cetera, to companies, product driven companies all over the world. But a lot of your listeners, I came up through product. I've been a product guy forever and pretty much everything I write about is either from my own personal experience or the experience of companies that I've worked with since I was a day-to-Day product manager.
Sounds perfect. So similar journey to myself maybe a few years ahead, just you've already got the book out,
You have a copy right there. Yeah, so that's really what I think I'm most known for is co-authoring that book with c Todd Lombardo and Evan Ryan and our designer Michael Collins four or five years ago. Now it's become kind of the standard text on road mapping.
I have to admit, when I first read it, it was epiphany after epiphany for me, so the challenges I've been struggling with seeing people have thought it through and come up with some solutions,
Well, we all go through that journey I think as product people because there's not a lot of formal training out there. It's an immature discipline. So we go through following our best advice, our best intuition, the advice of our friends, whatever it says in the latest book, and we learn by doing, and that's everything that's in that book is me and my co-authors learning by doing.
Let's start with a really basic one then. What's the purpose of a roadmap?
It's a really good question. I think if you ask a lot of people what is a roadmap, they would say, well, it's a schedule of deliverables, it's features and dates, and I think that that is completely wrong and misleading. There might be some dates, there might be some features, but really it's a strategic communications tool. It's laying out what does the future look like, how are we all going to benefit and what are the main big steps that it's going to take to get there? The big boulders that we have to move it, its job, its job to be done if you will, is to rally everyone around that long-term destination and get everybody moving toward that destination together. That's a much more long-term strategic job to be done than what I think people think the job is to be done, which is more of a project plan or a delivery plan or a release plan, which is all about resources, timelines, budgets, dependencies, all those things are necessary. I wouldn't argue for a moment that you should not have a project plan, but a roadmap is a different thing.
And so you talked about there about it being quite a strategic tool, so who's the audience for it? Is it particularly strategic people or is it everybody? How does that work? What's the audience?
I really think it's everybody. Sure. You might think about making your roadmap for your team so that we're all working on the right stuff in the right order, or you might think about your executive team because you need them to buy off on what you've got in mind, or you might think about your investors, your board, because high level you want them bought into the story too. And then of course there's the marketing and the sales team because once you've got something delivered, they've got to be able to sell it. And then actually there's a whole bunch of people who are working on it, not just your core team, but people who are working on it occasionally, the database team, the legal team, the finance team, the analysts, Gartner and Forrester, those guys, the list goes on to the point where you're just like, yeah, it's everybody.
In fact, you've mentioned some external ones like analysts. The controversial one for some people is customers.
Customers and for consumer products, I can sort of see why you might not want to open the door on something that isn't going to be available for a year because you could possibly cannibalise the sales of your thing that you're selling. Now if people are like, oh, I'm just going to wait for the next version. On the other hand, we've all figured out that there's an iPhone every fall and that it's always upping the game a bit. So it's not like we're sure the details of exactly what's going to be in the next iPhone are not known for sure. Well, there certainly are a lot of rumours until the last minute, but the broad strokes of where is Apple heading, we kind of know.
Yeah, I guess what about the new iPhone though when it first came out? I guess the roadmap brings us there as well, not just in life,
And if you want to make a big splash, you might not publish a roadmap of what that thing is until that thing exists or is commercialised, but these are exceptions. The life up to the point of the iPhone coming out in 2007 when they were working on it was pretty short compared to all the time since then. So there is internally at Apple, I'm sure a roadmap and we have a sense for roughly what is on it, but apple is kind of a unicorn, and so most of us deal in the world of more prosaic everyday products and especially on the B2B side, customers expect a roadmap from you, especially in enterprise software where the customer is not just buying what does the software do today, but they are buying your commitment to continue to enhance and improve it. They may not be insisting, although some will on specific deliverables, on specific dates, but they want to know that there is a roadmap, but they want to know that it's compelling and they want to know that it's oriented to them. So a good roadmap finds a way to convey, we are working on your behalf. We have a lot of good stuff in store. Your sign up with us and your relationship with us is going to get stronger and deeper over time without over promising on the details.
Yeah, I would like to say they go come in on a journey with us. That roadmap tells them what that journey is.
That reminds me actually of a conversation I had during the writing of the book with David Canel, who's CEO of Drift here in Boston and former head of product for HubSpot. He
Not a fan of roadmaps if I,
Well, no. He said, yeah, we don't do roadmaps. And I said, what do you mean you don't do roadmaps? And he said, well, it's a no-win scenario. I am going to make promises that either I will keep, in which case I'll disappoint you because it probably wasn't the right thing because I've learned a lot of things along the way or won't keep because I acted on the things that I learned along the way and now I lied to you. So he's like, I'm just going to be Captain Kirk here and I'm going to write my way out of the no win scenario by not doing roadmaps at all. But then when I asked him, well, what do you do instead? He said, well, we have broad themes of problems to solve for customers, and then we give the teams the freedom to figure out exactly and do a bunch of testing to figure out what's going to really solve those problems for customers.
And I told this story to Jeff Bussgang VC in the Boston area, and he said, he just described the thematic roadmap, and I said, yeah, and that's the way we describe the best way to do the book is sure, if you think of roadmaps as a bunch of commitments to features and dates, you're signing up for a disaster. Don't do that. Don't take away your own flexibility to figure out what's really working for your customer. Focus on problems instead, and if you've got a problem oriented thematic roadmap, then that's something you can share with customers. Then to close the loop on this, the second thing he said was, we found that customers are much less insistent on specific deliverables, features and dates. If we bring them into our process, if we say we're working on this problem and would you come and talk to us about your experience of this problem and tell us what you've tried to solve this problem, and then we'll talk about the solutions that we are exploring and testing and see what your feedback is on that and we'll share with you prototypes along the way that you can kick the tyres on and give us feedback on.
So under the banner of a strategic thematic problem oriented roadmap, you can set up a really healthy conversation with your customer,
A lot of discovery work that's ultimately it's driving.
Yeah, Steve Blank said the same thing when I talked to him. He said, roadmaps are a fantastic discovery tool and a fantastic validation tool in the sort of the lean startup phenomenon. If you think about some enterprise software that you're going to build that's going to take you two years to build even the first version of it, well, how do you iterate your way and test your way to success with that? He said, what I do in addition to a quick and dirty demo that doesn't actually work but looks like it works is a roadmap and I give it to the customer and I say, will you sign up for this product that won't be available for two years? And if the answer is come back in two years, then I haven't really cracked it yet. If the answer is that is so awesome, I will give you a pre-order, then you're onto something.
Now I want to circle back a little bit. We talked about that iPhone and that's part of a portfolio. I know you've been doing some thinking about portfolio road mapping, so maybe that's a good point to bring it in.
It's something we didn't really talk about in the book. We were focused on the roadmapping process for a single product, but of course a lot of companies have multiple products and the idea of bringing together all the roadmaps for all of those products into one view makes a tonne of sense. When you're talking to the board or investors or analysts or you're just making an internal all hands presentation, you want to be able to provide context to all these stakeholders about the job that each product is doing for the company as a whole and for the product line. So some teams organise it by, we have a bunch different solutions that do complimentary things for different people or we have a burger, but we also sell the fries and the shake and all these other add-ons.
It doesn't really matter, but what you want to do is be able to tell that story with your roadmap. Again, not deliverables and dates, but how is each one of these products contributing to the success of our customers and the success of our business? Sometimes it can be as simple as we've got a roadmap for this product and it's one row in a chart, and then we've got roadmaps for each of the other products in rows beneath, but if you're going to tell a really good story, there needs to be a wrapper for that. There needs to be something that shows your destination and where you are in that journey toward that destination. GitLab does this. They've mapped out an enormous territory of everything that they want to enable. For developers that's quite broad. It's something like number around 15 or 16 different broad areas and their roadmap publicly available on their website shows the level of maturity on each one of those.
Everything from we barely have anything in this slot to the core repos and things like that that are about release management where they're quite mature. So that's all in one chart and then you can click and dig into any one of those 15 or 16 areas and see a thematic roadmap. These are the problems that we need to solve in order to become really mature in this space. So they've got that overview that provides the context, lays out their scope that they believe that they should occupy and shows a snapshot in time, and then you can go into the now, next, later version of each one of those roadmaps. I think that's super compelling. Another way to think about it is the three Horizons framework. I really love that for portfolio roadmaps because it allows you to explain where you're investing and why from the point of view of making the company successful. I can spend a minute on that if that's okay. The fire? Yeah. The idea behind the Three Horizons framework, it starts with the recognition that all products go through a lifecycle.
They go through a lifecycle that's kind of shaped like an S, they begin life small, low bumping along, trying to reach product market fit, and then when they hit product market fit, they begin to grow much more quickly and they enter the growth phase and that can go on for years for many products, and then eventually they have plateaued. They have saturated their market or reached some sort of equilibrium with the competition and growth becomes much more difficult. So if they don't want the company growth to cease at that point, they've got to essentially stack multiple s-curves of growth one on top of the previous, and Amazon is famous for this, right? They have all sorts of products and if you look at their growth as a company for the last 20 years, it is absolutely straight up and to the right, but the growth of each individual product or product line is embedded in there and they are the usual s-curves.
So the three Horizons framework says basically that any given company if they want to be healthy and want to be growing over time has got to have products in each of those three phases of growth at all times. They've got to have something that is providing the bulk of the cash, the cash cow in what's called horizon one, but that something may be mature and not growing that much anymore, but they use the cash thrown off by that to fund things that are in horizon two that are small in absolute dollars, but growing fast today. And then they also use a bit of that money to fund the crazy lab experiments of things that are not yet at product market fit are losing money, are hopefully being tested and validated or pruned quickly in what's called horizon three, and you have smaller and smaller amounts of investment as you move further out on the horizons until those things are proven to.
Yeah, if I remember rightly, the classic wisdom is 70 20 10. Intuit famously used 60 30 10, for example, for their allocation of resources in those different horizons. Yeah, it's funny enough how I started road mapping in my last corporate role. It's definitely an approach I love and yeah, I guess the one thing I struggled with, and maybe you've got a thought here is physical products have some fairly hard timelines and that was still the thing I couldn't quite rationalise.
Yeah, I think that's right, and I know we say in the book over and over again that you don't want to get locked into features and date commitments, but that advice is general but not prescriptive. There are times and places where dates are important, production deadlines is a good example. You need to hit the holiday season next year, and if you're going to do that, then you've got to get your specs and your dyes finalised by a certain date in order for there to be enough time for the factory to produce the quantity that you project. So you back up from when you want to begin holiday sales like sometime in the fall, and that dictates your timeline and that's a deadline and you have to meet it, even if it's in software, even if it's in B2B software, there's still a buying season even for that, and there may be regulatory or contractual requirements.
We all had to comply with GDPR on a certain date or risk being sued. So my general approach is to say be as loose as you can get away with depending on those constraints, and just because some things require dates doesn't mean everything requires a date. So you could, for example, use a now next later format with no high level dates on the big columns in your roadmap and yet have a specific date for when you're going to have GDPR compliance on that one item. For example, you could, if you're a mixture of hardware and software, you could say, all right, well the drop dead date for the specs to the manufacturer is this, but we can keep tweaking the software even after the release so you can use a now next later format for that.
Cool. Perfect. Makes good sense. So we've got these roadmaps, who owns them and who are they for? I thought who owns them and who maintains them I should say?
So somebody needs to be the owner of the roadmap. I've just been making some slides about Apple's concept they call the DRI, the directly responsible individual, which they didn't call them product managers. It could be anybody from any function was the DRI ON making something happen that was the essential meaning of it. So I don't think it's always product managers, it's a DRI of some sort. It's the buck stops here person, but it's very often the product manager. It's very often it's sort of the classic, what does a product manager do? They maintain the roadmap and maybe at a lower level of granularity the backlog that feeds into the roadmap. So I think it's primarily their job, but I also think importantly that it's a team effort roadmaps that are made up completely and totally and exclusively on the product manager's laptop and don't see the light of day until they are announced are not generally successful.
You've got to really work most of those same groups of people that I mentioned that the roadmap is for should be participants. It's like I was saying about the customer that Drift brings them into the process. Your team needs to be a contributor to the roadmap. Your stakeholders need to be contributors to the roadmap. Even the customers, I always say that there are a few core pieces of information that need to be in a roadmap, and one of them is the subject to change disclaimer, and the reason that is important is not just for legal reasons, it's because you want to communicate directly to even the customer that they have the ability to influence your roadmap, that it's subject to change based on changing conditions and new things that you learn and you can learn new things from that customer. So please, Mr Customer or MS customer, tell me what you know because I'm listening.
I think one of the previous interviewees said they don't use the subject to change. They've gone through, I think one of the wordings from the Agile manifesto kind of essentially along the lines of we embrace change as opposed to it's subject to change just to get that point across, which it was an interesting sort of way of getting that same point across as opposed to making it feel like legalese is actually almost come across as a principle.
Yes, totally agree.
Okay, so we know who it's maintained by, we know who owns it, but it relates to some of the things you talked about, a project plan, what else does it link into and how does it link
Into them? Well, I mentioned a moment ago that it should link to the backlog. Imagine that you've got these themes of problems to solve that are the guts of your roadmap there, what you're working on, well, your backlog should be all the things that you want to try to solve that problem, and it might be features, it might be experiments like we're going to mock something up and put it in front of some customers and see what happens. It might be a marketing campaign. We're just going to try to create some awareness. I worked with this one team where on the roadmap, they really wanted to increase the successful implementation of their SDK among their customers, and they thought that it was going to require a bunch of code and code changes and engineering work to change the SDK to be more consumable. It turned out none of that was a problem. The real problem was documentation. It just wasn't clear how to integrate it, and they discovered by interviewing some customers that all they had to do was walk 'em through it and it was a fairly simple procedure and then the customer was like, oh, this is great. I'm done. So this group of three engineers who their time had been blocked out for months to rewrite the SDK actually decided, well, it's our job. So to make the goal to make this consumable and doc is what's missing, so we'll write the doc. We're writing it.
Well, that's a rep engineer that is still prepared to write the doc instead of saying, can you get a tech offer in
Now? Well, they knew that they actually, the doc team was down a few people and didn't have the time, and I asked them, are you comfortable with doing that? And they're like, well, it's not our favourite thing to do, but this is what the customer needs, so we're going to do it. And they kept on doing it and they were happy doing it and they succeeded. They tripled the successful rate of implementation of the SDK with their new documentation and then they went back to writing code and happily because that was the right thing to do.
So we've got a project plan with a backlog. Anything else that might link in there?
Yeah, both of those obviously an investment deck would obviously be a good place for a roadmap to sit in particular if you were to put percentages of effort or dollar signs or things like that about where the investment is actually going to give a sense of magnitude that the three horizons framework for a portfolio roadmap and how much are we investing in each one of those horizons would be a perfect discussion to have a market analysis and strategy deck. The roadmap could be at the end of that to say, this is what the market landscape looks like. These are the trends, this is where we see things being in a few years and therefore our roadmap is pointed in this direction. I've done that sort of thing for analysts in the past, for example. The other thing I really want to highlight though is numbers.
So I think it's really there's a tight possible integration between the OKRs or other metrics that you're using and the roadmap, especially if you're taking this approach of a problem oriented roadmap. Well, first of all, how do you know which problems you should be solving? Well, if you need to have a reasonable hypothesis that the problems you're focused on are the ones that will drive your business forward, the ones that will, depending on what the goals are, either drive revenue or growth or customer acquisition or retention or whatever you're focused on, and then what that suggests is that you can actually incorporate metrics directly into the roadmap as measures of success. You can say, well, this is the problem, and our hypothesis is that if we solve this problem, we will let's say increase retention and we will know that we're on the right path when we see some leading indicators that are correlated with retention begin to change like engagement or usage or NPS or things like that that are usually correlated with renewal.
Okay. Let's switch gears a little bit. What are the key elements that should be on any roadmap?
Right, so in the book we describe five core components that are necessary. There are a lot of things that could be in a roadmap, but if you don't have at least these five, I don't think you've got a solid roadmap. So number one thing that is necessary I think and often left out is some sort of vision of the future. If it's a roadmap, what's it a roadmap to what's the destination? The destination should be described fairly clearly in the slides leading up to the schedule grid. The themes, and I like to actually put it just a reminder of it, right at the top of that, here's what we're working on sort of grid, and I think that the vision usually ideally is described not like we will become the number one dealer in the northeast, but more in terms of we will create some value for our customer.
Here's who our customer is, here's the pain that they're in. Here's how we are going to uniquely solve that problem for them. If you have a customer oriented vision, then the list of problems to solve, customer oriented problems to solve becomes fairly direct. And that's the second one is the themes or the problems to solve. That's the guts of the roadmap. That's what I would put in instead of features because you don't know for sure which features are going to solve the problem, so let's keep the focus on the problem and let the features come and go and change and ship and get tested and validated and maybe rolled back if they don't work until the problems are solved. So that's two. The third one is timeframes. We've talked about that as we've discussed. I like the timeframes to be as loose as possible. Now, next later has become hugely popular as a framework since the book came out, but if that doesn't work for you, I like to use broad timeframes like quarters or even half years or even years. I try to not have exact dates. I think that that classic timeline view with a bunch of deliverables with exact dates March 22nd, that sort of thing is a recipe for David. Ken sell's fear about broken promises.
I mean, I sometimes find that broad timelines one then struggles a little bit though if as soon as you put that there, you put Q3 and sales, interpret it as Q3 is one thing, product is another, and engineering is another one. Again,
If you say Q1 sales assumes it's January 1st and engineering assumes it's March 32nd or
So. Yeah, I normally say April the third or something like that. April the first maybe.
Right, exactly. And so what I try to do is divorce it really from a timeline view and say, look, we're not mapping out a Gantt chart of effort. We are saying here are the windows for when something will appear that addresses this problem, and if the window is Q1, well then I'm not being specific about when in Q1, and you can cover that at the beginning of any presentation or in the fine print in A PDF that you're sharing or a slide deck or something like that and say, first of all, dates are subject to change, and second of all, they could occur anytime in that window. Another thing people sometimes do to really bring home that uncertainty around dates is to put percentages of confidence on timeframes, on specific deliverables or on the timeframes like the quarters for example. And I've seen roadmaps where it says our confidence in the deliverables that for this quarter that we're in right now is 80%, and then for next quarter it's 50 and on down to like 20%.
Yeah, I think I've got colleagues who've used a rag code in the similar way, your red and the green, or I've used almost the status whether it's in discovery, in development, in final usability testing. So you kind of get that feeling of how it's progressing through the machine.
If you give people a flavour of progress and ness that can often satisfy them. I mean, unless we're talking about talking to your retail distributor and they want to know, are we going to have it for the holiday season? Yes or no? You may need to answer that question.
So I think we've got timelines, we've got themes, we've got vision,
Right? So also business objectives. So this is where the OKRs and the metrics come into play, usually not for sharing with customers or others outside the organisation, but for the team, for other employees, for the investors, for the executives, all the internal ones want to know what needle are we trying to move with this? And it provides super helpful context to everything that's on the roadmap, the what should be clear on a roadmap, but the why needs to be the clearest thing on the roadmap and the why comes down to the vision. Sure, that's about the customer, but also down to the business results. We expect that this will double sales or we expect that this will increase retention or things like that. And then the final one is the disclaimer. You got to have that we embrace change statement somewhere prominent. Now, I want to address one thing.
I mentioned that it's possible to add dates. It's also possible to add features sometimes if you know that this problem is best solved by this feature here, you've been working on it for months, you've tested it with loads of customers and it's just a matter of completing it and getting it shipped in the next version or next release or whatever, well fine put that on the roadmap at that point, not before, but at that point. Or another way to use features that I really love is you've got your problem statement and then you could have a list of possible features that is kind of your backlog of things to test. And when you have multiple features listed under a single problem, it sets up again that aha moment for the customer or the partner or the stakeholder, oh, they're not actually going to do all of those. They're going to pick the winner.
I remember first introducing this sort of roadmap and that assumption that was going to be a lot of pushback from senior leaders and customers and this sort of thing, and suddenly realising that actually they all suddenly realised it was just a more honest view.
When they realise that they're seeing behind the curtain and then you're really sharing your actual thinking with them, including your actual uncertainty about what the winner is going to be among the features, they suddenly feel they stop pushing. They stop pushing for a hard and fast commitment because they realise that if they could somehow force you to commit to a date before you were ready to pick a winner on the feature war, that would reduce your ability to serve their interests. And then they're like, okay, you know what? I trust Bruce. I trust Phil, they're working in our interest and they'll take a meeting with me to discuss progress anytime. So why am I going to try to insist on a feature date commitment?
Now obviously there's a growing area of tools that are kind of there to support this. Just wondering if you had any preferred tools in terms of visualising roadmaps.
Well, the majority of product people still use PowerPoint for roadmaps, and I think that's because it's super flexible. It does what you want it to do. It does what you tell it to do. I should say, I think that actually you talked about visualisation and the simplest, easiest, quickest way to visualise a roadmap is to use PowerPoint or miro or something else where you have all the flexibility that you need. Where I see the various roadmapping tools that are out there now being useful is in creating a workflow that allows ideas to come in, be evaluated, be linked up to other similar ideas, be connected to the problem that they solve, be connected with discovery, tested, validated, and then maybe make their way onto the roadmap. And then the roadmap view of such a tool is really just a work in progress of that discovery process. Here are the things that have bubbled up to the top as of now, and they're in order, and maybe they're in some sort of timeline as well.
I had a really lengthy deep conversation with Jana from ProdPad about that and how ProdPad had evolved from a simple roadmap visualisation tool into a workflow tool that's more similar. I think now to something like user voice in that there's a way for people to submit ideas. There's a way for product people to categorise, evaluate, link, and use those ideas as grist. For the roadmapping mill, I like ProdPad in particular because of that approach, they are very opinionated about how you can visualise a roadmap. So if you don't like the noun next later view, that's the one they stuck. So on the far end of the spectrum, aha is well-known and very, very configurable, very flexible, kind of like Jira in that way. You can pretty much make it do what you want,
Although I think you only do a time lit based roadmap. At least last time I looked,
Yeah, last time I looked there wasn't a now next later view, but the timeframes were very flexible. You could set whatever timeframes you wanted and that complexity of course comes with a learning curve and an administration overhead. And so that's a trade off between those two extremes. Some of the others, road Monk product plan, they're real popular. They tend, at least the last time I looked at them, they're very focused on providing a rich visualisation and a lot of options for visualisation. And I think if that's the problem you're trying to solve, I think either one of them would do.
Yeah, I mean I know personally none of, I've not found any of them prior, something quite as pretty as I want, but I think the prettiness you can create in PowerPoint, which is probably comes back to that flexibility after all. I think if it's a communication tool and something that looks good is easier to have a conversation around, I find
If you think about a roadmap, as we said at the very beginning here as a strategic communications tool, well, there's a reason why people use slides for that because you can also include any ad hoc other information that you need. You can spend six slides on the customer and their problem and your vision for solving it before you get to the roadmap slide.
So I think we've explored quite a bit of my next few things I'd normally go to, but maybe we could highlight what do you think are the best practise, the single best practise on roadmap, the single worst practise on a roadmap and hit? Maybe
The most important thing in a roadmap is that since it is meant to communicate the context and the why of what you're doing to a broad audience, to pretty much everybody who has any sort of stake in your product, then it's got to tell a story. It's got to say, look, we are here and there is a journey that we're going to go on and we are going to be there and it's going to be awesome. That's the job of the roadmap. And if you're doing a traditional features and dates, timeline oriented roadmap, often that's completely missing. If you search for roadmaps on the web, most of them are complete gobbledygook. You have no idea what they're talking about. It's a lot of acronyms, it and a lot of jargon that you're not going to be able to follow, and it assumes that the audience is on the inside of your team or that there's somebody there to explain it all, but a lot of 'em are also extremely information dense.
So it's going to be some product person for an hour explaining every last little thing and putting the audience to sleep. No story. That was my first attempt at a roadmap. It was exactly like that, and it just put people to sleep until I learned that all those details can be left into the appendix if you've got a good story and then you can use them to answer specific questions. That's both the best and the worst in my mind. The best is let's tell the story and then let's worry about the details later. The worst is here's a million details and you're left to yourself to connect the dots.
Wonderful. So Bruce, now you are clearly one of the people whose advice people go to and listen to with the book, et cetera. So whose advice do you listen to on roadmapping?
Well, that's a great question. I've actually been really impressed with how a lot of the product community has taken up the message on how to do roadmaps. And so I get examples all the time, people seeking feedback, but I'm seeing lots of great examples of now next later roadmaps of thematic roadmaps. And so I am taking my cues from the community at this point. It's difficult to name any one particular source, just collecting good examples for the next version of the book.
Yeah, so you hint that before we talked?
Yeah, so the publisher has asked my co-authors and I to work on another version of the book, and we're planning on working on it later this year for release. Next year we'll be updating the examples, clarifying the text, and covering a few topics that have been the subject of questions since the book came out, like portfolio roadmaps for example, and also clarifying the link with OKRs. So I'd invite anybody in the audience who has a good roadmap example to reach out to me. My email isBruce@productculture.com because I would love to hear from you and maybe we'll feature it in the book.
Cool. And funnily enough, it's a shout out we're planning on doing in the near future as well to gather some ideas, some good, bad and ugly roadmaps as well. So what do we have? I'm sure we'll fire across to you Bruce as well. It feels like I might have to have a second edition of a book on my shelf. That's a rare thing. So if you listen to the community, it sounds like the resources you look at are the things the community are producing, but are there any particular other resources or sources of inspiration you look to?
Well, there is a whole community of terrific practitioners writing books that I super admire over the last year or two. For example, David Bland's book on testing, business ideas, fantastic book, Jim Callback's book on jobs to be done, and his O'Reilly book on mapping experiences. Another really good one, I'm just going to my bookshelf now to grab some other books, radical dts, radical Product Thinking, a terrific book about sort of thinking past iteration to what's the next big.
You're getting that big picture, if I remember rightly, everything been aligned around that, as you talked about vision earlier,
Right? And of course, escaping the Build Trap, Melissa Perry's, excellent, excellent book that is a hundred percent consistent with this whole, let's solve the right problem and let's measure the right thing, not let's just ship the feature and move on to the next one. A hundred percent consistent with that thinking. There's also some great organisations out there for product people to get together. Mine's a product, continues to be an amazing conference. They just did a hybrid version of the conference fairly recently on the west coast, and one of my favourite little conferences is the Business of Software Conference run by Mark Littlewood and Company First conference I spoke at in over a year with the pandemic going on. Spoke there in person this spring when they had it in Cambridge, England. So that's a small, intimate one. Highly recommended though because you get to really have a conversation with the speakers, with the other attendees highly recommended.
Cool. So Bruce, I'm going to get to the hard question now. If you had to distil your philosophy of roadmapping down to one or two sentences, what would it be?
Can I do it in three words? Tell your story that encapsulates that. My thoughts about the worst and the best practises,
And I love that distilling now. I think I spoke for about two minutes and then distilled it down when I came up with mine. What's yours? I think it came to one version of truth, multiple views or something along those lines. One of the reasons I quite like tools because I can have that one tool to manage it all, to keep it consistent, but I'm probably still going to render it in PowerPoint to give me that deck that I can communicate around. But I want to keep everything lined up and on the same page and create different views for those different audiences.
I'm a big fan of what you just described. I get the question all the time, should we have multiple roadmaps? And my answer is no. Really no. I want everybody to hear that same essential story that here's our vision of the future, here's how we're going to get there. And then however, every different stakeholder has different details that they care about about that, right? The engineering team wants to know, well, okay, but which features are we working on? When your best guess and when are we going to retire that tech debt? And the marketing team wants to know what are we going to be able to demo at the conference in three months? And the sales team wants to know, when do I have something to sell on down the line? And so the way I try to accomplish that different views approach is the first few slides in my deck are the same for absolutely everyone. That's the half a dozen slides that tell the story. And then I've got maybe one slide of details for each different stakeholder that hang off that initial story, that provide the additional granularity that they're looking for in their particular area. But for any given group, I'm only showing seven slides, even though my deck is like 25 slides because of all the different stakeholders.
I come back to a simple thing, communications to get across the audience, what the audience needs, what the audience care about, and in the audience's language. So there's going to be different ways of presenting it potentially to different people.
That's true. You can explain it differently based on, as you say, the language. Most people, even all around the world in lots of different countries seem to speak English, and yet we are all seem to also speak different languages.
Indeed. So I have one final question for you, Bruce. What should I have asked you about road mapping that I haven't?
So one of the things that we got asked about very often after writing the book and after doing a bunch of workshops with people, is there a template for a good roadmap? And we actually have a download on our website, which is sort of a do it yourself evaluation of your roadmapping process. And I think people are so ingrained with the idea of a template that they go and they download that with the idea that it will be a template and they're like, this is a PDF. I was expecting a PowerPoint file, but I think the content is so much more important than the form here that we all agreed, my co-authors and I, that we would not provide a template because we thought it would be misleading. We thought it would be too much of a shortcut, and people would bypass the thinking and just go, well, I'm just going to fill my features and jargon and acronyms into this form and I'll be done, and that'll be my roadmap. Kim Goodwin said to me when I explained this, she said, maybe to be a real product manager, you have to make your own lightsaber. And I think
I like that one. I mean, I think Jana in her discussion said, A roadmap is useless. Roadmapping is invaluable. To kind of paraphrase the planning. Yeah,
That's another good paraphrase. I like that.
So Bruce, it's been wonderful talking. Just like to give you an opportunity to, I guess make a pitch for yourself, what you offer, your services, how people might get in touch.
Sure. Easiest way to keep in touch with what I'm up to is on my website, product culture.com. You can sign up for my nano letter. That is, it's a newsletter that's so short, it's quicker to read it than file it in your read later folder that you never open literally on many people's phones. You don't have to scroll to get the whole thing because it's called one thing on product culture. It comes out every Thursday. And so whenever we have a new product, a new offering, a new service, whatever, we always announce it there. A couple of things that are coming up in the future. I mentioned that there'll be a new version of the roadmaps book. I'm also working on another book called That Working Title is Aligned and it's about stakeholder management. So if roadmaps, OKRs, discovery testing metrics, all those things are the hard skills of product.
The soft skills of influence without authority are probably the most important ones for product managers and something that a good roadmap would help you with. Unfortunately, they're also the least taught for product people, so I'm looking to fix that. So my co-author, Melissa Appel and I are hard at work. We've already signed an agreement with O'Reilly for the book. It'll come out next year. And I will shortly be announcing on my newsletter that we're going to be looking for early readers to beta test everything with us and contribute to the book. So watch for that.
I'm sure it'll be making Its worth my bookshelf. Thank you for coming here. I really enjoyed it. Great conversation. A little bit longer than I expected, but that's because there's so much good stuff to talk about. And I wasn't going to cut anything short. Just a reminder to our audience, we'd love it if you liked shared, subscribed, followed, all those good things just to spread the word. And if you'd like to be aware, Bruce is and take part and have a conversation about roadmapping. Get in touch as well, either through talking roadmaps.com or info talk king roadmaps.com. Great to have you, Bruce. Thank you for your time today talking.
Yeah, thanks for having me. Pleasure.
