Developed by Jake Knapp, a Google Ventures design partner, the method has worked for products as big as Gmail and Google Search and for businesses as wide-ranging as Facebook, Airbnb, Slack, Medium, and Blue Bottle Coffee.

When you’re stuck, starting something new, or debating a product’s prospects, you should sprint. “The perfect time is when a project seems so big, because the sprint encourages you to focus on the biggest opportunities and challenges,” says Knapp.

Over the course of five days, sprint participants map out a project goal and find its problems (Monday), brainstorm solutions (Tuesday), make progress decisions (Wednesday), prototype (Thursday), and have users experience the prototype (Friday). On the sixth day, you don’t IPO and become a millionaire, but you do have a ton more insight for your next move. “A sprint doesn’t mean you can solve everything in five days—you often will have to do another Sprint to narrow in on the best solution—but it’s a great way to start things,” says Knapp.

A sprint has parameters: Teams should be made up of seven employees who have a diversity of skills and perspectives, including at least one company decision maker. Sprint hours are typically from 10 a.m. to 5 p.m.—no checking email during this stretch, except during two short breaks. And, no joke, a light lunch should be eaten daily at 1 p.m. “We learned the hard way how burritos can kill a group’s momentum in the afternoon,” Knapp writes in his new book Sprint that goes deeper into the nuts and bolts of the process.

Knapp recommends that teams hold one sprint per quarter to check in on long term projects. The tight time constraints, he says, are one of the best things about the sprint.  “When you have a limited period of time, you will focus to get something done,” he says.

So instead of developing your next idea through guesswork and hoping you’re on the right track, use the sprint to test it in one quick, relatively-inexpensive burst of time and energy that unfolds according to the schedule below.

Monday: Map out your goal and find problems with it.

At the beginning of the day you determine the long-term goal—then you write down all the obstacles in the way. The challenges could be anything from being unable to technically construct the product to being unsure if anyone will buy it. By the end of Monday, you want a blueprint that identifies your overarching objective, lists the most pressing questions you have to answer, and points you towards your target, a piece of the problem you can solve in a week.

Let’s look inside Blue Bottle Coffee’s sprint to learn how they began: The company’s goal was to sell their coffee beans online to new customers. The challenges ranged from how they made their website shopping experience as interactive as in the in-store one (read: pour over coffee demonstrations) to how they enticed someone to buy beans they hadn’t tasted. And their target was to convert people who were already shopping online for coffee beans. All they needed was a solution.

Tuesday: Create ways to overcome the challenges.

The second day is spent coming up with solutions to any problems. The catch is that all solutions are sketched, rather that given verbally, because “the solution is either there or isn’t there in a concrete sketch,” says Knapp. The drawings don’t have to be beautiful, just detailed. “We don’t worry if the exact interface on a software product is figured out,” says Knapp. “We are going for that specificity about how it works.”

There are no freeloaders in a sprint. Each individual brainstorms solutions on their own to give everyone an equal voice. “Often, solutions come from a surprising place,” says Knapp. “If you are building a website, you might think to ask a designer or engineer for a solution, but the best idea might come from the customer support manager, who is talking to customers all day.”

Blue Bottle’s communications manager, for instance, came up with their winning idea, despite being a self-described bad drawer. His solution dubbed “The Minder Reader” was to organize Blue Bottle’s online store homepage in the same way that a barista might talk to a customer. Visitors would start at a page that asked how they prepared their coffee at home, before being offered recommendations and a brewing guide based on that preference. This way, those customers who weren’t familiar with Blue Bottle’s beans now had context around them.

Wednesday: Make important decisions.

On Wednesday morning, all of the sketches are taped to the wall and votes are cast for the one to prototype. To prevent any voting bias, none of the sketches have names on them—it’s purely about the ideas, and not the person who came up with it.

Drawn over the course of three sticky notes, “The Mind Reader” was picked because of its straightforward approach: customer reads a how-to guide for brewing coffee, customer then clicks on a link to recommended coffee beans, and then customer can click to find out more about each variety beans. Simple, clear—the whole concept could be easily understood.

Thursday: Build a prototype.

By the end of today, you’ll have a working—but not perfect—prototype. Knapp describes the intended result as “real enough” to evoke an honest reaction from a handful of reviewers on Friday (but we’ll get to that). Every product is different, so there isn’t a one-size-fits-all roadmap on how to build a prototype. But the user has to feel like its real. In the case of Blue Bottle, they didn’t need to make an entirely new website—they just had to build three web pages that looked and operated like live pages, so that the customer would feel like this was an actual shopping experience.

While you can spend longer building a perfect prototype, that isn’t the point of the sprint—it’s a learning process, not a manufacturing one. Knapp has found that teams can get 90 percent of a product’s user interface finished in a single day. And that timeframe is important. “After a day you are definitely willing to listen to what customers say about your product,” says Knapp. “But when your prototyping goes on longer than that, you become more and more attached to the idea.”

Friday: Elicit customer reactions and decide how to move forward.

On Friday, you’re trying to answer the overarching questions you posed on Monday. To do that, you will need at least five unbiased users to interact with your product. From them, you’re looking for a reaction, not feedback. “Feedback is not nearly as useful as an honest reaction from the gut,” says Knapp. “That is how people react in the real world.” Besides, sprint teams should be the ones who interpret what their users say and how that fits into their vision, rather than relying on the customer, who is not an expert, to be the ones telling the product team how to build something. You’re looking for patterns among the users. “If we see three users acting in a similar way, that is probably good enough for an answer,” says Knapp.

When Blue Bottle Coffee revealed “The Mind Reader” to customers, the team noticed how the customers grew more confident in the quality of the coffee as they clicked through Blue Bottle’s recommendations and used its guides. “Clearly, these people know coffee,” said one test subject. “The Mind Reader” subsequently became the foundation of the company’s new website.

Granted, everyone wants to see their experiment turn out perfectly by Friday afternoon. But Knapp says that the results don’t follow a neat template. Some ideas that seemed so smart on Wednesday and Thursday are flawed by Friday. Sometimes the flaws are small and can be quickly revised and re-tested. Other times the entire concept needs to be scrapped. The ultimate goal is to find out quickly where your idea is headed next. “Five days is a very efficient way to come to a conclusion,” says Knapp. “This way you don’t end up spending months on a hunch that could be wrong.”