Sign inGet started
Skills / Product-design

Design Sprint

The sprint is a five-day process for answering critical business questions through design, prototyping, and testing ideas with customers.

The Design Sprint is a rigorous, time-boxed five-day framework — Map, Sketch, Decide, Prototype, Test — developed at Google Ventures by Jake Knapp and documented in the 2016 bestseller Sprint. Teams of seven or fewer compress months of ideation, debate, and development into a single structured week, producing a realistic prototype and concrete user feedback before writing a line of production code. It's built for product teams, startup founders, and innovation facilitators who need a validated answer fast — not another round of meetings.

By Jake Knapp · Free
Specimen 01 · Live diagnosisDesign Sprint
Input

“We're a B2B SaaS company and our trial-to-paid conversion is terrible — about 4%. We think the problem is in onboarding, but we've been debating it…”

Diagnosis
Let's get your sprint set up properly.
Full transcript ↓
Calibrated referenceagent-skills.ai
The gap

Answer your biggest product question with a tested prototype in five days

Jake Knapp's Design Sprint structures problem-solving into five precisely scheduled days, each with named exercises, exact time boxes, and defined roles. Day 1 (Map) establishes the long-term goal, creates a journey map from customer to outcome, and selects a single 'target moment' to focus the sprint. Day 2 (Sketch) uses Lightning Demos for competitive inspiration and Crazy 8s — eight rough sketches in eight minutes — to generate divergent ideas before each person produces a 3-panel Solution Sketch. Day 3 (Decide) runs an Art Museum walk, Heat Map voting with dot stickers, a Speed Critique, and a Supervote by the designated Decider, culminating in a 15-panel Storyboard. Day 4 (Prototype) divides the team into specialized roles — Makers, Stitcher, Writer, Asset Collector, and Interviewer — to build a Goldilocks prototype: realistic enough to elicit genuine user reactions, not so polished it wastes time. Day 5 (Test) runs five structured Five-Act Interviews while the team watches a live feed, takes notes on a positive/negative/questions grid, and debrief patterns. The methodology requires a team of seven or fewer, a Decider with final authority, and a no-device policy during exercises.

The problem

Most product teams spend months debating solutions in meetings, building features customers never wanted, and discovering fatal flaws only after launch. The Design Sprint exists because the standard product development loop — argue, decide by seniority, build for six weeks, test, regret — is too slow and too expensive to use as a learning mechanism. Teams make costly decisions based on assumptions because the only way to get real evidence (shipping product) takes far too long to inform the decisions that matter.

The solution

In five structured days, your team moves from an open-ended challenge to a tested, realistic prototype with concrete user feedback — compressing what normally takes months of development cycles into a single week of focused, facilitated work.

You bring
  • A specific product, service, or business challenge to sprint on
  • The names and roles of your sprint team (up to 7 people, including the Decider)
  • Existing user research, customer pain points, or market context you already have
  • Notes or takeaways from prior expert interviews or stakeholder conversations
You get
  • A complete day-by-day sprint agenda with time-boxed facilitation instructions for every exercise
  • How Might We note clusters, a journey map target, and a written long-term goal statement
  • A 15-panel Storyboard ready to hand off to your Day 4 prototype team
  • A Five-Act Interview script and a 3-column pattern-recognition grid for Day 5 debriefs
In action

Watch the methodology work.

Three specimens from a single real session: the same situation, unaided and calibrated, the full transcript, and the skill answering live in the channel where the work happens.

Fig.01The same situation, two ways
Specimens A · B
Specimen AVague
Unaided

“Your team has debated the onboarding flow for three months across fourteen Slack threads and six meetings. The CPO has strong opinions, two engineers think the problem is a missing tooltip, and the designer wants to rebuild the entire flow. You're about to start a six-week development sprint on something none of you have tested with an actual trial user.”

×Vague — nothing concrete to act on.
Specimen BCalibrated
With Design Sprint

“It's Friday afternoon of sprint week. Five trial users just tested your Goldilocks prototype — a Figma mockup of the new onboarding flow with a sample dataset that bypasses the API key step. Three users completed setup in under four minutes. Two got confused at a different step you hadn't expected. You now have specific, observed evidence — not opinions — to bring into next week's planning meeting, and the Decider already signed off on the direction Wednesday afternoon.”

