Design Sprint: Google Ventures' 5-Day Process Explained

By Tara Minh · Updated Oct 10, 2026

A design sprint is a five-day process for answering a critical business question through design, prototyping, and testing with real customers. Jake Knapp developed it at Google and brought it to Google Ventures (GV). A small team spends Monday through Friday on one problem and ends the week with a realistic prototype and honest customer reactions, instead of months of debate.

Key Facts

• GV describes the design sprint as a five-day process for answering critical business questions through design, prototyping, and testing ideas with customers.
• Jake Knapp started design sprints at Google in 2010 and brought them to GV in 2012; the book Sprint by Knapp, John Zeratsky, and Braden Kowitz came out in 2016.
• The official guide says to keep the team to seven people or fewer, with one or two Deciders and a Facilitator.
• Friday's test uses five target customers, interviewed in one day.
• Nielsen Norman Group found that five users surface about 85% of usability problems in a single study.

What is a design sprint?

The design sprint compresses a long product cycle into one week. Instead of building the full product and hoping customers like it, the team picks a big risk on Monday, sketches competing solutions on Tuesday, chooses one on Wednesday, fakes a working version on Thursday, and watches customers react on Friday.

The output isn't a finished product. It's an answer. After Friday you know whether the idea is worth building, which parts confuse people, and what to change next. That makes the design sprint a way to learn cheaply before you commit budget and engineers.

The method is documented in the book Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days (2016), and the authors keep an official design sprint guide with checklists and templates. GV also publishes its own overview of the sprint, including videos for each day.

Design sprint vs Scrum sprint, hackathon, and Lean Startup MVP

The word "sprint" causes confusion. A design sprint has almost nothing in common with a sprint in Scrum except the name. Here's how it compares to three things people often mix it up with.

The cleanest way to think about it: a design sprint is what you run before you commit to a backlog. Scrum is how you work through the product backlog afterward. The Lean Startup approach described on The Lean Startup site builds a minimum viable product to start learning as fast as possible. A design sprint gets you learning even earlier, with a prototype that was never meant to ship. For the engineering philosophy behind that kind of waste reduction, see lean software development.

The roles: Decider, Facilitator, and the team

According to the official guide, a sprint team has seven people or fewer, with diverse skills plus the people who work on the project day to day. Three roles matter.

• Decider: One or two people who make the final calls. Without one, decisions don't stick. If the Decider can't attend the full week, they appoint a delegate who can.
• Facilitator: Manages time, conversations, and the overall process. Ideally someone confident running meetings and summarizing discussion on the fly.
• Experts: People outside the core team who give 20-minute interviews on Monday afternoon, about two to three hours in total.

If you know Scrum roles, the Facilitator looks a bit like a Scrum Master, and the Decider carries the authority of a Product Owner for the week. The difference is that these roles last five days, not a whole product's life.

The five days: Map, Sketch, Decide, Prototype, Test

The official guide recommends blocking 10am to 5pm Monday through Thursday and 9am to 5pm Friday, with regular breaks. It also asks for a room with two whiteboards for the week, plus a smaller room for Friday's interviews.

Monday: Map

The team sets a long-term goal and lists the risks as questions. Then it maps the customers, the key players, and the flow toward the goal. After interviewing experts and writing How Might We notes, the team votes and picks one target customer and one critical moment to focus on. GV's overview describes the aim as choosing a target the team can solve within one week.

Tuesday: Sketch

Everyone works alone first. The team reviews existing ideas to remix, then each person completes the Four-Step Sketch: notes, ideas, Crazy 8s, and a three-panel solution sketch. Working alone avoids the group-brainstorm trap where the loudest voice wins. This is also the day to start recruiting five customers for Friday.

Wednesday: Decide

The team critiques the sketches using a sticky decision process: an art museum, a heat map, a speed critique, a straw poll, and a final supervote by the Decider. The chosen ideas become a storyboard of five to fifteen steps, a frame-by-frame plan for the prototype. When two ideas both look promising, the guide lets you prototype both and run a "Rumble."

Thursday: Prototype

