What to Do After a Design Sprint

After a design sprint, and before the winning prototype goes on the roadmap, write down what the Friday result depended on and what change would reopen the decision. A clean Friday result does a team more harm than a failed one. A failed test gets questioned. A clean one gets treated as settled, and it keeps that authority long after the users, the context and the scale that produced it have moved on.

A design sprint is GV's five-day process for answering a critical business question by mapping, sketching, deciding, prototyping and testing with customers.

Five days buys a verdict a team can defend

The method comes from Jake Knapp, John Zeratsky and Braden Kowitz, who refined it at GV over more than a hundred sprints and set it down in Sprint (2016). GV describes the sprint as a five-day process for answering critical business questions through design, prototyping and testing ideas with customers. Monday maps the problem and picks a target. Tuesday sketches competing solutions. Wednesday turns the strongest into a testable hypothesis. Thursday builds a realistic prototype. Friday puts it in front of real customers.

The Friday test is small by design. The book recommends five one-on-one interviews, drawing on Jakob Nielsen's finding that five participants surface about 85 per cent of usability problems. The rest of the team watches the sessions on a video feed and notes patterns on a whiteboard as they appear. By late afternoon, the pattern across five people is usually clear enough to call.

The value is real. A sprint forces a decision that might otherwise drift across a quarter of meetings. It replaces opinion with observed behaviour. It puts the Decider in the room, so the choice has an owner from the start. And it costs one week and a prototype that was never meant to ship, well before any engineering budget is committed.

The output is a verdict: the prototype worked for these customers or it did not, and here is what to build next. Set against the months of internal debate it replaces, a sprint verdict is evidence a team can defend. It belongs in the same family as a usability test, with a commitment attached.

What has to stay true for Friday's answer to hold?

Every Friday verdict is conditional, though nothing on the sprint wall says so. Five customers were recruited against a screener. They used the prototype once, in a quiet room, with a facilitator beside them. The result holds for people like them, in circumstances like those. The verdict carries its conditions silently, and the silence is what lets it travel.

Take the conditions one at a time. Who was tested: the screener picked a segment, and Nielsen himself advises testing distinct user groups separately. What context: a moderated session strips out the interruptions, habits and competing tools of ordinary use.

What scale: a prototype seen five times says nothing about how a feature behaves when thousands use it at once, or when one person meets it every day for a year. What environment: the market, the regulation and the competitor set as they stood that week. Any of these can move after Friday without anyone touching the product.

None of this is a flaw in the method. A sprint is meant to answer one question cheaply. The trouble starts when the answer leaves the room. Sprint notes become a line on the roadmap, the roadmap becomes a build, and the build outlives the week that justified it. A decision that should carry an expiry condition enters the roadmap as a permanent fact. The same drift follows a winning variant after an A/B test.

Almost 690,000 pings in one week: the NHS COVID-19 app's summer of 2021

The NHS COVID-19 app was not built in a five-day sprint. It followed the same logic at national scale: prototype, test with real users, decide, ship. A revised version was trialled on the Isle of Wight, in the London Borough of Newham and among NHS volunteer responders in August 2020, then launched across England and Wales in September. It used Bluetooth to log close contacts and advised those exposed to a positive case to self-isolate.

The app worked. Kendall et al. (2023) estimate that its contact tracing averted about one million cases in its first year, corresponding to roughly 44,000 hospital cases and 9,600 deaths. The same study found that engagement and impact varied with changing social and epidemic characteristics across that year.

Those characteristics changed sharply in July 2021. On 19 July, England lifted most remaining restrictions while Delta infections were rising. In the week to 21 July, the app sent almost 690,000 alerts in England and Wales, an 11 per cent rise on the week before. Food and logistics firms warned of critical staff shortages, and ministers let limited numbers of workers avoid isolation to keep services running.

The recalibration came on 2 August. For people who entered a positive test without symptoms, the app had looked for contacts in the five days before the test. Following a review announced by the Health Secretary, and based on public health advice, the government cut that to two days, dropping contacts from days when the case was unlikely to be at peak infectiousness. It said the change did not affect the app's sensitivity or its risk threshold.

Nothing in the record suggests the settings were neglected. What it shows is sequence. The Health Secretary framed the update as reducing the disruption self-isolation caused people and businesses, and it arrived after the surge rather than before it. On that framing, the trigger for revisiting the lookback window was the damage itself: surging alerts, staff shortages and emergency exemptions.

A product team shipping a sprint-validated feature faces the same shape at smaller scale. A tool that works can still be tuned to a world that has moved. The only question is whether the team learns this from a threshold set in advance, which is what monitoring exists to provide, or from the consequences.

Take the finding your sprint team was most sure of on Friday and write down which customers and conditions it has to keep holding for. Start the Walk →

Attach a trigger to the Friday result before it reaches the roadmap

The step fits between the Friday debrief and the roadmap meeting. Take two artefacts the sprint already produced: the sprint questions written on Monday and the whiteboard notes from Friday's five interviews. Under each positive finding, write the condition it depended on. Who were the five customers, and which users were left out? What context did they meet the prototype in? What volume, frequency or environment did the test assume? When the learning becomes a delivery baseline, the follow-up to requirements gathering checks that acceptance means the same thing to users and the delivery team.

Then give each condition a trigger: an observable threshold that reopens the decision. If the tested segment was small-business owners, the trigger might be enterprise accounts passing a set share of sign-ups. If the test assumed occasional use, it might be daily use crossing a named level. Each trigger needs an owner and a place it is checked, ideally a dashboard built to change the decision rather than report on it.

Check the list twice: before the build is committed to the roadmap, and whenever a trigger fires. Not every change in context matters, and the list is how a team tells which ones do. Building monitoring into a decision before it is finalised is part of the Universal Decision-Making Method, and in change management it separates a rollout that adjusts on a signal from one that waits for complaints.

A sprint decides what to build, and the triggers decide when to ask again.

Grant Purdy is the co-author, with Roger Estall, of Deciding (2020), and the architect of the Universal Decision-Making Method.