Sprint

Review

I have a real soft spot for this book. I read it shortly after publication, just in time to apply it to some discovery work I was running. It is one of the few methodology books I have returned to more than once and found something new to use each time. The rigidity of the five-day format can frustrate more experienced practitioners, but for anyone setting up their first structured discovery sprint, that rigidity is the point. What really elevates it is the facilitation layer. There are dozens of small techniques embedded in here: how to run a silent review, how to use dot voting without anchoring bias, how to keep a Decider from derailing a room. You could spend years learning these the hard way. Worth the read, and worth re-reading.

Key Takeaways

The parts worth keeping

• Don't build a minimal product to validate an idea. Get real data from a realistic prototype first, before making expensive commitments.
• A Sprint helps you assess what customer reaction to your product will actually be. Sprints that fail provide huge value by quickly identifying critical flaws before you build anything real.
• Focus on the biggest question. Go after your most important problem. The bigger the challenge, the better the Sprint.
• Solve the surface first. Get the customer interaction right, then work out backstage systems later.
• Limit your team to 7 people or fewer. Include builders and a blend of expertise. Bring the troublemaker.
• Clear the entire week. Same space, no devices in the room, plenty of whiteboard.

The Sprint Framework

Monday: Map

• Set a long-term goal: Why are we doing this project? Where do we want to be in 6 months, 1 year, or 5 years?
• Capture the difficult questions that must be answered. What assumptions need to be true for us to succeed? What are the reasons this project might fail?
• Create a map of the experience from beginning to end. List the actors on the left, write the ending on the right, add words and arrows in between, keep it simple.
• Interview a range of stakeholders about the problem space. Knowledge is distributed: nobody knows everything.
• Choose a target for your Sprint. Narrow to the most important customer and most critical moment. Cluster How Might We notes to make the focus clear, then add the best ones to your map.

Tuesday: Sketch

• Start with lightning demos for inspiration: 3 minutes or less per person, covering what they find interesting inside or outside your industry. Capture big ideas on a shared whiteboard.
• Work alone together when generating solutions. You produce more ideas in parallel, and individual thinking avoids early anchoring on group consensus.
  • Four-Step Sketch:
    1. Gather key info in note form (20 mins)
    2. Doodle rough solutions (20 mins)
    3. Try rapid variations using Crazy Eights: fold paper into 8 panels and sketch one idea per panel (8 mins)
    4. Figure out the details and draw a full solution sketch (30+ mins)
  • The best sketches are self-explanatory, kept anonymous, worded carefully, and given a catchy title.

Wednesday: Decide

• Put sketches on the wall. Everyone reviews in silence and uses dot stickers to mark interesting parts. Each solution gets a 3-minute highlight discussion, and participants capture big ideas on sticky notes.
• Each person votes for one solution with a sticker. The Decider makes the final call, also by voting with stickers.
• If more than one great idea survives, either combine them or build both and test them against each other.
• Storyboard the winning idea in 15 frames. Choose an opening scene, fill in all the detail, and confirm the story can be tested in 15 minutes.

Thursday: Prototype

• Build a prototype that looks real enough to get a genuine reaction. Goldilocks quality: just enough time to make it feel real, not so much that you are polishing something you might throw away.
• Focus on the facade: the part the customer actually interacts with. Backstage systems can wait.
• Assigning roles speeds up the build:
  • Maker: creates individual components
  • Stitcher: collects and combines components seamlessly
  • Writer: makes all text realistic
  • Asset collector: grabs images, icons, and sample content
  • Interviewer: writes the interview script
• Stitch everything together at the end. Make sure the story is internally consistent: numbers, dates, prices.

Friday: Test

• 85% of problems are exposed after just 5 interviews. Fix what you find, then test again rather than adding more participants to the same round.
• Interviews tell you whether the product works and why. Be friendly, curious, and genuinely open to having your assumptions proved wrong.
• The five-act interview:
  1. A friendly welcome
  2. Open-ended context questions about the customer
  3. Introduce the prototype (make it clear you want frank feedback)
  4. Tasks designed to get the customer reacting to the prototype. Useful prompts: "What's this?" "What do you think that's for?" "What do you expect that will do?"
  5. A quick debrief: How does it compare to what you do now? How would you describe it to a friend? If you had 3 wishes to improve it, what would they be?
• Collect insights on a whiteboard grid. Columns are customers, rows are parts of your product or experience. Color-code stickies: green for positive, red for negative, black for neutral. Look for patterns across columns.
• At the end, review your long-term goal and Sprint questions. Can you answer them now?

Every interview draws you and your team closer to the people you're trying to help with your product or service