Why startups die and other answers

I really liked the book The Lean Startup, written by Eric Ries. I advised her to read all the startup authors. True, it turned out that not everyone is strong enough to read 300 pages of a fairly dense English text. Therefore, I decided to retell in Russian the most important parts of this book.

The book begins with a simple question: “Why do startups die?”

The startup team creates a new product in an environment of complete uncertainty. No one else knows exactly who their real users are and what the product really should be. Like any business, a web project needs to be managed. Someone somehow controls each startup, but most projects die. Why?
')
The first problem is an unconditional trust in a good business plan, a clear strategy and extensive marketing research. In not too old times, business plans, strategies and research were a good claim to the success of most business ventures. The temptation to introduce a similar approach to work planning and in startups is huge, but in startups this approach, alas, does not work, since startups exist in conditions of too much uncertainty. You can plan for something related to reality only in
based on a long and stable business history and conditions regarding a static market. Startups have no history, and they grow in an environment that changes with extraordinary speed.

The second problem is the lack of a plan and management system. When you start a startup, you actually build a business. Any business needs management. This simple idea sometimes introduces start-up entrepreneurs into a stupor, as they believe that management and a startup are two incompatible things. Entrepreneurs oppose any attempts to introduce a management system from the first days of a startup, fearing that this system will kill the creativity on the vine and create an unnecessary bureaucracy. What often happened when experienced managers tried to stuff the square logic of a startup into the round hole of a standard management model.

How to evaluate your work?

Most people working in startups rate their work by how well and how long they have worked today. For example, if the programmer was sitting for 8 hours, not looking up from the monitor, and was programming - this is a good day. If you were torn away from work with questions or, God forbid, with meetings, it means that you worked badly. How in this case to evaluate the result? Generated a lot of code - this is good. This is usually the case, because the lines of code, the implemented new function are tangible things that a programmer can see for himself and show to others.

But to evaluate the results of their work should be different. Unfortunately, many startups often program what eventually turns out to be unnecessary. In this case, it doesn’t matter if we programmed it in the planned time and did it in the budget.

The main task of a startup is to understand what really needs to be programmed - what your users will want and whether they will pay for it - and the sooner the better.

You can read my entire retelling by downloading the file by the link .