Unlocking a More Strategic Product Roadmap using Agile

Welcome & Speaker Introductions

Roger Snyder | 00:00:00–00:00:18

welcome everyone i’ll give just a moment for folks to join before we begin

Roger Snyder | 00:00:18–00:00:32

when i see the attendee number kind of level off we’ll get started so just a few moments

Roger Snyder | 00:00:32–00:01:15

all right let’s get started welcome good morning good afternoon good evening wherever you may be in the world my name is roger snyder and i’m the vp of marketing here at Productside thank you so much for joining us today and today we’re discussing the topic of unlocking a more strategic product roadmap using agile first off let me just point out and go ahead and do the answer to the next slide you may have noticed a change in our presenter today unfortunately kenny couldn’t join us at the last minute due to a family emergency but david nash has graciously agreed to join and step in today so i’m excited to introduce david nash our vice president of products and services here at Productside tell us a little bit about yourself david and why you’re passionate about this topic

David Nash | 00:01:15–00:02:10

hey thanks roger and welcome aboard everybody uh it’s nice that the attendee thing filled up here once we push the open the webinar button it’s great to be back with you today and it’s my pleasure to step in for our colleague who couldn’t be available you know as a product leader i’ve been dealing with road maps for most of my career roadmaps are really our calling card as product leaders so i’m very comfortable uh sharing this content with you i’m excited we do this this is just the kind of a heartbeat of product i’ve led product for enough years before joining Productside where i had to be a champion of the road map the purpose of it and hopefully we’ll share some of those best practices with you thanks roger and welcome aboard everybody

Roger Snyder | 00:02:10–00:02:40

excellent yup and so as i said before i’m vp of marketing i’m based here in the santa cruz mountains in california uh and have been involved with Productside for five years now but in the realm of product management and product marketing for 25 years

Housekeeping, Q&A, and About Productside

Roger Snyder | 00:02:40–00:03:45

all right let’s get to a couple of housekeeping items before we get into the meat of this after this webinar we recommend that you continue to stay engaged with the product management community by joining our leadership group on linkedin we’ll paste the link to that into the chat box in just a moment and at Productside we love interacting with you so we want to make this webinar as interactive as possible so you can ask questions and we’ve got a little link here to show you down in the q a box please put your questions in the q a box you can chat as well but the q a box is where i’ll be paying attention to your questions and we would love to have interaction here so please put your questions in the q a box and we’ll leave time at the end to answer questions but we’ll also try to take questions that uh seem pertinent to the moment as much as we possibly can and i will try to unmute you and let you ask your question live or we’ll just read the question from the chat box if that’s what you would prefer uh the most frequent question that we receive is hey how can i watch this webinar later or share it with my co-workers and you will receive an email from us later after the webinar is over and once we’ve got the recording completed and it will include a link to view this webinar after after you’ve received that email so keep an eye out for that email and yes you will be able to watch this webinar later

Roger Snyder | 00:03:45–00:04:40

let me just take a moment before we get into the meat of the presentation to talk about what Productside is all about our mission is to empower product professionals with a knowledge and tools to build products that matter products that matter to your your customers products that matter to your company hopefully products that matter to the world now unlike other companies we are focused on just the needs of product professionals that’s all we do is help product professionals up their game and become more effective in leading product management teams so whether you need your help as an individual improving your knowledge and skills or you’re trying to improve your team effectiveness check us out at Productside.com

Roger Snyder | 00:04:40–00:04:55

all right david let’s get this party started why don’t you take over and tell us about agile and roadmaps

Agile vs Roadmaps: Friend or Foe?

David Nash | 00:04:55–00:06:10

thanks so much roger all right you know i was delighted when scott adam came out of retirement and brought dilbert back to life because i got to tell you gilbert is as relevant today as it was back in the day when the strip first started and dilbert and his pointy-haired boss have riffed on agile a lot over the years but i thought this would be a fun icebreaker uh so just take a moment you probably have seen this skit uh or this piece pardon me if you haven’t i hope you’ll share kind of the macabre humor around it uh the the fact i’ll cut to the chase for the rest of our time together uh the title of our session today of course is unlocking a strategic roadmap in the face of agile you might say even in the face of agile road maps are more important than ever and no you can’t just start writing code and then complaining about it so i know we’ve had our moments uh where we’d say the hell at the road map let’s do this other thing instead but that’s not going to work

David Nash | 00:06:10–00:06:55

and speaking of agile uh we’re going to kick off our first poll of this morning and we’d love to take your temperature quickly as to first off whether or not you’re doing agile and then secondly in either of those cases you know whether you are using a formal road mapping process today so roger’s open the poll take a moment to click in and then we’ll do a quick readout

Poll: Agile & Roadmap Usage in the Audience

Roger Snyder | 00:06:55–00:07:30

so a couple of different choices here hopefully you fit into at least one of these four choices uh we’re getting good responses here david this is great so i’ll leave the poll open just for another moment or two and then we will look at the results

Roger Snyder | 00:07:30–00:08:10

all right i’m gonna end the poll and share the results okay so number one response was folks have got agile development and road maps 70 68 of the audience said that that was their their choice 14 said agile development but no road map so we’ll be talking about that for sure then we’ve got you know the other 12 percent have roadmaps but no agile development yet so for those folks probably looking into agile is going to be an important thing and then six percent no agile development and no roadmaps so that’s even higher than i kind of thought actually so very interesting meet new so i think you guys can see the poll here so i think this will be important the rest of our discussion not just for the 68 of you who are doing roadmaps in in an agile environment but for the other 32 percent of you who are not yet uh hopefully we’ll have something in here for everybody thank you roger

David Nash | 00:08:10–00:08:25

