Author of the New York Times bestseller "Sprint"
Jake spent 10 years at Google and Google Ventures, where he created the Design Sprint process. He’s written two books, Sprint and Make Time, and has coached teams at places like Slack, LEGO, IDEO, and NASA on design strategy and time management.
Randy: We would like to welcome Jake Knapp to The Innovation Series. Depending on the day, you could be described as an inventor, a writer, a coach and even one of the world's tallest designers...so much contribution to the collective good. We want more. What are you putting your time into now, and where can we find it?
Jake: Haha, thank you, you're very kind to describe me that way! I _want_ to say that I've been working on a new book, because I mean to be, but actually this year I've been putting most of my time and energy into my own family. We've had some chronic illnesses and that's been where I put my attention, because of course you have to. I'm very fortunate that my work right now is mostly teaching workshops and speaking about design sprints, which allows me to have a very flexible schedule on the other days.
It's been an interesting year, and for me—somebody who talks so much about being efficient with time—it's been a good reality check. It reminds me of the importance of focusing when I get the chance, and it also reminds me how I should never think I've got everything figured out.
Randy: At GV you worked with startups like Nest and Blue Bottle Coffee, but before that, you provided design leadership for products inside larger companies like Google and Microsoft. Are there any learnings working with startups you could share with teams in larger companies to help them deliver?
Jake: The wonderful thing about startups is the clarity. Because the teams are smaller and the products are at an earlier stage, usually everyone knows what's most important and it's a lot easier to focus on that. You spend less time guessing what other people in the organization are thinking and triangulating politics. Startups aren't perfect, but they generally have less of that garbage.
If I could go back in time and work on products at Microsoft or Google again, I think the thing I'd do is be more bold, and really try to clarify down what the most powerful thing we could do with a product would be, and then prototype it, even if nobody was asking for it. I thought I was doing that at the time, but in hindsight even what I thought was bold was tempered and diluted because a) I was guessing what the big bosses were thinking, and b) I spent so much time guessing about big bosses and worrying about team politics that it restricted my vision.
So here's my advice: If you work at a big company, remember you won't work there forever. Remember that the advantage of big companies is that they can more easily reach a big audience, provided they make the right moves. Throw caution to the wind, screw what the big bosses will say, and do the boldest things you can imagine.
I mean, that and run design sprints, obviously. Lots of design sprints and lots of copies of my book, that's the key to innovation. :)
Randy: In your last Sprint newsletter you featured an article titled, How to Make Design Sprints Work at Big Companies. I've worked with quite a few large companies in a product design capacity and used exercises from the sprint book very effectively. However, I sometimes struggle to implement the unadulterated 5-day process inside the context of larger companies. Do you have any stories you can share that demonstrate how teams have leveraged (or adapted) the sprint process effectively inside large companies?
Jake: AJ&Smart have a great approach to this because so many of their clients are big companies. Definitely worth checking out their YouTube channel, starting maybe with this clip:
Randy: #TBT Please step into the time machine, set the date for October 8, 2014. On this day you published an article titled Reactions > Feedback - a really interesting take on the interpretation of observations. This article has had a lasting impact on how I approach user testing today. What is the difference between reaction and feedback, and how can we figure out where the line is between the two?
Jake: I'm glad you liked that one! I wrote a related post called Paper Prototyping is a Waste of Time, and my point in general here is that when you show customers something that isn't finished looking, they are naturally going to switch into a mode where they want to be helpful, and they'll try to participate in the creation process with you. I don't find that especially useful—that's the team's job. Not everybody agrees with me about this, and it's fine, but this is my opinion. What the customers are really really amazing at is _being the customers_. So what they can do, what I'd rather have them do, is *react* to a realistic prototype in a realistic way. That kind of reaction is valuable to the team watching the interviews. Reactions are hard to fake, so if you look for reactions, you're getting higher quality data from your tests. The creative *feedback* on the other hand... well, if you know how to deal with it, and what to do with it, that's fine, more power to you. I'm just saying I don't know what to do with it and it doesn't seem as valuable as the reactions.
Randy: Alright, back to the future. In an interview you did recently with Jason Fried, the two of you seemed to have different opinions on the value of pre-launch testing. From your experience, can you give us your take on the importance of getting customer feedback before committing to build product. This is your chance to tell Jason he is wrong btw. Your welcome.
Jake: He is completely wrong... except for the most important example, which is his own very successful company, Basecamp. :) Look, Jason makes a good point: Any test you run before you launch is only a simulation. You can't trust that data, you can only trust a launch. For Basecamp, this works out great, because they launch every 6 weeks. If company x runs as effectively as Basecamp, and has such an experienced team (I think everyone there has been working there for, like, 200 years) with so much accumulated customer insight and great product sense, then yeah, they should absolutely not test before they launch. If, on the other hand, company x is like most companies and they spend about a year acting on a hunch every time they build and launch, then if they can't switch to Basecamp's every-6-weeks rhythm, they should consider testing before they launch. They should run design sprints and, again, buy lots of copies of my book.
So I do think he's wrong in some ways, but also very right. In fact after that conversation with him, I started saying "simulation" to describe what a design sprint is. It's the perfect word for it, and I think it helps people understand what it's about. If you're going to spend a year blindly building something, should you maybe run a simulation first? Yeah, maybe.
Randy: In the beautiful homage you wrote to your father How to Live, How to Work, and How to Die you promised to do work that matters. Your work has touched a lot of people and is making a difference every day, on behalf of the design community, thank you so much and for all that you do and for being part of The Innovation Series.
Jake: Hey, thank you Randy. That means a lot. :)
Therese Fessenden NN/g, Microsoft
Brittni BoweringSPRINT Facilitator, AJ&Smart
Fabricio TeixeiraWork & Co, UX Collective
Radhika DuttRadical Product Thinking
John ZeratskySPRINT, Make Time
Tobias van SchneiderSemplice, Spotify
Jeff GothelfLean UX Author
Taylor PalmerUX Tools, Neighbor
Daniel BurkaResolve to Save Lives, GV
Carie DavisYour Ideas are Terrible, Coca-Cola
Sean AmmiratiDirector, Corporate Startup Lab at Carnegie Mellon
Justin KimePrioritzing Customer Experience
Michael ManrossWhy other initiatives get prioritized over CX
Jason FriedClustering Requests to Produce Themes
Jon ArnoldThe most meaningful 2 1/2 things in the designer/developer relationship
Gavin GregoryBringing developers into the design process early creates alignment
Aaron LerchWhy designers and developers need to invest in being equal partners
Alex BillingsleyHow to get designers and developers on the same page
Kenn Pascasio Having a shared understanding of the user
Jen BurkusGetting and Keeping Good People
Adam YaleThe outlook for product design in a remote world
Jason FriedWhy people leave and why that's ok