Problem & Context
When confronted with the challenge of pivoting an existing product, or more the underlying technology and scientific models, and move it to a new market, new problems, and a new audience, I thought it would be a perfect opportunity to test the popular method known as design sprint. We had a vague idea where we wanted to go with this lean innovation initiative but we had two different camps driving it. On the one hand we had a business user group that represented a tangible business problem and made a case to address it with some artificial intelligence (AI) and machine learning (ML) capabilities. Even though the business case was sound, they treated AI and ML as a magic black box. On the other hand we had the science and development group. Their expertise in AI and ML was obviously deep and profound, so they started their business and research case from what’s scientifically possible and technologically feasible. Unfortunately they only had a fairly limited understanding of the day to day context and reality of the business user audience and their actual problems and pain points. Bringing both groups together and align their mutual understanding of the business problem and technical capabilities for a potential solution was the minimum expected outcome for a workshop. A design sprint aimed at exactly that, but also included the development, prototyping, and even testing of a solution. That’s why I decided for a design sprint following the book and methodology as developed and described by Jake Knapp from Google Ventures.
We run our first sprint in four days instead of five, as I could not get the entire group together for a whole week. I shortened the last 2 days into one which was a bit too short for both, the prototyping and the testing. I learned to insist on the full five days to get the most out of everybody’s time. However, even with the four day version we run through all steps of the sprint as described by the book & website and summarized in the free checklists. This is a rough overview from GV on what to expect in a design sprint:
Monday – Make a map and chose a target
Monday’s structured discussions create a path for the sprint week. In the morning, you’ll start at the end and agree to a long-term goal. Next, you’ll make a map of the challenge. In the afternoon, you’ll ask the experts at your company to share what they know. Finally, you’ll pick a target: an ambitious but manageable piece of the problem that you can solve in one week.
Tuesday – Sketch competing solutions
After a full day of understanding the problem and choosing a target for your sprint, on Tuesday, you get to focus on solutions. The day starts with inspiration: a review of existing ideas to remix and improve. Then, in the afternoon, each person will sketch, following a four-step process that emphasizes critical thinking over artistry. You’ll also begin planning Friday’s customer test by recruiting customers that fit your target profile.
Wednesday – Decide on the best solution
By Wednesday morning, you and your team will have a stack of solutions. That’s great, but it’s also a problem. You can’t prototype and test them all—you need one solid plan. In the morning, you’ll critique each solution, and decide which ones have the best chance of achieving your long-term goal. Then, in the afternoon, you’ll take the winning scenes from your sketches and weave them into a storyboard: a step-by-step plan for your prototype.
Thursday – Build a realistic prototype
On Wednesday, you and your team created a storyboard. On Thursday, you’ll adopt a “fake it” philosophy to turn that storyboard into a prototype. A realistic façade is all you need to test with customers, and here’s the best part: by focusing on the customer-facing surface of your product or service, you can finish your prototype in just one day. On Thursday, you’ll also make sure everything is ready for Friday’s test by confirming the schedule, reviewing the prototype, and writing an interview script.
Friday – Test with target customers
Your sprint began with a big challenge, an excellent team—and not much else. By Friday, you’ve created promising solutions, chosen the best, and built a realistic prototype. That alone would make for an impressively productive week. But you’ll take it one step further as you interview customers and learn by watching them react to your prototype. This test makes the entire sprint worthwhile: At the end of the day, you’ll know how far you have to go, and you’ll know just what to do next.
Our most important goal, to create a deep common and deep understanding of the business problem space as well as the capabilities and possibilities of the AI/ML technology was more than achieved. Above that, the diverse group really enjoyed participating in the workshop, learning a lot, and together took the ownership of the problem and the solution development. By the end of the week we had a massive amount of documented knowledge of the problem and solution space, interesting inspiration from competing solutions, many ideas, plenty of different solution designs, flow maps and scenarios, an interactive high fidelity prototype, and plenty of feedback from the target user community which was represented throughout the entire sprint. Running a sprint was an experiment in itself but it proved to be very successful and I will certainly repeat it with other teams for other challenges.