Airbnb, Dropbox, Slack: each of them found the answer before building the product.

The problem Drew Houston wanted to solve was real, but building the product would take a long time and file synchronisation is hard to explain. Instead of writing code, he recorded a demo showing HOW the product would work and shared it with technical communities.

By Houston's own account the waiting list jumped overnight from roughly 5,000 to 75,000 — with no usable product in existence yet. That is getting the answer to “would anyone want this?” before months of engineering, not after.

Early on, Airbnb's New York listings were few and badly photographed. Rather than write an algorithm, the founders got on a plane, visited hosts one by one, photographed the listings themselves and talked to hosts face to face.

The method did not scale at all, and that was precisely its value: the founders learned why listings were failing from the hosts themselves rather than from a dashboard. Paul Graham uses Airbnb as the central example in his essay on doing things that don't scale.

Stewart Butterfield's company, Tiny Speck, was building an online game called Glitch. The game did not take off and was shut down. But the team kept using the internal communication tool it had built for itself while working remotely.

Instead of trying to rescue the game, the team looked at what was actually working and turned that internal tool into the product. Slack did not emerge from the wreckage of a failed product — it emerged from the one piece inside that wreckage that had already proven it worked.

Kevin Systrom's first product, Burbn, did many things at once: location check-ins, planning, photos. When the team looked at usage data, they saw that people were using almost exactly one feature: sharing photos.

They deleted everything else and shipped Instagram, focused only on photos. That decision was not intuition; it was reading usage data — answering “what are people already doing?” instead of “what could we build?”