PRODUCT MANAGEMENT : Product Management: Building a Product Roadmap

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Learning From LinkedIn

Product Management: Building a Product Roadmap

https://www.linkedin.com/learning/product-management-building-a-product-roadmap/welcome

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Why do we Need a Product Road_Map ?

A Product road map give product stake holders the information to coordinate plans . A product road map has no value if the product stake holders are not aligned in advance 

Steps of creating a Product Road Map . From identifying your stake holders to , creating mile-stone and scheduling them , to building alignment and evangelizing your roadmap, taking you from inception to implementation with down to earth insights based on real world experience 

A Product Roadmap only contains new functionalities 

What is a Product Road map ?

1. Roadmap definition and purpose
2. Product road map template
3. Roadmaps in Agile Organization
4. Roadmaps for early stage products

1. Product Definition and Purpose ::

Roadmap definition and purpose

Selecting transcript lines in this section will navigate to timestamp in the video

- You might be asking yourself why you need a product roadmap at all. After all, if you work on an agile product development team where you plan one sprint at a time, what's the point of making a long-term plan? And is it even possible to create a roadmap in a dynamic market environment? Through my experience, I've learned that for most organizations, product roadmaps can be extremely valuable, if not critical, to the success of the business, but only if they're built correctly. To understand why, we need to think beyond the product development team to the larger business that it serves. Let's start with the basics. A product roadmap is nothing more than a long-term product development plan that gives all product stakeholders the information they need to coordinate their planning. Before we describe exactly what a roadmap looks like and how to build one, let's talk about why we might need one and what exactly it's used for. The product roadmap allows all of the different stakeholders of your product to plan and coordinate their own future activities. Another way to think about it is that a product roadmap provides predictability to the product development process, and everyone loves predictability. Now let's examine a few of the product stakeholders, the different groups of people inside and outside of your organization who will be impacted by product development. Let's also imagine how the product roadmap can help them to become more effective. First, your customers. If you serve large enterprise customers, they often want to see your product roadmap to help them make purchasing and implementation decisions, especially if the industry is new and changing quickly. Second are the customer-facing groups in your organization, like sales, and marketing, and customer support. They may use a product roadmap to develop their materials such as documentation and training, all of which require some lead time. Third are your investors, your board, or executive sponsors who may use a product roadmap to estimate future revenues, and costs, and decide what level of resources to allocate to your group, including financial investments and a hiring plan. Last, and the one people often don't think about, are your own architects, engineers, and designers. They can use the visibility provided by a roadmap to create higher-quality designs for your product. Without a longer-term plan in place, design can become piecemeal and create unforeseen problems, and there can be many others. Consider your human resources team, who might need to change hiring plans, or your legal team, who might need to develop contracts, and so on. There's another critical but less obvious function that a product roadmap can provide. It forces the leadership team of your business unit to clearly articulate its business goals and its strategy for achieving them. Having a product roadmap helps ensure that your product development efforts are aligned as closely as possible with your strategy. And having the key stakeholders aligned around that roadmap ensures that everyone works together effectively.

2. Product roadmap template ::

Selecting transcript lines in this section will navigate to timestamp in the video

- Now you might be wondering, what should a good product roadmap actually look like? Before I show you a roadmap, let me start with two caveats. First, there is no one format that will work perfectly for every organization. Different organizations have a variety of development processes, sales cycles, and decision making processes. For instance, on a small team with an early stage product, a white board photo of a prioritized list of future initiatives might serve as an adequate product roadmap. While in a large organization with a mature product, you might need a long slide deck with the detailed product strategy and feature breakdowns of each project. Second, and this is extremely important, the format of the document is far less important than the support of key stakeholders. Even the most beautiful product roadmap is worthless if your stakeholders don't really believe in it. The key to building this alignment is the process you go through. Not the final format or even the contents of the product roadmap. That said, here's a typical product roadmap format that works well in many organizations. You can download it from the exercise files. As you can see, this roadmap uses a graphical layout that can be easily drawn on a slide using software like PowerPoint. The roadmap shows the future time periods along the x-axis at the bottom and the different products along the y-axis on the left. And then plots the upcoming milestones for each product across the grid. The milestones are typically shown just as text boxes that are positioned at their release date. Or they could be long horizontal bars corresponding to the time period when the Dev team will be working on them. The right edge then is on estimated release date. So let's talk about how this might look in practice. Let's use the example of a digital publishing company with three mature products. A blogging platform, a website authoring tool, and a mobile app authoring tool. In this example, the x-axis shows the upcoming four quarters, and the y-axis breaks the product into three categories corresponding to the three different products you offer. And there are seven milestones on the grid. Here are some potential variations to this basic format. Depending on your product's maturity and your development process, it may be appropriate to use different time frames such as months, weeks, or even years. And you might choose to base the product categories on something different such as customer segments or strategic initiatives or different platforms you support. Now let's talk about the milestones on the grid. Remember, the purpose of this document is to allow each of your product stakeholders, including key customers, to coordinate their planning around this product development plan. So each milestone should be a meaningful bundle of new functionality that will have significant impact on your business. The product roadmap is not a complex document. Quite the contrary, you should strive to make it simple and easy for everyone in the organization to understand. But don't let that simplicity fool you. Creating a roadmap with the right milestones on the right release dates in a way that implements your product strategy and has all stakeholders aligned around it is no mean feat.

