Design Sprint - Common pitfalls (part3)

So well, a lot, like a lot of things can be found on the Internet regarding to Design Sprint and what is it good for? So we really want to use this time of the webinar to actually share a bit of some of the common pitfalls we have experienced when a corporate organization is trying to run a Design Sprint. So these pitfalls, we call them the do nots. So every time when you see this, you have to be alert that this is probably something you need to be aware of and mind the gap about. So apply Design Sprint to design a 360 degrees customer experience. From our experience, we say don't do that. So often what we get is a question like a challenge that is as broad as how can we create a fully personalized as well as engaging experience that will want, for example, for a patient that wants to make an appointment with the doctor. So this is something very broad and maybe some of you recognize this kind of challenge that you'll be that you guys are working with. What we often experience is that larger corporate settings, they're dealing with very complex projects and they're often very heavy. And when we step in and we propose a Design Sprint, they think yay, let's solve everything. So it's a broad challenge and there's a lot of pain points or areas of opportunity that can be solved and they want to do everything at the same same time. But what we learned is that the best way in order to get most out of Design Sprint is when you are able to scope your challenge, your point of departure as well as you can. So we really want to avoid the situation where the scope is that broad that you really don't know where exactly to start. And an example is when you figure out that you just want to solve everything. So we mentioned a few questions that you can ask yourself in order to hopefully help you to scope your challenge a bit better. So if you happened, if you're, if you find yourself ending up with a very broad challenge, ask yourself what's truly business critical? So what is that one area that if we don't get this right, then the whole thing will basically, yeah, crumble. Another question that you can ask yourself is what are some of the problems that if we would solve it first, it will allow us to gain most of the learning so therefore not only help us to solve the current pressing problems, but enables us to gain the learnings that allows us to solve the other problems. So these two questions are there in order to help you to really identify that one key moment in your customer experience. That you want to tackle first and foremost. And if you're not able to answer these two questions or you still struggle with scoping the project scope for your design sprint, then we'll suggest to actually before the design sprint to apply the empathize and the defines phase of the design thinking. What it does is it really enables you to better understand the full picture, the full 336 degrees of experience from your customer point of view and then from there understand what are the key touch points that, that we need to run a design sprint on or run multiple design sprints on for various touch points. Um, so a key takeaway from here is that in order to innovate you really go for minimal viable products and you try to limit the amount of touch points that you want to solve or address at the same time. And we have a tool for this and this tool is an uh, is really allows us to temper check whether your project scope is ready for a design sprint or not. So if you find yourself in a situation where the level of assumptions that you were able to validate is very low and at the same time you find yourself that the scope of the project is not yet mature, it's still very young, it's not clear yet, then we would suggest that to run design thinking, the empathize and the defined phase before you're going to run the design sprint. However, if you have a low level of assumption validation but the scope of your project is really clear, then we really believe that this project scope is very much ready to run a design sprint on. So from the first donut, our key takeaway is prioritize what you want to solve first, because a design sprint, it's a highly effective and battle tested process, but it won't allow you to accomplish everything. So scope appropriately and build from there. Second point that we often hear is let's involve all important people, all the stakeholders we say do not on this. So you know the situation where you in a meeting or a working session with maybe eight people or even more than that, and one person says, hey look, I have an idea. And then from there more opinions for that, they don't like it, a new idea gets generated and before you know it you have this bunch of people sitting with various ideas, a lot of opinions and some people just feeling very much excluded from the process and that they're not able to contribute. So this is really not the best way in order to get most out of your people nor out of the whole design sprint. What we suggest instead is really to set Up a core team maybe from seven people from different ranges. So we have put up some examples such as field workers, people from customer support because they know your customers the best, some people from the business and strategy technology, but also like temperament wise. So to really have a mix of thinkers and doers, but only not just senior and management level to really get the juniors, those who are more working on the frontline also involved then the rest of the people who are also important stakeholders to set them up more like a support team. So engage them during the various stages of a design sprint whenever it's relevant. So key takeaway from the second donors is that seven people would be the maximal amount of people to get involved with for a design sprint. Why? Because it is first of all big enough in order to include diversity, but at the same time it's small enough so everybody can fit on a selfie. If you want to take a selfie of the group and don't forget it will keep your meeting very efficient. The next point is to run a design sprint in an early explorative R and D stage. We say do not on this one. So, so remember the Google Glass, it was a really beautiful piece of technology where and that aimed to serve two functions. One is to capture images and second of all is to gain immediate access to a feed of useful information from the Internet at a glance away. So it was a really beautiful piece of technology. It got the early adopters very excited, excited about it. But what is actually the problem it's trying to solve, and this is basically a common business trap, is when we are too focused on the features of or the technology of the product or the service. So in this case, in this case, if you're not really sure what exactly is the problem that it's trying to solve and you're not able to translate that or communicate that to your target audience, don't expect that they will understand for themselves. So in that situation, again, we would recommend you to run a design thinking stage before that in order to truly get your customer needs and problems and insights in a very tangible level and to define the areas that are mostly important for them. But more on this we will share about later. So from this example of Google Glass, we want you to bring one of the key takeaways from this is to identify your key customer needs is a crucial first step for creating a great product. And yes, it sounds like very common sense, but we can't say it enough really make sure that before you're going to focus on the product or on the outcome that you communicated in a very crystal clear, crystal clear way. What exactly is the problem that you're trying to solve for your customers? So don't first make a product and then go and find somebody who is willing to buy it. Really flip that process. But speaking about all these challenges and the do nots that we're recommending, often what we also find the corporate struggling with is that they're really not sure about the challenge that they want to see solve. Sure, like there is a very key problem area and we really know like this is something that we want to target. But often that challenge or that problem is we don't take the time in order to truly define it. So we start to allocate resources and people in order to get involved and get on the project. But often this leads to more costly and resource consuming projects with unsuccessful outcomes. So it's really about being mindful about knowing the problem area that you want to solve and being able to formulate it as well as you can. If you don't feel that you have the confidence to truly understand and explain what exactly the problem is, again, we will recommend you to actually apply design thinking before you gonna run the design sprint. In a nutshell, the difference between the two is that design thinking really allows you to understand, identify the right problem that you want to get it solved. While the design sprint is really enable you to solve the problem or the challenge the best way possible.