Sprints are commonly known as a cycle of work that has a measurable outcome and follows a framework and methods that can set teams up for sucess, wether it be design thinking or development. A design sprint is vastly different from the sprints we are used to from agile development. It is a five day process for answering critical business questions through design, prototyping and validating possible solutions – ideally with real customers. It brings together a cross-functional team that can bring in their expterise while focusing around the problem to solve at hand.
Why run a sprint?
Developing entirely new products or game-changing features isn’t an easy task. The greatest risk is that users don’t find our solutions accessible or desirable. This is where a design sprint comes in – it is the ideal tool kit to help all stakeholders and their teams to align and test assumptions in a short amount of time. The sprint enables us to validate with real customers at the beginning of the product development process, setting the team up for long-term success.
If you have a problem to solve, the design sprint framework is very powerful. In contrary, the usual approach teams take is building a solution – meaning they spend design and development resources on a longer timeframe than necessary. Only after launching the initial idea gets validated: Does this solution solve the problem we framed in the beginning and are customers actually in need of what we built? Especially for early startups, a setup where time and money is very important, this can be very dangerous. Validating the solution before building means learning before launching, which can be a valuable asset.
When to do a Design Sprint
While the above is a great framework, it is important to know when to run a design sprint and when not to. It is best utilised when you need to answer a critical business question – the Design Sprint will allow you to get answers.
Before you get all the right people in one room, you need to ask: Is this is a problem worth solving? Only then does it make sense to follow up with solution validation.
Before the sprint starts, we decide what challenge we are trying to solve throughout the five day process. Then we try to figure out the right team, the right place – and the right time. The sprint usually consists of a facilitator and experts from our team, a decider that makes all the final decisions on your end and your team of experts that know the problem in and out. Ideally we bring in your end customer too.
What you will get
- Product Vision
- MVP Requirements
- User Journey Map
- Product Prototype
- User Test Results
- Solution Validation