Product design sprint

The problem this solves

A sprint is the right shape when the blocker is a decision rather than capacity. Two founders disagree about what the first version is. A feature has been re-specced three times. A new surface has to exist by a date and nobody can agree what goes on it.

What makes those expensive is not the design work. It is that the disagreement is never written down as a decision, so it comes back at every review, and each round of screens gets judged against a target that quietly moved.

So the sprint is built around producing decisions with screens attached, in an order that surfaces the argument early. Cheap fidelity while the structure is contested, high fidelity once it is not. The prototype at the end is useful, but the record of what was decided and rejected is what stops the same fortnight repeating in six weeks.

What you get

• A scoped version one, in writing

  What ships and what explicitly does not, agreed in the first days. The second list is the one that saves the sprint.

• Flows and screens at production fidelity

  The core surfaces drawn properly, with empty, error and partial states included rather than promised. Those states are most of the first week of real use.

• A clickable prototype

  Enough to put in front of five people, a board, or an investor, and enough for an engineer to see the intended motion and sequence.

• A decision log

  Each significant choice with the alternative that lost and why. This is what a sprint leaves behind that a folder of screens does not.

How it runs

1. 1

   Frame the week before it starts

   One call to name the decision the sprint exists to settle. A sprint pointed at a vague brief produces a vague artefact on schedule.

2. 2

   Compress the research

   Existing evidence, whatever users are reachable, and the competitors your buyers actually compare you against. Days, not weeks — enough to stop the sprint designing from assumption.

3. 3

   Structure while it is cheap to change

   Low fidelity, several directions, reviewed against the framing rather than against taste. This is where the argument is supposed to happen.

4. 4

   Build the chosen direction out

   Real content, real density, every state. One direction, taken seriously, rather than three kept alive to avoid a decision.

5. 5

   Prototype, test, hand over

   A round of sessions if the schedule allows, then the file, the decision log and a walkthrough with whoever builds it.

The longer version of this, with what happens in each week, is on the process page.

Where this has been done

• 22 two, AI interview coach

  4 core screens, 3 paywall concepts

  Most interview tools meter everything, so the free version reads as a trailer. The sprint gave away the whole feedback system and moved the paywall onto the job people have a deadline for — a positioning decision settled with screens rather than a deck.

• Fincline

  15 MVP screens, 2 buyer types

  Bookkeepers lose 12 to 20 hours a week matching payments to invoices by hand. The work was designing the layer that does the matching, and the interface that makes a human comfortable trusting it — for two buyers whose tolerance for automation is not the same.

Typical engagement

Two weeks for one contested feature or a single surface. Three to four for a first version of a product with a couple of user types, because the flows have to be worked separately before they can be reconciled.

It runs best with one person on your side who can make decisions in the room. A sprint that has to wait a week for sign-off is not a sprint; it is a project with a shorter name.

Who this is not for

• The decision has already been made and what you need is production capacity. That is ongoing design work, not a sprint.
• Nobody available can say yes during the block. The schedule is the constraint that makes a sprint work, and it is the first thing an absent decision-maker breaks.
• You want every option kept open at the end. A sprint that ships three directions has moved the argument, not settled it.
• The product already ships and is losing people for reasons nobody has diagnosed. Audit first — designing before the finding is guesswork with a deadline.

How I think about this

• AI made prototyping faster. It also made bad ideas faster. — why the structure round stays low fidelity even when it needn't be
• Feedback needs a subject, and taste is not one — how the review sessions inside a sprint are run
• Every product is empty on the first day and that screen gets designed last — why first-run states are in the deliverable rather than after it
• Your SaaS shouldn't look unique everywhere — where a first version should be conventional, and where it must not be

Frequently asked questions

How long is a product design sprint?

Two weeks for a single contested feature or one surface, three to four for a first version of a product with more than one user type. The length is agreed before it starts and does not move, because the fixed end is what forces the decisions the sprint exists to produce.

Is this the Google Ventures design sprint?

It borrows the useful parts — a fixed block, a framed decision, low fidelity before high, a prototype in front of real people — and drops the parts that assume five people can clear their calendar for a week. Most teams cannot, and a method that needs them to is a method that quietly does not run.

What do we get at the end?

Production-fidelity screens for the core flows including their empty and error states, a clickable prototype, and a decision log recording what was chosen and what was rejected. The last one is what stops the same argument reopening a month later.

Can you test the prototype with users inside the sprint?

Yes when participants can be lined up before the block starts — recruiting is usually the constraint, not the sessions. If they cannot, the sprint ends with a prototype ready to test and I will say plainly which decisions are still resting on judgment rather than evidence.

Who needs to be involved from our side?

One person who can decide, available for a short review at each step. Engineering represented at the structure review and at handover. Everyone else can read the decision log.

What happens after the sprint?

Usually one of three things: your team builds it and I stay reachable for questions, a second sprint covers the next surface, or the work turns into an ongoing fractional arrangement. None of them are assumed in the first quote.