There was no wizard
A design sprint fakes the back end so a team can test an idea in a week. Three and a half minutes on that clever trick, and on what changes when the machine behind the screen is real. It starts muted, and the words are under the film if you'd rather read. The narration is computer-generated.
The words
This is a design sprint: a way for a team to try out a big idea in just one week. On Monday they map the problem, on Tuesday they sketch answers, on Wednesday they vote and Doctor Ade decides, and on Thursday they build a prototype. It looks very real. But round the back, there's nothing there at all.
On Friday, Mrs Price presses the big button, and it works. But behind the screen, Mr Dobbs is pulling the levers. It's a clever trick called a Wizard of Oz test: you find out what people want before you spend months building it. Of course, none of it was real yet. And Doctor Ade's tea had gone cold.
Let's try that again. Same week, same room, but this time Mrs Shah, the analyst, checks the sums, and Mr Bello looks after the computer. Behind the screen is the computer itself. The sketches don't stay sketches, Doctor Ade chooses between real answers, and on Friday it works because it's real. Mrs Shah checks the answer, and Doctor Ade says yes.
Mrs Price still has to want it, of course. That's what Friday is for.
There was no wizard. Just good questions, and a machine that could keep up.
The design sprint
The design sprint is a five-day format developed at Google Ventures and set out in Sprint (Jake Knapp, John Zeratsky and Braden Kowitz, 2016). It runs through the week as map, sketch, decide, prototype and test, and GV's own guide describes it. One person, the Decider, makes the calls. On Friday, real customers try a prototype that is only realistic on the surface.
The Wizard of Oz test
Faking the machinery is much older than the sprint. In user-experience research, a Wizard of Oz study has a hidden person play the part of a system that doesn't exist yet. The name was given by J. F. Kelley, who used it to design a natural-language program without first having to build one (Kelley, 1984, ACM Transactions on Information Systems). It comes from L. Frank Baum's The Wonderful Wizard of Oz (1900), where the great wizard turns out to be an ordinary man working the effects from behind a screen.
It was a good compromise. Building the real back end took months, so a week could only afford to test its front, and you learned from users before spending that money.
The design-and-do sprint
Design-and-do sprint is our own name, not an established term. It's the same week and the same room, with the compromise removed. When the data preparation and the analysis can be built and checked about as fast as the questions are asked, there's no need for anyone to work the levers: the answers on Friday are real. Two things don't change. The analyst checks every result, and the person who owns the question still decides.
Decide-and-do
The same pattern needn't be confined to product design. Take any analytical question that would normally go away for a fortnight and come back as a report: in the same meeting, ask it, answer it, check it and decide what to do about it. We've been calling that decide-and-do. It's a working label, and we're not claiming it has caught on. What matters is the pattern: the people who ask the question and the people who answer it sit together, and the gap between asking and knowing shrinks to the length of a conversation.
How much faster, roughly
The numbers below are our own working estimates for well-specified, routine work. They come from our own use of agentic tools, not from controlled measurement. "By hand" means a skilled analyst working conventionally. "With an agent" means the agent's working time, before a person reviews the result.
- Cleaning and reshaping an unfamiliar extract: a day or two by hand; 10 to 30 minutes with an agent. About one and a half orders of magnitude.
- Descriptive tables and standard charts for a report: one to two days; around 15 minutes. About one and a half to two orders.
- Fitting, comparing and checking a set of regression models: two to five days; 30 to 60 minutes. About one and a half to two orders.
- A working simulation or dashboard prototype from a written specification: one to three weeks; one to three hours. About two orders.
- Re-running an existing analysis on new data, or answering a reviewer's question about it: days; under an hour. About two orders.
- A full evidence synthesis (systematic review and network meta-analysis): roughly 600 to 1,400 hours by hand; 9 to 24 hours of agent time. About two orders.
The by-hand figure for evidence synthesis fits the classic estimate of about 1,100 hours for a meta-analysis (Allen and Olkin, 1999, JAMA). Registered reviews have taken more than a year on average from registration to publication (Borah and others, 2017, BMJ Open). Even before large language models, one team completed a full systematic review in two weeks using automation tools (Clark and others, 2020, Journal of Clinical Epidemiology). The length of task that AI agents can complete has been doubling roughly every seven months (METR, 2025).
Two caveats keep these numbers honest:
- Review doesn't get faster at the same rate. Once the agent is quick, the person checking its work becomes the slow step. With every judgement signed by a person, the end-to-end gain is closer to one order of magnitude than two: still roughly a tenfold change, and months become weeks.
- The gain is largest on new, routine work, and smallest for experts in code they already know well. In a randomised trial, experienced developers working on their own mature open-source projects were slower with early-2025 AI tools (METR, 2025).
Why the same meeting is already doable
A task that took a day or two by hand now takes 10 to 30 minutes of agent time. That fits inside a one- or two-hour meeting, with time left for the analyst to check the result and for the people round the table to argue about what it means. Not every question can be answered that way. Many routine ones already can, and they are the questions that used to leave the room and come back weeks later as a report.
Prefer to write? hello@ktandb.co.uk.