Why startups die and other answers

I really liked the book The Lean Startup, written by Eric Ries. I advised her to read to all startup authors. True, it turned out that not everyone has the strength 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 knows for sure who their real users are and what the product really should be. Like any business, a web project needs to be managed. Someone somehow manages each startup, but most projects die. Why?

The first problem is unconditional trust in a good business plan, clear strategy and extensive marketing research. In the not-so-old days, business plans, strategies and studies were a good application for the success of most business undertakings. The temptation to introduce a similar approach to work planning in startups is enormous, but alas, this approach does not work in startups, since startups exist in conditions of too much uncertainty. You can plan something related to reality only
if you are 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 is changing with extraordinary speed.

The second problem is the lack of a plan and management system. When you start a startup, you are actually building a business. Any business needs to be managed. This simple thought sometimes leads into a stupor of novice entrepreneurs, as they believe that management and startups are two incompatible things. Entrepreneurs resist any attempt to introduce a management system from the first days of a startup, fearing that this system will kill creativity and create unnecessary bureaucracy. Which most often happened when experienced managers tried to shove the square logic of the startup into the round hole of the standard management model.

How to evaluate your work?

Most startup employees rate their work by how well and long they did today. For example, if a programmer sat for 8 hours without looking up from the monitor and programmed, this is a good day. If you were torn from work by questions or, God forbid, by meetings, then you did a poor job. How in this case to evaluate the result? Generated a lot of code - this is good. This usually happens, because lines of code, implemented a new function, are tangible things that a programmer can see for himself and show to others.

But it is necessary to evaluate the results of their work in a different way. Unfortunately, many startups often program things that end up being useless to anyone. In this case, it doesn’t matter if we programmed it for the planned time and whether it fit into the budget.

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

You can read all my retelling by downloading the file from the link .