There are two types of people who go and build new business. One type among them are people who have never built a business. Another type of people are those who have worked for bigger companies and have seen business at scale. This chapter is for the latter group.
When you work in a bigger company, while you have a lot of resources you also have a lot scope and processes already in place. You need to beware of lot of legal nuances because you are protecting the current revenues against lawsuits. You are a bigger target.
As a part of a bigger company you also work towards a lot of corner cases. This might involve handling corner cases in the product, tracking obscure metrics, or complying to a number of ISO standards. At scale, 1% of the underserved product use-case might mean millions of dollars. With you extra resources you can afford to go after those use-cases. So you start covering for these corner cases and the product keeps getting complicated to build and maintain because of this.
However, when you are starting to build your company, you wouldn’t care about use-cases that cause you to lose 1% of users, because you are focussing on 99% of the use-case. What you really want to prioritize is moving fast and figuring out our core use-case, which you would try to scale as soon as possible.
In most cases it takes x amount of effort to handle 90% of the use-cases and 5 times that amount of time to handle 95% of the use-cases. It might be better to get out soon and get 90% of a million users vs 95% of a thousand users.
A simple example that comes to my mind is when we were building Droptalk as a part of my startup Photo Lab, we were using email as an authentication channel. To keep things simple we would lowercase the email before storing and authenticating. This worked 99.99% of the the time. However someone in my team read somewhere that some email servers support case sensitive email addresses. So a John@bar.com might not get emails send to email@example.com. This particular team member was pretty insistent on supporting this use-case.
Thankfully, I was able to convince him by explaining that such users are a very small part of the overall user base and unlikely to be any part of our initial users. Eventually he relented and we were able to avoid the added complexity of handling email addresses which are case sensitive.
Another aspect I would like to touch upon is thinking simple. Almost everything you are building could be much simpler. Steve Jobs famously said: “It takes a lot of hard work to make something simple, to truly understand the underlying challenges and come up with elegant solutions”.
When you are working on building systems, take a hard look at what you are doing. If it looks too complicated, most likely you are not thinking about it right. The best products are very simple, and elegant and once you look at them they seem delightfully obvious. Spend time trying to make your product simpler to use and understand.
The best example I can think of on this front is the iPhone. Mobile phones have been around for decades before iPhone came out. Before that, Nokia, Motorola and Blackberry were trying to add more features to their phones to try to turn them into smartphones using various quirks like dedicated keys, joysticks, etc… They had multiple ways to control the interface. However, once the iPhone came out, they had a simple and consistent UI to use the product and as a result aforementioned companies didn’t survive.
That’s why it’s important to keep your product simple and elegant. When you find yourselves trying to cover multiple corner cases, you most likely you are not thinking about your product right.