9facts: debriefing

In the middle of March we, in fact, closed our startup 9facts.com , about which I wrote on Habrahabr in December. And by May, I was still ripe for writing this post.

I'll start with the most important:

What mistakes have we made?

1. The idea was not validated.

The most important hypotheses for any startup:
')

• The product will be used by the following categories of users: ...
• Market volume of the product: ...

Each one needs to be checked. The most reliable method of such verification is the development of a prototype, everything else (polls, etc.) has much lower accuracy. We, in fact, missed this stage, having decided to make a relatively high-quality product right away.

This happened because I (and not only) had absolute confidence that we are making a product that will find its users. In fact, it was just a hypothesis.

It is worth saying that the signals that the idea is risky were:

• No successful startup was found using a similar model for describing user activities. “Of course, all this is because no one has thought of this before!” - I thought about that.
• We should have been alerted by the fact that almost all the girls and women surveyed by me and other participants in the project did not quite understand why they should go to such a site all the time. Men responded to the description of the service very, very optimistic, but women - more skeptical. It seems that the truth is that they are more pragmatic in their assessments, and we should have paid attention to this, and not blamed everything on the fact that they are simply not our Central Asia.

All this led to something like this chain of events:

1. To develop the first version of the service was allocated too many resources. There was no prototype.
2. After launching the service, it quickly became clear that the user base is not growing as fast as we would like.
3. We made several attempts to fix it (improved UX, added virus features a la “Questionnaire”, checked whether it makes sense to slightly change the concept) - to no avail.
4. In fact, the key problem was that we have low user engagement. Simply put, it is not entirely clear why users should appear on it again and again. But as soon as we understood this (it happened in January-February), it became clear that we do not know how to fix it within the framework of the current concept of the service and the available budget.
5. And that is why it was necessary to start with a prototype. I think that even a serious attempt at modeling the user experience on the service could lead us to the conclusion that we are facing problems with user engagement.

2. Invalid risk model

Since I believed that the product would be guaranteed to be of interest to users (see 1), the risk of potential competitors appearing was considered most significant for us in the first months. Therefore, our goal was to produce a quality product as soon as possible.

It is hard to say how much I was mistaken in terms of what competitors will appear - in the fall Facebook had an Open Graph API, which aims to solve a very similar problem. But it is absolutely true that competitors should be afraid only when you already have a market and users. If they are not there yet, we should not think about competitors at all.

3. Incorrect resource allocation

As a result, during the first 6 months, we spent significantly more money on development than we should, having spent almost all the money “raised” by me in May. Suffice to say that in July-September, up to 8 people worked simultaneously on the project.

The large size of the team, the lack of a prototype, and, accordingly, live user feedback also had a negative impact on our priorities:

• We spent considerable time creating a taxonomy of keywords (we “pumped out” a lot of categories of terms with freebase.com ), although at the time of launch it was possible to do without it.
• It was necessary to completely “score” on the group. But since the resources were there, we made them.
• The whole UI with “friendship” was not worth doing at all. Instead, it made sense to count all your friends on Facebook / LinkedIn, etc. your friends and at 9facts. “Friendship” on another site is evil in itself, and I think if we even started a completely raw prototype, we would understand it right away (in fact, this happened in November).
• The work on preparing the service for scaling could not be done - it is now clear why.

This is not a complete list of what it was not worth doing - in retrospect, mistakes often seem obvious, because now everything simply does not make sense to list.

It’s important that if I didn’t make a mistake №1 (and as a result - №2 and №3), the size of the team at the initial stage would be much smaller, and as a result we would have much less opportunities to do something unnecessary. I am pretty sure that we all do it all together, we would also launch a prototype in September-October. Yes, he would be somewhat simpler, but he would answer the main question no worse.

Perhaps the only drawback of the “economical” option could be only that we would not hit the Start-up Rocket. But even this is debatable, since Start-up Rocket and all subsequent similar events, despite their obvious benefits for me personally, took away a lot of time and energy.

4. The absence of a “pessimistic” plan

Frankly, I did not know what to do if everything goes wrong, as it seems to me. In such a situation, it is necessary to change both the service itself and the approach to its promotion, and all this is extremely difficult to do if these options are not considered seriously in advance.

“I didn’t know” does not mean that I didn’t know at all - we tried to change the concept of the service, add virus features, etc., but none of this worked. Now it seems to me that it was possible to see all these shortcomings during the development of the service concept.

A “pessimistic” development plan should be the main one.

Supplement from investors

Leonid and Alexander (“Searchlight Ventures”) called the key mistake they made: “They gave too much money too soon. If this money were not, then you would not be able to hire 8 people to do unnecessary. Lesson to us. ”.

It is worth saying that I also contributed to this by agreeing to co-finance the project with two other co-founders of X-tensive.com , thus doubling the amount of funds available to us.

Much more detailed debriefing by investors is set out in the relevant post by Leonid Volkov - I strongly advise you to read it.

findings

1. The idea is worth nothing.
2. The most significant risk of an IT startup is the product’s mismatch with the market, and therefore ...
3. The idea must be validated. Practically the only reliable way to validate a new idea for an IT startup is to develop a prototype.
4. If you do not have a prototype, it is extremely risky to spend any money on developing the first version of a product. Probably, in our case, it would be possible to spend 2-3 times less amount in an economical version, and therefore, to get several times more time for adaptation.
5. The optimal size of the team at the stage of development and launch of the prototype is 2-3 people. The fewer people in the team, the less likely it is that something extra will be done.
6. In no case should we expect that everything will go well and smoothly. In 99% of cases, everything is completely different from what the founders saw. Therefore, a “lean” (economical) startup is the only reasonable development option.
7. No secondary indicators of success (wins in start-up competitions, etc.) play absolutely no role. The only significant indicator of success is the growth of the user base or income (depending on your goals at the moment).
8. Relying on the viral features of the service will not lead to anything good if the service is not interesting in itself. In other words, viral features are the same rocket fuel as venture capital. In order to use them, you must first build the rocket itself.