all right so let’s roll forward

Why Roadmaps Still Matter in Agile Organizations

David Nash | 00:08:25–00:09:45

so you know one of the first discussions we we like to have is that road and agile have been kind of set up as adversaries and i’m here to tell you that that’s really not the case but let’s let’s understand some of the starting assumptions for each again agile just celebrated its 20th anniversary this year and even though we’ve you know companies who are uh embracing agile are really focused on delivery and backlogs and release planning and all that other good stuff uh that has been juxtaposed with road maps so let’s start with agile quickly here are the major tenets of agile number one i’m not going to read you the agile manifesto you can do that yourself but agile is intended of course to be really really flexible right so the the idea is things change and you know let’s focus less at first on building things right and ensure we’re building the right thing no change is our friend in agile and you know the idea is when you’re dealing with agile whether it’s you know your sprint plan your release plan uh deadlines kind of take on a different meaning here uh number one is the dates you know for deploying code or releasing features uh are are likely to change because scope has changed stories have changed or if let’s say you’re practicing agile and you have the release training methodology where we’re going to you know deploy code every two weeks we’re going to release new features once a quarter whatever it may be then you have the ever famous did your story you know make the release train or is it going to miss the release trainer i have to wait for the next one so either way uh deadlines start meaning a different thing and so we want to change that up here because this purpose of a deadline is often a self-imposed uh crisis and a self-imposed uh milestone that you kind of have to surrender to not fighting that battle

David Nash | 00:09:45–00:10:40

so so that’s agile on the other side road maps are very deliberately time bound now when i say time bound i don’t mean we’re putting dates on them we’re going to come back to that later and we’ll show you in fact a couple of different road map uh practices which express a continuum of time without necessarily dates on them but they’re about what are we doing kind of now next and later what’s our plan from here to the horizon uh and they’re reasonably rigid not in the sense that they can’t change at all but in the sense if they have some abstraction some construct whether it’s themes whether it’s customer value where those things are fixed and intended to be durable let’s say for the course of the year uh secondly unlike a backlog and a jira backlog uh they’re generally graphical visualizations or abstractions visual representations of things that are fairly high level and the intention again is that you’re committed to your roadmap so when your big customer says i need to see your roadmap you know for the next five years to make sure you’re the vendor for us and you respond let’s say with a one-year world map or or not even still there’s an expression of commitment that here’s our plan unless it changes so that’s you know so just juxtaposing these two things is really really important so you might say that these things are not meant to get together and not meant to be reconcilable i have to respectfully disagree uh an agile product roadmap is is incredibly valuable and i assure it even more valuable having that roadmap in the face of agile than in uh than in a non-natural environment

David Nash | 00:10:40–00:11:35

so here’s some reasons why road maps work for agile and why they’re more essential than ever uh really this there’s three reasons first off road maps a good road map should change now you’re not changing a run back every two weeks like your sprint backlog might change but road maps have to change in the real world right because the idea as i said a minute ago is not building the wrong thing just because you said you would right a month a month or a year earlier so road maps do need to change the world is not waiting your competitors are not waiting your customers aren’t waiting for you to do the thing you said you did if that no longer meets their needs roadmaps and backlogs and the other agile artifacts are each each very deliberately intended to cut through the crap and provide transparency right so you may say road maps are wish washy sometimes maybe they’re high level maybe they’re too soft uh and they’re not specific enough but the idea is if they’re done right they’re a very clear expression of what you’re doing who it’s for and why it’s important so let’s not confuse the two that even though a roadmap is higher level and focused more thematically whereas a backlog is focused more explicitly on delivery they’re both about showing your customers and the world what you’re doing and why and lastly the fact is you can’t escape long-term planning i don’t care how agile you are and i’ve led you know very very agile shops uh your executive staff your board of directors uh your shareholders at your opponent company they really need to know what they can expect from you about a year from now so you can’t escape it it’s inevitable this is one of the things that makes product management so fun is really you know trying to bring in entropy and trying to conjure up a future you can deliver against while things are changing more frequently so i’d like to say i don’t want to say we’re stuck with road mapping but we are stuck in a world that wants expectations from us beyond what we can see clearly and so we have to really embrace that does that make sense

Roger Snyder | 00:11:35–00:12:30

yeah and from the marketing perspective right you and i uh are our partners here at Productside having a product roadmap helps me plan well when am i going to do the next product launch right so they are necessary in in the uh ability to allow coordination across the entire organization as well as provide a strategic view of this is what what we as a as a for product for this particular product express as a strategic vision this is where we’re going to go right and i love it when you can abstract a roadmap to be about the key benefits that you’re delivering and allow then the agile engine when it’s running properly to be able to pivot as you need to in order to get the right features together that do deliver to that benefit right so i think that is how the two can definitely cooperate more effectively

Vision, Strategy, and Roadmaps (Alice, JFK, and House-Building)

Roger Snyder | 00:12:30–00:12:55

um and david we’ve got a question already if you don’t mind we can take a question now we’ve got a question from tyler do you use and actually let me allow you to talk tyler and see whether or not you if you want to unmute tyler you can ask your question directly

Tyler | 00:12:55–00:13:13

oh i’ve never had this before thank you

Tyler | 00:13:13–00:13:45

uh we we’re adopting an estimation tool that kind of gives level of confidence based upon features and and is getting some help because stakeholders are no longer saying so you said january right i said no i didn’t i um the type of thing right but anyways do you have any type of estimation processes or tools that you use that you would recommend along with road mapping

David Nash | 00:13:45–00:15:05

