 Hello, friends. Good morning, afternoon, and evening wherever you are. Welcome to this product school webinar on outcome-oriented roadmaps. I am the Biappal Senior Product Manager at Amazon. A little bit of intro about myself. I have been in product management for almost eight years now. I started my career as a software engineer, then moved into business analysis and accidentally became a product manager. That's probably a story for some other time. Over the years, I have made a lot of mistakes. I've learned a lot from them. I've learned a lot from my peers. I've learned a lot from reading books. Today, I'm going to share some of that knowledge with you. Hopefully, this will help you in your day-to-day life as a product manager. Roadmaps. It's a very interesting topic that comes up almost every day for a product manager. They are very controversial and product managers carry a love-hate relationship with them. That's why I love it. It's pretty much like a ground-up day every year when it comes to building roadmaps, be it quarterly roadmaps or yearly roadmaps. People keep asking, how does your roadmap look like? What tool do you use? Are you doing it in an Excel or PowerPoint or a Kanban board? We keep repeating the same processes and same mistakes again and again and again. Honestly, the challenges that we hear about roadmap is not only the actual content of the roadmap, but how the roadmap is created and then communicated to others. Today, we are going to decouple some of those troubles and talk about outcome-oriented roadmaps. Today, we'll focus on what are the challenges with the current roadmaps? What's the roadmap? Why do we need outcome-oriented roadmaps? What are the inputs required to build a roadmap? The takeaways that I would like you to have is a better understanding of the alignment between product roadmap, product vision, and strategy. Why focus should be on outcomes? Why roadmaps differ based on the audience? How to apply best practices while creating and sharing a roadmap? This is not an exhaustive list, but the major challenges that I have seen so far with roadmaps. If you talk to 10 people within your org and ask them what is their perspective on roadmap, you will mostly get a different answer. They all have a different understanding of roadmaps, which is a problem. Most of the time, product managers complain about what tool they are using or the lack of it. These take their focus away from the outcomes they want to achieve through the roadmap. Then you'll hear about, I have a great idea of a new feature for our product that will drastically increase the adoption. A person, every idea that seems good without validating or even prioritizing them is what we call the shiny objects in general. That's a big problem that we as product managers face when we go to meetings with our stakeholders and execs. Just like the roadmapping tools, product managers also blame the process. Now, when something goes wrong with the roadmap, the response is that we did everything as per the process. But remember, product managers own the process, not the other way around. Now, roadmaps become a very easy way to blame other teams who are not following it. Quite often here, this item on the roadmap is red because there is a dependency with that team and they are not working on it. They have prioritized something else. Finally, data over opinion, that should be the norm. But then you have a leader asking for a feature because he has seen something similar in the competitor's product or somewhere else and that feature makes its way into the roadmap. The best product managers I have seen, they develop their own processes, frameworks and methods. So you don't have to do the same thing as others are doing. Learn from the best approaches and adapt it to your situation and into something that works for you and your team. Now, this is quite a popular, quite a common image that we know of. The build, measure, learn, feedback loop. It's a core component of the lean startup methodology. Now, pretty much all protocols and teams apply this or some version of this in their product development process. Yet, products fail, teams fail to achieve their goals and we do a lot of retrospectives, brainstorming sessions and everything possible under the sun, but nothing comes out of it. So what's happening here? So we actually follow a different process to be honest. We build something, we get feedback from customers or stakeholders, put them in our roadmap without validating them. We start building it again, hoping that this time things will change. Unfortunately, the results are always the same. Product managers might think that they are customer obsessed, but this is a wrong example of that. You need to know when to stop listening to your customers. And this is what Melissa Perry calls as a build trap. We need to get out of it and the bigger problem here is talking in outputs. So outputs of the what, they are the tasks, the to-do lists, the features, stories, launch dates, you name it. On the other hand, outcomes are the problems to be solved, the value created and the why behind it all. Now, the problem is teams often get lost in planning for the what, which is the output, and lose sight of the why, which is the outcome. And features are actually outputs. The goal of any feature you ship to a customer should be to change the customer's behavior in a positive way, in a measurable way. Now, if you ship a feature and it doesn't have the desired outcome, then we would say we haven't done the job right. To shift the perspective, we need to build our roadmaps around problems we are solving, around capabilities we want to unlock, and the user behavior we hope to change. Now, before going into what a roadmap is, let's just reconsider what we discussed. What a roadmap isn't. So it's not a list of to-do features, which are outputs. It's not a list of dates and deadlines. Roadmaps are dynamic in nature. They change over time based on customer feedback and company strategy. And roadmaps aren't released plans, and neither a tool to blame other teams. So remember, there are no perfect roadmaps. Like in search of the perfect roadmap, we lose sight of the big picture. So what is a roadmap? A product roadmap specifically. A product roadmap is just one of the tools that helps a product manager to communicate their intent. So when you combine this with other elements such as the product vision, the product strategy, provides a holistic view or a full picture of how a product team will capture and execute on the market opportunities. Now, it helps drive a shared understanding of the strategic direction for a product. What is the purpose of the product roadmap? Direction, alignment, priority, predictability, and order. So direction, in the absence of a product roadmap, many teams and execs feel lost. So product roadmap provides direction to your team. It tells you why you are on a certain path and also tells you if you are on the right path or not. So it's just like the GPS on your phone. Alignment, a product roadmap is a simple communication tool that helps align all the key stakeholders, creates a cross-cutting, a cross-functional unity and ensure the teams are not fighting among each other. Rather, they're working together effectively towards one single goal, towards one single vision. And roadmaps are all about alignment. Priority, a product roadmap surfaces the priorities a team or business unit will be focusing on in order to achieve their goals or their OKRs. So without roadmaps, we would only have opinions. Predictability, a product roadmap provides predictability to the product development process, which allows teams to allocate resources and then coordinate the product development activities among themselves. Order, now we spoke about direction, we spoke about alignment, but who is going to do the work? So we work with a lot of people. So to get things done, we need some kind of order. Now with order, you are better able to organize the work and ensure that your roadmap is not just something on paper and somebody is actively working on it to create the outcomes that they want to achieve. Now, this is what my first product roadmap looked like. If you ask me today what it was, I can't give a good answer. Like, it was a mix of features, tasks, release dates, quite waterfall-ish in nature. So don't do that. Product roadmap takes many forms in Word, Excel spreadsheet, Kanban board or a slide deck. Now many companies really only have a release plan. Leadership teams like this kind of certainty and control, even though teams rarely deliver on the roadmap as planned and the features delivered rarely have the needed impact of the outcome. Now this list of features and dates gets labeled as a roadmap, but it actually isn't. So we just shift features blindly at some date and hope that they'll have the same impact that we want. So this is an example of another feature-based roadmap. You will see timelines and then just a mention of all the features that the team wants to do. So when we think of building a software product, we don't always know what our customers want and we have no idea what the finished product would look like. So obviously it is impossible to estimate the time and effort it would take to build the product without doing enough discovery, without validating our hypothesis, without understanding the customer pain points and the jobs to be done. But the problem was that in these kind of roadmaps, we never shared the context. Why are we doing certain things? Why not? What value are we looking to deliver and why? What user problems are we trying to solve for whom and why? So that's the question that keeps coming up. The answer to this is outcome-oriented roadmap. So what does the outcome-oriented roadmap look like? What is it? So outcome-oriented roadmaps actually focus on value rather than features or dates. These roadmaps have four important components, vision, product strategy, goals or the OKRs and themes. Now in this roadmap, it's important to ensure that we have a clear lineage and alignment between the vision strategy, OKRs and themes. Now this roadmap focuses on changing the customer's behavior in a more positive way and in a measurable way such that it aligns with vision instead of focusing on tactics. So to start with the vision, start with a simple and compelling product vision. Now it should explain why your product exists. Where do you want to be in the next five years? The vision actually acts like a north star to your product and engineering teams so that you ensure that they are all rowing in the same direction. Now everything in the product roadmap should align back with the product vision. Take an example. Amazon's vision is to be as most customer-centric company where customers can find and discover anything they might want to buy online. See it's timeless and it shows customer focus, customer obsession. Next is the product strategy. Now product strategy is like a plan or a framework created by the company to realize the vision mentioned earlier. So the difference between vision and strategy is that the vision focuses on where you want your product to be where strategy will explain how you will get there. Then comes the most important part, like defining your outcomes through goals and metrics. I believe the best way to do that is through OKRs. That's where you will see mention of OKRs every time in all the slides instead of so replace outcomes with OKRs here. Now objectives in OKRs are like descriptions of what you want to achieve. It should be short and inspirational. Key results will be like the set of metrics that measure your progress towards the objective. Now this is a very collaborative process where leadership teams work with product managers to translate the organizational vision and strategy into the product vision and strategy. And then if you come down, you have the themes and opportunities that would lead to the desired outcomes or help achieve your OKRs. Now themes here are the jobs to be done identified through the discovery process. Each theme is a collection of ideas, hypotheses. These are your hypotheses that will help tackle the customer pain points. Now this is possible only if you have a deep understanding of the customer, the market and existing data in order to create products that are feasible, desirable, viable and usable. Now remember this is again part of the discovery process. I want to emphasize on that point because without doing product discovery, you cannot achieve your outcomes or you cannot build features. Those are aligned with your outcomes, aligned with your strategy and vision. By this time, you would have noticed that we don't have features, stories or solutions in the outcome roadmap. So that would be a release plan. A release plan is like a list of features and needs. A roadmap, on the other hand, as we have discussed earlier, it's a document intended to communicate the strategic direction of the company. So what are our goals, what are our outcomes and how will we be in the market? It's easy to come up with solutions or features, but how do you ensure that it would solve the customer's problem or help you achieve your outcome? Now the cross-functional team's responsibility here is to collaborate and brainstorm ideas as well as validate them during the discovery process. Now the cross-functional team comprises of the product team, the engineering team, the UX design team and maybe the operations team. Now this will remove the silos. This is part of what we call the discovery process in the product development life cycle. Now validate which ideas or hypothesis solves the customer's pain points using data and customer feedback. Now then create features based on validated solutions to customer's problems. The roadmap expectations vary from stakeholder to stakeholder. So using different roadmaps tailored to different audiences matters a lot and I believe it's very practical and important nowadays. For example, a leadership team would be best suited to a roadmap which shows the product goals and plans at a more high level, strategic level, while individual product teams or scrum teams may want to see more granular information such as what features they'll be working on or stories which they'll be working on. Now we are going to talk about portfolio roadmap or sort of like the leadership roadmap that you would show to a leadership team and this is an example and I'll go through it like how it has been built, what are the ideas that go into building this outcome-based roadmap as an example. So first of all, honestly it is difficult to put timeframes on roadmaps but to be pragmatic one needs to provide some guidance to leaders or execs on timelines now giving them a feeling of certainty and predictability. So time horizons in terms of like now, next and later that works really works well. Always list your vision strategy and goals or OKRs on the roadmap to ensure that your outcomes tie back to the strategy and vision. You group your outcomes into themes and then break them down into ideas that make sense and this helps make your strategy more concrete. Now so let's take an example of an e-commerce marketplace. Now their vision is to build a marketplace where people can come to buy and sell anything they want. So they believe that their key strategies are being mobile first, complete self-service and a more personalized experience for the users. This is how they plan to achieve their vision. Now their feedback and past data showed that they are facing challenges with their product adoption, their mobile purchases and many more challenges but they want to focus on the above two outcomes which is how can they improve their adoption to 40% and how can they increase their mobile purchases by 15%. That's the outcome they want to achieve. So now as the team did more discovery and understood the customer pain points and the jobs to be done, they clustered the major pain points or opportunities under these themes. Now in this case the team found that their product needs to be more engaging, needs to improve on ease of use and then needs to improve on the customer support. So now the product team comes up with ideas or hypotheses that needs to be validated. So in the near-term term they decide to experiment on, for example, on the quick view dashboards, on the how-to articles and how they can help resolve issues much faster through issue to getting. And in a later stage they would like to look into like, you know, bagification, gamification to improve engagement or to focus on chat to improve support. Again these are hypotheses that needs to be validated or experimented. Now, when you go to a product team or a scrum team, engineering team and show them the roadmap, so as you go further down the road through the discovery process, you actually share more detailed view with your cross-functional product team. So you are not only talking about the why, how, but also the what. And in my experience this kind of transparency helps, you know, elicit more commitment and ownership from the team. So in a product team roadmap you go deeper into the solution that was defined at the end of the discovery process. Like teams go through the backlog refinement and, you know, do release mapping exercises to create prioritized backlog of features and user stories. Now this gives a sense of certainty to the engineering team. So in this roadmap that you are seeing is not very different from the previous one, but as you can see it's more detailed. It talks in details about the solution in the form of user stories and features. Another great example here you'll see is that of a Netflix roadmap from 2007. And you can see they clearly articulate the vision at the top, the principles that they have, which is basically to delight customers in a merging, enhancing and hard to copy base. That shows what outcomes they want to achieve. They have their key strategies and the tactics, like how they're going to achieve those strategies and then how they're going to measure their outcomes, which is through metrics. So you can see here that there is a clear alignment between their vision, between their strategies, tactics and their metrics and everything is measurable. So basically the point is if you can't measure something, don't build it. Roadmap inputs, I moved to a new house a few months back and we bought a lot of IKEA furniture. And this is one of the desks that I have in the chair and I built it like last month. Now imagine if I didn't have the instruction manual on the right side, which acted like the input for me. So without that input, I wouldn't have achieved outcome, which is building an amazing desk, a chair for myself. So inputs are very important for roadmaps. Now, I know I talked about all the important components of an outcome-oriented roadmap, but the first question that I get when I speak to people is like, so where do I start? You work backwards from the customers, start from the early inputs. By that I mean talking to your customers, doing market research, talking to your stakeholders. And stakeholders could be your sales team, your customer support team, your operations team. It could be other lines of business. Now most of the times they know how the outside world feels about your product and engages with it. Now digging into your product data and analytics also helps, which I believe is like gold nuggets to me. And then you also have your product and engineering teams who have a lot of insights and ideas as they have been on the team. And they can provide a lot of input to your roadmap. Now once you are done with the early inputs, to be honest, by the way, they are never done. It's a process that keeps going on. You try to collect as much information as you can and you keep doing it every day. So collect all this information to have a solid understanding of your customer pain points. Now you can use different tools here, just empathy mapping, et cetera. But as a team and a company, you have to list out the top problems your customers are facing now. Prioritize a list of problems. After this, document the customer's jobs to be done. I'm not going to go into the details of jobs to be done, but that's an important thing. You have to create your prioritize list of jobs to be done that you want to focus on. Now here comes the tricky part, which is aligning your vision, your strategy, your OKRs with the jobs to be done. And when you are done with that, you actually get your themes. So after hypothesis validation, which is part of your themes, which is collection of your ideas and hypothesis, you come up with your epics, your features, or stories. And you can validate them through like A-B testing or prototype testing. And then continue to prioritize day in and day out. I cannot emphasize any more on how important this prioritization is now. There are different ways of being prioritized. You can use Canon model. You can use Rice framework. You can use value versus effort framework or Moscow. There are different ways of doing it. And it depends on you, your team, which method you want to choose, be it qualitative or quantitative. But you have to build a feedback loop here that will continue to enrich your product roadmap. And hence it's not static. You will continuously get inputs that will help you improve your roadmap. And you have to go keep prioritizing it. So be it on a weekly basis or a monthly basis, these are the mechanisms you want to build. Like how often you want to update your roadmap based on the team's needs, the company goals. So the final step here is to rally everyone around the roadmap and empower them to get the information they need. So product roadmaps, to be honest, are brutal. It's not just something you put on paper or on a PPT. It requires a lot of shuttle diplomacy that lead to alignment and consensus. Now a product manager acts as a mediator here between various teams, stakeholders and leaders to get money. So just sit down with each stakeholder one by one and go over your roadmap. Try to understand their concerns and build a trust with them. Now remember trust is a two-way door. So if you want things to get done, sometimes you have to follow your ego. If you do it alone, you might be burning bridges here. So building a roadmap tests all the required skills of a product manager. And most importantly, your communication and listening skills. Yes, you heard it right, your listening skills. So while talking to your cross-functional teams and others, stakeholders, we have to listen more and try to absorb what they're trying to say. Now a couple of concepts that I want to talk about, which I feel are very important while building a roadmap, and this is being used extensively within Amazon and outside Amazon too. And they are customer obsession and mechanisms. Amazon defines customer obsession as a leader's initiative to start with the customer and work backwards in order to earn and keep their trust. Customer obsession starts with understanding the customer's mindset and what do they require from us. Now this in turn helps us understand our own products and helps build a roadmap that doubles down on the customer's pain points, their jobs to be done. Now this makes you think of the value proposition of your product. So a roadmap should come out of your obsession for the customer and their jobs to be done. Mechanisms, a bit different, is a complete process that transforms a set of inputs into a set of desired outputs. Now in building a roadmap, the number and complexity of decisions are a lot. And so are the challenges of communicating and coordinating with other parts of the automation. Now it needs a mechanism, a complete process that improves and reinforces itself over time. Now think what mechanisms you want to build to develop roadmaps that comes out of your obsession for your customers. Few examples are your quarterly planning, your monthly customer feedback review, or your monthly business review meetings. So build a mechanism that will enforce your customer obsession into a repeatable set of outcomes in the form of product roadmap. So before we go away to key takeaways which we have already discussed, focus on outcomes, align your roadmap with the vision for a strategy and your OKRs. Ditch the dates, the timelines, because once you talk about dates, it's a different kind of commitment, you go into a different rabbit hole. And then practice influence without authority. Now influencing without authority involves understanding and empathizing with different kind of people, people in your teams, different kind of stakeholders. And then you build trust with them. So thank you for joining this webinar and hope you enjoyed this webinar and learned something which you can utilize in your day-to-day life as a product manager. If you have any questions, reach out to me through email or LinkedIn and have a great day. Thanks.