3. Roadmaps in agile organizations ::

Selecting transcript lines in this section will navigate to timestamp in the video

- If you work with an agile product development team, you probably have a product backlog. For those of you who aren't familiar with it, the backlog is a prioritized queue of the next most important product development tasks. And if you have a product backlog, you might be wondering whether you could use your backlog as your roadmap. After all, just like the roadmap, the backlog contains the projects that your development team intends to do in the future. Let's remember, a product roadmap is designed to give your product stakeholders the information they need to coordinate their own plans. So does your product backlog provide that? Your stakeholders, such as your customers, marketing group, or finance group are typically interested in milestones that will bring new customers, new marketing efforts, or new revenue. The product backlog, on the other hand, tends to be full of small tasks, like user stories or bugs. To release a milestone that matters to those stakeholders, you'll need to complete large numbers of tasks in your backlog. Your product stakeholders are also usually interested in knowing when the milestones will be available to customers. The backlog does intend to provide estimated release dates. So your product backlog isn't going to cut it as a product roadmap. In fact, you're going to need both. So there will be a close relationship between your product backlog and your product roadmap. In fact, each milestone shown on the roadmap will eventually have to be turned into a large set of tasks on the backlog. That milestone will only be completed when all of the backlog tasks have been finished. And while the backlog often contains lots of different types of items, such as bugs, product maintenance tasks, and engineering driven tasks, the product roadmap only contains new functionality. So this brings up an interesting question, how can you possibly put dates on the product milestones when the backlog tasks they're made up of don't yet have any dates? The answer is unsatisfying, but tends to work in most organizations. You estimate the dates of the product milestones on the roadmap using a completely independent set of top-down estimates from your product development leader. In the end, these estimates are inaccurate, of course. But as long as they're close, they'll serve the purposes of the product roadmap, to allow coordination among the different product stakeholders. Increasingly, your backlog will be directed by the product roadmap, which is one of the main ways you ensure that the activities of the product development team are aligned with the needs and goals of the whole company.

4. Roadmaps for early-stage products ::

Selecting transcript lines in this section will navigate to timestamp in the video

- There are times when you can't and shouldn't even try to build a product roadmap. Picture Christopher Columbus in the days leading up to his voyage from Spain to search for a western route to the Orient. Imagine asking him for an estimate of what he was going to bring back and when. It would be a fool's errand, because his intention was to explore a completely unknown territory. And, of course, he'd be learning along the way and making decisions in response to what he had learned. When you're developing a very early-stage product, when you're exploring a new market, a new customer and product, it would be foolish to try to plan out what you're going to develop far into the future. In the very early stages of the product, the team doesn't have a product strategy. They don't know enough about the market to form a coherent, well-founded strategy. Instead, they probably have ideas about some unmet customer needs and a possible way to meet those needs to create business value. In this case, the purpose of product development isn't to support the product strategy. It's to learn about the market and the customers and validate the hypotheses that will later form the basis of the product strategy. So how do you know if your product is mature enough to build a product roadmap? I think it's safe once your product has achieved product market fit, and you're able to articulate a product strategy that is based on solid market and customer knowledge. And how do you know if you have product market fit? Well, one definition is that you have a set of active, engaged customers who'd be very disappointed if they did not have access to your product. Until you get to product market fit, you should have a set of hypotheses that you're validating at every given moment. And instead of a roadmap, you should have a list of development projects that will allow you to validate these hypotheses as efficiently as possible. If you are working on an early-stage product that has not yet achieved product market fit, and someone, anyone, even your CEO comes to you and asks you for a product roadmap, tell them that you won't do it. Instead explain to them the key hypotheses that you are currently validating, and tell them that you'll be happy to build them a product roadmap after you've got to product market fit.

