Best Practices for Product Roadmap —Jeff Lash

I spend most of my day every day with folks like you with product management leaders and their teams hearing about the challenges they have the problems they're facing and helping them sharing research that we've done looking at what high performing product teams do sharing with them advice and guidance to help them improve their performance and there are a lot of topics that we cover a lot of issues that come up from product teams like how to better understand your customers how to manage a product portfolio how to better price your product how to work effectively

in an agile environment but roadmaps is the one that comes up that to me is sometimes the most interesting because when product teams have problems with their roadmaps usually the issue is not what's actually in the roadmap and I tell them the same thing I'm going to tell you here I cannot tell you what to put in your roadmap I'm not an expert in your market I don't know your customers I don't know your competitors hopefully you do but the challenges that teams have with roadmaps are not about what goes in the roadmap it's how

that roadmap is documented and communicated and that's really where the crux of the problem is for many of the teams that I work with you've heard a lot this morning and already this afternoon about all the things you should be doing to get an understanding of your market understanding of your customers test things but if you don't communicate that and document it well and communicate it with the various stakeholders then your product strategy won't be successful so I have four goals for you for this session today I want to help make sure you understand why

roadmaps lead to confusing conflict often because of the way that they're documented because the way that we what we talk about when we mean a roadmap where roadmap should fit into the broader lifecycle I'm going to share with you four key tips and then the fourth step is actually something for you to do after you leave my hope is that you're able to apply these principles probably not later today or tonight but probably Monday when you get back to the office so we need to start with a definition of what is a roadmap I'm gonna

give you ten seconds to think about it on your own and your head come up with a definition you're certainly welcome to close your eyes given that we're in the middle of the afternoon that could be dangerous but think about how you would define a road map I'm guessing there are probably some words that were part of your definition maybe something like vision or strategy like direction or future our kind of ideas about where the product might go as it continues its lifecycle and evolution when I ask this question to different audiences I get very

different answers and I don't mean different audiences of product managers I mean different folks within different areas of the business so for example the typical response when I talk to a product manager is something like this right the road map is a vision of how the product might evolve to meet needs and strategy then when I talk to a salesperson they say that the road maps a guarantee and a commitment of exactly what will be delivered I'm guessing you've experienced this before right so this is part of the challenge our definitions of road maps are

different across our different groups you work with and when you think about it there's many different ways that our road maps used and that's part of the challenge right just internally within your own organization this is not a complete list but a pretty good sample of all the different ways road maps can be used right your engineering team uses it to plan capacity and what technology projects they need to work on marketing should be thinking about how is this going to impact our campaigns and what we're going to do when we you know go to

market with this sales as I mentioned obviously it uses it a lot in retaining customers trying to get new customers right there's a whole bunch of different internal audiences that have uses for the road map and you can see slightly different uses and then we get to your external audiences and I work mainly with b2b organizations so we deal a lot with large companies that have partners that have long term customers that are making major purchase decisions so they want to know what's the strategy in the roadmap going forward before we make a purchase decision

or partners that you have to integrate or influencers like analysts so the problem comes when we have one single roadmap one slide one deliverable that we try to use for all these different purposes so here's this one common example how many of you have had to this present your roadmap to the senior leadership team at your company right okay so usually that's the vision right you want to seem like a competent product manager you want to seem like you have a vision you have a sense of where your products going so you project the vision

and strategy and maybe you're asking for money maybe it's part of an annual planning exercise and then meanwhile that same roadmap might be used by your sales team to try to entice customers to buy or stay right and this is where we get into conflict because obviously if they're expecting as I should be earlier I'll promise of what's gonna be delivered that's not what your roadmap was intended for so we need to start with a definition of what a roadmap is and I think sometimes it's easier to talk about what it what a roadmap is

not right I'm just showing a couple examples here these are all actual scenarios I've encountered I've seen a lot of teams in the past couple years start to adopt product management tools or agile planning software so they think oh well just press a button exports great that's my roadmap and it's really just a list of all the JIRA issues or all the user stories you have it's not a list of what sales needs to close things that are in the pipeline I had one product manager I worked with that literally she said there's a bunch

of stuff on the roadmap and I said do you really think you can get this delivered in so you said no but if it's on the roadmap and then it doesn't get delivered then it's not my fault it's development's fault so there's a whole set of other issues going on there which we won't talk about today maybe the engineering talk we can talk about that later and the last one I'll just point out that I talked to a lot of teams that are using agile and I'd say the majority of the clients I work with

