 Thank you. Thank you everyone for joining this session. We have Penelope with us. A quick introduction of Penelope. Penelope is a globally recognized award-winning innovator, entrepreneur and technologist. She holds around 20 years of experience. Her work has been recognized with innovation and technology awards in six different countries. Penelope has a great fund creating and transforming ideas into great products or businesses and working with teams to help connect people with purpose to find fulfillment every day. So without much delay, I'll hand over it to Penelope. Over to you, Penelope. Lovely. Thank you so much, Kartik. Okay, so today we are going to talk through a couple of different concepts and how I have combined those together to really try to enable more successful processes and products. So today I'm going to talk to you about the concepts of design sprints and also prototyping. So I'm going to, because we're doing this virtually, I'm going to ask if you are comfortable to do so and it'd be great if you could come on video on camera so I can see you nodding and agreeing and using your thumbs and saying yes, I agree or no. I'm also going to ask you to use the chat so we can say, yes, I've heard of this concept or no, I haven't. So I know I can get an understanding of who's in the room and what we want to, where we want to take the discussion. Thank you, Shiv, for putting your camera on. I can now see you. Thank you and a few others. Thank you so much. And then also we may break into some smaller groups as we progress. So as Karthik said, my name is Penelope Barr. So I'm currently in Melbourne. It's a holiday in Melbourne today and it's also my birthday. So I feel privileged to be amongst you today, celebrating two occasions. It's the holiday before the grand final for football. My team isn't in it so I'm very happy to be sharing this day with you. So I don't really have much of an interest in the football today. And I've also spent some nice time with my family this morning and my husband's currently cooking me a roast dinner. So as soon as I get off this, I'll have a beautiful roast dinner to look forward to. So I'm very happy. But one of the things that I'm really interested in is being as effective as possible and as efficient as possible. And as my husband quite often says, there you go offering your unsolicited opinion again because I'm really interested in continuous improvement. And so when I came across the idea of design sprints, I loved design sprints. So first I just wanted to understand how many people are familiar with design sprints, so the Google design sprint. So maybe if you can, if you can note in the chat if you are familiar with design sprints just so I can get an understanding of great. So we've got a couple of people who are familiar, not familiar, familiar. So we've got sort of kind of half and half, a few people haven't responded yet. So I'm going to know, okay, great. So I'm going to then take kind of a beginner's level of Google design sprint, if that's okay. What about pretotyping? Has anyone heard of or used pretotyping, not prototyping, but pretotyping? So where are we on pretotyping? No, no, no, no, no, no, not heard of it. Okay, brilliant. Well, great. So we have got some great learning to do together this afternoon. So I hadn't heard of pretotyping really until last year. And I love, I'm a lifelong learner, so I was very excited to learn of pretotyping. But as soon as I heard of it, I thought, great, now that I know a lot about design sprints, and I can see a real use for it. So today, I'm going to start sharing, I'm going to work through some slides, because some of these concepts are a bit of shared online, but we're also going to do some discussion. Now, Karthik, I'm just going to ask you, are people able to come off and share or not in this discussion? Or do they have to just use chat? No, they can talk if they want. Okay, beautiful. So please feel free as we go along, because this is a workshop. Please feel free as we progress to come off mute and discuss or add anything as we go along, because how we all learn is by sharing. So you'll have experiences to share that the rest of the groups can learn from and that I also would love to hear about as well. So please feel free to do that. Beautiful. So I'm just going to share my screen. Here we go. And just pop it into present mode. Great. Okay. So, yeah, so the title for me is if you buy it, we'll build it. And that's really the concept of prototype. So the whole idea is that we don't want to do anything more than the most basic of things before we actually do any work. So we don't want to start doing any discovery. We don't want to start doing any building before we really have got very, very strong buying signals that somebody wants something. So that's the beginning. And then we're going to combine design sprints and prototypes. So the outcome that I strive for when I'm combining these things is that we want to understand how to place the right bets on the right ideas. And as most of you know, when you're dealing with any kind of process around ideation to execution, it's all a bit. So even if you've done everything really well, you're still not always guaranteed to be successful with brilliant ideas. So we've all had experiences, I'm sure, where we've got what we think is a brilliant idea. We've done everything right and still for whatever reason, for a range of reasons. We're not quite as successful as we want to be. So everything's a bet. And we also want to try and shore up and give ourselves the best chance of becoming winning ideas based on data, not opinion. So that's one of the key things again around design sprints, but also around prototyping. So we don't just want people saying, I think I would buy it or I think that's a good idea. We want to get the data behind how people are going to act, how they're going to interact with these products and get some buying signals that they, how they might make a better decision, how they can help us get to a better decision and make a better bet. So this is the, if anyone is familiar with design sprints, this is the design sprint map that you would have seen. And basically you're sort of working through a process of kind of trying to understand through a range of techniques, which you'll go through in a minute. Then you're going to sort of ideate, then you're going to decide and then usually a prototype. This is here where we're going to prototype and then you test. So we're going to work through this end to end process today. But how you start is you start with the kind of challenge that you're thinking through. So what, how you kind of decide to come to a design sprint is because you've got a problem to solve. You've got an initiative or a project or a product that might be in trouble. You might want to be starting a new initiative. You've got a new product or a new problem that you want to solve. And then you think, okay, this could be a good candidate for a design sprint and we'll go and have a look at that again a bit later. And oh, sorry, one of the key things is really preparing the design sprint team and we're going to have a look at that as well. So we'll work through this end to end approach as we go today. So we're going to cover in who do you have to need to have in the room for a design sprint. We're going to look at, you know, what is designs, what is a design sprint and what is prototyping. That's why I asked at the beginning, you know, what's the level of knowledge. So I know how, how, where to start from there. When to have it, when to use these different techniques and then how to run design sprint. So given, given most people said they're not really familiar, we'll go into some detail on that. Sorry, these slides are moving. I don't know why. And then we'll come and combining that with prototyping. And we're going to have a problem around traffic congestion. So that's a problem that's irrespective of where you live. Everybody is familiar with it with the problem of traffic congestion and especially now that we're, we're going back into, you know, environments which don't have as much COVID in them, we're starting to see traffic again, when to use these techniques and then we'll sum up with some learnings. So I'm just going to pause and check if that sounds okay to everyone. Pop something in the chat. If there's something else that you would like to, um, like to hear from. So we've got a thumbs up there. Okay. All right. Beautiful. Good. A couple of thumbs up. Thank you. Okay. So let's um, let's just sort of pause and sort of think about a design sprint. So, you know, really design sprints help you get from kind of vague ideas. And as I said here of what's wrong into concrete tests, concrete solutions to test ideas. So there really are greatest hits of business strategy, innovation, behavior science, design thinking, lean and agile methodology. So if you've got, you know, a couple of those, you can, you can bring those skills to a design sprint. And it's really packaged up then into a battle tested process that teams can then use to try and solve any, any challenge. It's a research tool that gives, you know, the outcome of which is to give companies tangible results and help them stop wasting time and resources in terms of building the wrong ideas. And it follows a step by step process, which is one of the reasons I like it. So people can learn along the way to sort of test and hopefully build products faster. You might be familiar that it started in Google and then there's a design sprint book and also a course that you can do to follow along. When it first started, it was done, it was always done over five days. There's now a process that's usually done over four days. You can actually do it in, usually I do it in a couple of days because it's very hard to get all of the people in an organization for that time. I've also done just, you know, very, very short design sprints over 90 minutes. If you just, if you just pick out the real eyes. So you can, you can, once you, once you know how to do design sprints, you can make them work for you in terms of the key elements. But basically, what you're trying to do is you're trying to validate the time and the time between getting an idea, having an idea and then getting data to help you decide whether or not the idea is going to work or not. And that's really the essence of a design sprint. A prototype then is really enabling you to fail fast and fail cheap. So the key things around a prototype and that you want to be able to test an idea with almost, with zero dollars and in 24 hours. And the key questions are should I build it? Not can I build it? And you're really asked after data, not opinion. So prototypes are really trying to enable you to, you know, circumvent that sort of real, real error of going into some kind of, you know, full blown business plan or full bone product without really understanding what it is you're doing. And it's really trying to help you to test out any assumptions you might have. So preto, preto really comes from before meaning before. And it really helps you decide that you're building the right it. So sorry, I just lost my place for a sec. Yep. So the difference between prototyping and preto typing is that preto, preto typing is much lighter and much quicker than prototyping. So prototyping is usually when you've got much more of an idea about the concept that might work. And you might take a little bit, you might take more time to think through what the product features might be. And you're probably closer to the product increment. Whereas prototyping, it's more, it's closer to kind of throwing things against the wall and seeing what's going to stick. So we're going to look at some different kinds of prototypes as we progress through. But it's much more, it's much more about how can you quickly get an understanding of what might work. It's sort of like pretend prototyping. So the emphasis is on low fidelity mockups. You're trying to use it to see a user's problem. And you're trying to get that feedback as quickly as possible. Actually, I'm just going to come off and just see if there's any questions there, because I can't see the chat coming through. So I'm just going to see, are there any questions so far? Because I can see a couple of things in chat. Okay. So someone just said, what's the main difference between prototyping and prototyping? So yeah, one of the main differences, as I just said, is the difference in terms of the how close you are to a product increment. How is MVP different? Well, an MVP is basically your product. It's basically the minimum features of your product. So your product, it should look and feel almost like your product. And your product might have some additional features that are added to it as it goes along. But it's basically your product as you'd like it to be when it's fully released. Yeah. So yeah, you're right. Sometimes prototyping is also called pretend prototyping correct. Okay. All right. So when a prototype is needed, when is a prototype needed to be started and completed? So we'll get into that as we progress, if we can hold that question. Okay. All right. So I'll go back and share. I just wanted to check in and make sure I, for some reason, I can't see the chat I'm coming through when I'm sharing. So I will just go back and share my slides if that's okay. There are no other questions. Okay. So one of the key things to think through is that when you're running, I'm going to talk now for a little bit specifically around design sprints. So one of the things we talked about, we established at the beginning is that most people, I think there were a couple of people who had done design sprints or had heard of design sprints, but most people hadn't. So we will go back. We will spend a bit of time on design sprints. So one of the things that, one of the reasons design sprints were created was to bring people together, to work together on key ideas, but to work in a specific way. So the principles are outlined here and the first principle is around working together but working alone. So what that means is that during the design sprint process, there's quite a bit of time when you do your own sketching and you do your own thinking, but then we come back together and we share that. So we do that so that we don't bias each other in our ideas or our rationale for thinking through our responses to a product and we come together to think that through. The second principle is around getting started versus being right. So again, we've all had circumstances where we tie ourselves up in knots thinking, oh gosh, these things become too big and really around design sprints, everything is really time bound and everything's really fast and the idea is that we just really want to get something down on paper and we want to get something just started knowing that we can iterate so that we can kind of get our ideas out and then we'll build on those. Tangible things over discussion. So we've all been in meetings, we've all done product work, we've all done process work where we've had wonderful discussions but then we've said, oh gosh, now what do we do? And then we've realized that we've taken all of our time just in discussion. So the design sprint is very structured and we take the time to write and draw and capture in a very structured way. So in a moment I'm going to walk you through the design sprint structure and you'll see that and we don't rely on creativity. So one of the barriers that holds each of us back is that people think that they're either not creative or they're not as creative as somebody else and so they put barriers up when trying to think through a problem and the design sprint is a system that helps you work through any of those biases that you might have and enables you to decide that you don't have to rely on creativity as the key tool to get you there. The system will actually enable you to do that. So that's what we do there. Okay, so Alberto Savoia, he came out of, was the Google innovation that one of the key people in Google and he actually was the inventor of prototypes but also did a lot of work around design sprints as well. But the reason I call him out is because he does a lot of work around product maths around new ideas but one of the things that's really important that he champions is that even if everything goes really well, even if things are perfectly executed, we still have 80% of new products that fail and that's something that's really important to hang on to. Okay, so one of the really important things is the system of the design sprint. So I walked through before the design sprint map and I know it's really, it's going to be hard to see on this one slide but I'm just going to describe it to you and then we're going to go through it in detail. But basically, sorry, I don't know what is happening with my slides, I must be learning on the wrong thing. Basically, what happens is that we have a process where before the design sprint happens, you need to do quite, you need to do a bit of work to make sure that the key stakeholders are available within your design sprint to participate in the design sprint. So as I mentioned, when the design sprint was first conceived, it was conceived as a five-day event which as we all know allocating five days for anything is really difficult and especially if you're wanting to bring in key stakeholders, that's really difficult and having to get everyone that you need together for a dedicated amount of time is pretty tough. And so as I mentioned, now what I do is I either compress the time into a couple of days or I have three mornings where I bring people together or I have a couple of sessions where I bring the key, like everybody plus the key stakeholders and then the rest of the team across the rest of the days. So basically, what you're doing is before the session, you've obviously determined that a design sprint is going to be the key idea, the key technique that you're going to use. So I'm just going to go to the next slide first and these are the kinds of questions that you might ask to determine whether or not a design sprint is going to be appropriate for your challenge. So you might determine whether or not you've got a customer problem and that's a good thing to be using for a design sprint because you can either bring some customers or you can bring some customer feedback or you can bring some external information to discuss. Solving a high-risk challenge, so it's something that's waiting enough and it's something that's big enough to solve. If you want to offer something new to market, that's also a good thing. If you're wanting to source new customers, if you're wanting to decide between product options, when you're looking for alignment and buy-in, so if you've got some people internally where you're thinking actually we actually need to bring people on board, that could be a good thing and then also at the inception of a product or at a crisis point and then you need to be determining whether or not the problem is big enough and worth solving. If it's worth bringing a group of people together, so is this something you can actually just do yourself or is it something you can do with a small team? Do you actually need to bring a group of people together and if you're going to do this initiative, how much would it cost if it goes wrong? So that's another key consideration. So they're the key things. In terms of I mentioned team roles, in terms of the key people that you need, you need to have somebody who's going to act in the role of facilitator, so somebody who's going to keep the system of the design sprint going, who's going to keep all of the times going and they need to be really key on the times. Somebody who's the decider, so this is usually your primary stakeholder, so the decider for this is if you were making this product, making the key decisions and you made your decisions within the sprint and then you took them outside of the design sprint and this person said no that's not going to work or we're not going to do that, that's the person you need inside the design sprint who needs to be in the role of the decider because you need their agreement within the design sprint. You also need experts, so if we're talking about the problem of traffic congestion, we would want to have internal and external experts who have some expertise around traffic congestion. You want diverse team members, you want key internal and external stakeholders and then a group of other people with knowledge and skills and especially you need people who might block or disagree with the outcome of the design sprint. So you know anyone who if you're if everybody in the design sprint decides on a course of action and again you take it out and then it gets you thinking oh actually this group or this person who's really influential is going to block it, that's the kind of person that you need to get to come to the design sprint. Okay so if we just go back to the design sprint map, so basically this is a design sprint that's laid out on mirrors, this is what I usually use in mirror and I was going to use it in this workshop but I didn't know if everyone had access to mirror and that usually takes a little bit of time to set up but basically this outlines the agenda, who the key people are in terms of the team, what their roles are, their experts, the experts, it also has space for the long-term goal, the how might we so the how might we questions, it then outlines the map and the target which we're going to go through in a minute, it has space for the sketches and the different types of sketches, it then has space for your storyboards, has space for your prototypes or prototypes, it then has space for areas for testing, a scorecard and also a retro, so that's what I always have set up for running my design sprints virtually because that's what I've been doing for the last couple of years, so I would encourage you if you're going to be doing design sprints to do something similar to have either you know unique because you need to set this kind of thing up beforehand because if when you're running these design sprints you don't have time during the design sprint to set these things up within the design sprint, so I'm just going to come off again and just check any questions because we're actually going to then go into doing a little bit of work in a design sprint. Okay, so are there any other questions so far? Yeah, I wanted to understand, I mean do we do this thing right or do we run sprints to run the hypothesis testing? Every time we have a hypothesis whether you know this will work or this will not work, so do we do that for each and everything that you know whether this will work so let us run a sprint? I wouldn't do it for everything because it's a lot of work, so I would have a kind of a criteria for assessment as to whether or not you would run a design sprint, that's why I had the questions in there, you've got to be able to assess if the problem is big enough, if it's worth bringing a whole lot of people together, if it's something you can just solve, so you've got to have your own criteria to say if you need to bring all these people together. The actual techniques you can do yourself anyway you can or you can do as a small team, I've done these as a small team and I've done them just with a small group of people and you can bring some of these techniques out, but to bring like to do the whole spirit of the design sprint with bringing you know a diverse set of people, it's a big investment in terms of the preparation, the running of it, and then the you know the collation of it in terms of the design sprint report etc, so you need to be making sure that it's it's the right the right problem that you're working through yeah. Should I ask one more question because we have short of we are short of time, yeah that's where okay, yeah so does it work for software implementation because software implementation itself takes immense amount of time, so does it work for software implementation in that we are creating a prototype, we are also testing it with the group of people in just a matter of few days, yeah I mean so it wouldn't work, I mean this is this how it would work with software implementation is you would have done a design sprint before you're you're creating something from a software perspective because where you use a design sprint is in like at a conceptual level, so if you're if you're kind trying to create a product or if if the whatever you're creating from a software perspective has really gone awry then you might want to bring it back to a design sprint and say okay where have we gone wrong but you from an implementation point of view you wouldn't be using a design sprint because this is um this is not a standard testing process, this is a you know an ideation and testing process so you're trying to you're trying to you know think through if you know if this then that kind of approach with design sprints so and that's that's one of the reasons why you bring a diverse group of people together so you've got you know so if so as I'm talking about we're saying we've got our problem is we want to solve traffic congestion so usually you bring you bring a you bring a big problem like that so we wouldn't be saying okay so we start with something big and we know that that's big but part of the part of the process of the design sprint is we need to get it to something smaller that we can then actually test and then we can we can potentially create a product for that okay got it thank you yeah never mind um so I've got a question here will we be managing the same ticket if we've got the request for design change um I'm not sure if I understand that question to someone who ever wrote that into you want to um Shali Rajput would you like to explain that a little bit more sure um so question is like when we are managing the design sprint and we are getting some some of the feedback right we'll get that reviewed by our um stakeholders and if they have given you some um sort of design change and which is like not just 20 or 30 percent of design change but I'll say 50 percent of design change will we be managing the same ticket or should we create a new ticket as a change request like like we do for the development yeah so you wouldn't be having design tickets for this because it's it's not this whole process should be should be started and ended within a couple of days so um and out of this process you might then agree what's next so um you you might then say okay now based on what we learned in the design sprint we might then we might then decide to incorporate um some of these um product features into our product but it um yeah you you might then you could you could create some design changes based on based on this but it wouldn't be you wouldn't automatically make those changes I wouldn't think within the within that there's the space of this change because it this you want this to be really quite quick um yeah and then you want to say okay based on the report at which is what what you want to produce at the end then you say okay based on based on what we started with based on what our objective was based on our problem what we found in terms of solution then um then this is what we want to do next okay yeah yeah okay um anything else nope I'm good no okay anyone else no okay so what I'm going to do now is I'm going to start us off on doing a design sprint so um I'm going to imagine that we're a team so all of us have been called together as a team so we are team um team um challenge challenge makers and we have got we've been asked to um solve the problem of traffic congestion so um we have come we've decided this is a big enough problem to try to solve so we are doing a design sprint with prototyping as well so for the rest of the session today we're going to be having that in our mind and we're going to try and use some of our techniques so what I'm first going to do is then I'm going to be I found why my slides were moving because I had my keyboard under my papers so that won't happen again sorry about that um so first um what's going to happen is um I am going to are you sharing the screen no no no I'm not I'm not sharing the screen okay no not at the moment um we don't need to share the screen you just need to listen now um and have each of you got a pen or you can you can type some um questions for yourself yep couple of couple of thumbs up great because what we're going to do now is we're going to look we're going to learn the first technique of the design sprint which is around writing how might we questions so how might we use our um reframing a question of reframing a problem so has anyone used how might we use before has anyone used how might we use in terms of um design thinking or any other techniques so sometimes getting design thinking yeah great so yeah so quite often they're used to sort of reframe a question so they're called HMWs so what we might um what we what we are going to do is I'm going to now pretend that I'm the traffic congestion traffic jam expert and I'm just going to read a couple of paragraphs to you and as I'm reading I'd like you to um write some things that you hear as problems as reframe those as how might we questions so um just have a go at doing that so if I'm saying something like um the most common form of traffic jam occurs when the number of cars is more than the roadway can support you can you can make a how might we as how might we um change the the number of cars on the roadway does everybody understand what we're doing so I'm going to read a couple of things as a traffic expert and I'd like you to change those statements into some um how might we questions so because this is the first technique we're going to use for the design sprint okay so I'm going to start I'll just I'll just read a couple of paragraphs and then I'll ask a couple of people if they can share their how might we's okay so I'm going to start and I'm going to read about a couple a couple of things all right so I am the expert here and I'm going to start so we see a lot of um cars on the road every day however to say that cars are the only things that cause traffic congestion is not wise there are three factors causing traffic jams saturation construction and accidents saturation the most common form of traffic jam occurs when the number of cars is more than the roadway can trend can support this is known as saturation which is a recurring problem in our daily lives it makes up about half of all the traffic that Australians experience on a daily basis saturation is most likely to happen when the population of a city grows faster than its infrastructure I'll just read one paragraph okay great so someone's someone's got one how might we we've got a couple of how might we's in there okay how might we so how might we limit the construction of building how might we increase the size of roads how might we control the saturation based on time beautiful okay so if there was a um if I continued reading how might we be able to reduce the number of cars beautiful so we would we would um have many many um how might we use that would come out of um what the expert and you might have more than one expert what the expert would say so we would continue to do that which is great so that's that's with how might we is we're looking for um positive um positive responses so we're looking for um we're putting our positive spin on how might we solve the problems so um and we usually um sort of listen to the the um expert for about 15 to 30 minutes and then we usually would take um sort of about 30 minutes to try to um work through this problem and then the facilitator usually groups um these categories into sort of three or five categories and then we would vote on those so we've got a few more here um that you can read as well in terms of how might be forecast the population growth and improve in structure how might we restrict heavy weight and slow moving vehicles in those streets great so if we were doing this together we would have a couple of categories here in terms of construction size of roads um reduction of um number of cars and some forecasting so we would have we probably have we'd be able to make about five categories okay so that's our how might we is so um the next thing we would do based on what the um what the um experts had done is we would then have what's called sprint questions so the sprint questions are then thinking about the negative responses to what we've heard so what we what we're doing with a sprint question is we're trying to think through any blockers so anything that might stop us from achieving um our objective um and we write these questions as can we so um we might if we if we look at here about um you know how might we increase the size of the roads etc we might say you know can we increase the size of the road um can we um educate drivers better to reduce accidents can we um can we um build the roads better to withstand heavier weighted vehicles etc so we're we're trying to mitigate any of the problems that we're trying to have and so what we're trying what we do then is we select a couple of those problems that we want to that we want to really focus on so that they can become important considerations for us as we move for move through our design sprint so one question yeah sure right so these are there are two things that uh what I could understand one is HMW HMW is all about focusing on what are the problems that we are facing okay so that's uh the core the core idea of HMW is to identify the right problem statement correct while we are also telling yeah while we are also telling right we should also look at solutions simultaneously by asking questions can we okay can we type of questions so is it like we are you know having a dealing with questions and answers together simultaneously yeah we don't really want to try to get not really not really um solutions but that we're just trying to get the positive and the negative so um we're trying to get the can yeah the can we is more it's try it's it's moving towards it's moving into the solution right realm but it's not it's not completely solutions but we're trying to we're trying to think closer to that yeah you're right okay so that's that's something that you do as a first step right we also try to identify the problems and we also try to identify what could be the solution well we're not they're not quite solutions though so they're just saying that they're still trying this they're still trying to be um teasing out the problem because at this stage we're still we're still trying to tease out the problem because we we get closer we get into the solution in a little bit further it depends on it how long we're taking but we're we're not trying to close anything down we're just trying to still keep our minds open to um what can what could we do because at the moment you know we if we've got we've we've got an expert there who's who's talking to us we're just sort of saying oh well you know could we can we do this can we do that etc so um yeah we're trying we're trying to um just think through what might be possible yeah okay yeah okay and one one last question is like let's say i have four hmw questions okay one two three four yeah for each hmw question should we have can we questions or no no you don't have to you don't have to you don't have to relate them no no no no no yeah okay cool all right so um any more questions before i i'm just gonna because i'm gonna go back to the slides anything else no okay all right well let me just um go back here okay all right so um let me just yeah so we've just talked about that we talked about so basically then if we've got the how might we's and we've got the sprint questions what we what they want to be thinking through is the vision so we want to be thinking through um our long-term goal so this doesn't have to be um this is not something that we would never revisit but it's something that we want to be saying okay so just at a high level now that we've we've sort of started to identify um where we're sitting um or we've got some knowledge um in two years time you know where might we be so in two years time um we um you know we might have halved accidents on the road because we've introduced something we've we've better educated drivers about um you know the way they drive or we've um controlled for x y z or whatever it is depending on whatever whatever the um the problems are so um we would write a vision based on um what we've what we've determined the problems to be to date so that's that would be the next step that we would take writing our vision um the sprint questions as we talked about and then what we want to do is we want to make sure and this is where we we're um wanting to align you know before I mentioned that we want to move into data rather than opinion we want to make sure that we're working from um what's happening at the moment and then um working to what we want to be where we want to be so we we work to a map and so what we want you to understand is um what's currently happening in um the current system that we're trying to change so we think if we think about traffic congestion you know there's a there's a lot that's happening there so we would be wanting to understand what's happening so this is where we would come back to the how might we areas and we would we would um align those with these key these key concepts here around discover learn and use so we would go back and have a look at the how might wes that you came up with and we would say okay um we would place a couple of them under discover a couple of them under learn and a couple of them under use and then we would work from those and based on that we would then discuss together um where we think the the biggest problems are likely to be and we would vote on that basis um in terms of what is our target going to be because we can't solve everything in a design sprint but there would be a couple of areas that are going to come out as the most important thing in it in um you know in terms of traffic congestion or in terms of any problem so you know it doesn't mean that the other ideas and the other problems the other suggestions the other how might wes get thrown away but it just means for the purposes of this discussion we're going to focus on these couple of things so that's how we we build our map and then um we've so at the end of that that section and that is usually the end of that day um we've what what we've come to is we've got basically um our problem which has been reframed in terms of our how might wes and our um sprint questions we've got a long-term vision and then we've got a map of what our existing system is and then we've got a target in terms of you know what we want um to target in terms of our current problem and so then the IDA really brings us into getting us closer to um what we're potentially going to solve so one of the key things in this section is we want to be able to show not tell so before the usually before the the design sprint quite often the facilitator and usually other people have done some external research in terms of um potential areas of interest and we bring that in terms of a sort of some lightning demos or some um show and tells about you know what's already in the marketplace um that is similar or um has some of the attributes that we're interested in and so we spend some time working through so if we're thinking about traffic congestion we might we might um have already come into this session with some um global examples of what people do in other countries in terms of how they manage traffic congestion or um if we're thinking about from an Indian context we might talk about you know different um different states and how they manage traffic congestion and we might talk about you know traffic congestion in terms of different types of vehicles and how that's managed or different aspects of traffic congestion so we would we would talk about that in this this session and then what we're what we're doing is we want to be able to sketch and so this is this is the key component of working um together but working alone so in this section of the design sprint this is where we first we spend some time either writing or drawing and we collate all of the work that we've done first in terms of the high level how might we use the sprint goals this design sprint that's so the design the two-year vision and we we get really clear on what those things are and then um we collate the lightning the lightning demo um examples and the elements that we like from those and then we might sketch and so we'll we might sketch in a range of different ways um and people get can get um sort of nervous about about this there's a concept called crazy eights I actually usually do just do crazy fours because I find that you don't get much more than four ideas um and so that's really just sort of sketching four different kinds of ideas that you might have um for your or what a solution might be and then um you know creating different kinds of solutions and then the idea behind this is that you you individually create a sketch and then you show it to each other and so that you can you can share your concepts but you can also build on those concepts for each other and you can take different components of um each other's concepts and then you can decide and vote on which concept might be of most interest and then based on that then you can create a user flow and a storyboard of something that you might like to take to um to a testing environment in terms of prototyping so um you can see how this builds in terms of you've had a problem you've had a you've had some external or um some expertise that's come and um you know taken the problem to a different level for you you've looked at it in terms of you know some questioning in terms of how might we's you've looked at it in terms of some possibility in terms of could we's you've then thought about it in terms of some visioning um in terms of your long-term vision you've then um had a look at it in terms of external externally um some external positioning in terms of the two-year vision and the um lightning demos and then you've done some sketching in terms of what it might look like in terms of the solution um and then you've looked at it in terms of the user flows and the storyboard in terms of the overall map and the target and brought those in with the features and so now you've got a flow and a storyboard that you're ready to say okay this is what it could be and so this is where to answer the question from right before this is where prototyping comes in okay so now we get to prototyping but again I'm just before we just before we start here um I can see we've got one question in the chat which is oh so how might we number of cars okay are there any other questions from it um that we want to before we just get right into prototyping that we want to ask at this stage nope okay so there are a range of techniques um for prototyping which are outlined here um so I'm just going to let you take a couple of minutes to um um read those through and then um I will come I'll just get you to read those and then we'll come back together so just take a take a minute or so to read them and then I'll give you an example of each of them okay so um does anyone have any before I start with examples does anyone have any particular questions about any of these prototyping techniques yeah I do yeah I mean I'm I'm still not very much clear like you know what's the difference between preto type and prototype I'm also confused with MVP because all I understand by reading these techniques these are you know different types of MVPs yeah okay so prototype is really light um and it's no money it's really quick the the con the whole concept of a prototype is you do it for zero dollars and you it's something that you should be able to be to test within 24 hours so a prototype a prototype um most people wouldn't wouldn't do a prototype within within with that kind of money or that kind of time so prototype is usually testing um you know at least one feature and has usually been is usually um takes a little bit more time than that and is usually a bit more structured um and has a little bit more rigor around it it's also so prototype is very much conceptual and you you do we're doing it this test because we don't really know whereas prototype is um you got a bit more of an idea about about something and then MVP as we're I mean even though the MVP is one of the things here as well it's not the same level um an MVP when if you're really doing an MVP it is pretty much what it's it's basically your product it's just the minimum level of your product so if you're producing a traffic congestion response it's pretty much what your response would be but it's it probably doesn't have all of the features it's just the minimum minimum level of that so if you're doing a um a traffic traffic congestion report or a traffic congestion um uh policy so if India decided to you know reduce its traffic congestion instead of okay only um you know people with odd numbers of number plates are now available it can only go on um Mondays Wednesdays and Fridays maybe they say okay let's just test it in one city now and that's the MVP before they roll it out to the whole country okay they just do one town one town because that's the MVP but it's it's not saying we'll just test it on we'll just you know do a kind of that's that's the product it's going to be number plates they're just doing it in different way yeah okay thanks okay so um i'm just going to give you a quick example sorry hey i have a question what's the what's the difference between one night stand technique and provincial technique yeah so um provincial is um so in the example i just used um for the traffic congestion if you were testing it in one if you're just testing that traffic um congestion in one one city or one area um and you're testing something locally that's that's provincial so you're testing it in a small area and one night stand is just limited in terms of um time so you might you might say um we're doing this test for one one week only usually it's that's a dollar value one night stand is a dollar value but it could be a limited time time as well it's a limited time only usually refers to um you know this this amount of you can get this special if you hurry now or if you act now you'll get this this better deal okay thank you yep no problem okay so we've talked about a couple of them um so fake door is um yeah so something that's not not there at the moment so um you know with someone would someone take up a product um which is not currently available so um yeah you know how you can do you can do that is that um you can just kind of pretend that something's something's available and um and you know set up a set up a website that gets into register their interest or that sort of thing and then say to them okay we'll put on a wait list or we'll let you know etc um a facade so um this is where um yeah again it's fairly similar where you've got buy buttons where you're wanting to get um people to understand scalability so an example of that is um like in the in the 90s when they're first working out if people would buy cars online they did a cars direct website that had a buy button and um somebody sold the guy who did it first sold some cars on the weekend to prove that it was going to work um he lost a whole lot of money but he proved the concept um Pinocchio this is a non-operational version of something so Jeff Hawkins who did the first palm pilot he did his first version of the palm pilot was a wooden palm pilot and so he he carried that around with and he used instead of a stylus he had a chopstick and he used that um for ages getting a whole lot of feedback on whether or not people would use a palm pilot before he actually built one um quite a few years later um a mechanical Turk so IBM famously used um a mechanical Turk in terms of the speech text computer and the key thing that they they learned with the objections that people had were privacy but also that they thought people thought that their throats would get tired um in terms of using that um uh in terms of um MVP so the first iPhone um didn't support cut and paste and it only um had a few notifications so um they put it out anyway because um and then they added things later um one night stand so you know everyone would know the Airbnb story that was a an example of a one night stand where they had a a quick offer of um an air mattress breakfast for $80 a night and they were really surprised when three people signed up um on the first night and then now it's worth $10 billion um Pinocchio um oh we've talked about Pinocchio um Provincial um we've talked about that but um and YouTube so um I mean Google Glass was an example of YouTube where people um um had the opportunity to to sign up and pay for that um before um Google produced it and they were able to really gauge the initial level of interest for for Google Glass so yeah so they're good techniques to um to produce um before you determine whether or not you should you should actually build a product okay so um one question here yeah yeah I just uh wanted to understand right when when let's say Steve Jobs or the entire team Apple team this you know came up with the iPhone and Steve Jobs had commented if if I actually create a product and if I start validating it into the market um it will be difficult for a product to come out because people themselves don't know what they want okay that was statement yeah so right all he said is like you know people have uncertain behaviors so how do we actually so is it really a rational wherein we can validate or it's it's like you know a case like you know we cannot validate what's it like who is right in this case we have a lot of preto type techniques but you know there are you know market leaders who are talking about it in a different way yeah I mean basically he would be the I would imagine he would be the same that you just you need to um run a range of tests and I guess that's why I reference Alberto Savoia in the beginning that you know you basically even if everything's going right still 80% of products will fail so um yeah you know um with the palm pilot example um you know Jeff Hawkins he he carried that wooden palm pilot around for two or three years in different iterations testing that with different people and got hundreds and hundreds and hundreds of people's um feedback before he actually produced anything that was mechanized because he just was trying to get the people to understand and give him give him commentary on the usability and utility of that so um yeah I think that that it's probably a combination because I and it probably depends on um the the type of disruption that you're going for so the palm pilot was was in that category and the same as uh you know the the iPhone um yeah so I think it's it's probably a similar thing that you kind of just some you know you you've got a you know we all know that there's things that have been brought onto the market um which have similar potential um changing life changing properties as the iPhone that haven't taken as well um and so you know for every everything that's um that's taken in terms of the iPhone there's there's a whole um uh there's you know there's there's things that haven't so I think it's it's a case of you know keep trying yeah okay okay thanks yeah okay um all right so when we when we're doing prototyping um sorry did did anyone else have another question oh that's it that's it no okay great um so we also we then also use um generally we use a a lean canvas so I'm sure most of you have used lean canvases before um and so we use a lean canvas to basically then work through um before we said that so we can choose which of these techniques um we would most effectively use with our problems so I've prepared a a lean canvas so I'm just going to go to can you see that now yes yeah okay perfect sorry I had done two versions and this is so um basically when you're doing a lean canvas for prototyping you um you don't need to include the cost structure and the revenue um because you're not at the point where you need to worry about those so if I was doing a lean canvas for um traffic congestion I've I've prepared one here um so I've said here that um you know the problem is traffic congestion is a universal problem and it contributes to air pollution adds travel time and increases accidents and my solution um based on the design sprint that I did in my head um with myself um was a private location location based car sharing solution so you know I would pick up my neighbour my neighbour would pick up me we work in the same building etc um my key metrics would be the number of inquiries or people who indicate interest in car sharing my uvp would be to have my have the travel costs my unfair advantage is to partner with large corporates and partner with city car parks to advertise the service the channels would be social media car parks workplaces internal email news or news media and customer segments are office workers and schools and then you use a process so that you have the idea you um through a link have a canvas capture and clarify idea assumptions you've got it you want to um get a key market hypothesis so determine the overall hypothesis to validate you've got an x y z hypothesis so you set the metrics against the market hypothesis you've got a hyper zoom so you really want to zoom in the hypothesis to target a key um customer segment and then you want to experiment so you design run and revise the experiments and then you want to get a decision so um that that you can really compare the results with the success metrics and decide your next action so for me if I've run my experiment and I've I've um undertaken my based on my lean lean canvas I've said that people will share their cars and drive and driving to save money time in the environment I've hypothesized that 20 percent of my organization will work will inquire about car sharing and on the day that I run car sharing 10 percent fewer cars are observed in the car park um I think that 2 percent of people adopt car sharing if they if they save money 2 percent if they can save save time and 1 percent if it helps the environment um I intend to run fake door and mechanical Turk um experiments and the decision is if 5 percent of inquiries do a car share and confirm that they've saved dollars um time or environment savings then I would go ahead so that's the process um that you go through to confirm that your prototypes have um have actually got you where you need to go so there's a there's a couple of you know templates that you need there in terms of the the lean canvas that needs to be completed and then this process um which you you you can pick up from the slides um to basically run run your prototype so it's not like you just set off your set your prototypes um out into the the ether and hope that they work but basically you you need to run them even though you're running in the minute you know an expedited time with no money you still need to control them so that you actually get you know you know you get some meaningful outcomes from them so basically you're really wanting to kind of undertake a process where you're running in prototypes you're getting your customer feedback you're then collating your score cards at the end and then the overall approach that you wanted to take then is developing a sprint report and conducting a retro with as you do with with everything so um that's pretty much the the design sprint process which when you when you have a look at the slides um after this session you will see that that's mapped out in that um the five-stage approach that I've provided um so I just wanted to see if there are any final questions in our last couple of minutes because what we've done today is we've taken a look at design sprints and prototypes we've looked at sort of when wine how to run design sprints we've looked at some prototyping techniques and then we've looked at um combining design sprints with prototyping so I just wanted to um then sort of say thank you and leave you with my details um and yeah I've written written just recently written a book um on experiment driven transformation and I'm writing a new one on innovation um so yeah I'm happy to take any questions that you've got um now um yeah I have all right it's it's again me I have one yeah sure question yeah see right when when we started with this entire sprint exercise we saw you know the first step is about mapping yeah to do the maps in in maps we said that you know we need to write down each and every step of a current process and we need to tie hmw with that current current uh set of processes right right out of those let's say we identify that the current process is five step process okay and we also write hmw okay and we are trying to tie hmw with the current step process correct that that's what we discussed you know that the how might we's um linked to the expert interviews so the overall map so if I I'm just going to take you back to let me screen again because um I think you so let me just go back okay so can you see this is the overall sprint map correct and um so there's a there's a couple of maps so that the yeah sorry the overall process is called a sprint map but within here as well there is a um map of the process yeah map of the process I'm talking yeah yeah map of the process yeah so that's that's that's part of this and within within this first section which can either be a day or it can be you know your first chunk of so I don't I like it used to be that these were each days but so we'll say a day for just for ease of explaining it so within the first day you're trying to really understand the problem and and sort of ideate on the problem and so what you're wanting to do is you're wanting to um you're wanting to hear from the the experts so you want to um hear usually from an internal expert and an external expert about why this is a problem and why people should be listening to it and you're wanting to listen to that critically with how might we so that's reframing the problem in terms of how might we is and then you're also wanting to listen to it um in terms of you know then from possibility in terms of can we's and then you're wanting to reframe those both in terms of like you know then what could it be so the long-term vision so they're the three things in terms of saying okay based on the external view um of the problem what what could happen and then the the map that so that's the the three components and then what you do with the how might we use is um because usually you've got quite a few people in this you'll get some similar ideas so you you'll do some affinity mapping but you'll also do some categorization so there'll be some things that come up that are similar so one of the jobs of the facilitator is you want to basically kind of create about five categories and you say okay this is category one ideas category two three four five and so you kind of want to put all of their different ideas under those different categories and so and you do the same with the sprint questions so you're not trying to you can't because you can't deal with too much stuff so you basically categorize those things and then you say okay now we want to understand what's currently happening so what's currently happening in terms of traffic congestion so we want to we want to map what's happening so we want to say okay currently in india what's happening is in terms of problems we've got people leave the house then they get on a bus and it's crowded and then they get to work and they work all day and then they try to go home and it's crowded and they get home really late because it's so crowded and or they get on you know they get on the train it's crowded they get on the the road it's crowded they get in a cyclo it's crowded they get on a bicycle it's crowded you know and the the environment is terrible the roads are cracking etc etc so we want to we want to map everything that's happening and then we say okay that's the map of the current system and so when then we say okay within the current system what are the key problems there that we want to focus on and then looking back at the long-term vision and and the categories of how might we send spring questions which can which can kind of align a little with those we can say okay what what what would be the target area that we want to focus on so it's not just the how might we is linking up it's saying okay given given all of the framing of the problem um does are there particular areas of the current current um problem that yeah that are leading us to focus yeah so so when we are talking about a current process are we actually laying down a customer journey map or you can do a customer journey map is a good a good thing to do but it doesn't have to be it's usually only about sort of six to ten steps it's not it's not highly detailed because again you're trying to do this in in um you know an expedited time frame and so and you know you know sometimes customer journey maps can take forever okay so now right going back to the last slide where you know we had these steps just wanted to understand where in the map does this fit oh in which to the traffic the our traffic solving problem last slide last slide last but one just before thank you yeah this one yeah yeah so prior to this one uh prior yeah yeah this one right we said right people will share their cars and i mean that's actual market hypothesis right so where in the map i mean is this actually related to the actual problem statement or is this related to one of the steps of a map so i'm imagining that as part of the design sprint that um we together said we came up with an idea of saying one of the solutions could be people sharing their private cars instead of everybody taking their own car and so the hypothesis was you know if people shared their own cars um it would save money time and the environment and so that was what the the hypothesis we were testing so it's it's just one step of the entire map right that's what you're talking about yeah so this is yeah so this is so we wouldn't we wouldn't only be doing we wouldn't necessarily only be doing this one but this is but we might we might do two or three but we wouldn't do more than that that's what i said before it doesn't mean that other ideas don't nothing it doesn't mean that nothing happens to them it just means that you choose because we're doing we're doing um we're trying to choose the best the best ideas so whatever you know as a group you decide is the best that's what you want to take forward okay that's why you need to have your key objectives and your blockers within the within the sessions because if you're going to spend all the effort of trying to come up with these ideas and then do the work you don't want to then go back and say oh my god we found the best idea and then they say what are you talking about like we don't think this is the best idea and also we don't want to spend any time on doing this yeah okay awesome thanks thanks a lot for you know sharing your knowledge thank you thank you so much thanks great okay so can't take your back that probably means it's time yes uh yeah we are almost we have almost covered up everything i don't see any major questions in the chat for now but uh yeah thank you so much panel up for the session it was really a wonderful talk from your end