Laying the ground work ?

1. The importance of process
2. Why roadmaps fail
3. Select your stakeholders
4. Customer research
5. Start with product strategy

1. The importance of process ::

Selecting transcript lines in this section will navigate to timestamp in the video

- A product roadmap, no matter how good it may appear to be, has no value if key product stakeholders aren't aligned around it. I've seen it happen over and over again. The CEO and the product leader at a startup are preparing for a company presentation, and together, they create an excellent roadmap for the development of the product based on a brilliant strategy for leapfrogging the competition. It correctly prioritizes strategic features while delaying some others that some executives have been asking for. They present the roadmap at a company-wide meeting, and it seems like everyone is aligned. But a few weeks into the execution of the plan, things start to go wrong. Development falls behind schedule, and when the VP of engineering is asked about the delays, he says that the plan wasn't realistic in the first place. "I could've told you on day one we couldn't "hit those release days," he says, "but you didn't ask me." Then, when they finally release the strategic features, sales are lower than expected. When asked about missing the numbers, the VP of sales says it doesn't have the features his customers have been asking for, so there's no way he can hit the numbers. He also says that he knew about this ahead of time and could've told them, but wasn't asked. So what's the problem here? Why isn't this new roadmap working? Well, the problem, of course, is that the CEO and the product leader didn't take the time to get the team aligned around their roadmap in advance. It didn't matter that the roadmap was excellent and the strategy behind it brilliant. It was never going to work. So the reason you need to get key stakeholders aligned around your product roadmap is that product development doesn't happen in a vacuum. The purpose of product development is to serve the business, to support the company's overall strategy, usually by winning customer adoption, loyalty, and ultimately, revenue. And that almost always requires that all of the different functional groups in your company work together, including sales, marketing, customer support, and so on. If any of them aren't on board and doing their part, it's going to present a major barrier to the success of the product plan achieving its intended objectives. There are many ways to get alignment around a plan, but alignment is easier to achieve when you include your stakeholders early in the process, when you take the time to ask for their feedback and address it, and when you keep all of your stakeholders updated as the plan takes shape and evolves into its final form. When people are involved in making something, they feel ownership, and they'll promote and defend it. Sometimes, all of the meetings required to build alignment can seem redundant and laborious, but I promise you that it's worth it. If you find yourself wondering whether you really need to spend so much time on building alignment, think of it this way. The stakeholder alignment itself is actually the goal, and the resulting product roadmap document is only there as a reminder of what you are aligned around.

2. Why roadmaps fail ::

Selecting transcript lines in this section will navigate to timestamp in the video

- In order for a product roadmap to be successful, it needs three things. It must be based on a sound product strategy. It must be realistic. And it must be fully supported by the key product stakeholders. And when a product roadmap fails, it's always because one of these things is missing. The most common failures I've seen come about because someone tries to shortcut the process and fails to accomplish one of these things. Many organizations have a strong and persuasive leader who cares deeply about the future of the business, who is very knowledgeable about the market, and who thinks that they know exactly what we should build next. This is typically the founder, but it could be the CEO or the sales leader or even the CTO or product leader. What often happens is that this person uses their intuition to build a product roadmap and then uses their powers of persuasion to push it out to whole organization. While in rare occasions this person may be so talented that their intuitions are correct, take Steve Jobs for example, it often doesn't work out that way. If you are a product leader who is working with someone like this, you have an added challenge. You need to channel this person's energy into a process that will ensure you end up with a successful roadmap. It's extremely important not to let this person's intuition, no matter how good or well-informed it is, dictate the roadmap. There are several good reasons to prevent this. First, their intuition can be faulty and there is information from the rest of the stakeholders that the leader doesn't have or isn't taking into consideration. You can end up with a roadmap that is based on flawed assumptions about the market or which is just plain unrealistic. Second, when other company leaders and stakeholders aren't part of the decision-making process, you can end up with a lack of alignment, meaning that some people will not be supporting it or worse actively trying to undermine it. Here's the best way to handle this situation. First, try to spend some time with this leader at the very beginning of the process. Ask them for their ideas about the roadmap and the development projects that are most important to them. Also ask them for the thinking that underlies the selection of these projects. This person most likely has valuable knowledge about the market and the customers so make sure you capture that as well. After this person has been fully heard and their opinions recorded, explain to them the importance of including other product stakeholders in the process. Let them know that stakeholders are more likely to be aligned and to actively support the plan if their opinions are solicited and incorporated. Also explain that it's a good idea to estimate development time for these projects so that the plan can be as solid as possible. If they object, reassure them that you can run the process quickly and that it doesn't need to slow you down. In most cases, this logic will appeal to those in charge and they'll support the rest of the process.