great question tyler uh here’s my lived experience and thanks for asking the question uh estimating uh is dangerous because you know we the last thing in the world we want is our product team or our engineering team signed up to deliver something they can’t do because they didn’t understand it and then get punished for it so i would say a couple of things here number one estimating uh is really good continuously not just once early on and whether you use small medium large hard medium easy risky or not risky whatever the t-shirt sizing is that you would use uh just just you know refer back to what we call the cone of uncertainty right which is that your estimations are going to be terrible at first you know until maybe you’ve done some research spikes you understand some of the unknowns so uh it’s good to do t-shirt sizing frequently especially for things that may be many months out but you have to have wiggle room and the road maps again should be sufficiently uh spaced out where you’re not estimating uh you know you’re not setting yourself up to fail you’re not making promises you can’t keep the estimating tool itself is less important uh what’s what’s really important is for the product team and the engineering team and the product leader and engineering leader to be kind of hand in glove and know that the engineers need uh to estimate work uh early the estimates will be terrible they’ll get better later and that stuff will serve your wrote your backlog of your release planning a lot more than it will serve your roadmap so that’s probably the best answer i can give you for now

Roger Snyder | 00:15:05–00:15:40

now i would just add that i want to emphasize david’s point that um you will get better at this over time whichever tool you choose so give it a chance try it for a couple of iterations and and hopefully you’ll gain some confidence in it and then that will give you a little bit more confidence in building your estimates and and what you’re going to be able to add into sprints but to to the earlier conversation try to keep the roadmap high level so that it’s about the benefits you’re delivering not any particular feature so that then when your estimates are going to be off there’s there’s less disruption that way hope that helps

David Nash | 00:15:40–00:16:05

yeah that’s a great point roger it’s a great question tyler thanks for bringing it if we have time at the end maybe we can revisit it again

David Nash | 00:16:05–00:16:30

all right so that’s why road maps are still important even in the face of agile and you know the title of our session this morning was how to unlock a more strategic road map so let’s push into strategy and the role that strategy plays in road mapping and at the risk of being repetitive you know what you’ll hear from me uh until our time today end is that the roadmap is a strategic tool uh it’s not a tactical tool

David Nash | 00:16:30–00:17:35

so let’s start off with strategy informing every roadmap we do you know if you read alice in wonderland uh which i did again not too not too long ago uh when alice first meets the cheshire cat and she says you know excuse me sir can you please tell me which way or to go from here of course the cat gets his usual snarky response says this quote here uh which is you know young lady and as you can see the quote here but the idea just want to bring it back to what we’re talking about is that you know if you’re planning for the future and you want to include your product plans in that future you have to have a sense of where you’re taking the company uh you know whether it’s you or whether it’s your executive staff your ceo you cannot do a road map in isolation you cannot do a road map based on features uh that’s a fool’s errand because if the road map is not intricately and intimately aligned with your corporate strategy you are doomed to have a road map uh which won’t be meaningful and even to execute against it you know it won’t necessarily advance your company’s strategy so start with the company strategy by the way as a long-term product leader i understand that sometimes we don’t personally form our company strategy we inherit it it might come from the c-suite it might come from some other place but for goodness sake we must start with with the strategic levers going into the road now

David Nash | 00:17:35–00:18:45

so let’s let’s click on each of these there’s three primary constructs that are kind of intertwined here uh the first and you know sometimes these come top down sometimes these don’t start at the top but they are amplified and then aligned from the top down so our vision is all about a point in the future not today that we can clearly conjure up and enroll our company and our customers in so visions are deliberately high level they’re powerful they’re clear and the intention of your your vision is to enroll again customers company uh intellectually uh emotionally in what we’re trying to get done you know if you flash back to john f kennedy president kennedy’s mission uh and vision uh in 1963 uh when nasa had just been formed the vision was all about before this decade is over we’re going to bring a man to the moon and return him safely to planet earth now that’s a powerful vision it was unambiguous everyone knew exactly what success looked like and the vision did not concern itself was how hard was this going to be when were we going to do it what was it going to take to do it so vision again by itself really really important it’s often said that vision without action is just a daydream and action without a vision is just wasting time but the two together are our powerful uh co-requisites to unlock uh the vision happening

David Nash | 00:18:45–00:19:40

strategy is what steps are you going to take to achieve your vision right so if we’re all bought into our vision and our company has a vision hopefully your company has a vision and you know what it is if you don’t know what it is it’s okay you would not be the first product manager to not be clear in the vision challenge you know challenge your manager challenge your c staff to make sure it’s their job to help the entire company know what the vision is and so you can share that with your customers but the strategy very simply is is the next step of how are we going to get there what are going to be our guiding themes what are going to be our guiding constructs and then the road map is really a visualization of that strategic plan i’m going to make this really simple for you because these are kind of ambiguous abstract terms my wife and i built a house a few years ago and i went through this exercise in a very deeply experienced outside of the work environment so we had a vision for this home we knew what kind of view we wanted we knew generally what kind of architectural style we wanted we we had bought a piece of real estate it was built on a grade uh with a grade fell away pretty clearly in the back but we didn’t want a big monster towering uh hulking house so we wanted a one level house so it was very sleek and low to the ground and we knew that because the grave fell away that we would probably have a two-story house with a daylight basement and we have this great view in the back we wanted a lot of light i live in portland oregon the pacific northwest is a little dark in the winter so we knew we wanted it to be bright and to bring the outside in that was our vision we didn’t even have an architectural plan all we had was a a a land uh uh a lot of land on a grade but it started with the vision

David Nash | 00:19:40–00:20:50

