Skip to content
Discovery WaypointDecision-ready discovery
Start WorkspaceSign in
Start Workspace
Sign in
GV

GV Sprint

Borrow the artifact · Primary source

GV Design Sprint

Treat the sprint as a compact operating sequence for answering a specific risky question, not as a default wrapper for any ambiguous project.

Best opened when

Risky concepts that need one compressed answer and fast user reaction.

What to steal first

The bounded sprint question, storyboard discipline, and prototype-test ending.

What not to copy

It is not a substitute for foundational discovery when the problem space is still largely unknown.

Closest move

Storyboarding

Core mechanism

Operating model anatomy

The GV Design Sprint is a five-day operating sequence for compressing framing, concept selection, prototyping, and user testing into one bounded push around a single hard question. It was designed for venture-stage teams that needed to validate or invalidate a risky concept quickly — not as an innovation ritual, but as a decision accelerator.

The transferable core has three elements. First, the sprint question: one bounded, answerable question that the sprint is designed to resolve. Second, the storyboard discipline: a structured way to move from concept selection to a specific scenario that can be prototyped and tested. Third, the prototype-and-test ending: a real session with real users whose reactions change what the team does next, not just document.

What does not transfer: the full five-day format requires decision-maker presence, genuine consecutive time, and a team capable of building a prototype realistic enough to test. Shorter, partial versions of the sequence lose the compressed decision pressure that makes the format valuable. If the team cannot commit the calendar or build a testable prototype, a lighter Waypoint technique will produce more useful output at lower cost.

Use it in a session

A clean first pass you can run

Participants
5–7 people: one decider with genuine authority to commit to the outcome, one facilitator, domain experts who understand the problem space, at least one person with enough making skill to build a realistic prototype on day four.
Timing
Four to five full protected days. If the calendar cannot give you this, run only the sprint question exercise instead (2–3 hours) — it delivers more value than a compressed sprint that cuts the user testing.
Prep
Define the sprint question before day one. A sprint question is specific and answerable: 'Will customers in segment X pay for feature Y?' or 'Does approach A produce better task completion than approach B?' A sprint question is not 'What should our product strategy be?'
  1. 1Day 1 — Map and target: Build a shared map of the challenge space. Agree on one specific target to address. Close with a single 'How Might We' cluster that the team will attack.
  2. 2Day 2 — Sketch: Each person sketches solution concepts individually. No group ideation. Individual work produces better raw material for the decision step.
  3. 3Day 3 — Decide and storyboard: Use structured critique to decide on one concept. Commit to it. Storyboard the full user experience the prototype will simulate.
  4. 4Day 4 — Prototype: Build a prototype realistic enough to generate genuine user reactions — not a wireframe, not a finished product. Focus on the specific interaction that answers the sprint question.
  5. 5Day 5 — Test and decide: Test with five users. Run a readout immediately after the last session. The readout ends with a decision: proceed, pivot, or stop. If the team cannot make this decision from the test signal, the sprint question was too vague.

You leave with

A clear answer to the sprint question — proceed, pivot, or stop — grounded in observed user reactions, not team opinion.

First failure point: The prototype is too polished and the team becomes protective of it during testing. The purpose of the prototype is to learn, not to impress. Watching users struggle with a flawed prototype is the point.

What good looks like

If this is working, these are the signals you should be able to point to

  • The prototype was specific enough to generate a clear yes or no from each test participant.
  • The team tested a real question, not a question they already knew the answer to.
  • The sprint output changed what the team would build next, not just validated the existing plan.
  • At least one assumption the team held on Monday was contradicted by Friday's testing.

How it worked there

The conditions that made it hold

GV developed the sprint format for portfolio companies that needed to move from question to tested concept fast — often because investor decisions, customer commitments, or product bets were riding on a specific risky assumption. The sprint was a forcing function for organizations that would otherwise spend months deliberating.

The format worked in that context because the companies were small, the decisions were high-stakes, and the decider was in the room with authority to commit. The sprint's five-day compression only creates the right kind of pressure when the participants cannot easily escape into other work, when the question is genuinely bounded, and when there is a real consequence attached to the test result. Most enterprise teams running 'design sprints' have modified the format so extensively — running it over two weeks, removing the decision-maker, replacing user testing with internal review — that the compression mechanism no longer functions.

What not to copy · Failure modes

What goes wrong when this is copied

The sprint is run without a crisp question worth answering. Teams use the sprint format to get unstuck on a project that is still too vague, poorly scoped, or politically unresolved. A sprint that starts without a single specific, answerable question will spend its first day generating the kind of breadth that belongs in earlier discovery work, and will arrive at Friday's test with a concept that represents a compromise rather than a bet.

The test is treated as the output rather than the decision signal. A good sprint ends not with a prototype but with a reading of what the test showed and how that changes what happens next. Teams often finish the test on Friday afternoon, collect some notes, and declare the sprint complete. If the team cannot answer 'what does this change?' from the test results, the sprint produced a prototype artifact, not a decision.

The sprint is chosen because the brand gives it legitimacy. 'We're running a design sprint' sounds rigorous. Teams sometimes choose it not because a five-day compressed sequence is genuinely the right move, but because it is recognizable and defensible. The selection logic should be: is there one bounded question, can we build a testable prototype, and would user reaction in four days genuinely change what we do next? If not, the sprint is the wrong tool.

Weak signals to watch for

  • It is not a substitute for foundational discovery when the problem space is still largely unknown.
  • It is not the right default whenever stakeholders want visible progress fast.
  • Do not run a sprint because the brand is famous while the team still lacks a crisp decision question.
  • Do not imitate the sequence if the team cannot build a credible enough prototype to test.

Closest Waypoint move

What to open next

Primary route

Storyboarding

Use this when the sprint is overkill but the team still needs to make one concept concrete enough to test.

Use this when you need one concept made concrete enough to test and can accept the full five-day structure being overkill if the question is already settled.

Sources and confidence

Primary source

Reviewed by Discovery Waypoint Editorial Team · 2026-04-04