Workshops as you know them are dead, long live the Sprint.
So, you have identified a need to develop something new to support your company’s bottom line. You know what the challenge is, but it represents itself as a gray blob that is hard to grasp. Also, when you ask your colleague, they are aware of the same challenge, but see it from a different perspective that isn’t really aligned with your thinking. This should make you uneasy, if you are the one in charge of the budgets. How can you make sure the development budget isn’t wasted on something utterly useless? And how do you make sure to pick the right battles and add real value to your company?
This struggle is more common than you can imagine. This relates closely to our daily work as some companies “externalize” the problem by briefing companies like us to solve their problem. From experience, I can say that answering a brief isn’t problematic, but managing all the different expectations often is. If the client doesn’t have a common understanding of the challenge they have asked us to solve, it is next to impossible to adequately meet everyone’s expectations.
Over the years, we have explored and tried many practices how to unify the thinking and get the project on the right track from the get-go. Some of these practices we have adapted from books and best practices, some we have invented ourselves. Naturally some of these practices have worked better than the others, but we’ve still been eager to find something more universal. Something that really encourages decision making and having your ideas heard instead of endless debates and wasted time.
The good folks at Google Ventures came up with “The Design Sprint”. Could this finally be the process we’ve been looking for? We decided to give it a shot and yes, we were on to something big.
We have now utilized the Sprint methodology with several of our clients, small and big, and the results have been astonishing. The structured and well documented process enables us to get more done in a single week than anything that we’ve tried before.
Without going into the nitty-gritty details, the elevator pitch for the Sprint approach is: “From a vague idea to a tested prototype in a week”.
First few things about the value that the Sprint brings to your project. As I mentioned before, all people have their own interpretation of the problem and the potential solution. Without making sure that everyone is on the same page, the project is deemed to head towards a disaster.
In many organizations, the one that yells the loudest often gets heard, while the folks less loud may not have a chance to propose their ideas. This all changes with the Sprint, all ideas are treated equally until decisions are made which ones are to be taken forward.
Once the decisions have been made on what ideas to fly with, everyone’s onboard supporting the common goal.
Refining and developing the idea into a prototype comes next and this doesn’t take weeks as it traditionally used to. The prototype is created during a single day to a level that it can be tested with real test subjects.
Having something tangible to test without using any time or resources for the product development fully supports the idea of “Fail fast, scale fast”. If the prototype ends up not performing as expected it is still easy to scrap, as the investment made is so small. On the other hand, the majority of the ideas we have prototyped, ended up being further developed after testing.
If this method is such a game changer, why isn’t everything done based on it, you may ask? Frankly, there is no other reason, except the fact that the Sprint requires a significant time investment from the stakeholders and finding such common time is a challenge. I do promise that when we find the needed time together, it will the most productive week you have ever experienced.
Questions about "The Design Sprint"? Let's talk.