Design sprint

Hi and welcome to the webinar. My name is Marco and today I'm going to talk about design sprints for corporates. How do they look like? Why are they different? When should you do it? What outcomes can you expect? And finally, what obstacles are there when you start scaling the methodology? So let's start from the most obvious question that you might have. What's a sprint? We define it as a structured set of activities that take place between four and five days in which teams achieve validation of a business concept of an idea. Essentially, the format was originally developed inside Google. And the way that it looks like is that on Monday the team starts working on a challenge by mapping out everything that they know, and they choose a target, a problem to tackle. On Tuesday, they come up with different solutions and they also look around for inspiration. On Wednesday, they choose one final solution and they start sketching it out as a storyboard. On Thursday, they build a prototype, prepare the testing, and finally, on Friday, they test it with real customers. Now, there's several reasons why design sprints are successful with companies. The first one being that it allows them to avoid bureaucratic speed bumps because people are in the same rooms, they don't need to jump from different meetings. The second reason is that it allows teams to validate concepts early because on Friday, on the last day, you directly talk to customers and show them something. The third reason is that it allows people to drive consensus on the solution because they work together and they need to make decisions throughout the week, which also relates to the fact that it allows them to create a shared vision of the product. A prototype, or rather prototyping in general, is an extremely good tool for making ideas concrete and really aligning teams. It allows them furthermore, to speed up the development process because they go from product problem to solution in just one week. And it allows them to tackle uncertainty because by talking to customers, by testing with them, you can get answers to things that you don't know yet. As I mentioned before, sprints were born inside Google and by such, their structure works best in an environment that has very specific conditions. The first one is low levels of hierarchy. Ideas are just easier to come by when people are empowered to put forth their thoughts and there are no power games at play and they don't get judged for the quality of their ideas. The second condition is, is having an experimentation culture and allowing people to try out something and especially accepting failure. The third condition is an environment in which people from different backgrounds come together and work often on the same challenges, because this allows them to get to speed much faster and to avoid friction and miscommunications. Finally, the last condition is having a place where teams have a direct ownership on their solutions, on their product. Because this means that when the sprint is over, they will continue working on it. They will want to see it implemented in the market. So by looking at those conditions, you might already notice what are some of the main struggles that sprints encounter when they're being implemented. Large organizations the first one is that a lot of times employees who work in corporate environments might have never talked to an actual customer. And this means that their views of what their problems are is likely to be very biased. So if we start a sprint only by asking to internal stakeholders about all the information that they have, we preload the whole five days with a lot of risks, with a lot of assumptions, what the problems are. This means that the team goes off in a trajectory that just loads even more risks and even more assumptions to the project itself. And by such, maybe create a solution that is not really needed, that is not fit to a problem. Most employees are very deep into their own job and industry and they're often also kind of brainwashed in thinking that they're not creative. What this means is that without exercises that pull them out of their ordinary way of thinking, they will keep repeating the same ideas and essentially come up with what everybody else is already doing in the industry. This is especially important if we're working on Horizon 2 or 3 projects, because when the objective is to look for adhesion markets or new markets, then we really want to make sure that we're using every tool that we have to think in non obvious ways. The third struggle is about the fact that the Google venture model, it's all about figuring out what to do, then building it, and then testing it with customers. But then what if you're working inside the big organizations and you have senior leadership maybe coming in in the last days, they will expect something, they want to have something happening after this whole process because we're generating momentum here. However, if we don't make space for figuring out what needs to be done next, then the process kind of ends up in the air, essentially. Which also relates to the final struggle. Siloed functions. A sprint environment is just one of the steps of building a product, but it cannot end up there. If that's the case, the risks are either that the next department just builds the prototype without really looking if there's any commercial value that can be grasped from that, or that the prototype gets deprioritized and goes to the bottom of the product roadmap because the department does not see the value of a validated prototype. So when we started using Design Sprints for corporates, we faced these challenges and we essentially just asking ourselves, okay, but how can we keep all the good things that made Design Sprint successful with tech companies and startups and kind of have it fit with corporate environments? So what we did essentially was changing big parts of the structure and basically compressing the design thinking process in five days. In the first two days, we tried to understand what the problems are by interviewing customers and then making sense of all that information. This is very important for us because we want to ensure an outside in innovation process which is less risky than an inside out one. In the last three days, we go through intense ideation exercises to building a prototype and then testing and pitching to management. Now this is where things get interesting because by pitching to senior management, you essentially empower the project team to let everybody know where the project is going and kind of steering the big ship towards that direction. Now, if you received good validation and you don't need to iterate too much or to continue testing assumptions, then we use the momentum of heavy management there to seamlessly transition to the next phase of the innovation process, which is looking at the value. Is there any value that we can capture from here before we build it? And this is something that resonates really well with senior management because often they're going to expect some kind of business case out of it. And what we're doing is saying, yes, you will get your business case after we look at if people really need it, because otherwise it's just wasted time. So if your company is new to innovation, this is also a great way to introduce governance teams on the innovation process and to also kind of break up the whole thing in little chunks, each of which can kill a project earlier if needed. And if you're curious to understand how that next stage looks like, I suggest you to check out Kenan's webinar on our website. He covered all the main topics. So back to us. A design sprint for corporates has essentially three main characteristics. We started by looking at what worked really well, what made Design Sprint successful for startups and tech companies. And we kept all those features, but we stripped away everything that was not really a fit for corporate environments. And instead we added things like multiple interactions with customers, in depth ideation, industry specific tools, and B2B processes whenever they're needed. And what that means essentially is that it's a different model. Whereas the normal sprint goes from 10 to 4, our sprints go from 9 to 5. So we're more demanding, there's more content. But at the end, what that means for the participants is that it's a little bit more tiring, but at the end of the day, you get much more learning and it's less risky for the project. So that was a little bit of a high level overview of how the sprint looks like and why is it different. But I know that you still have a lot of questions, so I'm gonna go in some more details for each of the days. On day one, we essentially start with alignment and the goal, and then we get information both internally and externally. One thing that has to be mentioned here already is that we do really the scoping of the project before the sprint starts, because then we save this time but for actually research. So what that looks like is that we do empathy research, preparation, introduction. So we introduce teams to what qualitative research is about, how to set up an interview. Then we of course still do the lightning talks with experts, but we also interview customers. What is important here to outline is that in case of B2B projects, then we do need to do a problem sizing and scoping before the sprint start, which is a little bit more in depth. And also we need to prepare different interviews depending on what stakeholders we're going to interview. On day two, it's all about essentially figuring out what kind of problems do we want to tackle. So we go through extracting insights, we map out all the information, we find the patterns, and we create Persona, customer, journey, and then finally we crystallize all that into one or two how might we statements that are really the departure point for ideation in the next days. Again here, different exercises depending of the kind of company, the kind of environment that we're in. Day three is often quite intense for participants because we go through a lot of exercises in ideation and we start often with, okay, what's a creative session? Like, what are the rules of brainstorming? But then we add difficulty with each exercise. So we often start with something easy like brainwriting or crazy8. But then we start adding triggers from other industries like brainstorm cars. Then we start shifting the world upside down and looking at the underlying assumption that nobody ever questions or we even put random triggers. So the more the merrier. Here we really want to get out with the most crazy things and then converge back to one concept card which structures the final idea. Starting from that final idea. Then here we implement the Lean Startup methodology of mapping Assumptions and designing experiments. So we start the day with introducing how you design experiments. What are the major risks of this idea that we have? What can really make it fail? We map all that and we design experiments based on that. Our prototyper or the prototyper at the client side will help the team build the prototype. And in the meantime, we focus on preparing the testing and preparing how you do solution testing the day afterwards. Then the fifth day is really when the plane either flies or crashes to the ground because we have the testing session with the customers who come in. Then afterwards, we structure the inside. We figure out, okay, what parts need to be updated, where do we need to go? Back to the drawing board. But then we also plan the next steps. We give accountability to some of the teams to make sure that they go forward after the project is over. And we pitch to senior management. This is a B2B project. Then in the pitch panel, we also need to include problem owners, senior leadership, sometimes partners or customers. It depends a little bit on the, on the project that you are. But what is interesting here is that by ending the week with a pitch to management and the next steps, we have everyone in the same room agreeing on what to do next. Which empowers the project team to either keep testing the assumptions that were mapped on day four, or to seamlessly transition to the next phase, to the next part of the innovation process, which is looking at the viability side, looking at the commercial side, through a human center of the perspective. And again, if you're interested about this, check out the webinar that Kenan made on the topic. Now, let's look at when to actually sprint. So there are essentially three main situations in which you might consider whether doing a design sprint. The first one is that you're stuck at a problem and the normal ways of working haven't really been successful. So you could really use the input from different departments. The second situation is that you're under time pressure, whether from regulations, from investors, from management, and you really want to show some results fast. Whereas the third situation, it's about starting a big project and you just want to test if the ground is solid before you invest all that resources or you want to show some quick validation, some quick results. One thing to mention here is that design sprints are not optimized to test little things better. You often just want to work on projects that are uncertain, to work on things or new initiatives, for example, whatever case you might be in. There are essentially three main criteria to define whether we have a good challenge or not. The first one is that you should be focused on human behavior. And by this I mean that understanding people's problems, needs and jobs to be done are key for the project success. The second criteria is that the challenge should be broad enough for allowing creative thinking. You want to be able to have several competing solutions and not have a scope that is too narrow for one. Which also relates almost paradoxically to the third criteria, which is the scope should be narrow enough for you to be able to go deep in the testings, go deep in the interviews that you go, that you have with clients. You don't want to have to ask them about anything because otherwise you can't go and ask the whys. Why is that? Why is that? Blah, blah, blah, like this. So let's look at some examples of bad challenges. One example is increasing the NPS of our customer support. This is bad as a challenge because it's way too broad and it's also not really framed for, from the customer's perspective. NPS of which part of the support? Support of what for who? The next example would be improving the fleet management system of deliveries to customers. Why is this bad? Well, because it's essentially an engineering challenge, right? You're improving the fleet management system, but it's also not really focused on the human behavior, not really focused on the customers themselves. It's about the fleet system here. Whereas when it comes to good challenges, an example will be redesigning the onboarding experience of our B2B customers for product X. Why is this good? Because it's focused on customers. It's narrow enough for you to understand which part of the experience you should ask about, and it allows for different possible solutions. Another example is improving the accessibility of our digital support tool to the senior segment of our customers. Why is this good? Because it has a very particular scope. So we're looking at senior segment of our customers, but it is broad enough to allow you to come up with different types of solutions for improving the accessibility. And so this part of figuring out exactly the right challenge is something that happens before the sprint, as I mentioned before, and that you often do together with the consultant. But we have a tool called Scoping Canvas that essentially allows you to break down the problem by essentially asking you different triggering questions and make the whole thing a little bit more concrete. I won't go into details in this topic as well because Jimlay has written a blog post on it, so you can just check it out on our website. Now, let's look at the outcome. So what can you get out of doing A design sprint for corporates. Well, there are three main types of outcomes, three main areas, the first one being for the project. What you get by doing a sprint is essentially new insights that can inform the wider business on the customers, a solution which is invalidated by the market, concrete items to test for further development, because we're mapping all the main risks. And so this inform also the future work of the team. And it allows you to explore risky concepts in a cheap and fast way compared to just building the project, that is, for what regards the budget? Well, you essentially speed up project delivery and avoid investing in projects that do not add value. You can buy in from stakeholders for working on things that do add value actually, because you present to them and you all agree throughout the process. But most importantly, you get to kill off projects quicker, which is something that sometimes is not being talked about enough, but that could save really a lot of the resources. And finally, for what regards the team, essentially you build a customer centric mindset because you allow people, you make them used to talking to customers more often. You create a practice in which people from different departments work together and solve challenges together. But most importantly, you spark a mindset of getting things done, of solving problems. Something that we call the constructive troublemakers. People who go around the company and see problems and instead of complaining, they act on it. This is the type of mindset that you instill by doing design sprints. So finally, what obstacles to expect when you try and scale this methodology through the organization? This is relevant especially if you're new on design sprints, because if you're considering whether making one. One thing that I want to tell you right away is that doing design sprints will not solve all your problems. However, it's a very good first step. Why is it a good first step? Because you get both very tangible results and you're showing management plus colleagues and employees how to work in a different way. However, when you start and scale this process, you often encounter two main obstacles. The first one is that prototypes go straight into production. Why is this a problem? The problem is the fact that after a sprint, the solution that you built will still have a lot of unknowns, a lot of assumptions that needs to be tested. If you don't test them, it means that you're accepting them as risks, and by such you're kind of betting that you're right. This is particularly problematic if you do sprints at scale because these risks compound with each other and all of a sudden you might have projects failing very down the road after you already invested so much in building half of them. Maybe the second problem is that design sprints are either not being applied to the right project or that management is struggling in finding a strategic initiative that is worth the investment. Now, it's understandable that you want to make sure you're using sprints for the right type of projects. However, if you encounter too many of these situations, then it's also a sign that a strategic direction is missing. And by such, you're kind of doing shotgun innovation when you shoot in the dark and you just hope to catch something. So how do we solve these problems? The first has to do with the fact that after a sprint you really need to make sure that you know who will work further on testing the solution and you keep mapping assumptions. This has to be communicated, especially if there's another team taking over the product because they might not have this type of iterative way of working. If this is the case, know that sooner or later you might need to instill this way of working also there and then, of course, don't forget about viability. Check before creating the thing if there is any commercial value to be taken out of that. For what regards the second problem instead, this is actually something that I encounter quite often. We might build the skills that an organization needs to be able to execute design sprints, but then they don't know exactly where to apply them. They don't have the strategy or they don't have a methodology. This is totally fine. If you are in this situation, it just means that you started transforming the way of working from the bottom up and now is a good time to look from the top down. So what you need to do here is essentially just make an innovation strategy and have a portfolio of projects that follow this strategy that you can use for a design sprint. Now, if an innovation strategy sounds like something new to you, here's our definition. It's essentially a commitment to a common mission and a set of activities that support the growth of the organization. What is very interesting about having an innovation strategy is that sprints and other activities do inform the strategy above and do give direct feedback from the market that can shift the strategy accordingly. I won't go in depth about this either, but if I just. If what I just said sounds interesting to you, then check out the webinar that Vincent has made on the topic. And actually, if you're based in New York, luckily for you, he just opened an office there, so you can go and have a chat with him directly. He's a nice guy. That being said, in this webinar we covered what are design sprints for corporates and how they're different? When should you use it, what outcomes can you expect, and what are some of the challenges that you will face when scaling them up again? My name is Marco Barcoria and if you have further questions, doubts, hopes, fears, dreams and feedbacks on the webinar, please let me know. You can find me either via email or LinkedIn. Thank you so much for watching.