16. Cases

§Four cases. Each is here because it produced one rule in this whitepaper, and each is told only as far as that rule.

§ 16.1The desk-research founder#

§A founder had an idea in a category with three failed predecessors in six years, all of which had written post-mortems. She read them before talking to anyone. Two had failed on distribution: the product worked and nobody could be reached cheaply enough. One had failed on the problem: the customers it targeted did not, in the end, care.

§She spent her first expert conversations on the distribution question, because the graveyard had already answered the problem question for two of the three, and she needed to know which of the three her segment resembled. Her first customer conversations confirmed that her segment was the one that cared, and turned up a distribution channel none of the three had used.

§The lesson is chapter 2's: someone has tried this before, and the cheapest research you will ever do is reading what they wrote about it. She entered her interviews with two questions instead of ten, and got answers to both.

§ 16.2The banks and the wrong words#

§A team in an accelerator was building an AI platform to help banks analyze customer transaction data. The one-sentence description was clean, the technology was real, and the first version was underway when the customer conversations began.

§The banks did not describe a data problem. They had analysts, and the analysts were good. They described an execution problem: they knew what the data said and could not turn it into changes in their digital products fast enough. Same technology, different sentence. The team pivoted to helping banks apply what they already knew to their apps automatically, and the market that had been polite about the first product was impatient for the second.

§The lesson is chapter 7's: the statement is written in the customer's words, and the gap between "banks cannot analyze their data" and "banks cannot act on their analysis" was invisible until someone tried to say the first sentence to a banker. Perplexity's founders describe an early version of the same turn: the natural-language database tools they started with were the technology, and the answer engine was the sentence the market actually said.

§ 16.3The two-MVP team#

§A team in an accelerator built two complete first versions for the same problem before doing any solution exploration. Both were technically sound. Both were wrong, in different ways. "We thought we knew what to build," they said, and they had: they knew the first solution they had thought of, and then the second.

§When they finally generated options, the one that worked was on neither list, and it took an afternoon to find. The lesson is chapter 8's, and it is the most expensive lesson in this whitepaper because it is the most common: the first solution is the one everyone thought of, and building it is not exploration. Cursor's founders describe a version from the other direction: months on a product for mechanical engineering before they explored where the technology was actually working, and the exploration, not the building, is what produced the company.

§ 16.4The 2026 field sprint#

§A multi-brand hospitality group with more than twenty restaurant brands, a product lead, a group of ten in the room and four of them building. The problem was loyalty and recognition across brands. The team had never prototyped anything.

§Insight. Ninety-five pains written in silence, from the customer side and the operations side. Five themes. Ten questions in five pairs, one per side per theme. The most talked-about theme was paying and splitting the bill. The most written-about theme was recognition, twenty-six notes against thirteen. Talking and writing produced different rankings, and only writing was counted.

§Options. Twenty-six references from real products, each with a note on exactly what to steal. Six patterns. Two build teams of two, split by side, nobody from design or engineering.

§The brief and the build. One requirements document written to be uploaded: two named personas, the business rules already decided as numbered statements, a paste-ready dataset of real dish names and local prices, five screens allowed, what was out. Eleven prompts, one screen or flow each, the last one asking the design tool to write the instructions for the no-code builder. Two working days, a freeze at the end of the second. Two navigable prototypes on phones, from four people who had never made one.

§Demo. About a hundred written comments from the room. The design pile said clean, simple, premium, and nothing else. Every substantive comment was about scope: whether the loyalty unit was money or something else, whether check-in was a QR code or something else, whether one program could serve more than twenty brands. Six decisions were left open and written down with owners.

§The field. Twelve interviews against a target of five, six customers and six operations staff, because recruiting began on day one. Two people per session. Life before the prototype. Situations, never instructions. Think-aloud, silence through the hard parts, a commitment at the end, one synthesis page per person before leaving.

§Six of six customers did not understand the loyalty unit. "I don't get how much they're worth, what they're for, how they add up." Six of six failed the check-in; one said she would rather close the app. Four of six thought the section labeled My card stored credit cards. Five of six loved reservations, especially seeing the group's other restaurants when there was no table. Five of six operations staff named the customer profile card as the most valuable thing they saw: "it lets us anticipate before they sit down." Nobody needed to be paid for their information; they filled it in gladly, because they understood it would get them served better, and the point economy the team had designed sat on that false assumption. Two operations interviewees barely touched the screen. One refused the laptop.

§The position. A tension map: validated, open, discarded, with the quote and the code for each row. A memo in two acts. Act one, the customer builds a profile and sees a tier, nothing else, because it depends on no one and ships in a month. Act two, the operation reads that profile before serving, in one restaurant, read-only, because five of six asked for exactly that. Payments deferred, not discarded, because they need a check-in that failed six of six.

§The team entered with payments as pain number one. It left proposing to leave payments out of version one.

§ 16.5What the four cases share#

§The founder let the dead do her desk research. The bank team let a banker write their sentence. The two-MVP team let an afternoon of options replace three months of building. The hospitality team let twelve strangers outvote a room of ten. In each case the team's own judgment was overruled by evidence it had gone and got, and in each case that was the point.

§ 16.6What you leave with#

§Your own case. Written the same way: what you assumed, what you did, what the strangers said with the numbers, what you proposed. One page, dated, filed next to the research plan. The next sprint reads it first.