Whatever your company designs, you'd probably love to do it faster--without increasing the risk for error. 

A new book called Design Sprint: A Practical Guide to Building Great Products, due out Oct. 9, shares a proven framework for accomplishing just that: More speed, fewer mistakes. That framework is a five-step process called a "design sprint." The book's three authors, each of whom is a design and innovation entrepreneur or executive, interviewed dozens of product professionals to research the best way to conduct a successful design sprint. 

One of their interesting discoveries was that--while design sprints across different companies share many traits--they often vary in length, depending upon the project, team, the company's design culture, or some combination thereof. "Google Ventures evangelizes a five-day process, while Intrepid Pursuits does a design sprint over four to six weeks," they write. Scott Jenson, product lead at Google, says he's seen the design sprint "work miracles" for his teams. 

So what is a design sprint, exactly--and how can you make it work for you? Here's a thumbnail version of the five steps: 

1. Understand (clarify the problem you're solving). 

This is the key phase. "If you don't get that right, you're in big trouble, as the rest of the sprint will be off," says co-author C. Todd Lombardo, Innovation Architect at the Small Business InnoLoft at Constant Contact. The other two authors are Richard Banfield, CEO and co-founder of Fresh Tilled Soil, a user experience agency in Boston, and Trace Wax, director at thoughtbot, where he has organized and facilitated many product design sprints.

The "understand" phase is when the team clarifies the customer problem is aims to solve with its product. That's why it's not easy. To fully "understand," you usually have to review all of the observations and ethnographic research you've conducted about the potential users of the product. 

There are many approaches, including building a wall on which you can post or tack user feedback and insights. Any way you do it, the idea is to go from a high volume of user information to an agreed-upon grasp of the problem your product must address.

2. Diverge (brainstorm what's possible).

There are several ways to do this, including old-school brainstorming. You can also conduct one of Lombardo's favorite design-sprint exercises, the "6-up," in which you sketch out six solutions to the agreed-upon problem. Some have been known to use drinking games for the occasion.

3. Converge (rank solutions, pick one).

During this phase, it's important to remember you've got two more phases: prototyping and testing. So when you're pondering which solutions to try first, remember: You're no longer solving the product in the abstract. The brainstorming portion of the exercise has ended. The time has come to rank the solutions not only based on how deftly they solve the problem, but on how skillfully you can execute them as a team. In short, the point of the "converge" phase is to distill your ideas into one or two solutions that you can actually test. 

4. Prototype (create a minimum viable concept).

Don't let perfection be the enemy of the good. You need to make your minimum viable prototype (MVP) as quickly and cheaply as possible while still ensuring that it's a viable enough dummy product to test the feasibility of your solution.  

The business world is filled with classic examples of MVPs. For instance, the Wright brothers famously built a wind tunnel to test their planes. But they did it on the cheap, using "a wooden box 6 feet long and 16 inches square, with one end open and a fan mounted at the other end....the box stood on four legs about waist high," writes author David McCullough in his 2015 biography of the brothers.

Even if you're building digital products like apps and nothing quite so ambitious as an airplane, remember: You only need to do enough to viably test the product. Innovation expert Scott D. Anthony calls this building a "MacGyver" prototype. It can be homemade and inexpensive. This isn't a guitar; it's nails, wood, and rubber bands. The idea is speed, not aesthetic perfection.

5. Test (observe what's effective for users).

Testing is the other reason you should remember the "minimum viable" part of your prototype: You'll have saved a lot of time and money if it turns out that users don't like your prototype. Which happens, more often than not. 

That's why the authors emphasize the importance of taking your time in the testing phase. "Many times we've felt quite confident about what we're doing in the sprint, only to watch it fall apart in the users' hands," says Lombardo. "This is because we had an incorrect assumption, or our design choice looked great for the prototype, but the user was confused or completely missed something." 

You might think that the design sprint framework only works when it comes to creating products--digital or physical. But the authors say that it's broadly applicable to almost any team working on a project involving feedback from a group. "We've seen design sprints used to develop solutions for sports training, personal time management, and physical space solutions," says Banfield. "The fact that they are called 'design sprints' shouldn't confine them to design problems. In this case, design is the tool to discover solutions, not the sector in which is can be used."