Sprint_ How to Solve Big Problems and Test New Ideas in Just Five Days

1. 1Recruit the knowledge before the sprint starts. List everyone you want, then cut to seven or fewer. Mix the core execution people with a few specialists, and cover the roles in the cheat sheet: Decider, finance, marketing, customer, tech/logistics, design. You do not need every role, and some roles can take two or three people.
2. 2Add the people whose knowledge sits outside the build team. Savioke's Izumi Yaskawa did not build the robot, but as head of business development she knew more than anyone about how hotels operated. At Blue Bottle, the customer service manager and the CFO supplied key insights. Choose for deep expertise plus excitement about the challenge.
3. 3Ask who would cause trouble if left out. Invite the smart person with strong contrary opinions, even for a guest appearance. They see the problem differently, and a dissenting view pushes everyone else to do better work.
4. 4Set up the shared brain before Monday. Get at least two big whiteboards (rolling boards, IdeaPaint on all the walls, or poster-size Post-it paper). Check them before the sprint starts, because BadgerCo lost about 90 minutes buying poster paper once the whiteboard ran out of room. Use the same room every day, or use rolling whiteboards so the notes are not erased overnight.
5. 5Run the expert interviews on the premise that nobody knows everything, not even the Decider. Each person's knowledge is locked in their own head, so the goal is to get it out and build a shared understanding. Keep asking obvious questions, pretend to be naive, and ask "Why?" a lot.
6. 6Capture continuously (ABC: always be capturing). Synthesize the discussion into notes on the whiteboard and keep asking, "How should I capture that?" Turn problems you hear into "How might we" notes, so each problem becomes an opportunity.
7. 7Cluster and vote the How Might We notes. Stick them all on a wall in any order, move similar ones together, label themes as they emerge, and stop after about ten minutes. Each person gets two votes and may vote on their own notes or the same note twice. Move the winners onto the map.
8. 8Keep the key notes visible all week and pick the target. Circle the most important customer and one target moment on the map. The team can weigh in, but the Decider makes the call. If a debate drags, ask the Decider to decide so the group can move on.

Savioke built the Relay, a hotel delivery robot, but did not know how it should behave around guests. Steve Cousins and head designer Adrian Canoso worried it might feel creepy to have a machine delivering towels. They had open questions: how should the robot communicate, how much personality was too much, and what about the elevator? The sprint team included the roboticists and the head of design, and also Izumi Yaskawa, who was not on the build team. As head of business development, she knew more than anyone about how hotels operated and what they wanted from the robot. Her knowledge, plus the engineers' and designers', went onto the whiteboards as shared notes instead of staying in individual heads. The team could then pick one target and prototype it. Part of the prototype was an iPad attached to the robot, running Keynote.

• If you have more than seven candidates, cut to seven or fewer. Keep the mix of core execution people and specialists, and use the role cheat sheet to check for gaps.
• If a person has deep expertise and cares about the problem, include them even if they are not on the build team. Savioke's business development head and Blue Bottle's CFO and customer service manager are the models.
• If someone smart holds a strong contrary opinion, bring them in, even for a guest appearance. Do not avoid them for disagreeing, but do distinguish a rebel from a jerk.
• If the Decider cannot attend the whole sprint, have them make a couple of appearances and delegate one or two Deciders who are in the room at all times.
• If discussion sinks into a long debate, ask the Decider to make the call and move on. If you cannot keep one room, use rolling whiteboards so the shared brain is not erased overnight.

• Staffing only the people who normally work together. The tell: nobody can answer how customers, money, or operations actually work, so those questions stay open.
• Treating the Decider as the all-knowing source. The tell: the team waits for one person's answers instead of drawing knowledge out of everyone.
• Running out of board space. The tell: cramped margin notes, notebook paper taped up, and a 90-minute supply run like BadgerCo's.
• Letting the shared brain disappear. The tell: notes are erased overnight, sit in file folders, notebooks, or decks, or move to a room where they cannot stay visible.
• Excluding the troublemaker, or over-polishing the How Might We wall. The tell: a surprise objection from the excluded person later, or the team still perfecting clusters long past the ten-minute limit.

• ▸Sprint challenge: one sentence stating the big problem.
• ▸Team of seven or fewer: list each person and their role (Decider, finance, marketing, customer, tech/logistics, design).
• ▸Outside expert(s): who knows the most about the customer or operations but is not on the build team?
• ▸Troublemaker: who holds a strong contrary view, and how will they be included (full time or guest appearance)?
• ▸Delegated Decider(s): who is in the room at all times if the main Decider cannot be?
• ▸Boards and room: two big whiteboards or equivalent confirmed, same room all week, checked before the sprint starts.
• ▸Supplies: sticky notes, markers, pens, Time Timers, printer paper, snacks on hand.
• ▸Top How Might We themes: the labeled clusters that emerged after ten minutes of sorting.
• ▸Winning notes and target: the notes that received votes, plus the circled customer and target moment the Decider chose.

1. 1Open Tuesday with the rule: everyone works alone, in the same room, at the same time. Tell people the sprint is device-free and that they may step out whenever they need to. The room should have a clear schedule and whiteboards big enough to hold the Monday map and notes. Check the whiteboards before the sprint starts.
2. 2Step 1, Notes (20 minutes). Everyone silently walks the room and copies what is useful from the whiteboards onto their own paper. Then take about three minutes to review and circle the notes that stand out. These notes are your raw material for the next steps.
3. 3Step 2, Ideas (20 minutes, plus 3 to review). Privately fill a sheet with rough ideas: doodles, sample headlines, diagrams, stick figures. Messy and incomplete is fine. This page is a scratch pad and is not shared. Spend the last three minutes circling your most promising ideas.
4. 4Step 3, Crazy 8s (8 minutes). Fold a letter-size sheet in half three times to make eight panels. Pick one strong idea and sketch a variation in each panel at one minute per panel, using a visible timer. Ask yourself, 'What would be another good way to do this?' The 'crazy' refers to the pace. Stay with ideas you believe will work, and do not aim for goofy ones.
5. 5Step 4, Solution sketch (30 to 90 minutes). Put three sticky notes on a sheet of paper and draw a three-panel storyboard of your best idea. Make it self-explanatory, because the sketch must stand without you in the room to explain it. Keep it anonymous, accept ugly, and use words, since words matter. Give it a catchy title.
6. 6Use a large visible timer for each block (the sprint uses a Time Timer for chunks from three minutes to an hour). The deadline keeps people from overthinking and removes the need to argue about time.
7. 7When the solution sketches are done, place them in a pile and save them for Wednesday. Do not present them or pitch them today. Wednesday starts by taping them to the wall in a row so they can be judged on the page.

Savioke's team was designing how a hotel delivery robot should behave around guests. On Monday they mapped the customer story (guest meets robot, robot gives guest a toothbrush, guest falls for robot). The CEO, Steve, chose the moment of delivery as the target. He also named the team's recurring worry: making the robot appear too smart, because guests expect C-3PO or WALL-E and the robot will not talk back. On Tuesday they switched from problem to solutions and skipped a raucous brainstorm. Everyone sketched alone, not just the designers. Tessa Lau, the chief robot engineer, sketched, and so did Izumi Yaskawa, the head of business development, and Steve himself. By Wednesday morning the conference room walls were plastered with sketches and notes. Some ideas were new, and some were old ideas that had once been discarded. Because every idea was on paper at the same level of detail, the CEO's sketch was judged alongside the engineer's. This is the point of concrete sketching: no idea gets overvalued because of who proposed it or undervalued because it was explained badly.

