Erika, thank you for the snake oil origin story- didn’t know. Love that stuff.
I kind of agree (for sure used to) with Erika but have come to understand situations where Sprints are an appropriate process. Consider my input a little perspective to add to this discussion.
I’ve been in the design field a long time, at IDEO for over 20 years and now inside a design group within a large organization.
I was at IDEO when we did Deep Dives like the one made famous on Nightline in 1999 At IDEO I’ve also planned at least two of what I/we called sprints- two week mini-projects. Until I heard of the GV Sprint, I wasn’t aware of IDEO as one of the sources of the Sprint structure that GV is now publicizing but IDEO’s a big place and lots of people are doing lots of cool things. When I left IDEO in 2014, as far as I know (from my vantage point in IDEO Boston) Design Sprints weren’t highly formalized, publicized nor promoted- they would have likely been exceptions or compromises- not a replacement for a real project, but a cost effective effort to see if there was a There there.
I suggest the curious amongst you read the Knapp Sprint book if you are interested in the GV team’s perspective. They make their point that a Sprint is good for three reasons- 1) You soimply don’t have time to do anything else (yes, it’s better than nothing), 2) you are just stuck in some way that your current team/process just can’t unstick (ok, perhaps any team can get stuck), or 3) you are embarking on something so big, you think it prudent to “dip your toe” in to see what’s there- water, molten magma, kittens, or those fish that do pedicures. (ok, like a rough prototype project). I’d add 4) If your team doesn’t have any affinity for gaining user empathy on its own nor iterating on prototypes nor moving quicly through milestones with discipline (because Sprints are Reader’s Digest version of all that.) So it’s kind of design wake up call.
First opinion- A Sprint is no substitute for a design team doing real design work, starting with figuring out who they hope to serve, then user empathy work, then synthesis, solution generation, prototyping, technology and business design innovation. The whole spiel. If you have time, money and a design team to do this, and you need to innovate to move your company forward, do the real thing. A GV Sprint does not replace a real cross-disciplinary, phased design project, but it’s oh so much cheaper, faster and “controllable”. And you can’t do very complex things in a sprint and you can’t build a full design project by stacking sprints. They are intense, focused one-offs.
Second opinion — Google Ventures is investing in many ventures. They are playing a numbers game and trying to get the most for their investments. They invest in startups and my guess is (I’m not a student of their business) those are predominantly tech inspired efforts rather than human desirability need-inspired efforts. So they are dealing with teams of people who like working together, and are mostly focused on some IP and finding some application for it, or maybe solving some specific problem. They may not have design teams, or have any sense of user empathy, or rapid iteration. For GV, a one-week design sprint for all of their ventures raises the chances that any one of them (not all of them) will be successful, and that’s the goal for Ventures. It’s all about percentages and efficient use of money, not high quality in any particular area. For a company that wouldn’t ever put anything in front of a user, a sprint can be a dose of what they are missing. So it’s more cost effective than having each venture hire a design group and for sure better than nothing. Perfect for GV to apply to their portfolio.
Third opinion- Here’s a super simple comparison of the differences between the IDEO Deep Dive and the GV Sprint. A Deep Dive starts with users, the GV Sprint ends with users. The classic IDEO Deep Dive (which is a loose thing as all IDEO processes are), started with very fast user empathy, the GV Design Sprint starts with subject matter experts and ends with user testing of a prototype. That feels more like Lean Startup process than Design Thinking mindset. So a Sprint is a good check to see if you are right or wrong (like Lean) but it really doesn’t tell you much about where to go for more “rightness”. It feels shallow in insight to me.
Two projects I planned at IDEO we called “sprints.” But that was mostly to remind the client and our team that they weren’t just inexpensive design projects. They were two-week, short explorations of a technology space for a long term client to better understand the opportunity space. They did NOT include user empathy nor testing. That was for later for this project. For all I know, other teams did 2 week sprints that were ONLY empathy based, little prototyping.
I was part of two GV sprints in my current organization. One Sprint was injected into a short timeframe to get a new product out in beta by a certain calendar date, allowing time for a lengthy pre-defined technical cycle. We had only so much time to try to crack a particular usability/understandability nut in a short time. So the GV sprint informed the design team for an aspect of the product and fueled a few more weeks of design work before an MVP was pushed out. It was better than nothing, not Innovation nor even innovation, though, just some quick design iterations.
The second sprint was thought to be in similar situation to the above- we had developed a set of optimizing algorithms that we wanted to make available for end users. The GV sprint exposed the complexity of getting all the data into the system as well as how complicated it was to explain what was going on to the user. But it wasn’t long enough to actually figure out how present it all, how to design the experience. This had value to the entire team, and it happened quickly. But even for a tool that seemed simple, it was much more complex than a Sprint was able to handle. But the Sprint sobered people up such that this potential solution might get more attention and resource in the future. So it was a good build to learn experience, but not how we had expected.