uh we then uh worked with our architect to understand the strategy what was the structure of the house looked like right maybe what kind of materials would we use all these things were informed by the vision constrained maybe by the vision but empowered by the vision is how i would describe it and we did kind of the first just just renderings uh we didn’t have a plan to build the place yet once you were agreed on the general structure of the house maybe the material for example we knew also was part of our vision we didn’t want to be wasteful we didn’t want to burn a lot of wood we were going to use steel for anything great so that’s part of our vision but nothing about the house plans yet but out of all of that vision out of the strategy about how to have the house fit the land how to use those materials we came up with a road map which was our blueprint of you know what the foundation of footings would look like and took it up from there so i use this example uh only to show that this vision strategy roadmap stuff uh it’s real it’s very easy if you tease these things apart to get clear on each of them and when you put them together you can have a roadmap that is really really informed by all the things that you need to do at work with your customers with the product line etc does that make sense

Roger Snyder | 00:20:50–00:21:20

before we move on david i want to uh entertain a question from srinivas and i’m going to invite him to unmute and ask his question hey sure welcome

Roger Snyder | 00:21:20–00:21:30

maybe he’s in a place where he can’t unmute so uh i’ll read the question for you then david how do you measure quantitatively the alignment of the agile roadmap with the company’s strategy goals and objectives

Strategy, OKRs, and Measuring Alignment

David Nash | 00:21:30–00:22:25

great question srinivas uh one of the best ways i found to do that is to again uh the roadmap you you know typically do once a year you might update a quarterly that’s a best practice your mileage may vary slightly but road mapping beyond a year uh is often difficult uh so snap a line once a year updated quarterly uh is is fairly uh is kind of the right cadence and then aligning it with the with the agile road map is really the purpose of your release plan uh and making sure and we’ll get by the way this we’re about five minutes from answering your question even in more detail but uh having the roadmap inform your release plan not just your delivery of pushing code into production on each sprint but the release plan would probably be the greatest uh manifestation of aligning what your team is delivering versus what the strategic intent of your roadmap is

Roger Snyder | 00:22:25–00:23:20

i would just add in terms because because screening was talked about quantitative as you are working on your strategy i think that’s the time to understand how will you measure success and you want to then connect those measurements for success whether it may be increasing revenue or it may be increasing customer satisfaction it may be helping a customer solve that problem more effectively in a quantitative way say reducing production time you then want to make sure that that is in the road map that you create the instrumentation to be able to then measure against that strategic objective right and i know david loves talking about metrics so i’ll leave it there for now but i think that yeah the so what as roger said it’s the so what so when we deliver this feature what happens so we need to couple you know a product outcome or a feature uh with a business outcome uh which is ultimately how does the world look any different how does our customers life get better how does our bottom line get better by delivering the thing thanks roger

David Nash | 00:23:20–00:24:25

all right so one more you know one more note on vision strategy and road map again vision high level and by the way if you don’t inherit this if you don’t know what this is and it’s very real for you uh you should create this for your for your product in the absence of a corporate strategy it’s way better to enroll the rest of the company and your customers in your product vision even if you don’t have a clear corporate vision at least the world and everybody on your team has a very clear sense of what they’re trying to accomplish and why it’s important so purpose and benefit at the top of the pyramid in the middle again is the strategy as rogers just said a minute ago focus on delivering value we talk about features hopefully not on the roadmap ever but we talk about value for customers on the roadmap when they when they for example if you are building enabling a single sign-on boy there’s a great enterprise platform people probably a lot of you have worked on single sign-on by itself it’s a feature but the value of single sign-on to a customer uh in terms of greater productivity lower i.t expenses all those kinds of things uh are really the so what around single sign-on so focus on the value uh your customer your business value to your company yeah be aware of the competitor’s position but don’t pop your competitors roadmap don’t play their game because it’s their game play your game uh be informed by your competitors but don’t chase your competitors uh when you are when you are uh ideating on your vision and on your strategy very often here’s the place where your objectives and key results will start coming in your objectives again are fairly high level like the one i mentioned about jfk you know having a manned moon mission before the end of the decade for a high level the key results are what gives us confidence that we’re heading in the right direction and we’re actually making progress towards that goal so that’s where the key results plug in by the way separate discussion on on ars that we’ve had in the past and we’ll have again and for today that’s how they target and then the roadmap will allow us to build a visual representation of how are you going to accomplish that broader strategy

David Nash | 00:24:25–00:24:35

so let’s let’s kind of move into some actual examples so there’s a roadmap from yes

Roger Snyder | 00:24:35–00:24:55

yeah um if you wouldn’t mind uh going back for just a moment but also there’s some comments that people are now hearing echo and i am as well hearing echo so i don’t know if you need to adjust your speaker or your excuse me your microphone but um all of a sudden you have a lot of echo uh is it any better now nope still have the echo i don’t know what’s going on you might check your audio microphone or check it in zoom in just a second you know what i’m going to do is i’m going to just change my

Roger Snyder | 00:24:55–00:25:35

there was a question about how do you align okrs uh quarterly with your your quarterly oqrs with the roadmap so i’ll answer that question while you’re fiddling with your mic and uh as this slide shows you should be using okrs as something that comes out of your product strategy and then becomes an input to the product roadmap so that in fact your roadmap is an expression of we’re going to deliver on these okrs with these particular benefits so there definitely needs to be that relationship between the two of them as this slide shows so i hope that helps answer that question but make sure that as you’re building your roadmap you are keeping in mind what are going to be the metrics of success connect those to the okrs so that those okrs and those metrics of product success are in fact going to be connected and feed each other

David Nash | 00:25:35–00:25:55

great point uh roger can you hear me now and is this any better

Roger Snyder | 00:25:55–00:26:00

much better

David Nash | 00:26:00–00:26:20

all right we’ve gone i’ve been channeling nasa early on so i’ve got the nasa headset on now just to make it complete

Example Strategy-Aligned Roadmap (ProductPlan-style)

