Most products don’t die from missing features. They die from empty rooms.
A marketplace with no sellers. A community with no posts. A tool that only gets useful after months of your data. The product works fine. Nobody shows up. That’s the cold-start problem.
Founders know this. But they still spend their time building more features. Why? Because features are controllable. You write code, the feature ships, you feel progress. The cold start is different. It’s uncomfortable. It means talking to strangers, getting ignored, doing boring manual work. So we avoid it and build instead.
That’s backwards. Solve the cold-start problem first.
Before you write any code, answer one question: who shows up on day one, and why is it worth it for them alone? Not for them plus a thousand other users. For them alone, in an empty room. If you can’t answer that, more features won’t save you.
Here are four tactics that work.
Build single-player mode. Make the product useful for one user with zero network. Before Instagram was a social network, its filters made your photos look good. That was worth it alone. If your product only works when everyone’s friends are on it, you have a chicken-and-egg problem baked into the design. Redesign it.
Seed one side yourself. Marketplaces need supply before demand. So be the supply. Reddit’s founders posted under fake accounts for months. Airbnb’s founders photographed listings themselves. It feels like cheating. It isn’t. It’s how you fill the room so the first real users see something alive.
Narrow until you have density. A community of 100 people spread across the world is dead. The same 100 people in one city, or one profession, or one niche hobby, is alive. Facebook started at one university. Don’t launch for everyone. Pick one tiny group where every user can bump into another one. Win that room, then find the next room.
Do things that don’t scale. Onboard users by hand. Send personal messages. Deliver the service manually before the software exists. This feels wrong to engineers. We want systems, not chores. But at zero users, the manual work is the product. Automate it later, once there’s something worth automating.
Notice what all four tactics share. None of them are features. All of them are answers to the day-one question.
Here’s a test I use now. When I judge a product idea, I ignore the scale story. Every idea sounds great at scale. Millions of users, network effects, data moats. That story is easy to tell and worth nothing.
Instead I ask for the day-one story. Day one, zero users, empty database. One person arrives. Who is it? Why did they come? What do they get that made the trip worth it? If the answer is fuzzy, the idea isn’t ready. If the answer is clear, everything else is execution.
The scale story tells you what the product could become. The day-one story tells you whether it will exist at all.
So before you open your editor, sit with the uncomfortable question. Who shows up on day one, and why? Answer that first. Then build.