20 Apr Design Sprint — take 5 days to answer critical business questions
The Design Sprint (at least the one we refer to here) was defined by the Google Ventures (GV) team in 2016. Having been tasked with honing their portfolio company’s products and marketing over the years, Jake Knapp and team had developed a formula for testing and validating new ideas. Their book, Sprint, outlines this formula and it continues to be supremely useful. If you want a quick fix, they’ve outlined a summary of the process here. Ken Norton’s interview with Knapp is also insightful. Below we look at how three groups approached Design Sprints and what they learned.
The art of the design sprint. The Guardian’s digital team new the problem they were trying to solve from the outset: “getting less frequent visitors to form a lasting Guardian habit”. The Design Sprint book was already popular amongst their staff so it didn’t take much to get buy-in for the project. But they did have to be flexible in the way that they approached it. For instance, it wasn’t possible for staff to completely remove themselves from their day jobs. And they couldn’t help but create several prototypes rather than the 1 or 2 that GV recommends.
How we completed a 5-day design sprint in 3 days. Demonstrating how flexible a Design Sprint can be, the Mobile Majority worked through the process in only 3 days .. and only committed 2 hours of work for each day. The GV team might balk at the idea of running such a lean operation, but it’s clear that the team did benefit significantly from the process. They wanted to create a solution that allowed their customers, mobile marketers, to forecast how effective their campaigns would be. So they dug into the problem by looking at user needs and the business opportunity, explored an array of solutions, and finally tested their prototypes with some users.
A Google Design sprint gone wrong (and what it taught me). Being too flexible can corrupt the process. Skjoldbroder knows all about it having attended a bad Design Sprint. Fortunately she’s shared what can be learned from this experience. When you conduct your own make sure you don’t change the “assumptions, questions, goals and problems” that were defined on day 1, delegate the building of the prototypes (get your hands dirty!) or encourage any negativity within groups.