 Hi there, I'm Radu. Welcome to my very first webinar about product programs, the do's and the don'ts. Before we get started, I would like to tell you a few words about myself and my past experience so you know who you are listening to. Let me share my screen. I have a pretty presentation here. So I've been in the product game for 10 years. I had the opportunity to create products in domains like oil and gas, automotive, automation and robotics and now advertising. Currently, I work for Skyscanner as a senior product manager for modern advertising. Looking back at my experience, I did some thinking after 10 years, it happens. I was thinking about my products and that sometimes really I wish to go back. Don't get me wrong, I had my first success of products and product management with really good products. However, sometimes I wish I could have done it before. Thinking even more about this, I found that product roadmaps were the most challenging part of product management. And with the imposter syndrome sometimes kicking in, I felt that I'm to blame. I'm not really good at it. However, speaking with other product managers, having a team of product managers, I saw that I'm not the only one. I saw that it's challenging, it's hard. And I went a little bit more, I did a little bit more discovery and research and try to understand why. I have some findings here, unfortunately 25 minutes, 30 minutes, it's not enough. Maybe I'll go even more in detail. However, I feel that I can give you a little or some insights of what I found. Now, the aim of this presentation is to help you recognize patterns or situations that might be miniature roadmaps value. What I will do, I will start to do some assumptions about you and speak a little bit about strategy. Then I want to tell you what's not a roadmap, so we are on the same page here. What is a roadmap and how I see roadmaps and some dos and don'ts. Let's start with assumptions. I believe you're working in a product team or with product teams or you are a product manager. You know the difference between product management and project management. You know terms like stakeholders, users, users versus customers, vision, mission and in general the notions of strategy. So I will not go into too much details about this. However, I want to speak a little bit about strategy because I feel that this is one of the most misunderstood concepts in our domain and it's a foundation of a successful roadmap. A good strategy is a strategy that has a clear diagnostics, a guiding principle and coherent actions. A diagnostics is an educated guess of what's going on in a situation. A diagnostics replaces the overwhelming complexity of a situation with a simple and short story that is understood by everyone. The simplified model gives you the opportunity to make sense of a situation and engage in more problems something. A good diagnostics, it does more than just explain the situation but defines the domain of action. Now when we go in guiding policies, they outline the overall approach for overcoming obstacles that we define in the diagnostics. It's guiding because it channels energy and effort in a single direction without defining exactly how it needs to be done. Good policies are not goals, visions or images of the future. Instead they define a method of grappling with the situation and improving a vast array of possibilities. I've seen the mistake that people stop at guiding policies in general or principles. A good strategy means actions. To close the loop, we need coherent actions. It doesn't need to pinpoint the whole array of actions exactly what we are doing and when we are going. But it's enough to bring the clarity to the concepts we are trying to do. To be powerful, actions must be coordinated and built on top of each other to focus the organizational energy. The reason I'm talking about a good strategy is because a bad strategy will provide a bad outcome regardless of the quality of your roadmap and the quality of you as a product manager. So when we look at a bad strategy, I usually recognize it by looking at some traits like fluff. If anyone played corporate bingo, that's fluff. Usually there are words, sounding words sometimes recognized like Sunday words. And they are masquerading complexity. They are saying they are fancy, they sound complex and mysterious, but actually they're not. Another one is failure to face challenges. If you can't define a challenge, you can't define a strategy. It's simple. And I've seen the mistake of thinking goals are strategy, which are not. Many strategies are just like statements of desire. We want to achieve this extra revenue. That's not a strategy. And of course, it's just there are bad strategic objectives. They fail to address the critical issues or they are impractical. Simple as that. For more on these, I would recommend reading the book, Bad Strategy, Good Strategy by Richard Ramlet. I think I'm saying his name right now. I've read this book in different times in my career, and it helps because you build up the experience and now you can understand the pattern sometimes. I truly recommend that. Okay, right. With all of this in mind, I want to continue with what's not a roadmap. And I think this makes it pretty clear. A product roadmap, it's not a project plan. Okay, I've seen this mistake a lot of times. A project plan doesn't recognize and doesn't focus on delivering value to customers and organizations. Roadmap brings bad value first. Okay. Most of the times projects care about maximizing output, meeting timelines and combining resources in the best way. It's not bad, but it's not a roadmap. We can ship a lot of things, features, etc., but you could see that they don't bring value to your customer. A project plan feels okay for shipping features, shipping deliverables, but your customers don't. Product roadmaps are plans to deliver value. Okay, so what's a product roadmap then? Well, to be honest, you can go with it. Like 1.3 billion results on the search, it's amazing. Almost 1.4 billion actually to be a little bit more precise. But the way I see roadmaps is they're like a breach, a breach between product strategy and product engineering or product development. What product roadmap will produce problems or product with technical depth with the resources, shape, quality, or strategic compromises. Like late to market, not meeting the market's demands, not delivering the expected value to your customers or business. A good roadmap, besides delivering the product and the vision and the strategy put in place, will be able to identify flaws on either side, product strategy or product development. Making more clear, I've done this diagram here. I have a saying like one diagram is 1000 words. The roadmap is the breach and is held by clarity and how accessibility is and how visual it is. In the next part of the chat, we will go into some situations that will try more or less to emphasize those three pillars about clarity, visual and accessibility. Okay, let's continue. The do's and don'ts, the core discussion of the day. I have four situations. For sure there are more. I will not go into them because of time. And yeah, maybe I'll have the chance to do more of do's and don'ts. Now, the first don't is don't assume that one after one meeting, your team as stakeholders understood your roadmap. Of course, this is, this is not something that it's only for road maps, right, in general, for everything we do in product management and beyond. However, road maps have a complexity that needs to be addressed in more detail with different types of stakeholders. I've seen that you we usually have this quarterly road maps reviews or product plannings, whatnot, how they're called the person organization but they're all the same. But after you finish the roadmap after one week, two weeks, three weeks, you hear why are we kind of questions like why are we prioritizing this piece of work? Why is this important? Why are we doing this? Also, you observed that similar problems, but with different names or different definitions, let's say, are solved around the business by other teams. Usually this happens in larger organizations. But the problem, the large problem, the biggest problem is that your main stakeholders are introducing problems or to do's in your roadmap regularly, ignoring the product strategy you have in place. You feel reactive and you feel misunderstood. My suggestion is to take a step backward, again, you'll hear this a lot from me. And do a stakeholder map, understand your stakeholders. Understand their times, objectives and needs and adapt your story to your audience. Your roadmap needs to be reached to all your stakeholders more with a higher frequency than once every three months. Try to understand their objectives and align your roadmap and align your story to their objective so they understand. The next don't is, it's kind of related with what's not a roadmap, don't fall into the output trap, don't transform the roadmap in a project plan. I've seen this happen in companies that have also the hardware mix, a lot of the times, but not only. I've seen it in traditional companies that adapt digitalization or software development while they were conservative and they still have a project mindset. Although you are delivering or each quarter you're achieving those milestones of delivery, your product suffers. Your OKRs are just not achieved. But this cannot be, I mean you are delivering, the features are working that are out there. And what even worse, it's hard for you to represent a medium to long term roadmap. And stakeholders ask you or customers more when than what. Here is where product managers skin and craft coming and this is where it's important to try to be problem oriented, opportunity oriented. Break larger problem is smaller ones. Try not to represent solutions on your roadmap because this is how you create a behavior around your stakeholders. When you create those problems on your roadmap, you will be able to say, I'm not changing the color. I'm making it more visible. OK, you're solving a problem in the end. You're not flushing out features. There is a catch here, although, and this is a weird one. And unfortunately, I do believe that this is another topic. Maybe we need a different webinar or chat about it. It's how your organization is organized in the end. If it's an engineering one that has a lot of hardware problems or hardware challenges, things change and you need to adapt and you need to understand your organization in the end. If you have any problems like this, please contact me. I'm happy to coach or share some wisdom if I have any. But it's a much more complex problem. What I can tell you now, again, break your problems in smaller problems, represent problems on your roadmap. Try to avoid timelines and always talk about value. Don't talk about delivering code. The next don't is about design and I've seen this and I've done this mistake a lot and I've seen it a lot also is that people get bogged down into design. They try to reinvent hot water and they use a lot of fluff on their own maps. When I was doing this a little bit more, especially in the beginning of my career, I was trading the idea of updating road maps, which you shouldn't because it's your main tool. During meetings you explain more what you are showing than your story. You're not talking about your product, you're explaining what it means. And a lot of the times without you there in the room, your team doesn't understand the roadmap, they don't get it. And another symptom here is that each session your product roadmap changes. It looks different. And again, you'll go through the same wheel of what's going on, what does it mean, etc. My suggestion is keep it short and sweet. It's about the story, then the design. I've seen one of the best roadmaps I've seen was a simple Excel. It was great. Everybody knew what's going on and it was so simple, so direct. There are many tools around that can help you, but you need to make sure that the whole organization is aligned in that design in how it looks like and how it feels like. We need to reduce the cognitive load of our stakeholders because we are bombarded with a lot of information. So when you're looking at something needs to be clear, concise, accessible. Cool. And yeah, don't use Fluff. I've explained a little bit in the strategy. We are multinational companies, organizations. I think in my office here we have 18, 19, maybe more, my mistake, nationalities. English is not our first language. We have the tendency, and I've seen the tendency of trying to enrich our language with complex statements, etc. Not being native sometimes we misuse words that are just not suitable for a certain situation. And I'm saying that as a Romanian, there are words that you don't use, although it means what it means, they are theoretically they're correct, but you don't use them in that situation. By doing this, it can be difficult to make your roadmap understandable. So try to keep it simple. And that's it. The last don't on my list today is regarding learning and research. I've seen this happen a lot of the times in different colleagues on different colleagues road maps. And it's a situation where stakeholders seem to be surprised about new things. Road maps tend to be only with the deliverables and discovery is almost nonexistent on your roadmap. Sometimes product teams actually miss their goals, spin by spin or quarter to quarter, because learning and discovery is not represented on your own. We need to recognize that your product gets better only with discovery, either problem discovery or solution discovery. Sometimes, and this is one of the most important learnings you can take from discoveries that the path you're going is not the right path, and you need to show it on your roadmap. You need to learn how to fail fast and fail early, and you can do that only with discovery. If you represent on your roadmap only the partner only the user or customer facing deliverables. It's a piece out to show that your product actually adapts, learns and becomes better each iteration. It's important for you as a product manager to recognize that and create that behavior in your product team. Some extra tips for you when it comes to road maps in general is that you're not alone. Here I need to raise my hand and admit that I have the lone wolf syndrome. A lot of the times I think I can do it better than others. But I've learned that when you get stakeholders involved in a roadmap creation and your strategy creation, you will have a better picture of what you need to do. And a lot of more information created create the second advice would be to create a behavior of continuous discovery on your own. That you're speaking with users that engineers are because you're validating your assumptions. Engineers are involved in the discovery process. Try to represent it on your own. And finally treat your roadmap as a product. It's not done in one day. It needs to be iteratively improved step by step. And don't be afraid to start from zero. This is the mountain analogy where you're on a mountain, you have climbed two thirds of it. You can see the peak over there. But you see that the last third is tedious and dangerous. What do you do? You continue on that path or you go back and look for another one and you waste or lose the two thirds already climbed. Do the same with the roadmaps. I've seen where because feeling that you've put so much effort in a roadmap, you don't want to start from scratch. Sometimes it needs to be done. Pivot and redo your roadmap. That's it for myself for today. I hope it was useful. Please send me your comments, your remarks. I'm, as I said, it's my first webinar. I'm here to learn. You can find my details on England. You can find learning them pretty easily. There are not a lot of positions out there. So that's all. Take care.