В середине марта мы, фактически, закрыли наш стартап 9facts.com, о котором я писал на Хабрахабре в декабре. И вот к маю я таки созрел на написание этого поста.
Начну с самого важного:
Какие ошибки сделали мы?
1. Идея не была провалидирована
Наиболее важные гипотезы для любого стартапа:
- Продуктом будут пользоваться следующие категории пользователей: …
- Объем рынка продукта: …
Каждая из них нуждается в проверке. Самый надежный способ такой проверки — разработка протитипа, все остальное (опросы и т.п.) имеет гораздо меньшую точность. Мы же, фактически, пропустили этот этап, решив делать относительно качественный продукт сразу.
Это произошло потому, что у меня (да и не только) была абсолютная уверенность в том, что мы делаем продукт, который найдет своих пользователей. На деле же это была всего лишь гипотеза.
Стоит сказать, что сигналы того, что идея является рискованной — были:
- Не было найдено ни одного успешного стартапа, использующего схожую модель описания активностей пользователей. “Конечно же, все это потому, что до этого просто никто еще не додумался!” — примерно так я тогда думал.
- Нас должно было насторожить то, что практически все девушки и женщины, опрошенные мной и другими участниками проекта, не совсем понимали, зачем им на такой сайт ходить постоянно. Мужчины реагировали на описание сервиса весьма и весьма оптимистично, а вот женщины — более скептически. Похоже, правда в том, что они более прагматичны в оценках, и нам стоило обратить на это внимание, а не списывать все на то, что они — просто не наша ЦА.
Все это привело примерно к такой цепочке событий:
- На разработку первой версии сервиса было выделено слишком много ресурсов. Прототипа не было.
- После запуска сервиса быстро выяснилось, что пользовательская база у нас растет не так быстро, как нам хотелось бы.
- Мы сделали несколько попыток исправить это (улучшали UX, добавили вирусные фичи а-ля “Опросник”, проверяли, имеет ли смысл слегка менять концепцию) — безрезультатно.
- На самом же деле ключевая проблема была в том, что у нас низкий user engagement. Проще говоря, не совсем понятно, зачем пользователям появляться на нем снова и снова. Но как только мы это поняли (это произошло в январе-феврале), стало понятно и то, что мы не знаем, как исправить это в рамках текущей концепции сервиса и имеющегося бюджета.
- И именно поэтому нужно было начинать с прототипа. Думаю, даже серьезная попытка моделирования работы пользователя на сервисе могла бы привести нас к выводу о том, что нас ждут проблемы с user engagement.
2. Неверная модель рисков
Так как я считал, что продукт будет гарантированно интересен пользователям (см. 1), риск появления потенциальных конкурентов считался наиболее значимым для нас в первые месяцы. Потому нашей целью стал выпуск качественного продукта в максимально короткий срок.
Трудно сказать, насколько сильно я ошибся в части того, что конкуренты появятся — уже осенью у Facebook появился Open Graph API, который нацелен на решение весьма схожей проблемы. Но совершенно верно то, что конкурентов стоит бояться только когда у вас уже есть рынок и пользователи. Если же их еще нет, думать надо вовсе не о конкурентах.
3. Неверное распределение ресурсов
В результате в течение первых 6 месяцев мы потратили заметно больше средств на разработку, чем следовало, израсходовав практически все деньги, “поднятые” мною в мае. Достаточно сказать, что в июле-сентябре над проектом одновременно работало до 8 человек.
Большой размер команды, отсутствие прототипа, а соответственно, и живых отзывов пользователей негативно сказалось и на наших приоритетах:
- Мы потратили значительное время на создание таксономии ключевых слов (мы “выкачали” массу категорий терминов с freebase.com), хотя в момент запуска можно было обойтись и без этого.
- Стоило полностью “забить” на группы. Но так как ресурсы на то были, мы их сделали.
- Весь UI с “дружбой” не стоило делать вообще. Вместо этого имело смысл считать всех ваших друзей в Facebook/LinkedIn и т.п. вашими друзьями и на 9facts. “Дружба” на еще одном сайте — зло само по себе, и думаю, запусти мы даже совершенно сырой прототип, мы поняли бы это сразу (собственно, это и произошло в ноябре).
- Работы по подготовке сервиса к масштабированию можно было не делать — сейчас хорошо понятно, почему.
Это далеко не полный список того, чего делать не стоило — в ретроспективе ошибки часто кажутся очевидными, потому перечислять сейчас все просто не имеет смысла.
Важно же то, что если бы я не допустил ошибку №1 (и как следствие — №2 и №3), размер команды на начальном этапе был бы значительно меньше, и в результате у нас было бы гораздо меньше возможностей сделать нечто ненужное. Я почти уверен, что делай мы все это втроем, мы так же запустили бы прототип в сентябре-октябре. Да, он был бы несколько проще, но на главный вопрос он ответил бы ничуть не хуже.
Пожалуй, единственным минусом “экономичного” варианта могло бы быть только то, что мы не попали бы на Start-up Rocket. Но даже это спорно, так как Start-up Rocket и все последующие подобные мероприятия, несмотря на их очевидную пользу для меня лично, отняли массу времени и энергии.
4. Отсутствие “пессимистичного” плана
Откровенно говоря, я не знал, что стоит делать, если все пойдет не так, как мне кажется. В такой ситуации нужно менять как сам сервис, так и подход к его продвижению, и все это крайне сложно делать, если эти варианты не рассматривалось всерьез заранее.
“Не знал” не означает, что я не знал совсем — мы пробовали менять концепцию сервиса, добавлять вирусные фичи и т.п., но ничего из этого не сработало. Сейчас мне кажется, что увидеть все эти недостатки можно было еще во время разработки концепции сервиса.
“Пессимистичный” план развития должен быть основным.
Дополнение от инвесторов
Леонид и Александр (“Прожектор Венчурз”) назвали ключевую ошибку, сделанную ими: “Дали слишком много денег слишком рано. Если бы этих денег не было, то и ты бы не смог нанять 8 человек делать ненужное. Урок нам.”.
Стоит сказать, что я так же этому поспособстововал, договорившись о софинансировании проекта с двумя другими соучредителями X-tensive.com, таким образом удвоив объем доступных нам средств.
Намного более подробный разбор полетов со стороны инвесторов изложен в соответствующем посте Леонида Волкова — я очень советую вам его почитать.
Выводы
- Идея не стоит ничего.
- Самым значимым риском IT-стартапа является несоответствие продукта рынку, а потому...
- Идея должна быть провалидирована. Практически единственный надежный способ валидации новой идеи для IT-стартапа — разработка прототипа.
- Если у вас нет прототипа, тратить какие-либо деньги на разработку первой версии продукта крайне рискованно. Вероятно, в нашем случае можно было бы потратить в 2-3 раза меньшую сумму в экономном варианте, и следовательно, получить в несколько раз больше времени на адаптацию.
- Оптимальный размер команды на этапе разработки и запуска прототипа — 2-3 человека. Чем меньше людей в коменде, тем меньше вероятность того, что будет сделано что-то лишнее.
- Ни в коем случае не стоит расчитывать на то, что все пойдет хорошо и гладко. В 99% случаев все идет совершенно не так, как виделось основателям. Потому “тощий” (экономный) стартап — единственный разумный вариант развития.
- Никакие второстепенные индикаторы успеха (победы на конкурсах стартапов и т.п.) не играют совершенно никакой роли. Единственный значимый индикатор успеха — рост пользовательской базы или дохода (в зависимости от ваших целей в данный момент).
- Ставка на вирусные особенности сервиса не приведет ни к чему хорошему, если сервис не является интересным сам по себе. Иначе говоря, вирусные фичи — это такой же rocket fuel, как и венчурный капитал. Для того, чтоб ими воспользоваться, нужно сначала построить саму ракету.
Забавно: в том, что написано выше, нет ничего нового и уникального. Несмотря на то, что стартапы “взлетают” и “падают” по совершенно по-разному, законы, в соответствии с которыми строятся дествительно удачные модели поддаются обобщению:
- если вы потратите все средства на разработку только одной модели, ваши риски будут безумно высоки
- маленкая и дешевая модель, как правило, дает хорошую оценку летных качеств полноценной модели той же формы
- состав команды инженеров определяет успех предприятия на 80-90%.
В этом смысле Eric Ries и Steve Blank совершенно правы. Вам же стоит извлечь максимум из опыта тех, кто прошел этот путь до вас.
Попробую перечислить то, на что вы навряд-ли обратите внимание, читая о стартапах:
1. То, что вы прочли “The Lean Startup” и др., вовсе не гарантирует, что вам удастся применить все рекомендации авторов на практике при первом же удобном случае. Лично я обманул себя сам, допустив, что моя идея заведомо хороша, и потому не требует валидации — в результате получился отличный, но весьма дорогой урок.
2. Даже если вы идеально выполните все рекомендации, это не устранит огромный риск провала. Цель №1 любой жизнеспособной методологии управления стартапами — максимизация отношения прибыли к инвестициям в среднем (т.е. на большой выборке стартапов). Она не может существенно повлиять на такие факторы, как качество команды основателей и жизнеспособность идеи. Таким образом, минимизация убытков в случае провала и максимизация времени на адаптацию — это лучшее, что может дать хорошая методология среднему стартапу.
3. Закрытие стартапа — весьма неприятный процесс для его основателя. Довольно подробно я описал свои ощущения от закрытия 9facts в ответе на соответствующий вопрос на Quora. В тот период даже по моему блогу было заметно, что с делами и настроением у меня все не очень хорошо — с нового года я практически ничего не писал. Думаю, как только я определюсь со следующим проектом, я “вернусь” и в блог (но вы меня не ждите — подписаться можно и прямо сейчас :) ); пока же я доволен тем, что сэкономленное таким образом время не пропадает впустую.
4. Деньги на стадии идеи получить заметно легче, нежели на стадии, когда у вас уже есть продукт. На стадии идеи все решает то, какое впечатление на инвестора производите вы лично, ваша команда и нравится ли ему идея продукта. Если вы весьма конкурентноспособны как разработчик и тимлид, а идея — не совершенно безумна, шансы найти инвестора на этой стадии достаточно высоки, даже если презентация — это все, что у вас есть.
Все намного сложнее, если у вас уже есть прототип или продукт (не важно, кстати, какого качества): на этой стадии любого инвестора, с которым вы общаетесь, интересует исключительно traction. Рост пользовательской базы, числа платящих подписчиков, оборота, месячной аудитории и т.п. — любых метрик, которые характеризуют потенциал продукта. И если вы не можете показать хороший рост (а это, как минимум, 20-30% в месяц на начальном этапе, а лучше — 50-60%), ваши дела плохи. Никакие презентации вам не помогут, как и разговоры в стиле “мы только что запустились, и оценивать нашу аудиторию пока рано”. Любой инвестор в такой ситуации будет склонен занять выжидательную позицию — согласитесь, ведь намного разумнее подождать 2-3 месяца и оценить результат, нежели принимать на себя риски вслепую.
5. Ранее я считал, что для проверки качества вашей идеи вам обязательно стоит найти инвестора на этой стадии. Сейчас я склоняюсь к тому, что прототип продукта (или MVP) практически всегда лучше делать своими силами (т.е. исключительно за счет времени и средств команды основателей). Привлекать инвесторов стоит уже после того, как у вас появились первые пользователи, которым действительно нравится ваш продукт.
Почему?
- Предыдущий пункт показывает, что если вы найдете инвестора на стадии идеи, то это будет на 95% оценкой команды основателей и ваших презентационных способностей; идея же просто пройдет тест-минимум на адекватность. Кстати, это объясняет, почему идея не стоит ничего.
- Более жесткие ограничения на доступные ресурсы приведут к более качественному выбору фич MVP.
- Скорее всего, такой бутстрэппинг займет больше времени, т.к. вы не сможете выделить все ваше время на работу над прототипом. С другой стороны, времени на принятие решений у вас так же будет больше, а значит, они будут более взвешенны.
- Вам не придется тратить время на открытие компании, переговоры и соглашения с инвесторами, подбор и найм сотрудников, отчетность и т.п.
- Вы существенно уменьшите риски для инвестора и всех будущих членов вашей команды, и вероятно, в 5-10 раз увеличите оценочную стоимость стартапа на момент первой инвестиции. Если сейчас вам все это не кажется важным, вспомните, что 95% стартапов закрываются в течение 1-2 лет, и потому пройти наиболее рискованный участок самому стоит, если вы не склонны перекладывать часть рисков на остальных. Если вы не совсем понимаете, почему это не так привлекательно, как может казаться — перечитайте п.3 и вспомните про 95%.
Эпилог
В заключение стоит сказать, что 9facts принес немало позитивного в наши жизни:
- Проект стал отличной практикой для всей команды — даже в техническом смысле он был весьма интересным.
- Я получил новый для меня опыт общения с инвесторами, инвестфондами и просто массой интересных людей, имеющих отношение к IT-стартапам. В первую очередь это общение с Леонидом Волковым и Александром Гощицким (Прожектор Венчурз), и далее — Startup Rocket, Startup Sauna (там был Алексей Штин), два StartupPoint, i-Convention (Y Combinator, 500 Startups и др.), Yandex.Start, Farminers и Runa Capital.
- Думаю, каждый из нас получил один из лучших уроков в своей жизни, прибавив +100500 к опыту.
- Наконец, в результате я написал эту статью, + всю предысторию. Надеюсь, это поможет кому-то из вас, друзья, сделать нечто стоящее, и в результате наш мир станет чуточку лучше и удобнее. А вы скажете: “Все благодаря 9facts!”. Шучу, конечно :)
9facts, R.I.P.
P.S. Для авторов уже “умерших” стартапов: историй фэйлов на Хабрахабре (да и вообще) не так уж и много, хотя в жизни их в десятки и сотни раз больше, нежели историй успеха. Мне кажется, их заметно меньше вовсе не потому, что никто не хочет их читать. Никто не хочет их писать. “Сначала сделаю что-нибудь мегакрутое, а потом уж займусь мемуарами, где и расскажу обо всех своих фейлах!” — подобные отмазки вполне типичны и понятны. Так вот, попробуйте написать ваши “мемуары” прямо сейчас. Если историй будет достаточно много, на Хабре может появится новый раздел “Epic fail”,
