A while back I ran into an article which spoke about Google Venture’s Product Design Sprint, which caught my attention. The sprint is based on Lean methods, with a focus on learning and reducing waste. It does this by giving “teams a shortcut to learning without building and launching.”
Google Ventures compresses it’s design sprint into “a five-day process, answering critical business questions through the rapid design, prototyping and evaluation of ideas with customers. The reason Google Ventures uses this 5 day (Monday-Friday) approach probably has more to do with logistical issues and cost of flying founders to their offices, and compacting everything inside that window. Introducing weekends risks spending money on unproductive hours and travel cost. Not something that is very beneficial to startups. That being said, the time constraints is one of the most important assets of a lean organization as it serves to create a sense of urgency on all involved, and results in the “fat” being cut out of the innovation processes.
Why a “design sprint”?
Google Ventures process is broken out into 5 days:
- Unpack: The process of building understanding. “Expertise and knowledge on most teams is asymmetrical: Sales knows things engineering doesn’t, customer support knows things design doesn’t, and so on.”
- Sketch: An individualize ideation approach with a focus on illuminating group think
- Decide: A democratic process of narrowing down directions that you’d like to prototype
- Prototype: Rapid creation of testable and realistic experience to use during user testing.
- Test: Showing the prototypes created to real customers in 1-to-1 interviews, and observing which ideas are winners or epic failures.
Working at a large organization that is heavy into product development, “design sprints” seemed like an interesting experiment to introduce into our process. The main issues that I was observing at my organization was products being developed with little to no customer feedback. This might have been due to a variety of reasons, like tight production cycles, odd financing models, and the false sense of certainty that experts get when producing ideas to name a few.
Large organization tend to fall prey to departmental silos. Communication across groups is really tough, and decisions tend to be made in a vacuum. Once products are complete, there is sometimes no clear metric for success. They are sometimes created as an afterthought, typically around the time an organization has a feeling that the product launch is not going as well as they though it would.
Tweaking the Process
Any good process is tailored to explicit needs of the organization it is serving. After various attempts at running “design sprints” at my organization, I’ve tweaked a couple things to be a bit more helpful to our context.
The first, and possibly most important addition to the process was the addition of an “Empathy” phase. Google Ventures may very include users in their “Unpacking” phase, but I wanted to explicitly state that the team will have an opportunity to observe many of the assumptions brought up during our initial round of understanding with actual customers.
We gave it our best effort to shout for a, now 6 day “design sprint”, but it quickly became apparent that 6 days was not enough for our context. Things like serving a multi-sided market, such as students, instructors and administrators, each with their own desired outcomes. Trying to squeeze in interviews, and other empathy exercises in one day for 3 groups seemed impossible to do effectively. Running several parallel sessions at the same time (we shoot for 7-10 of each group), gathering an enormous amount of insights, and then having share that insight with each member of the core group so everyone understands the various audience perspective is unnecessarily impossible. Instead we split this into individual days, allowing everyone in the core team to immerse themselves into each perspective. We then allow an additional day to organize all the insight into something that is manageable.
The other issue we ran into was squeezing in enough business knowledge into one day. One day consist of 8 hours, one of those hopefully including lunch, which leaves 7 hours. We do 30 minute slots for each, which if everything goes smoothly could lead to 10-14 amazing opportunities for understanding. You quickly realize however that for every hour of learning, there needs to be an hour of organization and analysis. What did they say, how did what they say relate to what was said by the previous person? What do we expect the next person to say? All important questions to think about. Furthermore, since we added an “Empathy and Customer Development” phase, what will we be asking or doing with the students, instructors and administrators that we have scheduled to talk to? Success metrics also needs to be stated BEFORE any ideas surface. Not know where you’d like to go, before coming up with a solutions, is like saying here is a motorcycle now go to Hawaii. Needless to say, we have broke this out into at least 2-3 days as well, which still feels uncomfortably short, but possible and extremely productive.
Ideation tends to fluctuate in duration. If the design sprint is focused around a complex process, which has the potential of introducing solutions across a wide variety of identified issues, then the time needs to be extended. What tends to happen is that once we’ve identified the main problems we’d like to tackle in ideation, we time block each into its own few hours, where the particular issues gets the entire team’s attention. The alternative is to divide and concur, which could result in spreading the ideas too thin in divergent activities where quantity is key. Also, parts of the process, might not get any attention at all. Another alternative is to break each issue into it’s own “design sprint”. Although this seems like a good idea, the biggest issue that I see, is that designs are proposed with narrow understanding of the entire system. In my opinion, have the team ideate and iterate with a holistic understanding works much better, and allows solutions to be a bit more seamless.
Other than those slight tweaks, and the addition of some home-brew tools, we’ve kept the intent of the original process in tact. Being about 6 sprints in, we have very positive results, and I am looking forward to iterating some more. Over the next several posts I will dig a bit deeper into each of the phases and introduce some of the tools that we’ve integrated into the process.