 Hi, everyone. This is Strategic and Tactical Roadmaps for Product School, and I'm your host today. My name is Alexandra Milton. I've been working as a product manager for six years, and I came to product management for marketing and telecom tech. My experience in product spans from aspiring startups like AdSperd to well-established big tech companies like Yelp, where I work right now. I've been lucky to learn product processes from industry leaders, as well as to form them myself. My passion is to build new products from scratch, especially when it comes to creating value and solving real-life problems with machine learning and artificial intelligence. Today we will talk about product roadmaps. I will start by sharing why I think you should consider listening to this webinar before or even instead of looking for product roadmaps templates online. Then we will put on our product manager heads and look at roadmaps as if they were our products. We will discuss who needs product roadmaps, what they need from them, and why I think you might need more than one roadmap to be successful. I'll try to make this part practically useful by showing you some examples. Now let's dive in. First of all, why do I want to talk about roadmaps and why should you listen? If you've been in product for a while, you probably feel that you know all about roadmaps and also have a strong opinion on the matter. If you're new to product, you'll catch up quickly with all the information available online. And yet, one day, a colleague recommends you a new, fancy roadmap template. And do you think, wait, is this what a roadmap looks like? Was I doing it wrong all the way? I don't know about you, but I'm no stranger to impose the syndrome. And it's no surprise that happens because this is a roadmap by InVision. And this is also a roadmap by AHA. They're quite different, aren't they? And not only in fonts and colors. Doesn't mean that one of them solves the problem better than the other, or do they perhaps solve two different problems? Well, here is the roadmap definition by product plan. A roadmap is a strategic plan that defines a goal or desired outcome and includes the major steps or milestones needed to reach it. It also serves as a communication tool, a high-level document that helps articulate strategic thinking, the why, behind both the goal and the plan for getting there. The definition highlights two distinctly different goals on degree, reaching the outcome and communication. We can also say that it targets different audience, the teams implementing the plan, including you, the product manager, and your stakeholders. This reflects the dual nature of the product manager's job, strategic planning and stakeholder management and communications on one side, execution and delivery on the other. This is how I came to believe that when it comes to roadmaps, one size simply doesn't fit all audiences and purposes. Since then, I was created two different roadmaps, one strategic, one tactical, or to put it otherwise one external and one internal. We start from high-level strategic roadmap that expresses your product vision and helps you sell it. This is an external roadmap. You can show it to anyone and everyone within your non-disclosure agreement. Don't forget to present it to your team. Everyone likes to work towards a big and shiny goal. However, you're not building it for everyone. You're serving the pains and interests of very specific groups of people. Let's list them and the questions they might have for you. Let's start from executive management that probably wonders, what is that you're building? Do you have a plan? Are things under control? Do you know how to monetize it? Does it make sense? Is it realistic? And is it aligned with the company's mission and overall strategy? Then come key customers and partners that want to know, what am I going to get from my money now and in the future? How do you compare it to competition? When can I expect the capability I need? How should I adjust my own strategy if I use your tool? Marketing, your friend and support probably wants to know, what are the milestones and key messages for my marketing and communication strategy? Do I have any valuable knowledge that will help to validate and polish the product strategy? Finally, there are investors. Here is, am I getting returns from my investments? One approximately, does it look profitable in the long term? Now these pain points help us flesh out the principles of strategic road mapping. Your stakeholders tend to and definitely should see the features from the perspective of customer value. In the strategic road map, make sure to emphasize the value over the functionality that enables it. The purpose of this document is to obtain approval for the outcome of the product strategy. It is important to convince the stakeholders that you're building a good product and identify any misalignments and misunderstandings. That's why it's vital to guide the stakeholders through the thinking process and show them why this product idea is so brilliant. Remember that every milestone that appears on the external road map turns into a commitment, so be defensive and generous in your estimations or consider dropping the timeline altogether. Once the direction is set, getting from point A to point B is a tactical plan and largely a responsibility of the product team. In most of the companies, there is no need to concern your stakeholders with complex technical implementation details. Instead, use major milestones to reassure your audience that they won't be kept in the dark and you will provide them with regular clear and consistent progress updates. Our goal here is to gain the trust of the stakeholders so that they collaborate with you on the vision and judge your success by results. Everything that happens in between is your personal magic. Working on strategic road map is also a great opportunity to shape and polish your actual product strategy. This is not the topic of today's webinar, but here's a quick overview of principles that help me frame my product strategy. First of all, strategy before tactics. Figure out your strategy before planning your tactics and tools. Strategy is a high-level plan for how you will achieve your objectives which requires knowing your audience and the value you want to offer them. Think of a strategy as the big picture of what you want to accomplish. Then we don't deliver value once, we deliver value incrementally. Each element of the strategic road map should express what value is being added to the product. Finally, the elements should be prioritized according to the value and the effort required to develop them. Now that we know what we want to achieve, it will be easy to choose the right format. We are looking for a way to emphasize the value and resist the temptation to go into details of the execution master plan. Also, visual aesthetics goes a long way towards making a good impression. So here we go. Make your road map look sleek and beautiful. Pay attention to the phones, colors, and consistent styling. Gladly, there is an abundance of tools that can solve this for you unless you want to flex your design muscles. Choose free design tools, over rigid templates, content the skin here, and it's unique to your product. Don't fall into the trap of tailoring your road map to a template. Finally, tell the story. Draw a big picture, not a schedule. Consider replacing the actual timeline with fuzzy terms like current, near term, and future, or use large time intervals like quarters. But here's an example of such a strategic road map built using Miro. You can see quarters and columns and the value delivered by different teams. Alternatively, you can drop the timeline altogether and use horizontal axis to display an ordered list of large customer value slices like this. This is a theme-based road map. Okay, this is delivery time. We go on stage our main implementation facilitator, the tactical or internal road map. Let's repeat our problem-defining exercise and outline the audiences and their key questions that can be answered with this tool. And let's start with our key customer, you. That's right. The main stakeholder for the tactical road map, just as for the delivery in general, is a product manager. The teams execute on the PM's tasks and submit them for your review and approval. This doesn't mean that for the delivery time, you can kick back and open a beer. As product managers, we prepare user stories, acceptance criteria, spring goals, epics, and anything else that helps the teams deliver value. We also track and coordinate the progress towards the milestones. And the tactical road map is a tool for that. It's just as instrumental to the overall success as the strategic one, because product managers are ultimately responsible for the product results. Now, the tactical road map is for you and you decide what it looks like. Okay, it's not only for you. Depending on how product management and technology departments are structuring your company, the tactical road map can have other stakeholders. All of them would be directly involved in managing product delivery. Let's make a list of audiences and questions. First comes your engineering partner, your engineering manager, the manager of the product team. The questions would be, do we have the right qualification for those tasks? Should we hire more people or help some team members develop necessary expertise? How to make sure that the work is distributed fairly in the team? How to plan for absences? How can the new direct management in product and technology probably wonders? How can I track progress? When is my help and feedback needed and how to make sure that the different teams are aligned? Then of course you care about PMs and EMs of other teams. How do we align the team's efforts and benefit from each other's progress? How do we surface dependencies and avoid blocks and bottlenecks? Finally, how do we avoid work duplication? Then of course come the wrong questions. And that's not an exhaustive list, that might be a long one. Of course you will ask something like, is my team on track? What are the risks? What is likely to cause delays? How can I plan for an electronic route? Where are my tickets needed now and where later? How the expertise of the team and availability of the team will affect my timeline? What can I do about it, if anything? How do I integrate efforts, estimations and uncertainties into my prioritization? How do I align with other teams? Take advantage of their work and avoid the work duplication? How do I surface dependencies? How and when should I adjust my communications and manage stakeholder expectations? And when's the right time to validate the MVPs, collect feedback, analyze data and adjust all through our maps, including the strategic map. Now that the list of the audiences and the panes, let's summarize what the tactical road map should be. In value versus functionality, we need both. I usually use value increments to group the features. They are the milestones and they serve to align strategic and tactical road maps. However, it's the functionality that you need to release for the milestones. The tactical road map is the visual actionable plan of the how, he features and implementation steps. Naturally, tactical road map units are much more granular than those of the strategic road map. The why, as interesting as it is, simply won't fit the scale and should be communicated by other documents. Now time estimates. Take your average team velocity, a calendar with public holidays and paid vacations and a deck of tarot cards. And produce your very best and most honest time estimate. You need to be realistic in order to identify dependencies and overlaps between the teams. Eliminate bottlenecks, avoid jamming and manage stakeholders' expectations in a timely manner. As said before, the tactical road map is your tool and you perhaps with your engineer manager, decide what format you take. I'll just share what works for me and what key features I find beneficial. For the strategic road map, we talked about using horizontal blocks for themes and cells for actual road map units, for value increments. You can use a similar approach for the tactical road map and use cells for features. However, I prefer to swap the rows and the cells. In this example, the features are grouped by value increments and each feature takes a separate row. You can read this road map in different ways. From top to bottom, you see the ordered list of tasks. From left to right, the time and resources needed to deliver them. I also like to group the rows so that you can collapse them and basically zoom out and get a better overview. The tactical road map is like a table of contents for sprints and user stories for months to come. It informs both the content of the tickets and their order, the optimal granularity of the road map units and their mapping to epics and stories can vary from team to team. What's important is that one look at the road map should tell you what the next big thing is. There is an opinion that the time-bound feature plan contradicts the Agile methodology and limits the team's maneuverability because that's not really true. Agile doesn't have anything against planning. However, it does require regular reviews and adjustments of the plan based on the new data. The trick is to be able to change the plan that is already in action without wasting the work already done. This can be achieved by delivering value in small incremental slices. And nothing serves this goal better than the tactical road map. It visualizes the value slices, their building blocks and the resources required. You can easily add, remove, replace or reprioritize the features while keeping the resources constant and simply reallocating them from one task to another. It helps you see what you gain and what you lose in time and resources if you proceed with your changes in full compliance with the job principles. A good tactical road map should surface interdependent blocks of functionality. Ideally, it should help you discover the problem and figure out how to minimize the dependencies together with your team. If it cannot be done, you'll be able to anticipate the bottlenecks and prioritize the tasks in order to avoid them. Cal according of resources is handy when you work with cross-functional teams. And a final note, technical debt exists and it affects the timeline and overall capacity. The tactical road map should surface it. I like to use this opportunity to empower the team and ask them to explain the value of the technical tasks and infrastructure work to me. If I can then include it in the road map in a way that's both correct and easy to understand, the team has done well. Let's summarize what we've discussed today. A road map is just another product you build and it's tailored to the needs of the audiences. One size doesn't fit all here. A road map for your stakeholders communicates your product strategy and gives you a great opportunity to polish all the vice and the ones. A road map for you and your team drives execution and helps you deliver the product on time. That's all I wanted to share today. Thank you for being with me here and happy road mapping.