How collaborative is roadmapping? | Roman Pichler

In episode 14 of Talking Roadmaps, Justin Woods interviews Roman Pichler, a renowned product management expert. Roman delves into the purpose of roadmaps, emphasizing their role in outlining product value over a specific timeframe. They discuss best practices for collaborative roadmapping, balancing short-term goals with long-term vision, and the importance of stakeholder alignment. The conversation also touches on practical tips for effective product strategy and agile leadership.

He’s is a leading product management expert specialised in product strategy, leadership, and agility. He teaches product managers and product owners, advises product leaders, and helps companies succeed with product innovation.

Roman is the author of three books on product management and one on Scrum. He writes a popular blog at romanpichler.com/blog, hosts his own product management podcast, and offers a range of free product management tools.

“I’m a big fan of collaborative roadmapping”

— Roman Pichler

Have a watch and if you enjoy the video don’t forget to subscribe to the channel, like it and maybe sign up to our mailing list!

Here is an audio-only version if that’s your preferred medium - and you can access it through your favourite podcasting platform if you prefer (Apple, Spotify, Amazon).

How collaborative is roadmapping? | Roman Pichler

Justin Woods and Roman Pichler

Next up we have C Todd Lombardo, author of Product Roadmaps Relaunched and a true expert on discovery. So watch out for Episode 15!

