My best work happened when I had a big challenge and not quite enough time. (Location 70)

Instead of waiting to launch a minimal product to understand if an idea is any good, our companies get clear data from a realistic prototype. (Location 246)

Tags: prototype

Note: .prototype launch a prototype early to get feedback

On Monday, you’ll map out the problem and pick an important place to focus. On Tuesday, you’ll sketch competing solutions on paper. On Wednesday, you’ll make difficult decisions and turn your ideas into a testable hypothesis. On Thursday, you’ll hammer out a realistic prototype. And on Friday, you’ll test it with real live humans. (Location 256)

First, the sprint forces your team to focus on the most pressing questions. Second, the sprint allows you to learn from just the surface of a finished product. (Location 375)

Get that surface right, and you can work backward to figure out the underlying systems or technology. (Location 381)

To build the perfect sprint team, first you’re going to need a Danny Ocean: someone with authority to make decisions. That person is the Decider, a role so important we went ahead and capitalized it. The Decider is the official decision-maker for the project. At many startups we work with, it’s a founder or CEO. (Location 392)

Tags: sprint

Note: .sprint you need the key decision maker

If the Decider agrees to the sprint but can’t spare a full week, invite her to join you at a few key points. On Monday, she can share her perspective on the problem. On Wednesday, she can help choose the right idea to test. And on Friday, she should stop by to see how customers react to the prototype. (Location 421)

If she’s only going to make cameo appearances, your Decider needs to have an official delegate in the room. In many of our sprints with startups, the CEO appoints one or two people from the sprint team to act as Deciders when she’s not there. (Location 423)

Ocean’s Seven We’ve found the ideal size for a sprint to be seven people or fewer. With eight people, or nine, or more, the sprint moves more slowly, and you’ll have to work harder to keep everyone focused and productive. With seven or fewer, everything is easier. (Yes, yes – we know there were eleven people in Ocean’s Eleven. It was just a movie!) (Location 433)

Tags: sprint

Note: .sprint 7 people or less

Sprints are most successful with a mix of people: the core people who work on execution along with a few extra experts with specialized knowledge. (Location 439)

Recruit a team of seven (or fewer) Choosing whom to include isn’t always easy, so we’ve created a cheat sheet. You don’t have to include each and every role listed here. And for some roles, you might choose two or three. Just remember that a mix is good. Decider Who makes decisions for your team? Perhaps it’s the CEO, or maybe it’s just the “CEO” of this particular project. If she can’t join for the whole time, make sure she makes a couple of appearances and delegates a Decider (or two) who can be in the room at all times. Examples: CEO, founder, product manager, head of design Finance expert Who can explain where the money comes from (and where it goes)? Examples: CEO, CFO, business development manager Marketing expert Who crafts your company’s messages? Examples: CMO, marketer, PR, community manager Customer expert Who regularly talks to your customers one-on-one? Examples: researcher, sales, customer support Tech/logistics expert Who best understands what your company can build and deliver? Examples: CTO, engineer Design expert Who designs the products your company makes? Examples: designer, product manager (Location 446)

Tags: team, sprint

Note: .sprint .team

The Facilitator needs to remain unbiased about decisions, so it’s not a good idea to combine the Decider and Facilitator roles in one person. It often works well to bring in an outsider who doesn’t normally work with your team to be the Facilitator, but it’s not a requirement. (Location 486)

Note: Have a different decider to facilitator

You’ll start at 10 a.m. and end at 5 p.m., with an hour-long lunch in between. That’s right: There are only six working hours in the typical sprint day. Longer hours don’t equal better results. By getting the right people together, structuring the activities, and eliminating distraction, we’ve found that it’s possible to make rapid progress while working a reasonable schedule. (Location 516)

The no-device rule In a sprint, time is precious, and we can’t afford distractions in the room. So we have a simple rule: No laptops, phones, or iPads allowed. (Location 534)

To make sure nobody misses anything important, there are two exceptions to the no-device rule: 1.  It’s okay to check your device during a break. 2.  It’s okay to leave the room to check your device. At any time. No judgment. Take a call, check an email, tweet a Tweet, whatever – just take it outside. (Location 540)

Tags: sprint

Jake likes to introduce the Time Timer with a bit of narrative, because timing people while they talk can be socially awkward. He says something like: “I’m going to use this timer to keep things moving. When it goes off, it’s a reminder to us to see if we can move on to the next topic. If you’re talking when the timer beeps, just keep talking, and I’ll add a little more time. It’s a guideline, not a fire alarm.” (Location 611)

Tags: timer

Note: .timer

Monday’s structured discussions create a path for the sprint week. In the morning, you’ll start at the end and agree to a long-term goal. Next, you’ll make a map of the challenge. In the afternoon, you’ll ask the experts at your company to share what they know. Finally, you’ll pick a target: an ambitious but manageable piece of the problem that you can solve in one week. (Location 618)

Set a long-term goal To start the conversation, ask your team this question: “Why are we doing this project? Where do we want to be six months, a year, or even five years from now?” (Location 646)

Tags: goal

Note: .goal why are we doing this. Where do we want to be in x months

Lurking beneath every goal are dangerous assumptions. The longer those assumptions remain unexamined, the greater the risk. In your sprint, you have a golden opportunity to ferret out assumptions, turn them into questions, and find some answers. (Location 662)

Tags: assumptions

Note: .assumptions work to validate assumptions early

List sprint questions You’ll list out your sprint questions on a second whiteboard (if you have one). We have a few prompts for getting teams to think about assumptions and questions: •  What questions do we want to answer in this sprint? •  To meet our long-term goal, what has to be true? •  Imagine we travel into the future and our project failed. What might have caused that? An important part of this exercise is rephrasing assumptions and obstacles into questions. (Location 669)

Tags: assumptions

Note: .assumptions rephrase assumptions as questions

Each map is customer-centric, with a list of key actors on the left. Each map is a story, with a beginning, a middle, and an end. And, no matter the business, each map is simple. (Location 757)

Previous Efforts Often, someone on the team has already thought about the problem in detail. That person might have an idea about the solution, a failed experiment, or maybe even some work in progress. You should examine those preexisting solutions. (Location 828)

The method is called How Might We. It was developed at Procter & Gamble in the 1970s, but we learned about it from the design agency IDEO. It works this way: Each person writes his or her own notes, one at a time, on sticky notes. At the end of the day, you’ll merge the whole group’s notes, organize them, and choose a handful of the most interesting ones.

These standout notes will help you make a decision about which part of the map to target, and on Tuesday, they’ll give you ideas for your sketches. With this technique, you take notes in the form of a question, beginning with the words “How might we . . .?” For example, with Blue Bottle, we could ask, “How might we re-create the café experience?” or “How might we ensure coffee arrives fresh?” (Location 858)

Tags: design thinking

phrase “Remind us . . .” is useful, because most interviews include content the team has heard before, at some point or another. (Location 902)