A meeting with Jake Knapp, author of Sprint.

I had many reasons to want to meet Jake Knapp of Google Ventures, while I was in San Francisco courtesy of TRC Media's Cross Creative Program:

  1. He's the author of Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days, a process that we have used and abused at CreateFuture to collaboratively solve creative challenges with our clients at Expedia, Prudential, Hymans Robertson and SCUF Gaming.
  2. As a designer at Google Ventures, he works with a portfolio of 350 start-ups at the cutting edge of the tech scene.
  3. He claims to be among the world's tallest designers. At 6'6" myself, I had to see how I measured up.

We met Jake at Google Venture's offices on Embarcadero, overlooking the Bay Bridge. Jake was in the middle of not one but two Sprints, something he was quick to dissuade us from attempting, but was gracious enough to spend 30 minutes fielding our questions. The following is a write up of my notes from the chat, and contains some (hopefully) useful insight and practical advice if you run or are considering running Sprints yourself.

Jake works as part of a small design team at Google Ventures that support all of their 350 investments. The team is made up of one design researcher, one producer and the rest are product and interaction designers. He explained that it was this need - to be able to quickly and effectively support such a wide range of issues with only a small team - that has helped hone the Sprint process. When they are introduced to a new company, they immediately seek to increase the value of their investment by helping them quickly answer their biggest blocker, or removing the greatest uncertainty from their business. The tendency of most founders is to want to get their product out into the real world, collecting real data at scale. Even if building an MVP, building something real is slow and costly and possibly predicated on a false assumption. The Sprint process, if you're not aware, is a 5 day process to develop and test solutions without (really) building anything. The process needed to be adaptable to a wide range of projects and easy enough for clients to run the second or third sprints, in whole or in part, on their own. In this way, a small team is able to offer design support to as many teams as possible. Jake described Sprint as a recipe, a repeatable process so designers need not reinvent the wheel time and time again.

With hundreds of Sprints under his belt, and with thousands more being run around the world (many of which are documented on Sprint Stories), we were interested in how, if at all, he might iterate the process in Sprint V2? The answer was that there may be some tweaks, but the core process wouldn't change a great deal. One user had shared an interesting way to draw storyboards and journey maps that Jake had tried and liked which might make it's way in. Other than that, the core 5 day process had stood up to everything thrown at it and was tried and tested. 

Which led us to a couple of conversations around the rigidity and flexibility of the process. As an aside, one of our party, from Bemo, had created an Alexa Skill to facilitate the Sprint - which forced a rigid process. You can't beg Alexa to give you another 10 minutes of ideation. Several of the team had run Sprints, and all of us had broken it in some way - either building in up-front research, or taking 2 or 3 days to prototype. On these matters Jake was surprisingly pragmatic and undogmatic. The one-day prototyping rule, for instance, is there to stop you investing too much time in an untested idea - but if you're on Sprint 2, and feel the need warrants it, by all means spend a little longer prototyping. 

Regarding up-front research, this was a criticism of mine of the process - that the voice of the customer is absent at the start of the week. To counter this, we have been including customers as Experts on Day One. Jake's UX Research Partner Michael Margolis, will often conduct some up-front research to feed into the Sprint - and this research is structured specifically to support the Sprint process, following a typical funnel and helping to draw out the customer experience map on day one. 

With time running out, we fired a few rapid questions:

How to deal with HIPPOs: Make them work harder than anyone else! Meet the standards expected of the Sprint and don't allow them to break the process

How to deal with people who insist they aren't creative / can't draw: Show the expected outputs up front and repeatedly. On Tuesday morning show the 3 step solution sketch again, so people know what format they are expected to present their ideas. And anything that doesn't fit the format (flow charts for example), goes in the bin.

How to deal with a closed mind - the client who 'knows' what the outcome will be: Don't be afraid to pull the eject lever. If the client knows what they want, then take it out of a Sprint and just design it for them. But remind them that going through the Sprint can yield some surprising solutions, and may also show them that their idea possibly isn't the one. 

Finally, we asked Jake, having worked on so many Sprints, and seeing so many companies come through Google Ventures on a weekly basis, what's exciting him at the moment? "Healthcare - without a doubt. The American healthcare system needs help, and the connection between technology, our evolving understanding of how the body works, is very exciting. It's a hard but meaningful problem to solve: regulation is hard, insurance is complex but there are some exciting developments to work on". 

And with that, we said our goodbyes and Jake headed off to work on not one but two Sprints. But not before stopping to take a photo with the team. In which, unfortunately, you can see he has a good inch in height on me. Damn it. 

 
 
Nathan Fulwood