are in agile development environments they say oh we don't really need a roadmap because we're agile we're moving fast and that's a whole separate fallacy for another day but the reality is as I'll show you regardless of the environment you're probably going to need a roadmap for some purpose so let me talk about how we define a roadmap and where we see it fitting into the broader product life cycle this is a model we developed that we use with our clients to help them understand the a best-in-class process for innovating for bringing offerings to market

and managing them throughout the lifecycle it looks at how do you take an idea you get approval and agreement on it build it and then launch it and make it successful in the market you probably have a process like this that you're using in your company maybe not this exact one but something that talks about you know incubate design-build launch manage or something like that so we're not going to get into the details but I just want to point out one key difference from a roadmap perspective we actually have two boxes on here the boxes

represent specific activities and deliverables we've got two boxes representing roadmap first is what we call a product roadmap product Robeck comes before you've actually start building the product or if you're talking about the next version or next evolution of the product before you actually start developing it and we define the product roadmap differently than what we call the future roadmap which comes in that growth phase let me explain the difference the product roadmap is really a short term view that is based around what we think we can actually deliver it's based on a plan for

what we believe we can bring the market usually in the next six to twelve months with some decent level of certainty it's not a commitment it's not a promise but at that point we should have an idea of what we think the needs are that we're going to fulfill in the market what market segments we're going after and what problems we think we're gonna solve for customers in the near term separately we need to have a future roadmap the future robot is that vision when Gibson presented this morning he talked about that long term vision

for Netflix right you know when they were so sending DVDs out by mail and what 2004-2005 right there was this long term vision that we're gonna be streaming we're gonna have original content right that's part of that future roadmap the future roadmap is that vision so I think when I talk to product managers a lot of times when they think roadmap they think more of that future vision where as sales and marketing and development oftentimes they're looking for that more near-term product roadmap now the reality is is as I'll show you in a minute these

are not necessarily two distinct separate deliverables right you're you have an overall roadmap that looks at the entire vision lifecycle for the product just the first part of it might be more certain and definite which is your product roadmap and then you still have that future roadmap that gives you that vision the future the reason that I think this distinction is really important is because then for those purposes where you do need to share your roadmap with sales with customers with partners you can have a product roadmap that there's a certain level of certainty around

there's a certain level of definition in detail but you can still also have that future roadmap that's really your roadmap that gives you the vision and maybe that's shared with a much smaller audience and it has things on there that are much more speculative much less certain but give you that direction for where you want to go in the future so now that we've defined or at least how we define what a roadmap is let's talk about some of the problems we see this is a safe space we are all friends here so we could

admit that we have all probably made some of these mistakes I certainly know I have this is a I'd say a typical road map how many of you have created a road map that looks something like this at some point in your career okay this is an anonymized aggregated version of many many many roadmaps I've seen so first we've got a very specific timeline that to a salesperson or executive kind of give some level of certainty you know we're looking at the next six months and this is exactly what's gonna happen month by month well

maybe we don't actually have that level of certainty maybe those are just the dates that were on there we thought oh we have to present that but in many cases though timelines presented on road maps give you a level a level of certainty that really isn't there we see a lot that use technology right so we're going to upgrade to version 7.6 sp3 I have no idea what that means there's probably some people in the company that knows what it means but many of the people that are looking at this roadmap may have no idea

same with Web Services well if I ask a developer what a web service is versus a customer for someone marketing I'm gonna get very very different answers so just saying oh we're gonna do Web Services and it starts here and ends there doesn't really communicate a lot in fact it probably raises more questions than it answers most or most Road are organized into what we call swim lanes right think of a pool and you've got the different lanes that you swim in so this is an example of what I see a lot which is where

road maps are organized based on technology and this makes a lot of sense if you're talking to engineers who think in terms of technology but if you're talking to a customer they don't really care about cm4 integration versus a platform reboot right they don't even know what those things are so we're using language that doesn't make sense to our audience my personal favorite is when we put development timelines on road maps that external parties see when does sales care about when what date does sales care about on the roadmap when it's delivered right they don't

care when you start they don't want to know when you start they just want to know when is it going to be done when can I start selling it customers want to know when is it going to be available so by saying that this project starts in May and ends there gives a whole lot of detail that a people don't care about and also provide some level of assurance that really isn't there that assumes that the developers are available to start on that date that assumes that the project actually takes this long it doesn't take