3. Select your stakeholders ::

Selecting transcript lines in this section will navigate to timestamp in the video

- Choosing which stakeholders to include in the roadmap creation process is incredibly important. If you're missing a key person, it can come back to bite you later. And if you include people who aren't central to the plan's success, it can waste your time or even put a drag on the whole process. Your most important stakeholder, as well as your partner in building the roadmap will be your business leader, usually a CEO or general manager of your business unit. Ideally, this should be someone who leads the business functions other than product development, including sales, marketing, and customer support. You'll need this business leader to allocate the resources, especially the headcount, and you'll need them to remind each of the stakeholders to prioritize the tasks necessary for roadmap success. For this reason, you must include them early and often in the process of your roadmap development. They must feel complete ownership, like the product roadmap you developed together is their own. Next, you probably also need your sales leader, like your VP sales or chief revenue officer, since they have to hit the sales targets based on the product roadmap, and you don't want friction there. Let's face it, companies tend to organize efforts around revenue streams and the sales leader will have the ability to rally other resources to make the roadmap successful. The third person you need onboard is your product development leader. They'll be responsible for organizing and motivating their team to hit the roadmap milestones. In many companies, this is likely to be your chief technology officer or VP of engineering. In large organizations, it may not be easy to identify your stakeholders, because the teams are organized functionally. You might need a person deep inside the sales group, another from inside the engineering group, and so on, each of whom report up into their own larger functional organizations. When you're working across groups, there may not be a single clear business leader. In these cases, I've often found it useful to use the sales leader as your business leader. So that's the core team for roadmap development, the product leader, you, the business leader or CEO, the sales leader, and the product development leader. In many cases, a team like this can develop a strong roadmap that effectively guides product development over the long-term. That said, it can be useful to include other stakeholders in the process, at least for some key decisions. For example, if you have a strong operations leader, like a chief operating officer or a VP of customer service and you have a product that is going to require a lot of operational work, it can be valuable to include them too. But whomever you choose to include, make sure they will be adding to and not distracting from the process.

4. Customer research ::

Selecting transcript lines in this section will navigate to timestamp in the video

- People sometimes ask me how to earn respect as a product manager. The answer is simple. The more you know about your customer and your market, the more you can speak with authority about the impact of specific product development options. Customer knowledge is the primary currency of a product manager. So how do you learn more about your customers? By talking to them of course. If you haven't done it before, now would be a great time to invest in learning about your customers. This will help you build a product roadmap that's likely to have the intended impact and achieve your business goals. Here's the question you need to answer. What decisions do your customers need to make in choosing your product? What problem are they trying to solve? What other options are available to them today? Sometimes the choice is between your product and a competitors. And sometimes it's between your product and doing nothing or addressing their need in some other way. The best way to figure this out of course is to go right to the horse's mouth and ask your customers directly. Here are a few common ways you can do this. If you're in a large company, you may already have a research group that has the answers to the questions you're asking. If not, you may be able to initiate a new research effort with them. It's more likely you'll need to ask your customers yourself. There's several ways you can do this. You could of course design a survey and send it out to a small sample of your target customers using any number of widely available survey software tools. You could also just participate in sales or customer service meetings either as an active or a passive participant. I found however that direct qualitative customer research yields more insight more quickly than almost anything else you can do. Here's how it works. Reach out to a handful of your customers directly with a personal phone call or email. Introduce yourself as the product manager and ask them for a few minutes of their time to learn about their experience using your product. You'd be surprised how many people respond positively to a request like this. Then in your conversation, after you introduce yourself, ask them to share their screen and watch them actually using your product, listening to their observations along the way. You should also ask them a few questions. Why they decided to try your product, what their other options were, and whether or not they plan to continue with your product and why. You can also ask them what they wish the product did differently. How many customers should you talk to? Well, you know you've talked to enough of them when you start to be able to predict how they're going to answer your questions. Amazingly, in practice, for many products, it seems like five customer conversations is often enough. After even the first few conversations, you're sure to bring home lots of insights about what they need, how they make decisions, and what the product needs to do differently in order to achieve your business goals. When you bring these insights back to the rest of your team, you'll be able to speak with authority and you're sure to earn their respect.

