With all the startups I have worked with, I have noticed one mistake that every founder keeps making when they are starting off with the product. Planning for millions of users from day 0.
Founders are too blinded by their ideas, that they believe “if you build this awesome product, they will come.” Even worse, there are founders who think, on the day of launch, users will come out in hordes, signing up and using their product exactly the way they envisioned.
The product manager or the CPO would have outlandish claims of their potential user base and how the product needs to scale from the time they press the launch button. Raise your hands if you have heard someone say something similar to this “There are 2.2 Billion Facebook users and even if we get 1% of that crowd, it is 22 million. We need to handle all those users.”
Developers Love Working on Scaling Problems
We developers love a good challenge and think of all the different possible ways the system can break down – How many concurrent users will sign up, what if the confirmation email blocks the request for another user, what if the users upload GBs of videos, what if they have a unique hierarchical data model, and so on.
When there are numerous possible problems, we do premature optimizations — like spawning off multiple unnecessary microservices, developing a custom framework which is needed just for this project, using a data store which requires atomic clocks to synchronize data, etc.
For a developer, all this is fun and we
Launch Day
You are not going to get million users on Day 1. Not on Day 100. Maybe even after a year. There is perhaps a 1 in 100000 chance that your product gets viral and you get thousands of users every hour from day 1.
With such low chances, why do you want to waste precious time and resources, building things which are not needed? If you had set realistic estimates of the number of users, your tech team could have built the product maybe in a month. And if you launch early, it allows you to test your hypotheses and iterate much faster.
Your development team would have chosen Rails and MySQL for the product and would have hashed out a basic CRUD app in less than a week. Would it scale to millions of users? Maybe not. But it would get users into your system.
ChangeLog.host isn’t scalable, but works
Let me show an example from my own life. When I built ChangeLog.host, I didn’t worry about scale. I built it using Flask a simple Python web framework, used Postgresql for my DB and hosted it on a free Heroku instance.
I built it because I wanted to use it. It was designed for a single user in mind. It might work for a few thousand users, but I didn’t build it like that.
I built it in 24 hours, did a soft launch to a limited group. How many users did I get? A grand total of 10 users. Will it scale to thousands of users efficiently? No way, but this is a decent enough product that does it’s job.
I deliberately didn’t market it to more than 10 people, as I wanted to see how they use it first. Instead I went out and talked to them, did a bit of cold calling and messaging. I found out what my potential customers wanted and didn’t want. The results and insights I got out of it are worth it.
I would have spent maybe about 40 hours in total on this product, but I learnt quite a lot from that time. I am happy that the product isn’t viable for the market I was looking for and that I learnt it much sooner than later.
Imagine if I had hired a team of UI designer, front-end developer, mobile app developers and spent 3 months building everything and then launched. Even with a conservative estimate, I would have wasted 1440 hours in total. It doesn’t require a PhD to realize it would have been a mega-failure.
TL;DR
Stop building products for millions of users. I understand that not every product can be built for a single user and scaled up. But at least don’t expect millions of users to come knocking on your door when you launch. Build small, iterate fast.
PS: In the future posts, I would be writing how to identify your idea by doing the right customer development, building a MVP, and other such product related posts. Subscribe below to receive them.
