How do you use a roadmap to align with stakeholders? | Melissa Appel
In episode 54 of Talking Roadmaps, Justin Woods interviews Melissa Appel, a product management expert and coach. Melissa shares insights on leveraging roadmaps to align with stakeholders, emphasizing the importance of communication and collaboration. She discusses practical strategies for engaging stakeholders, overcoming common challenges, and the significance of continuous alignment in successful product management.
Melissa Appel has 20 years of product management experience at companies in various industries, stages, and sizes. She is currently a coach for product management executives, focusing on process improvement, team development, and stakeholder management. Before that she was a director of product management at Wayfair, in their fulfillment center and supply chain technology group. She’s he co-author of "Aligned: Stakeholder Management for Product Leaders," co-written with Bruce McCarthy.
Here is an audio-only version if that’s your preferred medium - and you can access it through your favourite podcasting platform if you prefer (Apple, Spotify, Amazon).
In the next episode we are talking to Maartin Dalmijn, he is a consultant, speaker and trainer. So watch out for Season 1 - Episode 55!
-
- Hello, everybody, and welcome to the Talking Roadmaps Channel. My name's Justin Woods, I'm one of the co-hosts here, and today, I'm joined by Melissa Appel. Melissa, welcome. Please introduce yourself.
- Hi, thanks for having me. I've been doing product management for about 20 years, mostly in B2B or internal products. I've worked in a variety of different industries and stages of companies, and I am currently a product management coach, and I'm writing a book on stakeholder management called "Aligned".
- Very nice, and very topical at the moment with a lot of things that are going on in product management, alignment is really important, right?
- Yeah, for sure. Yeah, people think that you just have to check the boxes, make the roadmap and deliver it, and like you're done. But that's not the whole story.
- If you're enjoying the channel, subscribe, hit the bell icon, and give us a like. Absolutely. It is just one part of the problem and the puzzle. So, Melissa, why don't we start with one of the most fundamental questions, which I think is what do you think is the purpose of a roadmap?
- I always think about a roadmap as a communication tool. So, it's not necessarily exactly what you're gonna do or detailed plans or what features you're gonna deliver, it's how you document the alignment with your stakeholders. So, it's the end of a process, not the beginning of a process. It's a way to tell a story to communicate what you're doing and what you're not doing in a way that kind of gets everybody on the same page and reflects conversations that you've already had.
- Yeah, I like that. And in fact, what picking out of that that really struck with me was it's the end of a process. All too often, it's the beginning of someone's, dare I say, strategic process. And actually, that's just missing so many important pieces of there as well. So, the end of the process, oh, I really like that. So, if the roadmap is the end of a process and it's a communication type tool or vehicle, who do you think is the audience of a roadmap?
- I would say pretty much everybody who's gonna be working on the product and everybody who's going to be impacted by the product. So, you wanna make sure that the people who are working on it understand the vision and the themes and what you're going after, the prioritisation of what you're working on now versus next or later. And then, the people impacted to make sure that their needs are represented, that there's not something that's completely missing or making sure that you're solving the biggest problems that the whole company needs to solve. I go back and forth about whether or not roadmaps are for customers. Some companies have public-facing roadmaps, which hopefully are a little bit de-detailed, if that's a word. But I think roadmaps can be a useful customer tool, say if you're in a call with a salesperson and you can explain what's coming up, I think that's really helpful. But I think, mostly, I've used roadmaps as more internal tools.
- Yeah, that makes sense. I think there's a lot of different audiences there. Sometimes it's the right tool to use. Sometimes it may not be the right tool to use. We can set expectations with customers without using a roadmap. Maybe just a list of priorities, but I love the fact that it's there to set expectations with a number of different people that need to be involved. I think that's a polite roadmap. Who do you think then would typically own the roadmap?
- I would say product management should own the roadmap, because product is a hub, a facilitator, a connector of all the different teams, and you can't go and create a roadmap off in a bubble, and then come back and be like, all right, this is it. You need to involve everybody. And since that's the product manager's job, I think it makes sense for them to own the roadmap. Now, of course, some people's roadmaps look like a list of features, which isn't really a roadmap, that's a delivery plan. I know that the product manager should own that flavour of quote, roadmap, but the way I think of roadmaps as a communication tool, as a document of alignment, it makes sense for the product manager to own that.
- Yeah, it does. And you mentioned about it being an alignment tool. Have you found, again, through your research in the book that you are writing, that there are other ways to align people that maybe are better than the roadmap sometimes?
- I think that the ways that you use to align people are not a roadmap. The roadmap is the documentation of that alignment, but it's a conversation piece
- Right.
- as well, because you say like, here's what I think I've heard. Is that right? Is there something missing? So, I think it's a check on your alignment rather than a method to align.
- Yeah, I think too many people treat it as a, this is the sacrosanct thing that we are doing and everyone else is a spectator. And actually, again, to pick up on your wording, it's the end of a process and maybe the start of a discussion.
- Yeah, for sure. And so, there's also, the roadmap isn't one and done. At the very least, you're gonna need to add on an additional quarter every quarter, otherwise you run out of room. So, it needs to be updated. And I think that how you update it and how you communicate that and how you work with all of your stakeholders to figure out what's changed, what's new, what have we learned, and incorporate that into the updates is also important. So, it's also, it's a living document.
- Yeah, exactly. I think that's where I certainly, in my experiences, it was not so, it was more of a static document and it was far too long. It was almost the worst of all worlds. It was static and 12 months long, or 18 months long. But yeah, I think that's a great observation on it. And so, if the product team own the roadmap, you mentioned around the maintenance of that, who do you think maintains the roadmap? Is that still with product management?
- I would say so. I talked a little bit about kind of updates to the roadmap. And because those updates require all the collaboration that product managers do with all the stakeholders and the technical teams and the customers and the market, that any number of those areas could provide a change that needs to be reflected on the roadmap. And so, maintaining it and updating it and improving it over time, I think would also fall with the product there.
- I'm gonna go back to that again, the favourite quote that you mentioned, which was it's the end of a process. And so, if the roadmap is the end of a process, what needs to fit up before that and what's the roadmap's relationship to those, do you think?
- I think it's a matter of, a lot of people create roadmaps for the first time when there wasn't one. A lot of my coaching clients are like, "Yeah, my stakeholders keep telling me they need a roadmap." Like, yeah, you need one. So, I think the process to create the roadmap in the first place is a little different than the process to update the roadmap. And regardless of how long your company has been in existence, it's possible that you don't have a roadmap still or don't have a quote, proper roadmap. And so, you need to create one or maybe somebody's come in and realised that the roadmap is all wrong and they need to create a new one, so those kinds of processes. So, before the roadmap, I think is the discovery process. And you can put discovery items on the roadmap, because it is a communication tool. We're not just developing code, we're doing these other things too. We're learning. But really figuring out, okay, if we already have a product, what is it? How's it doing? What do people think? How do customers like it? How is it performing? How is it selling? How are people receiving it? How much money is it making? Is it profitable? And to try to figure out, okay, well, what are the problems that we're trying to solve? My favourite question as a product manager is, what problem are we trying to solve? And I ask people even just in random situations in my personal life, like, what problem are we trying to solve? But I think back to another question that you haven't asked me yet, but that you may, is on objectives and strategy. And so, you need to line up what you are planning to do, what you're hoping to accomplish, what outcomes you want to drive with the roadmap. And so, defining those is something you need to do first. I think some people try to do it the opposite. They're like, okay, well, we have this roadmap, what then are the objectives that we are trying to achieve? And I think that that's the opposite. It's like, oh, we have all these great ideas. Okay, what do we hope will come out of it? It feels the opposite to me.
- Yeah, it does. And one thing that you're saying there is often, the first thing that you get asked for is the roadmap. It's almost like a product management right to passage. Is like you get asked for a roadmap and in many cases, it doesn't exist. That was certainly for my case. I came into when I was at Vodafone and was asked for, come up with a roadmap, and I didn't have one to inherit yet I inherited a mature product. And it's almost like sometimes that's the wrong conversation to be having. And it also assumes that everybody understands what a roadmap is in terms of your stakeholders know what they think it's going to be, and you create what you think they wanted to see. And that's often gives us so much latitude to get into hot water as well, because it might have actually been the CEO or the head office says, Melissa, I want to see the roadmap. And actually, you just come up with a list of initial problems that you think need be to be solved and some initial discovery phases on what you're gonna do before you've even done that. And it's so tempting to try and impress people at that level and come up with some authoritative roadmap and actually, it's not doing us any favours.
- Yeah, I think it's useful to ask, what are you expecting out this? What would you like to see in a roadmap? Or how... I'm going to give you a roadmap. I'm interested in how you're going to use it, rather than like, why do you need this? So, a lot of times, you're right, people don't know what a roadmap is or they think they know what a roadmap is and the sales person asks you for a roadmap, could be asking you for like, when their list of pet favourite features are going be delivered, like give me some dates. Other people might be thinking of completely different things. So, rather than trying to create something that's pretty and has lots of colours and deliver it, it's helpful to figure out what it is that they're actually looking for.
- Yeah. I wish I'd spoken to you about 10 years ago when I first needed that bit of advice. So, you mentioned a little bit about the presentation of a roadmap and I think that's a nice segue into maybe a little bit of roadmap design. You also mentioned now-next-later earlier as well, so maybe that will reappear. But what do you believe are some of the key elements or content of a roadmap?
- I think it's always helpful thinking about a roadmap as a living document and something you're going to revisit periodically. Having the vision, the objectives right on there I think is helpful. Let's just remind everybody what we're hoping to achieve. And having that connected. I've seen roadmaps that have, maybe there's three or four objectives and they either have swim lanes for each one or they have some sort of coding for each item on the roadmap as to which objective it's going after. I think those are really helpful to put things in context. Definitely timeframes. It may not be exact dates, but at least quarters maybe, or now-next-later, or this quarter, next quarter, and to be considered later. You need to know what order you're doing things in and approximately how big they are. And then, the items on the roadmap, the items themselves, which are hopefully more problem-oriented or thematic, but sometimes it's helpful to have a couple of larger features or initiatives on there if it's something that you know you are working on. I like to see discovery topics on there as well. A lot of people say like, oh, well, we estimate the engineering time. We don't estimate product or designs time. I think putting discovery items on the roadmap is helpful for that. Say like, hey, listen, we can only do so much research at a time. I know you wanna see all of these things and we're not with any of them. We're gonna prioritise what we're even investigating, 'cause we can't do that all at once. And then, the last thing that I think is really important on a roadmap is some sort of disclaimer. Things may change over time like a cone of uncertainty. We're like, we're pretty sure what we're doing now. As you get further out, like, I don't know. Just to set expectations that even if you have an 18-month roadmap, things like 18 months from now are very likely to change. And if they don't change, that means you're not responding enough to environmental factors.
- Absolutely. And I think that's one of the biggest challenges about roadmaps is that people don't see them change frequently enough. And so, because of that, they have an increased confidence that they're static and they are not changing. And I think that's one of the biggest challenges there. They're not revisited enough, they're not changed enough, so that people then get a false sense of confidence in them. The other bit that you mentioned, which I love, is discovery on roadmaps. I think we need to be much more transparent around what a product function does and that we are not just delivery, in fact, we really shouldn't be delivery just solely. And so, that transparency shows that we are busy doing other things and that the roadmap is, there is a level of capacity there, where we are doing a load of validation on these things. And that's important, especially, Melissa, with the frightening statistics you see around the number of features of the work that gets unused. I think it's more important to show that we are doing our due diligence and not hiding behind just shiny new features.
- Yeah. I've also seen roadmaps that have, right, so you put something on a roadmap and it's in say, this quarter, but I think a lot of stakeholders assume that at the final day of the quarter, customers will have it. And that's also not necessarily true. There may be some sort of onboarding process, there may be some sort of launch process, there may be some sort of release something. And so, to think about, okay, there's like discovery, and then there's the actual developments, and then there's some sort of ramp up period. I remember at Wayfair, we had this big discussion with the finance team, 'cause they're like, okay, at the end of the quarter when you say you're doing the thing, we should have money to reflect on. It should make a difference on that day. Well no, because that's when we're done creating the thing, but then we have to roll it out and people have to use it. And then, we start seeing the impact. So, trying to find a way on the roadmap to say like, okay, we have this thing that we're doing, this initiative, this theme, this problem we're trying to solve. There's a discovery period, there's some sort of development period, and then there's sort of a launch period in which people start using it.
- That's right. We start to see the metrics change. It's not gonna be from day one. I've used to call it benefits realisation in my roadmaps. I've seen using different terms, but I think it's right, there are some lagging indicators, which is where people start to use that change. And I love the fact that you are building that into your roadmaps, because again, that's the transparency that people need to show that product management is a learning function and that things aren't just about delivery.
- Yeah, it's transparency and clarity. Because two people look at the same document and have different interpretations, that's a problem.
- Yeah, for sure it is. So, you mentioned a little bit around how, what the key elements you like to see on the roadmap and how you like to visualise and staff it, and that deeply resonates with me. Are there any tools that you prefer to use to manage or visualise your roadmap, things that you go back to time and time again?
- I always say when you're creating a product, any product, you have two biggest competitors. One is do nothing, like they're just not gonna solve their problem at all. And the second one is spreadsheets. Because you can do so much with spreadsheets that have nothing to do with numbers. It's a grid. I know that there are a lot of really great road mapping tools out there. I think part of the reason that I haven't used any of them is because I have had problems getting the funding at the companies that I've worked at, which maybe is my problem for not selling things well enough.
- It's difficult though, because they often are like, well, you've got the corporate suite of office tools and everybody else uses those, so what do you need?
- It's hard. I think working at a very, very big company makes it hard, because they like to standardise and stuff. And working at a very, very small company makes it hard, because there's just not that much money.
- I think there's nothing wrong with a humble spreadsheet. Even though I've worked with different tools in past and even work for tooling companies, I think it's to work with the tool that's most appropriate for the maturity and where your company's at at the time. And if it's a now-next-later roadmap with the big problems that you're going to solve, there's nothing wrong with doing that in a spreadsheet. In fact, one of my favourites is to use PowerPoint or Mural or Miro, because you can style it in the way that you want, surface the data that you want in a way that is meaningful to the company. And not every tool can do that. So, there's lots of things out there, but they might not just solve that immediate problem. So, yeah, I'm totally with you. Talk to me a little bit about, I dunno, some best practises in road mapping that you see. And I think we've covered some, so if you wanted to pick those back up again, then feel free to, but what do you think is a best practise in road mapping?
- Well, I'll pick something back up that I talked about before, which is to make it a collaborative process.
- That's one of my favourites.
- Yeah, you shouldn't go off in some room somewhere and make a roadmap and then come out and share it like a magic show reveal. It doesn't make sense, because immediately, you're gonna get, oh, well I was expecting to see this or why didn't you have that? Or what does that mean? And I feel like the best practise is to work with your stakeholders along the way and even review the roadmap with each one individually and ask for feedback. And so, when you bring your group of stakeholders or executives or whoever you're presenting to, they should have already seen it. This is a good practise with meeting with stakeholders anyway in a group is that it's a confirmation and not a brainstorming session. So, I find that when people do this kind of big bang reveal, it never really works out the way they hope.
- I think that's great. I've just made some notes here. It is a confirmation, not a presentation. And I think that's right. It is around, let's talk around this and discuss rather than let you sit down and grab the popcorn and I'm gonna present the roadmap that I've created on my own and this is what we're doing. Yeah, I think that's great. And so, what maybe one of the biggest mistakes is that people don't do that. Is there an anti-pattern or a bad practise that you regularly encounter when you are working with your coachees or the companies that you work with? Any sort of bad practises that you see them doing with road mapping?
- I'm thinking about this. I think the big bang reveal is probably the biggest bad practise.
- And what about a pet hate that you see on the roadmap? Is there anything that you really despise to see?
- I think really specific features. So, if it's clear to me that you could solve the problem in any number of different ways, but you've already picked one without starting to work on it yet, it feels like you're pigeonholing yourself. So, why would we do it this way for sure when we haven't even started working on it. Maybe that's gonna be technically difficult and we may wanna change course, but we've already promised this specific feature. So, that's what we have to deliver. Even if we learn along the way, it's not the best solution.
- And so, actually, you mentioned something there, which was really important, which was the collaboration side of things. Do you think, and I wanna talk a little bit more about your book and where you've come from in terms of "Aligned". I think collaboration is one of the, or communication is, it must be a big part of being aligned with an organisation. Do you find that as a common thing within the research and the documentation that you've done?
- Yeah, absolutely. I think it's communication, but it's two-way communication. I think even bringing it back to roadmaps. If you think about like a roadmap update, whether it's monthly or quarterly or whatever, you can't just present what you've learned and say what changes you are making. You have to figure out if any stakeholders have learned anything. Check in with sales, see how it's going. Check in with customer support. See if customers are complaining about some new thing. And so, I think making that communication two-way is the most important thing you can do.
- And maybe that's something as simple as changing the wording that we use. Instead of maybe quarterly roadmap updates, they should be called quarterly roadmap conversations in order to just to frame the intent of that meeting. And that bi-directional nature I think is so important. 'Cause again, I see it as very much a one way thing. And I think that's one of the biggest mistakes that actually a roadmap is to capture what we all know to be true and what we all can kind of, not necessarily agree on, but align on. And it's the beginning of a conversation. So, Melissa, you work with two of my favourite road mapping people actually, with Bruce McCarthy, but also with with Phil Hornby, who I've spent some time with as well. Who's advice do you listen to? Typically I'll listen to those guys and many more, but is there any standout people that you listen to for road mapping or even product management advice?
- Lately, since I've been working on the book, I've been reading a lot about trust and relationship building and negotiation and influence.
- Yeah, it makes sense, 'cause really, product management is obviously a discipline and a part of a company, but actually, there is so much more that it embodies with people and the processes and the tool side of things. And then, you can go deep into psychology and often we have to, because a lot of product managers have to influence without authority. It can be a really tough role. So, I'm assuming some of that is what you've also covered in the book.
- Things like Kim Scott's "Radical Candour", things like Kahneman and Tversky about how we are irrational thinkers. Amy Gallo wrote a great book called "Getting Along: How to Work with Anyone, Even Difficult People". And it's things like that the quote, soft skills of product management. How to get along with people, how to negotiate. "Never Split the Difference", something that I read recently that's great. Yeah. And those sides of things I think are critical, which is why I'm writing a book.
- Absolutely. I think that's really important to know the people and who you are working with. I think that's gonna be something that transcends any type of role that you perform within the company. So, yeah, that makes sense. What about some sort of road mapping or even product management resources? Are there any that come to mind that you typically recommend?
- I mean, I do recommend Bruce's roadmapping book to everybody.
- Me too. It is one of my favourites.
- I think podcasts like this and Lenny's podcast, I think certain Slack communities are great. Like Lenny's Friend Slack and Rands Leadership Slack are really great communities where you can find loads of information and get feedback really quickly on things, specific things you're struggling with. As I'm writing a book, you can read a book, but it's also helpful to get feedback on your particular situation. That's why Slack communities or coaches even are helpful to help you figure out how to fit in what your day-to-day issues are into the theory, more or less.
- Yeah, big time. I think it's... Somebody mentioned in a previous episode just speaking to clients, your coachees, the things that we learn from them being within their organisations is an incredible resource. So, I wonder if you had to distil your philosophy of road mapping into just a couple of sentences and that's often a hard ask, but how might you summarise road mapping as your philosophy of it?
- I would say, if you think of your roadmap as a communication tool, if you think of your roadmap as a documentation of alignment you've already generated, then the roadmap becomes a manifestation of the agreement you have with all of your stakeholders as to what you're working on. And it does change over time. And so, the roadmap is not only a document or a living document, but it's part of a process.
- I'd love to give you an opportunity to share with our audience how you help them. You are tackling some pretty gnarly subjects around alignment and road mapping and things like that. Tell our audience what it is that you do and how you can help them.
- Yeah, so in my work as a coach for essentially heads of product, your title depends on the size of your organisation, a lot of the work that I do is helping the head of product sell the road mapping process to their stakeholders. And so, what I mean by that is, they have an idea of, okay, I need to do discovery and I need to get alignment and I need to create a roadmap and I need to work with engineering. But the executives are still coming in and saying, I want this, I want that, this customer is asking for this, you need to do this. And everything just falls apart. And so, figuring out how to talk to each of your different stakeholders from their different points of view in, it's sort of a meta question. You have to align on the process of aligning before you can do the actual aligning. So, working out, hey, we're gonna create a roadmap. Here's what I think it should look like and we're gonna have these processes around it and everybody needs to actually participate in the process and here's how you participate and here's how you influence the roadmap and here's what to expect. And selling to different types of stakeholders means that you have to understand where they're coming from. Tell the story in a bunch of different ways. It's the same story, but you're appealing to what different types of stakeholders' motives and incentives are. So, to sales like, hey, if we can focus on certain things, we're gonna have an intake process for you, where we're going to periodically check in with you and see what you need, but interruptions in the roadmap actually slow us down. And so, if we can have a more organised process to take in your needs and to consider them and to work with you on prioritisation, then we can let the engineering team focus on what they're working on and we can actually speed up the delivery. So, thinking about how to sell that to different audiences in terms of what they need and what they want, I think is critical there.
- Melissa, how can people get hold of you and how can they get hold of your book?
- Yeah, so "Aligned" is coming out hopefully in May. I don't know when this podcast is airing, but we've written it with O'Reilly and it is available right now for pre-order on Amazon and other bookstores.
- Amazing. That's so exciting.
- If people are interested in product management coaching, they can go to productculture.com.
- Melissa, all that leads me to say is thank you so much for spending time with us. I've thoroughly enjoyed speaking with you today and talking roadmaps with you. I always learn new things when I speak to different people and that's the beauty of this. So, even speaking today, I've got some favourite quotes that we're going to feature there. But thank you so much. I hope you've enjoyed your time with us.
- Thank you. I have. Thanks for having me on.
