Колонки

«Не взлетел»: 10 стратегических ошибок, которые могут привести к закрытию нового проекта

Колонки
Ольга Шеина
Ольга Шеина

Исполнительный директор «Профиланс Групп», профессиональный коуч ICF

Анастасия Удальцова

Запуск нового проекта — задача непростая, особенно когда ранее компания работала только над одним. Как избежать ошибок из-за недостатка опыта?

Ольга Шеина, исполнительный директор «Профиланс Групп» и профессиональный ICF-коуч, поделилась десятью рекомендациями из практики и разобрала ошибки компании, из-за которых пришлось закрыть восемь проектов.

«Не взлетел»: 10 стратегических ошибок, которые могут привести к закрытию нового проекта

Содержание: 

 

Нашему флагманскому проекту «Все сдал!» в этом году исполняется уже десять лет. И долгое время мы были маленькой компанией только с одним этим проектом.

Но потом попробовали запустить еще один проект, потом другой и третий. Последние годы мы работаем по принципу стартап-конвейера: запускаем новые проекты каждые три месяца, а то и чаще. Итого в копилке около 20 запущенных проектов.

Мы умеем делать это быстро и понимать, будет проект приносить прибыль или нет. Стараемся проверять гипотезы с минимальными вложениями денег и времени. 

Но сейчас речь не про методологию запуска, она заслуживает отдельного материала. Дело в том, что наши запуски не всегда были быстрыми и экономичными. Когда мы только начинали запускать новые проекты, у нас был совсем другой подход. Новым проектом будем считать отдельное направление бизнеса с работоспособным продуктом, отдельным руководителем проекта и командой.


Читайте по теме:

Не ждать «лучших времен»: реализуем проект в любых условиях

Зачем разработчики создают сразу несколько сторонних проектов


Как следствие, проекты запускались долго, дорого и не принесли ожидаемых результатов. Поэтому со слезами на глазах мы их закрыли. Восемь проектов. 

Почему этот опыт нам не помог:

  1. мы не проводили ретроспективу, чтобы понять, что послужило причинами закрытия.
  2. мы не писали список действий, который приведет нас к другому результату. Как итог, повторяли этот опыт снова и снова.

Сейчас мы действуем иначе и предлагаем вам пройтись по ошибкам, которые неминуемо приведут закрытию нового проекта. 

 

Ошибка 1. Опираться на свое мнение и не общаться с клиентами

Если нам что-то нравится, абсолютно не факт, что люди разделяют наш восторг от продукта и готовы за него платить. Мы так и не смогли придумать факторы, которые приведут к успеху проект про биохакинг. Да, тема новая и интересная.

Наш руководитель очень горит идей долголетия и биотехнологий, но клиенты «не проголосовали рублем» ни за доступ к обучающей платформе, ни за сопровождение специалиста, ни за отдельные дешевые блоки контента по биохакингу. 

К слову, опрос потенциальной аудитории перед запуском этого проекта мы не проводили.

 

Ошибка 2. Строить сразу завод, вместо того, чтобы проверить востребованность идеи

У нас не было и доли сомнения, что курсы по Soft Skills нужны всем. Ведь это то, без чего не начинается карьерный или любой другой рост?

Мы потратили сумму с шестью нулями на продакшн первой части курса. С арендой дорогих машин и актерами. Наняли команду методистов и были готовы покорить мир с нашим оригинальным продуктом.

Продаж были слезы, суровый мир инфобиза «выплюнул» наш продукт.

Еще пример: сайт с максимумом функционала, который мы могли придумать. Писали мы и такой восемь лет назад. Писали долго и дорого.

А потом пришел клиент и сказал, что большая часть этих функций была не нужна. И даже путала и усложняла работу пользователей на сайте. Поэтому нам пришлось их отключать, оставляя только основные.

Теперь перед тем как запускать что-то новое, мы собираем самый минимум необходимого функционала, тестируем спрос. И только если видим, что проект набирает обороты, спрашиваем у пользователей, чего им не хватает и почему.