• If teammates stare blankly at an idea, or nod along to a vague one, then stop discussing it and have people sketch it. Abstract ideas get undervalued or overvalued, and concrete ones can be judged fairly.
• If someone proposes a group brainstorm, then keep everyone working alone in parallel. Individuals generate better solutions than groups brainstorming out loud, and parallel work still produces competing ideas without groupthink.
• If your first idea feels reasonable and you want to move on, then run Crazy 8s anyway. It forces you past the first solution to variations or alternatives.
• If a sketch would need you beside it to make sense, then add words, labels, and a title until it stands alone. The test is whether a stranger could evaluate it with no sales pitch.
• If the whiteboard is small, worn, or full of gray-on-gray marker, then fix it before the sprint starts. A cramped board costs more than the time spent replacing it.

• Treating Crazy 8s as a license for wild ideas. The tell is a page of jokes rather than eight variations of one good idea.
• Sketches that need a sales pitch. The tell is the author hovering by the wall to explain it, or the team asking 'what is this panel?'
• Sharing the notes, ideas, or Crazy 8s pages, or signing the final sketch. The tell is people polishing for an audience, or reacting to the author instead of the idea.
• Drifting into a conversation or a device. The tell is a quiet room that has gone off-task, with people reading the news. This is the problem working alone is meant to avoid, which is why the steps are timed and devices are out.
• A bad workspace. The tell is cramped writing in the margins, notebook paper taped to the wall, or an unplanned trip to buy poster-size sticky notes (it cost one sprint about 90 minutes).

• ▸Sprint target: Write the one target from Monday that you are solving for.
• ▸Notes (20 min): List the notes you gathered from the walls, then circle the ones that stand out.
• ▸Rough ideas (20 min): Doodles, headlines, diagrams. Circle your most promising ideas.
• ▸Idea to vary: Name the single strongest idea you will take into Crazy 8s.
• ▸Crazy 8s (8 min, 1 min per panel): Eight panels showing eight variations of that idea. Pick the best one.
• ▸Three-panel storyboard: Panel 1, Panel 2, Panel 3. Three sticky notes in sequence showing the customer's experience.
• ▸Self-explanatory check: Add enough words that someone could understand it without you. Note any labels you added.
• ▸Catchy title: Give the sketch a memorable title, with no author name on it.
• ▸Handoff: Place the sketch in the pile for Wednesday's art museum. Do not present it.

1. 1Open Wednesday with the pile of Tuesday's sketches already on the walls. At Savioke that was twenty-three solutions, some new and some old ideas that had been discarded or never thought through. Treat all of them as candidates. Tuesday's sketches came from everyone, including the engineer, the head of business development and the CEO, so no idea has an author's rank attached.
2. 2Get the group's permission before you run the day. Say you will keep track of time and process so they don't have to, then ask 'Sound okay?' This is the Facilitator's opening move from the passages, and it gives people a chance to object up front.
3. 3Set a visible timer for each step and introduce it with a narrative: 'When it goes off, it's a reminder to see if we can move on. If you're talking when it beeps, keep talking and I'll add a little more time. It's a guideline, not a fire alarm.' The goal is to decide in one day what most organizations take weeks of meetings and emails to decide.
4. 4Narrow the pile with voting and structured discussion instead of open debate. The source's aim is to decide 'quickly, quietly, and without argument.' Each person registers a preference on the sketches first, and discussion only follows to clarify. This is what prevents groupthink: opinions are recorded before anyone argues.
5. 5Let the single decision-maker make the final pick. At Blue Bottle the team voted on their favorites to cut fifteen sketches down, and then James, the decision-maker, chose the final three. The vote informs the choice. It does not make it.
6. 6Sort the winners into compatible and incompatible. Ideas that can live in the same prototype go in together. At Savioke the slate combined a face, a soundtrack of beeps and chimes, and the controversial dance. Ideas that conflict, like Blue Bottle's café-look website versus the other two, become competing prototypes. Because you only need a few key screens to look real, you can test all of them and skip the argument.
7. 7Deliberately keep at least one bold or controversial idea in the slate. Savioke kept the dance even though the CEO was nervous. Tessa's logic: 'If it blows up now, we can always dial back.' This is the moment for risk, because the test is cheap.
8. 8Before the day ends, document each chosen solution in detail. Savioke could build the prototype in eight hours on Thursday because Wednesday had settled which ideas to test and written each one up. Only execution remained. Capture everything on the whiteboard as you go ('always be capturing').

Savioke's sprint targeted one question: how should the Relay robot behave around humans? By Wednesday morning the conference room walls held twenty-three competing solutions, and the hotel test was set for Friday. The team used voting and structured discussion instead of weeks of meetings and emails, and it settled the choice quietly and without argument. The slate that emerged included designer Adrian Canoso's boldest ideas, a face and a soundtrack of beeps and chimes, plus one intriguing but controversial idea: the robot would dance when happy. Steve, the CEO, said he was nervous about too much personality but that 'this is the time to take risks.' Tessa answered that they could always dial back. Because Wednesday ended with every chosen idea documented in detail, Thursday needed only execution. Tessa and Allison programmed the robot's movements with a laptop and a PlayStation controller while Adrian built the sound effects. The prototype was ready for Friday's live test in the hotel.

• If a sketch is incompatible with the others but too appealing to drop, then prototype it as its own competing version. Blue Bottle's café-look site was the example, and they built all three because a prototype only needs a few key screens.
• If votes narrow the field but no clear winner emerges, then the decision-maker picks. James chose three sketches from the voted favorites. Do not reopen debate to reach consensus.
• If an idea is bold but controversial and the test is cheap and reversible, then include it. Savioke's robot dance went into the test because they could always dial back.
• If the timer goes off mid-sentence, then let the speaker finish and add a little time. The timer is a guideline, not a fire alarm. If it goes off and the discussion is circling, move on.
• If you are not ready to write each chosen idea up in enough detail to build it, then Wednesday is not done. Detailed documentation is what makes a one-day prototype possible on Thursday.

• Running Wednesday as an open debate. The tell is a single dominant voice and a day that ends with a short list nobody quite owns. The source's alternative is quiet voting plus structured discussion.
• Letting the vote make the final call. The tell is a list of three popular but similar ideas with no bold bet. The decision-maker's pick is part of the process, as it was at Blue Bottle.
• Forcing every idea into one prototype. The tell is a muddled prototype built from incompatible solutions, or long arguments over which one wins. Split incompatible ideas into separate competing prototypes.
• Skipping the write-up. The tell is a Thursday morning spent re-arguing what the team agreed to test. The Savioke prototype finished in eight hours because the ideas were documented in detail on Wednesday.
• Filtering out discarded or risky ideas early to stay safe. The tell is a slate that contains nothing a team member is nervous about. Savioke's slate included old, previously rejected ideas and a controversial dance.

• ▸Sprint question and target: copy both from Monday so every choice is judged against them.
• ▸Candidate solutions: list every Tuesday sketch by name or number (Savioke had 23, Blue Bottle 15).
• ▸Permission and timer: note that you asked 'Sound okay?' and the time box set for each step.
• ▸Vote results: record each sketch's preferences, gathered quietly before discussion.
• ▸Key points from structured discussion: capture only what clarifies or changes a choice.
• ▸Decision-maker's picks: name the person and list the sketches chosen (Blue Bottle: three).
• ▸Compatibility sort: mark which picks can share one prototype and which must be competing versions.
• ▸Bold or controversial bet: name the risky idea included and the reason it is safe to test.
• ▸Written detail per chosen solution: list what each is, so Thursday needs only execution.

