Book Summary: “Sprint” by @jakeknapp

Smashing R+D timelines down to just 5 days

Sprint (2016)

Awesome how-to manual on iterating solutions quickly through a crisp, minimum-viable-prototype process. We’ve all likely been part of (and complicit in) traditional corporate problem solving projects…. initiatives that feel very clever but take hundreds of resource hours stretched over 6+ months of research, approvals, meetings, focus groups, etc. Here’s a way to crush it in literally five days at a fraction of the cost:

The Sprint process — see

That visual pretty much says it, but if you’re going to run a Sprint, of course read the actual book — there’s a LOT of granularity to facilitating this properly. Below are my favourite takeaways:

Sprints work in situations of high stakes, not enough time, and when you’re just plain stuck. First, assemble a team of MAX 8 ppl, ideally <7:

  • Marketing
  • Sales
  • Engineering
  • Customer Support
  • Designer
  • Decision Maker (KEY role)

Day 1: Map & Define Problem

  • Align on end goal
  • Invite 5 external customers for Friday
85% of patterns in feedback show up in sample set of just 5 (Jakob Nielsen)
  • Try to find some internal and external experts to answer key questions. Include experts who represent strategy, voice of customer, how things work, past efforts

Day 2: Create Solutions

  • “R+D = Rip off + duplicate” (thanks David Reeve)
  • Sketch competitor solutions in detail (include analogous industries), then mix and match to splice together a NEW solution
  • Brainstorming is useless — instead, work alone, together → when the whole team works in parallel, they’ll generate competing ideas, without the groupthink of a group brainstorm

Day 3: Down-select

  • Decision Maker supersedes the group with “super votes” and picks up to 3 options to continue with — without this mechanism you get solutions that have been sanitized by consensus

Day 4: Put it all together and build mockup

  • Build just enough to learn, but not more
  • When too complex, you can use the “brochure façade” — instead of the actual thing, prototype the brochure that will be used to sell that thing (if you’ve procured enterprise software, you may be painfully familiar with being sold something that doesn’t actually exist — there’s one vendor in particular who’s notorious, but they get to keep anonymity here as I’d prefer not dealing with their army of lawyers)

Day 5: Observe customer reactions, and learn!

  • What do you think about what just happened?
  • How would you compare this against other options?
  • What worked? What didn’t?
  • Would you buy this?
  • Observe reactions rather than just listening to feedback
Show your support

Clapping shows how much you appreciated Tom Dvorak’s story.