Specific, grounded, and ends with one clear next step.
Fig.02A real session, unedited
In-app · assistant
Design SprintClaude
Design Sprint
Let's get your sprint set up properly. Before we build the agenda, I need to answer three questions that will shape everything: What's the specific challenge you're sprinting on? Who is your Decider — the person with actual authority to make the final call? And how many days do you have: a full five-day sprint, or are we adapting to a condensed format?
We're a B2B SaaS company and our trial-to-paid conversion is terrible — about 4%. We think the problem is in onboarding, but we've been debating it for months. Our CPO can be the Decider, and we have a full week blocked off starting Monday.
Good — a 4% trial-to-paid rate with an onboarding hypothesis is exactly the kind of high-stakes question a sprint is built for. Here's how I'd frame Day 1:
Long-term goal: 'In two years, our onboarding converts trials into confident, activated users who see immediate value and renew annually.'
Sprint questions (the assumptions that could kill this goal):- Will users understand what they're supposed to do first in the product?- Can someone reach their first 'aha moment' without talking to sales?- Does the current onboarding hide features that would make users stay?
For the journey map, we'll trace the path from 'user signs up for trial' to 'user completes first meaningful action.' Which step do you think is where people fall off? That's likely your target moment.
Honestly, we think people get stuck on the 'connect your data source' step — it requires an API key and most users don't know where to find it. Half of trials never get past that screen.
Then your target moment is the API key step — that's where Day 1 ends and Day 2 begins. Let's set up your How Might We notes for the Day 1 expert interviews. Based on what you just told me, here are starter HMWs:
- HMW make it obvious where to find the API key before users hit that screen?- HMW let users see the product's value before they connect a data source?- HMW offer a sample dataset so users can experience the 'aha moment' without any setup?- HMW surface the right support resource exactly at the moment users get stuck?- HMW turn the API key step into a guided checklist rather than a blank field?
For Day 2, each team member will independently sketch solutions to the 'API key blocker' moment — starting with Lightning Demos (3 minutes each: what does Stripe, Zapier, or Notion do at this exact step?), then Crazy 8s (8 sketches, 8 minutes, no filtering), then a 3-panel Solution Sketch. The solo-then-share format is non-negotiable — it prevents the loudest person in the room from collapsing the idea space before it opens.
That makes sense. Can you build out the full Day 2 agenda with timing? We have 5 people plus our CPO.
Here's your Day 2 agenda (6 people total, targeting the API key onboarding moment):
9:00–9:15 — Recap Day 1: Review the journey map and target moment on the wall. Remind the team: today is solo divergence — no group discussion of ideas.
9:15–10:30 — Lightning Demos: Each person picks 1–2 examples of great onboarding or 'setup wizard' flows from any product (Stripe, Linear, Airtable, etc.). Three minutes per demo — describe what works and why. Facilitator captures 'great ideas worth stealing' on sticky notes.
10:30–10:45 — Break
10:45–11:15 — Notes & Ideas: Individuals review their own notes from Day 1 expert interviews and the lightning demos. Write down interesting ideas quietly. No sharing yet.
11:15–11:35 — Crazy 8s: Fold a sheet of paper into 8 panels. Each person sketches 8 variations of their best idea in 8 minutes — one panel per minute. Speed is the point; polish is the enemy.
11:35–1:00 — Solution Sketch: Each person produces a 3-panel storyboard showing their best solution in enough detail for others to understand it without explanation. Anonymous — no names on the paper.
1:00–2:00 — Lunch (sketches go on the wall while the team eats)
By end of day: 6 anonymous solution sketches on the wall, ready for Day 3's Art Museum walk and Heat Map vote.
This is really helpful. I was worried the sprint would turn into another workshop where the CPO just decides in the first hour and we all nod.
That's exactly the failure mode the sprint structure is designed to prevent. The Decider's Supervote doesn't happen until Day 3 afternoon — after the team has silently voted with dot stickers (the Heat Map), after a Speed Critique where each sketch gets narrated without its author defending it, and after a Straw Poll that makes everyone's preference visible. The CPO gets the final call, but by the time they cast the Supervote, they've seen the team's reasoning visually and can't just override it on instinct.
The 'no device' rule during exercises serves the same function — it removes the escape hatch where whoever is Slacking the loudest shapes the outcome. The sprint forces decisions to be made from shared, visible evidence rather than whoever spoke last in the meeting.
Shall we build out the Day 3 agenda and the criteria your Decider should use when casting the Supervote?
Reply to Design Sprint
What the skill is doing
01Sprint Agenda Builder
02How Might We Synthesizer
03Storyboard Architect
Fig.03The same skill, in the channel you already use
WhatsApp · live
9:41
DSDesign Sprinttyping…
Messages are end-to-end encrypted. No one outside of this chat can read them.
Today
We're a B2B SaaS company and our trial-to-paid conversion is terrible — about 4%. We think the problem is in onboarding, but we've been debating it fo…9:14✓✓
Let's get your sprint set up properly.9:14
Before we build the agenda, I need to answer three questions that will shape everything: What's the specific challenge you're spri…9:15
Who is your Decider — the person with actual authority to make the final call?9:15
Message

The same skill, where the work happens.

No new app to learn. The methodology runs over the WhatsApp Business API, so the answer lands as a reply in the thread you’re already in — same rigour, zero context-switch.

Reads the situation, names the pattern, returns one concrete next move.
Delivered in seconds, inside a conversation that already exists.
Specimen · WhatsApp Business API · live
Capabilities

What it does, specifically.

Each capability is a distinct move drawn straight from the source methodology — not a generic assistant guessing.

CapabilityC-01

Sprint Agenda Builder

