Stop Brainstorming and Start Sprinting

For years, people have told us group brainstorms don’t work. Here are well-written articles on the topic from 2010, 2011, 2012, 2013, 2014, and 2015. And this isn’t some recent trend — half of those articles cite a 1958 Yale study which found that individuals working on their own are emphatically better at problem-solving than teams of brainstormers.

And yet, we keep right on brainstorming. We have a problem to solve, we have a group of people, and somebody says, “Let’s brainstorm a few ideas.” We can’t resist.

Right now, you’re reading 2016’s anti-brainstorming article. But this time, you’re going to change your ways. No, really! This time, I’ve got something much better to offer you: a sprint.

But first, I need to admit something: I am a recovering group brainstormer myself.

A brief history of the design sprint

Back in 2008, when I worked at Google, I ran a lot of group brainstorms. For a long time, I’d been interested in helping people be more productive and effective at work. Structured group brainstorming seemed perfect. After all, people brainstormed already — why not teach them how to do it properly? When engineers followed the classic rules (defer judgment, encourage wild ideas, and so on), they were able to generate stacks of solutions. Not only that, they enjoyed the process.

Then one day, in the midst of a 100 person training workshop, an engineer stood up and loudly interrupted me: “How do you know group brainstorming actually works?”

I didn’t have an answer. And at that moment, I realized how foolish I’d been.

Later, spurred by doubt, I reviewed the outcomes of the workshops I’d run. What happened in the weeks and months after each brainstorm? The results were depressing. Not a single new idea generated in the brainstorms had been built or launched. The best ideas — the solutions that teams actually executed — came from individual work.

I was still convinced that teamwork was important. Teams provide a variety of skills and expertise, as well as conflicting opinions — all healthy ingredients for success. And I still believed that teams could do better work — and do it faster — if they had a method to follow. I wanted to come up with something that did work. I decided that if I wanted a great problem-solving process, I’d have to make one from scratch, and I’d have to build it on individual work.

So I started over. Teams at Google were open to experimentation (and willing to forgive my mistakes!) By 2010, I’d come up with an alternative: a five day process that I called a design “sprint”. I ran problem-solving sprints with teams like Gmail, Google X, and Google Search. This time, the process worked. The output of the sprints made it into real products.

In 2012, I went to work at Google Ventures (now called GV), and there — with the help of my partners — I’ve run over one hundred sprints with startups in fields as diverse as healthcare, farming, and robotics.

The big idea of the sprint is to take a small team, clear the schedule for a week, and rapidly progress from problem to tested solution. On Monday, you make a map of the problem. On Tuesday, each individual sketches solutions. On Wednesday, you decide which sketches are strongest. On Thursday, you build a realistic prototype. And on Friday, you test that prototype with five target customers. It’s like fast-forwarding into the future to see your finished product in the market.

Four big fixes

In my experience, there are four major problems with group brainstorms. When I designed the sprint process, I built in steps to address each one.

1. Brainstorm problem: Shallow ideas from the group

In a group brainstorm, ideas are shouted out loud, rapid fire. The goal is quantity, with the assumption that there will be diamonds among the coal. But details matter, and good ideas require time for deep thought.

Sprint solution: Detailed ideas from individuals

In a sprint, each individual considers several approaches, then spends an hour or more sketching their solution. In the end, there are fewer solutions than in a group brainstorm, but each one is opinionated, unique, and highly detailed.

2. Brainstorm problem: Personality outshines content

If somebody has a reputation for being smart or creative, their ideas are frequently overvalued. And a group brainstorm can be a nightmare for an introvert. Charismatic extroverts who give great sales pitches often dominate.

Sprint solution: Ideas stand on their own

The sketches in a sprint don’t have the creator’s name on them. And when we critique them on Wednesday, the creator remains silent and anonymous, saving any sales pitch until after everyone else has given their opinions.

3. Brainstorm problem: Groupthink

The collaborative, encouraging environment of a brainstorm feels good, but often leads teams to talk themselves into watered-down solutions.

Sprint solution: Opinionated decisions

In a sprint, decisions are made by one person: the Decider. The Decider is a CEO, executive, product manager, or other leader. For example, in a sprint with Medium, the Decider was founder Ev Williams; in a sprint with a cancer data company called Flatiron Health, the Decider was Chief Medical Officer Amy Abernethy. With the Decider in the room making all the calls, the winning solutions stay opinionated.

4. Brainstorm problem: No results

Worst of all, brainstorms result in a pile of sticky notes — and nothing else. It’s a loose methodology to begin with, and there is no map to get you from abstract idea to concrete implementation.

Sprint solution: A prototype and data, every time

The sprint process requires your team to build a prototype and test it. By the time you’re done, you have clarity about what to do next.

To give you an idea of how this works, I’ll tell you about a sprint we did with the team at Slack. (If you’re not familiar with Slack, it’s messaging software for teams.) Slack wanted to improve first-time customers’ experience with the product. In the sprint, one person sketched a very clever and ambitious solution — the kind of bold creativity we normally associate with brainstorms. Someone else sketched a traditional approach, but spent a lot of time thinking through the text and steps. It wasn’t flashy, but it was logical and clear. Out of ten competing solutions, those two rose to the top.

So what happened? Slack prototyped both solutions and put them to the test. In the end, it turned out that the boring, traditional approach was the clear winner — it actually explained the product to customers. In a group brainstorm, that idea might never have been noticed, and even if it had, it likely would have remained as a sticky note. The sprint helped Slack consider multiple solutions and make a decision informed by data.

It’s hard to stop brainstorming. I know this as well as anyone — despite all my talk, I slip into brainstorm mode at least once a week, blurting out ideas and giving a sales pitch before anyone has a chance to speak. Heck, “brainstorm” is even fun to say — it sounds smart and fast (in fact, the word was coined by an advertising executive).

But when an important challenge comes along, you owe it to yourself and your team to make better use of your time. Give a sprint a chance. You can find out more about the process by reading my book, Sprint. Check it out — and may 2016 be the last year you have to read this article.

A version of this article originally appeared on Pulse.