this long right there's a whole bunch of assumptions that go into here that people will make inferences about that we probably don't want them making those inferences about it provides this level of certainty that something's when we were released in the middle of June when actually it might be October I see a lot of roadmaps I see this less and lately but a lot of times roadmaps are folders on features and design this came up this morning a little bit right we want to focus not certain on the technology we're gonna deliver features and functionality

but we want to focus on what problems were solving and I'll talk about in a few minutes and might probably actually I lied my favorite favorite part is this part here the text is really small that's intentional right you usually bear it on the bottom so for those of you up there back there that can't see I'll read you part of it it says this roadmap is intended for use as a guideline and for informational purposes only and represents our current view of the product direction blah blah blah subject to change without notice blah blah

blah we use an agile development methodology blah blah blah right this is the cya statement cover your I think that translates well to Europe right I can guarantee you that when your salespeople present this roadmap they cover that or they take this part off the slide and I can guarantee if you if you talk to an angry customer who's upset that something wasn't delivered on time and you tell them oh well there was that box and the roadmap they don't really care they're probably gonna cancel anyways right so the point here I'm making is that

as I said I can't tell you what to put on your roadmap because I don't know your customers I don't know your market but I can tell you that all this great thinking that you're doing all this great customer research all this great strategy work you're doing that goes into creating the roadmap gets completely destroyed if you don't document your roadmap well and present it well and communicate it well so that's what we're gonna talk about I've got four specific pieces of advice the first is around the time horizon and by that I mean there's

some sort of timeline right you saw January February March et cetera you can have different views of your roadmap for different audiences and different purposes and I would advise you to tailor how specific of a timeline you give based on a number of different factors so for example do you have a good track record for meeting dates if you don't don't put dates on your roadmap I worked for the company and they said look Jeff we've got a problem you know we produced our roadmap and people don't believe that we can actually deliver and I

said well what's your track record for delivering on time they said pretty bad I said well then I would not expect you to deliver on time right so there's there's no law there's no product management guru that came down from the mountain with tablets that says thou must have dates on your road map how important are the dates everyone wants to know dates but is it really a necessity or is it more just I'm curious I asked do you have agreement on the road map right you can use your road map for different purposes for

getting discussion and getting input or for communicating decisions so if you're in that discussion and input phase you probably don't want to put dates because your focus is more on getting the ideas out there is the road map going to change or even a fast-moving environment have you already done estimates with your development team right all these different variables depend on how specific we get and then here I can just show you a couple examples right so based on these factors based on where on on the towards the left or right you fit you might

have a different view of the road map so if you think that if you if you come out and say look you know we can probably provide a lot of specificity around your time horizon the great then maybe month-by-month does make sense but if you really have no idea if you're all the way on the right side of the slide then maybe it's just now soon and later and I've seen some people start to do that and that may be appropriate for some audiences as a default recommendation I often give people is the two two

and two rule which is two quarters two halves and then two years right so the time nearest to us we can probably find a lot more detail I hope you know what you're working on this month and this week and maybe next month and maybe a little bit less detail the quarter after that and probably a little bit Leslie till the half a year after that so that middle option is probably a good default starting point but certainly based on this you know we want to vary that as needed the second is how we group

things right to those swimlanes how we group items communicate something to our audience if we group based on technology then they're gonna think technology but if we group on other areas other factors and they're going to think about something differently so there's a bunch of different ways you can group I'm just going to do a quick overview of these and these are not again the only options but these are the most common ones I see so one of the best ways in many cases is to do it based on a problem or a need or

a benefit we heard this a couple speakers mentioned this already today right let's talk about problems not features right so for example you know the the need is we want to help our clients process invoices more quickly or improve their ability to diagnose patients so if you can talk about this is really helpful because it forces the whole organization the whole team to think about how are we helping people with these problems you also might have specific product strategy objectives you know we want to expand into new markets or we want to decrease our support

cost and let's talk about all the different things we're going to do to support that so if you have those specific objectives and you're choosing items for your roadmap to meet those objectives this can be a great way and it can also make sure that you get alignment from your internal stakeholders around are these the are these the strategies and the objectives that we want to focus on if you're using okay ours as I've seen a lot of people start to use okay hours of their team this can be a great way of doing it

