A product squad can spend a quarter polishing a prototype that never meets a customer, then report the quarter as progress because the demo looked finished. The costly moment is the commitment that follows, when a sponsor funds a build nobody outside the room has reacted to.
GV describes a design sprint as a five day process for answering a critical business question through design, a prototype and a test with customers. The point, on their page, is a shortcut to learning without building and launching. Jake Knapp began running that process at Google in 2010 and brought it to GV in 2012. The GV sprint guide lays the classic week out in order. Monday is a map of the problem and a choice about where to focus. Tuesday is competing sketches. Wednesday is the hard cut, and a hypothesis you can test. Thursday is a prototype real enough to put in front of someone. Friday is that test, with people who were not in the room that made it.
That week is a decision machine. It is not a tour of a method, and it is not a promise that the idea will survive Friday. The useful part is the forced contact with someone outside the team, before money is spent building the wrong thing. Corporate teams lose this when the calendar is already full and a senior person already has a solution in mind. The skip feels efficient. It is how a quarter disappears into a prototype that only the squad can love.
What changes when a model is in the room
An AI design sprint keeps the decision and puts a model inside the slow parts. Research can get wider before anyone treats it as evidence. The room can see more options before it cuts. A thin prototype, a screen, a script or a service walk through, can exist before the days run out. The model does not get a vote. It gets a job, and a person still checks the output against something real.
The AI design sprints workshop is this shape with a facilitator. AI is a tool in research, ideation and prototyping. The team leaves with a tested concept and a clear decision, not a tool demo. Three failures show up often enough to name. A sprint that ignores the tools spends the week on sticky notes while a model could have sped the research and the first version. A demo without a decision lets someone show a chatbot while nobody decides what to build. A tool debate spends the days on which model to use, instead of whether the idea is any good.
None of that is a new religion. GV's sequence is still the spine: understand the problem, choose a focus, make options, decide, prototype, test. The model compresses the slow middle. It does not replace the Friday test, and it does not replace the person who is allowed to stop the work. If you leave with a polished demo and no decision, you ran a show.
Who it suits
It suits a product squad that needs a concept test, not a six month discovery. It suits an innovation programme that has been asked to show progress on AI without shipping theatre. It suits the sponsor who has to fund, change or stop the next step, and who is willing to be in the decision rather than receive a pack afterwards.
In Melbourne the room is specific. The AI design sprint in Melbourne is for the product or innovation team who will make the thing, and the sponsor who has to fund what happens next. Engineers help. They are not a prerequisite. A mixed team can still prototype. If you cannot name the customer or the operator who feels the problem, you are not ready. If you cannot name the person who may say stop, you will spend the days producing a recommendation for a committee that was not there. That is a pre meeting with better stationery.
It does not suit a team that wants a certificate, a tour of logos or a vision for the year. One live problem is the brief. A portfolio of themes is a different meeting, and it will not fit in the days.
How a Melbourne team spends the days
Collective Campus, founded by Steve Glaveski, runs the facilitated version in Melbourne. The core team meets in person. A sponsor can join hybrid from another Australian city. The length is three to five days, or shorter when the calendar will not move. The tools are the ones the team is actually allowed to use after the room empties. The brief is one live customer or operator problem. The week is not a debate about which model is fashionable.
The sequence follows the workshop, not a canned case. You can run it as a classic five day arc, or compress it when the date is fixed. The jobs do not change when the hours shrink. What changes is how strict you are about the cut.
- Frame the problem, the user and the decision the sprint must produce. Proceed, change or stop are the allowed endings. Write them down before the first exercise, including the evidence that would make you stop early.
- Learn fast. Use a model to widen the research, then check what it produced against evidence you can point at. A fluent summary of a customer you have not spoken to is not research.
- Diverge, then cut. Generate more options than the room would invent alone. Keep two. A pile of notes is not a result, and twelve options is a refusal to choose.
- Prototype the thinnest version a stranger can react to. A screen, a script or a walk through of the service. No new platform, and no vendor you will still be procuring next quarter.
- Test and decide. Put the prototype in front of people who were not in the room that made it. Keep, change or kill, and record the decision where the next team can see it.
Data is part of the brief, not a footnote. The session uses dummy or approved material, and it covers what must not be pasted into a tool. If nobody in the room can say which records are in bounds, the sprint does not start. Speed is not a reason to create an incident on the way to a prototype. Agree the rule with whoever owns it before the first prompt.
The test is there to catch the fluent mistake. A model will draft a confident version of the wrong service. Thursday, or whichever day you have left for the trial, is when that version meets a person who does not care that the room is tired. If that slot becomes a demo to stakeholders instead of a reaction from someone outside, you have built a pitch.
What they leave with
They leave with a sprint brief tied to a real customer or operator problem, not a theme. They leave with a smaller set of options, produced faster because a model widened the set and a human threw most of it out. They leave with a prototype someone outside the room has reacted to. They leave with a decision: proceed, change or stop. They leave with guardrails for data and accuracy that were used during the days, not added as a slide at the end.
A stopped idea counts, if the stop is written down. Organisations get stuck when every concept stays alive because nobody wants to be the person who ended it. The useful failure is a kill you agreed was allowed while the room could still hear it. Proceed means a named owner for the next step, and a version the operator can actually run. Change means you know which assumption broke. Stop means the idea does not return next month as a fresh pilot with a new name.
Shipping, in this room, is not a slide and it is not a prototype only the squad can operate. If the sponsor needs another month of business casing before anyone may try the thing, you were not in a sprint. You were preparing a meeting. Say that on the last day, while the people who did the work are still there.
What to book, and what to skip
This is not the AI training day. Training builds skill across ordinary work. The sprint spends that skill on one live challenge and ends with proceed, change or stop. If the team has never used the tools, do the training first, or the sprint becomes a tour and the decision never arrives.
It is also not a hack day. A hack day ends when the demo works. A sprint ends when someone decides. The two get mixed because both look busy and both can involve a model. The artefact you should be able to point at afterwards is the decision and the evidence, not the applause.
A team that already has a decider, an operator and a data rule can run a thinner version inside the company. That sequence is written up in building an internal AI design sprint. Use it when you do not need a facilitator. Use the Melbourne room when you want the sequence held, the cut enforced and the decision made in the days you actually have.
To book, name the decision the sprint must produce, who can attend in Melbourne and any data you are not allowed to paste into a tool. Send that through the contact form. The days get shaped around that constraint. They do not get shaped around a case study we brought with us.
A design sprint is a way to see a reaction before you spend the build. An AI design sprint is that same bet, with a model doing some of the slow work and none of the deciding. A Melbourne corporate team is ready for it when the problem is live, the sponsor can say stop, and the room will accept a killed idea as a result. If those three are missing, book a different meeting. The sprint will not invent them.
Source: GV, "The Design Sprint". Jake Knapp began the process at Google in 2010 and brought it to GV in 2012.