15. Failure modes of the sprint

§The question this chapter answers: where will this go wrong, and how will you know?

§The failures below were each observed enough times to earn a name. They are listed in the order they tend to appear in a sprint, and they share one root, which the last section names.

§ 15.1The pitch trap#

§What it looks like. Somewhere in the first ten minutes of a customer conversation the founder explains the idea. Everything afterwards is a reaction to the idea rather than an account of the customer's life. Why it happens. Enthusiasm, and the founder's belief that the customer needs context to be useful. They do not. They need to be asked about Tuesday. The tell. The founder's speaking share is over a third. The notes contain the word "liked." The defense. The one-sentence description written on the notes page and not spoken unless asked. A note-taker who counts.

§ 15.2The leading question#

§What it looks like. "Wouldn't it be great if..." "Don't you find that..." "How much would you love a tool that..." Why it happens. The founder knows the answer they want, and the question is shaped to produce it. Daniel Kahneman's account of confirmation bias is the whole explanation: we ask the questions whose answers we are prepared to hear. The tell. Every answer is yes. Every yes is polite. The defense. Every question begins with "when," "what," "how" or "tell me about," and points at the past. The follow-ups from chapter 5. A rule that no question may contain the product.

§ 15.3The feature shopping list#

§What it looks like. The conversation drifts into features and the customer, helpfully, lists what the product should have. The list is long, the founder is delighted, and none of it is evidence. Why it happens. Features are easy to talk about and easy to write down. Problems are neither. The tell. The synthesis contains a list of features and no stories. The defense. When a feature is mentioned, ask what happened the last time its absence cost them something. If nothing did, it goes on the wall as a compliment, not a finding.

§ 15.4"Everyone has this problem"#

§What it looks like. The problem statement's first line names a population rather than a person. The team believes the market is enormous and cannot say who is out. Why it happens. A large market feels like safety. It is actually the absence of a segment, and a product built for everyone reaches no one. The tell. The team cannot describe a person who does not have the problem. The defense. The statement in chapter 7, whose first two lines require a type of person in a situation. The question "who has this worst?" from chapter 3.

§ 15.5Features from nowhere#

§What it looks like. The prototype contains a screen, a unit, a gesture that no question on the board produced. It looked good. Someone had seen it elsewhere. Why it happens. Divergence produced ideas; the freeze did not filter them by origin. The tell. A screen with no question number. The defense. The rule from chapter 11. Every screen carries the number of the question it answers, or it does not go to the field.

§ 15.6Adding because it costs one prompt#

§What it looks like. During the build, a feature is added because adding it took thirty seconds and it seemed harmless. Why it happens. This is the failure the AI era created. When a feature cost a week, the cost filtered the ideas. Now nothing does, except discipline. The tell. The prototype has more screens at the freeze than the brief allowed. The defense. The brief's "what is out" section, read aloud at the freeze. A count of screens against the count in the brief. Marty Cagan's warning about feature teams applies to a two-person team with a prototyping tool: outputs are not outcomes, and a screen that ships is not a question that got answered.

§ 15.7Testing operations in a conference room#

§What it looks like. The operational side of the product is tested with staff in a quiet room, seated, with two interviewers, imagining a shift. Why it happens. It is where the interviews were happening anyway, and the operation is hard to reach. The tell. Polite nods. Interviewees who do not touch the screen. A finding that says "staff found it valuable" and no observed behavior. The defense. Honesty in the synthesis about what the setting could not test, and a plan to test it where it lives. The customer side can often be tested at a table. The operational side lives in noise and time pressure, and the sprint should say so rather than pretend.

§ 15.8The root#

§Every failure above is a case of one thing: something entered the sprint without a question behind it. A pitch enters the interview without a question. A leading question carries its answer in. A feature list enters synthesis without a story. A population enters the statement without a person. A screen enters the prototype without a number. An operational finding enters the position without an observed behavior.

§ 15.9What you leave with#

§The list above, pinned next to the research plan. Before each phase, read the two or three that apply. After each phase, mark which ones you caught yourself in. Every team catches itself in at least one, and the sprint is designed so that catching it costs an afternoon rather than a quarter.