 We're on the skull as a developer Okay, not a few. Okay. So who is a business analyst or a product owner who works in product? Who defines product? Even business maybe who's who's in the business themselves? Okay, not too many or a few that's great man. Who's a tester some testers here as well Okay, who's an architect? Someone like an architect Okay, there's a lot and a lot and a lot of people of different roles, which is fantastic Because it's all those different roles that we will need in order to build our power for roadmaps So in order to get through this session We're going to use an example an exam and we're going to build a roadmap along the way And that example is of a corner store and anyone knows examples of a corner store that you might have a Convenience store we call it oftentimes as well And this is a typical old style a convenience store No online presence none of those things, but you see that the lady who is who's basically owning the store Is is about to retire and her son bill is taking over and bill has fantastic plans He wants to take the store online. He wants to build out a whole Empire of of grocery stores and he wants to make sure that they feel Exactly like the store that he inherited from his from his mom Right, so he's got a lot of plans. He even got a marketing Marketing slogan ready already and that is at your convenience calm, right? That's kind of the website convenient your convenience calm that he's referring to and all of the z-mails are at your convenience So he has a whole bunch of features that he wants to introduce he wants to make sure that the store is accessible not just online through a laptop or computer but also through a mobile phone and And even a tablet he wants to make sure it's very convenient and that people can use it With the payment methods that they're used to with the credit cards or the debit cards that they've been using along the way He wants to make sure it's easy to use That people can very quickly find the products that they need and Order those right that they don't have to go through a very difficult and painful selection or product selection process He wants to make sure it's feature rich that all of the coupons for instance that people have been using in the store that they're used to Which is one of the reasons why they come to the store that all of those coupons are still valid that they can still use the Store in the same way as they did before and of course it needs to be Recognizable it still needs to be his mom's store. That's really really important It needs to feel like a store around the corner Even though it's on the internet and he's got an awful lot more things planned like delivery Like making sure that people are rewarded for Shopping at the same store over and over and over again He's got a whole bunch of things and he goes and talks to his IT team And together they come up with a roadmap. So let's look at that roadmap for a second So they say like the IT team is fairly smart and they say like, okay So bill we we don't want you to need to wait for six months or nine months before you get the first piece of value You want to make sure that we deliver this roadmap to you in an incremental way so that you can Push a certain release out That your customers can start using it that you get some revenue from that already And that you can get feedback that you can use to improve your product. My bill says that's great. Let's see What does that look like? so the first step that they want to Make the first release basically that they want to Introduce is to ensure that they have a product catalog Gotta do this anyways, right? If you provide a store, you need somehow A list of all the products that you're selling. So why not providing that up front? Why not having this as the first release? Enabling your customers to see what you have to offer and at the same time They can take a quick peek at the products before they even come to the store While the online purchasing capability is not implemented yet And of course the next functionality would be that we can online purchase That we don't just see the products But there's also a buy button that we can click and then suddenly and automatically That product appears on our doorstep. It's great. And then we get into the more refined and custom ideas that That bill had in mind So one was personalized offers because now we have the data right as soon as we start Allowing customers to purchase things online Then we start seeing all the data related to those purchases. We can start figuring out. Okay So what do these people like maybe they like pasta and anything related to pasta sauces and those kinds of things And whenever there is a commercial or there's a sale of a pasta sauce or a type of pasta on Maybe we should send it out to those people specifically and it would attract more customers or at least Entice them to to buy more right and then the next one is loyalty. So how can we now Ensure that these customers keep on coming back So who thinks that this is this is a valuable roadmap Who thinks this is a very valuable roadmap and there's well thought out and we can get value along the way Any thumbs up? Okay, there's a few So who thinks this is this is not so valuable a roadmap. There's problems with it Well, there are some people who think there's problems with it It's going to be hard to try to figure out what those problems are that you all see But if you can put those in a discussion, I would really really appreciate that and just to just take a look Just add add them to the discussion. What kind of problems you see with this particular roadmap So in the meantime, I will keep on I will keep on going forward So there are some problems with it because Yeah, there's a timeline missing. There's some some dependencies. There's a no architecture runway in there There's a lot of complexity. That's interesting. Okay, so these are some really good insights Yet the competition is not in there. So that's not Not added either. So there's a couple of really interesting comments that we get there So what happens is Bill says, you know what? I think this looks really really really nice This is a good so people have a gift of foresight as well that the online purchase is going to be a super epic all by themselves Okay, so this is all great. So and these comments are very very meaningful and I encourage you to take a look at them as well And not just me So the the team starts delivering this roadmap, right and they they start building the product catalog And that goes relatively well and everything is kind of on schedule and suddenly bill is capable of putting all those products online And he's very very happy, right? He says like, yeah, great. This looks fantastic. We have our first milestone Let's get to our next milestone right now. Let's continue with this online purchase but they run in a few problems as I think Mayuresh Started to to see himself as well Um, so the problems that they're dealing with is well, they suddenly need to start thinking about they suddenly need to start thinking about um Integrating with an inventory management system Then you start thinking about how do we integrate with a point of sale so we can actually help? People pay right and we can also automatically get that from our get get that included in our accounting And how on earth are we going to deliver frozen foods? There's a lot of people who come and purchase ice cream How on earth are we going to ensure that this ice cream is still ice cream by the time that people receive it Right. So all of that stuff we really need to think about this, right? And what we're getting is while we're addressing all those problems It's not going to be released at the time that we thought it would it will take us an awful lot longer And it will take us an awful lot longer to get to that second point and While we are trying to get to that particular milestone We're of course missing out on a couple of opportunities So one opportunity that we're missing out on is the early feedback. We don't get this I mean if it takes us three four months before we can actually have this online purchase out That's three four months that bill doesn't know anything about His customers about how they feel about the new functionality how they feel about the choices that they have made There's also late return on investment all of this time bill has been being his delivery team to ensure that they're working on On the implementation of this roadmap to ensure that they're working on his online store And he's not making any money yet because the first coin the first dollar that he will make Will be when the first product is sold through Through the online store and we far from that right especially and Not until we have this online purchase and honestly We don't know how long that will take and there's also little flexibility and somebody was Was referring to this in the comments as well There these features are sequentially and there's really no way To go anywhere and if you go back If you go back to the roadmap that we showed in the beginning a map between multiple cities With different options to get from one city to another depending on traffic depending on where your mind is at depending on whether you want to use highways or more like Backroads where the scenery is more beautiful each and every one of those things will inform you Which roads to take and there's multiple options that you have So really is this really a roadmap that we get? um Anyways, the reason why this is the reason why we have a roadmap like this is because oftentimes they are built by it They're built by it not necessarily with the business in mind And what we're doing is we're kind of creating a solution And we're building the different components of that solution And when you look at the functionality, there is um a clear link with The content management system that provides the product catalog the e-commerce system that provides all of the shopping experience the the building your cart the uh The building the customer the the following through on the process the order management itself and so forth And all the rest is custom development personalized offers and loyalty And maybe there are some libraries that you can use to help with that But it's mostly custom definitely needs a lot lot more configuration So what we're actually having is Instead of a roadmap that allows us to get feedback really early that allows us to get return on investment that That gives us flexibility on which roads to choose to get to a certain point We're really getting something that more looks like this Which is a road and on that road there's multiple stages and you really can't get to Point five until we hit point one two three and four And what we're really doing is we're building in dependencies In our roadmap those dependencies are actually driving the schedule and that's kind of our problem So we have an alternative but let's first uh Summarize again what the problems are So what we really have instead of the logical building blocks that made up our roadmap We have technological building blocks and those drive the the schedule those dependencies drive the schedule It's no longer priorities. It's no longer the business value that they all deliver It's really the dependencies between the individual pieces And that actually leads to infrequent incremental value delivery And as a result very little opportunity for feedback And why would we need to get feedback anyways because we have no flexibility in changing another route depending on that feedback so we're not really enticing our Our developers to take that feedback into account because we really don't have an option After stage two there's stage three. There's stage four. There's stage five. There's no alternative to two three and four and five Right, so that's always the challenge that we're dealing with So the alternative approach is based on something That I started introducing quite a while ago. This is a picture of I think it's about eight years ago when I first Started using this approach. So the project was for It was a fairly complex project. It was all engineering and This was a customer who was making Landing gear for airlines for for Boeing and an Airbus and so forth And so what they had was they had a whole army of engineers Who needed to calculate the strength of individual pieces like an individual bolt or a piece of metal or shank or any of those things And they they had a piece of software Actually, I didn't have software and I had a an excel sheet where they used that they used to track all the Calculations and they needed to model the impact of force and all those things on it. So they asked us To build a piece of software that would allow them to work together With all of their engineers around the world So our team of business analysts took their 100 page requirements document and Try to split this up into smaller pieces And we just been introduced to the the company had just been introduced to user stories and agile methods So we came up with about a whole bunch of user stories like Like a hundred two hundred. I don't know anymore how many And then they asked me So how can we deliver this incrementally and I looked at this All of these user stories, they were all in JIRA I would look at all these user stories and I said, oh, I don't even know where it starts Right like to 200 maybe more user stories All of those things really don't make an awful lot of sense. They're very dependent. They're not real user stories Yes, they used a user story template as a I can do something so that I achieve a certain goal, but honestly, they're not really good user stories So the problem that we kind of had was how do we make sense of this mess, right? So then we started thinking well, you know what this is a very risky project for us This is not something that we've done in the past. We haven't built anything for for an engineering team. We're more like Into the customer business to customer and business to business market, but not really into Yeah engineering solutions, if you will So, so let's figure out what all those risks are and let's try to address those in the beginning And when you look at this, I don't know if you see it. I hope you can Yeah, I don't I don't think you see it but when you look at this This image on top the top line trying to use my mouse to to indicate anything You see that there's all the risks that we kind of laid out there on the top And the first milestone was try to figure out how we can build this framework In with as little functionality as possible The second one was how can we add materials because materials were really important Are we going to use this in in? In aluminum is this code to be iron all of those things had a significant impact the third one was We needed to actually integrate a module that already existed Excuse me within within excel And so forth so each and every one of those things would add a tiny bit more functionality and would address a risk Bit by bit and the functionality underneath was Functionality that already was identified by our team of PAs and we just tried to figure out. Okay What of that functionality actually is addressing part of that risk? How can we do the minimum amount of user stories to address that risk and know that we're on the right track in In delivering that business value for our end customer, right? And this is where it all started from so Let me give you a tiny bit of theory to to to show how this actually is solving our problem So this is a slide or at least an image that comes from alistair coburn one of the 17 original signatories of the manifesto and he basically is saying that While we're doing while we're building software, we are making a whole bunch of decisions we're making decisions about which functionality we want in the product and That we believe the customer needs in order to solve their problems which Patterns that we're going to use user experience patterns in order to provide that functionality in the most user friendly way About how we're going to implement all this how we're going to structure the code To deal with the load how we're going to test it to ensure that we have enough confidence So all of those decisions that we make along the way are based on assumptions are based on assumptions of how the customer is Going to use the application are based on assumptions on which devices the user is going to Use the application on are based on assumptions of how Many people are going to access the the platform together, right and that will inform us On how we deal with concurrency and how we deal with the load of the system Um Are based on assumptions of what mistakes the programmers can make where the complexity sits and so forth and so forth and so forth Right, so all those assumptions. However we cannot Be sure That we uh, we made the right assumptions until the very end until we finally give our software to our end users They start using us and they tell us whether or not we are right They tell us just by using the system If suddenly the system falls over because there is a thousand people Concurrently starting to use our services. Well, then clearly we didn't make the right assumption about the load of the system If the features that we spend most time and most money on are never used by our users Well, then clearly we didn't make the right assumptions about what was more important for them and what was not if After two days our service desk is bombarded with with calls about the functionality not working Then clearly we didn't make the right assumptions about which parts of the system Needed extra testing on which part could be left alone, right? So those assumptions we already can we only can validate them at the very end when we give this application to our to our users And what we are trying to do is we're trying to figure out Whether those assumptions are correct early around in the process. So we have more time to resolve them so what is a powerful roadmap a powerful roadmap deals with those assumptions really early on and it um It is built of milestones just like any other roadmap That every single milestone delivers real progress towards their end results and that real progress either comes in the form of value delivery in the form of some piece of value that you you offer or in the form of Addressing a risk or mitigating a risk Right. So the value really is Either we we do something that makes the customer Achieve their goals right like in those case we can sell stuff Or we address the risk we address the risk that the solution that we had in mind is not working So the second thing that is important is every milestone just like you saw in that image of about eight years ago Every milestone gives a very clear description of what the value is that we're bringing in that particular step And also those milestones are really really smart small And the third thing that is really important is that feedback that we get When we achieve such a milestone is going to inform us about what what next step to take right, so Think about it when you go from city a to cdb Maybe there's in the middle. We have Crossroads where we can either take a left or take a right. What's going to What's going to make us choose either way? Maybe it's a traffic. Maybe left is more beautiful I write is more highway all of those different things they will inform us but a powerful roadmap is one that Uses that feedback it uses that feedback to make your your way to success More meaningful and also to try to shorten it. Okay, so what does that look like? Well, there is there is a process for it That process is is relatively simple even though it might look a little bit complex We're going into the details in a bit, but but I'll I'll explain what the process is from a high level right now So the first thing that we need to do is we need to identify really the problem that we're solving And I'm talking about the problem not about the solution Right, we need to separate the problem from the solution. So we know What we need to address Right, there's a whole bunch of things There's a whole bunch of risks that can come with the the solution itself But we want to Ensure that we address at least the risks that are Inherent to the actual problem that we're trying to address The next thing that we do is we we need to kind of know something about the solution Is we're going to build a high level solution architecture, right? A high level architecture that gives us an idea of Of what the different elements and the different components are in the system We'll see an example of that as well Then we're going to list the risks those risks need to be both business risks and technology and technical risks So the business risks really being associated with the problem the technology risks really being associated With the solution and oftentimes those technology risks the choices that we're making might introduce might introduce new New risks as well might introduce new business risks, right? So if we indeed are going to implement this application in a certain way it might throw Throw another risk in the mix So once we have that then we're going to calculate something we call risk exposure And we're going to sort our risks according to how much impact they have on our success That's ultimately what it boils down to and then we're going to mitigate those risks So the ones that are have the most impact we're going to mitigate them first We're not just going to mitigate them by saying Okay, well if if a risk that That our our team members are taking off the project that is a risk and we won't be able to deliver on time Well, how do we mitigate this? Well, we mitigate this by by ensuring That we're very clear on the value that this project brings and by keeping Good relationships with people who might steal our our developers away Yeah, that's not really addressing a risk is it right? So what we're going to do is we're going to use the functionality That we already wanted in the project in the first place that we already wanted to be part of the application We're going to look at that functionality and see Which one of those are actually mitigating those risks and that will ultimately inform us About about our timeline and about how we want to deliver this how we want to incrementally Deliver this piece of functionality So we're going to assess how much of that risk that functionality addresses And and then use that to prioritize the functionality and basically the roadmap rolls out of it pretty much automatically So let's go a little bit deeper into what those pieces are and you see on the right hand side top right You see where we are in that process when we are talking about those issues So identifying the problem. So why is this important? It's really important as I said to separate the problem from the solution Right, we want to make sure that we address the problem and not necessarily The solution that that the customer or even us as a delivery team came up with And the easiest way that I find to The easiest way that actually helps us to to get to such a Such a real problem description is to try to write it down in an elevator pitch So when we're thinking about for instance builds grocery store Then this elevator pitch could be something like we want to build a website that allows A customer experience for online shopping similar to our corner store Well, okay. First of all, this is a mouthful. There's an awful lot to say about that So, um, we get the point, right? I mean the bill is Bill is pretty clear. We know what we want. He wants a website and so forth But suddenly we are seeing that that website is that necessary Is that part of the problem or is that part of the solution? It looks like a website is more related to the solution So we kind of want to strip that context from the problem description So we don't want them to describe that it's a website. We want it to be An online shopping experience so So we get to something like this providing an online yet personal corner store experience Nobody says it's a website if we can deliver this in a different way if we can for instance use A marketplace that is already available. Why not, right? Just this might be something this might be all we need This might be all that bill needs. So it's really important to strip the problem down to its core Next thing that we do we build a high-level Architecture a high-level solution and I'm really talking about high level We really want to look at the different components the responsibility they have The main responsibility and how they somewhat interact And we see that the user is going to need something like a catalog because they need to Be able to see what the problems are or what the the products are They need something like a shopping cart or anything that allows them to shop around And collect items that they will later check out On the administrator side, we need some accounting of course because When the the store is going to attract a whole bunch of customers We don't want to do this all by ourselves and manually And we need a way to see the orders that the customers are making So we can fulfill them and ensure that they get delivered and those components on the bottom those great components Those can be Technical components like content management system that that facilitates the building of a catalog or a payment engine and so forth You get the point and honestly This is the depth that we need at this point for this particular solution for a solution that is a bit more complex You might see some more Ellipses and some more boxes, but that's only normal But for this solution that that pretty much satisfies our need. That's all we really need So let's get to the next point which is listing the risks And here I want to I want to stop for a second because this is really where the fun starts, right? So those risks One of the things that we got to do in any project is doing risks management And this is this is really really important, right? But oftentimes we don't do it really well We don't spend the necessary time and we do it only because there is somebody who watches over the entire process to Because there is somebody who ensures that that's risk this risk identification happens and that we can mitigate But no, what we want to do is we want to use that risk management process To drive our roadmap so we can get real value from it and we can address the real risk Not the risks like yeah, what if the budget tries to pull? What if it takes longer than we thought it would? Oh, what if somebody pulls a person away from our team? No, no, we want to talk about the real business risks So we identified a few And there's obviously an awful lot more but just just for For the purpose of this exercise We we looked at a couple of things Like what if we cannot guarantee that the ice cream will make it on time to the customer? What if someone and and I like to as you see as well, I like to Create what if questions to Communicate those risks. So what if something like this happens? What if something like this happens and if we use what if questions then it's a lot easier for the business Not technological people but for the business to participate in that brainstorming as well So what if somebody from the other side of the country tries to buy this stuff bill is not ready for that Right, what if you're out of the product that people want? What if the customers are not interested in the service and so forth? So there's a whole bunch of a whole bunch of risks and you see that this list contains both Technological risks, but also business risks. So the technological risks are more like, oh, what if you're out of the product that people want? That is something that we should be able to to get through our inventory management system, right and So if we can integrate with that that we have this information So that's more like a technological risk or point of sale system the fact that we can integrate with that That's also more like a technological risk But the fact that all of these things are listed in the same In the same section may enables the business now to participate in this conversation as well So next thing that we want to do is we want to Calculate the risk exposure and what is risk exposure? It's the opportunity cost times the probability Opportunity cost is the money that you're losing and preferably this is addressed as money indeed Is the money that you're losing when this risk occurs? For instance the risk of Customers are not really interested in this service. Well, the the money that we're losing is all of our investment Plus we're not making any sales Compared to a successful product. We're making a million dollars of sales every year That's a million dollars right there. What is the probability? Well, the probability is really high Well, would they shop with us instead of with an amazon or or or a wal-mart or something else, right? So that's a probability cost the opportunity cost times the probability is the risk exposure And when we start assessing this and I didn't assess it in terms of money You can do it in terms of your business case You can do it in terms of a percentage of revenue Or you can even say it costs our team three weeks to deal with that particular risk Any one of those things work as long as it's something that the business understands And as long as it's something that the business can calculate with So we're just assessing it very lightly on a on a four On a scale with four ratings plus plus plus minus and minus minus and we're seeing that In this assessment, for instance, what if we're out of the product that that people want? Okay. Well The cost is really high because that means that we're not selling anything the probability of it Yeah, okay Maybe it is it is high, but it's not as high as the next one What if customers are not interested in the service probability is really high and the cost is really high as well So probably this is the highest risk exposure So now we start using that to work on the risks that have most impact on our final solution and the success of our product and So we need to start doing that and we need to start mitigating those risks And how do we mitigate risks because risk exposure is a combination of The opportunity cost and the probability we either reduce The the probability of the risk occurring or we reduce the cost that is associated by Or with that risk once it occurs. That's Medication of the risk ultimately. So if we work on either one of those two, we're good, right? So we want to use planned functionality to do the risk medication functionality that was already on the list already in our backlog And there is a couple of additional strategies that we can use to Ensure that we address that risk and I I have four that I kind of wanted to call out because there are somewhat special and I call them lisa So the first one is lure we add a piece of functionality That forces us to deal with the risk. Let's say for instance, our problem is an inventory management system You know what the next piece of functionality that we plan needs the inventory management system So whatever step we take we have to deal with this our risk disappears It disappears solely because we can implement that particular piece The second one is in form and that is you know what we don't have too much information yet about Let's say our customers interested in our service at all How can we get more information? Well, maybe we just need to build a website And maybe we need to put a button on there and that button will Allow customers to say whether they're interested or not and and we will If we if we get an awful lot of messages from Customers who are interested in the service. Well, then we have more information about the risk or released about the probability of it occurring spy It's not something that reduces the upper the risk or the probability of the risk occurring But reduces the cost when it occurs. So a great example there might be Let's say that if something goes wrong We need to sift through all the logs to try to figure out how to deal with that problem Revert something in the database and so forth. Well, if we know that if if that is a risk Why don't we have a separate log file with specific information? Related to that particular risk that might occur when it does occur Do we know exactly which file we need to look into? We have a stripped down information. We don't need to spend the time to To sift through all of those log files that would be a spy And then we have an avoid and avoid basically means we avoid the risk altogether and we'll see some examples of that as well So there is an algorithm there as well and I I need to keep my time in mind There's an algorithm there as well to use this so that that you can use so we want to mitigate a risk So let's just look whether or not there is planned functionality Functionality in our backlog that already would mitigate this risk If that's not the case then we just implement new functionality at mitigating functionality We add something different to the list and of course that new functionality might Lead to new risks. So we have to follow the process all over again Now if we do have functionality that already addresses that risk Then the next thing that we need to do is do we need it all? Do we need the entire piece of functionality? Or can we just take a small piece out to increase the frequency of our feedback Or to reduce the investment that we need to make before we know something more about that risk If we can do that then we extract the mitigating functionality We put the rest back on the backlog if we can do that we implement the whole thing And then we just go to the next step which is assessing risk reduction So that next our mitigating functionality for the application here is Build a product catalog and so Do you know you have biominers? Yes. Yes, I know I've been keeping an eye on my watch as well. Thank you So building a product catalog And a little bit more so so that would definitely Help with mitigating some of those risks providing a shopping list, right? It would actually inform us whether or not people are interested if they use this functionality Offer a virtual wallet as a payment that would help us reduce the costs that we have Associated with credit card small credit card purchases and so forth offer pay at delivery You get the point there is a whole bunch of mitigating functionality that Addresses a certain risk and if we if we look at the risks that they the address we can look at Build product catalog. It's really helping us to To to understand whether or not our customers are interested in our service in the first place But there's other things that have an impact on that risk as well like provide a shopping list We'll tell us whether or not our customers want this service Which was the most important risk that we wanted to address The second most important risk was that credit card transactions are too expensive for small purchases like an apple so Basically offer pay at delivery would help with that offer virtual water as a payment would help with that So this functionality is actually addressing that risk to a certain degree and some of those Pieces of functionality address multiple risks Some of them address the entire risk or basically reduce the the probability By a tiny bit or gives us some more information About the risk a tiny bit more information and based on that risk reduction based on how much of the risk It actually gets rid of we we can prioritize our functionality And when we're doing this we kind of end up with something like this and this is not prioritized this list of features We're building a product catalog then we're providing a shopping list and so forth But you see on the right hand side that we can actually branch off and if we While building a product catalog We already know that we have a thousand people who immediately responded to our request and they said Yes, we're interested. Please sign us up. Let us know when this Purchasing functionality is available. Okay, great. If that is the case We can skip the shopping list and we can go straight to Showing product availability in the product catalog, which is basically addressing our integration with our inventory management system And then based on the feedback or the challenges that we have related to this We might say, you know what let's do a range pickup in the store And this is kind of a business decision at that point We do a range pickup in the store or we organize delivery. So you kind of get the point We have instead of just with single line a single road through multiple milestones. We actually can branch off So this is again the process. I talked about it at length before and you'll be able to download the slides as well So you can look more Into into the details. So I just want to reiterate that in a powerful roadmap Every single milestone We deliver on an objective instead of just adding new features out there instead of just providing new Yeah new scope, right? So we're actually delivering on a certain milestone and What really are the benefits of such a powerful roadmap? And it is that it allows for prioritized prioritization Instead of for scheduling we can focus on the things that are really important the things that are addressing our risks the things that are Capable of preventing us to be successful in our project Because of those powerful roadmaps our customer can help with the prioritization because they might not understand the dependencies between technical components But they definitely do understand how risks impact their potential success Delivery remains flexible because we can use the feedback from those deliver from those milestones and we get real value at them The biggest risks are addressed really early in the project So later in the project most of our risk is already taken care of and there is um, and we've we've addressed the biggest issues It's not like in a marshmallow challenge where we put the marshmallow on top at the very end of the game And we get additional value from risk management processes that we need to do anyways in order to be compliant with the project management practices So the things that I want you to remember is that a roadmap is not a schedule That a roadmap is really something that allows you to prioritize the functionality and deliver Something in an incremental way and that those increments will deliver value along the way every step of the way I Want you to focus on the fact that business risks are really important and that we shouldn't only look at technological risks And and I hope that you saw a way to do this um I want you to think about risk mitigation and and that risk mitigation that will actually generate your roadmap and give your um And give you your information on what to do next And I want you to seek fast feedback because that's really what makes your prop products an awful lot stronger and more meaningful Um, I have nothing more Thanks for the session. Gino. That was awesome. Um, and thanks for everybody participating here