1. 1Start from Wednesday's storyboard, not a blank page. Savioke finished in eight hours because 'much of the hard work had been done already': the ideas to test were chosen and each solution was documented in detail. Thursday is execution only. If the storyboard is vague, fix it first.
2. 2Define the façade's narrow task. Savioke's robot didn't need to run autonomously. It only had to appear to work for one task: delivering one toothbrush to one room. Write one sentence naming the single scenario the customer will experience and cut everything outside it.
3. 3Set the quality bar at Goldilocks. Too low (paper drawings, simplified wireframes) and the illusion breaks, and customers switch into feedback mode and start suggesting fixes. Too high and you work all night. Aim for 'real enough that customers react naturally and honestly'.
4. 4Fake the parts the customer can't see. Savioke's engineers drove the robot's movements from a beat-up laptop and a PlayStation controller. Anything behind the curtain can be manual, rigged, or mocked up.
5. 5Mock up the visible parts with the fastest tool available. The robot's 'face' was an iPad mounted on the robot. A designer, wearing headphones, orchestrated the beeps and chimes as sound effects. Match each tested element to the quickest tool that looks real.
6. 6Divide and conquer: give each person one piece of the façade to build, matching the roles on the sprint team (engineers on movement, designer on face and sound). Each person solves their own part and can quickly ask the others questions.
7. 7Work to the clock. Thursday is a single day (the sprint day runs 10 a.m.–5 p.m.). Savioke's robot was ready by 5 p.m., the day before the live test. Treat the deadline as fixed and cut scope, not time.
8. 8Include the bold ideas you chose to test, even the controversial ones. Savioke kept the face, the sounds, and the happy dance. Steve's reasoning: 'this is the time to take risks,' because a failure now can be dialed back.

Savioke's team had 23 competing solutions on Wednesday and used voting and structured discussion to pick a slate of designer Adrian Canoso's boldest ideas: a face for the robot, a soundtrack of beeps and chimes, and a dance when the robot was happy. On Thursday they had eight hours. They narrowed the build to one task: delivering one toothbrush to one room, and the robot did not need to run autonomously. Tessa and Allison Tse programmed and tuned the robot's movements using a beat-up laptop and a PlayStation controller. Adrian put on massive headphones and orchestrated the sound effects. The face was mocked up on an iPad mounted to the robot. By 5 p.m. the robot was ready. On Friday the guests at the Cupertino Starwood hotel met a robot that appeared to work, so their reactions were to the robot's behavior rather than to a drawing of it.

• If a component is invisible to the customer during the test, then fake it by hand (e.g., a human driving the robot with a controller) instead of engineering it.
• If the prototype is a drawing, a wireframe, or a paper mock-up, then raise the quality until customers can't tell it from a real product; otherwise you collect feedback instead of reactions.
• If the build will not finish in one day, then cut scope to one narrow task (like one toothbrush to one room) rather than extending the timeline or lowering realism.
• If a Wednesday decision is under-documented on Thursday morning, then clarify the storyboard before building, since the day only works when 'only the execution remained'.
• If you're tempted to polish, then stop: quality that's too high means working all night and spending effort the test doesn't need.

• Building a paper or wireframe prototype. Tell: customers say 'maybe you could add...' and offer suggestions, because the illusion broke and they switched into feedback mode.
• Over-building toward a real product. Tell: the team is still engineering autonomy or edge cases late in the day, and the prototype covers more than the one scenario you're testing.
• Starting Thursday without a detailed storyboard. Tell: the team spends the morning still deciding what to build instead of executing.
• Making the façade too narrow to answer the question, or too broad to finish. Tell: the Friday test can't show the specific behavior the sprint question depends on, or the prototype isn't ready by 5 p.m.
• Dropping the risky ideas to play safe. Tell: the controversial elements chosen on Wednesday (like the face, sounds, and dance) quietly vanish from the build, so the test can't learn from them.

• ▸Sprint question: the one question Friday's test must answer.
• ▸Narrow task: the single scenario the customer will experience (e.g., one toothbrush to one room).
• ▸Elements to include: the Wednesday-chosen ideas to be visible in the façade, including the bold ones.
• ▸What the customer sees/hears/touches: list each visible or audible element.
• ▸What can be faked: the behind-the-scenes parts you'll operate manually (e.g., laptop and controller).
• ▸Tool per element: the fastest tool to make each element look real (e.g., iPad for the face).
• ▸Owner per element: one named person for each piece.
• ▸Realism check: would a customer believe this is a real product? Yes/No, and what to fix if No.
• ▸Ready-by time: the hard stop (e.g., 5 p.m.) and what gets cut if time runs short.

1. 1Tie the test to the sprint before you recruit. Reread the sprint questions and the Monday target. Name which question Friday must answer. Flatiron's target was coordinators searching for matching trials, and it lined up with the question 'Will clinics change their workflow?'
2. 2Assign recruiting to someone other than the Facilitator. The Facilitator is already busy. Give the recruiter the target customer profile and the number you need: five.
3. 3Pick the channel by how findable your customer is. If customers are easy to find, recruit through Craigslist. If they are hard to find, recruit through your network.
4. 4For Craigslist, post a generic ad in 'et cetera jobs' that reveals neither what you're testing nor which customer you want. Offer a token stipend, usually a $100 gift card, and state the date, city and a 60-minute length. Link to a screener survey. A generic ad in a big city can draw hundreds of applicants.
5. 5Write the screener in two lists. First, list the characteristics of the customers you want and turn each into something a survey can measure. Second, list the characteristics you want to exclude, such as too much expertise in your industry. Blue Bottle wanted 'coffee-drinking foodies', so the screener used measurable criteria such as drinking at least one cup of coffee per day.
6. 6Select the five best matches from the applicants and schedule them. Run the interviews against the prototype built on Thursday. Set up a makeshift research lab if you need one. Savioke used a nearby hotel.
7. 7Seat the team together to watch the interviews, so everyone hears the same reactions at the same moment. Each Five-Act Interview aims at honest reactions and the 'why' behind them, so the team watches for the reasons as well as the verdicts.
8. 8Close Friday in the Learn step. Look for patterns across the five customers and decide the next step. Treat a flawed success as a reason to continue, and a failure as a cheap early catch.

Flatiron Health wondered whether existing users of its software would change their workflow for a new clinical-trial tool. The Monday target was coordinators searching for matching trials. That target matched the sprint question 'Will clinics change their workflow?' The team prototyped the software and tested it with real research coordinators. The coordinators didn't love every part of the prototype, but their enthusiastic reaction to the concept gave Flatiron the confidence to keep designing and developing. The authors call this an 'exciting flawed success'. Six months later, clinics were using the real thing to match patients to trials. The test needed only five days of work and a handful of the right customers. It answered the question the team had set on Monday.

• If your customers are easy to find (coffee drinkers, hotel guests), then recruit through a generic Craigslist ad plus a screener. If they are hard to find, use your network.
• If a characteristic would contaminate the feedback, such as too much industry expertise, then write it into the screener as an exclusion. Don't rely on the ad to filter it.
• If the ad could reveal what you're testing or who you want, then rewrite it until it could be about anything: 'coffee, robots, coffee robots, whatever.'
• If the Facilitator is the only person with time to recruit, then reassign the work. The Facilitator already has enough to do on interview day.
• If the test shows a flawed success, then keep going. A successful test is often the beginning of the process, as Medium found when it built two of its strongest ideas and launched them to a fraction of users.

• The ad names the product or the customer type. The tell: applicants arrive pre-coached or are plainly the wrong people.
• The screener is loose, so participants don't match the target customer. The tell: you can't state which measurable criteria each of the five met.
• The Facilitator tries to recruit as well as run the sprint. The tell: slots are still unfilled late in the week, or the Facilitator is distracted.
• The team skips small-scale data and waits for large-scale data. The tell: someone says 'let's just launch and see'. Early data is the cheap chance to course-correct.
• A good result is treated as the finish line. The tell: nobody names a next step. Flatiron and Medium both treated their flawed successes as the start of the next stage.

