As I became more and more interested in product development, I found the book Sprint, by Jake Knapp, John Zeratsky, and Braden Kowitz. I am familiar with agile practices, and understand the practice of two week software sprints to work towards a customer software release, but the one week design sprint was new to me. Sprint details a process to find answers quickly to - typically - business case questions, aiming to provide a successful prototype quickly. I’ve identified six categories regarding what I learned and points that stood out to me.

Golden Nuggets

Several points in the book allowed me to reflect on having the proper mindset, and planning my day in order to be productive. Distractions are everywhere, and providing a bit of strutcure can help mitigate those urges to detract from the task at hand. It takes approximately “23 minutes for distracted workers to return to the task at hand” (39). For me, my distractions include a pressure to reply to a recent Slack message immediately, beginning to work on a more “fun” task than the one I really should be working on, and checking email too often. All of this task fragmentation impedes my ability to get focused and find my flow state. I’m the most productive in my flow state, and it’s easier to find that flow state when I’m motivated. As the authors write, “you probably feel the most productive when you’re doing” something “you’re especially good at” (218). It’s so important to me to enjoy what I do, so that I’m all the more motivated to get tasks done, and enjoy the process of working towards completion. Having “six working hours in the typical sprint day” is a reminder to myself to prioritize quality over quantity when it comes to work (39). It’s a reminder to work with myself and listen to my body. If I’m working for 20 minutes, but all I’m doing is metaphorically banging my head against the wall, am I really working? I’m certainly not making progress on the task I had laid out before me. I’m tired or struggling to find motivation, and now may be stressed, having seemingly wasted the last 20 minutes. Take a break from that task and revisit it later. The authors suggest to “run a sprint anytime you’re not sure what to do, struggling to get started, or dealing with a high stakes decision” (230).

Sprint Focus

Before you begin, it’s helpful to understand the end goal you’re working towards. As the authors put it, “start at the end” (55). I really like the mindset of turning the problem into questions - putting the issue at hand in a more positive light - moving beyond stating that there is a problem, and following up with being open to accepting possible solutions. This is imperative to my work on a daily basis, and likely that of many others. These questions are called your sprtint questions. What questions do you “want to answer in this sprint?” (57). “Turning these potential problems into questions make them easier to track - and easier to answer with sketches, prototypes, and tests. It also creates a subtle shift from uncertainty (which is uncomfortable) to curiosity (which is exciting)” (57-58). After brainstorming sprint questions, you’ll move on to “choose a target for your sprint” (84). With a week where you have your team’s undivided attention because all other meetings have been erased from the calendar, what do you want to build a prorotype for and test at the end of the week, knowing you have a group of people’s precious time for 5 days? After you’ve selected a target, review the list of sprint questions; “one or more should line up with the target” (88). This question will be your guiding light, as it’s the question you’re looking to answer by the end of the week.

Facilitator

As a project manager, I took a keen interest in the facilitator role, which comes with its own ABC slogan: “always be capturing” - a quote by Josh Porter (89). (In sales, ABC refers to always be closing.) A great way to capture ideas is to press your team further, even when the answer may seem obvious. Pretend you’re an outsider, who isn’t familiar with any of the topics the team is familiar with (90). This runs in the same vein as the Five Whys technique when pressing to find root cause or explore underlying cause-and-effect relationships. Put simply, ask “why?” multiple times to dig deeper into what the underlying issue may be. In addition to asking why, “ask open-ended questions” and steer away from any leading questions (212). While extracting thoughts from people’s heads, it’s also the facilitator’s role to ensure the group stays on track, focused on the agreed upon task at hand. In terms of a design sprint, prevent new ideas creeping in during middle of sprint. When someone brings up something that detracts from the design sprint task at hand, acknolwedge it as a valid point, take note, but table for now - perhaps this will be something that gets discussed in the coming weeks, but for now, it’s time to focus on the design sprint (159). This acknolwedgement, taking note, and tabling discussions is also an important practice in meetings. You show respect to the individual who introudced it, and as it’s deemed appropriate, schedule another meeting - dedicated time to discuss this new item.

Decision Making

Parkinson’s Law states “work expands so as to fill the time available for its completion,” as stated by Cyril Northcote Parkinson himself in an essay entitled Parkinson’s Law, published in The Economist in 1955. When you must identify an issue, build a prototype, and test it all in one week, quickly making decisions is crucial. One way to cut down on the decision making feedback loop is to restructure how solutions are identified and evaluated. The authors suggest to share all possible solutions up front, instead of intiating discussions surrounding a few, and identifying other ideas as a result of earlier discussions. This way, all cards are layed out on the table from the beginning, and all solutions are critiqued together, allowing a decision to be made more quickly (128). The authors then outline how to go about making the decision to identify which components of various solutions the team should move forward with:

  1. Art museum: Put the solution sketches on the wall with masking tape.

  2. Heat map: Look at all the solutions in silence, and use dot stickers to mark interesting parts.

  3. Speed critique: Quickly discuss the highlights of each solution, and use sticky notes to capture big ideas.

  4. Straw poll: Each person chooses one solution, and votes for it with a dot sticker.

  5. Supervote: The Decider makes the final decision, with - you guessed it - more stickers. (131)

The points that stand out to me about this five-step process are:

  • The speed critique for each solutions lasts for just three minutes (136)
  • The Decider (example: product manager/owner) must make honest decisions - it’s up to them to take in the feedback from the group, and decide if they agree with the consensus or not (140)
  • Test early. Whether it turns out to be a dud or spectacular, “it’s better to find out early” (168). This reminds me of one of my favorite quotes from the author Jen Sincero: “Deciding is freedom. Indecision is torture.”

Best Practices

  • Set the team up for success by building your line-up. An important common trait to have amongst members of the sprint team is that they have expertise. They have unique backgrounds that enable them to be invaluable members of the team (33).

  • As much as the team is chomping at the bit, excited to execute solutions, ensure the design sprint’s priorities are sorted first - lay out the plan, before jumping in (54-55).

  • The knowledge about the challenge you’re tackling is distributed amongst those familiar with it. Gather information from indiviudals who are included in the sprint team, along with individuals who are not included, but also have insights into the challenge at hand (68).

  • Work alone, together: have individual brainstorms in the same room. Give individuals time to think and brainstorm ideas without being interrupted by one another (107).

  • Be optimistic when prototyping. You’ll find “some way to prototype and test your product” (169).

  • Reactions are much more valuable than feedback during a test. Pay close attention to how test subjects interact with the prototype (170).

  • When something appears to not be successful, it may be because “there’s [a] gap between the vision and the customer,” to quote Joe Gebbia, co-founder of Airbnb. Remedy that by talking to people (211).

Tools

  • Time Timer: a visual timer that shows the passage of time with a red disk (47)

  • Map it out: include the key players and major steps of the story or sequence of events (65)

  • How Might We (HMW) exercise: convert something interesting you heard into a question; capture “a problem and convert it into an opportunity” (75, 78)

  • Storyboards: “use your storyboard to imagine your finished prototype, so you can spot problems and points of confusion before the prototype is built” (149)

  • Color coding: color code observations (green = positive, red = negative, black = neutral) (220)