Design Sprints are built for purpose. The process by its nature forces the team to focus and act decisively. There is a set endpoint which is the result of testing something with a relevant audience. Therefore as a project sponsor you can be guaranteed an outcome. We have found they are best suited when the stakes are high, there isn’t much time, and there is a high level of uncertainty.
The tangible outcomes of a Sprint include are not exclusive to —
- An artefact (a product/service prototype) – to be used beyond the program to demonstrate to stakeholders.
- First-hand customer knowledge – this may have been the first time that some of your team would have spoken to your customers. An often tremendously powerful moment for people.
- Alignment from your business units – you get early buy-in from relevant stakeholders and they have ‘skin in the game’ in the direction and outcome.
Why are there many different forms of Design Sprints, and is there any difference between them?
This is super confusing for most. Especially if you aren’t on the ‘inside’ by being part of a Global Design Sprint community where this is often a source of debate. This is arguably the crunchiest bit of the article. As no doubt, it will cause the most conjuncture from the Design Sprint community.
If you are outside of the community you may be confused when you see version 2.0 or 3.0. Don’t be alarmed. These alternative versions aren’t a radical departure from the original program. They are merely refinements that both still hit the same beats as the original. The difference in approaches standardise a shorter four-day version and include more rigour either side of the main program to ensure success; that the group are solving the right problem, with the correct people and that there is the opportunity to refine the prototype for a greater outcome.
We’ve found adding more rigour upfront with Problem Framing is a good thing. There is nothing worse than being into the second day when the pin is pulled because the focus of the Design Sprint isn’t relevant to the broader organisation challenge or strategy. Also, by including an extra round of refinement (Iteration Sprint) after the program affords the group an opportunity to quickly iterate and refine before presenting it to test subjects.
Then at either end of the scale are the ‘purists’ and Google’s Design Sprint Practice. The former being practitioners that won’t deviate from the book. They believe in the pace and process and stay true to how it was originally intended. Whereas Google is more adaptable and pragmatic in their approach. They scale the length of the process depending on the problem and design maturity of the team.
At this point we’d like to state for the record we have never run an identical Design Sprint program. We’ve had to continually refine the framework to ensure it is adaptable to suit whether the challenge is related to a business process, strategy and future vision, product, service, or even a theatrical performance. As a rule of thumb, we won’t deviate from the program’s five-phase framework of —
- Understanding the challenge.
- Ideating on solutions.
- Deciding on a path forward.
- Building a prototype.
- Testing to learn and validate.
Regardless of your approach, in layman’s terms, it is still referred to as a Design Sprint. Let’s be honest, if you don’t focus your pitch on outcomes and benefits you’ll be shut down by the fact you need to allocate days and resources. Project sponsors and leadership aren’t concerned with the name or the version of the program, they have a budget, a timeline and are juggling stakeholders calendars. They have trust in the process and the Facilitation Team. It is our role to guide them to an outcome that will allow them to progress.
How does the Design Sprint fit into the bigger picture of a production process?
This is an interesting one. It is important to set expectations early as the Design Sprint is not a silver bullet. It is part of a bigger picture. We’ve helped organisations come unstuck in regard to knowing where to start (see here) to taking a leap into the unknown to discover if the risk will be worth the reward (see here).
We do impress on organisations that it is important to plan ahead with the simple question, ‘what’s next?’ This directs the project sponsor’s conversation to whether outcomes will be further validated by checking feasibility and viability for the business. Or if the outcomes of the Sprint will initiate and prioritise adjacent projects on the roadmap. What is critical is that there is a ‘next’. We’ve found a great hack to keep momentum is to create a ‘28-Day Later’ plan. Rephrasing insights from testing into task categories, assigning project leads and major/minor milestones will pass the baton of accountability. The RACI Matrix is a great tool to accomplish this.
There are also the hidden benefits we’ve written about previously about the program being a Trojan Horse for bringing people together and being a device for building team camaraderie (read more here).
Do you need formal training to facilitate a Design Sprint?
