Thursday, December 29, 2016

Eric Ries "The Lean Startup"

For me, this book is really mind-changing. What I like in "The Lean Startup" is that every assumption is there with robust proof. You understand why author tells you this thing, he tells the stories and gives you examples of why that thing is bad and why the different thing is good. I learned really a lot from it, and not only about the approach to the business but also about the approach to the life. I am the big fan of the term "Leap of faith", because I found so many leaps of faith in my life, that now I really understand why the things are going in this way and not in other. A quick summarize of the book below.

The concept of this book is built around "Validated learning" term. The validated learning means, basically, failing. After each fail, you get some experience about what was the mistakes, that led you to the fail. The problem is that, probably, you spent a lot of time and money to learn this. The solution here is to fail as early as possible, so you can avoid spending your money and time to the lousy things. So the flow is: you make some product and try to recognize that it is failing as early as possible then you make some changes, based on your experience, and start the process again.

There are three basic things that you need to know, before implementing this approach. The first one is how to recognize that your project is failing? You can see that it doesn't achieve its goals. E.g. the feature you decided the most important doesn't earn money, or nobody use it. Your customers are the only people who unintentionally show you the value of your product. Why unintentionally? Because when they use (or not use) your product they do it only because they need it and they use it only the way they can. You cannot understand if your product will be successful or not only by yourself or with your partners. The only way to understand it - release the product. And that means that you need to release your product as fast as possible.

How to release the product fast? Build less. You need to release only the most important things and they can work poorly, but anyway, you will see how your customers interact with that. How to choose which feature is the most important? Here is the term "Leap of faith". When you start your project you usually assume something. If you design a photo sharing app, you assume that people will be ready to switch to new photo sharing app. Usually, you accept these assumptions without any proof, and it becomes the main reason of your fail. What you need to do is find which assumption you accepted as the axiom and check it first. Just build the most simple implementation (in some cases you don't even need it, try to make the service by your own - contact customers, make the work with your own hands, without your application or web service).

That means, that you need to work in small batches. You need to release fast and with really small changes. You need to thoroughly check how the change affected your project. For this, you need to use cohort analysis instead of vanity metrics. Vanity metrics are simple, e.g. the number of users or the number of something else. Why is vanity metrics bad? Because they don't really show are you growing or not? Cohort analysis allows you to segment your customers and check the percentage of the segments. If the percentage of users in your target segment is growing it means that you are growing too, otherwise, you do something wrong.

To wrap it up:
 - Your goal is to fail earlier to avoid unnecessary expenses
 - You need to release often and in small batches
 - The first thing to test are your leaps of faith
 - Use cohort analysis instead of vanity metrics

Of course, there are much more useful things with different interesting stories about fails and successes of the different startups, about mistakes, problems, and solutions. I highlighted ones, that I think are the most important. I definitely advise to read this book to everyone, who involved in IT industry or want to build his own business.