 I think we are ready to begin. Excellent. All right. Good morning, good afternoon, good evening, depending on where you are. My name is Carlos Santamaria and welcome to the NoMap to a Defensible Roadmap in one day. Let me share my screen. All right. So the idea for this webinar came from a situation I recently experienced, which was actually a repetition of a situation I have experienced before. But this time I think the process I put together provided great results and I want to share that process with the product management community. Before we begin, a little bit about me. I have been in the field of product management for the last 20 plus years working for companies between 10 employees and 1 million employees and doing product management and innovation for software hardware and firmware products. I am an engineer in electronics and have an MBA in innovation and sustainability. Currently, I am the Vice President of Product Management for Kuba Systems and my LinkedIn is shown on the screen in case somebody wants to connect. On the screen, I have three things, three points I think you can take away from this webinar as follows. The first bullet point is about always starting with the customer, with their problems and their struggles for progress and walking backwards until you arrive to the requirements for engineering. The second bullet point refers to the fact that there are tons of frameworks out there but there is no silver bullet, meaning there is no framework that will work for you in all situations. As a product leader, you need to pick and choose a framework or set of frameworks that will help you achieve your goal. On this presentation, you will be able to see how I mentioned frameworks such as Jotubidon, the KNO model of innovation, the outcome-driven innovation and some others. And last but not least for the third bullet point, you need to be always ready to explain why something is or is not on your roadmap. Even when you are the owner of the product, there will always be people above you in the organization and there will always be customers that demand explanations. If you present your story in a cohesive way that showcases the direction of the company in terms of the roadmap item or items as contributors to that company's desired direction as part of that overall journey, your job of explaining the roadmap will become a lot easier. Now, with the formalities and the outcomes cover, let's get into today's subject. In companies, there are tons of ideas but sometimes not much in terms of a clear and consistent criteria for filtering and organizing those ideas into something that, one, provides an overall understanding of where the company is going towards. Two, transmit confidence that such direction is conducive to success. Third, filters out things or things the company should not spend resources in. And fourth, provides prioritization, meaning the company knows what to do when. So the whole reason for you as a product manager to be in that company is or it should be to provide the leadership that will answer those questions. So the whole company ends up with a clear and justifiable path to the future in a way that generates confidence at all levels in and out of the company. You can follow the process I am going to describe on your own and get by in from the right people in the organization later. In my case, I got the right people together in a room for a face-to-face workshop. And in one day, we did all the work and I got all the buy in, I needed to move from the product's ideas forward. You are the product leader and therefore the ultimate decision maker for the direction the product will follow. But whether you like it or not, if you don't get buy in for your vision inside of the company, if the company is not willing to believe what you want them to believe, your chances of success will be very slim. The process of getting ideas of where products should go has become increasingly more open. Before it was basically the direction decided by the CEO and the senior leadership. Later, companies realized that their chances of success will dramatically increase if they focus on their customers. With that openness to new ideas, companies are now receiving a plethora of requirements that ultimately overwhelm and confuse the direction that should be followed in order to succeed in the marketplace. As an example, the image on the slide shows a partial screenshot in one of the tools we use to collect ideas and feedback for the product. The column on the left contains close to 300 entries. So you can do a proportion and understand how large the whole collection of ideas is. When you see something like this, what do you select? What do you ignore? And from the things you select, when and in what order you implement those ideas and equally important, why? Most companies now understand that the key to success is to satisfy customers' needs. Unfortunately, understanding the needs of the customer by simply asking them, like, what do you want? Is going to land us in the wrong place? As Henry Ford used to say, the real key to sustained success is in realizing and understanding the problem the customer is trying to solve, as family stated by Professor Levitt, there on the right side of the screen. Customers want a home. They don't want a drill bit. There is something I learned throughout the years as product leader. And when I saw it obsessively applied, I definitely saw better results for that company. And that is to start with the customer and walk backwards from there. That is what we did in the workshop I mentioned before. We began by defining what is that we do for the customers. And with that, we started to work backwards until we understood what is that we need to tell developers to do. To go from no map to a justifiable roadmap, we started with the customer and walk backwards. The first step backwards starting from the customer is to figure out what does your product do for customers. There are many ways to find out what is that we do for customers. We use one way to find out and one way or one verification point to ensure we did it right. To find out what is that we do for customers, we focus on the main job to be done. The main reason our customers hire our product in order to deal with a particular struggle on their lives. In our particular case, we have a proprietary camera that is able to see invisible gases in a cloud solution that receives and analyzes and presents that information to customers. One will think that what we do is to sell cameras and access to our cloud in the form of software as a service. However, that is not really what we do for customers. Remember the sentence I showed before from Professor Leavitt, customers don't want a drill bit. They want a hole. Same thing for us. Customers don't want a camera. They want a view, a way to view invisible gases. The camera is just a way. It's just a tool to achieve that. With that mind frame, several ideas were written down on a whiteboard and we settled down for we characterize the invisible as I showed there on the screen. As a validation point or a checkpoint, if you will, we analyzed that sentence in light of our corporate mission and we found a match. So we went ahead with it. This checking with corporate mission is vital as we need to ensure that the product is supporting the corporate mission, the company's mission. Otherwise, we might be taking the company to places where it shouldn't go, like a discount retailer working on a very expensive and exclusive product. The company is going one way, the product is going another way. It doesn't mix very well. The second step on the journey from no map to road map, find the themes. So after defining what is that we do for customers, that is the column most to the left on the slide, we focus our collective effort on breaking down what that overarching task meant. For that, and using verbs as clues, we created what we call themes. Themes are those discrete areas where our actions and solutions will positively help customers in their struggle for progress. One thing I want to highlight here is that I keep on saying that the focus should be on the problem we are solving for customers. And that must be understood as themes being areas of works which are external, like external facing functionality. And that is almost true. As much as we like as product managers to focus on external facing functionalities, or what I call my customer enablers, there are internal activities such as architectural changes which consume resources and therefore compete with your desire to create new functionality. Those internal activities or business enablers need to also be considered for better planning and road mapping. And I show you later how I dealt with those during this experience. For our product, a characterized invisible basically meant six themes shown on the screen. Again, these are actions we want our product to take in favor of our overarching tasks. And that's why we focus on using verbs as the start word for the themes. Third step on the road from no map to road map, language commonality. After defining these themes and as explained on the previous slide, we proceed to define each one of those themes. And literally on an Excel spreadsheet, we wrote a definition for each of the themes, a definition that we could agree on as a company. One of the biggest innovators of our time, Dr. Anthony Orrit says that commonality of language is key to innovation. Otherwise, people will have like a divergent, different understanding which might lead to different product direction. Fourth step, defining ideas. Once we were all on the same page in terms of definitions, we focus in defining ideal outcomes. In other words, we define how idea looks like. Customers are always going to emit judgment as it is mentioned or thought in the outcome driven innovation framework. They are always going to rate your product. Now, what is that criteria that customers are going to use to say your product is or is not good? Now, my question for you as product managers, as product leaders is, if you don't know that criteria, where are you going to be aiming in order to satisfy your customers? Conversely, if you know that criteria, you will know what to develop in order to make customers happy. To express those kind of ideal results or ideal outcomes, we use a technique called IFRs or Ideal Final Results. IFRs are defined as a description of the best possible solution for a problem regardless of resources or constraints. In the fifth step, we moved from idea to achievable. IFRs are broken down into epics, which are large development efforts. This is the same concept of epics that is so commonly used as part of agile practices. From agile, we know that epics are too large to be assigned and tracked. For that reason, we further break down epics into stories on step number six of this process as a way to achieve two things. First, to provide engineers with workable chunks of work. Second, to deliver value in pieces. Rather than telling customers, hey, you have to wait for eight, 10, 12 months before you can see anything new on the product, we can deliver value in pieces. So customers feel that they are getting something out for their money sooner rather than having to wait for a very long period of time. Now remember, we started this discussion with a series of unorganized requirements, which was no more than really a basket where all sorts of ideas were put to rest. This is shown in this slide inside of the blue frame. We then followed the process that we have been building on the previous slides. That process, a screenshot of that is shown inside the purple color frame. When we arrived at the last step in the process, which are the stories, we use the repository of ideas as the starting point for the stories we wanted to work in the product. We track all these in a spreadsheet that look like the one shown on the right side of the slide. Now, not all the stories in the idea repository made sense when look under the light of the process I just described. Why? Because there were ideas that didn't fit the logical conclusions we achieved by thinking about the customer first and then walking backwards, trying to find who is that our product can help with the struggle to make progress. The nice thing about applying this process to the ideas repository is that we ended up with a list of stories or tasks whose rationale was understood by everybody and at the same time, those were stories that our developers were able to work on. Now, after erasing many things in the ideas repository that didn't make sense to keep according to the process, we ended up with a sizable list. He was still a sizable list of things to do. Now, the question is how do we organize all that information? Here is where prioritization comes very handy. There are many ways to do this and what I am going to describe here is just the process I follow, but like everything in product management, there are many ways to do this. A well-known and effective model of innovation is the Kano or Kano model. This model states that customer features can be placed into three buckets. The most halves that are the ones kind of in the lower corner, in the lower quarter of the diagram, the ones also known as a performance functionality that is the line there at 45 degrees and the outsiders, that's the top of the diagram. In our particular case, our product, our solution is still young. It's still early on its product life cycle and because of that, we still have some gaps that we need to fill in order to ensure customer satisfaction. Those gaps fall into the must category of the Kano model and they are there because if we don't have them, then customers will be unhappy. That is the reason a functionality on that kind of must bucket receives high priority in our prioritization exercise. High priority is also shared in our case by quality and infrastructure. Quality is, in my experience, the best value proposition we can try and sell to customers. It might not be what brings the customer the first time they come, but it will keep customers coming back over and over again. Infrastructure is the last high priority component of the three pillars for prioritization and intended to use and it reflects our desire to grow in ways that are sustainable, fast and at the lower cost possible. So when we take that long list of activities we need to work on and filter that list based on the three pillars I just described, the result is the roadmap. Our prioritization table looks something similar to what is shown on the screen. As you can imagine I changed a lot of information in what I am showing here from the real prioritization table we use. However, what I am showing on the screen still shows the point that I want you to think about. The table is just a weighted prioritization table. What is important are the factors, what we are going to consider when doing the prioritization and those are shown in row one. Contribution to any of the themes we discussed before, contribution to foundation, which is quality and infrastructure, also the storage placement in the Kano model and customer satisfaction with the current solution. So using this criteria we evaluated the relative importance of the stories we had in the backlog in the long list. If you check the formula above one thing I'm doing is that I am subtracting the satisfaction of the customer with the current solution. If a story ends up with a total score of zero or even a negative number then there is a story that is not going to help the product succeed in the market and therefore I need to focus on something else. The weight of 90 I use for the weight of the customer satisfaction with the current solution is a semi-arbitrary number I use for this calculation and it is calculated to make the result of the total score equal to zero if all of the factors of the table are set to their maximum possible value. At the end of this exercise the stories with the highest score should gather most of the attention of the product manager and should probably go first on your roadmap. Now with the stories prioritized in a way that makes sense for the roadmap, for the organization we need now to organize things and to present them in the form of a proper roadmap. Now one of the best frameworks I have seen to characterize the roadmap and the stages where features on the roadmap are is shown on the screen. It all begins with the product backlog in the left side of the screen which is again basically a repository of all the ideas we come across then we apply all the filtering that I have been describing on this presentation. Still there will be a bunch of ideas there. Now based on priority, opportunity, market feedback, competitive analysis and some other factors ideas from the roadmap are moved from the backlog into a plan of vision or POV. Ideas in the POV, in the plan of vision, they make sense but they are not yet explored really. We haven't gone deep into it and they are not urged. POV ideas whose priority begin to rise are moved closer in time. There is a timeline there if you see in the middle of the screen and they begin to be explored by engineering. To indicate the new state those ideas are now placed in what I call the POI or the plan of intent state. Now the next step in the roadmap is the POR or the plan of record where we place work that is fully understood by engineering and which is of the highest priority. Now there are no facts in a roadmap as roadmaps are ultimately a depiction of intentionality and not a prediction of the future. However, PORs are as good as it gets in terms of roadmap certainty. There are many ways to present a roadmap. This is just the one I use. It groups the functionality that made it out of the backlog and into the roadmap. The first three groupings of functionality, the picked quarters, as you can see there. The last one, the one on the right side, the picks a semester. This is due to the common uncertainty that tells that the farther the time horizon, the less certainty you have on what is going to happen. Also, you can see that the first grouping of functionality is a POR, meaning that engineering is working as we speak on those things and there is a great level of confidence that we will be able to deliver this functionality. The two blocks in the middle are POI or plan of intent, which means we have architects and program managers analyzing the requirements, ensuring their completeness, breaking them down and doing an initial estimation of effort from them. The last on the right is the POV, which groups things to come, but that we haven't analyzed and in some cases even discuss with engineers. At the bottom and going across time are the foundational efforts of infrastructure and in quality. The roadmap I presented in real life has a bit more information for those two topics, but again, I cannot reveal too much of our secret source. Also important to notice, on the top right corner, there are six color rectangles, one rectangle per theme. As you can see, the color of the font that I use in the roadmap allows the reader to see to which theme is each of the functionalities depicted on the in the roadmap, contributing the most to. A comment I received once when showing this type of roadmap was, is that a waterfall methodology? Well, actually it is not. Each one of those entries in the roadmap is broken down into individual tasks, which are then worked by the developers. We do a release of bug fixes and new functionality every two weeks at the end of each sprint. To finish today's discussion, let's go back to the stated outcomes for this webinar. We discussed a process that showed how to start with the customer and in a sequential and logical way, walk backwards towards the things we need to ask developers to create. Now, as we went through the presentation, several frameworks and tools were used to help us create value at each stage of the discussion. That's the second bullet point there. And last but not least, we ended up with a roadmap where each entry can be traced back to a theme, which can be traced back to our main goal with the, with the, with the product. And that goal with the product is in line with the corporate mission. So this creates a storyline for the roadmap that is coherent and justifiable by the product leader. I think that is the end of the presentation for today. Thank you for taking time away from your valuable schedule. And I hope that this has created some questions and answers for you as product leaders. And I hope to see you next time. Please reach out in case that you have any questions. Thank you.