because it helps you reinforce that thinking around your objectives and those key results you're trying to meet you might be focused on different market segments right so we have certain things we're doing for the financial services sector or certain things we're doing for the education sector or certain things we're doing for specific countries so if the roadmap is structured around benefits for those specific market segments or geographies that can be a great way to approach it as well I've seen a lot of teams start to do this by persona I worked out a product that

we had two very distinct in different personas that had very different and sometimes conflicting needs so we thought about quarter by quarter or released by release what are we doing for each of our different personas and if you have items on your roadmap that are going to provide benefit only for one of those specific personas it makes sense to organize it that way and it also helps again you focus so you're not trying to do a little bit for everything all the time you can organize it by the different aspects of your product so for

example what are the things that we're doing for our account information section versus our credit card terminal versus the you know the search section this is I would say probably maybe you it's not as ideal because it's a little more internal facing than customer or external facing but if you have a large complex product and you have lots of different components this can be a good way to think about it or if you have an internal audience that's very familiar with their product again they understand what those differences are versus showing this to a customer

may not make as much sense if you're trying to do a portfolio roadmap and look at all the different roadmaps across different products right we can have different rows that represent different products this is particularly useful if you have enhancement or change in one product that will be impacting another one so when I see teams that have lots of complexity and lots of platforms and shared services and things like that they oftentimes want to have their roadmap documented this way so they can make sure that you know if we're releasing this thing in June we

want to make sure that this other part is delivered in April so we can bring it to market and then lastly there are certain situations where you might want to organize your roadmap by technology right so what are we doing for the mobile operating system versus what are we doing for a certain platform this makes a lot of sense to developers and when you're talking with engineers this is a good way to do it and especially if you're trying to align your roadmap with the engineering team now obviously there are going to be different audiences

and these are going to different work work differently for different audiences so this is not to say that you need to have one version of your roadmap and pick one of these the components that are on your roadmap would be the same but you might and probably will need to have different views of your roadmap for different audiences I like to think of it as different views and not different versions right different versions implies that we're actually showing something different to different people you know I'm going to show you that we're releasing something in June

and you that we're releasing something in July and that's not what this about think about having kind of a master database of all of the things that you're doing with your product and then just based on your audience and your purpose you're gonna show different levels of that information you're gonna use these factors to decide how we organize it and what's actually displayed the third element I've kind of alluded to already and again some other speakers this morning talked about it so this is great reinforcement we want to focus our roadmaps on benefit and value

and not on features as much as possible a feature describes what something is right what is it that we're building what's the output of the component but the capability is well what does that do what does that feature provide us what does it allow the person to do and the value is well what does that mean right why do I care about it what benefit do I get so as an example instead of saying we're gonna increase our storage capability to one terabyte let's instead say we're gonna solve the problem and allow you to store

more legacy data because that helps you fulfill an auditing requirement right that's what customers care about they don't care about how much a day-to-day store they want to make sure we don't get audited or if we do get audited we don't go to jail instead of talking about you know we're gonna we have a classroom management system and we're going to create some views that give instructors views into what's going on in the class well really the problem we're trying to solve is we want to give teachers better visibility of how their students are learning

in their progress they're making or instead of saying we're gonna build a mobile app well what problem is the mobile app solving what value is it providing the value is that it gives us the ability to access key information while we're outside of the office and we know that a mobile app is one way to do that so the other benefit of this is it gives you civility right if I say we're gonna increase capability capacity to one terabyte and our engineering team works and works and works and they can only get to 90 percent

of the way there we've already kind of painted ourselves in a corner we've already promised a certain level of data storage but if we say we're focusing on solving the problem of helping you avoid helping you manage audits and not get audited then it really doesn't matter how much storage we provide as long as it fulfills that requirement so in choosing the proper level of detail there's a couple of different variables we can look at again just like earlier right this is not a either or a black or white decision it's a it's a spectrum

and thinking about a number of different dimensions helps you decide how much detail should I share in my roadmap do you trust your audience right I've seen situations where product managers present their roadmap to a prospect and then the next day or later that day a competitor comes in and presents their roadmap and maybe that roadmap gets shared right so if we're in a situation where we don't necessarily know or trust our audience and how they're gonna use that roadmap we might need to be a little bit more withholding of information versus if it's our

development team that we work with very closely we can probably share a bit more how important is that detail again do they really need to know the detail are they just curious if a client's customer is planning a major technology implementation and it's hinging on having one key capability available in your product to make that implementation go well they probably need to know it but if they're just asking out of curiosity we probably don't necessarily need to provide that level of detail what's the purpose of sharing your roadmap are you trying to actually share the

