Design sprint promises in just 5 days you can explore a problem domain, zoom in on the riskiest assumptions, lateral innovation, creative solutions, prototyping and learning from real user reactions. Really? Aren't we going to cut a lot of corners if we try to do all that in 5 days? Will we really deliver validated learnings? If its that great why isn't everyone doing it?
I took the Tes product team to Mind The Product conference 2017 in London where Jake spoke on design sprints. After having the design sprint explain to us, we were inspired and wanted to try it out. We read the book and planned our first design sprint to kick off the following week.
We picked one of our big product strategic bets where we had a plenty of known unknowns. We recruited a cross departmental team (including the CTO and CEO), cleared out 5 days in the calendar, purchased a heap of healthy snacks, bought a Time Timer and kicked off the first design sprint at Tes. I blogged every day to share our learnings of the process, below is a summary and links to the posts on medium.
Day one rocked, but the team and I were exhausted. As facilitator I made a few mistakes and would do a few things differently next time like:
- Less time arranging HMW notes
- Group HMW notes but no titles for HMW
- More time to talk decision maker through the HMW.
- Charge my Fitbit (my watch) so as facilitator i didn’t have to ask what the time was !
Day two looked on paper like a pressure pot doomed for failure. I was not convinced that 2.5 hours of unprepared, on the fly lightening talks was going to do anything, but put pressure on individuals of the sprint team. Could we really fill 2.5 hours up with useful talks? I was so wrong, this process was very valuable. The big ideas captured on the whiteboard provided lateral innovation and helped understand our problem at a different perspective.
The four step sketch was perhaps a tad basic for the creatives in the room but empowered everyone to produce a solution sketch. Personally I really liked each step, specially crazy 8s.
Day three was a day of decisions. The day started with the nervous process of simulating day two’s solutions, would they be any good? The speed critique process was very efficient and supported the decision makers. By lunch we had chosen 3 ideas to prototype and the entire team was behind the choice.
After lunch was a stream of micro decisions as we built out the storyboard for our prototype. This was tough on the facilitator to keep the energy in the right direction and I made the mistake of a facilitator getting over involved. By the end of the day we had a storyboard.
Day four we built a prototype in 6 hours. This was an exciting day, the sprint team was eager to turn the storyboard into a prototype. As the facilitator I made quite a few mistakes on day 4. We chose to ignore the advice of using Keynote, instead we opted for Marval and Sketch. I forgot project management techniques and known gotcha’s as a symptom of overly focusing on the design sprint book. We built whole page in sketch when we should have built page components in sketch and let the stitcher combine them in Marval.
The day became high pressure, frustration level grew, a few people had to put in extra effort and an super intense workrate. In the end we went home with a prototype built and ready.
Day five, the day of reckoning. I was nervous would the investment of 40+ man days, including two of the exec, turn out to be a waste of time? We felt a great sense of achievement, but would users give us valuable reactions? We had a few issues, some technical problems, testers not turning up and we forgot to take users to one of the screens.
At the end of the day, the team including the CEO, was in full agreement. We had learned lots. We had clear patterns that gave us answers to our questions. We understood our users around this problem domain with far more depth. A number of previous perceptions were changed. The week as a great success and the product manager knew exactly what to do next. The problem was a big one, it was still a huge challenge but our odds at tackling the right bite sized chunk and winning had improved dramatically from the start of the week.
So to answer the question at the start of this post, “design sprints, should you bother?” — yes you should!
I can only assume everyone is not doing it because there is fear. Its a big risk to initiate a new process, specially one that cuts across multiple departments and asks for the commitment of an entire week. In our company booking a meeting room for an entire week was a mini challenge all of its own. My advice is get over the fear. Make sure you pick a really big, scary ass problem that keeps you and others awake at night. Then go for it.
You can’t lose, if your prototype is hated you still learn so much and save the company millions of pounds (or dollars) from building the wrong thing. My advice is to make lot of noise internally, go big. Everyone was asking the sprint team at lunch how it was going, what were we building, was it a secret, how could they get involved. Now when we run our second design sprint it will be easier to recruit a team, easier to book a meeting room and easier to clear calendars. Hopefully my lessons from this one will make our second one even more valuable.