5. Start with product strategy ::

Selecting transcript lines in this section will navigate to timestamp in the video

- Suppose I showed you a product roadmap from my company and asked you what you thought of it. How would you know whether it was a good product roadmap or a bad one? You likely realize that you can't really determine the quality of a roadmap unless you know a bit more about my business. So what kinds of things would you want to know? Well, who my customers are and what their needs are, what features our product currently has, and how well the product is meeting the needs of our customers today. And finally, what are the competing products in the market and what functionality do they have. You might also realize that you can't be sure of what my business objectives even are. Maybe I want to capture the whole market. Perhaps I just want to build a strong business in a niche segment. Perhaps I'm trying to grow revenue. Or perhaps I'm just looking to acquire new users. The point here is that you can't really evaluate the quality of my product roadmap without knowing something about my company's strategy. So, the first step in roadmap development is to clearly articulate your product strategy. A product strategy is a description of the way your company or business unit intends to achieve its business goals with its product. Here are some of the key questions that a product strategy should typically answer. First, what are your business goals? And how will you measure success? Next, who are your target customers? Which customers do you really want to win? What are the key needs of your target customers that you think you can meet? And what is the key benefit that your product will provide to these target customers? Also, what are the key competitors to your product? What other options do your customers have? And finally, what are the key differentiators between your product and those of your competitors? Although it's not essential, I found that in practice it's extremely helpful to write down the answers to these questions in a brief document. And even though you, the product leader, may be the person initiating and facilitating the product strategy process, it's critical that your business leader feels like the owner of this strategy. In other words, they must be the key participant in developing it and they must promote and defend it actively with the senior members of your team. The resulting document should be their document, not yours, but you must make sure it answers all of these questions to a sufficient level of specificity. Once your business leader has a product strategy articulated, in a shared doc or a short set of slides, make sure to discuss it with each of your product stakeholders. It's best to start with one on one meetings where people feel more comfortable giving you their unbiased feedback and concerns. Then after incorporating their feedback, have one group meeting where everyone discusses and hopefully agrees to support the strategy. If you don't have alignment, you'll need to go back and do it all over again. With a product strategy in place and your key product stakeholders aligned around it, you're ready to start building your roadmap.

Decision making and building alignment ?

1. Identify key milestones
2. Estimate levels of effort
3. Build the strawman
4. The product road map meeting

1. Identify key milestones ::

Selecting transcript lines in this section will navigate to timestamp in the video

