Last week, we co-hosted a design sprint workshop with the creator himself, Jake Knapp. Despite reading and re-reading his book, staying up to date with Sprint Stories happening throughout the community, and being a part of several sprints of my own, I still learned things from Jake that I wouldn’t have gotten anywhere else.
A few days before the workshop, our Director of UX spoke at a meetup in Boulder on “What I’ve learned from Jake Knapp.” Knowing what we do now, I wish we could add to that conversation, so instead, I’ll share it here.
Your prototype is likely to fail the first time
In many of Jake’s examples of previous sprints, when he gets to the end result, you see a lot of red—the tests failed. He urges you not to panic, and to remember that you are doing this sprint for the sake of learning. If your prototype fails on Friday, that’s a huge takeaway. It is incredibly more beneficial to test an idea that fails after a week, rather than testing an idea that fails after spending months of time, effort, and investment working towards a dead end.
A failure is great news for your team. It will help you refine your prototype and guide you towards seeing green the next time you test. Jake uses the analogy that your first sprint is like throwing a dart in a dark room. You have no idea where you’re aiming, and there’s a really good chance you’ll miss. But after you’ve thrown, the light comes on, and you get to try again. You have a much better chance of hitting the target now.
“Even if you’re wrong the first time, the sprint process will help you light up your future path.” – Jake Knapp
Your team doesn’t necessarily need to do any prep work
Sprints require a ton of work. Five 8-hour days of uninterrupted effort, to be exact. However, they don’t require your team to do any sort of preparation. It’s possible that there may be time constraints that merit participants coming into the sprint with some homework done, but the process should eliminate the need for any work upfront.
It’s actually beneficial to have your team come in with a clean slate, an open mind. This attribute of sprints might be helpful for someone looking to get buy-in to do one in the future. You just need a problem to solve and a team willing to work for a week—no prep time required.
The facilitator should restate a question twice…or even three times
This was probably my biggest takeaway. The first time you ask your team a question or give them an instruction is a throwaway. Assume it went in one ear and out the other. People, even the best listeners, will benefit immensely from you repeating the instruction so they can either grasp it better, hear anything they may have missed, and/or shift their focus to what the desired response is.
When I’ve led sprints in the past, participants asked many questions throughout. While that was a good sign that they were actively participating, it was also a sign that maybe I wasn’t explaining clearly enough. Throughout Jake’s 9 hour workshop, I don’t think a single participant asked him to repeat or better explain one of his instructions. Instead, they asked thoughtful, contextualized questions to their unique experiences with sprints.
That’s because he repeated everything. And repeated again.
The office supplies matter
Jake is very specific about the type of supplies he recommends for sprints. There’s a reason behind each of these recommendations, though, and it was enlightening to find out why the size of the markers and the color of the sticky notes matter.
He’s a designer by trade, so these choices are very well informed by an understanding of perception and human interaction. The size of the marker matters because you don’t want one piece of paper or sticky note to stand out as “bold” and therefore seem more important, and another to be glanced over because it was too light and hard to read. Using the same size marker evens the playing field and makes everyone’s work noticeable and easy to read.
A similar logic applies to the sticky notes. If they are all yellow, participants aren’t wasting time trying to figure out why this one’s green and that one’s pink—everyone’s contributions are weighted evenly, all the same color.
I’m a logical person. I really wanted to know the meaning behind his choices. Now that I know the “why,” I’d highly recommend using all of Jake’s recommended supplies for running a sprint.
A lot of the early activities are “Structural Support”
With sprints, I’ve learned to trust the process. Almost to a fault. It’s difficult to want to deviate, even a little bit, when they’ve proven to work so well. When Jake shared this insight, I relaxed a little. He listed out all of Monday’s activities, and said that the Sprint Questions, the Map, and the Sprint Target are what really matter here. The rest of the activities, while important, are “structural support”—they don’t have to be perfect.
Don’t spend too much time getting granular with all the little steps. Keep in mind what the sprint goal is, what you’re trying to get out of the week, and what the next step is, so you can efficiently move forward in your sprint.
The mapping & storyboarding processes got an upgrade
Jake shared some insider-only insights with us: he made some updates to what’s in his book, Sprint. The first applies to the Mapping process.
Instead of just starting with customers/actors on the left, the end goal on the right, and filling in the middle as you see fit to reach that goal, Jake added more of a framework.
By adding in Discover, Learn, and Start as categories to guide the steps an actor will take to reach the goal on the right, he reframed the map to consider everything as “shopping” (more on where that came from here). The Discover phase is where the user might find out about the thing/product/service/etc., i.e. a Facebook ad. This is a passive step. The Learn phase is where a user might learn more about it, by actively seeking it out, i.e. a marketing page. The Start phase is a user would take an action to interact with it, i.e. buy it.
With this improvement, the map now clearly walks each actor through the process from discovery to learning to action, towards the overall sprint goal. This is an extremely helpful refinement to the mapping process, adding in more structure where I previously felt it was lacking. Jake also urges you look further upstream than you might think to hone in on your sprint target. This updated version of the map is useful in helping visualize that, as he advised us to look in the Learn category for our target in the workshop.
The second major update from the book applies to the storyboarding step. AJ&Smart, a product design agency in Berlin that uses design sprints to solve their clients’ toughest problems, has reimagined the storyboarding process. Having run so many sprints of their own, they began refining the storyboard phase along the way, and came up with the Storyboard 2.0, which Jake wholeheartedly adopts.
In the storyboard phase, you are instructed to sketch out the entire journey of your solution, with enough detail for your team to turn that sketch into a prototype. It’s probably one of the most arduous parts of the whole sprint, and involves a lot of back-and-forth amongst the team.
Version 2.0 lets everyone collect their thoughts independently before coming together on the whiteboard. So, each participant takes 8 sticky notes and writes out one key user action on each, from discovery to completion of the sprint target. Then, everyone sticks their “timeline” on the board for the team to compare. All the Step 1s will not be the same—some points will require more discussion, but patterns will emerge and become the basis for the storyboard.
This new version applies the sprint methodology of “working alone together,” by adding in this step of independent work before coming together to collaborate. Similar to the updates to the Map, it adds structure where it’s lacking, and has been proven by the team at AJ&Smart to improve results and save time.
When you choose the solution you’ll prototype, justify it
Although a small nuance, this part really stuck out to me. Wednesday is Decision Day in a sprint, and it requires a huge team effort to come to a decision that everyone feels confident to move forward with. The nuance Jake added here is to have each team member justify why they feel X or Y solution is the one they should prototype and test.
This will merit some discussion, but it offers everyone the opportunity to explain their choice and perhaps even persuade the Decider if he/she feels differently. It also ensures everyone does, in fact, have a justification for their choice—whatever solution your team moves forward with, it should be for a reason.
“Let’s pause this conversation” is a great euphemism
Team discussions can go on, and on, and on, and…you get the point. While the sprint framework sticks to a tight schedule and has processes in place to keep things moving forward, it’s almost inevitable that your team will get stuck on some topic or point of disagreement and spend way too much time trying to talk it out.
“Let’s pause this conversation” is Jake’s way of respectfully telling everyone to, well, shut up and move on. You most likely won’t come back to that point, but it allows the discussion to end fairly, with the prospect that the team can return to it. It will save time, people’s feelings, and unnecessary conversations that are going down the wrong path.
Sprints are a kind of Trojan Horse
Sprints are many things, but this was a new way of thinking about them for me. Sprints are a “Trojan Horse” to make teams actually watch their customers interact with their products or services.
One of the biggest struggles we face in any business is in trying to understand the customer we are marketing to. Sprints lift that curtain, forcing you to see with your own two eyes how your customers are using what you’re offering, what they like and what they don’t like.
Old ideas are often the best ideas
I don’t think this is a particularly groundbreaking takeaway, but it is very significant. I read this in Jake’s book, and while I’ve made a note if it in the sprints I’ve been in, it never really stuck until hearing him talk about it.
Old ideas exist for a reason—maybe they came up at a time when your company wasn’t ready to act on them, maybe the leadership team didn’t agree with them, maybe a thousand other ideas won out because the old idea came from the lowest person on the totem pole. None of those are good reasons to throw the old idea away. In fact, it’s probably a well-informed idea about your business problem.
Old ideas may require refinement to bring them up to date with your current brand positioning or goals, but they are often a gold mine of a starting point. Don’t be afraid to look back and resurface the “could have beens.” They just might become the “should and will bes.”
High fives are underrated
While this one might not seem that important, it was amazing to watch the smiles and positive interactions that occurred each time Jake instructed us to high five our team members.
In the beginning of the workshop, Jake told us how he used to struggle with high fives, awkwardly missing, or choosing to avoid them altogether and would leave someone hanging. He then learned that if you look at the other person’s elbow, you have a much better chance of making contact every time. After a quick demo, we all got the chance to try it out and high five our table-mates.
After every major activity in the workshop, Jake told us to high five around our tables again, and our table-mates quickly became our teammates. We shared this small moment of celebration everytime we reached a milestone in our sprint, working through the process together. The smacks of contact would fill the room and you could feel the energy instantly recharge. Everyone was proud of what they’d accomplished (including successful high fives).
This small action can have a big impact, and it’s something we can all apply more in our everyday lives, outside of sprints. We’re all working hard, burdened by deadlines, buried under big tasks and long days. Celebrate the small wins. High five your team members. You’re way more than table-mates—you’re in this together, solving big problems and important challenges.
You should reward yourselves for that.