Product Management: How to make your roadmap | Meryam Bukhari | Skillshare

Playback Speed

  • 0.5x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 2x

Product Management: How to make your roadmap

teacher avatar Meryam Bukhari, Product Management | Teacher at heart

Watch this class and thousands more

Get unlimited access to every class
Taught by industry leaders & working professionals
Topics include illustration, design, photography, and more

Watch this class and thousands more

Get unlimited access to every class
Taught by industry leaders & working professionals
Topics include illustration, design, photography, and more

Lessons in This Class

12 Lessons (39m)
    • 1. Introduction

    • 2. Agenda

    • 3. What is a roadmap

    • 4. Don't overcommit!

    • 5. Template: time-based roadmap

    • 6. Template: release-based roadmap

    • 7. Template: thematic roadmap

    • 8. Roadmap software previews

    • 9. Aha

    • 10. Productboard

    • 11. Roadmunk

    • 12. Asana

  • --
  • Beginner level
  • Intermediate level
  • Advanced level
  • All levels
  • Beg/Int level
  • Int/Adv level

Community Generated

The level is determined by a majority opinion of students who have reviewed this class. The teacher's recommendation is shown until at least 5 student responses are collected.





About This Class

As a PM, one of your core responsibilities is to make and manage roadmaps, regardless of which industry or company you're in. This class goes over tangible examples of roadmaps that you can apply directly to work along with an explanation of why each template may be a fit for your product and context. We also review commonly used software that can help you automate the roadmap artifact building process so that you're spending your time on strategy and thinking instead of spending it in PowerPoint. 

Whether you are brand new to the PM role or if you have some experience under your belt, crafting a strong roadmap will help you level-up. 

Meet Your Teacher

Teacher Profile Image

Meryam Bukhari

Product Management | Teacher at heart