- This next step may well be the most creative part of building your product roadmap. Let's say you've assembled your team of product stakeholders and together have aligned around a specific product strategy. Now it's time to identify the sequence of product milestones that best implement that product strategy. Before you start asking your stakeholders for their ideas, it's often best to start with a little of your own research and thinking. Start by rereading your product strategy. What are the barriers to achieving this strategy? And which ones could be removed or at least improved by changing your product in some way? Hopefully you've spent some time researching the market and in particular your target customers and you understand the decisions they make when choosing to use your product. Think about the barriers that prevent your target customers from adopting your product. As you do so, try to imagine the major product changes that you believe would have the desired impact on the strategic objective. Often these will be features that your customers have asked for directly. But sometimes they might be features that will benefit your customers but haven't even occurred to them yet. Remember that milestones can be impactful in different ways. Some may just address pain points of existing customers, increasing their usage or reducing their churn and other milestones may allow your customers to use your product in new ways and reduce some of the appeal of competing products. Some might be intended to open up new markets for an existing product or even launch a new product that has strategic value to the business. And sometimes the milestones won't directly benefit your customer, but would benefit some other strategic objective like opening up a new distribution channel or lowering your cost structure. Make sure you're thinking about things at the right level of granularity. These are not backlog tasks. These milestones should be major product changes which will take significant amounts of research, design, and development work and will correspond to perhaps dozens of tasks on the backlog. As you write down each milestone, be sure to record the strategic objective that it supports as well as the rationale. Your rationale should be high level and easy to understand. For instance, if your strategy calls for winning over a specific customer segment and you know that the primary reason they're not currently adopting your product is because it's too expensive, then your strategic objective might be to reduce your cost of service delivery. You probably want to propose a milestone that would significantly lower your cost like automating some manual tasks or switching service providers. Notice that at this point, you have not yet put dates on any of these milestones nor could you because you don't yet know how long they would take to build. We'll do that in a later step. But you can try to put the milestones in a rough priority order. Once you've done your best to brainstorm the milestones on your own, it's probably a good idea to meet with each of your product stakeholders to see whether they can think of any that you might have missed. I found that it's best to meet with each stakeholder one-on-one to increase the chances that they'll share their ideas freely with you. At the beginning of each of these meetings, start by reviewing the product strategy with your stakeholder and then ask them for their ideas about which milestones would best support that strategy. Once you've exhausted their ideas, review the other milestones you proposed with them and ask for their feedback as well as their sense of priorities. At the end of this process, you should end up with a sequence of product milestones, each of which has measurable impacts on one of your strategic objectives and which together will implement your product strategy.

2. Estimate levels of effort ::

Selecting transcript lines in this section will navigate to timestamp in the video

- Now it's time to estimate the level of effort required to complete each of your product milestones. This will help you put dates on the roadmap that are as realistic as possible. You'll need to work with your product development leader on this. To start, you'll need a realistic estimate of the development capacity of your team. Usually, we measure these in developer time units such as developer days, developer weeks, or developer months. While it seems like the development capacity of the team would be obvious, after all, it's just the number of people you have developing multiplied by the time unit, you'll soon find out it's not so simple. A typical product development team does a lot of things other than build new features and functionality. Typically, some of their time is spent on bug fixing, product maintenance, and engineering-driven projects. Ask your product development leader to estimate the amount of time the team currently spends on these items. Usually, it's easiest to compute it as a fraction of their overall capacity. Like 25% of their time on bug fixing, 20% on product maintenance, and 20% on engineering-driven projects. Once you remove the time spent on these items, whatever is leftover, in this case, 35% of the total, is the capacity available for development of new functionality for your roadmap projects. The next thing you'll need to do with your product development leader is to estimate the amount of development time each of the milestones is likely to take. It's a good idea to capture this information in a spreadsheet. A typical layout might look like this, with one row per milestone and columns for the strategic objective, the milestone summary, the source, and of course, the development time. Now, since the milestones are much larger and more complex than a typical backlog task, it's going to be quite difficult for your product development leader to estimate the scope, and they might even be reluctant to try. Be clear that you're not asking them or the development team to commit to these estimates, you're just asking for their best guess. In fact, it's a good idea to put this disclaimer at the top of your spreadsheet to remind everyone that you share it with that they are only time estimates and are subject to change. If, after scoping, some of the milestones are too small, it might not be worth listing them individually on the roadmap. In this case, you might want to try to group them together into a larger milestone that supports some element of the strategy. And if some are too large, see if there's a way you can decompose them into smaller milestones while making sure that each still has an independent business impact. Once you're done with this phase, you should have a spreadsheet with enough information to build a product roadmap with milestones that are realistic for the team to complete.

Estimating the effort :

3. Build the strawman ::

Selecting transcript lines in this section will navigate to timestamp in the video

