The power of collaborative process design: An interview with John Zeratsky

What we can learn about process design from the guys who created the Design Sprint?

There’s been a lot written about the Design Sprint; why it works, the methods, facilitation techniques and how to use Sprints inside an org but I was interested in learning more about the process of designing the process (so meta, right?) from this conversation with John Zeratsky (JZ), co-author of SPRINT.

How did he, Jake and Braden collaborate to define this way of working together — and what can we learn from them about collaborative process design for teams?

“The default processes and workplace norms are not the result of some brilliant master plan. They are just the collection of behaviors and habits that have stuck around over the years. They are accidental defaults. And you can change them!” — John Zeratsky (JZ)

Jackie: How did you decide to collaborate with one another to further define the process? What did your collaboration process look like?

In the Sprint Book, Jake writes about how he decided to start testing the Design Sprint at Google in 2009 and ran a series of experiments using the method before he joined the team at GV (Google Ventures.) His mission was to: “Make workdays efficient and meaningful. To focus on what was truly important and make time count — for him, his team and customers.”

This mission rings true for me as someone who loves making awesome experiences AND believes that the experience of making can be awesome.

How did you decide to collaborate with one another to further define the process? What did your collaboration process look like?

JZ:

In 2012, there were only two designers at GV: Braden Kowitz, our first design partner (also the first at any VC firm) and me. Our UX research partner Michael was there, too — we always referred to him as a designer, but I don’t think he liked that 😂

So, there were three of us, but probably close to 100 startups in the portfolio. We were interested in frameworks or processes that could help us serve those companies in an efficient way. We couldn’t just parachute into each startup and immediately give them the answers to their big questions. And we didn’t have time to get fully embedded, learn the business, and develop the intuition to contribute as individual designers.

When we learned about the Design Sprint process from Jake, we were really excited, for three reasons. One, it provided an engagement model for us to work with a startup for a fixed amount of time. Two, it was a recipe for helping them find their own answers to their big questions. And three, it was a tricky excuse to get them to run user research! We had all seen the power of user research, but believe it or not, in those days, most tech teams didn’t think it was a good use of their time.

On a personal level, I was really interested in the Design Sprint as a way to help teams focus together on their most important work. Over the 10 years leading to that point, I had transitioned from business owner to startup employee to big tech company worker, and watched powerless as my time went more to emails and meetings and bureaucracy than to the essential work of building a business and serving customers. I had tried to optimize around this by becoming more “productive”, but that just made me feel like a todo-list-checking robot. I loved how the Design Sprint wiped all that away and said, “let’s just focus on the one thing that matters most to our business right now.”

Jackie: What did you learn early on and how did that inform your “final” and best recipe — the one that made it to print?

JZ:

Our first Design Sprint at GV was ridiculous. It was with this struggling SaaS company, and I think we spent close to six weeks with them. It was a mess of workshop sessions, interviews with executives, prototyping, and customer testing. Their leadership was not fully committed to the process. We didn’t have clear goals (other than “make it better”). I honestly don’t know why it took so long! 😊

But still, even with all the problems, it was valuable. We got knowledge out of people’s heads and onto whiteboards. We turned abstract ideas into concrete sketches. We built prototypes in days, not weeks. And we did multiple rounds of user testing, which showed the team (and us) what customers really thought of their product and their new ideas.

In the second sprint, Michael figured out a way to recruit customers and plan user research in one week. That was a huge breakthrough, as it meant we could select the target customer on Monday and test with them on Friday!

In the first year or so, we ran Design Sprints with 23andMe, Pocket, Blue Bottle Coffee, HubSpot, and others. We quickly learned a few important lessons:

• The leadership has to be totally bought-in to the sprint project, and we need a genuine decision-maker in the room

• We have to tackle a big problem in the sprint; asking people to clear their calendars and spend five full days on a trivial issue leads to disengagement, resentment, and a lack of ownership

• Don’t spend too much time prototyping; the additional details we squeezed in rarely mattered to the big questions, and we found that more time spent on the prototype translated into less willingness to listen when customers reacted negatively (because the team got attached)

• Make it uncomfortably fast; shorter timelines helped us avoid dwelling on decisions and exposed our ideas to customer reactions sooner

Jackie: How did you know when you should adapt or change something and when you should stay true to the methods you’d used previously?

JZ:

By 2013–14, we were running 20 or 30 sprints per year. We had experimented with longer and shorter formats, and with splitting the sprint across two weeks, but we found that five days was a sweet spot: It kept the team together and focused, and it fit neatly into a standard five-day work week.

We were constantly experimenting and tweaking the process. During those early sprints, we would often call for a break, step out of the sprint room, and talk about the process itself. Jake might observe that we the conversation was getting too abstract. Maybe Braden would suggest a new group exercise we could try. And then we’d step back into the room, resume the sprint, and try it. Because we were getting in so many reps, we could afford to try lots of things.

With all the experiments, our north star was always the test at the end of the week, and the questions the startup needed to answer. I remember a lot of conversations like, “Is this really necessary to talk about right now? Is this going to help us resolve the challenge we’re focused on this week?”

Jackie: What advice do you have for teams who are collaborating to define their own ways of working?

JZ:

• Don’t be afraid to spend time and energy on the process itself. Most people are analytical and critical about their work, but when it comes to how they are spending their time, they step back and let default habits and routines take over. It’s okay to focus on the process … actually, I’d say it’s necessary to think about how you’re spending your time if you want to be effective in our crazy 21st Century world.

• Get in lots of reps. Experiment so you can improve your frameworks and models. Pay attention to what’s working and what’s not. Don’t get locked into a new model or approach too early.

• Remember that the default processes and workplace norms are not the result of some brilliant master plan. They are just the collection of behaviors and habits that have stuck around over the years. They are accidental defaults. And you can change them!