The goal is a convincing front end, not working software. The team picks rough, fast tools, then assigns roles such as Maker, Stitcher, Writer, Asset Collector, and Interviewer. By the end of the day there's a trial run and a finished interview script. GV notes that a realistic, customer-facing prototype can be built in one day.

Friday: Test

The team interviews five target customers in one day while everyone else watches together on a video feed. The guide recommends a five-act interview, and after each session the team marks a simple scorecard. At the end the Decider makes the final yes or no calls and captures next steps.

Why five customers is enough

The guide puts it plainly: five is the magic number, and after five customer interviews big patterns will emerge. The reasoning traces to Jakob Nielsen's work at Nielsen Norman Group. In Why You Only Need to Test with 5 Users (2000), he reports that a single user reveals about 31% of usability problems on average and that, after a study with five participants, about 85% of the problems have been found.

Two cautions apply. First, Nielsen is describing usability problems, not market demand. Five interviews tell you where people get lost, not whether a million others will buy. Second, he recommends several small tests over one big one, for example three rounds of five users instead of one round of fifteen. A design sprint is round one. Plan a second round after you fix what you learned.

A day-by-day schedule template

Copy this into a doc and fill in names and dates before the week starts.

How to run a design sprint step by step

1. Pick a high-stakes question. A sprint suits a big, risky problem: a new product, a pricing page, a service redesign. Skip small tweaks you can just ship.
2. Choose the Decider and the team. Keep it to seven or fewer. Get the Decider to commit to the whole week or name a delegate.
3. Name a Facilitator. Ideally someone who isn't the Decider, so one person can focus on time and discussion while the other focuses on calls.
4. Block the calendar and the rooms. Five days, two whiteboards, one small interview room.
5. Start recruiting early. Assign one person to recruit five target customers. A screener survey, online communities, or a recruiting service all work, and attendance should be confirmed by email and phone.
6. Run Monday through Thursday. Follow the schedule above and protect the afternoon breaks.
7. Test on Friday and decide. Look for patterns that show up across customers, then agree on next steps.
8. Move the findings into regular work. Turn what you learned into user stories and refine them with the team in backlog refinement.

Design sprint examples by business function

The method came from product design, but the logic works anywhere a team faces a risky decision and can test a fake version.

• Product: Test a new onboarding flow with a clickable prototype before engineering writes any code.
• Marketing: Prototype a landing page and a campaign message, then watch five buyers explain what they think the offer is.
• HR: Mock up a new employee onboarding experience or benefits portal, then walk five new hires through it.
• Operations: Sketch a redesigned intake process for service requests, build a paper or slide mockup, and test it with the frontline staff who'd use it.
• Customer success: Prototype a new help-center structure and watch five customers try to find an answer.
• Sales: Draft a new proposal format and a demo flow, then run it past five prospects.

Do's and don'ts

Do

• Do give the Decider real authority. A sprint without one turns into a long meeting.
• Do recruit real target customers. Colleagues and friends tell you what they think you want to hear.
• Do prototype only the surface. If it looks real to the customer, it's good enough.
• Do work alone before you work together. Individual sketching beats group brainstorming.
• Do plan what happens after Friday. Know who owns the next step before the week ends.

Don't

• Don't run a sprint on a small problem. Five days of a full team is expensive for a button color.
• Don't invite everyone. More than seven people slows decisions.
• Don't build production code. The point is to learn before you build.
• Don't treat five interviews as proof of the market. They show usability patterns, not demand.
• Don't confuse it with a Scrum sprint. Your sprint planning and your design sprint answer different questions.

Variations and limits

The official guide notes that you can run most sprints remotely with a Miro template and video calls, and it admits remote sprints are "less fun but more practical." It also says you can borrow single pieces, such as the Four-Step Sketch or a single customer interview, when a full week isn't realistic. For large companies, it suggests scheduling cameo appearances from leaders on Monday and having the Decider delegate a daily decision maker.

The sprint won't fit everything. It needs a team that can drop other work for a week, a problem that can be tested through a prototype, and a Decider willing to commit. If those aren't available, a shorter, partial version usually beats a diluted full one.

Where to go next

Treat the design sprint as the front end of delivery, not a replacement for it. Once Friday gives you a validated direction, pull the winning ideas into your backlog and run them through your usual agile cadence.