Sprint

A prescriptive schedule developed at Google Ventures and run with startups: five days, a small cross-functional group, a cleared calendar, and a specific set of activities each day.

Its purpose is narrow and worth stating precisely — it is for answering a significant question quickly, not for building a product, running a team, or replacing ongoing discovery.

It answers one large question in a week. It is not a way to build products or to run a team.

Devmark’s reading — not a quotation from the book

The day for building a shared understanding: set a long-term goal, list the assumptions that could sink it, map the customer's path through the problem, interview internal experts, and choose a single target on the map.

The choice of target by the decider is the day's real output, because a sprint that tries to address the whole map produces nothing testable.

The day for generating solutions individually rather than in a group. Each person reviews existing solutions, then works through a structured sketching sequence ending in a detailed, self-explanatory solution sketch.

The rejection of group brainstorming is deliberate and grounded — the evidence that groups generate fewer and less varied ideas than the same people working alone is one of the better-supported findings in the book.

The day for choosing without discussion-by-committee: a silent review of all sketches, a heat map of interesting parts, short critiques, a straw poll, and a final binding decision by the designated decider.

The structure exists to prevent the two standard failures — the loudest voice winning, and a consensus that blends everything into nothing.

The day for building a realistic facade — enough to produce a genuine reaction, with no working system behind it.

Their prototype mindset is the transferable idea: it is temporary, it needs to be only as real as the test requires, and building it in a day forces decisions that would otherwise be deferred for weeks.

Build only as much reality as the test requires. The one-day limit forces decisions that would otherwise drift.

Devmark’s reading — not a quotation from the book

Five customer interviews with the prototype, watched live by the team, with notes taken in a structured grid and patterns identified at the end of the day.

The five-participant number comes from usability research suggesting most major problems surface within that many sessions. It is a reasonable working heuristic, though the original claim has been qualified considerably since it was made.

Their insistence on a single person with authority who is present for the week, and their contingency advice if that person cannot attend throughout.

This is the requirement most often ignored and most responsible for failed sprints, because a week of work that ends in a decision nobody can make produces nothing.

It works for open questions with several plausible answers and real stakes — a new product direction, a redesign, a service concept.

It works poorly for incremental improvements, for problems requiring technical investigation, and for questions where the uncertainty is about feasibility rather than desirability. Teams that run sprints on a schedule rather than on a question tend to discover this.

Five days of several senior people is expensive, and the book underplays that. The subsequent shortened variants — including the authors' own four-day revision — exist because the original commitment proved hard to obtain repeatedly.

A team can only justify the format for questions large enough to warrant it, which is a constraint on frequency rather than a flaw.

Work alone, then decide together, which is the sequence that fixes most of what is wrong with idea meetings and transfers to any group decision.

And the discipline of putting a realistic artefact in front of real users before committing, which is the whole point and is skipped far more often than it is done badly.