• ▸Sprint question being answered: copy the Monday sprint question this test must address.
• ▸Target customer: write the one customer from the Monday map, in a sentence.
• ▸Include criteria: list the measurable traits that match your target (for example, 'drinks at least one cup of coffee per day').
• ▸Exclude criteria: list the traits that disqualify, such as too much expertise in your industry.
• ▸Recruiting channel: Craigslist (easy-to-find customers) or personal network (hard-to-find customers), and why.
• ▸Recruiter: name someone other than the Facilitator.
• ▸Generic ad text: write an ad that hides the product and the customer type, with date, city, length (60 minutes) and stipend (for example, a $100 gift card).
• ▸Five selected participants: list five screener respondents who fit the criteria and their slots.
• ▸Pattern notes and next step: after the interviews, record what the five customers did and said, the 'why' behind it, and the decision you will take next.

1. 1Write sprint questions on Monday as unknowns the Friday test can answer, not as opinions to defend. Each question should name a customer reaction you could actually observe, such as whether they understand it or whether they care. The long-term goal is your measuring stick; the questions are what you hold Friday's results against.
2. 2Build the prototype to answer those questions and nothing else. The prototype mindset says to build just enough to learn. Anything on the façade that no sprint question needs is effort that gets no learning back.
3. 3Make the prototype look real enough that customers do not have to use their imagination. Realistic surface means genuine reactions, and genuine reactions are the only kind that count as validation. A prototype that looks fake produces polite guesses.
4. 4Keep the prototype disposable and your attachment low. Validation only works if you can accept a negative result. After one day you are receptive to feedback; after three months you are committed. Do not spend extra days polishing a solution that may lose.
5. 5Test with real people on Friday, using the five-customer 'small data' approach. Interview them with the right questions and watch their reactions rather than collecting their opinions of your idea. The point is to see what they understand and what they care about.
6. 6Take notes on each customer's reactions as they happen, so every observation can later be filed against a specific sprint question. Do not wait until the end of the day to reconstruct what happened from memory.
7. 7In the Learn step, look for patterns across customers, not single reactions. Mark which patterns point to success and which point to failure, and for each one ask why it happened. The 'why' is the learning that lets you fix, cut, or proceed.
8. 8Close by answering each sprint question explicitly, then plan the next step. Treat a failure as the highest-return outcome: you found a critical flaw in five days, before committing to build.
9. 9Where the whole product is too big to prototype, solve the surface first. Test the part where the product meets the customer, then work backward to the underlying systems.

Graco's engineers believed an industrial pump was too complicated for a five-day sprint. They sliced the challenge into questions and matched a cheap test to each one. To test marketability, they would prototype a brochure of the pump's new features and use it in sales visits. To test ease of use, they would 3D print new nozzles and attach them to existing pumps. To test installation, they would bring cables and hoses to nearby manufacturing plants and get reactions from assembly line workers. None of these tests was perfect, but each produced real reactions to the surface of the product, answering a big question before the pump existed. Blue Bottle did the same with a slide show standing in for its website, before building the software and inventory processes behind it. In both cases, the evidence comes from customers reacting to something realistic, not from the team debating internally.

• If a sprint question cannot be answered by watching a customer react to the prototype, then rewrite the question or drop it.
• If the whole product seems too large to test, then prototype only the surface where it meets customers and work backward from there.
• If the team wants to spend extra days perfecting the prototype, then stop. Diminishing returns plus growing attachment make negative results easier to ignore.
• If customers have to use their imagination to respond, then make the prototype look more real before testing. Their reactions will not be genuine otherwise.
• If a test fails, then treat it as the greatest return on investment: you identified a critical flaw after five days. Ask why, and decide whether to fix or cut.

• Testing a prototype that is not realistic enough. The tell: customers say 'I would imagine…' or react to the mockup rather than to the product idea.
• Over-building the façade. The tell: the team is wiring, plumbing, or engineering parts that no sprint question depends on, and Thursday feels unfinished.
• Falling in love with the solution. The tell: negative reactions get explained away, and the team blames the customer for not understanding.
• Overconfidence about understanding and caring. New ideas usually fail because we assume customers will understand and care more than they do. The tell: no sprint question tests comprehension or interest directly.
• Collecting reactions without finding the 'why'. The tell: Friday ends with a list of quotes but no patterns, no answers to the sprint questions, and no next step.

• ▸Long-term goal: copy the Monday goal word for word; it is your measuring stick.
• ▸Sprint question: write one unknown the test must answer, one question per sheet.
• ▸Prototype surface tested: name the façade element customers reacted to (for example, brochure, slide show, nozzle).
• ▸Customer (1–5): record which of the five customers this reaction came from.
• ▸Observed reaction: describe what the customer did or said, not your interpretation.
• ▸Success or failure signal: mark whether this reaction supports or undermines the idea.
• ▸Pattern across customers: note how many of the five showed the same reaction.
• ▸Why it happened: state your best explanation for the pattern.
• ▸Answer and next step: answer the sprint question (yes, no, unclear), then decide to fix, cut, or proceed.

1. 1Before Friday, write down the gamble in one sentence, plus the make-or-break questions it must answer. Savioke's gamble was giving the Relay a personality. Its open questions were whether guests would find a delivery robot creepy, how much personality was too much, and what happens in the elevator. A verdict is only possible against a stated question.
2. 2Split what you are testing into the core bet and the details around it. At Savioke the bet was personality. The touch screen, the sound-effect timing, and the games idea were details. This split lets you tell a bad idea from a rough execution.
3. 3Run Friday's test on the surface only: a realistic prototype with real target customers. Savioke recruited target customers and set up a makeshift research lab at a nearby hotel. Blue Bottle used Keynote slides as fake websites. You are looking at how customers understand and care, not at whether the back end works.
4. 4Have each team member take notes individually during the test, and keep the Facilitator unbiased. Do not let the Decider also facilitate, because the person summarizing results should not be invested in a particular outcome.
5. 5Sort every observation into one of three bins: confirms the core bet, flaw to fix, idea that failed. Savioke's sort: personality confirmed (it might be the secret to boosting guest satisfaction), sluggish screen and mistimed sounds as flaws, games rejected as a failed idea.
6. 6Classify the result. If the core bet fails and you learned it in days, it is an efficient failure: stop, or change direction before building. If the core bet holds and the details need work, it is a flawed success: proceed and reprioritize. Say the label aloud so the team and the Decider hold the same reading.
7. 7Name the next build or fix with its time limit. Savioke's flaws meant reprioritizing some engineering work, and there was still time before the full-time hotel launch. Write each fix as an owner, an action, and the date it must be done by.
8. 8The Decider makes the call and records it, with the evidence beside it. The sprint will not hand you a complete, ready-to-ship product. Its promise is that you know for sure whether you are headed in the right direction.

Savioke's Relay is a flawed success. The team worried that guests would find a delivery robot creepy, and they were unsure how much personality was too much. They gambled on giving the robot a personality. Over the sprint they considered dozens of ideas, built a realistic prototype in one day, and tested it with target customers at a makeshift lab in a nearby hotel. The evidence supported the core bet: character might be the secret to boosting guest satisfaction. It also exposed flaws. The touch screen was sluggish, some sound effects were mistimed, and the idea of games on the touch screen did not appeal to guests at all. The team classified this as a success with fixes, not a failure. The flaws meant reprioritizing engineering work, but there was still time. Three weeks later the robot went into full-time hotel service. Guests loved it, and by summer Savioke had more orders than it could easily produce. The authors say Savioke was confident in the gamble only because the sprint let them test risky ideas quickly.

