 Hey everybody, Brittany here. You've just clicked on the absolute perfect video if you're just about to run a design sprint. In the following footage, you're going to get answers to questions like, what kind of challenge should I actually try to solve in a design sprint? Who should I bring into my design sprint? And what exactly should I expect if it's my first time running a design sprint? So the following footage is actually taken directly from our online design sprint masterclass. If you want more info on that, you can just find the link in the description. What we've done in this video is we've spliced together three videos that are all really, really valuable and nice and short and sweet. If you do have any questions or anything comes up at all while you're watching, just throw a question in the comments. We answer absolutely every comment, if you can believe that. If you want more videos about the design sprint, about product design in general, UX, UI, the tech world, you should definitely subscribe to this channel. We are releasing videos every week on all of these topics. If you want to make the design sprint 10,000 million times better and easier to run, then there's a couple of things you can do to prepare and make sure that it really runs smoothly. Using some time in the week before to prepare the long-term goal, the sprint questions, the map, and the lightning demos is an amazing way to get a great head start and to really build confidence with the team on the Monday when you start already with a little bit of information. And we're going to tell you exactly how you can prepare that right now. The way you can do this is not just you as a facilitator sitting down and trying to guess what these things are, but having a little catch up chat with the person who really owns the product. So it might be someone called the product owner or the person who really knows the most about the product or the thing that you're dealing with. So having a quick phone call for us, it's a phone call with our clients, one of our clients to talk to them about this. It could be just you having a quick catch up with someone who works in your organization. Could be a fax. Just no faxes. But just to really have a quick check-in and start asking them some really general questions to just start getting a bit of understanding about the topic and using that to give your input. So in the call or in the meeting, you can just start asking them things like, what are the main problems that you're facing that you want to be dealing with? What's described as current situation to me? And while you're having this talk, just as you're listening to them, start writing down some already, some how might we post it notes, which you'll learn exactly what they are in the rest of the masterclass if you don't know already, but you're really starting to write down, rephrasing all the things that they're saying as really simple questions that frame the problem. So you might start with a few of those already. And that's one of the exercises in the sprint that you can start with those how might we questions and bring them in as a starting point. And while you're asking them all these questions, you're really just starting to get a picture in your mind as a facilitator how what the whole thing looks like. So after you've had that that chat could be just a 30 minute chat, you can go away and then use that to start writing your own version of what you think a long-term goal should be, your own kind of draft of what the map could look like and getting some of your own ideas about what good lightning demo examples could be good examples from other companies and other products that are solving the same kind of problems that need to be solved here. So just having that chat, sitting down and getting a starting point or a draft of some of these things, these exercises, how might we questions, long-term goal, sprint questions and the map and lightning demos. It's but it's really important to keep in mind that you're only giving yourself a bit of a head start and making it a bit easier. And you should tell that person that you're speaking to as well that this doesn't mean that these are the answers now, that this will be the long-term goal, that this will be the map, but you can tell them you're asking them these questions to help you get a starting point for these exercises. But when you're in the group, you'll ask the same kinds of questions in the expert interview and you'll hear from multiple people that might be experts in different parts of the product or service and these things might change. So even though you're asking them the questions and getting their perspective, when you're doing the actual sprint with the team, you'll be using that as a starting input, but they will change, the map might end up looking a bit different, more lightning, there will be different lightning demos that come out of it as well. So it's important to give them that awareness that you're using their information to start, but that it will change when you're in the big group together. Yeah, and I think it's maybe a couple of points there to summarize as well. When you are preparing the sprint, you're not just collecting random information, right? In your mind, you want to fill out a couple of things, right? Before like, let's say two years ago, when we used to run the sprint, we used to talk to the stakeholders beforehand, we used to gather a lot of information and then share it with our team. That doesn't really work. You want to be starting the day with some scribbles of how the map might look with some scribbles of how the long term goal can look so that when you're facilitating, you can already get a head start and start filling things out just to help guide people along the sprint. Another thing you can talk about in that, while you're having that chat, is you can, if it makes sense, you can already start talking about the customers and the target market that they might already have or they might know it's generally this product or this feature that we want to be kind of working on. So this is our customer segment, this is our target market for that area. And that also as a facilitator can help you or the person in your team who's going to be recruiting the user testers, that can help them get started a little bit earlier with recruiting user testers. It doesn't always work because sometimes you go in with a more vague challenge and you're not sure exactly even which product or part of your product you might end up working on. But if you can, if you think it makes sense, start talking about that stuff too. And there's one other person you should have a really quick chat with before the sprint as well. And that's the person who's going to be the decider. That could be the same person as the product owner or the product expert, but it's not necessarily the same person. So make sure you have a quick chat with the decider as well, just to explain what the role of the decider is. And that there'll be different points during the sprint where there'll be the ones that are needing to make a choice or a decision. But the whole group will be providing input to help them make that choice and give them that feeling of what their role really is. So they're not going in completely cold. So make sure you're starting Monday morning with a maybe a few pieces of paper in your hand or maybe it's on your laptop. You want to have an idea of the long term goal. You want to have an idea of a couple of the sprint questions that might come up. You want to have an idea of the map, couple of the top rated how might we that you think maybe those are going to bubble up to the top and you want to have some lightning demos up your sleeve. Now all of it might change in the end. In fact, it's very likely that none of it will stay even close to the same, but it gives you the confidence to guide people through it. Right. This is really, really starting the sprint without this is going to hurt you starting it with this preparation will give you the confidence and give the team the confidence to actually get you through the start of the sprint and all of this, everything we've just talked about the conversation with the product owner conversation with the decider starting to scribble and sketch out how might we use and the map and getting some lightning demos and thinking about sprint questions. All of this you shouldn't spend more than two to three hours. This is what we spend. So a couple of call calls or chance and a bit of scribbling and starting to get these starting points just a few hours. If you really put too much effort into it, you won't find as high returns as the effort you put in two to three hours is totally enough. And if you put too much in, then sprints will start to feel more difficult to do because they you feel like there's so much more prep time that you have to do. So only spend a few hours to do all of this and you can feel really well prepared for your sprint on Monday morning. One of the most important things to figure out before you actually start a sprint is knowing what kinds of problems are the right types to bring into a sprint. Yeah. And it's super important that you bring the right types of problems into a sprint because if you bring the wrong types of problems into a sprint, bad stuff can happen. So let me just like actually tell you very quickly what the right types of things to bring into the sprint are. The right types of problems to bring into the sprint are problems that are big enough to warrant bringing a group of people together and blocking a week of time, right? So you don't want to be doing things like, hey, we want to change like one of the icons on the left sidebar. That is not a sprint. A sprint would be, hey, we maybe want to add a subscription service to this product, or we want to create a brand new product, or we want to do something that's big enough and could be costly enough if it goes the wrong way. The sprint allows you to validate things very quickly. So you want to bring things in that are worth validating quickly, right? So one way to even measure it is, if we're going to do this project, how much would it cost if it was if it would go wrong? And I guess you have to figure out what number that sprint is worth for you, right? So don't bring problems that are too small and too specific into the sprint. Bring problems that are big and messy and potentially dangerous for the company into the sprint. Another thing to think about also is how many people are involved or how many different teams are involved in the decision. If it's, it could be a big decision, but if one person really has the authority and responsibility to just be able to make that decision without it being useful to get different perspectives from different types of teams, if it's a decision that can be made easily without needing to bring in those different people, that maybe doesn't need a sprint either. One example of a reason to run a design sprint is if a company has a product and they're struggling with increasing the engagement rate for that product. So that's something pretty broad. That's something you could run through a sprint. One example of something you would not want to actually run through a sprint is if that same company was trying to figure out, we want to change the navigation in this app. That would be something that maybe just the UX team can figure out themselves without a sprint or just by taking some elements of the sprint, but it's too small and it's too compartmentalized, especially if it's spread out over multiple teams like marketing sales and especially if it could have strategic implications on the whole company, then a sprint is the right thing to do. So make sure the problem is big enough and not too baby small. So now that you know how to set up the perfect sprint team, it's time to move on to the next step. Who should be on the design sprint team? Good question, John. This is a question we get all the time, constantly, constantly people asking us how to find the right people to be on a sprint team. So who should be on a sprint team, John? Okay, so I'm going to kind of take this from two different angles. One is that if it's a smaller company, let's say a startup or a small business, and two is if it's a large organization, which can be some Fortune 500 with thousands and thousands of employees. If it is a startup, then generally what you want to have is the team is the CEO, product manager, someone from sales, a designer or two, and then maybe someone who's involved in marketing. And that would be for me, a pretty perfect sprint team to have, obviously, plus a facilitator if you don't have someone in that team who's really comfortable with facilitating. And if it's a large organization where the chances of you getting the CEO in the room are pretty difficult, then probably the most senior member in that team is going to be either the business owner or the product owner. And then you have someone from sales, someone from marketing, and then maybe some designer. So I think that would be an ideal looking. So it totally depends on the project, but this mix of people is the most important thing. And I think a clean number to have in every sprint is seven people. That's the ideal team size. When we're doing design sprints, we send two to three people from AJ and SmartSide, and we ask for about four people on the client side so that we get this sweet little number. So around seven people is ideal. We've run sprints with up to 12 people. That gets really messy and gets really long. So I think it's like between four and seven is your ideal number. And then who should be the decider is the next question that people are always asking. So then this is really, really important to get right as well. And we've had many situations where if we the decider isn't available to come at all, or they just pass it on to someone else, but they're not really the decision maker that we've not done the sprints for this reason. So it's important to actually understand who the person should be, who the decider should be. And that person should be the one who in reality, in the real world, in that organization, is the one that actually has the responsibility to make the decisions about this topic. So it could be the product manager or the project manager, but if there's someone above them or even not above them, but someone else who would come back and be able to actually have the authority to say, no, I don't like that idea, we're going to do something else, that's the person that you should have in the room. So it's not necessarily just about the role, but it's about who has the authority to actually make the decision. And if someone can override you after the sprint's been done and say, no, thanks, that's the person that needs to be there in the sprint. Yeah, you can really destroy the whole sprint by, you know, somebody who you think should be the decider telling you, oh, no, no, it's okay, I'm just going to give it to like Sarah and then like at the end of the week, I'll have a look and see what's up. You say, no, that's not okay. If you want to give the responsibility to Sarah, then it's all hers. Like she is going to be the one making all the decisions and then nothing will change afterwards or else you need to be in the room. So either they hand over all responsibility or they have to be in the room or you don't run the sprint because honestly, it's a waste of time running a sprint without the decider being in the room. But sometimes the decider can come to the sprint and be the decider, but they maybe say they can't be there the whole time. They can't commit even just the two days. What do we do in that situation? In that situation, we offer the decider to be in the room for the expert interviews for the map and for the long-term questions and goals. They may potentially leave at that point if really needed, but then they need to hand over their decision-making power to someone else in the room and it really needs to be final. They can't come back on the next day and take back their decision-making power because what happens is they start to undo a lot of the work that you made. So we allow people to come in at the start and then leave and hand over the decision-making role, but they really, really have to hand it over then. Is that what you were going to say? Yeah, yeah, exactly, great. Yeah, that's good. We're very aligned on these topics here. Yeah, totally, all the time, aligned on everything. Hey everybody, I really hope that you liked those three videos. I hope they gave you lots and lots of value. If you have any questions, don't forget to put them in the comments below. We'd really love it if you liked this video, if you found it helpful, and hopefully we've convinced you to subscribe to our channel. See you next time, everybody.