После сбора обратной связи от пользователей, изучения конкурентов, оценки стоимости внедрения мы принимаем решение о дальнейшем развитии.

 

Ошибка 3. Отсутствие утвержденных на старте метрик для оценки успешности проекта

Сейчас мы можем протестировать спрос на продукт (MVP) за пару месяцев, но когда-то мы и спустя два года не понимали, что проект пора закрывать. 

Так мы нянчились с проектом «Турбо Ассистент»: пробовали разные варианты продаж, дорабатывали сайт, процессы работы с заказчиками и исполнителями. Но эти пробы растягивались во времени — все казалось, что еще чуть-чуть, и мы увидим стремительный рост числа клиентов и дохода. 

Но роста так и не произошло. Почему мы ждали два года? Потому что сразу не договорились, что для нас будет являтся причиной для закрытия.

Теперь мы четко знаем и еще до начала работ над проектом фиксируем — какой результат и через какой период времени мы хотим получить. Что будем делать, если результат не достигнем. Поэтому когда наступает день Х, мы смотрим на результаты и решаем, какой будет следующий шаг. Благодаря этому тестирование гипотез сократилось с двух лет до двух месяцев.

 

Ошибка 4. Отсутствие согласованности между собственником и командой

Собственник вкладывает свой смысл в проект, отдает команде, а та вообще делает все иначе. 

Мы тоже столкнулись с такой ошибкой, и теперь она описана как кейс для принятия решения при найме руководителей в новые проекты. Так получилось, что информацию о новой идее передали устно одному сотруднику. Он транслировал ее еще двум сотрудникам команды, и они начали работу по подготовке к запуску. Но получился сломанный телефон. 

Через два месяца упорной подготовки прототипа сайта мы увидели, что первоначальный замысел бизнес-идеи кардинально отличается от того, что получилось. Поэтому запуск проекта был сильно затянут, пришлось все переделывать. 

После этой ошибки мы действуем так:

  1. При получении задачи заполняем бриф и совместно его обсуждаем с заказчиком и командой проекта.
  2. Договариваемся о промежуточных точках контроля и сверки.
  3. Формулируем ключевые тезисы и смыслы, которые вкладываем в проект.

 

Ошибка 5. Слабая команда проекта 

Когда у команды мало опыта в запуске новых проектов и тестировании гипотез, можно легко уйти в постоянные улучшения и тянуть с реализацией задач. Чтобы запускать новые проекты и делать это быстро, нужны определенные навыки и мышление. 

Сейчас у нас разделение команд на тех, кто занимается запуском и кто развивает уже действующие проекты. Первые спокойно могут пренебрегать лишним функционалом для ускорения запуска и выпускать на рынок дизайн, который еще можно доработать. Те же, кто работают в уже запущенном проекте, больше сконцентрированы на усовершенствовании продукта.


Читайте также:

Бизнес как море: 5 советов по управлению командой, чтобы не потопить проект

Как определить, что компании пора запускать новый продукт


 

Ошибка 6. Раздувание штата для новых проектов 

Это когда на самом старте бизнеса сразу нанимают полный комплект менеджеров, несколько маркетологов, программистов, бухгалтера и других сотрудников. 

Мы совершили эту ошибку в одном из закрытых проектов, когда ФОТ составил ~80% расходной части проекта. Тогда мы думали, что полная команда — это отлично, и вместе действительно можно делать быстрее и эффективнее. 

Но при таком подходе:

  • появляется риск перекладывания ответственности, лишние коммуникации и согласования;
  • возрастают налоги и расходы на ФОТ. Как правило, в начале пути у некоторых должностей еще не такая загрузка, а кого-то нет смысла вообще трудоустраивать, пока не ясен результат запуска.

Поэтому перед утверждением новой должности или сотрудника убедитесь, насколько это сейчас ускорит запуск проекта? Можно ли легко и без ущерба передать эти функции на аутсорс или фрилансерам?

 

