Drew Houston had no product. He had a three-minute video.
The video showed how Dropbox would work, if it existed. Files syncing between a laptop and a desktop. Photos appearing on a phone. A folder that just worked.
Overnight, 75,000 people signed up for the beta.
None of them had used Dropbox. There was no Dropbox to use.
They were responding to the brochure.
The trap that kills six months
Most founders skip this step. They go from "we understand the customer" straight to "let's build". Six months later they emerge with a product nobody reacts to.
Or worse, they write the spec. Forty pages. Edge cases documented. Database schemas planned. Engineering nods. Sales nods. Marketing nods. Everyone agrees on a thing none of them actually visualised the same way.
The product ships. The brochure gets written after. The brochure describes what got built. Customers don't buy.
You've now done it backwards.
The brochure comes first
The brochure is not the marketing asset you produce at launch. It's the artefact you produce before you write any code to find out whether anyone wants the thing you're about to build.
It's two pieces stapled together.
A drawing of the product. Not a wireframe in Figma with perfect kerning. A drawing. Five rectangles on a screen. Boxes and arrows. Storyboard the user's flow. Use Balsamiq if you want it slightly less crude. The crudeness is the point: a polished mockup invites debate about colours. A sketch invites debate about value.
And a description of what it does for the customer. Features. Functions. Benefits. Targeted at the persona you already built in step 5, walking through the use case you already mapped in step 6.
That's the brochure. Two pages. Ten minutes to read.
Why Drew Houston didn't write a PRD
Houston could have written a forty-page Dropbox spec. Database design. Sync protocol. Conflict resolution. He didn't.
He made a three-minute video showing a man with two computers and a phone. The video didn't work. It was a screen recording stitched together to look like it worked.
Y Combinator wrote a cheque. 75,000 users signed up. Engineers later built the thing.
The brochure validated the demand. The product followed.
Same playbook, different founder: Joel Gascoigne at Buffer. Two pages. The first described what Buffer would do. The second was a pricing page. Visitors who clicked "buy" got a screen saying "we're not ready yet, leave your email." Buffer had paying customers before it had a single line of code.
The brochure was the product, until the product was the product.
What goes on the brochure
Start with the customer's needs. Always. You did this work in steps 1 through 6. Use it.
For each major thing your product does, write three lines:
- Feature: what the product is or has. "Two-tap photo editing."
- Function: what the user does with it. "Tap once to brighten, twice to publish."
- Benefit: what changes in their life. "Your photos look better than your friends' on Instagram, without lifting a finger."
Founders skip the third line. They put features on the brochure and call it done. Features sell to engineers. Benefits sell to humans.
Re-read the brochure as Melissa. If she can't tell in ten seconds why her Tuesday is better with this thing, the brochure isn't done.
Show, don't sell
Take the brochure to customers. Not to sell. To iterate.
You're testing the gap between what you think the product does and what they think it does. The conversation that goes "oh, it does X too?" is useful. The conversation that goes "wait, what does it do?" is gold. The conversation that goes "yes, I'd pay for that" is the one you stop and write down word for word.
Don't argue. Don't explain. Don't defend the drawing. Take notes. Update the brochure. Take it to the next person.
If you defend the brochure, you'll defend the product, and you'll spend six months building something nobody wanted. The brochure is supposed to break. That's the whole point of drawing it before you build it.
The team alignment bonus
There's a quieter benefit nobody talks about.
The brochure is the single document that gets your engineering, sales, marketing and product people thinking about the same product. Without it, every function describes the product differently and you find out in week thirty when sales is pitching one thing and engineering built another.
One drawing. One page of features and benefits. Everyone on the team can quote it. That's worth the afternoon it takes to make.
What the brochure is not
It is not a launch asset. It will get thrown away. You'll redraw it ten times before you write any code, and another fifty times after.
It is not the product spec. The spec is detailed, the brochure is high-level. The spec is for engineers, the brochure is for customers. Confuse them and you'll build the wrong thing for the wrong reason.
It is not the MVP. The MVP is what you eventually ship to acquire your first paying customers. The brochure is what you show before any of that happens, so you don't build the wrong MVP.
And it is not optional. The founders who skip it write off the first six months as "learning" and then quietly do the same thing again.
The brochure that beats the demo
A demo is a feature show-and-tell. A brochure is a benefit promise.
Customers buy the promise. They tolerate the feature.
Draw the promise first. Build the features later. In that order. Always in that order.