Validated Learning Through Discovery

Definition

Patton names the failure pattern "the bad old days": build the full solution first, ship it, and only then discover — through complaints, silence, or apathy — whether it actually worked. His alternative borrows two lineages. From design thinking (IDEO, Stanford's d.school): empathize with real users firsthand, define a specific focused problem, ideate multiple solutions rather than committing to the first obvious one, prototype cheaply, and test with real users doing a real task. From Eric Ries's Lean Startup and Steve Blank's customer development: run short validated-learning loops that treat a solution as a hypothesis to be tested with the smallest possible experiment, not a plan to be executed.

In the Book

Chapter 15 opens with Patton's own admission that he still slides back into "the bad old days" — build first, hope it works, spend energy "pretending we were successful" when it doesn't — to make the point that this isn't a hypothetical failure mode but a default one, even for an expert. He walks through the five design-thinking steps and pairs each with a story-mapping practice: use the map to record what you observed while empathizing with real users; use it as ideation backdrop, writing multiple candidate solutions directly onto the cards where they're relevant, rather than converging on the first idea a "design studio" produces. He then lists concrete ways teams sabotage a good discovery process even while following it correctly on paper — skipping direct user contact because "our solution ideas are great," polishing a prototype until it "looks really lovely" but doesn't work well enough to actually use for the real task, or blaming a person once the shipped outcome disappoints instead of the untested assumption that caused it. Chapter 14 grounds the earlier, cheaper end of this same discipline: mapping how people work today, before any solution exists, to find where the real pain and opportunity sit rather than guessing.

Why It Matters

Every solution encodes bets about what users need and whether the proposed fix actually meets that need — bets that are cheap to test before you build and expensive to discover you got wrong after you ship. Building the smallest artifact that can expose whether a specific bet is true, and treating a user's reaction to it as data rather than validation-seeking, converts "we think this will work" into "we know this works" before the expensive commitment is made. The same discipline underlies any field where building the real thing is costly relative to testing a rough approximation of it first — policy pilots, scientific experiments, architectural mockups.