David Nash | 00:26:20–00:27:35

all right so let’s let’s talk a little less uh theoretical and more practical so here’s a roadmap from uh a great product tool out there from a company called product plan by the way uh it’s a good tool there’s others out there and really this discussion is less about the tool and more about trying to give you a a real world example of the theory we’re talking about so here’s a road map uh this particular one by the way is uh broken out where different teams are in different swim lanes and this is one type of road map which is effectively uh which is which can often be effectively used internally when you want to express how you know what the resources in a company are being allocated to so here’s an example i’m not going to read you every box but let me call out the color coding and the color coding in this case ties from each of the things that these three teams are delivering down to why why are they doing these things so you can see some of the goals they’re five-fold and they range from enhancing performance all the way down to improving security so what a great representation right looking at some of these high-level features and deliverables or capabilities without going into the weeds about you know exactly how it works again this is not your backlog it’s your roadmap but what it does show exquisitely and simply is how these things correlate to the very important goals that you’ve ostensibly agreed as a team and as a company are important so i wanted to show this example because it expresses uh exactly what we spoke about of tying roadmap to strategy and goals

Roger Snyder | 00:27:35–00:28:15

i love how this shows you know for example the increased customer satisfaction goal how all three teams are going to contribute to that over time right and and based on your prioritization it appeared that an android app and customer outreach were most important but then later on adding in a self-service portal which is in a different development stream all together but this kind of allows you to see those goals and see how each team is contributing to them and it visually shows you what’s most important as well so i think this is a great way to represent a rhythm

David Nash | 00:28:15–00:28:30

agree and this is not the only way but this is a great way and the the real the real takeaway is the so what of all the things we’re doing and why they matter that’s the real key thing on your roadmap

Roadmaps vs Backlogs (and Epics)

David Nash | 00:28:30–00:29:25

so let’s now move into kind of juxtaposing the roadmap with two things number one are backlogs and number two our release plans again with a real focus on roadmapping in the context of other agile artifacts and ceremonies so first let’s talk about road maps versus backlog and at a high level uh here’s the way to kind of to keep from conflating them and keep them separate in your head number one as as we said earlier there’s repeating here uh roadmaps are about intention and aspiration they are not about delivery so let that sink in for a moment we have other artifacts around delivery but the road map is strategic again uh what and why sometimes for who there are thematic abstractions uh and they are intended to be a little more durable again my my lived experience says that the best practice is go out to about a year and leave yourself uh kind of a few different tiers between now and a year from now and i’ll give you an example of that in just a moment to to try to affect climate change of what you want on your product as well as dealing with the weather that’s going to pop up in terms of of things that cause you to change over the course of that year and generally this is tops down and it’s high level top down doesn’t necessarily mean from your executive staff in fact our job as a product team and my job as a product leader was to enroll them in our roadmap so it doesn’t start at the top but you want that uh leadership team understanding enrolled in your roadmap so they can propagate it outwards and align the rest of the company your sales team your customers in that same roadmap so that’s all about looking forward looking forward a little further out

David Nash | 00:29:25–00:30:10

the product backlog whether you’re using jira or rally or visual studio whatever tool set you’re using uh all have a few things in common number one these are all around delivery they’re all around execution they’re all tactical by the way if you joined our our webinar about a month ago on product manager versus product owner here again was something we talked about then and it’s kind of an evergreen topic is that these things are not different they’re not in opposition they are two sides of the same coin so they’re closely related but this is about delivery how and when uh this is an ordered prioritized set which is again a manifestation of your product backlog of what we’re doing now and what we’re doing immediately next and the sprint after that and it’s bottoms up in the sense that it’s it’s started by the product manager perhaps the product owner you know with 100 buy-in from your development team about executing so again generally will flow from left to right but these things are not in opposition they are very very symbiotic

Roger Snyder | 00:30:10–00:30:25

so we have a question from dennis about the relationship between epics and road maps and dennis if you are comfortable on muting maybe you can ask your question

Dennis | 00:30:25–00:30:47

sure i was just wondering if there was a relationship between the epics or these larger bodies of work and the entries in your roadmap you know whether the you know they they correlate you know they or um we often find ourselves working on an epic that happens to be a road map item so

David Nash | 00:30:47–00:32:00

dennis thanks for the question they actually do correlate although the correlation can be loose and it can vary tremendously from computer company so in epic you know before we go too deep down the agile rabbit hole here an epic is generally a higher level expression of something you’re trying to accomplish which might decompose and generally almost always decomposes into a number of stories that comprise that epic so you could say what what dennis did is that there’s a correlation between roadmap should never go below the epic level i would go a little further and say that you know epics may or may not belong on the roadmap but an epic will certainly decompose into a number of stories you know all of which would be expressed in your product backlog yeah i would just add that it can be depending on the scope of your product that an epic is a roadmap entry if the epec represents a key piece of functionality that’s that’s a benefit if you want to keep the roadmap focused on benefits then hopefully that benefit decomposes into a small number of epics which are more focused on the feature that delivers that benefit but the epic should certainly express the benefit and it is possible that it could be a one-to-one mapping but i would imagine it’s a one-to-one mapping or a one-to-few mapping in most cases yeah i know a great a great example thank you dennis for the question you know another great example uh since since i mentioned uh single sign-on earlier again for a b2b enterprise kind of epic you know there might be an epic which says you know allow single sign-on across our three major products man that’s fairly high level right so there’s a great example of something which might go on a road map around you know making being expressed in terms of the benefit in terms of making it easy for large customers to you know to authenticate to some of your different products now below that might be dozens of stories around you know what your authentication stack looks like what the login workflow will look like so there’s a good correlation and practical example of something which would sit on the roadmap and then decompose into things which appear in your backlog

