Build for the Few, Not the Many

Definition

Rather than compiling a Marketing Requirements Document — the sum of every prospective customer's feature requests, prioritized across Marketing, Sales, and Engineering — a startup should build the product exactly as its founders envisioned it and then search for the small group of customers who will buy that specific version. Feature requests only get added "by exception rather than rule": only after no one will buy the product as spec'd.

In the Book

Chapter 3 argues the standard MRD process is "rational for an established company" with known customers and known needs, but "folly for startups," who cannot afford to build every feature a mainstream customer will eventually want and would be obsolete by the time such a product shipped. Instead the founding team's job is "to find customers for the product you are already building," tailoring only the first release to the needs of the visionary customers (earlyvangelists) who actually show up. The FastOffice case (revisited across Chapters 1 and 3) illustrates the failure mode directly: without this philosophy the company churned through executives chasing a moving mainstream spec before finally discovering its true core asset was a narrower data-communications capability that a focused early group actually wanted.

Why It Matters

It resolves the false choice between "build what customers want" and "build what you believe in" by narrowing "customers" to the specific handful who have already proven they'll act, not the aggregate of everyone who might someday have an opinion. Any team facing infinite plausible requirements before it has a single committed adopter can use this move: build the founders' best-specified version, then search for the who, instead of trying to survey the what across an audience that doesn't exist yet.