Dispense a twenty-dollar bill.

Before Apple, Jay Elliot worked at IBM on the ticket machines for BART, the Bay Area's rail system. You put money in and got a ticket out.

At an IBM demonstration, a salesperson who worked with Bank of America asked Jay a question that turned the machine around. In It's the Product, Stupid, Jay puts it this way: "Instead of putting in money for a ticket, could a person put in a card and receive money?"

Jay's answer is the whole lesson: "My answer was that it should be possible, but I wanted the first version narrow. One denomination. Dispense a twenty-dollar bill."

One denomination

It wasn't a bank in a box. "We were not reproducing a complete bank in the first demonstration," Jay writes. It was one card, one request, and one twenty-dollar bill.

That was deliberate. "I did not need a complete bank to learn whether the central transaction worked."

The narrow version paid off quickly. "That restriction made the product small enough to build and show," he writes, and his group built the cash-dispensing prototype "in about two months at the most."

Then Jay did something I love. He told the bank he would bring two demos "so they could see that two of them worked." He did, in San Francisco. His reasoning: "Two working units were better proof than a drawing of everything the system might do later."

What the person actually wanted

The first version was narrow because the need was narrow. "The user did not care what category IBM put around the machine," Jay writes. "I could call it banking technology or a consumer system, but the person wanted twenty dollars."

That's the test the first version had to pass, and nothing else: "If the machine recognized you and delivered the cash safely, it had done its job."

Jay's sentence on why this works is the one I'd put above every product roadmap: "You can expand after the promise works; before it works, a larger feature list gives you places to hide."

Places to hide. When a first version tries to do thirty things and it doesn't sell, you can't tell which part failed. Was it the pricing, the dashboard, the integrations, the onboarding? Everyone on the team gets to keep their favorite theory. When the first version does one thing, the answer is plain. The twenty dollars came out, or it didn't.

The supertanker

The prototype worked. Jay didn't only want to sell machines. He wanted IBM to place them with banks and earn ongoing revenue from leasing and maintenance, a business built around ordinary people using the machine directly.

The proposal went to IBM headquarters in Armonk, New York, where Frank Cary, who ran IBM, turned it down. Computer rooms were IBM's focus, and the company didn't want to deal directly with consumers. Then he gave Jay an image Jay says has stuck with him ever since.

"IBM is like a supertanker," Cary said. "It takes ten miles to turn and fifteen miles to stop. So don't be disappointed, things will change eventually and Jay, you are a very good IBMer. You need to be patient."

Jay doesn't paint IBM as foolish. "Intelligent people can make a decision that is reasonable for the company and wrong for you outside it." From headquarters, a consumer cash machine looked small next to the computer-room business. From the sidewalk, it didn't. "If you needed cash after the bank closed, it did not look small."

On the flight home, Jay knew which boat he wanted. "I did not want to wait for a supertanker to turn. I wanted a sloop, or even the little pram I had learned to sail as a boy—something close enough to the water that I could feel the change and move."

A few years later, he was sitting in a restaurant listening to a young man talk about putting a computer in everybody's hand.

What Jay doesn't claim

Jay is careful not to make this story bigger than it was. "Cash-dispensing machines existed before this work, and IBM had other banking technology. I am not saying my group invented everything that became the ATM." What he does say is that his group built a cash-dispensing prototype out of the BART work, and "those machines became the prototype for the ATMs you find everywhere now."

I appreciate that. A narrow claim you can defend beats a big one you can't, which is the same lesson as the twenty-dollar bill.

Find your twenty-dollar bill

Here's how I'd apply this to whatever you're building:

1. Name the one transaction. Forget the category. What does the person walk away with? That's your twenty-dollar bill.
2. Cut the first version down to that. Everything else waits until the transaction works reliably for someone who didn't build it.
3. Prove it twice. One working demo can be luck. Two is evidence.
4. Then expand. Once the promise works, adding to it is building. Before that, it's hiding.