This morning, The Atlantic launched a project called the Life Timeline. It’s an ambitious attempt to sort, contextualize, and personalize more than a century of journalism. By entering her own birth date, a reader can see her lifetime through the lens of The Atlantic’s historical coverage. It’s quick. It’s surprising. It might teach that reader something about her place in the world.
What that reader may not realize, however, is that the Life Timeline isn’t merely a new way for her to discover stories — it’s also the result of a Silicon Valley innovation process only recently imported to our east coast headquarters; a process that’s revolutionizing the way we think about creating new products and shoring up our creative process throughout the company.
The sprint is a five-day process for answering critical business questions through design, prototyping, and testing ideas with customers. Developed at GV, it’s a “greatest hits” of business strategy, innovation, behavior science, design thinking, and more — packaged into a battle-tested process that any team can use.
The sprint has proven to be a powerful catalyst for concept development here at The Atlantic. More than a year ago, the site’s deputy editor Matt Thompson conceived of a tool that found a story from The Atlantic’s archives pegged to the midpoint of a reader’s life. Everyone liked the idea, but nobody was quite sure what shape it should take, or what the best way to deliver it to the reader would be.
Then, along came the sprint.
By using the sprint methodology, we “fast-forwarded” through five days of rapid learning and concepting to develop a solid theory of what the tool would be and how it would work exactly. We made some mistakes along the way (keep reading!), but we also took an idea that had been gathering dust on the shelf and turned it into the tool we love and launched today.
Why did we need it?
The Atlantic has a 160-year history of big ideas and exploration of difficult questions. In many ways, innovative thinking is already a core part of our work every day. Yet, we consistently found ourselves running up against a wall when it came to giving outside-the-box thinking the kind of time it needed to really take flight. Throughout the media industry, companies find themselves pitting small, incredibly busy teams of brilliant people against huge goals, grand ambitions, and endless task lists. With these very limited resources, how is it possible to innovate on unknowns?
For The Atlantic, the sprint has been part of the solution to that problem. One of the greatest risks in developing ambitious new ideas is that it’s possible to sink months, even years of work into what seems like a good idea, flying blind the whole time to how it will be received in the market. A sprint allows you to move directly from idea to testing, cutting out the development and launch process in order to test a concept before it’s even begun. That makes all the difference. The ability to pre-flight an idea, to understand its value before assigning strategic priority to it, is radically powerful. Even a “failed” sprint, where all of your ideas and conclusions are proved wrong, is still a huge success — that’s months of work and thousands of dollars saved from a wild goose chase.
And, in the really great sprints, you find an amazing idea and gain invaluable insights into what makes it tick.
So how does it work?
(You can, of course, skip this part if you’re already familiar with the sprint process. Really, I won’t be offended. Move along to the next section, it’s a good one.)
The sprint works by gathering a small team of smart people in a room for a full week, from 10am–5pm, and asking them to follow a rigorous process for discovering, curating, and exploring ideas. And when I say “rigorous,” I mean that they specify the size of paper and, ideally, the color of sticky dots you use, when you take your lunch break, even what kind of snacks you should be providing. (Yes, snacks are mandatory.)
The process demands some breaks from intuition and business convention, but always justifies whatever it asks of its participants with case studies from successful companies like Slack, Savioke, and Blue Bottle Coffee — or, just as often often, cautionary tales from pseudonymic companies that strayed from the straight and narrow and failed because they didn’t live up to the sprint methodology.
The benefit of this specificity is twofold: first, it works. GV is a serious investment company, and every item on the checklist is there because it’s needed and it’s worked over hundreds of successful sprints. Second, the specificity ensures that the entire team (and their managers, who are releasing them for a full 40 hours per head) that the process is on the rails.
At its core, a sprint consists of the work week broken out as follows:
- On Monday, you learn. You study the problem, set a goal, invite outside input, and agree on the landscape of the problem you’re tackling.
- On Tuesday, you sketch. Rather than group-thinking your way to an outcome, you sketch solutions individually (and no, you don’t need artistic talent) and then, counterintuitively, you don’t show those sketches to each other.
- On Wednesday, you wear pink. (Sorry, I couldn’t resist.)
- On Wednesday, you decide. You evaluate the sketches and decide on a direction to pursue for the remainder of the sprint.
- On Thursday, you prototype. You rapidly create not an actual product, but a facsimile thereof that’s good enough to elicit an honest reaction from a potential customer.
- On Friday, you test. You bring in people who are either in your customer set or as close as you can reasonably get, show them the prototype, and learn from their feedback.
Each day has a checklist of steps that break down those ambitious results into reasonable actions. If you’re interested, I highly recommend picking up a copy of the sprint book — even if you’re not implementing the process formally, it has great insights into what makes the creative process tick… and how to reinvent it.
Here’s what we learned
So we sprinted. We’ve done it several times now, with increasing success. In fact, if you’re reading this during business hours on the week it was published, I am presently in the middle of running a sprint at this very moment. But I said I’d tell you the mistakes we made, and I’m true to my word. Here’s what not to do when you try your own sprint.
- Don’t hack it lightly. Our first sprint was… well, to be honest, it was kind of a mess. We didn’t plan it far enough in advance, so we only had people for about half the week. We didn’t have conference rooms booked, so we moved from place to place like vagabonds. We ignored the entire third act of the process and put together a pitch deck instead of a testable prototype, which led to all kinds of false assumptions and downstream woe. If you’re going to attempt a sprint, I highly recommend following the process as closely as possible. It may take work to get that kind of buy-in from busy stakeholders, but changing the formula is kind of like changing a recipe for baking on the fly. If you’re an expert, it could be okay — but spinning the temperature dial on the oven rarely yields good results.
- Get the right participants. The method outlines exactly who should be in your sprint, with archetypes like “The Decider,” “The Troublemaker,” and “The Voice of the Customer.” You’ll want to take these recommendations seriously — especially when it comes to the Decider. It’s essential to go as high up the food chain as possible when running a sprint. The Decider is a key player in the process. She’ll be the one to ratify the goal, to decide on the concept to prototype, and — ultimately — to defend the decisions you made to the leadership of the company. In a perfect world, your Decider should be the person who actually makes the decisions, day to day, about the problem you’re trying to solve in the sprint.
- Don’t hand-wave the hand-off. As much as I am a deep believer in the efficacy and usefulness of this process, it’s easy to make a single, crucial mistake — bad followup. A sprint is a learning tool, a way of breaking out of stale innovation processes to see what could happen in the future, to understand your customer better. However, a sprint does not and cannot replace your time-tested product process. A sprint will educate you, but it will not magically build a well-considered product. It’s geared for speed, not permanence. My recommendation is this: when you’re scheduling the sprint, schedule a Monday meeting for the week after the sprint. In that meeting, lay out what you’ve learned and determine how to use those learnings to inform your normal development cycle. Don’t assume that you can translate the incredibly hacked-together prototype from Thursday into the actual product. It won’t work. We tried. It was bad. Don’t do it. Use the sprint as a discovery engine — then use your incredibly effective and brilliant team of experts in their everyday roles to figure out where to go from there.
The future of Atlantic sprints
We’re excited about the design sprint process as an ongoing part of our innovation cycle here at The Atlantic. I wouldn’t be preparing to lead another one as I write this if we weren’t. As long as we have big ideas with only vague ideas about execution — or massive head-scratchers we’re not sure how to tackle — the sprint process is going to have a place.
But there’s more to it than that. These sprints aren’t just about five days in a well-provisioned room with lots of natural light and whiteboard marker fumes. They’re about learning to think differently. In isolation, any of the days suggested in the process offers a wealth of design thinking and creative strategy insights. The Monday process can be executed in isolation to identify a problem and a goal. Tuesday’s sketch methodology is helpful anytime you want to break apart your assumptions about what a product “has” to be. (Trust me. That Crazy 8’s exercise really works.) Wednesday has a lot to teach about how to find the best ideas in sketches without falling prey to the wiles of a charismatic pitchman with a half-baked idea. Thursday is all about making something that’s useful, even if it’s not pretty or perfect. And Friday is a masterclass in user testing that should be brought into every project that involves human beings interacting with a thing made by other human beings.
We’re just starting the process now of learning how to bake these lessons into the totality of our process. But whether we’re sprinting in whole or in part, we’re glad to have come across this methodology. It seems to be here to stay.