- Finally, it's time to build the first version of your product roadmap. I call this version a strawman because it's just a rough first draft, and it's likely to change a bit before it gets approved by the team. It's a good idea to produce a strawman before meeting with your team, because you're more likely to have a productive discussion when you start with something concrete for people to react to. Your first step is to roughly sequence your milestones in terms of their value in supporting your product strategy. Go through them one at a time and remind yourself of the rationale for each one and prioritize them. Your next step is to schedule these milestones into your roadmap. You can start with the most basic approach to scheduling. Look at your first, highest priority milestone. Use the effort estimate provided by your product development leader, as well as the development capacity of the team, to figure out when on the calendar you could expect it to be delivered. For instance, if the milestone requires 20 developer weeks and your team has five developer weeks of capacity for new feature development every week, then you can assume for now that the milestone will be released in four weeks, assuming the team can get started now. Next, you pick up the second highest priority milestone and assuming that the first one is completed on time, schedule that one in the same manner. When you're done, it should look like this. Now there is another approach to roadmap scheduling. You can instead look at time periods out into the future, like the next four quarters or the next six months. In this case, you identify a set of high-priority milestones that can be completed together in the first time period and a set of lower priority milestones for the second time period, and so on. And when you're done, it might look like this. In each case, you need to be mindful of the total development capacity of your team in each time period, of course. This approach has the advantage that it sets less precise expectations about the exact delivery date of each milestone, which can be a good thing, because the scope estimates are approximate anyway. In larger product development organizations, you'll probably have multiple development teams working in parallel. If the teams are organized around distinct products or customers, like publisher tools and advertiser tools, you'd probably have separate milestones for each of them, and should schedule them separately. You can then draw them on your roadmap diagram like this. Add separate rows of releases set on the same horizontal time axis one above the other. Scheduling becomes more challenging if the teams are organized functionally, so that each team owns different system components, like a front-end team and back-end team. If this is the case, you need to figure out the capacity and effort required of each team separately. You'll also need to schedule the milestones in such a way that each of the teams will have enough capacity to complete each of the milestones in the time period you schedule it for. Once you're done and have a completed schedule, take a step back and run a sanity check on your strawman from a few perspectives. First, ask yourself if it implements your product strategy. Try to make adjustments so the impact on the product strategy is maximized. Ask yourself, is it feasible from a development resource perspective? Run it by your development leader again, and make any adjustments they deem necessary. If the answers to these questions are yes, then you've got a strawman, and are ready to share it with your team.

4. The product roadmap meeting ::

Selecting transcript lines in this section will navigate to timestamp in the video

- Once you've created a straw man product roadmap of your own, you're ready to get together your product stakeholders to review and hopefully approve your roadmap. This is the most crucial step in the whole process. Remember, the purpose of the product roadmap is not the document itself, but the alignment of the different product stakeholders around the development plan that your roadmap represents. You'll want to plan and run this critical meeting in close collaboration with your business leader like your CEO or general manager since they directly manage most of the product stakeholders and have the authority to ask for their participation. At the start of the meeting, explain the goal, to emerge with a shared product roadmap that all stakeholders fully support and can use in their own planning. The first item on the agenda should be a quick review of your product strategy. Explain that it's the foundation and that the roadmap must be designed to implement the strategy. It's critical that you check for alignment at this stage. If your team isn't aligned on the strategy, it's pointless to discuss the roadmap. The second item on the agenda is to review the development capacity of your team. Have your development leader present the team's capacity and explain how their time will be spent on things other than new product development such as bug fixing and engineering-driven projects. Next on the agenda should be a walk through of your product roadmap straw man. Present each milestone one at a time as well as the strategic objective for each. Try to get through all the milestones before you start making changes just so people know everything under consideration. Remind the team that each of the milestones has an associated developer time estimate and that the releases on the roadmap are designed to fit within the limited resources. At this point, ask your team what they wish was different in the straw man. It's important in this step to hear some diverse opinions about the roadmap. This is how you'll actually surface the important issues facing the business. I found that it's best to modify the product roadmap directly in the meeting so everyone can see the consequences. It's best to work together using a live spreadsheet. It's critical that when you agree to move one milestone up to an earlier release date or time period, you also then have to remove other milestones of equal size to compensate and push them back to a later date. This is how you show the team the tradeoffs of the decisions they are making. Sometimes this will result in negotiations or trading between team members. For instance, one person might give up a feature in the next quarter to gain something else immediately. This can help resolve disagreements. As you proceed, keep inviting the group to think about the future success of the business rather than just their own interests. In the best case, the team will reach consensus. Of course, it's not always possible to get the whole team to agree fully with the roadmap. But you do need to make sure that the whole team is aligned with the decision. In this case, it's your business leader's job to make the final decision and check for alignment with the rest of the team. If you haven't gotten to this point by the time the meeting is over, schedule a followup session to resume the process. At the end of the meeting, everyone should be looking at the revised product roadmap in the spreadsheet and agreeing to support it publicly. There you have it. Congratulations, you've just built yourself a product roadmap.