• If the core bet is confirmed and the problems are in details (speed, timing, a single feature), then call it a flawed success. Reprioritize the work and proceed.
• If customers misunderstand or do not care about the core idea, then call it an efficient failure. Do not engineer further. The authors say new ideas usually fail from overconfidence about how well customers understand and how much they care.
• If one feature draws no interest (Savioke's games), then cut it. Do not rescue it, and do not read it as a verdict on the whole concept.
• If you cannot choose between competing approaches, then test all of them, as Blue Bottle did with three slide-built websites. Treat the sprint as a way to answer the choice with customers.
• If the Decider's view conflicts with what customers did, then follow the customer evidence. Deciders do not know everything even when they think they do, as the WalrusCo CEO showed when Wendy changed almost every part of the map.

• Judging the sprint by team mood. The author once surveyed brainstorm participants on enjoyment without measuring results. The tell: your evidence is 'people liked it' instead of what customers did.
• Treating a flawed success as a failure because the prototype was rough. The tell: you discard a confirmed core bet over sluggish screens or timing glitches.
• Treating a failure as a success because some details worked. The tell: the list of fixes grows while the core question (will customers care?) stays unanswered.
• Letting the Decider's certainty override what the test showed. The tell: the WalrusCo pattern of 'absolutely, one hundred percent' confidence that holds until real customer knowledge contradicts it.
• Ending with 'we learned a lot' and no named next step, owner, or timing. The tell: no fix is tied to the remaining time before launch.

• ▸Core bet (one sentence): the risky idea you are testing, such as 'a robot with personality'.
• ▸Make-or-break questions: the questions the test had to answer, written before Friday.
• ▸Evidence confirming the bet: customer reactions that support it, in their own behavior and words.
• ▸Evidence against the bet: reactions showing confusion, indifference, or discomfort.
• ▸Flaws in details: the specific items to fix, such as speed, timing, or a single feature.
• ▸Ideas to drop: features customers did not want.
• ▸Classification: efficient failure or flawed success, with one line of reasoning.
• ▸Next build or fix: owner, action, and the date it must be finished before launch.
• ▸Decider's call and date: proceed, change direction, or stop, signed off with the evidence attached.

1. 1Get the Decider into the room before anything else. The SquidCo prototype tested well, yet the project ended when Sam returned, because Sam disagreed with the problem. A sprint that tests the wrong problem produces a good result you cannot use. If the Decider cannot give a full week, schedule her for Monday (perspective on the problem), Wednesday (choosing the idea to test) and Friday (watching customers react), and name an official delegate for the rest.
2. 2On Monday, write the long-term goal at the top of the whiteboard. Ask: 'Why are we doing this project? Where do we want to be six months, a year, or even five years from now?' Make it reflect your principles and aspirations, and do not shrink it. The coffee team could have written 'sell more coffee online', but they wrote 'Bring great coffee to new customers online' to protect quality and reach new customers. Leave it up all week as the beacon.
3. 3Switch to pessimism. Imagine it is one year later and the project was a disaster, then ask what caused the failure and how the goal went wrong. Every goal has unexamined assumptions, and the longer they stay unexamined, the greater the risk. List them.
4. 4Turn each assumption into a sprint question. Savioke's were: Can we make a smooth delivery? Will guests find the robot awkward? Will guests come to the hotel just for the robot? Keep the questions on a whiteboard as a quasi-checklist for solutions and decisions all week.
5. 5Prioritize before you solve. Share what you know, then choose a target: the most important customer and the critical moment of that customer's experience. Like Mission Control fixing the trajectory before the air filter and the landing, work the part of the problem that decides everything else first. Savioke picked the hotel guest and the moment of delivery.
6. 6Decide fast and anchor decisions to the goal. When a decision stalls, the Facilitator calls on the Decider. Before the supervote, remind the Decider of the long-term goal and the sprint questions. The Decider has to decide honestly. OstrichCo's Decider went back to his normal decision-making after the sprint and committed the company to an untested idea.
7. 7Prototype only the target moment and test on Friday with real customers. You will not finish a ready-to-ship product, but you will learn whether you are headed in the right direction. Judge success by the sprint questions you answered and by what the data says about the next step.

Savioke wanted to accomplish a lot with its Relay delivery robot. The team chose the goal the hotels already used, a better guest experience, rather than front-desk efficiency or robot count. Then they imagined failure: the robot is awkward or confusing. That produced three questions: Can we make a smooth delivery? Will guests find the robot awkward? Will guests come to the hotel just for the robot? They targeted the hotel guest at the moment of delivery. The Friday test answered all three. Delivery was smooth. Guests did not find the robot awkward, apart from a sluggish touch screen. Some guests even said they would come to the hotel just for the robot. The team learned which fixes mattered, and learned it in a week, before building the full product.

• If the Decider cannot attend all week, then get her on Monday, Wednesday and Friday and name an official delegate. Do not guess what she would say, as in the SquidCo failure.
• If the team disagrees on the long-term goal, then discuss it until it is clear and write it down. The discussion can take thirty seconds or thirty minutes, and it should reflect your aspirations, not a safe version.
• If a risk would sink the goal but you cannot answer it today, then write it as a sprint question so Friday's test addresses it.
• If a decision drags or the group debates without converging, then the Facilitator calls on the Decider to decide so the team keeps moving.
• If the Decider is tempted to ignore the goal and questions, then remind her of them before the supervote, and require her to decide honestly rather than revert to an untested favorite.

• Guessing the Decider's view instead of having her present (SquidCo). The tell: the prototype tests well but the project dies when she returns because she thinks it solves the wrong problem.
• Writing a safe, narrow goal like 'sell more coffee online'. The tell: the goal gives no direction on quality or on reaching new customers.
• Skipping the pessimistic exercise and testing only for success. The tell: the sprint questions are all things you expect to be true, so Friday cannot surface a hidden risk.
• Solving before prioritizing. Mission Control fixed the trajectory first or the ship would have headed off toward Pluto. The tell: sketching solutions for a side issue because it was the first idea in the room.
• The Decider cedes or abandons her authority (OstrichCo). The tell: after prototyping and testing, she reverts to her usual decision-making and commits the company to an untested idea.

• ▸Long-term goal: write it in one sentence, six months to five years out, reflecting your principles and aspirations.
• ▸Failure story: imagine it is one year later and the project was a disaster. What caused it?
• ▸Assumptions behind the goal: list what must be true for the goal to work.
• ▸Sprint questions: turn each assumption into a question Friday's test can answer.
• ▸Target customer: who is the most important customer?
• ▸Critical moment: which moment of that customer's experience will you prototype?
• ▸Decider and delegate: name who attends which days, and who decides when the group stalls.
• ▸Friday answers: for each question, record what the test showed.
• ▸Next step: decide whether to build, fix or rethink based on the answers.

1. 1Name the problem in one sentence and test it against three filters from the passages: it is important, it is hard to know where to start, and it would take significant time and money to get right. Blue Bottle's online store passed all three, which is why Braden and John called it 'a perfect candidate for a sprint.'
2. 2Check the pressure source. The sprint works best with a big challenge and 'not quite enough time.' A real deadline, a stuck project, or a high-stakes launch gives the week its focus. Without one, the team drifts back to regular work.
3. 3Pick a problem you can open with a map: a customer moving from beginning to end. If you cannot name the actors and an ending (Flatiron: diagnosis to trial enrollment; Savioke: a delivery), the challenge is still too vague to select.
4. 4Accept that the challenge may be unfamiliar territory. Blue Bottle was not a tech company and James was no expert in online retail, yet the problem still qualified. Importance and uncertainty matter more than expertise.
5. 5Decide who has to be in the room, then ask what the problem demands. For Blue Bottle, that meant the programmer, the COO, the CFO, the communications manager, the customer service lead, the executive chairman, and James himself. If the people needed to solve the problem are not available for the week, pick a different challenge.
6. 6Face the cost directly: these are busy people who will miss a full week of important work. Ask whether the answer is worth that week. Select the challenge only if you can say yes.
7. 7Confirm the big challenge can narrow to one target. Everything in the sprint (sketches, prototype, test) flows from one target customer and one target moment on the map. A challenge that cannot be narrowed to a single target is too diffuse.
8. 8Write the challenge down and get the Decider's explicit agreement before you schedule anything else. The rest of the setup (team, time, space) depends on it.

In October 2012, Blue Bottle Coffee raised $20 million from Silicon Valley investors, including GV. One of James Freeman's most obvious plans for that money was a better online store for selling fresh coffee beans. The problem was hard: Blue Bottle wasn't a tech company, James was no expert at online retail, and he faced the question of how to translate the magic of his cafés to smartphones and laptops. Several weeks later, Braden Kowitz and John Zeratsky met James at a counter over coffee. They judged that the online store was important to the company, that it would take time and money to get right, and that it was difficult to know where to start. That combination made it 'a perfect candidate for a sprint,' and James agreed. He then staffed the sprint with the people the problem needed, not a typical software team. He brought in the programmer, COO, CFO, communications manager, customer service lead, and executive chairman Bryan Meehan, and joined them himself. Everyone knew they would miss a full week of other work. On Monday, the team mapped how coffee buyers move through the store and targeted a new customer purchasing coffee beans.

• If the problem is important, you don't know where to start, and getting it right will take real time and money, then run a sprint on it.
• If the challenge is vague or low-stakes, then you won't justify a week of full attention. Choose a bigger problem or don't sprint.
• If the people who must contribute can't clear their calendars for the week, then the challenge is wrong for now. Pick one that matches who is available or wait.
• If you can't sketch a simple map (actors on the left, an ending on the right, steps between), then narrow the challenge until you can.
• If you lack domain expertise, then don't disqualify the problem. Bring in people who have it, as Blue Bottle did with its chairman, operations, finance, and customer service leads.

• Picking a comfortable, low-stakes problem. The tell: nobody feels urgency, and teammates keep slipping out to handle 'real work.'
• Choosing an unbounded challenge such as 'fix our whole business.' The tell: Monday's map sprawls and no single customer or moment can be circled.
• Staffing the sprint with the usual team instead of the people the problem requires. The tell: key knowledge (finance, support, operations) is missing and questions go unanswered all week.
• Underestimating the cost of the week. The tell: participants treat it as optional, arrive late, or leave early because their regular work is piling up.
• Selecting a challenge without a deadline or pressure. The tell: the team over-thinks details and gets caught up in less important work, as the Preface warns happens on regular workdays.

• ▸Challenge (one sentence): State the problem, opportunity, or idea the sprint will address.
• ▸Why it's important: Say what is at stake for the company if it goes well or badly.
• ▸Pressure source: Name the deadline, stuck point, or high-stakes event that makes a week of focus appropriate.
• ▸Where to start: Describe what makes the starting point unclear or the work hard to scope.
• ▸Cost of getting it wrong: Note the time and money the full solution will require.
• ▸Rough map: List the actors on the left and the ending on the right, to confirm the challenge can be mapped.
• ▸Required people: List who the problem demands, including expert, operational, and customer-facing roles.
• ▸Week cost: Note what work each person will miss and why the sprint is worth it.
• ▸Decider's go/no-go: Record the Decider's decision and the date.

1. 1Name the Decider before you schedule anything. The Decider is the official decision-maker for the project: at startups usually a founder or CEO, at larger companies a VP, product manager, or team leader. Pick someone who understands the problem in depth and holds strong opinions and criteria. If no one holds that authority, the project may be wrong.
2. 2Get the Decider in the room for the full week. If you are the Decider, clear your schedule. If you are not, make the case with four arguments: rapid progress (a realistic prototype in one week), a one-time experiment she can evaluate afterward, the tradeoffs (a list of the big meetings and work items you will skip or postpone, and why), and focus (an excellent job on one thing instead of an okay job on everything).
3. 3If she cannot spare a full week, fix her cameo slots: Monday, to share her perspective on the problem; Wednesday, to help choose the idea to test; Friday, to watch customers react to the prototype. Do not let her drop any of the three.
4. 4Whenever the Decider will not be present, appoint an official delegate in the room, and make the transfer explicit and written. One CEO emailed her design director: "I hereby grant you all decision-making authority for this project." Absurd, but it added tremendous clarity. One or two delegates are fine.
5. 5On Monday, use the Decider's expertise and vision. She states the core values, the vision, and the criteria she will use to judge solutions. Her input shapes the long-term goal and the choice of target. Do not choose the target without her.
6. 6On Wednesday, have the Decider make the binding choices. She chooses the sketches that best align with the vision, and her supervotes carry decisive weight in the deciding process. The team's straw polls inform her but do not replace her call. This is how the sprint avoids both groupthink and consensus.
7. 7Keep her engaged through Friday. She watches the real-world customer tests firsthand, so she sees the evidence behind the next-step decision. Some Deciders are not excited about customer tests until they see one.
8. 8Treat refusal as data. If the Decider will not even stop by for a cameo, that is a giant red flag. Stop and talk with her about which big challenge would be better.

SquidCo is the failure case. The sprint facilitators invited everyone who worked on the project except Sam, the chief product officer, who was traveling. The week worked for everyone else, so they ran the sprint, built a prototype, and tested it. It did well with customers, and the team was ready to build. When Sam returned, the project ended: he did not think they had picked the right problem, and he saw more important priorities. The facilitators had tried to guess what Sam would say and failed. The Blue Bottle Coffee sprint shows the opposite. CEO James Freeman was in the room to talk about the company's core values and share his vision for an online store that matched their standards of hospitality. He chose the sketches that best aligned with that vision. He also knew how the baristas were trained, a detail that unlocked a surprising solution. The difference is not talent. In one sprint the Decider supplied the criteria and made the choices, and in the other the choice about the problem arrived after the work was done.

• If the Decider can attend the whole week, then require it. If she can only give part of it, then lock Monday, Wednesday, and Friday and appoint an official delegate for the rest.
• If the Decider will be absent for any session, then get an explicit written transfer of decision-making authority to a named person in the room before the sprint starts.
• If the Decider is reluctant, then answer with the argument that fits her objection: rapid progress, a one-time experiment, tradeoffs, or focus.
• If the Decider will not join even for cameos, then treat it as a red flag and reconsider the challenge before starting.
• If the team is tempted to guess what an absent Decider would say, then stop and get her input or her delegate's, because guessing is what sank the SquidCo sprint.

• Scheduling around the Decider's absence, as with SquidCo. The tell: the team says the week works for everyone, and the person who can veto the project is not in the room.
• Substituting guesses for the Decider's input. The tell: phrases like "Sam would probably want..." appear in planning.
• Appointing a delegate informally. The tell: people in the room argue about who gets the final say, or revisit decisions later because authority was never made clear.
• Letting the Decider appear only for the final results. The tell: she sees a finished prototype but never shaped the problem or criteria, so she questions the target after the work is done.
• Accepting a Decider who shrugs off the sprint. The tell: she will not attend even a cameo, yet the team proceeds anyway instead of reconsidering the project.

• ▸Project and big challenge: State in one sentence the problem the sprint addresses.
• ▸Decider (name and title): Name the person with real authority to make binding decisions on this project.
• ▸Why she is the right Decider: Note her depth of understanding of the problem and her opinions or criteria.
• ▸Attendance plan: Mark full week, or list which sessions she attends.
• ▸Monday contribution: Record the vision, core values, and criteria she will share on the problem.
• ▸Wednesday contribution: Record that she will choose the ideas to test and exercise the deciding vote.
• ▸Friday contribution: Record that she will watch customer reactions to the prototype firsthand.
• ▸Official delegate (if any): Name the delegate and attach the written statement granting decision-making authority.
• ▸Objection and response: Note her main hesitation and which argument you will use: rapid progress, experiment, tradeoffs, or focus.

1. 1Start by listing everyone you want in the room, without cutting yet. The passages say a list longer than seven is 'a sign of a strong team,' so over-list first and trim second.
2. 2Lock the Decider before anyone else. Name the person with authority over the project (CEO, founder, product manager, head of design). If she can't attend the full week, have her appear a couple of times and delegate a Decider (or two) who is in the room at all times. If she won't even stop by for a cameo, treat that as a red flag that you have the wrong project.
3. 3Fill the room using the role cheat sheet: Decider, finance expert, marketing expert, customer expert, tech/logistics expert, design expert. You need not cover every role, and some roles can take two or three people. Mix the core people who build the product or run the service (engineers, designers) with a few extra experts who don't normally work on it.
4. 4Test each candidate on two traits: deep expertise and excitement about the challenge. Don't skip someone just because they disagree with you. The sprint process turns competing ideas into an asset.
5. 5Cap the full-time team at seven or fewer. At eight, nine, or more, the sprint moves slower and keeping people focused and productive takes more work.
6. 6Move the overflow to Monday-afternoon visits. Schedule each extra person as an 'expert' for about half an hour to share what they know and give opinions. This feeds the Ask the Experts session while keeping the team small.
7. 7Pick a Facilitator who manages time, conversations, and process, and who is confident summarizing and calling time on a discussion. Do not combine Facilitator and Decider, because the Facilitator must stay unbiased about decisions. An outsider who doesn't normally work with the team often works well, but isn't required.
8. 8Confirm the final seven can all clear their schedules for five days of side-by-side work, since they'll be in the room 'all day, every day.'

At Savioke, the team included the people you'd expect: the roboticists and the head of design. One of the most important contributors turned out to be Izumi Yaskawa, who wasn't part of the team that built the robot. As head of business development, she knew more than anyone how hotels operated and what they wanted from the robot. At Blue Bottle Coffee, CEO James Freeman was the Decider. He shared the core values and the vision for an online store matching their standards of hospitality, chose the sketches that best fit that vision, and knew how baristas were trained, a detail that led to a surprising solution. The customer service manager and the CFO, who normally wouldn't have helped build the website, also supplied important insights. The opposite case is SquidCo: everyone who worked on the project was invited except Sam, the chief product officer, who was traveling. The team prototyped a solution that tested well, but when Sam returned he said they hadn't picked the right problem and the project ended. The facilitators concluded the Decider should have been in the room.

• If you have more than seven people you want involved, then keep the seven who build or decide for the full week and schedule the rest as half-hour Monday-afternoon experts.
• If the Decider can't attend the whole sprint, then have her make a couple of appearances and delegate a Decider (or two) who stays in the room at all times, with explicit transfer of decision-making authority for the project.
• If the Decider won't join even for a cameo, then stop and reconsider the project; the passages say you may have the wrong challenge.
• If you're choosing between two candidates, then favor the one with deep expertise and enthusiasm over the one who simply agrees with you or normally sits on the team.
• If you are the Decider, then don't also act as Facilitator; give the role to someone unbiased, ideally an outsider who doesn't normally work with the team.

• Guessing what an absent Decider would say. The tell: the team is confident in the solution but nobody with authority has seen the problem choice, as in SquidCo, where the project ended on Sam's return.
• Staffing only the people who normally work together. The tell: the room contains no one who knows the customers, money, or messaging, such as Izumi's hotel knowledge or Blue Bottle's CFO and customer service manager.
• Letting the team grow past seven. The tell: the sprint moves more slowly and you're working harder to keep everyone focused and productive.
• Excluding people because they disagree with you. The tell: the room is unanimous early, so competing ideas never get to become an asset.
• Merging Decider and Facilitator, or leaving the Facilitator undefined. The tell: no one is summarizing discussions or ending debates, or the person running time also has a stake in the decision.

• ▸Decider (and delegate): Name the person with decision authority and any delegate who will be in the room at all times; note when the Decider will appear if not full-time.
• ▸Facilitator: Name an unbiased person (not the Decider) who will manage time, conversations, and process.
• ▸Core builders: List the engineers, designers, or operators who build the product or run the service.
• ▸Finance expert: Who can explain where the money comes from and goes?
• ▸Marketing expert: Who crafts the company's messages?
• ▸Customer expert: Who regularly talks to customers one-on-one (researcher, sales, support)?
• ▸Tech/logistics expert: Who best understands what the company can build and deliver?
• ▸Full-time headcount check: Count the people in the room all week; must be seven or fewer.
• ▸Monday experts overflow: List each extra person, their specialty, and their scheduled half-hour slot on Monday afternoon.

1. 1Name the single challenge the week answers, in one question. Savioke's was 'How should our robot behave around humans?' Every calendar decision below serves that question and nothing else.
2. 2Block Monday to Friday for every person on the sprint team. Seven people or fewer, since more slows the sprint and costs you extra effort to keep everyone focused. Cancel the meetings. Do not move them to 'before or after'. The goal is no context switches between projects and no random interruptions.
3. 3Have each person set an 'out of office' responder on email for the full week, as Savioke did. This removes the pull to check in and tells colleagues the absence is deliberate.
4. 4Manufacture a deadline. Book something external for Friday, such as Savioke's live test at a hotel with real customers. That leaves four days to design and prototype and puts real pressure on the schedule.
5. 5Timebox each day to the six-hour structure. Write the day's agenda on the wall before people arrive, and hold the start and end. The bounded day is what lets people clear everything else around it.
6. 6Announce the no-device rule before the sprint begins, with its two exceptions: devices are fine during breaks, and anyone can leave the room at any time to take a call or check email, no judgment. Tell people about the escape hatch up front so busy people can still commit to the week.
7. 7Reserve devices for two purposes: showing something to the whole team, and Thursday's prototyping. Everything else happens on paper and walls.
8. 8Inspect the room before the sprint. It needs whiteboards, and they must be big, clean and equipped with markers that work. BadgerCo's three-foot, grayish-pink board with worn-out markers could not hold a customer-discovery map and a subscription-plan diagram at once.

Savioke's team was building a hotel delivery robot, the Relay, and had only a few weeks before a pilot with Starwood. They cleared a full Monday-to-Friday week, canceled all meetings and set 'out of office' responders on email. They then manufactured a deadline by arranging with the hotel to run a live test on Friday, which left four days to design and prototype a working solution. All of that attention went to one question: how should the robot behave around humans? On Monday they mapped the story, from guest meets robot to guest falls for robot. With only five days, Steve chose a narrow target, the moment of delivery, rather than spreading effort across the lobby, elevator and hallway. Because meetings and email were out of the picture, they were able to review the problem, choose a target, decide among ideas and build a realistic prototype in one day, then test it with target customers in a makeshift lab at a nearby hotel.

• If a team member says they cannot clear all five days, then treat it as a team-composition problem and replace them with someone who can be in the room all day, every day. Do not run a patchwork sprint.
• If someone needs to stay reachable for their regular job, then do not loosen the device rule. Point to the two exceptions: use devices on breaks, or step out of the room at any time.
• If your team is larger than seven, then cut it. At eight or nine or more the sprint slows and you work harder to keep people focused.
• If no external event forces a finish, then create one by scheduling the customer test for Friday before the week starts.
• If the available room has a small or dingy whiteboard or dead markers, then fix it before Monday by buying large writing surfaces and fresh markers. Do not improvise mid-session by taping notebook paper to the wall.

• Clearing the calendar only partly, by keeping 'just one important meeting' per day. The tell: people disappear mid-morning and return needing a recap, so the group keeps restarting. The studies cited put recovery from an interruption at about twenty-three minutes on average.
• Imposing a device ban without the escape hatch or advance notice. The tell: busy people decline the sprint or sneak glances under the table, because the rule feels like a trap.
• Allowing devices to creep back in beyond the two exceptions plus whole-team demos and Thursday prototyping. The tell: heads down in laptops while someone presents at the board.
• Holding the sprint in a nice room with poor whiteboards. BadgerCo's polished office still failed: the map filled the board, the subscription diagram did not fit, and Braden ended up writing cramped words in the margins. The tell: you stop mid-session to hunt for space or supplies.
• Skipping the manufactured deadline, so the week has no pressure and drifts. The tell: nobody can say who will see the work on Friday.
• Starting without one sharp focus. The tell: the team debates scope on Wednesday, when it should be deciding between solutions. Savioke avoided this by picking one target moment, delivery, on Monday.

• ▸Challenge question: Write the single question the week answers, in one sentence.
• ▸Team (7 or fewer): List each person and confirm they are free Monday to Friday.
• ▸Calendar cleared: For each person, mark yes or no for meetings canceled and 'out of office' set.
• ▸Friday deadline: Name the external event or customer test that forces the finish, and who has confirmed it.
• ▸Daily six-hour timebox: Write the start and end time you will hold each day.
• ▸Device rule announced: Record the date and how people were told, including the two exceptions (breaks, leave the room anytime).
• ▸Allowed device uses: List the whole-team show-and-tell moments and confirm Thursday prototyping.
• ▸Room check: Note whiteboard size and condition, working marker count, and what you must buy to fix gaps.
• ▸Escape-hatch spot: Name where people go to take calls and check email outside the room.

1. 1Clear the week and seat the right people before you frame anything. Savioke canceled all meetings and set out-of-office replies from Monday to Friday. Blue Bottle's CEO James brought in the COO, CFO, communications manager, customer service lead and executive chairman, and sat in the room himself. Keep the group small: Jake Knapp's first sprint had forty people and nearly derailed before it began.
2. 2Start at the end by writing the long-term goal. State what the business needs to be true if the work succeeds, in terms the team already tracks. Savioke's version: guest satisfaction, which hotels track religiously. If the Relay robot raises it, hotels order more robots. If it stays flat or falls, the business is in a precarious position.
3. 3Turn the goal into sprint questions. List the make-or-break questions you need answered this week, and the biggest worries that keep resurfacing. Savioke's core question was how the robot should behave around humans, and its repeated worry was making the robot seem too smart. Blue Bottle's was how to organize the coffee when no barista is there to help.
4. 4Draw the customer-centric map as a story. Name the customer and write the steps from first contact to outcome. Savioke's read: guest meets robot, robot gives guest a toothbrush, guest falls for robot. Mark the moments where customer and product first interact (lobby, elevator, hallway). Map the whole experience, not components or technologies.
5. 5Pull in what people know while you map. Review everything the team knows about the problem. Let each person say what they know, including personal expertise: Braden admitted he is a coffee obsessive with a home scale, and that changed how the team thought about organizing coffee. Hang questions and risks on the map where they occur.
6. 6Choose one target: a single customer and a single moment on the map. Pick where effort buys the most. Savioke's Steve chose the moment of delivery: get it right and the guest is delighted, get it wrong and the front desk answers confused travelers all day. Blue Bottle chose a new customer who had never heard of the brand, because if that case works, every other case is easier.
7. 7Check the target against the goal and the questions. Confirm that the chosen customer-and-moment can move the long-term goal and answer the sprint questions. Confirm you can recruit that kind of customer for Friday's test, as Savioke recruited target customers and ran a live test at a hotel. Then commit: everything Tuesday through Friday aims at this target.

Savioke Labs built Relay, a three-and-a-half-foot robot that glides through hotels, and had only a few weeks before a Starwood pilot. The team cleared the week and agreed to run a live test at a hotel on Friday. On Monday they started at the end: Steve, the CEO, explained that guest satisfaction scores decide whether hotels order more robots, and flat or falling scores would leave the business precarious. The sprint question was how the robot should behave around humans, and one worry kept coming up: guests expecting a C-3PO or WALL-E and being disappointed when the robot doesn't talk back. They mapped the story as guest meets robot, robot gives guest a toothbrush, guest falls for robot, with critical moments in the lobby, elevator and hallway. With five days, they had to pick one place to focus, and Steve chose the moment of delivery. That choice set up the Tuesday sketches, the twenty-three competing solutions, and the Friday hotel test.

• If the team cannot agree on a target, then the Decider chooses after hearing the map and the experts, as Steve did at Savioke and James did at Blue Bottle. Don't spend the day negotiating.
• If you must choose between an easy scenario and a hard one that matters, then pick the hard one when solving it makes the rest easy by comparison. Blue Bottle chose the new customer who had never tasted their coffee.
• If a moment on the map has high stakes in both directions, then favor it. At Savioke the moment of delivery produced delight or front-desk confusion, so it got the target.
• If a worry keeps resurfacing, then turn it into a sprint question. Savioke's fear of the robot seeming too smart was raised repeatedly and stayed in view.
• If the room is large or lacks the people who know the business, then fix the team before mapping. A forty-person sprint nearly derailed, and Blue Bottle gathered its operations, finance, communications and customer service leads.

• Mapping components or technologies instead of the customer's story. Tell: the diagram shows features and systems, and no customer moves from first contact to outcome.
• Refusing to choose, so every moment gets covered. Tell: Tuesday sketches scatter across the whole experience and Friday's test would need several different customers.
• Skipping the long-term goal and going straight to the map. Tell: no one can say which result, such as hotel orders following satisfaction scores, would make the sprint a success.
• Letting an unspoken assumption stand as the answer. Tell: someone says 'obviously' and the team moves on, as Blue Bottle nearly did when it assumed coffee is organized by region.
• Too many people in the room. Tell: framing drags, and the team is large because everyone was invited rather than needed.

• ▸Long-term goal: what must be true if this work succeeds, in the business's own measure (e.g., satisfaction scores rise and customers reorder).
• ▸Stakes if it fails: what happens to the business if the number stays flat or falls.
• ▸Sprint questions: the make-or-break questions this week must answer (e.g., how should the robot behave around humans?).
• ▸Biggest worries: concerns that keep resurfacing (e.g., the robot seems too smart).
• ▸Customer and story: who the customer is and the steps from first contact to outcome, written as a sentence.
• ▸Critical moments: the points where customer and product first interact (lobby, elevator, hallway).
• ▸Expert notes: what each teammate or expert knows that changes the map.
• ▸Target customer and moment: the one customer and the one moment you choose.
• ▸Why this target: how it serves the goal and answers the questions, and the reason it is the right place to focus.
• ▸Decider and Friday fit: who made the call, and where you will find that customer for the Friday test.