Sprint by Jake Knapp, John Zeratsky and Braden Kowitz reveals a process that focuses on making very rapid design and product improvements by focusing on a specific project for a period of one week. The book says it is a method “to solve big problems, test new ideas, get more done, and do it faster.”
The book is based on the “design sprint”, a five day problem solving process that Jake Knapp created while working at Google. His ‘sprints’ were used on Google Search, Chrome and Google X. Jake then joined Google Ventures, a part of Google that invests in startups and then grows them into successful companies. It was there that he met his co-authors Braden Kowitz and John Zeratsky, who had worked on products like YouTube, Gmail and Google Trends. Together they have run over 100 sprints with their portfolio companies and this book claims to be the distillation of those experiences.
I’ll admit I wasn’t sure if I should spend time reading this book. It was based on a method used by companies and requires a team of up to seven people. However, this includes a number of experts, including a finance expert who knows the finances of your business, a marketing expert familiar with your competitive environment, and someone familiar with your customers. If you run a solo or low employee business you are probably those experts anyway. So I decided to ignore the big company aspects and just concentrate on the process.
For many businesses the traditional method of approaching a problem is to research a market to uncover insights into the products or services they could offer, then develop and test the solutions. In the ‘sprint’ approach you design a prototype first, then test it to uncover more insights. You learn by testing rapidly built prototypes first, not by focus groups and surveys.
Esentially the first three days are spent working through ideas and solutions, day four is spent on prototyping, and on day five you stage a user test. So within one week you solve the problem conceptually and create a prototype.
The book breaks this process down further. The ‘sprint’ runs from Monday to Friday, but I’m going to present it in terms of days. Each day starts at 10am and runs to 5pm with lunch and breaks between sessions, but if you’re a solopreneur or don’t have to round up and coordinate a lot of people you can follow your own timetable.
Day 1: You start by creating a path for the sprint week. Start with the end in mind and identify the goal you want to achieve by the end of the fifth day. What would success look like? What problem(s) would achieving the goal solve? What answers do you need?
Day 2: Start finding solutions by reviewing what’s already on the table. Consider which of the existing possible solutions you can remix and improve. The core principle of design thinking is that “all design is redesign”. So each member of the team (or just you, if you are working alone) works individually to create redesign variations and then creates a rough ‘sketch prototype’ of their preferred remix. The goal for this day is to produce these sketch prototypes ready for the next day.
DAY 3: In the morning, the team (or just you) critiques the sketch prototypes, selects those most likely to succeed and decides which one to progress or which ones to combine and progress. This is done using a voting process involving coloured stickers placed on the sketches. Next you turn the winning sketch into a customer storyboard that outlines the steps from product discovery to purchase, use and disposal.
Day 4: You adopt a “fake it till you make it” philosophy and convert the storyboard into a realistic prototype that you can present to a customer and learn from their feedback. It doesn’t have to be a finished product, it’s a prototype. So you can use Powerpoint, Keynote or a word processor to summarise a digital product, or outline a sales page. You could create a prototype advertisement or even build a rough webpage to send people to. Alternatively produce some prototype packaging or a brochure related to your product or service.
Day 5: It’s test day. Share your prototype with customers and record their reactions. The authors suggest you get the prototype to five customers as that number will probably identify around 80% of all problems. Collect feedback with followup questions and combine the answers with your observations and customer comments to get an early insight into how end users will see the product or service. If feedback is favourable you can get an idea of how successful your solution might be. You’ll also get an idea of what and how to improve.
So what insights can we take from this process?
- Take time to map out the problem and decide on the goal you are aiming for.
- If you are working as a team it’s best to work independently to come up with possible solutions instead of brainstorming as a group. Then present the options, discuss, vote, then optimise.
- The quick development and voting aspects of the process stop progress being held up by endless debates and deferring decisions.
- Develop a quick and easy prototype that you can immediately show a few customers.
- Once your customers have seen your prototype observe their reactions and get feedback so you can learn, adapt and optimise.
In summary, if your product or service is fairly straightforward ‘sprints’ can help move you forward quickly and give you the chance to fix obvious issues at an early stage.
If you’re interested in taking a closer look at this process you’ll find the book at http://www.thesprintbook.com. There are also free resources, including slides and pdfs, and there’s a bonus pack available too.