Sprint Book Review
Business problems excite me. I love to take on a new situation and try to solve it. In order to do this effectively, I believe it is important to continue developing different mental models for problem solving. I was recently reminded of my time in Dublin at Dogpatch Labs during a Google Sprint Design. At the time I was challenged, intrigued and excited by the methodology.
A few weeks ago, I began to look back into this problem solving method. After many Google searches, nights learning the method and scouring different sites, I came upon SPRINT written by Jake Knapp with John Zeratsky & Braden Kowitz, 3 partners at Google Ventures.
The pages of the book review a 5 day problem solving process starting from mapping out the problem needing to be solved to actually creating a prototype and testing that prototype in just 5 days. The beauty of this process is that while it is largely used in business, the framework can be applied in most areas of life during a decision making process. The book provides many different examples from Slack, Blue Bottle Coffee and Savioke.
Here is a sketch of the process:
Day 1: Create a map of the problem you want to solve by defining the goal of the sprint, and establishing the relevant questions you want to answer.
Day 2: Sketch solutions. Woah! So fast. But, yes sketch your designs.
Day 3: Decide which design wins out.
Day 4: Create your prototype from the solution you decided on the day before.
Day 5: Test the solution. Get real user feedback.
While a whole book was written on this method, I am going to leave you with my top 3 takeaways whether you are running a sprint design or you are in your normal work routine.
1. Start at the end and face your fears. Take the time to align your team on a vision.
“Why are we doing this project? Where do we want to be in 6 months, a year, or even 5 years from now?” (p.55)
Make sure the decision maker is in the room who is casting the vision and steering the ship. Share all information to get the team paddling in the right direction. Align your team.
Now that you understand the problem and are aligned, it’s important to look at all sides of the situation. Think about what needs to be done to reach the long term goals. What might happen to make the project fail? Think about the potential problems as questions (p.57). Knapp and his team talk about the “How Might We” Notes (p.75). When a potential problem comes up ask “How Might We?”. Get your brain flowing. In a Sprint Design you can take the chance to think big and take risks.
Once you define your business problem and questions that need to be answered, map it out (p.59). Who are the stakeholders, where could problems occur, how do we get from point A to point B?
2. Translate abstract ideas into solutions (p.107)
Someone might have a great idea, but until it is on paper it might be misunderstood. If 10 people interpret the simple phrase of “A sunny and beautiful day” - we might all be thinking of something slightly different. The shades of blue for the sky will vary. The sun will be in different parts of the sky. The landscape will be drastically different - for some people they would be looking at a scene of a beach, for others the mountains, yet others a forest. The possibilities are endless. Write down your idea, mock it up, create a sketch and a prototype.
During a sprint design the sketching takes place on Tuesday. The prototype is done on Thursday. But just as a sketch is incomplete, the prototype will be too. The prototype doesn’t need to be fully functioning or complete. It just needs to appear real. The Sprint team suggests building a facade. Test that facade and iterate on it. It will save you and your team precious time. Your prototype should only appear real (p.167-169). Create something so that people see what you mean. Make it clear. Don’t leave it to their imagination.
Adopt the prototyping mindset - “from perfect to just enough, from long term quality to temporary simulation” (p.168). Receive feedback at this point so you have time to iterate and create a lasting solution. Don’t wait until you have fallen in love with your potential solution and have become too invested in it causing you to ignore useful advice.
3. Don’t wait for a Design Sprint to implement these steps.
Propose a design sprint if it seems right for your team or organization. But, don’t wait for a Sprint Design to implement these ideas. Start at the end. Get to the root of the business problem. Get the right people in the room. Create images and prototypes to show your ideas. Use Powerpoint, Keynote or Google Slides. Use Excel. Use anything. Communicate your ideas. Receive feedback, iterate and deliver quality results.
There are many more practical and useful learnings packed into this book. These are just a few takeaways. Thanks for reading.