How to Solve Problems in Just Five Days

How can we solve big problems and test new ideas in just five days? If you are at all experienced in lean, you may reply, “Run a kaizen event.” By various names, the five-day rapid improvement workshop has been helping companies redesign processes and products to deliver double-digit results for over twenty years. The 2016 publication Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days was written by Jake Knapp, John Zeratsky, and Branden Kowitz, a trio from Google Ventures. The book describes the sprint as a five-day process for developing new products and new business ideas.

The book takes the reader through each day of the process with helpful diagrams, illustrations, photos, and practical tips. Here is the sprint at a glance

• Preparation: define the problem at hand, select the team, schedule people’s time, secure the room
• Monday: agree on the long-term goal, map out the problem, interview the experts, narrow the focus
• Tuesday: come up with ideas, sketch out solutions on paper
• Wednesday: select the best solutions, maintain competing ideas, make a tryout plan
• Thursday: build a mockup, build a better prototype for a trial run
• Friday: get customer feedback and data, reflect on learning, plan next steps

For anyone unfamiliar with kaizen events, they basically follow the sequence above but with a greater emphasis on fieldwork and observation of existing processes that are problematic, while the sprint leaves this until the end when the customer interaction with the prototype new product or service becomes visible for the first time.

Why five days? Why not four or six? For the Japanese consultants who introduced the kaizen event to the West, it was the obvious convenience of being able to sell five working days within a week. There would be no lost billable time as travel was left to the weekend. The rationale for the five-day sprint is not clear, and by adjusting scope, hours, and pace, it seems like it could be done in 3 or 4 days as easily. Or if necessary, even as a pair of 2-3 sessions across two weeks. One week is a neat package for a rapid improvement workshop, but not set in stone for every situation.

The authors claim that it is better to tackle bigger problems. The “big is better” message should be taken with this grain of salt. A big problem that is an aggregation of many problems, and thus complex, or one that is too big to be beyond the scope of a sprint, should not be selected. The authors’ intended message is that the topic should be big and ambitious enough to generate a sense of urgency as well as focus people’s creative energies, but bigger is not always better even in that regard.

The authors give advice on setting up the sprint team. This largely mirrors what lean practitioners have learned over the years such as limiting teams to seven people, having a cross-functional team, including a troublemaker or skeptic, having access to decision-makers during the sprint, and having a facilitator. These are most likely best practices linked to human psychology and group dynamics, with less to do with the nature of sprints, kaizens, business innovation, or process improvement.

The call to “solve the surface first” before diving deeper into a more mature technical or system solution is good advice. The sprint process allows the team to test how a customer would interact with a prototype product or service before investing a lot to make it technically more robust. It is an example of observing and listening to the customer, experimenting with quick-and-dirty prototypes, and attempting to solve problems with simple solutions, all commonly seen in lean management circles.

Why sprint? Why not design daily work to include improvement, problem-solving, experimentation, and critical decision-making? This question has been asked and answered over the past decade in the work of lean management. Many companies attempted to transform their organizations almost exclusively on the backs of a series of kaizen events and failed to sustain the gains. Today most practice lean with a balance of sprint-like improvements based on an end-to-end plan sustained through daily cycles of improvement, coaching, and learning. The book’s co-author Jake Knapp takes credit for inventing the sprint. That may be an independent invention, or it may be the result of Jake studying and modifying other effective five-day workshops such as the kaizen event. The authors’ answer to “Why sprint?” is that in their experience traditional problem solving and decision making takes too long or is done poorly. Their solution is the sprint. But we are missing the process to arrive at this solution. Why does it take so long? Why do we allow important decisions to take more time and effort than they ideally require? What are the root cause behaviors and beliefs? Based on this, what methods other than the sprint are needed to make entrepreneurship, innovation, new product, and new business development less of a struggle?

Even if you are an experienced kaizen event facilitator this book provides good reminders on how to plan and run five-day sprint-type workshops. The examples, illustrations, and brainstorming practices such as the Crazy 8 are sure to bolster a facilitator’s toolbox, especially for new products and new business development workshops. This book is recommended reading for people striving to invent new products and services, for anyone involved in lean management, and for facilitators of kaizen events and other workshop formats.

---