Problem

In large companies, problem solving happens often in traditional ways. IT is a time consuming and money draining effort. There would be no efficient way to test a product for product-market fit and so the companies would only create projects or start products when they know that the risk is not high.
‍
Specific teams in such large companies would need new ways of testing a hypothetical product, ideas coming from data or just a hunch. They would want to know fast if that potential idea is worth of investment or not. In such companies, the team would hire a product owner who would be tasked to figure out the technology and the solution based on some vague PowerPoint presentations the business people of the team have come up with.
‍
In the unlikely scenario that this new product was a failure and did not get adopted by the customers, those teams would have wasted potential budget that could lead to problems with staffing, scaling existing products, or convincing the company to fund new ideas.
Enter design sprints. Originally arrived through Google Ventures (Jake Knapp), a *design sprint* is a time-constrained, five-phase process that uses design thinking with the aim of reducing the risk when bringing a new product, service or a feature to the market.
‍
At Elisa we wanted to test certain hypotheses fast, validate them and only move to develop the ideas after that. We used design sprints in a custom way that we saw fit, and we were able to use this method a few times already to build 2 successful B2B products, plus validate hypotheses for redesigning existing products. The method is gaining momentum and so do design methods altogether.

Audience

The primary audience for the design sprints are the business people and teams that we are working with. They have a specific problem/challenge, (ie; we would like to sell product X and we need to know whether or not there is a market for that). The outcome includes research about the problem, solution creation based on the user data and the team’s expertise, early testing with selected potential customers & validating a worthy investment or not.
‍
The secondary audience is their customers and stakeholders who are affected by the results of the sprints. In all cases  the deliverables were not only demos or UI work, but a variety of deliverables such as sales decks. In fact during the first sprint we run, the sales deck became the most important deliverable for the whole group that was working for the sprint.

“The design team was able to distill the very core value of our [product] opportunity. It was great that we started this process with a design sprint instead of building software”
- Kirsi Valtari  - Head of Elisa Automate

‍Process

Pre-work
One of the most important parts of a design sprint in my opinion is the discovery (or pre-work) phase. This is the part where you have the challenge at hand and you are trying to gather as much information as possible, so that you can use during the sprint with the team to help them understand and deliver solutions that address the challenge. This part of the process involves a lot of planning:
‍
- how and when the days of the sprint are run
- how to communicate a clear schedule
- who is needed in each day and who is available
- supplies you need to run a successful sprint
- physical UX (food - coffee - music!)
- how to include key people either as participants or interviewees
- how to adjust the interviews based on busy schedules
- identify the power voter(s) of the sprint
‍
In addition, there is one very important step we include in the pre-work phase instead of the first day of the original sprint. During the pre-work phase we run the interviews and conduct synthesis of the results. The designers and researchers along with whoever else is available from the team conduct the interviews and document the results. The team gathers together and does the synthesis in the end and create affinity maps based on the results. This is one of the most vital bits of the sprint, and we know that it can be one of the most time consuming parts of the sprint especially in an enterprise setting that risk has to be carefully mitigated. Therefore it makes sense for us to break it apart and let it run within a period of a week at least.

Sprint days
‍
When we run enterprise design sprints at large organisations, the flexibility of time is of importance. Many things will not work out in a traditional strict time-boxed sprint, and it is important to make sure that we adapt the most critical parts of the process according to the time that key stakeholders are available to put. It is ok to not run the sprint in just one week and it is possible to break the days of the sprint between several weeks even.

Day 1
This version is the adapted one from the sprint 2.0. Basically the first two days of the original sprint are now squeezed into one. It is especially effective to our enterprise design sprints as we conduct the interviews before the sprint starts, and we require the whole group to be present at only 2 days.
The day consists of 2 major themes:
‍
- Mapping
- Presenting interview results
- How might we?
- Creating a map
- Long term goal and sprint questions
- Sketching
- Lightning Demos - inspirational examples that we can potentially copy with pride
- 4 part sketching - fast-paced methods of sketching aimed in quantity and not quality of ideas.

Day 2
Already in the second “official” day of the sprint, we involve the whole group and we do rounds of voting to narrow down where we want to focus with our prototyping and to produce a final solution to be tested and validated. With the storyboarding we are creating a really effective preparation on what we will be designing the next day.
- Deciding
- 4 parts voting - focused on finding which ideas, features and solution is preferred, and which direction we are going to take when we prototype
- Storyboarding
- User test flow - a new method that everyone creates a 6-step user flow
- Storyboard - a scenario that is enhanced with the most voted solution, features & ideas, and additional information from the team

Day 3
In this day it is all about prototyping therefore there is not much to be said here as the designer(s) focus on creating a realistic and testable prototype to take to our test customers. There are a couple of check-ups throughout the day to make sure that the team is on the same page, but otherwise this day involves designing and focusing on the task at hand based on the previous days’ work.

Day 4
The last day of the sprint which is now the 4th, is also pretty straightforward and it is all about testing and validating our assumptions. When this is done, a reflection or retro is organised to deliver the outcomes and solutions of the sprint as well as get feedback on how the sprint was run and what to do to improve it further.

Deliverables
‍
Deliverables can take variable shapes and formats. They can be:
- Sales decks
- Actual UI prototypes of a service
- Printed artefacts
- Dummy services
- Scenarios
- Promo video
- A combination of the above
‍
Result
‍
By the end of the sprint the “client” team has a tangible result they can ponder upon and plan on how to build it. From the first 2 design sprints we run at Elisa Automate now 2 of those are products that are built and piloted with real customers. Others include feature implementations and product redesigns that are data-informed. Design sprints are winning traction as an effective and proven way of building something without throwing development hours in an idea that we do not know if it will work or not.
‍
Key findings
- Enterprise design sprints take their own time (many times more than a week!)
- Be sensible and adapt to your people’s time schedules
- Interviews are the bread and butter and often they light the way of where our solutions should be heading to
- Embrace complexity and ambiguity as a norm and learn to adapt through it - a lot of the design sprint planning is adapting the sprint to the specific cases to fit them best
- Results can be narrow but keep in mind that a design sprint should not solve everything but you should create something out of it regardless
- Always ask for feedback from your team
- As a facilitator and designer it is hard to juggle both jobs but help as much as possible
- Share your process for critique and adaptation.
- Design Sprints are not a panacea, and should not be used for every possible problem.


‍