Generates a complete, time-boxed agenda for each of the five sprint days — or a condensed 2- to 4-day version — with specific exercise names, durations, materials needed, and facilitator instructions. Accounts for your team size, available time, and domain (software, physical product, service).

Based on Knapp's exact day-by-day agenda structure from Sprint, including all named exercises (How Might We, Lightning Demos, Crazy 8s, Heat Map, Speed Critique, Storyboard, Five-Act Interview) and their official time boxes.
CapabilityC-02

How Might We Synthesizer

Transforms a challenge brief, expert interview transcript, or set of user pain points into a structured list of How Might We (HMW) questions — the affirmative, opportunity-framed prompts that power Day 1's note-taking and clustering exercise. Groups and prioritizes HMWs around the sprint target.

Based on Knapp's HMW method, where each HMW is written on a sticky note and later voted on with dot stickers to surface the most promising opportunity clusters on the journey map.
CapabilityC-03

Storyboard Architect

Drafts a 15-panel Storyboard from a selected Solution Sketch description, filling in opening scenes (how the customer finds the product), the core experience panels, and a closing scene — ready to serve as the blueprint for Day 4 prototyping.

Based on Knapp's 15-panel Storyboard format from Day 3, which begins with an 'opening scene' (how the customer arrives) and maps the customer's step-by-step experience through the solution, panel by panel.
CapabilityC-04

Five-Act Interview Scripter

Generates a structured, five-act user test script tailored to the specific prototype being tested: a friendly welcome, warm-up context questions, prototype introduction with task framing, task prompts with probing questions, and a debrief. Includes facilitator reminders on what not to say.

Based on Knapp's Five-Act Interview structure from Sprint's Day 5, which separates each phase of a user test to avoid priming, leading, or rescuing the participant — a common failure mode in unstructured usability sessions.
CapabilityC-05

Sprint Pattern Analyst

Takes raw notes from five user tests and organizes them into a 3-column pattern grid (positive observations, negative observations, open questions), then surfaces recurring patterns — the specific signals that indicate which assumptions held and which need revisiting.

Based on Knapp's Day 5 debrief structure, where the team watches interviews via a live feed and records observations on sticky notes sorted into three columns, then identifies patterns that appear across at least three of the five participants.
CapabilityC-06

Condensed Sprint Adapter

Reconfigures the five-day sprint into a two-, three-, or four-day format (including Design Sprint 2.0), identifying which exercises are non-negotiable, which can be shortened, and which can be asynchronous — without breaking the core Map → Sketch → Decide → Prototype → Test logic.

Based on Jake Knapp's Design Sprint 2.0 (developed with AJ&Smart), which condenses the original five-day sprint into four days by combining Map and Sketch into a single day and streamlining the Decide phase.
Tested

Graded before it shipped.

Every skill is scored against independent scenarios for methodology fidelity before it goes live — not vibes, a rubric.

What it produces
OutputD-01

Sprint Brief

A one-page alignment document covering the sprint challenge, long-term goal, sprint questions, team roster (including the Decider), and schedule — created before Day 1 to ensure stakeholder buy-in and prevent the Decider from going AWOL mid-sprint.

OutputD-02

15-Panel Storyboard

The panel-by-panel visual blueprint for Day 4 prototyping, including opening scenes, core interaction steps, and a closing scene. Each panel maps to a specific screen, moment, or touchpoint the prototype team needs to build.

OutputD-03

Five-Act Interview Script

A structured facilitator guide for Day 5 user tests, with scripted language for each act, task prompts matched to the prototype's storyboard, and probing questions designed to surface genuine reactions without leading the participant.

OutputD-04

Pattern Recognition Grid

A 3-column synthesis table (positive observations / negative observations / open questions) populated from five user test sessions, with recurring patterns flagged and a 'next steps' recommendation based on what the team learned.

The source

Grounded in the original work.

Every answer traces back to a real source and the practitioner who wrote it — not a secondhand summary. Here is the source of record.

Source authorA-01

Jake Knapp

Jake Knapp created the Design Sprint methodology while working as a Design Partner at Google Ventures (GV), where he ran sprints with more than 150 companies including Slack, Blue Bottle Coffee, and Nest. He is the co-author of the 2016 global bestseller Sprint (with John Zeratsky and Braden Kowitz) and Make Time (2018). Previously he designed products at Google and Microsoft, and he has since partnered with AJ&Smart to release the condensed Design Sprint 2.0.

Status · Inspired by Jake Knapp’s work — not yet claimed. Are you Jake Knapp?
Primary sourceS-01

Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days

by Jake Knapp

Former Google Ventures Design Partner; Sprint (2016) is required reading at IDEO, Stanford d.school, and major tech product organizations worldwide.

Read the original ↗
Citationthesprintbook.com
In the build queue

Be first to run it.

Design Sprint is being built right now. Leave your email and we’ll tell you the moment it goes live.

Notify meEmail
At launchI want to run a Design Sprint on our [problem]. We have [X days] and a team of [N people]. Can we start with a Sprint Brief and build out the Day 1 agenda?