Check out ‘Sprint’ (and go behind-the-scenes with Slack)
My friends at Google Ventures have just published a new book called Sprint. I’m really excited for this to come out, as I considered one of our best-kept secrets, something I know the entire startup ecosystem can benefit from. Not just our portfolio companies.
What is Sprint? In short, it’s a refined five-day process for building and testing products. A lot of it revolves around using structure to cut past abstract debate, enabling you to build and test your products faster.
Here is a great excerpt from the book, showcasing how Slack used the GV sprint process to decide between two competing ideas. Enjoy.
From SPRINT (Simon & Schuster)
Chapter 10
Decide
You know those meetings. The ones that go on and on, wandering off on tangents, burning up time and energy. The ones that end in a decision nobody’s happy about — or worse, end without any decision at all.
We’re not anthropologists, but we have observed (and engaged in) a lot of human behavior in the office environment. Left to our own devices, we humans tend to debate this way:
Okay, we’re exaggerating, but not that much. You might recognize this kind of back-and-forth. Someone comes up with a solution, the group critiques it, someone tries to explain the details, and then someone else has a new idea:
These discussions are frustrating because humans have limited short-term memory and limited energy for decision-making. When we jump from option to option, it’s difficult to hold important details in our heads. On the other hand, when we debate one idea for too long, we get worn out — like a judge at a baking contest who fills up on apple pie before tasting anything else.
Normally, if we want the benefit of everyone’s perspective, we’re forced to endure these slogs. But not in a sprint. The sprint is our five-day process for taking any team from problem to tested solution is just a week. Mid-way through the sprint — on Wednesday — you’ll need to narrow a range of possible solutions down to the one or two you’ll actually prototype. But you won’t leave these decisions to chance. Instead, we’ve structured Wednesday’s decision-making to do one thing at a time — and do it well. We evaluate solutions all at once, critique all at once, and then make a decision all at once. Kind of like this:
Your goal for Wednesday morning is to decide which solutions to prototype. Our motto for these decisions is “unnatural but efficient.” Instead of meandering, your team’s conversations will follow a specific process. The structure is socially awkward, but logical — if you feel like Spock from Star Trek, you’re doing it right. It’s all designed to get the most out of the team’s expertise, accommodate for our human strengths and shortcomings, and make it as easy as possible to come to a great decision.
To show you what Wednesday looks like during a sprint, we’d like to introduce you to a startup. This company makes business software, but they didn’t start out that way. In fact, their first product was a video game called Glitch.
Glitch was unusual: a multiplayer game with no combat. Instead of fighting, the game encouraged players to collaborate, solve problems, and chat together in groups. Unfortunately — say what you will about society — this unusual game with its emphasis on good behavior never caught on with a big audience.
When it became obvious that Glitch wasn’t going to be a hit, the company did something strange. Instead of making a different game or closing down, they shifted their efforts to a side project: a messaging system they had originally built for their own use. The startup’s founder, Stewart Butterfield, had a hunch that this messaging system could be useful to other companies, too. So they launched it to the public, and named it Slack.
Technology companies went bonkers for Slack. A year after launch, more than 500,000 people on more than 60,000 teams used Slack every single day. For workplace software, this kind of growth was unheard of. When Slack announced they were the fastest growing business app of all time, the press agreed. Slack was growing fast, but — like any team — they had challenges.
One of those challenges was maintaining their rapid growth. Many of the teams adopting Slack were at tech companies, which are often more willing to try new software. But there were only so many tech companies in the world. To keep expanding, Slack needed to get better at explaining their product to all kinds of businesses. It was a tricky problem.
On the surface, Slack was simple: a messaging app for the workplace. But under the surface, the story was more complicated. Slack had become so popular because it changed the way teams functioned.
Teams started by using the service to send instant messages to one another, and then often abandoned email in favor of it. But Slack wasn’t just for one-to-one messages. When a team used Slack, all of its employees were in a chat room, so they could communicate as a group.
Soon, Slack replaced check-in meetings and phone calls. Teams used it to manage projects and stay up to speed on what the whole company was doing. They connected other software and services to Slack, so that everything was in one place. Slack became the hub for all of their work, and that efficiency and connectedness somehow made work feel good.
That whole story of Slack — how it provided a service that was familiar, but different and somehow better . . . Well, that story was really difficult to explain, especially as Slack expanded to new audiences.
Merci Grace, a product manager new to the company, was in charge of solving this problem. It was her team’s job to figure out how to explain Slack to potential customers. Merci decided to start with a sprint, and since GV was an investor in Slack, she invited us to join.
The sprint team included Merci, two designers, an engineer, and a marketer, along with a few of us from GV. ByWednesday morning, everything was right on schedule. On Monday, we had unpacked the problem, and on Tuesday, we had sketched solutions. Now, there were about a dozen solution sketches stuck to the glass walls with blue masking tape.
We walked around the room in silence, seeing one another’s ideas for the first time. One sketch featured a case study of a well-known company using Slack, one sketch had an animated video, and one introduced the software with a guided tour. Each of the dozen ideas for explaining Slack was different, and each had potential. It would be a difficult decision.
Luckily, we didn’t have to make any choices right away. Instead, we placed dot stickers beside the parts of ideas we found interesting, an exercise we call heat map. After a few minutes, there were clusters of dots on almost every sketch. When we were done with our silent review, we gathered into a group and discussed the sketches, one at a time. We kept the conversations short by focusing on the clusters of dots — and by using a timer. This is the speed critique.
It took just under an hour to review all of the sketches. When we were done, everyone took a pink dot sticker to cast his or her final vote. After a few minutes of deliberation, each person silently placed the sticker on the sketch he or she wanted to prototype and test — this is what we call a straw poll.
After a short discussion, the decision was turned over to Merci, and Stewart — who, as CEO, made a cameo appearance to share his opinion too. They looked at the pink stickers, took a moment to think, and placed their own “supervotes.” And with that — with no meandering debate and no sales pitches — the decision was made.
In the Slack sprint, there were about a dozen different solutions for explaining the product to new customers. Each person believed his or her own idea could work. And each person could have spent an hour explaining why. But if we had spent an hour discussing each idea, the whole day could have gone by without any clear conclusion.
Instead, we used the sprint process to reshape that open-ended discussion into efficient critique and decision-making. By the end of the morning, we knew exactly which solution we wanted to test.
Slack followed a scripted process we call “The Sticky Decision.” Why sticky? We’ve spent years optimizing our sprint decisions to be as efficient as possible. We ended up with a five-step process — and coincidentally, every step involves something sticky:
- Art museum: Put the solution sketches on the wall with masking tape.
- Heat map: Look at all the solutions in silence, and use dot stickers to mark interesting parts.
- Speed critique: Quickly discuss the highlights of each solution, and use sticky notes to capture big ideas.
- Straw poll: Each person chooses one solution, and votes for it with a dot sticker.
- Supervote: The Decider — in Slack’s case, Merci — makes the final decision, with — you guessed it — more stickers.
This sticky stuff isn’t a gimmick. The dot stickers let us form and express our opinions without lengthy debate, and the sticky notes allow us to record big ideas without relying on our short-term memory.
For a detailed guide to making Sticky Decisions on your team‚ check out Sprint. It’s an hour-by-hour practical guide to running your own sprints, and contains the full story of Slack (plus dozens more behind-the-scenes stories).
This story was adapted, with permission, from the book Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days (Simon & Schuster) by Jake Knapp with John Zeratsky and Braden Kowitz. Order a copy here.
