When you are building your product, there should be a big focus on removing frictions on every aspect of your product building and operations.

These friction points could be related to how your team is building their product, or it could be how you are operationally running your company. Some examples could be related to the steps needed to build and push the code for your apps. Or it would be related to the steps needed to deploy your code. Or this could be related to the steps needed by a salesperson to generate a new lead.

Each friction point kills the momentum of your team. This is especially impactful in a negative sense when your team is in highly productive zone. This is equivalent to a situation where while you are running a marathon, your shoe laces open up every 10 minutes. And you need to fill up a form and get an approval to run at every mile. This would kill the momentum of the runner and make them less likely to finish the race.

One another angle that is a huge problem for companies are when your team starts being so afraid of their own product code and processes, that they do not want to make changes. Once this happens, they are unable to make the right choices. They cannot develop the features which are needed because it would break too many things. Even if they end up trying to develop, they are not able to do justice to the feature because they are scared to touch parts of code and try to work around it.

As this goes on and on, this leads to complex bugs, which can only be fixed by changes in the scary parts of the code. However, because people do not want to touch that part of the code, they try to patch around that, which leads to even more bugs. This can bring down the morale of the team and your best people might start leaving. You could end up losing the very people who had the best chance of fixing this issue.

At the end of it all you are stuck with an unmaintainable code and unable to respond to the market need and the competitors. Companies must never be scared of their own code and whenever they find this happening, they should take the problem head on and delve into the code and do the right thing. This helps them maintain momentum and build the best product.

It’s understandable that the above steps can be difficult to do that especially when your are understaffed and barely able to meet your deadlines. For that very reason, it’s important to create a fine balance and find the right fit for yourselves. What matters in the end is whatever gets you faster to your goal. The choices people end up making largely depends on their individual situation.

One thing that has seen to be helpful to people is if they have “great taste.” If they accept a subpar situation and are fine with dealing with friction, fear and frustration on daily basis, they might end up in a tight spot. However, if they have great taste, they find constantly strive for a better operating situation, which helps them find time and energy to fix the above issues.

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 john@bar.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.

Once people have launched the product, many of them avoid getting their hands dirty. They launch the product, do a little bit of first day launch press and expect that the users will automatically find out about the product, that there would be a good product market fit and soon everyone will start using their product.

The truth is, this almost never happens. You launch your product and then you wait for users. You get a bit of uptick after the initial publicity but the growth tapers off soon afterwards. Then, you feel that you product is broken and either start working on pivoting it or adding a lot more features.

However in many cases, it’s possible that the core foundation of your product is right, but it wasn’t presented in a good manner. Or it is also possible that they core foundation is wrong, but you kept on adding features without realizing this shortcoming because you aren’t talking to your users.

It is important to go out and talk to your users. You will learn quite a bit about their needs, how they are using the product, what is working for you and what is not. No one expects you to get millions of users manually. Unfortunately, most products are stuck at a point where they do not have even hundred users. So go out and learn from your users.

Airbnb is an example of one of the recent and biggest success which started by doing things that didn’t scale. They started with building a shared Bed and Breakfast. When they launched initially they didn’t get any users. After some time they went door-to-door in New York trying to sign up people to host their homes on their service. During this phase they learned a lot of about their product.

When you create products that don’t scale, benefits are not limited to learnings about your product. You can benefit from quite a few more dimensions.

This can help bootstrap your product. When you start your company you have zero users. Bootstrapping a few initial users can really accelerate your growth. Now when you are launching things, you can get quicker feedback. This helps you know what works and what doesn’t. When other people join your product, it gives them confidence that other users are also using their product.

One other issue is that usually people are used to very shitty customer service. Most of the companies they are used to dealing with do not have personalized service and aren’t customer-centric.

When you are interacting with your customers directly, you are offering a direct connection with them. They are also getting an experience that they haven’t gotten before. This will make it easier for you to acquire more customers. You could also use this process to identify and groom champions for your product, who would then go ahead and help get more people signed up on the platform.

Airbnb was able to execute this really well, where they signed up some of their earliest users to start running meetups for them, which would answer questions from potential users and help set them up.

One of the best articles about this is written by Paul Graham, hosted at http://paulgraham.com/ds.html. Paul’s article talks about some of these factors in further detail.