Roger Snyder | 00:32:00–00:32:06

yeah did that help dennis

Dennis | 00:32:06–00:32:10

yes thank you

David Nash | 00:32:10–00:32:20

you’re welcome thanks for the question

David Nash | 00:32:20–00:33:05

so let’s look at another uh key thing uh it bears repeating the road map should inform the backlog but it’s not a one-way street right because as your team is is going through the backlog you’re probably doing some discovery as well you are refining your stories you are grooming your backlog you are uh

David Nash | 00:33:05–00:33:40

responding as a product manager a product owner to your team asking to improve those stories have better acceptance criteria all the things sometimes you will discover stuff just by managing the backlog and executing against it uh which may want to inform some subsequent days of your roadmap this may result from a deliberate research spike it may just result from something that team discovered that oh my goodness uh we have an opportunity when we’re fixing a single sign-on to do a bunch of things around better connecting our apps you know for for user reporting and those kinds of things so key point is roadmap informs backlog but there needs to be a feedback loop also and that’s why again if you’re sprinting kind of every two weeks which is a norm for for scrum and you’re updating a roadmap around quarterly that turns out to be a really good cadence for just making sure the two things uh don’t completely diverge and and separate from each other

Roger Snyder | 00:33:40–00:33:50

yeah stay aligned i think that’s exactly right cadences could not agree more

Roadmaps vs Release Plans

David Nash | 00:33:50–00:34:50

so let’s move now from road map and backlog to roadmap and release plan and let me riff on something that i mentioned a couple of minutes ago here again the roadmap does all the things on the left the why why are we doing this roadmaps you know can have a deliberate long-term uh horizon you know figure about a year uh if you’re asked to do a road map for more than a year uh it’s it’s tough and you need to have a lot of wiggle room and we’ll by the way we’ll we’ll share one of my favorite road maps in about five minutes the so-called now next later roadmap which which is an effective tool for that but even before you get there the roadmap again uh is generally something that you know you’re going to share not just with your sales and marketing team but with external customers as well and it’s high level this gives the rest of the company and your customers the knowledge and the confidence that you’re thinking beyond the end of your nose and you know you have a plan that’s going to uh that’s going to be the right plan for your customers into the future so that’s all the roadmap stuff

David Nash | 00:34:50–00:35:50

the release plan again critical agile artifact right you’re going to have your release cadence and i don’t know what it is it’s going to vary on your company it may be x number of sprints that you will release it may be time box where you’ll do a quarterly release plan the release plans that i found work best in in uh you know mature high functioning agile organizations are all around delivering value right now you may be deploying live code into production every sprint but the release plan would say here’s when that valuable thing from the roadmap is accessible you know by customers so this spans out you know not too many releases into the future uh i’ve i’ve found it’s a way to do a release plan really months and months ahead of time because there’s just too much change it’s going to be very low confidence that that thing is going to remain intact and this is internal this is kind of how we’re making the sausage this is very deliberate around internal stakeholders aligning people like roger and i for example as you heard a minute ago we work hand in glove because it’s not just important that roger knows what we’re planning a product but it’s essential for our team to know what marketing has planned for example you can count on Productside to do a black friday thing every year like a lot of companies so i want to know about that so we can get you know we can get lined up for new stuff for black friday so again goes both ways uh the release plan would be something that that roger or any marketing partner would be really really interested in and this again takes a strategy into specific features uh maybe new things maybe defect fixes all those kinds of things so different but like the relationship between road map and backlog the relationship between road map and release plan is just as important

David Nash | 00:35:50–00:36:20

so let’s look at a real world example uh here’s a release plan for you know typical product front end you know user facing uh stuff on the screen backend services and then what the qa team is going to be doing so here again you can see just like the road map and uh that we showed a couple of minutes ago this again shows the value around we’re even improving uh performance in in one of these one of these green dimensions we’re gonna make our product more findable you know via seo so you can see there’s things are thematically aligned with uh one or more of these categories and just like your roadmap our job as product managers and product leaders to make sure we’re delivering value uh periodically i won’t even say necessarily frequently but as frequently as necessary right to make sure that your roadmap is becoming real and the way your roadmap becomes real is by releasing things as depicted in your release plan

Dealing with Change & Stakeholder Expectations

David Nash | 00:36:20–00:37:45

all right so that’s those are kind of the three big artifacts so now i i want to kind of close out our discussions that we have plenty of time for q a with this notion of you know life happens so you know we used to joke that as a product manager and certainly as a product leader whenever i walked into the board room and we had that long oak table you know with 12 seats around it probably 10 of those 12 seats were filled with people who wanted something from me or from the product team that they were not going to get or maybe not get any time soon so uh that’s that’s part of our life part of our existence in product is making friends with change change is not the enemy change is actually our friend so when i walked into that room and 10 of the 12 people on that seated at that table wanted something that they were not going to get immediately uh first off uh i sometimes had to be the bearer of bad news only bad in that in the sense that it didn’t meet their existing uh expectations but my job is to bring them along uh be honest about it don’t apologize for the road map we own the road map it’s our calling card so never apologize own it and then document it and you know my very quick story here is that i would do an annual road roadmap better said my team would do our annual roadmap i would champion it to our executive staff and we knew we knew that when we did that roadmap in november or december for the next year it was our best informed guest and our intention but we knew life would change so we snap a line once a year we do all the t-shirt sizing here’s what it’s going to cost here’s what you’re going to get and then we knew that we’d have to update it quarterly so in our case we use something called product counsel you might have a different forum in your company but the idea was keep the roadmap changed and don’t carve it and grant it where it becomes a tombstone and you can’t change because if you can’t change you’ve already lost before you’ve started so these are some of the ways you do it you document it you bring people along and by the way at the end of the year here’s the best part at the end of the year when we reviewed our roadmap it wasn’t just a question of all the things we didn’t do that year but a much more powerful discussion around all the things we did that we said we were going to do all the new things we hadn’t even planned to do that we took on and in a lot of cases the new things we did instead of the things we planned because they were better better for our customers better for the company that’s a really powerful place to be in