Common Challenges ::

1. Evangelize the roadmap
2. Maintain the Roadmap

1. Evangelize the Roadmap ::

Selecting transcript lines in this section will navigate to timestamp in the video

- Once you have a roadmap that's been reviewed and approved by your key product stakeholders, it's time to start building alignment for it among all of your product stakeholders including those inside and outside of your organization. These are the people who weren't in the meeting but who will need to support the roadmap and use it moving forward. In some cases, this may include your customers and partners especially if you have a close relationship with them. The first step is to create a short presentation that simply presents the key elements and decisions of a product roadmap as well as the rationale behind them. It's often good to start with a slide or two that reminds everyone of your product strategy, what are the top-level business objectives, who are your target customers, and how you plan to win them over to your product from the competition. The meat of the presentation should be a slide with the product roadmap diagram which shows the time periods on the x-axis, different customers or product categories on the y-axis if needed, and the milestones in the grid. Then it's good to have a few rationale slides, one for each of the key decisions where you had to favor one important project over another. These are especially important for projects that got delayed but are popular with some set of customers or internal stakeholders. It's important that you show the project supporters you understand how important the project is to them and that there's a good reason why it was delayed. The next step is to schedule a series of one-one-one meetings where you present the new roadmap to any product stakeholders who will be impacted by it but who did not participate in the roadmap development process. These could be leaders of operations, customer service, technical support, finance, legal, and so on. In these meetings, explain the decisions made by the team and the thinking behind it. At the end of each of these one-on-ones, you need to check for alignment again. You might say something like, "I know you're not getting everything you wanted here, "but can you live with this? "Or is there something we need to revisit with the CEO?" If there are any major issues that the decision-making team missed, you'll have to raise them again to the whole group. Once all the one-on-one meetings are completed and all the key stakeholders are aligned, it's time to roll out the roadmap to the entire company or business unit that it'll impact. It's best to do this as part of an all-hands meeting. This large group meeting is expensive so your presentation should be brief about 10 to 20 minutes max. Any longer and you'll lose a lot of your audience. It's also a best practice to do a public question and answer session at the end of your presentation. Be careful that you always present the product roadmap as the result of the team's efforts. It's not my roadmap and I decided, but our roadmap and we decided. If appropriate, make sure your external facing teams also have an easy way to share the roadmap with your customers and partners. Often this takes the form of a one-pager that your salespeople and account managers can share with them. Once these meetings are over, your work is done. Your whole organization and its customers and partners can now operate in close coordination with your product development plan.

2 . Maintain the Roadmap ::

- Even though some of your stakeholders might wish otherwise, product roadmaps are dynamic documents. They have to be. They represent your organization's development plan at a particular point in time based on the best information available to you at that point in time. When you learn new information about your customers or the market, guess what? You'll need to update your roadmap. So how do you know when it's time to update your roadmap? When you've learned something new that makes the old roadmap no longer seem like the optimal course of action. There are several types of new information that you might encounter. First, you might've learned information about your customers' needs and desires. For example, you might've tried out a new pricing model and found out that your customers won't accept it. Second, it could be information about your competitors. Say you've just read a major announcement from one of your competitors which makes them more of a threat than you thought. And third, you might've learned something new about the time or cost of product development. The projects that you prioritized on your roadmap might be taking much longer than anticipated to complete. In all of these cases, you'll probably want to revise your roadmap. Sometimes, team members may approach you and ask for changes to the roadmap. In these cases, it's important that you try to understand the reason for the change. What's the new information that's been learned since the last roadmap update? In some cases, you might find that there really is something new. But in others, you may discover that one of your team members is still not aligned with the decisions made in the previous iteration and still trying to promote their point of view, in which case, you might want to alert your business leader. The frequency of roadmap updates can vary widely between organizations. If the product you're working on is very immature, you're probably learning new information all the time, so your roadmap will probably change very frequently. If the product is much more mature, and your market is very stable, you might not need to revise your roadmap at all, that is, until everything's been released. Remember that the decision about whether and when to update the roadmap is your responsibility. As the product leader, you're the guardian of the product roadmap.