5. Can we deliver it

§The hypotheses: every part of the first version that touches an operation asks that operation for something it has already shown it can do, at a volume it has already shown it can absorb.

§The demo runs on a laptop in a quiet room. The product runs on a Saturday night with two hundred covers, a broken dishwasher and a server on her first week. Business design has to hold the second picture, and the sprint's own honesty about its weakest interviews is where it starts.

§ 5.1The operation as a constraint#

§Frei and Morriss's argument about service businesses is the right frame: excellent service is designed around what the operation can actually do, and a product that asks the operation to be excellent at everything will be mediocre at all of it. For a first version, this means writing down what each operational surface can absorb, in numbers.

§The floor: how many seconds a server has between tables, what they can look at, what they will never type. The kitchen: what it can read, when. The support inbox: how many questions per hundred users, answered by whom, in what time. The partner: what a development partner, a payments provider, a reservation platform will do, by when, with what failure modes. Each is a number or it is a hope.

§ 5.2What the first version must not depend on#

§The fourth whitepaper's rule for the first act, that it should depend on no one, is a feasibility rule as much as a strategy rule. Every dependency on an operation is a place the product can fail for reasons the team does not control and cannot see in a demo.

§The test for each element of the first version: has the operation already shown it can do this? Not said, shown. Servers said they would glance at a profile card; five of six named it as valuable. But two of six barely touched the screen and one refused the laptop, and nobody had watched a server glance at anything during a rush. The glance was plausible. It was not shown. So act one asked nothing of the operation, and act two, which asked for the glance, was scoped to one restaurant, read-only, with training, precisely so that the glance could be shown before anything depended on it.

§ 5.3Doing it by hand first#

§Paul Graham's essay and Eric Ries's concierge share a feasibility insight that is often read only as a desirability one: doing the operation by hand, for a few customers, is how you learn what the operation actually involves. The team that manually recognizes twenty regulars for a month, from a spreadsheet, at one restaurant, learns which seconds the server actually has, what the manager actually looks at, and what breaks on a Saturday. The concierge is operational research disguised as a product.

§ 5.4The support inbox#

§One operational surface every product has and almost no first version budgets: the questions. For every hundred users of act one, how many will write to ask what a tier is, why their visit was not counted, how to change their name? Who answers, how fast, and what does that cost per user? This is a feasibility number and a unit-economics number at once, and the team that estimates it before launch is rare enough that doing so is an advantage.

§ 5.5What has to be true#

§Added to the running list: for each operational surface the first version touches, what it is asked to do, the number it must absorb, and whether that has been shown or only said. For everything only said: the discovery-loop conversation or concierge test that will show it, with an owner and a date. The support load per hundred users, estimated, and who carries it.