Preface
There were three things that drove us to create this book—in short, we want to:
Reduce the number of products built that do not add value
Provide practical applications to the product design and development process for a range of companies
Improve the accessibility of design sprints
We’re attracted to the design sprint process because it’s a simple way for prototyping and testing just about any product in a week or less.
Like many product teams, we’ve witnessed the creation of far too many products that didn’t have a good market fit. These misfires waste money and energy—but worst of all, they waste time. For many startups, getting a product to market quickly is the difference between life and death. For enterprises, getting the resources behind the right ideas is critical—otherwise, you launch products customers do not want. Further, in enterprises, the challenge is often more complicated than just time and cash; there’s also organizational politics to deal with, as some in large organizations pursue their own agendas.
Might there be a process out there that helps control costs, reduces the waste of going in the wrong direction, and helps keep the peace? Could such a fabled thing exist in the chaotic world of product design?
Although digital products have only been with us for a few decades, they have become the dominant way we communicate and consume information. At the time of writing this book, there were 500+ new apps being released into the wild every single day! That doesn’t even include the related physical products and services that accompany those apps. At that rate, it’s hard to grasp the effort and time needed to make so many products, let alone understand the wasted hours and dollars.
You’d think that digital products would be easier to build than physical products. CEOs and founders often can’t understand why their investments in digital products aren’t paying off. The path to creating digital products appears so much easier: no injection molding, no flying to China to meet suppliers—hardly a whiff of dirty labor at all. Building a digital product is, in fact, relatively cheap and quick. But building the right product to win in the marketplace is as hard and grueling as ever. This is because the key components to digital products are not pixels and code, but rather people, time, and process. And people are always going to be complicated.
If you’re a product lead, time (or lack thereof) is what keeps you up at night. Having collectively worked on over 800 digital products, we feel your pain.
We will focus on the realities of designing digital products, and lay out a practical guide to implementing the design sprint principles and techniques. Knowing full well that there is no single way to create the perfect product, we don’t want to sound prescriptive. However, in all cases, having a disciplined and proven process wins out over winging it. This book will help almost anyone working on digital products go from knowledge to action.
Another distinguishing element of this book is that we discuss how design sprints fit into the real world. Unlike in controlled environments or case studies, things don’t always align. In the turbulent reality of our lives, it’s hard to find five days of uninterrupted time. It’s hard to get the attention of the executives. It’s hard to find testing subjects who fit your exact target profile. This book was written for the sticky, messy, chaotic world we all live in.
We interviewed dozens of product professionals just like you, and we saw a wide variety in the way design sprints are being used. In fact, no two organizations we spoke with ran them exactly the same way. Google Ventures evangelizes a five-day process, while Intrepid Pursuits does a design sprint over four to six weeks. Agencies like Fresh Tilled Soil have undertaken sprints that take up to two weeks. At the other end of the spectrum, a design sprint can be run in a few hours. But be careful of the desire to shorten it too much! At larger companies like Constant Contact, a design sprint can last from a half day up to nine days, depending on the project. The design sprint is a framework, not a set of rules. We’ll show you several ways to tailor a design sprint to meet your specific needs.
As flexible as design sprints are, we like the approach better than most design processes for one simple reason: it’s as far from the “gut feeling” approach employed by many product designers as you can get. Patrick Solvabarro, the CEO of Upward Labs, said after going through a design sprint, “These design sprints are a lot like mini science experiments.” We like that comparison. The scientific process has successfully given us a model to get our ideas out of our heads (a hypothesis) and test them against the pressures of the big bad world (experimentation) so that we can either validate the hypothesis or figure out what’s not working.
Many great scientists, artists, and engineers have built their work on the “ideate, build, test, validate” model. E. E. Lewis, professor emeritus of mechanical engineering at Northwestern University, tells the story of how science and engineering came together to create the technological world of the 21st century in his book Masters of Technology. He cites the idea-build-test-use cycle that was likely used by many famous innovators.[1] Galileo was one of the famous innovators to use experimentation to prove his ideas valid or not. As part of a now legendary experiment, he dropped two balls of different materials and weights from the leaning Tower of Pisa, and observed that they landed on the ground at the same time, which was in contrast to the conventional thinking of the time. Edison famously iterated over 300 different designs on his way to inventing the lightbulb. Picasso is considered as one of the most prolific artists, not because he produced many artworks, but because he constantly experimented with artistic directions.
We think it’s time that product teams did the same.
This process won’t prevent failures, but it’ll help your team identify them quickly and move you forward to the next breakthrough. There’s no process that will prevent mistakes. In addition, we’re not looking to eliminate mistakes entirely. Failing faster is a part of the process. The design sprint process gives you “bounce back” power. By providing almost immediate feedback, the design sprint allows you to determine if a proposed direction is likely to lead to failure, and if so, can help you to find the path to success more quickly. You might fail a few times, but you’ll have the tools to get back up and tackle the next challenge.
Design sprints are a great way to make sense of the complicated design considerations. Translating the objectives or problem into a narrative and then physically crafting potential solutions is a powerful way to make customer needs and desires visible and visceral. Connecting these customer stories to practical and emotional user feedback via testing generates a road map that becomes the path for future design and development work.
Who This Book Is For
We interviewed CEOs and founders of startups, CTOs, product managers, product owners, VPs of product management, and lead designers. We asked them what worked in their product design cycles, and what didn’t. They told us how they structure teams and keep people focused. What we learned is that no two design sprints are exactly alike. We have included their perspectives here so you can learn from varied experiences in driving product development using the design sprint approach.
Very often, the person driving the design sprint won’t be a senior executive. If you’re a product manager trying to get the CEO, CMO, and key stakeholders to give you up to five dedicated days, you’re going to need more than a nice smile. Finding support for a design sprint requires that you communicate the value of the process and outcomes. The three greatest values we often see are the alignment of a team around a product concept, the reduction of resource expenditure, and the validation of an idea from a customer’s perspective. By their intense nature, design sprints spur action.
Who Are We to Tell You?
Well, we’ve been in your shoes. In many senses, we still are! After many years in product management, C. Todd ran the same sequence of activities during his time as a consultant for design-centric organizational change consultancy XPLANE, as well as his consulting agency, CATALYTIC. In his current role as Innovation Architect at Constant Contact’s Small Business Innovation Loft (InnoLoft), C. Todd guides both internal Constant Contact teams and InnoLoft startup residents through design sprints to gain clarity, solicit customer input, and define design direction for their products. He has lost count of how many design sprints he’s run to date.
Richard leads a team of senior design strategists and personally runs design sprint sessions with his clients at Fresh Tilled Soil. The team works with clients ranging from Fortune 500 corporations such as Intel and Staples, to venture captial–funded startups and emerging businesses. The design and development team at Fresh Tilled Soil has run over 50 sessions using the design sprint approach.
As a Director at thoughtbot, Trace has led the company’s NYC office and has attended and facilitated a large number of product design sprints to ensure projects start with enough initial validation. Collectively, designers and developers at thoughtbot have run hundreds of design sprints, and share their experiences in an open source repository on GitHub.[2]
How We Wrote This Book
A book about design sprints should be written...well, like a design sprint! We had to solve a large, complex problem in a timeboxed manner. Creating a book with the tools you’re writing about keeps you very in tune with the benefits and flaws of the methodology. The design sprint forces a concept to become a reality in a few intense days, and this book was born from an equally extraordinary multiday session.
Our initial hypothesis was that product people need a guidebook to design sprints. After all, if we heard rumblings from our peers, partners, and clients, then this would be worth the investigation. We included as many viewpoints as possible from those who manage digital products and/or consult for them, including product managers, product owners, product designers, CEOs, CTOs, and vice presidents. Four intense days of writing produced a prototype draft of the book that we were able to share with our peers. That prototype was the first iteration of the book you are reading today.
After that initial four-day effort, we reviewed, revised, and continued with our interviews. We secured a contract with O’Reilly to bring this knowledge to the masses. Richard and C. Todd even arm-twisted Trace to visit Boston a few times. We wrote, ate, drank, wrote, slept, and wrote some more. We then held remote pair-writing sessions to refine the output and had one final “book sprint” to finish it all off. And really, is it ever finished?
How This Book Is Organized
This book is divided into two parts: the first three chapters cover the basics, including some background information, and the benefits and limitations of design sprints. This part also looks at a few different ways to incorporate a design sprint in your organization by showing many ways we, or others, have implemented them. The next chapters in the second part cover the details of how to run a design sprint yourself, with each chapter outlining the crucial steps from planning to execution to follow up.
Part I, The What, Why, and How of Design Sprints, includes the following chapters:
Chapter 1, What Is a Design Sprint?
Before we get into it, let’s define what it is, and talk about where it came from.
Chapter 2, When (and When Not) to Do a Design Sprint
Here we’ll review the reasons to do a design sprint (as well as reasons not to do one).
Chapter 3, How to Approach Design Sprints
We’ll address the flexibility of this framework by showing you variations on the typical five-day design sprint, including sprints as short as three hours and up to as long as four weeks.
Part II, How to Design Sprint, includes the following chapters:
Chapter 4, Before the Design Sprint: Make a Plan
We’ll get you ready to go with topics such as: What information will you need? Who should be there? Where will the design sprint happen? How long should it be?
Chapter 5, Phase 1: Understand
This phase is about identifying and clarifying the problem at hand. You’ll get the background on your users and identify their needs and workflows, so that you can set yourself up to create a solution.
Chapter 6, Phase 2: Diverge
Through collaborative brainstorming and sketching exercises, you’ll explore a range of possibilities that solve the problem you’ve identified.
Chapter 7, Phase 3: Converge
You’ll distill your large number of ideas into one or two solutions to move forward with and test.
Chapter 8, Phase 4: Prototype
We’ll talk about a number of ways to bring your solution to life and get it in front of your users.
Chapter 9, Phase 5: Test
Here’s where the rubber meets the road and you test what you’ve created with people who would use it. We’ll talk about how to run your test and interpret the results.
Chapter 10, After the Design Sprint: Capture, Iterate, and Continue
You’re done with the design sprint, so what’s next? We’ll talk about ways to integrate the output and outcome into follow-on workflows such as Agile/Scrum, follow-on design exercises, or other methods.
Acknowledgments
We’d like to thank everyone at O’Reilly: Nick Lombardi for bringing us into the mix, Angela Rufino for editing the heck out of us, Edie Freedman for her design direction, and Dellaena Maliszewski for all her marketing help.
Our technical reviewers, Keith Hopper, Scott Jenson, Harry Max, Joe McNeil, and Dan Saffer, provided critical feedback that was incredibly helpful in shaping this content.
Our colleagues, Alicia Chavero (h2i Institute) and Steven Fisher (NetApp), also commented on a few chapters for us.
The support from our companies was fantastic. Huge thanks to the Fresh Tilled Soil team: Michael Connors for mocking up the design of the book and dealing with C. Todd’s numerous cover concepts, Mark Grambau for his mad illustrations, and Chris Wilcox and Alex Stetson for their marketing brilliance.
Thank you to the team at Constant Contact’s Small Business Innovation Loft: Andy Miller and Laura Northridge for their support of C. Todd writing this book. Innovation Catalyst Ethan Bagley for his help in reviewing our first prototype, which we made in Northampton. Innovation Catalysts Jill Starett and Kayla Doan, who were a delight to train how to run design sprints. Training Jill, Kayla, and Ethan was a big help in refining the methodology, because when you have to teach something, you must know it inside out. From Constant Contact’s User Experience team: Damon Dimmock for his wisdom on how design sprints integrate with Agile. Michael Kennedy, Cay Lodine, Tom Gallo, Sam Roach, and Scott Williams for being amazing designers and researchers who participated in many design sprints. From the Constant Contact corporate team: Erika Tower for her help in navigating the internal public relations and investor relations, Jason Fidler for his help with external public relations. And finally, Vice President of Product, Piyum Samaraweera, and Senior Vice President of Product, Ken Surdan, for their willingness to embrace new ways of approaching product design and development.
Many thanks to thoughtbot’s entire design team for championing the design sprint concept, for performing so many design sprints, and for sharing your knowledge with us and with the community. A big thank you to Galen Frechette for creating and blogging about our design sprint approach, Dan Croak for distilling that and placing it front and center in thoughtbot’s playbook, Alex Baldwin for his thoughtful history of the design sprint approach, and Andrew Cohen and Corwin Harrell for a shining example of how to iterate to turn things around when users didn’t want the first thing we came up with. A special thanks to Kyle Fiedler who distilled and open sourced our methodology so people can follow it to do their own design sprints. A big thank you as well to our clients who shared their stories and materials, especially Character Lab, whose well-run design sprint turned into a big win.
To all the people we interviewed, thank you so much for your time, willingness to be interviewed, and for sharing your experience with us:
Matt Bridges at Intrepid
Heather Abbott at Nasdaq
Steve Fisher at NetApp
Patrick Solvabarro at Upward Labs
Marc Guy at Faze-1
Scott Jangro at Shareist
Damon Dimmick at Constant Contact
Brian Colcord at LogMeIn
Dana Mitroff-Silvers
Karen Cross and Jurgen Spangl at Atlassian
Larissa Chavarría at The Advisory Board
Rie Yamaoka at Truila
Alex Britez at MacMillan Education
Dan Ramsden at BBC
Alok Jain at 3 Pillar Global
Seth Godin
Ben Ronning at Tradecraft
Andrew McCarthy at Red Radix
Alan Klement at ReWired
Alex Nemeroff at Dynamo
Ariadna Font Llitjos at IBM
Finally, we’re hugely appreciative of our families and significant others. Without your love and support, this book would have never happened.
And finally finally, we’d like to thank the Academy. We don’t exactly know who or what this Academy is, but we hear them thanked all the time. So thank you, Academy!
[1] E. E. Lewis, Masterworks of Technology: The Story of Creative Engineering, Architecture, and Design (Amherst, NY: Prometheus Books, 2004).