David Nash | 00:37:45–00:38:45

so be direct you want to be empathetic you don’t just want to say no you can say things like we can’t do that now because we’re doing this other thing instead so again again getting very clear on strategy and people are going to complain to you there’s no question product managers are targets for complaints uh so all you can do is draw energy from it keep the keep the relationships really healthy so that people feel comfortable complaining to you and asking about the thing that they promised their customer the thing they think is important but you need to be very effective listeners we need to be uh have a lot of emotional intelligence and when the road map changes moving on the right column here our job is to make sure that we can tell them why so when they didn’t get single sign-on in q1 even though we thought we would do that a year ago we made this other change instead because and roger hit this a few minutes ago let me recap we either had something that was more important to more customers than that uh we had a big revenue opportunity uh maybe we had a product crisis maybe we had an all hands on deck thing because of some tech debt or something that blew up so we needed to do a whole student body left and abandon our short-term roadmap these things happen never plan for them but you always want to let people know if they didn’t get the thing they wanted what they got instead and why it was either better or why it was necessary and these are really really important but but you need to let people know that you hear them and you’ll be in constant communication with them not only when you give them the thing they want but when you can’t give them the thing they want right very important

David Nash | 00:38:45–00:39:40

uh so yeah and the last point here you know the things we can do to not just prevent these things but preempt them when we can uh and not just correct them when they happen is try to reduce the emphasis on dates i learned a long time ago again uh right after i learned that a product backlog was not a roadmap to take dates off the roadmap my goodness if you’re not doing that you should start doing that right away i’m not saying take any representation of time off your roadmap but but a roadmap the horizontal axis should always be some continuum of time but uh you are much more likely to miss your dates and get punished for it and it’ll give you it you’re setting an expectation that it’s almost always impossible to keep uh when you have very explicit dates on your roadmap your backlog has dates your release plan has dates uh your roadmap should not have dates make sure you vet that roadmap all the time that you again you update a quarterly it shouldn’t be hidden everybody in the company should know where the roadmap is and it should be sufficiently high level that you are not getting to get pinned down to some feature or some atomic particle you know being on the road map and again keep it fresh because your road map is sometimes obsolete the day after it’s published so this is the only way that you can turn the road map into a strategic asset and not turn it into a weapon that gets used against you

The Now–Next–Later Roadmap Framework

David Nash | 00:39:40–00:40:05

and with that as a segway i want to move into

David Nash | 00:40:05–00:41:40

my very favorite road map in the entire world now some of you may cringe when you see this and say oh my god there’s no dates on this thing but in fact that’s the beautiful part of it so let me let me describe a now next and later now and by the way we go into really great detail on this in several of our courses this is one of the product roadmap frameworks that i think is just so versatile now by the way is near term and now may mean let’s say the next 90 days the next quarter on the calendar so now is as close to an expression of commitment as you’ll get on a roadmap and and since we’re talking about agile today now generally correlates with the things that are currently in your backlog they’ve been sized they’ve been groomed they’ve been estimated they’ve been ordered so now you can you can say uh we’re doing this and it’s going to happen so it’s really close to an expression of commitment next is an attention is is an expression of intention next basically says uh at current course and speed based on what we know today here’s what we expect to do next notice in each case whether you’re talking about the here and now and commitment or the next horizon and intention we’re still talking about benefits about you know not so much just the feature but the so what and next and by the way i found next basically is probably the next quarter to uh the year so think of think of now uh as a good practical rule of thumb as the current quarter next is out to the the the end of the year so the next nine months so the quarter plus nine and an expression of intention and later is really powerful later is an expression of aspiration later you know could be a year from now and later is the place where you can dream later is the place where you can maybe go fishing uh with your customers and with your stakeholders and say you know here’s the stuff that we’re thinking about that you probably even haven’t thought about yet and asked us for and what a great construct for us to provide thought leadership when we’re talking with customers and colleagues about the things we’re thinking about that are over the horizon so this is your lowest competence this is done here specifically to provoke interaction provoke engagement and provoke feedback from your stakeholders so later was where i went fishing and this was great for us because it informed the things would then move into our bound of intention and later move down into the the realm of the stuff we’re actually building customers love this stuff because when they’re when they’re looking for vendors they want to know you’re thinking about stuff that they’re not even thinking about yet and that builds tremendous confidence with you as a supplier

David Nash | 00:41:40–00:41:48

all right so uh change is not the enemy changes your friend so uh let’s break out let’s break out to another poll now

Tools Poll & Practical Tooling Discussion

David Nash | 00:41:48–00:42:40

uh and uh roger and i would love to know uh if you’re using a product management tool like aha product plan or any others uh if that’s if that’s what you’re doing today uh if you are more agile focused on boards uh trello jira rally uh if you’re doing it old school in excel on powerpoint there’s no wrong tool here it’s not about the tool but we just want to understand kind of what the practices are uh if there’s some other tool dropping in and if you’re not using something today i think it’s time to start but let us know that as well so roger released the hounds he’s down it’s already been released we’re almost there in terms of getting good responses and this actually helped answer one of the questions i think i saw in the chat box which was uh you know what tools do you use and these are some of those categories right uh when i was doing product management 20 years ago the tools were terrible but be honest right but now aha product board product plan really do provide great product management tools and they integrate well with jira and rally which are more traditionally development tools um so let me share the results here uh you know it is what i kind of expected the center of gravity is still xl and powerpoint right 38 okay but jira and other development software sure you can put your epics in there right maybe you’re using confluence in in correspondence with jira but it’s great to see that now 25 of our audience are using software designed for the product manager themselves right