status are you trying to receive input most product managers use the road map as a outward communication tool I'm going to tell you what I'm thinking I'm gonna tell you what we're delivering but the reality is in many situations a road map can be a great tool for getting input from other stakeholders internally and from your customers as well so if you're not if you're if you haven't decided yet what's in your roadmap are you trying to get feedback and input less detail can probably help because it will help enable those conversations and then lastly

is there not lastly there's one more is her internal agreement on your roadmap right if you've already had the discussions and everyone's on the same page that's great but if not you probably don't want to present that level of certainty and then last how likely is this roadmap to change right change based on internal factors or external factors if you're in a very slow moving market if it's pretty clear what you need to deliver if it's unlikely that a new competitor is going to come into the market you can probably be a little more comfortable

with more detail but if it's the exact opposite then you probably wouldn't be really careful about what you put out there so again let's just look at a couple different examples so a very low level of detail might be hey you know we think we're gonna help customers better monitor their health status well maybe in we're in our heads we know exactly what it is that we think we want to build but we're just not going to share that vs. we're gonna create a micro sensor embedded shirt that in real-time monitors your biometric data so

if we know that and we can say look we are pretty certain that that's what's going to happen that's what we're gonna build there's agreement on it it's unlikely to change we might want to share that information but we also might want to be careful about how much we share particularly with audiences that are a little bit more customer or market facing just because we don't know how this information might get out so those are the four key pieces of advice again I'm not talking about what actually goes in your roadmap because hopefully you've done

the work to understand what customers need and what your strategy and vision is but taking that information and presenting it well is really important so let me give you a couple just high-level examples of these principles in action so here's just an example of the roadmap now again a lot of times people will come and say you know can you give me the roadmap template I should use and if you've been listing I hope you understand there is no single template because it's going to change on all these different factors but as an example we've

got a timeline that looks at you know quarter quarter half a year year we've organized it in this case by persona there's also something really interesting about this roadmap there's a magic trick in this roadmap are you ready for it are you ready for it all right there is a no law that says your roadmap has to be a static one-page document right you can have animation you can have click throughs right just like there's no law that says you have to put timelines on it right so you can say look we're gonna have this

version of the roadmap that salespeople see or partners see but then we're gonna have this version the roadmap that I'm the only one who can present it or only our you know customer advisory board can present it and when we present the details of it we're not listing here's the 18 bugs we're fixing or here's the specific features we're saying look what are we doing and why right we're now rather than talking about a quarter one release we're gonna say we're gonna focus on compliance because that's the problem we're solving and here's what we're gonna

deliver and why and you can see as we go out in the future years right we have less detail so we know that exactly what we're gonna do in the first quarter of 2020 because there's regulations out there we know we have to fill this but sometime in 2022 we're gonna focus on graduate education we don't really know exactly what that means we just know that that's that vision that we have for the future so this is one example let me just show you quickly another example this is a more detailed example right if I'm

talking to my development team I might organize my roadmap differently I might organize it the way that they think about it because they think about the different systems they're working on they think about we've got a team that's working on reporting and a team that's working on search and a team that's working on administration now when we're working with developers we've have to provide more detail because often they want to know you know what is it we're actually going to build but it's a good practice to talk about why as well most developers I've worked

with when they come into the office they want to know why are they coming into the office what's getting them up in the morning right so and rather than just saying here's the five features you're gonna build we want to talk about you know we're going to do this because we're losing support or we know that we have customers using third-party tools so we need to integrate with them so again these are just examples of these principles in action so a couple key takeaways I think first make sure that you have agreement on what the

definition of a road map is because if you ask ten people at your company I guarantee you you're gonna get ten different answers the second is using road maps as this way of getting alignment and for gathering feedback it's not just a one-way communication you want to have that single source of truth and then have different views of it based on the situation and make sure you're spending a lot of time you're spending a lot of time doing research doing competitive analysis doing all the work that goes into understanding what goes into your roadmap you

want to make sure that all that hard work is not lost so that's probably the last piece of takeaway guidance that will give you you know although all the other speakers have been talking about some great things today and lots of guidance I think is really relevant you want to make sure that all that hard work that you do up front to understand the market and give yourself a strategy and a vision and all the work that you're going to do down the line to actually get that delivered doesn't go wasted and that's why having

a good road map is important so thank you for your time enjoy the rest of your day