 Hello, everybody. I'm Pawan, Senior Product Manager at Amazon Web Services. I bring in more than a decades of experience in building, launching, and maintaining technology products. Currently, I manage tools and services that enable AWS IoT customers and partners to validate and build well-architected IoT devices. Before Amazon, I built and managed products at Symantec, Everton Packard, and Samsung Electronics. Today, I would like to provide my perspectives on how to build and execute roadmaps. I will answer four questions today. What is a roadmap? Why is a roadmap important? How to build a roadmap and how to execute a roadmap? Let's quickly take a look at the example that I'll be using throughout this session. We'll be assuming that you're a product manager for a supplier-side portal for a right-sharing app such as Uber. And you as a product manager is tasked with the responsibility of coming up with a roadmap for 2021. As you would assume, there will be a lot of many features that you would need to take care of within this experience. There would be account creation, account verification. There would be things like payments, reporting, number of rights that the supplier did, so many other aspects that you would be owning. And you as a product manager would need to take a holistic look and come up with a plan on how you want to utilize the resources and investments in a productive manner. With this background, let's understand what is a roadmap. In very simple terms, a roadmap gives a path to reach your goal or objective from the current state. Your current state is nothing but the state of union of your product. And the objective or the goal is what you want to do or where you want to reach from a product perspective. You might want to increase adoption or revenue, profitability, reduce costs, lower user friction. There can be many different things that you want to do for your product. A roadmap gives a clear path on how you will reach the goal or objective from the current state of union in a given timeframe. If you see in this example, the current state is A and the goal is B and the roadmap shows a path from A to B for a given timeframe of one year. Now that we know what is a roadmap, let's understand why it is important. If you ask me, the roadmap is like an anchor for product development. It provides clarity to your stakeholders on what you want to do and by when. Stakeholders could be your internal stakeholders such as marketing, sales, operations or support or it could be your customers or combination of both. So roadmap basically tells them what you want to do and by when. In this example, for example, in a supplier side portal, the roadmap is communicating that you want to make it more easier and secure in a period of one year. And the roadmap is also communicating that you'd be doing it by launching or developing four different milestones of M1, M2, M3, M4 on March, July, October and November. So your stakeholders, which are your internal or external such as suppliers would get clarity on what you want to do and when. This clarity helps them to prepare themselves for the actions that they need to take. For example, your software development team can take actions such as having the right resources, right number of resources and right scales to implement this roadmap. Your other business functions such as marketing and sales and support can take necessary actions from their side to be prepared to know read the subjective. And your customers or suppliers themselves can plan from their side on what they want to do for each of these milestones. Another reason why roadmap is important is roadmap allows you to review your plan in advance with various different people and then identify any gaps if there is any in the plan and then take corrective actions for the plan. In the absence of roadmap, there will be a lot of subjectivity. Every person would interpret the product in the way he thinks is right and would assume this is the product's objective and this is what will be done. In the absence of roadmap, they would be expecting many different things to be done on the product. So roadmap is sort of expectation setting exercise where you clearly communicate. This is what I want to do and by this time frame. Now that we know why roadmap is important, let's see how to build one. I see building up of roadmap as a first step process. First, you would consolidate all the feature request or your product backlog. Then your stack rank, all of this feature request. Then you would prepare a prioritized roadmap with dates. And then you review this plan with several people or stakeholders before starting of your execution. Let's go into the details of each of this step. Step one is to consolidate all of the feature request or build your product backlog. This is nothing but an exercise of knowing the current situation, knowing what has to be done, knowing where are the gaps and what all improvements need to be done. You can do that by doing five things. First, you as a product manager will use the product, will look at the customer reviews, issues from customers. You would also look at customer adoption, journeys and several metrics and build a perspective around what are the places you want to improve. Then you would go and talk to your customers and understand from them on what is working, what is not working, where are the areas this product needs to improve. You would also speak to your internal teams who are customer phasing because they also bring different perspectives. And you get to know from them on what are the improvements that we have to make on this product. The internal stakeholder teams can be marketing or sales or support or operations, legal, finance, all these things, right? Which are basically using your product in one or the other manner. You would then also speak to your own development team, which obviously knows your product, which has built the product, which understands the backend technology being used and its limitations. So the development teams many times has good ideas on how to make improvements and what you want to do. You would also speak to your senior leadership and get a perspective from your senior leadership because they would have high level strategy and vision at organization level. And that might be a few things that they're expecting your product to deliver. Once you do all five of this, you would basically get to know on what all you want to do. You would then jot down all this request in a Excel or a Word document or any other tool. For each of this request, you would basically have a small description to convey what is needed. You would also need to have description around the benefit itself on why it is needed. And then details around who requested, whom it is impacting and all those aspects, right? So for this example of suppliers at Portal, there are requests that have come from suppliers that have come from your internal teams such as operations. There is a request that has come from your own development team. So you would jot down all this one to end request, which is coming from faster registrations to launching of a new mobile app. You would have descriptions for each of this item, call out the benefits and the request a name. And you would keep in a state so that you can reveal them and stack rank them as and when needed. Now that we know what all we want to do, we need to stack rank them to understand which is more important when compared to others. To do the stack ranking exercise, first you have to determine the factors using which you will stack. In this example, we have considered simpler experience and security as two factors, which we will, which we have used to score all of the request. These criteria, so the factors are derived from the objectives. We wanted to make the portal much more easier to use and more secure. That's why we selected the factors of simpler experience and security. You could have more factors or less factors, you could have a score range ranging from one to 10 or any of the score range, it's up to you. But once you have the factors in the range, you would go through all of the request that you got in step one and stack ranked them based on these factors. For example, here, electronic payments to suppliers is ranked one because one, it really improves the experience for the suppliers. They're working hard, they need money and electronic payments allows to pay them very quickly and it's very secure way of paying. So it's scored very high on both of the factors. That's why it's ranked one. And then there is aspects such as localization, which improves the experience but doesn't, you know, impact from a security perspective, so it's ranked lower. It's perfectly fine if many of the requests have similar scores, then you, you know, take a judgment on which one has to be ranked higher versus lower. And it's also a good idea to review your scores and the stack ranking with your peer product managers or with your few of the stakeholders so that they are also aligned with the approach you are using and the criteria you're using. Once you stack rank all of the request, the next step is to prepare a prioritized roadmap. At the end of the day, you don't have infinite amount of resources. You have a team which is limited in resource. You have stakeholders who are busy with a lot of things and customers themselves have a lot of things to do other than your product as well. So you would really need to focus and invest in those areas which can be done by the limited resources. From the end request that are there, we have basically decided to invest in the five features. And the way you arrive at this, first you go to your development team, understand the effort involved in implementing all of the features that allows you to know how big or complex the feature is. You would also get to know the return of investment for each of this request. Then you would also dig and find the dependencies. You would go to these dependency dependent teams and ask them on when they can support you. Based on their commitment and your development teams commitment, you would come back with a prioritized roadmap based on what is visible and what is not visible within the given resources. In our case, we decided to go with deployment improvements first, although it was stacked ranked lower because this is like a foundational item. You would need to improve on coding, testing, building and deployments even before you build new features because if you don't improve on them, you are always hindered in the long run. So it's okay if an item which was stacked ranked lower is prioritized considering other factors. Then you would prioritize things based on dependencies, feasibilities and complexities. What I'm trying to say is it's not necessary that what was stacked ranked from rank one to five are the items which are prioritized when you finally come up with a prioritized roadmap. Once you have a prioritized roadmap, the next step would be to review this roadmap with multiple stakeholders. You would review this roadmap with your internal teams such as marketing, sales and operations. This will allow you to uncover any gaps in the plan, take feedback and take corrective actions. Then you would review the roadmap with customers with NDAs or non-disclosure agreements. This is the second step you're taking to make sure you're heading in the right direction and you're not missing anything that is important. Once you're aligned with your internal stakeholders and customers, you go and present your plans to your senior leadership who are investing in your product. Senior leadership basically validates your roadmap and it aligns with what they want to do. And if they see any gaps, they will either ask you to take corrective actions, make trade-offs or they might give more investments to you if they see that something which is important is missing. Once you review with all the stakeholders and update your roadmap, you're like in a place where you can start execution. I would recommend having a regular review cadence for your roadmap at least once a month or in a quarter to make sure you often check with several teams and stakeholders and customers that you're heading in the right direction and you're not making investments which will be unproductive. Now that we have built the roadmap, let's see how to execute one. I see execution of a roadmap as a three-step process. The first step is to begin or start the execution. Second step would be to review the progress on an ongoing basis. Last but not the least, you would launch the product of the features and celebrate success. Let's go into the details of each step. As the slide says, the very important step for any roadmap execution is to just start. It's not uncommon to see many teams which are mostly analyzing, discussing, debating and doing a theoretical exercise. It's good to debate and discuss, but if you're spending a lot of time on analyzing, then you also need to know that you're missing opportunity to launch and solve customer problems. Customers are waiting on several things. They would wait for some time, but then if they lose their patience, they are going to switch from your product to something else. It will be very hard to gain them back if you lose. Hence, it's important that you start on execution with the clarity you have. It's perfectly fine if some of the items are not very clear to begin with, but you will get to know more on each of those items as you start execution. I would recommend starting with the items which are most impactful and more critical. Within this item, starting with the items that have more clarity and within the items that have more clarity, starting with items that have less dependencies. By doing so, you can be on your own and start rolling out value adds to your customer at the earliest. I would also recommend launching incrementally, launching with the minimum lovable or viable product, and then adding features along the way rather than making a one monolithic big launch. Last but not the least, when you begin execution, I would also recommend investing in foundational items first rather than investing in items which are non foundational. For example, if you know that there are issues in the way you develop your software, if it is suboptimal, if it takes long time to develop a feature, you would need to invest to unblock those inefficiencies and make it more efficient so that you can launch more features faster. It seems that it might not value at your customer directly, but it's pretty important that you make improvements in such things before you launch more and more features. Once you begin your execution of your roadmap, the most second important step to do is to review on the execution on an ongoing basis. You would review the progress of software being developed, you would attend sprint demos, or you can get access to the product itself and play around, or you can actually take the product and present it to your stakeholders. All these are the mechanisms through which you are reviewing the progress of the application or the software that is being developed. You give inputs to the team based on what you see so that the team can take corrective actions earlier. You would also review the preparedness of your internal stakeholder teams such as marketing, sales and support to support and to be prepared for your launch. In case any customer is waiting on your product or features, you would also review with your customers on their readiness to consume what you're launching and be ready to adopt your product. You would also review your progress with your senior leadership to make sure they are aware of where you are and you can ask them for help in case you're blocked on anything. There is no hard and fast rule on how frequently you should review but I would say a review of once in two weeks with your software development team and an ongoing review with all of the cross-functional team will be helpful. Along the way, as you're reviewing, you will get to know when the product is ready for the launch. With that, we go to the next step of launching the product. When you know that you are ready for the launch, go ahead and launch your feature or the product. Make the necessary announcements. Inform your customers. Inform your business stakeholders. Keep a tab on usage and feedback. And don't forget to celebrate the launch, right? Because it's a lot of hard work. A lot of people would have put a lot of time and efforts on this. So appreciate all the people involved in your launch. Take time off. Celebrate what you did so that you're ready to build more products. Quickly summarizing on what we covered so far. The first step in building and executing Roadmap is to get clarity on the vision and the goal. You should be very clear on what you want to do and what's your main objective when it comes to your product. Then you talk to multiple people, customers, stakeholders, understand what are the gaps, collate all the requests, relatively stack them based on your vision and goal. Based on the resources available, you prepare a plan which clearly clarifies what you want to do and by when. Then you start the execution. You review the progress of the execution on an ongoing basis. You take corrective actions along the way. And when you think that you're ready for launch, you go ahead and launch and celebrate success. That's it for the day. I would like to thank Product School for this opportunity. Unsplash for a few of the images and slide deck for the template and a few of the slides that I used. Thank you all for the patient listening. Feel free to reach out to me via LinkedIn. Have a good day. Bye.