David Nash | 00:42:40–00:43:15

area of focus which is fantastic yeah thanks roger and thanks for uh all our attendees today for your input and again it’s not about the tool at Productside we use a tool called asana asana is really great it’s kind of a heartbeat of how we coordinate with each other and get clear on dependencies and deliverables it’s not great for road mapping but you know what it works as good as anything else so i use it for road mapping there too so that roger and all the other colleagues know where to go they know what the road map is it’s a live living breathing maintained thing so whatever the tool is make it work for you

Key Takeaways: Four Big Wins from Strategic Roadmapping

David Nash | 00:43:15–00:44:40

so uh we’re coming up on the end of our time together let’s tie up everything i think we spoke about number one roadmap is all about goals and outcomes and value not about features features are the province of your release plan your product backlog etc strategy must inform your roadmap otherwise it’s just an ad hoc unrelated uh nice picture so strategy first corporate strategy if you know it even if you’ve inherited it product strategy which is ours to create number three roadmaps are around having a discussion they’re about storytelling they’re about getting people enrolled intellectually and emotionally and letting people all know we’re heading towards and how you’re going to get there leave the details off the map they can only work against you when you put details on a product roadmap and lastly embrace change change is the only constant today particularly in the world of product management if you do all these things you get four big wins the first is much better collaboration not just within your product team but with all your stakeholders and with your customers when they know where you’re heading uh they’re much more likely to uh let you know whether they’re heading in the same direction or whether you need to change direction it helps understand the why we’re doing some things and equally importantly why we’re not doing other things or why we’re doing things in a particular chronology the roadmap becomes much more powerful for your sales team for your marketing team for your customers and everybody everybody will have greater confidence that we know what the heck we’re doing uh we have a plan and this is the direction we’re heading in and they’re going to be much more able to help you row uh and get you in the same direction

Roger Snyder | 00:44:40–00:44:55

yes totally agree

Roger Snyder | 00:44:55–00:45:10

all right so with that uh let’s open uh the q a for any questions we haven’t hit already uh roger what do we have teed up

Q&A: Agile in Hardware/Manufacturing & Convergence Points

Roger Snyder | 00:45:10–00:46:05

so in the interest of time i’m just going to read some of these questions um because i want to try to grab as many as we can bob wilkins asked how do you apply agile within a manufacturing environment more specifically more and more hardware projects have got software components right so how do you bring those two things together and if you don’t mind david and i’ll just give my quick answer when i look at where we were doing both hardware and software we had convergence points so we we still ran the hardware business on a waterfall style roadmap because there are long lead times for tooling or for dies right but then every two months or every three months there would be a convergence point where the software sprints would have to line up and there would be times where the two would interact you would need something from software to be able to test the hardware and vice versa vice versa so you had these convergence points where the sprints would line up so they would deliver something that the hardware would need and then later on to the next convergence point the hardware will provide a new basis for the software to operate as well so ram the software using agile ran the hardware using waterfall and use these convergence points to be able to sync up periodically so i hope that helps bob

Roger Snyder | 00:46:05–00:46:20

thanks bob for the question by the way we’ll also answer questions afterwards uh when the uh webinar is published we’ll have questions there uh answered as well

Roger Snyder | 00:46:20–00:46:35

yep and i think the last question that we’ll take is from from jim who asked from a change management perspective and we get this question all the time how do you get leadership who want a time-bound roadmap to get comfortable with the now next later roadmap

Q&A: Leadership Buy-in & Time-bound Roadmaps

David Nash | 00:46:35–00:47:40

oh what a great question i knew that i had arrived so to speak when my ceo didn’t fight me at my last company about now next later and i knew i had arrived for the second time when he said no to a customer a big powerful customer to their thing because it wasn’t on the roadmap so really from change management gym the long and short of it is go back to some of those soft skills that we covered about five minutes ago make sure you’re enrolling your stakeholders let them know that change is not just your friends it’s their friend and you’re gonna have to make tough trade-offs uh that’s why those of us who are in product or drawn to it uh it’s not for the week and uh but you gotta bring your your uh your leadership team along through constant listening letting them know you understand and letting them know that you’re a steward of the company and you’re going to make the tough decisions that no one else is going to be able to make

Roger Snyder | 00:47:40–00:48:25

yeah i’ll just add jim that when you start setting your goals to be about achieving objectives rather than about time frames that also gets management more comfortable because then they they will see there’s a dashboard they will see there is a metric of success and agile allows you to get to those metrics of success more effectively so over time having those metrics of success also really helps

Roger Snyder | 00:48:25–00:48:40

all right well thanks for the questions everybody

Closing Remarks & How Productside Can Help

Roger Snyder | 00:48:40–00:49:35

yeah great questions and uh lots more there so we will follow up probably with a blog post to answer some of these other questions but if you’re interested in getting help to transform your team we’ve got experts available to help you nicole will put a link into the chat box for this but contact us we love being able to help organizations with private custom training optimizations and assessments as well as provide some strategic advisor services so thank you so much david for covering what is often a contentious conversation i hope you brought some light to the fact that agile and road maps they live together they can work together and they can actually support each other to deliver great products

David Nash | 00:49:35–00:50:05

thanks roger thanks to the hundreds of people who joined us today and we’ll talk with you soon bye have a great afternoon have a great weekend

System (Webinar) | 00:50:05–00:50:08

you