Ошибка 7. Запуск продуктов, спрос на которые не сформирован, и ожидание быстрой прибыли или сверхрезультатов

Если вы запускаете продукт, который до вас либо вообще отсутствовал, либо только начинает появляться на рынке, будьте готовы, что вам может потребоваться время на раскачку и формирования спроса у вашей аудитории.

Заложите это в финансовый план и поймите для себя, сколько средств вы готовы вложить и сколько времени ждать до получения той прибыли, которая вас устроит.

Так у нас было с проектом по детской психологии. Как обычно, идея классная, рынок вроде бы есть (почти в каждой же семье есть дети), но запрос на психологов возникал у единиц — не принято в нашей стране активно заниматься ментальным здоровьем своих детей, успеть бы развезти их на все кружки и секции.

 

Ошибка 8. Игнорирование unit-экономики на старте

Проект может пользоваться спросом, но при прогнозировании прибыль от него может быть настолько крошечной, что даже и не стоит начинать.

Конечно, все зависит от выбранной бизнес-модели, скажете вы. Да, и ее стоит рассчитывать на старте, закладывая среднюю стоимость заявки. 

Так у нас случилось с проектом по онлайн-диетологии. Спрос есть, клиенты платят, но при расчете unit-экономики получалось, что положительная прибыль по проекту наступила бы только спустя пять лет. При трех разных сценариях финмодели результат примерно одинаковый. Если бы прикинули это уже на старте, то проект просто бы не запускали.

 

Ошибка 9. На старте проекта усложнять процессы 

Подход MVP должен сохраняться во всем: от создания только базовых функций продукта до построения работы внутри команды. Сразу подключать все возможные сервисы, писать регламенты, задействовать все возможные каналы трафика — не требуется на старте

Сейчас мы делаем все по мере необходимости и на основе полученного опыта, поскольку предусмотреть все ситуации нереально.

Проще быстро адаптироваться к новым условиям по мере их появления. 

Например, если клиент захотел консультацию вместо сопровождения (про ту же онлайн-диетологию), мы организовали ее за десять минут. Если пока хватает таблицы Google Sheets для учета клиентов, зачем подключать CRM?

Везде должен быть предел, до которого еще можно что-то делать по-простому, а после него уже необходимо вкладываться в сложные вещи.

 

Ошибка 10. No risk management. At all

На старте каждого нового проекта мы теперь всегда оцениваем риски.

  • Что будем делать, если произойдет какое-то событие?
  • Как мы можем уже сейчас предотвратить его?

Конечно, не в наших силах было повлиять на пандемию, но мы могли бы разработать планы Б и В для быстрой адаптации к ней. Это один из постулатов так называемой антихрупкости.

RB.RU готовит большое обновление — и мы хотим учесть пожелания и интересы вас, наших читателей. Если вы готовы поделиться своим мнением об RB.RU, переходите по ссылке, чтобы заполнить короткую анкету.

Риски могут быть самыми различными, от утечки информации до пандемии. Конечно, предусмотреть все нереально, но с опытом приходит понимание, какие факторы обязательно необходимо учитывать на старте проекта. Например, что не будет заявок, низкая конверсия в продажу, юридические сложности.

Фото на обложке: Shutterstock / hugo_34

Подписывайтесь на наш Telegram-канал, чтобы быть в курсе последних новостей и событий!

Нашли опечатку? Выделите текст и нажмите Ctrl + Enter

Материалы по теме

  1. 1 5 типичных ошибок при создании hardware-стартапа: как сделать по-настоящему нужный продукт
  2. 2 7 бизнес-катастроф, которые вошли в историю
  3. 3 Customer Development и Customer Discovery — в чем разница?
  4. 4 Выйти на международные рынки: подготовка продукта и компании
  5. 5 Ожидание и реальность: как не разочароваться в инновациях
ArtTech — карта разработчиков арт-технологий
Все игроки российского рынка технологий для искусства
Перейти