what to build first

The mistake is building a little of everything. The first version should do one thing so well that a small group can’t live without it — and consciously leave out everything else, even the parts you’re sure you’ll need.

Start from the smallest paid version of the problem, not the vision. A founder wanted to fix fragmentation in Indian manufacturing — huge, real, and unbuildable as a v1. The thing to build first was one screen: the e-way bill the factory owner fills by hand on a Friday night because it doesn’t work on mobile. Automate that and he pays five to ten thousand a year, happily. The platform that ties twenty of these together is two years out, minimum. Build the one job someone pays for this week.

Make the first version single-player. The most common way founders kill their own v1 is a benefit that only appears once enough other people show up — “someday when enough apps integrate this, your users get a unified account.” Nobody turns up for the multiplayer. What does one user get on day one, alone, with nobody else on the platform? If you can’t answer that, you don’t have a first product yet, you have a network you’re hoping to summon.

Depth over breadth. Facebook’s first version had one feature — you could see who at Harvard was single. No photos, no wall, no comments. One campus, until people kept coming back, then the next. In a thin enough slice, being number one or two makes you impossible to displace; spread across four things, being number five in each means nothing.

So when you show someone the product and they ask about the other five things on the roadmap, hide them. When they hear your company’s name, they should think of one thing. Build that one thing until a small group needs it, then — and only then — add the second.