14. Adapting to your situation

§The question this chapter answers: how much of this applies to you, and what do you cut?

§The preceding thirteen chapters describe the sprint in full. Almost nobody runs it in full, and nobody should feel they have to. What follows is how it bends to three common situations, and how to answer the three objections every team raises at some point in the second week.

§ 14.1Pre-funding#

§You have an idea, a co-founder or none, and a day job or a shrinking runway. The order of the first half matters more than ever, because the expensive sources are the ones you cannot afford to waste.

§Problem first, always. Do not build. Do not prototype. Chapters 1 through 7, compressed: an afternoon of desk research, three expert conversations, a week listening in communities, eight customer conversations, one matrix, one statement. All of it costs nothing but time and nerve.

§Free methods only. Every tool in this whitepaper has a free version. The communities are free. The experts, asked well, are free. The customers, recruited through the experts and the communities, are free.

§Leverage the network you have. Your first experts are people you know or are one introduction from. Your first customers are the people the experts point you to. The cold outreach comes later, when you can say what you have learned.

§Manual before automated. If the problem statement holds, the concierge rung is your prototype. Do the job by hand for three customers. It is the cheapest test on the ladder and the one that teaches you the most, and Paul Graham's essay remains the best argument for why it is not a detour but the road.

§ 14.2Funded#

§You have a small team and a year or two. The risk inverts: you can afford to run the full sprint, and the danger is running it as a phase rather than a habit.

§Parallel tracks. Two segments can be researched at once. Two canvases can be prototyped at once. Two people in the field on the same afternoon double the interviews and halve the elapsed time.

§Invest in the tools. A research repository so that quotes are searchable. A shared wall that survives the sprint. Recording and transcription so the note-taker can watch faces. None of this changes the method. It removes the friction that makes teams skip it.

§Build the habit, not the project. Teresa Torres's argument for a weekly customer touchpoint is the right frame for a funded team: discovery does not end when the sprint does, and the team that keeps talking to customers every week after launch is the team that notices when the market moves.

§ 14.3Solo#

§A third of new startups now begin this way, and the sprint was written with you in mind. Everything in it can be done by one person, and some of it is easier.

§Protect the time. A solo founder's calendar is the company's only resource. Decide how much of a week the sprint gets, and hold it against the pull of building, which will be strong because building is the part you can do alone and the field is the part that needs other people.

§Go for the highest-yield sources. Three former operators beat ten current ones. Six customers who have the problem worst beat twenty who have it mildly. You cannot afford breadth, so buy depth.

§Automate the mechanical. Transcription, first-pass clustering, desk research, the drafting of a brief from your notes. The next chapter but one is about exactly this. What you must not automate is the conversation itself, the silence in the room, and the decision about what you saw.

§Learn in public. Write down what you are finding and put it where the community you listened to can see it. It recruits interviewees, it attracts the expert who disagrees, and it creates the accountability that a co-founder would have provided. Julian Weisser's work with solo founders comes back to the same point: the absence of a partner is survivable; the absence of anyone to argue with is not.

§ 14.4Three objections#

§"We don't have time for discovery." You do not have time not to. Two weeks of the first half saves months of building the wrong thing, and the arithmetic is not close. The version of this objection that is legitimate is "we don't have time for all of it," and the answer is the introduction's rule: do the condensed version well.

§"Users don't know what they want." Correct, and irrelevant. Nothing in this whitepaper asks them what they want. It asks what happened last time, what they did about it, what it cost, and then it watches them use something. People are poor at predicting themselves and superb at remembering and at reacting. The whole method is built on the second pair of skills.

§"We're getting conflicting feedback." Good. Conflicting feedback from a tightly described segment almost always means the segment is two segments, and you have just found the boundary. Map the conflict: who said what, and what else distinguishes them. The conflict is not noise to be averaged. It is usually the most valuable finding in the set.

§ 14.5What you leave with#

§A one-paragraph statement of which version of the sprint you are running and why. The steps you shortened and the steps you cut. And, for each step you cut, the question you have chosen not to ask, written down, so that when it comes back, and it will, you recognize it.