Funny: in what is written above, there is nothing new and unique. Despite the fact that startups “fly up” and “fall” in completely different ways, the laws, according to which really successful models are built, can be summarized:

• if you spend all the money on developing only one model, your risks will be extremely high
• small and cheap model, as a rule, gives a good assessment of the flight qualities of a full-fledged model of the same form
• The composition of the engineering team determines the success of the enterprise by 80-90%.

In this sense, Eric Ries and Steve Blank are absolutely right. You should make the most of the experience of those who have come this way before you.

I will try to list what you hardly notice when reading about startups:

1. The fact that you have read “The Lean Startup” and others, does not guarantee that you will be able to apply all the recommendations of the authors in practice at the first opportunity . Personally, I deceived myself by admitting that my idea was deliberately good, and therefore does not require validation - the result was an excellent, but very expensive lesson.

2. Even if you follow all the recommendations perfectly, it will not eliminate the huge risk of failure . Objective # 1 of any viable start-up management methodology is to maximize the ratio of profit to investment on average (i.e., on a large sample of start-ups). It cannot significantly affect factors such as the quality of the founding team and the viability of the idea. Thus, minimizing losses in the event of failure and maximizing the time for adaptation is the best that a good methodology can give to an average startup.

3. Closing a startup is a very unpleasant process for its founder . In some detail I described my feelings about the closing of 9facts in response to the corresponding question on Quora . At that time, even in my blog, it was noticeable that everything was not very good with my affairs and mood - from the new year I practically wrote nothing. I think as soon as I decide on the next project, I will “return” to the blog (but you don’t wait for me - you can subscribe right now :)); In the meantime, I am pleased that the time saved in this way is not wasted.

4. Money at the stage of getting ideas is much easier than at the stage when you already have a product . At the idea stage, everything is decided by what impression the investor makes you personally, your team and whether he likes the idea of ​​the product. If you are very competitive as a developer and team-leader, and the idea is not completely insane, the chances of finding an investor at this stage are quite high, even if the presentation is all you have.

Everything is much more complicated if you already have a prototype or a product (it doesn’t matter what quality, by the way): at this stage, any investor with whom you communicate is interested only in traction. Growth in user base, number of paying subscribers, turnover, monthly audience, etc. - any metrics that characterize the potential of the product. And if you can not show good growth (which is at least 20-30% per month at the initial stage, and better - 50-60%), your business is bad. No presentations will help you, as well as conversations in the style of “we just started, and it’s too early to evaluate our audience.” In this situation, any investor will be inclined to take a wait-and-see attitude - you must agree, because it is much more reasonable to wait for 2-3 months and evaluate the result rather than take the risks blindly.

5. Earlier, I thought that to check the quality of your idea, you should definitely find an investor at this stage. Now I am inclined to think that it is almost always better to do a prototype of a product (or MVP) on your own (that is, solely at the expense of the time and resources of the founding team). It is worth attracting investors after you have the first users who really like your product.

Why?

• The previous item shows that if you find an investor at the idea stage, it will be 95% rated by the founding team and your presentation skills; the idea is just pass the test for adequacy. By the way, this explains why the idea is worth nothing.
• Tighter restrictions on available resources will lead to a better choice of MVP features.
• Most likely, such bootstrapping will take longer, because you can not allocate all your time to work on the prototype. On the other hand, you will also have more time for making decisions, which means that they will be more balanced.
• You do not have to spend time on opening a company, negotiations and agreements with investors, recruiting and hiring employees, reporting, etc.
• You will significantly reduce the risks for the investor and all future members of your team, and probably 5-10 times increase the estimated cost of the startup at the time of the first investment. If now all this does not seem important to you, remember that 95% of startups close within 1-2 years, and therefore it is worth going the most risky part yourself if you are not inclined to shift some of the risks to others. If you do not quite understand why it is not as attractive as it may seem - reread paragraph 3 and think about 95%.

Epilogue

In conclusion, we should say that 9facts brought a lot of positive things to our lives:

• The project was an excellent practice for the whole team - even in a technical sense, it was very interesting.
• I got a new experience for me to communicate with investors, investment funds and just a lot of interesting people related to IT start-ups. First of all, this is communication with Leonid Volkov and Alexander Goshchitsky (Searchlight Ventures), and then - Startup Rocket, Startup Sauna (there was Alexey Shtin), two StartupPoint, i-Convention (Y Combinator, 500 Startups, etc.), Yandex. Start, Farminers and Runa Capital.
• I think each of us received one of the best lessons in his life, adding +100500 to experience.
• Finally, as a result, I wrote this article, + the whole background . I hope this helps some of you, friends, to do something worthwhile, and as a result, our world will become a little bit better and more convenient. And you say: “All thanks to 9facts!”. Just kidding, of course :)

9facts, RIP

PS For authors of already “dead” startups: there are not so many stories of failes on Habrahabr (and indeed in general), although there are tens or hundreds of times more of them in life than success stories. It seems to me that they are noticeably smaller at all because no one wants to read them. No one wants to write them. “First I’ll do something mega-cool, and then I’ll take care of my memoirs, where I’ll tell you about all my Fails!” - such excuses are quite typical and understandable. So, try to write your “memoirs” right now. If there are a lot of stories, a new section “Epic fail” may appear on Habré, offering every loser to the public to dig himself a hole of the right size for everyone who is a loser , who is no less interesting than “ Success Stories ”.