I'm deeply interested in the art and science that is product management. I hope to teach you the lessons that I've learned about being an effective Product Manager through my firsthand experiences working at both start-ups ( See full profile

Class Ratings

Expectations Met?
  • Exceeded!
  • Yes
  • Somewhat
  • Not really
Reviews Archive

In October 2018, we updated our review system to improve the way we collect feedback. Below are the reviews written before that update.

Why Join Skillshare?

Take award-winning Skillshare Original Classes

Each class has short lessons, hands-on projects

Your membership supports Skillshare teachers

Learn From Anywhere

Take classes on the go with the Skillshare app. Stream or download to watch on the plane, the subway, or wherever you learn best.


1. Introduction: Hi everyone, welcome to this course on how to create a compelling product roadmap. Now, the product manager role and its responsibilities really vary from company to company, depending on the size of the company, the size of your product organization, as well as the industry that your company operates in. Despite all that variation, the one thing that is a very standard and a common responsibility for PMs across companies and teams as coming up with a roadmap. And typically we think of a roadmap as an artifact that a PM comes up with once they've actually figured out the strategy for their area, and once they've actually made some decisions around what they should be prioritizing in terms of feature and how they should be spending their engineering teams time. However, through this course, I hope that we can cover our main agenda, which consists of us walking through different types of roadmaps and figuring out what is the right time to actually use that roadmap. But also align around this Meta point that keeping your end artifact, your end of roadmap in mind and working backwards from that can actually help you sharpen your part of thinking and figure, figure out what the right thing to do for your area actually is. And as always, if you have any feedback or any questions, please feel free to use the discussion section below, or send me an email through my email address that's listed in the course description. Thanks, and I hope that this course is useful to you. 2. Agenda : So in this course, we have two goals. The first is that we end up figuring out how to actually build a product roadmap, which as I mentioned, is a common responsibility for all PMs regardless of their level. And secondly, and this is something that I really wish I had been taught when I was first entering the PM craft, is you don't just want to build a roadmap. That's basically a summary or a spreadsheet of the things that you want your engineering team to build. You really want to build roadmaps that are useful for your product and for your organization. And very importantly, there's a caveat here, which is you want to build roadmaps that are useful, that do provide clarity, that make it clear to your important stakeholders whether they're engineering external customers, marketing, sales, et cetera. What it is that you actually think is the right thing to build. But you want to do it without overcoming. And so to actually achieve this, this is the agenda that we're going to follow it today. We'll first start out by what exactly a roadmap is. And I think the way to understand that is to understand who your roadmaps audiences. Again, depending on your company, depending on your product area, your company's industry, you're going to have different audiences that are trying to learn and consumer roadmap. Then we'll turn to abstract some learnings. If we think about great roadmaps, what are some of their shared traits so that you can have these principles almost as shortcuts that you can reference when it's time for you to put together your roadmap, whether it's for a PM interview or whether it's for your actual day job. After that, we'll walk through a couple of templates. The first template that we'll walk through and examined as a canonical time-oriented roadmap. When you hear the word roadmap, this is probably what you're thinking of. And so this is really useful for those that are beginners, possibly new to the product management space. We'll walk through what exactly this an example of this roadmap is and then how it relates to task management. So when you're a newer PM and you're really responsible for feature level individual implementation. This robot can be really helpful. After that, we'll get into a couple of other templates. We'll go over the high level release base roadmap and I'll get into more details in that section. And then the somatic roadmap, which is really handy for roadmaps that either span multiple products or multiple features and, or just have a lot of complexity built into them because of the domain that you're in, or maybe some context that makes prioritization particularly challenging. And then finally, we'll end with software that you can use to build your roadmap artifacts. This is may not be useful or relevant for everyone, but there are some ways that you can help automate your roadmap building, or at least the input into your roadmap, the inspiration that you can get to figure out what your actual implementation work is by using some of the software that's out there on the market. 3. What is a roadmap: So let's get started with the very first topic on our agenda, which is, what is a roadmap? We will soon preview roadmap templates, but I want to first take a step back to understand the building blocks of a great road-map. Sort of like figuring out what the bigger picture is before we dive into what the trees are. So a roadmap is a living strategic artifact that lets your, typically mostly internal stakeholders know where your product is headed. So what you're talking about is what you will do between today, basically the day of your presentation, the day that you write that roadmap or sure. That document up until various points in time that are in the future. So let's break that apart a little bit. So it's a living strategic artifact that lets your stakeholders know where your product is headed. However, keep in mind that it's not a rigid document that rules you. It will change. And the recommendations that you make, the features that you're prioritizing or how you're even thinking about success will change as you iterate. And that's something that is common to just about any industry. And it's something that you need to be able to build for within the document itself. And the other important component is that you want to think through your stake holders as perspectives. So for example, if you have a product that is monetized, Probably sales and marketing are really important stakeholders for you. And especially if you work with sales, because they have to take your product or your service, and they have to take it out into the market to acquire new customers and also service existing customers. It's really important that they have a sense of where your product is headed so they know what the position, not just about the existing services that your engineering team has built, but also what else they might be able to promise to the customer or a signal to the customer. And it also helps them as salespeople understand what the competitive positioning of the product that your roadmap is building out is. So think through exactly. We are stakeholders are the roadmap is yes, helpful for you to clarify your thinking? Definitely helpful for your engineering team. And these are sort of like, you know, core stakeholders. But think about, almost think about it like a product itself. Like who are your customers and what our credit and critically, what are the main questions that they are hoping to answer with your roadmap? Will they take this information and it's just helpful for them to build understanding? Or will they want to take the information that you're sharing and share it with others. In which case, you want to be strategic about what information you share. You want to be strategic about what experiments you're sharing, what launches, you're signaling to them and how certainly you want to position those launches. Or they are given or they definitely going to happen. Are there risks along the way? So keep in mind that just like a product, your roadmap as you can almost PM your roadmap, right? And so, so you want to be mindful of who your stakeholders are and what their main questions are. And lastly, again, your roadmap is about the things that you will do between today and at some critical points in the future. So it should be clear from reading the document or watching the presentation what everyone should actually be expecting that you will launch. Sometimes your launch cycle, your development cycle is really, really long. In some companies, you maybe you're releasing experiments every month. And some companies you may be releasing an experiment once a year, that, that can happen, right? It depends on your domain, but ultimately people do. And by people, I mean the other members of their product team, your engineering team, et cetera, you are there because they want you to release new product, however subtle it might be, or however long it might take. So your document, your artifact should also clarify what it is that you'll be launching. So with that, let's actually get into some of the principles. And these are the things that I think you can almost use as like shortcuts, principles that you can keep in mind in the back of your pocket for what grade roadmaps consistently achieve regardless of which template you decide to follow. So the first is that they draw a clear line to the customer. What does that mean tactically? It means that maybe you are articulating themes that tie back to your customers, to your market, et cetera, that you're focused on. It means that the customer's perspective is accounted for. If you decide which can look like you deciding to build a top requested feature, but it can also look like you deciding to not build a top requested feature because of some rationale. So the line to the customer should be clear. The other thing great roadmaps consistently achieve is setting expectations on time delivery. So maybe you are sequencing your launches by, or your announcements by time for delivery or level of effort. It should be important or it should be clear to the listener, to members of your audience what your rationale is. And they should be able to clearly identify what it is that you're testing versus full launch type work. Next, key milestone should be clear. So yes, as PMs, we make launches, but it's more than that. Sometimes a key milestone can be your product area hitting a certain metric or a certain, you know, for example, a certain monetization rate or a DAU, or in an MAU count. It could also be a development in the ecosystem. For example, maybe you were waiting for some sort of a clarity in all legislation. Maybe you were waiting for a certain announcement from a competitor, whatever it is, key milestone should be accounted for. And I actually think that roadmaps that account for either explicitly or maybe in your rationale, milestones and aren't most obvious. There aren't just self-contained and burned by the company like launches, they tend to be more well rounded because they also give your audience information that they may not have. And it helps them understand the bigger picture of what this roadmap is trying to achieve. And finally, great roadmaps complete the loop. They tied together the pieces of delivery launches, developments in the ecosystem. Feedback that you're waiting on, other risk factors that you may want to wait for before really finalizing your roadmap. Different options or paths that you have for launching into an overarching narrative. And this last piece is sort of a qualitative thing that you get better at over time. But I just wanted to call this out even though I don't think that this is that straightforward of a box checks so that you keep it in mind. And over time as you develop your own taste and get your own experience for what it's like. To write your roadmaps and write your strategies. You'll be able to kind of pick up on this in your own work. 4. Don't overcommit!: And finally, the one sort of constraint that you want to keep in mind is you don't want to over-commit. And it is so much easier than you think. Why is it that easy? Because typically, if you look at the right-hand side of the screen, this is loosely what most part development cycles look like. Usually, once you have a feature launch, XYZ happens, then you have some time. You get some feedback from the market on how they're reacting to the roadmap, reacting to the feature. And then you incorporate that intelligence into your roadmap. And then probably you might see that your product environment will change. Either the competitors will do something different or something else will change. And then, you know, you again have to sort of incorporate that intelligence and make some other launches, so on and so forth. So it's a cycle, right? But the Meta point here is that change is a constant. You are learning new information from your own launches that may change your roadmap. You are learning information from your environment that may change your roadmap. And the information that you learn is actually not straightforward. Rarely does someone come to you and write on your whiteboard that this is the way you should change your strategy. So all of that is to say is that it takes time. And because it takes time, You want to give yourself enough leeway to learn and adapt to uncertainty. For example, in the first part of this like loose framework for how development happens, let's say feature launch XYZ happens. It may or may not be successful in moving your product in a direction you intended. So then it will take you some time to figure out why. It will take some time to sometimes in some cases, judge whether or not you even worse successful or weren't successful. And then it, and then it takes time for you to turn your team around or, or 10 year roadmap around or to align people behind a different direction, then you revise your roadmap, right? You may add, remove, modify launches, fine, but that also takes time then your engineering team, by the way, your design team, if you have one, your sales team, whoever they have a bunch of work to do, and then your product environment changes. So all that is to say is that it takes time and you want to build for that uncertainty. But by not over specifying what exactly your roadmap will contain in terms of launches. So now you might be wondering, well, I thought the point of a roadmap was to be specific. It is it is to an extent, but this is where one of the difficult things about being a PM comes in, which is you have to exercise some judgement. And this is a little bit of an art. How much information do you share? How much information do you not sure and how do you position it so that at a glance, did just the right way with your audience. That, that is the hard work. And we will get into that through examples in a little bit of time in the following chapters that walk through different examples of what roadmaps can look like. 5. Template: time-based roadmap: So let's go over the canonical time oriented roadmap. This is a great template to use or something like it when you have a very specific feature or a relatively small product area that you're responsible for. That is because it allows you to go into depth. And that's typically what your teams, your cross-functional stakeholders are expecting as well. So let's imagine that this is a roadmap that you're responsible for. For an audio book based platform. We don't really be more detailed and not. So you can see that this roadmap does a couple of things. The first is it is sequencing your releases based on time. So you can see that in the first set of releases in Q1, towards the left-hand side of the screen. It is starting out with some roadmap type or with some MVP type features. As you work your way towards the right-hand side of the screen, there is a more full fledged expectation of how the product works. We are officially in V1, V1 0.1 type territory. Now, let's look at what is highlighted in the MVP stage. The PM calls out that that there'll be testing with the first 11000 users. So that alone, as I'm sitting in the audience, tells me that there's a lot of unknowns here. They're looking for feedback and they're really looking to just even hit that first milestone. And there's a couple of very specific references to features that this Pm will actually launch, like feature one for audio book contributors, which is one type of customer. For this roadmap, they'll launch an upload, manage a Management page That's pretty descriptive, almost self-explanatory feature to that they call out for audio book contributors again. So it seems like this roadmap in the very beginning within Q1 2020 one is really focused on getting features out for audio book contributors as opposed to for listeners. Now, that alone like that takeaway, that implies some decision-making, some strategy on behalf of this PM. So for feature to this PM wants to launch an analytics page for measuring engagement for audio book contributors than feature 3, the lasting mentioned here. So presumably this Pm is only getting out these three launches, but they seem really important for the first 1000 users. As far as aimed at listeners. So the listener customer type, and they are launching a personal catalog page. So maybe this is where listeners save the audio books that they like. So this combined with this sort of like mostly empty circle denotes that these are really the building blocks of what this PM thanks, are important features. Now if I'm sitting in the audience for this roadmap, this really, you know, seeds my, seeds for me the information that I can then engage with some of the questions that I might ask is, well, how do you know that the catalog pages the right feature to launch as opposed to something else. And then as the PM, the PM is able to engage in that conversation. You know, given strategic insights, maybe give some insights from you, XOR, from user research, et cetera. Now as you work towards the right, as I mentioned earlier, you have it seems like this roadmap is progressing towards a more full standing, fully fleshed out roadmap. So for example, looks like Q2. This Pm calls out a pretty important milestone, becoming ga. Ga stands for general, general availability. So taking a product into GA means that it's not going to be gated or under testing for, just for a slice of the population, just about anyone that has access to this website or wherever this product is can access it. So here we see, again, very specific references to additional features. And this time interestingly, the PM mentions how feature is 1, 2, and 3 are actually aimed at listeners. And then there seems to be some feature that's aimed at just the like the platform itself. So it's implementing improved logging infrastructure. And then the PM also calls out marketing and PR push. So you see how from Q1 to Q2, the PM is exercising judgment. There's some strategy right there now focusing on listeners. This roadmap makes that very clear to me through how specific is by calling out individual level features. And then as you move towards the right, specific references dwindle, but instead they start focusing on instead of each column which refers to each quarter. So that's focusing on other, on other milestones are other important pieces of information. So if we take a step back, what this roadmap gets right is what is not on the roadmap. Or put another way, some jargon in the industry is what is below the line. This roadmap makes that clear because it references specific features. If a feature is not mentioned here is not on the roadmap. Super clear for the engineering team, super clear for other members of the product team, et cetera. It's also clear and what this robot makes gets right is that the sequencing of new feature releases. How do I know that? While one, there's two layers of sequencing, actually, there's time sequencing as he moved from left towards the right. And then within each quarter there's numbered sequencing. So feature 1, 2, 3, 4, presumably their features 1234 and not ABCD or insert feature name because feature 1 is going to come before two, which is going to come before three, so on and so forth. The other thing that this roadmap it gets right is it's clear what the critical dependencies are. Presumably because there is a sequencing, we will not be able to, or this roadmap in Q2 will not be able to GA, unless we do on the or this roadmap is able to achieve testing against this first roughly 1000 users, right? So that's very clear to me. So for example, if it's taking us longer than expected to implement for engineering to actually implement these tasks. So for designed to come up with the right experiences, we know some of the downstream milestones that are going to be affected. We are not going to be able to GA and Q2, let alone do the things that are listed out in Q3 or Q4. And What's also clear from this roadmap, which is why I think this makes for a great template for you if you are responsible for a relatively small product area or some, some like very specific set of product features is that there's a clear link between the items that are listed and tasks being performed by engineering and other members of the cross-functional team, right? So what do I mean by that? Well, features are specifically called out there, called out, they're going to be implemented. Marketing push, it's called out. I'm opening up bug reporting from customers for support teams is listed. So the reason that's important is because one, we know how each cross-functional member of the team or teams are going to come together to facilitate this roadmap and help realize it. But also, it clearly makes room for cross-functional members of the team to contribute to the roadmap. So presumably they have been engaged already and they're already bought in on this PMs roadmap. 6. Template: release-based roadmap: Next, let's talk about the high level release based roadmap. This is going to be visually the most simple, but don't be fooled the hard part or the work really involved in presenting your roadmap in this way is what you decide to not show. So let's go and do an example of what it actually looks like. So here you have the release based roadmap and look something like this. Now, let's assume that again, we are making a road-map for the same product that we assumed earlier, like this audio book platform where people can create audio books and other people can listen to those audio books. Now in contrast to the very specific details, depth oriented, time-based roadmap, what this artifact does is that it paints a much higher level picture. So again, it doesn't mention a couple of the same things. From the left. You're working, you know your skew have some origin point and BP for an audio book platform. And then as you go towards the right, there's the sense that you're getting, that they're showing through the visuals of the circles getting bigger, getting fuller, that you're working your way towards a bigger, a full-fledged roadmap. What information is shared here is at a high level, what the product will gain. So it looks like if you start with an MVP, moved towards the MEP with some debugging enhancements in Q3, we have a lead 1. Now what this means is that this roadmap is incredibly sales and marketing friendly because there aren't too many details. It's not committing the engineering team, the product manager or the company to specific features like a catalog page or like better support for bugs that are reported from customers or externally. And therefore, it can be easily repurposed to share externally. Depending on your companies. Sometimes the PM can, can come up with this, or someone on the marketing team or the product marketing team can come up with this roadmap so that you don't have to. So again, the sort of higher-level takeaway here is that if you have a product or if you have stakeholders that want to share information externally, you can still create that roadmap, but the work is actually involved in deciding what you don't share. So you can literally have something that looks very similar to this, where over time you share what will actually be added. And you could frame it in terms of MVP to V1 to be 1.1 staging. Or you can frame it in terms of something else, like MVP and testing or testing and then GAA, etcetera. 7. Template: thematic roadmap: Now let's talk about the last template, which is that the medic roadmap. I think this is a really great structure for a roadmaps that are complex or when you have a relatively large scope. Because it becomes an increasingly hard to really focus on what it is that you're doing and why in all you know, all within a document that presumably can speak for itself without you having to voice over it. So this is an example of what a theme-based or a rat can look like. Here, let's again assume that we have the same product that we're working for that audio book platform. And what you can see here is that this roadmap is clearly communicating some sequencing. So from the left to the right, starting with Q1, you're working towards Q3. And it looks like there's actually multiple features that this roadmap is referencing. And it also looks like this roadmap is communicating something to us about the expected time of delivery of those features. So feature x, it looks like takes quite a bit of time to build. And it will actually take us almost two quarters to get it out the door. And the other thing that's interesting about this is we get a sense of how long it may take to build a feature, but then we also get a sense of the overlapping timelines of those features. So that's telling me that, for example, feature E can only come once Feature D is finished. Now that could be because maybe it's the same engineers that are working on both features D and E. But it could also be because maybe feature E can only be built once you have insights from Feature D. Or maybe feature is infrastructure and actual implementation represents something in Feature D. Or maybe we only decide to build feature eat depending on how Feature D actually goes, right? So, so there's actually a lot here. But in terms of the information that the audience, whether it's engineering or sales, et cetera, support can actually get from the primary focus of this of this diagram, which is the actual feature enumeration. But other interesting things that this roadmap gets right as well. So what I want to call out is I want to call out the left-hand side. You can see that there's actually three themes that each feature is attached to. The first theme is around user experience. So it looks like feature X and Y are dedicated towards user experience, then there's content richness. So presumably these are features that are built for the audio book creators. Clearly content richness you can just see because of how much space it takes up relative to both of the other two themes is really important as a part of this product strategy. And then finally, the last theme is something around access. So this is probably features like logging in or saving or sharing, et cetera. So the main takeaway here is that the left-hand side clearly articulates with the themes are. And those themes loan just that articulation can help everyone understand what the priorities for this product area are. So the theme synthesize a narrative around the various actual tasks that, and just implementing. And that becomes really important in an area that either has a lot of launches happening or has a lot of complexity, or maybe a lot of lag time that otherwise makes it difficult for people to know when exactly things will happen. We also know as we learned from that loose framework of the product development cycle earlier, that sometimes you just don't know what to build, it just takes time, but still, the people that you're lecturing this roadmap, would they crave certainty? They want to know more, right? And so this is a great way for you to convey what, how you will actually decide to build features and what you will build by referencing to themes instead. The other great thing about this format is that it's great for communicating upwards and outwards. With non-engineering counterparts. You're not engineering counterparts care less about how much effort it might take. They just want the end result, they want the feature or they want to know what your strategy is that they can communicate it with customers or even internally within their own organizations. And this roadmap allows you to convey how much effort you are engineering team is building in. After all, it looks like each of these bars that represent a single, a single feature, their size, right? Like they're literally size in terms of how long it will take for them to be implemented. But it's still somatic and it's high level so it doesn't get too much into the details. And the other great thing about it is, and what this template gets right is that it manages expectations and when things can be delivered and how much capacity the engineering team actually has. So for example, let's say that feature D in the axis being towards the bottom of this diagram takes a long time to actually get built and runs late. Then we know the we here refers to your entire cross-functional team. That feature is likely compromised because of the sequencing that's involved here. And why are they compromised? Well, that's probably something that you've voiced over when he talked about the theme of access. So this diagram is also great for managing expectations because it conveys the information of, of effort as well as relative prioritization. 8. Roadmap software previews: So now that we've talked about the different kinds of roadmaps that you can build. Let's talk a little bit about how you can make the actual tactical work. Building an artifact much easier for yourself and for your team. So luckily, there's many products that are on the market that you can use to either build robot documents on top of your bug tracking or Sprint tracking research tracking is that our software, whatever it is that your teams used to organize themselves. And there are some products that actually offer you solutions alongside each of these pain points, including the templates for actually making roadmaps. So they're all pretty similar, but the four that I'll be talking about are Aha, product board, road, monk, and Asana. In terms of pricing, again, they're pretty similar, except with the exception being on Asana, which is price on a per user basis. But you'll see as we walk through both the clips today and then when you can check out the products on your own, on their websites, that there are some differences in the user experience. And then there's some differences in terms of the support that the company actually offers you. Some products offer you 24, 7 support. So with that, let's take a look at these four, these four products that you can use to make the work of putting together a roadmap much easier for yourself and for your team. 9. Aha: So here we'll start with Aha. So you can go to a ha and literally the URL as AHA dot io, they have multiple products and the one that you want to look at is their product roadmap, sweet. It's the first one that's actually listed. Now, a hot like the other three does offer a free trial so you can actually try it out before you try to adopt yourself or your team to it. But after taking a look through their demos and the information that they're sharing their site. I think they're distinguishing feature is that you can interact with the metadata that goes behind each of the tasks or the stories depending on the structure, like the project management structure that you're using. So yes, there is a visual format of the roadmap that you can put together. That's what, for example, they're showing here on this screen. But you also have really easy access to a lot of the other metadata that you may want to convey. Like, for example, the status of the feature, the name, how many points it's worth if your team is following this. Again, like the sprint structure, who it's assigned to, and higher level information like what feature or you know, like what initiative does this feature belong to? So I think that's something that I really like about yeah, ha, product. And if you're someone who really wants to be able to dive into the performance of your team, the velocity of your team, and like look at how you're working against your roadmap over time. This is especially good if you again, have like God defined responsibility for a specific set of features, then I definitely recommend this. It gives looks like it gives you a lot of data and even reports that you can use to learn about your velocity. But then other insights by in terms of the features or the initiatives that you actually have going on. And if you're more involved in project management, I think there's a lot of information, this product suite as well. So I would recommend a ha, if you're someone who actually wants to really be able to like run reports and analyze the performance of your team. And so, and also are closer to task management and don't just want an end sort of like template or like visual output. 10. Productboard: In contrast to a ha, there's also Product, Product Board. So it's again, the URL is literally product They have multiple products. Roadmap Solutions happened to you, one of them. So what stuck out to me while browsing through their site and looking at the information that they share is that they're distinguishing feature is that they offer a highly visual UI. And it looks like you can actually get a lot done, like actually build out your roadmap, whether it's, you know, you see, you can see it through this example sequence through time or through other groupings, more or less through a drag and drop feature. And so it seems to me that if you maybe have less time or less of a need to really get into the nitty-gritty details of product board can be a great solution to help you basically put together an end highly visual artifact in almost no time and doesn't involve a lot of input data. It also looks like they have a lot of other tools that can service other needs for your team, but you won't really get into that at this video. 11. Roadmunk: The next part here is roadmap. So the URL is And to have again multiple products roadmap and happens to be one of them. Just like aha and product board. They also offer a free trial. And so will the next project that I'll mention. But the distinguishing feature for me for road monk that are really wanted to call out is that they give you lots and lots of templates for you to work with. So literally on the landing page here you can see me clicking, try a roadmap template. You have so many options that you can start with and you know it because you have a free trial. And if you have time and this activity is really important to you, you can click through sort of all of them. But let's just go ahead and click on the very first example that they have, which is a product roadmap. Let's see what it looks like. So it looks like they give you two options if you want to define swim lanes. So you can see swim lanes in terms of the state, the status of the tasks, backlog design, as well as the component parts, right? So are you solving and infer problem testing, stickiness, improvements, or you can work with more of a timeline format. And what I love is that you can literally click Try this template. And if I had an account with road monk, presumably this would take all of my existing task information and fit it to one of these two templates. So I think if you're someone who as trying to get a roadmap created asap. If road monk drives down the setup time to nearly 0 it looks like and also gives you lots of different options. And they also have some collaboration tools and task management tools that you can use. But really to solve your roadmapping needs. It looks like you can get started within a couple of minutes. 12. Asana: And finally for Asana, and the URL for asana is a a and, and they also offer a free trial. It looks like a sauna has lots of solutions that basically give you the building blocks for all of your development artifact needs. So the first one, we'll focus on its product roadmap, which you see highlighted here on the screen. They like road monk also give you a template that you can immediately get started with. Now I don't have an account with them, so I'll get this I'll get this gated like it. That's sort of like account creation wall. But in addition to the product roadmap templates, they also give you lots of other, almost like a plug and play type templates. So you can see they have one for bug tracking, for Sprint Planning, for daily stand-up meetings, for usability testing plan. Now what I love about this is it's almost like they've given you, you know, like Legos, each of these templates, each of these documents that they give you an example of, you can literally plug them into your team to either introduce a process like sprint retrospectives or to actually give your team a little bit more structure, more memory by recording things like customer feedback, user research, what decisions you make and daily stand-ups, et cetera. So I highly recommend a sauna if you maybe are like sorting out a new team or if you feel like you're kinda doesn't have a lot of the the sort of like documents, documentation in place for processes that might already be taking place. But putting the process stuff aside, I think Asana also seems like a good product that can help drive down setup time for nearly 0 because it gives you templates that you can start with. And it looks like the templates are actually pretty intuitive and probably good for or are great for a roadmaps that are bit more timeline based.