• Transcript

  - Hello and welcome. My name's Justin Woods, and I'm one of the co-hosts of The Talking Roadmaps Channel, along with my other co-host, Phil Hornby. Together we talk everything roadmaps from the good, the bad, and the ugly. We get to speak to real-life practitioners, experts, and some thought leaders in that space as well. If you're new to the channel, please do look through our back catalogue of other people that have spoken with us, see if there's some value there. And if you find value, please give that video a like or consider subscribing if you haven't already. Also, if you'd like to take part in the channel, then feel free to reach out to us either in the comments or drop an email over at our website talkingroadmaps.com, and we'd love to get you in the hot seat as well. Talking of hot seats, my guest today, he's a very special guest for me personally. He's a leading product management expert for the last 15 years and specialises in product strategy, leadership, and agility. I know I've used many of his concepts and tools in the past, so for many of you, he doesn't need much introduction, but today, Roman Pichler, welcome.

  - Thank you Justin. Thanks for the kind introduction.

  - Of course, I hope I did you justice, but I wanted to give you an opportunity just to introduce yourself to people that may not have heard of you.

  - I think you've said it all. So you know, my job is to try and help people ultimately create successful products, at least that's how I see it. So I work with heads of product leaders. I work with the doers, product managers, product owners, and train, offer workshops, training courses, books, blog, podcasts, various resources. And I've been doing this for quite a while. Yes, and it's lovely to be on the show.

  - Fantastic, it's lovely to have you here and follow YouTuber as well, Roman. So we're gonna link to your channel down below in the description, but yeah, fantastic to have you here. So why don't we get stuck in and get straight to the meat of the conversation today, which is obviously talking roadmaps. We're very passionate about roadmaps, but they're only a small part of, let's say, the roadmapping process. But maybe if we just keep it small for the moment. In your view, what do you think the purpose of a roadmap is?

  - What's the purpose of a roadmap? Yeah, that's I think a very good and very important question. So for me, I'd probably say the purpose of a roadmap is to allow us to describe what is the specific value that our product should create over the coming months. And so that timeframe I like to suggest is around about 12 months. If that's too long, then maybe more six months or nine months. Sometimes when there's hardware and plastic involved, 12 months is not long enough, and then we have to extend it and maybe go up to 18 or 24 months. But you know, Woods? The specific value our product should create and what are the specific outcomes or the specific goals that we'd like to achieve, that we'd like to meet. And by specific, I mean really something like we want to increase engagement by 3 to 5% over the next 2 to 3 months, for instance. And so in making those outcomes, making those goals, making the value, the benefits measurable. So that's, for me an important aspect, an important purpose of roadmaps. And the other thing I'd say is that a roadmap allows us to communicate and show how a higher level product strategy and what I would call a product strategy is likely to be implemented. A product strategy being a plan that maybe contains the purpose of why we're doing the product, something like a vision statement. Talks about the users and customers target group market, market segment talks about the needs or the problem that the product should address, the benefit it should offer, maybe stand out features and business goals. And I like to work with such a kind of higher level strategy, but in order to describe what's our approach to making the product successful. But it tends to be a little bit too high level, a little bit too coarse-grain, a little bit too vague than to really have these kind of specific outcomes or specific goals that we'd like to work towards. And that's exactly where in my mind the product roadmap comes in. So you can tell I'm a bit of a roadmap fanboy as well.

  - Yeah, great to have you on the channel.

  - At least certain types of roadmaps, I should say, certain types of roadmaps.

  - Yeah, and in fact, later on we'll talk about some of the pros and cons of those 'cause I think people fall into some anti-patterns or some bad habits, certainly myself, when I did. So we'll definitely come onto that. But I love the way that you positioned it there and also acknowledgement that really the roadmap that the duration or the cadence of that roadmap really depends on your product. It probably depends on where your product is in its life cycle and the type of company that you have as well.

  - That's right, yes, that's right. And it's one of those things in product management that often the answer is, it depends. And it's true, as you said, you need to look at the market, you need to look at the product, you need to look at the organisations that's developing and providing the product, and then determine what is the right approach for you. You know, having said that, I do think that, particularly in the product roadmapping space, when I think back to like 10, 15 or even 20 years ago, a lot of progress has been made. And I think we've got more, much better tools available today, much better templates, much better roadmapping approaches. There's much more advice available, which I think is brilliant, it's great. I sometimes envy people who come into the profession now and thinking like, well, when I started I was kind of thrown into this, I kinda fell into it. I guess the challenge today is that there's so much information available and sometimes it's hard to find out what is really valuable, what is really applicable to me and my product.

  - Massively. And the other thing I find, and I completely agree with what you've said, the other thing that I sort of found is that sometimes people try and take a model from a successful company that maybe worked 10 years ago, and they're working hard to implement that now, but their company isn't where that company was 10 years ago and things are very different. So I think you really have to carefully analyse these things and take what works for you and take some inspiration from those things, but trying to blindly implement, the Spotify model for instance, may not be the right approach. It really does depend, I think you said it well. Yeah, I agreed. So I think you've nailed the purpose of the roadmap there, and that really resonates with me as well. Talk to me maybe about the audience of a roadmap.

  - Yeah, that's another great question. So I like to... It's not only me, I think it makes a lot of sense to distinguish between an internal or private and a public external product roadmap. Some companies like to publish their product roadmaps and then the audience, customers, users, as well as internal stakeholders, people from the various business units, departments, as well as the development teams. And some companies have a preference to work with internal product roadmaps, and then the audience really will be primarily the key stakeholders, the internal business stakeholders and the development teams, and maybe the sponsor. So most of my work really focuses on internal roadmaps that essentially help people coordinate, help align the work of the various individuals and teams in order to create a whole and in order to create value.

  - Right, yeah.

  - So and I do think it's important to be aware of this distinction because I think in external product roadmap, you probably want to then be a little bit careful, with regards to certain types of information that you expose. So for instance, specific dates or you know, even specific features. If you want to use any features at all on your product roadmap, I'm not sure that that's necessarily such a great idea because you might make a commitment at an early stage that you may not be able then to deliver. So depending on who the audience is, that will influence the roadmapping approach and it will influence the specific product roadmap format that you choose, or at least the elements that go on the product roadmap.

  - Yeah, absolutely. It just strikes me that there needs to be, you need to think about what the audience wants to see, but also what you're comfortable sharing. I often talk about the circle of trust, and it might be that the product teams, which might be the UX teams, the development teams, you might share a certain level of information with them of what we might put as an internal type roadmap and then other audiences where sales and marketing might get different views of that. And then the external customer as well. I like what you said about the features, I think there is an evolution going on at the moment where we need to bring our customers along that journey with us in terms of letting them know what the expectations are of a roadmap and what it is. You know, a lot of people get very hung up on releases and what functionality is in a release, whereas actually, we should be educating them more on these are some of the problems that we're trying to help you solve. And almost leaving the solution agnostic of that. It's like, we're going to go about this many different ways, so we're gonna tell you what we're going to, what you can benefit from, but not necessarily the how.

  - Yeah, and I fully agree. For me, if you think about how product roadmaps are traditionally designed or built, and it's still interesting, a few days ago I went on Google images and keyed in product roadmap, and most of the images that come up are traditional roadmaps and those are feature-based roadmaps. So traditionally, and I think that's still the concept, many people in product management have, product roadmap essentially is a list of features mapped onto a timeline. And for me, I'd have to say that, certainly when we talk about digital products and also when we talk about markets that change unexpectedly and rapidly, that concept is no longer beneficial. So personally, I think, if that's all what some of the viewers do currently map features onto timeline, there's a massive opportunity to upgrade and level up your product roadmap practises. So I'm a big fan of working with outcome-based or goal-oriented product roadmaps. To me, those terms are largely interchangeable, synonymous. Some people like to talk about theme roadmaps or problem-based roadmaps. I mean, the various terms that I think really describe the same idea and that is first and foremost, think about the specific value that the product should create in the coming months. You know, the specific outcomes that the product should achieve the specific problem. A product should solve, like, increase engagement or acquire more users or increased revenue, or reduce cost, or future proof the product by reducing technical debt, just sort of to give some examples and really make that the heart of the product roadmap. Make that the backbone, the core of your roadmap. And then you can decide what other elements you use in order to, in a way compliment that picture, compliment that narrative. You know, if you want to use timeframe, if you want to use dates, if you want to use metrics in order to make sure that those outcomes, those goals are measurable. If you want to use selected coarse-grained features in terms of product capabilities to sketch out what the solution might look like, just at a very high level. Or if you say, actually now we're not gonna use any features at all, we're gonna really be a solution agnostic over an external roadmap. We only show the outcomes, we only show the goals and that's it. And maybe then use an approach that Janna Bastow suggested that now, next, later, that you have these really, really big timeframes where you've got a lot of room to wiggle. But again, it'll depend on the audience, it'll depend on the expectations of the market. And you mentioned product lifecycle and maturity earlier, it'll depend where your product is and its lifecycle. The more stable the product is, the more you, and the better you understand the market, the easier it is to look ahead with confidence, right?

  - Yeah, absolutely. And you've touched on a lot of different concepts there, which we will revisit just briefly because I think there's some real best practises that you've mentioned that you've baked into that response. And so I'm definitely keen to pick up on that. In fact, Janna joined us on the channel very early on to talk about those things. And that's certainly a style where when I was starting out as a product manager, I stuck myself in a room and I created a release plan and said, this is my roadmap and how I've evolved there. So like you said, a Google search of these things shows that there's still some work for us to do, but we're moving in the right lines.

  - I think so as well. Yeah, I think so as well. And I do think there's some agreement in the product management community that probably an outcome-based, goal-oriented roadmapping approach is the way to go or tends to be preferable over feature-based roadmaps. And I think that's great. I think, as you said, that's moving us really in the right direction, hopefully.

  - Absolutely, we just need to keep communicating that and showing the way forwards. But I wanna talk about kind of vision and strategy in just a moment, but just to finish up that section. Who in your mind owns a roadmap and maintains the roadmap are they one in the same?

  - Yeah, that's another really interesting question. So for me, ultimately the person in charge of the product owns the product roadmap. So the traditional term would be a product manager, or in an agile scrum based context, it would be the scrum product owner. And I generally, I guess that's related to the question of what is the product manager, the scrum product owner role all about? And what level of empowerment of authority, of decision-making do product people have to have? But for me, ultimately, the person in charge of the product should have the final say on strategic product decisions. And so I personally look at the roadmap as a strategic product plan, together with the product strategy. So those are the two strategic planning artefacts. But the same- Ultimately, person in charge of the product owns it, and ultimately the person in charge of the roadmap has to ensure that the person in charge of the product is to ensure that the roadmap is up to date. I mean, it's not only wasteful to have a product roadmap that's outdated. It can be really, leads to people making the wrong decisions. So that'd be a shame. However, I'm personally a big fan of collaborative roadmapping of involving development team representatives and key stakeholders in creating the initial product roadmap and then regularly, excuse me, reviewing and updating the roadmap.

  - I really like the concept of where you're going with that Roman. So it is more of almost not leaving that to one individual. And especially you mentioned tech debt and things like that earlier, so I'll let you carry on, pick up where you were, but that sounds like a very important transition.

  - I guess there are different approaches that you can employ, but I always find it nice to try and bring the right people together in form of a collaborative workshop, be it on site, be it online. You know, for me that has, you know, if that workshop is prepared well and facilitated well, then that has several benefits. The first one is it creates a clear understanding and a shared understanding of the plan. You know, people are on the same page. People understand what those outcomes or those goals really are about, excuse me, you leverage the expertise. You mentioned it with technical debt, you know, as the person in charge of the product, I may not have all the necessary knowledge, technical knowledge to understand, okay, how bad is it? Would it be worthwhile to spend like six weeks or two months just addressing technical debt, just removing spaghetti code, doing architecture refactoring, reducing code complexity, and then really having a clean code base, certainly a cleaner code base so we can innovate faster, add more features more quickly. And thirdly, I find that when I ask people to contribute to a decision and I invite them, and I make an effort to listen to them with an open mind and appreciate what they have to say, they're much more likely to support the decision or the decisions, and in this case, the product roadmap, and not just pay a lip service to it and then go away, and do whatever they think is right. But I actually work towards those outcomes, work towards those goals that we've captured. So that for me, really kinda justifies the effort of trying to bring people together and trying to encourage people to reach some form of agreement or consensus. And so a decision rule, for instance, that could be used in order to reach agreement might be constant, which means that, everybody has to be, you know, nobody has any meaningful objections. That's probably the better way to put it. Nobody has any meaningful objections, particularly when it comes to the core elements of the product roadmap that the outcomes, the goals that were put down on the plan. So everybody can live with it. It's good enough to start working towards those goals and then we'll review it, we'll inspect it on a regular basis anyway, and it'll change because it's a living document. It's a living plan. And yeah, so for me, that's really a powerful concept. It's difficult to implement in some organisations where, people aren't that used that much to teamwork and collaboration, and where there's some hierarchies that are very strong. And it can also be challenging when you have difficult individuals, collaborative roadmapping approach, collaborative decision-making means that people essentially see each other more or less as peers and treat each other with respect. So if you have a very senior stakeholder in there who just thinks that they know best, they must decide, and their opinion must win, then it can be very challenging and difficult. And so, just to elaborate on this very briefly, and as we, as product people aren't always necessarily, you know, fully qualified facilitators and as our job is not only to kind of run this workshop, but also to make sure that the right decisions are being made and actively shape the roadmap. I think it's very helpful to have an outside facilitator who can make sure that everybody's heard and nobody dominates. Because what you don't want is you don't want the most senior stakeholder to take over and essentially decide. And what you don't want either is you don't want to agree on the smallest common denominator and try and please everyone a little bit. And then you have these weak goals or these weak roadmaps that really, you know, probably not gonna result in an amazing successful product. So having a qualified facilitator there, it might be a scrum master, it might be an agile coach, it might be another role, but it's important that somebody who has in a way that the cloud or has the courage to tell difficult people or people who like me, like to talk a lot, thank them and say like, this is lovely, but let's hear from some of the others. You know, even if those individuals might be very senior. And yeah, guides the team through the decision-making process through the roadmap workshop. I think that can be really beneficial.

  - That's great guidance, Roman. And I think just thinking of that you're right, not everyone is going to be an expert facilitator. There's a lot of soft skills or the personal skills that are so important to be a product manager or the owner of that roadmap. But what I really liked and I wanna pick out there, is you talking about bringing a lot of stakeholders along for the journey and sharing that roadmap often because it's just the latest of what we know right now. It's going to change, it's going to be, you know, there's gonna be changes over time, but bringing people along that journey and having them bought in often means that when they next see the roadmap, there's no surprises on there. They've been bought into those decisions already.

  - That's right, yes, exactly. And you know, we all know that unexpected things do happen. Pandemics come along, wars come along, energy prices go crazy, cost of living goes through the roof. All sorts of stuff has happened in the past few years. So it seems that if anything, our world has become more volatile and changeable. And so I do think it's really important to make an effort and regularly review the product roadmap. My rule of thumb is once a quarter, sometimes that's a little bit too frequent, and then you can maybe go up to four or six months if you have a very stable product in a stable, slow moving market, sometimes it's not frequent enough. And then you have to kind of go down to two months, sometimes even review the roadmap on a monthly basis. But often quarterly reviews, collaborative reviews, with the development team representatives and key stakeholders, I think are good way to start. Yeah, and as you said, that makes sure that people kinda get reconnected with each other, but also get reconnected with the plan and everybody's on the same page. And the benefit for me as the person in charge of the product is that I, assuming that the conversation is open, and there's a certain level of trust that say the sales rep tells me that actually that goal is gonna be pretty ambitious given that everything else that's going on for the sales team, in that quarter for instance, you know, the marketers says, wow, that means we'll have to adjust the marketing strategy because we're reaching out here to your new segment. We'll have to create, maybe use a new marketing channel and open that up. We'll have to create new marketing collateral. Wow, that seems very ambitious to me. And I'm not sure that I'm, you know, that this goal is achievable, that it's realistic. So, do you know what I mean? So you know that I understand at a very early stage, what is doable, what is not doable. And we can adapt the plan accordingly. So we don't just kinda commit to a plan or say like, let's do this, full of enthusiasm and then we find out, Oh dear, dear, dear, now the sales rep can't support it. Now the marketeer can't support it, now the development team says, Oh actually.

  - That's right, that's right. And that's I think goes into a bit, we'll talk about in a moment about the good and the bad, and the ugly of roadmaps. But we've often it's been a tool where we've tried to be well-meaning and we've tried to be too transparent and it's caused us some problems as well. But before we go to that section, Roman, I know there's some, I watched your video that you put on your YouTube channel just a couple of weeks ago, actually, around your product strategy model. And the next two questions I have for you is around the relationship of a roadmap to vision, strategy, objectives, and maybe some of those related artefacts. Because I think certainly when I first started out a roadmap was a single page of a Gantt chart, my goodness, how has my, you know, as being a product manager, that evolution changed, but your video, touched on things like the product vision board and the goal product roadmap. Maybe you can suspend a little time just talking about those 'cause that really resonated with me.

  - Yeah, sure, I'm very happy to. So in a way, a strategy model that I like to work with, and that I've kinda created for the work that I do has an overarching vision as the ultimate purpose of the product. The reason why we create the product, the positive change we want to bring about. An example I like to use something like healthy eating, like a slogan, easy to understand, and hopefully somewhat inspiring.

  - People could do it.

  - Yeah, and then the strategy will be the path that we choose in order to get closer to our vision, realise our vision, at least to a certain extent, and the approach that we'd like to implement in order to achieve product success, make the product successful. And I think I very briefly mentioned the key elements that I like to describe and that's really the market-market segment, the target group, the beneficiaries of the product, the users and customers, who are those individuals, the value proposition. And by that, I mean the needs and particularly the main need or the main problem, the primary benefit that the product should address. So why would anybody want to use the product? Why would anybody want to pay for that product in one way or another? What is the value that it should create for people? And it might be something like, you know, just to stay with the healthy eating example, reduce the risk of developing Type II diabetes by, I don't know, making this up between 10 and 20%. And then the target group would be middle-aged men like myself, who've maybe developed unhealthy eating habits, maybe don't exercise, or don't exercise enough and eat too much and drink too much, and all the other stuff that we tend to do.

  - All the stuff would've introduced.

  - So yeah, and then think about maybe some standout features, 3 to 5 elements, capabilities that set the product apart from other products that might be personalised, eating recommendations or weight loss recommendations, whatever it might be. And then the business goals, the reason for the company to invest in the product. You know, maybe it's about generating revenue, at a later stage, it might be about meeting a specific profit target or margin. It might be about developing the brand, it might be about developing a technology advantage, it might be a combination thereof. But I think there have to be some tangible business benefits that our product generates, that our product achieves really. And so I always look at a product as a value creating vehicle, must create value for a group of people and must at the same time, create value for the business. And so for me, a strategy has to capture those two parts of this value equation, if that makes sense, and if I putting this correctly. And that's where I'd like to start. And once I've got a draught strategy that is good enough, I'll start validating it. I'll start testing it. And that means I'll just go through it systematically and look for the key assumptions or leap of faith assumptions as Eric Ries calls them, and key risks and address them. And that might be that the target group is to heterogeneous, or it might be that the value proposition isn't strong enough, or that maybe, I don't know, the appropriate machine learning technologies aren't available possibly. So depending on where the risk is, that then results in different validation techniques. So it might be direct observation or custom interviews, or it might be a prototyping and then creating some throwaway prototype, some spikes. And so then for me, this validated strategy, which means I now have this high level idea of how I can create value and make the product successful and how I can get closer to the vision, that is really the basis for creating, for building a product roadmap. And I'm emphasising this because I think one of the big mistakes that I've seen people make is just to kinda draw up a roadmap. You know, I mean, you could argue, well, what's wrong about this? And per se, nothing. But if you're not clear on who the customers and users are, and why they would want to use the product in the first place, or how that product would create some value for the business and for commercial revenue generating product, how that product will be monetized and what the underlying business model is. I think there is no point really in creating that roadmap. And the analogy I like to give is like saying, Oh we want to, I don't know, where would we like to go on holiday next year? So this is autumn here in the UK and today was a lovely day here in Buckingham, but I mean, yesterday was rainy and windy. And so, for me, I always get itchy feet this time of year, and I think it was talking to my wife about this yesterday saying, let's decide on where we wanna spent the next summer, family summer holiday. So and say we wanted to go into Southern France then, before I now think about, okay, I must book the shuttle to get from the UK to France. I must book the ferry and then it's a long journey, so you should really pre-book a hotel or something. I should check that actually a road trip and driving there is the right approach. It might be better to take the train, might be better to fly, might be better to be ambitious and cycle there and you know, take a little sabbatical. So make sure that I've select the right strategy and then I can literally do the roadmapping, right? I can map out the journey and I think we should do the same thing for our products. And that increases the chances that we have, that we're able to create a realistic, actionable product roadmap and not just a product roadmap that is based on, you know, I don't know, hopes and dreams.

  - I was gonna say exactly the same in fact, that really resonated with me, Roman, and great to bring the roadmapping analogy back to a map of roads, right? But it's so true, that the outcome is that you get to France and you have an enjoyable holiday, not how you get to France, which can change. So I absolutely love that you mentioned that, and I completely agree. I wonder if you go into the design of a roadmap, So you mentioned one of your preferred ways to visualise the roadmap is the now, next, later. And I think that's a classic one in terms of different time frames or different horizons. But what are some of the key elements you like to see on there? I think you've mentioned some of them already, but are there any other different things you'd like to see on the roadmap?

  - So for me, because I really have a very strong preference to work with a goal-oriented, outcome-based roadmaps, to a certain extent changed my mind on this. I used to say, in certain circumstances, feature-based roadmaps are okay, and pick and choose. But I actually found that this advice was for some people confusing for some of my clients. And so in these days I tend to say, as I mentioned earlier, just don't use feature-based roadmaps. Don't go there. Always think about specific outcomes, always think about specific goals, specific benefits that you'd like to achieve, that you'd like to create with your product over say, the next 12 months roundabout. And so for me, that is really the core element of you could say modern product roadmap, those outcomes, those goals. And I generally like to identify them first and sequence them in such a way that a meaningful narrative is created on a logical progression so that, you know, it's not just a random collection of outcomes, oh engagement and oh revenue, oh a retention, oh then this, oh then that, it's like, no, no, no, let's think about this. And sometimes the sequence can be constrained by the business model, particularly for a new products, brand new products. But I think it's really important to get that right, to carefully think about the goals and then think about, okay, what's a good order, what's a meaningful order? And goals might be directly derived from the needs and the value proposition and the business goals in a higher level product strategy. Or you know, you might find that your KPI is actually pointing towards some issues that need addressing because engagement has dropped and maybe therefore, that's something you should now look into and improve. So again, that'll depend a little bit where the product is in its life cycle. But all the goals I would suggest that our product roadmap should be in line with the overarching strategy. And again, for me, the roadmap always supports the strategy. And then, so that's really the heart of a roadmap. I'm still a fan of working with timeframes and dates, and I guess, you know, Janna might disagree here, certainly for internal product roadmaps. So for internal product roadmaps, I find that it can be very beneficial to, first of all ask ourselves how long is it likely to take to achieve a specific goal? Or are there any expectations around a timeframe by when the goal should have been met. And sometimes, I mean, I've worked, for instance, in healthcare for a number of years, you do have external time constraints. I remember, there's this trade show with the RSNA in the US and for certain imaging products like, sorry, certain healthcare products like imaging devices like x-ray machines and ultrasound machines. It used to be at least the case that you had to show at least a prototype at this trade show. So you could then launch a new product or you could then introduce a new product version or you think about entertainment type products, be it computer games, or be it gadgets like smartphones, you know, typically now is a good time to introduce new products to gear up for the Christmas sales. You know, this is typically then where most of the money is made. So sometimes you've got some hard external time constraints and I think then it's very important and helpful to take them into account on the product roadmap and during the roadmap planning process. So daytime frames goals, and again, daytime frames with the restriction on internal product roadmaps. What else do I like to put in the metrics? I like to put metrics on my roadmaps to ensure that the goals and outcomes are specific and measurable. And then, you know, the added benefit is that you can take the metrics and add them to your set of KPIs. I do like to put high level coarse-grain features capabilities on my roadmaps. But I tend to say, first of all, any feature on a product roadmap must be truly big. So again, if I go back to the healthy eating example, something like dashboard or something like social media integration, literally at that level, no more detail, no epics, no user stories, no detail functionality, that's a no-go because otherwise you solutionize and you kinda make detailed in a way tactical product decisions too early. And the other thing I'd really like to emphasise is that any feature on a roadmap, if you decide to add features really must serve a goal. So you can't just stick a feature on that, any feature really has to help meet a goal. And so if a stakeholder comes to me and says like, Roman I've got this super, super important feature, if we implement this, then we'll be rich, let's go there, you know, champagne, breakfast every morning, talking about healthy eating.

  - Exactly, but that golden thread back up to our goals is vital was really important at least.

  - Yes, yes. Then have to sort of see if there's a goal that this feature supports. And if that's not the case either, decline the request or adapt change the product roadmap map, but I can't just stick it on there. So that's really important. And then, the final kinda rule that I have is no more than 3 to 5 coarse-grain high-level features per goal, but because we don't wanna turn our product roadmap map into a mini backlog. And in fact, that's a mistake that I've seen roadmaps that are too detailed, contain too much information, too many elements, particularly, too many detailed pieces of functionality. And then you have an overlap with a requirement specification or product backlog in an agile context. You know, those documents start to compete. Updating or keeping the product roadmap up to date is more work, it makes the roadmap more volatile, so I wouldn't wanna go there. Those are some key elements that I'd be looking for. And as it happens, I created, you mentioned the goal product roadmap I created a template with those elements, and that's actually a fifth one, just the name if meeting the goal does result in a major release or new product version. So I captured those elements as a template a few years ago, but it's not about the template, it's really, for me, again, it's the roadmapping approach. It's first and foremost asking ourselves why are we spending time, money, and energy on progressing our product? What is the specific value or what we want to create, What are the specific outcomes to specific goals? And then adding other elements if and when that's helpful.

  - Just nodding through that, my head's gonna fall off, but it completely makes sense to me. And the bits that I picked out from that really resonated was not adding so many features or even capabilities on there where it becomes a mini backlog. I loved your comment around different dates because for me as a former product manager, I used to look after the eCom basket for Dell in EMEA. And so some of my key things deliverables were when Switch changed, sorry, for when Switch changed to Maestro, that was a big key one that we had to hit dates because that payment method was going away and there was also some legal compliance things around insurances, and we absolutely had to meet those dates so that really resonated as well. So I completely agree. I think it depends, but you've just got to work with your market, work with your stakeholders and understand what's really relevant to them. And I think you've shared some great kind of anti-patterns as well of where people can sometimes go wrong. I guess to close out this section, do you have any tools that you prefer to use for managing or visualising your roadmap? And not necessarily a leading question from maybe my background, but what's your favourite? 'Cause I think my favorite's even changed over the years.

  - In terms of the format, it'd be sort of an outcome-based, goal-oriented format that I'd be, that I use for stopping. And I like to use the template, apply the template that I've created. But I mean, I really just really basically fill out the PDF template that's available for download, plug on my website.

  - Fantastic.

  - Or use a spreadsheet-based version. So I'm really, in terms of tooling, I'm low key. I know that some, you know, not some, a lot of organisations like to use much more powerful roadmapping tools. And of course, the number of commercial roadmapping tools out there and there's nothing wrong with it. For me, again, it's a matter of experimentation. And my general advice that I give myself, but also that I give my clients and people who come on my training courses is, do the simplest thing that could possibly work initially. And that might be literally drawing up a roadmap on a piece of paper or PowerPoint slide or a spreadsheet. And then once you're happy with the roadmapping approach that you've found, you're happy, you know what the key elements are that you want to display on your roadmap, you know roughly how much detail you wanna put on there and what timeframe you want to cover, then you're in a great position to look at the commercial tools that are out there and do some meaningful evaluation, and pick the one that serves your needs best rather than being too let... I was once working with a large established publisher and they had just kinda introduced a product management organisation for the digital product and did a roadmapping strategy session for them. And then they said to me, which tool should we use? And I said, well, I gave them this advice. And then I think a couple of months later they got back in touch and saying, Hey Roman, we're making some really good progress, can you teach us how to use this tool that we've selected now?

  - No tool is the silver bullet and a tool is really only there to speed up a process. So it's really strip it back to basics. And that's why my tool of choice has maybe changed over the years as well. Strip it back to basics and really think what you need, and then look for a tool that meets those needs. The other bit that you mentioned is your website. So we'll definitely put for people watching on YouTube, or if you're listening on the podcast, come along to the YouTube video, we'll put in a links, some links back to Roman's site and some of these templates that he mentions 'cause they're really valuable, and I've used those with my clients.

  - Oh, that's nice of you to say. Yeah, so, you know, don't get me wrong, I don't wanna sort of say tools aren't important, but just like with the example I was trying to share, from the client, I think it's a common trap that we tend to fall into that, but tool let and that we believe, you know, if I only select the right tool, then the rest will be easy. But along the lines, or along whatever, you said something like this much earlier in our conversation about the concepts, and being aware of the context, and then deciding how to apply it. I think, that's exactly what we need to do. We need to figure out how we wanna apply things and then select the right tool, and then typically the tool will be helpful, but otherwise, it's sort of that fool with a tool type scenario.

  - I said the same thing in videos previously. I still love that a fool with a tool is still a fool and that really resonates with me. That's a brilliant quote. Roman, you're one of the people that I come to for advice on roadmapping, but I'm curious on whose advice on roadmapping do you perhaps listen to?

  - Whose advice do I listen to? So I mean, I listen my colleagues in the product management community. So there's not a single person that I go to, but you know, I always kind of curious to sort of hear what other people have to say about product roadmaps. You know, you've talked about Janna or be it Marty Cagan, who's in the past been quite critical of product roadmaps. I remember listening to a talk by Marty, that was a long time ago, I think that might have been, I dunno, that must be like 12 years ago or longer. And you know, he said, Oh product roadmaps, don't use product roadmaps. I think he might have changed his mind somewhat on this or have a slightly more differentiated perspective. So because it helps me evolve my own thinking and it helps me also challenge my own thoughts, my own assumptions, right? I mean, it's so easy to suffer from confirmation bias. I think I know best. But I mean, there's not a specific person I hope that people don't think, I am the roadmap expert because I don't really... I don't think it's about saying that person is right or that person is wrong, it's really listening to different people, looking at different approaches and as we've just said a number of times, then experimenting with different ideas and approaches, and figuring out what is the right one for me, for my product in my organisation. So that's what I'd like to encourage people to do.

  - It's such a big response.

  - Yeah, and you know, if somebody say for instance, uses my goal roadmap or any of my other templates, that's brilliant. But I tend to say, use them as a starting point and then adapt them. I mean, I do appreciate if people adhere to the licence agreement, but you know what I mean? They're just meant to be a starting point.

  - Yeah, I love that. It's like you said, it's just experiment with it, be playful, take the bits you like, discard the bits you don't, you're obviously in touch with a lot of your different clients and a lot of different experts in the world. You take the bits that you like and you think of different opportunities and then craft your own. So I think that's really great advice. Are there any roadmapping resources that you typically recommend or does that fall into the same kind of response as the previous one?

  - It does, yeah. I mean, you know, this is another outrageous plug. So I mean, it's of course, it's not the product roadmapping resource, but I mean, I actually, I recently in September published the second edition of Strategize and I essentially rewrote the product roadmap part. And so because some of my thinking had changed over the past six odd years and I felt there was an opportunity really to update it. Improve, improve, improve particularly those sections. And so, as part of that I did quite a lot of research, looked at quite a lot of other books in that space. I've read a lot of articles. And so, for me, if somebody says, I'd like to learn more about goal-oriented, outcome-based roadmaps, particularly in an agile context, then I say like, well, why don't you have a look.

  - I confess I haven't read it yet, but it's on

  - That's all right.

  - growing list of books and congratulations on the second version. In fact, that's not your first book either, is it Roman?

  - No, it's not my first book, but you know, I just thought that the book was decent, but that was partly because my thinking has evolved and changed. There was an opportunity to make it in a way better and make it more up to date. A few people said to me, why did you issue a second edit edition? What was wrong with the first book? It was pretty good. It's like, well that's nice of you to say, however, there's always rooms improve a product. And you know, I also felt that some of the examples needed updating or benefited from updating in that way, hopefully it stays fresh and meaningful for people. And you know, that's what it's about.

  - It is, that's really humble of you and I think you mentioned on your website that it's writing these books is a nice way to summarise and acknowledge your knowledge of that subject at the time. And it's okay, for our knowledge to change over time, and you share that with your audience, which I think is fantastic. So look Roman, we we're gonna look to wrap things up, I've probably got a couple of last questions. This next one's a bit difficult actually, but it's not to trick you to catch you out. I found this difficult, which is if you had to distil your philosophy of roadmapping into a couple of sentences, what would it be?

  - So I guess the first sentence would be, base your product roadmap on a validated product strategy, number one. Second one is use a goal-oriented, outcome-based product roadmap and ensure that any outcomes, goals are specific and measurable. Third, use a collaborative roadmapping approach and actively involve key stakeholders, and development team members in creating the product roadmap. And finally, regularly inspect and adapt the roadmap, regularly review the product roadmap, and make sure that it stays up to date. And again, preferably involve key stakeholders and development team representatives in those reviews, in those updates. So for me, those are key elements of what I would call a healthy product roadmapping practise.

  - That's great. And I think, people will be scribbling down those notes at home. I know that I'm gonna be taking some of those as well because I think roadmapping is a process, not just an artefact and it's getting into that mindset. So that really resonated with me. I think you nailed it there. Roman, before we wrap up, I wanted to give you a chance just to share with our audience where they can learn more. If stuff that we've spoke about has peaked their interest, where can they go to get more information on you and get in touch?

  - Yeah, sure. Happy to do so. So the best place to go is probably my website, romanpichler.com. So there's a fair amount of free information available on roadmapping, blog posts, podcast episodes, at least a few. There's some YouTube videos, which you kindly mentioned earlier. There are also, if you're interested, links to the books, particularly to Strategize and you can download a product roadmap template if that's something you'd like to experiment with. So yeah, check that out and hopefully you'll find something that is useful for you.

  - Absolutely brilliant. And I know that myself, I'm really grateful for the thought leadership and the transparency, and things that you've shared. So Roman, thank you so much. Really appreciate it. Thank you for being so generous with your time. I'm gonna wrap up now. So folks, if you've enjoyed today's session, please do give us a like, if you think that something that Roman or I have shared, probably Roman, let's face it, is gonna resonate with your teams, please do go and share it with them. And if you haven't subscribed already and you found value, please do consider subscribing to the channel. Also, if you'd like to get in touch because you want to be where Roman is today, then feel free to reach out in the comments or drop us an email. Otherwise Roman, it just leaves me to thank you once again. It's been an absolute pleasure and I look forward to speaking to you again.

  - Yeah, likewise. It was lovely to talk to you and thank you for having me.

  - You're welcome, thanks.