Блог компании TeGo

Почему мы убили агрегатор мероприятий и пришли к идее маркетплейса ИТ-разработчиков

Как мы отказались от предыдущего проекта из-за слабого рынка и нашли новую идею проекта.

Маркетплейс команд разработчиков TeGo мы делаем небольшой, но очень крутой и амбициозной командой: Диана – ex-KROK, креативный ИТ-маркетолог, душа компании и главный мотиватор команды, я – продуктовый маркетолог, организатор бизнес-процессов и Никита – project-менеджер, который знает как собрать команду и разработать любой ИТ-продукт от А до Я. Это уже второй проект, который мы делаем с Дианой. Изначально появилась идея создания агрегатора мероприятий бизнес-клубов, где маркетологи находили бы проходящие поблизости мероприятия в одном месте. В процессе работы обнаружили, что рынок бизнес-клубов довольно незрелый для появления на нем маркетплейсов. Большинство клубов работают в формате самозанятости основателя, который является экспертом рынка и по выходным встречается с аудиторией своего блога попить кофе и обсудить профессиональные вопросы. На таком рынке тяжело взимать комиссию с продажи билета, т.к. часто стоимость билета составляет расходы на кофе и вознаграждение спикеру без существенной наценки. Попытаться сформировать этот рынок – тоже сомнительная идея. Так, после месяца исследований и попыток заключить партнерства, мы с командой решили оставить эту идею и сменить идею и рынок.

В поиске новой идеи мы изучали уже существующие проекты на западном рынке, предлагающие инновационные идеи. За основу взяли работающий проект на западном рынке, чтобы оттолкнуться от понятной потребности рынка. Мы предположили, что брать идеи из головы – опасная затея, потому что есть риск сделать продукт, который никому не нужен.

Поиск новой идеи проекта


Итак, мы отказались от идеи агрегатора мероприятий и обсудили критерии поиска новой идеи. Одним из главных критериев стал большой рынок – не менее 100 млн долларов. Мы остановились на двух идеях: первая – платформа управления проектами для закупок крупных партий товаров из-за рубежа, например, из Китая. Вторая - маркетплейс команд ИТ-разработчиков. У нашей команды есть опыт в ИТ-разработке крупных проектов, к тому же мы верим что за платформенной занятостью будущее. Диана делилась мыслями по поводу будущего рынка труда в статьях о сложности развития HR-бренда для борьбы за ИТ-разработчиков и отличия фриланс-биржи от human cloud платформы. Про опыт разработки готовы рассказать в личном диалоге, а насчет платформенной занятости предлагаем подискутировать в комментариях. Вы, кстати, как считаете?

В итоге остановились на маркетплейсе фриланс-команд по критерию простоты тестирования, но на счет простоты тестирования мы ошиблись. Идею проекта, несмотря на наличие маркетплейсной механики, решили протестировать на Тильде без создания самого маркетплейса. Маркетплейс, по сути, площадка, где встречается заказчик и исполнитель, а платформа берет комиссию за проведение операции и соединение продавца с покупателем. Эти манипуляции можно в простом варианте можно провести вручную, не затрачивая значительных ресурсов на разработку. Такое тестирование идеи мы выбрали, потому что придерживаемся продуктового подхода: сначала убедиться в наличии спроса, а потом уже что-то там разрабатывать и тратить деньги. Кстати, того же подхода – ни рубля лишнего не потратить – мы придерживаемся и в разработке для наших клиентов: сначала убеждаемся, что у нас полное ТЗ и точно будет спрос через продуктовые исследования, а потом начинаем работу над проектом.


Выводы из нашей работы


1. Хорошо сверить свои амбиции и размер рынка проекта. Вы сможете усилить продукт и команду, но рынок увеличить практически нереально.
2. В поиске идей проекта отталкивайся от существующих проектов на других рынках. Так шансы попадания в реальную потребность рынка существенно выше, чем у идеи, выдуманной из головы.
3. Прежде чем взять идею проекта в работу, определитесь с экспертизой вашей команды. Желательно, чтобы у команды были навыки, которые позволят проверить жизнеспособность идеи на рынке в кратчайшие сроки и в идеале – без привлечения существенных инвестиций. 
4. Прикиньте юнит-экономику для того, чтобы понять, про каких финансовых показателях ваш проект будет бизнесом, а не самозанятостью. Так у вас будет конкретный список предположений модели экономики, которые требуется проверить. Например, величина среднего чека, количество продаж на одного продавца и т.п.
5. Перед формированием оффера для нового проекта посмотрите, что предлагают на рынке конкуренты уже сейчас. В размышлениях о оффере вы как минимум оттолкнетесь от существующей потребности клиентов. Наверное, кто-то подумает, что я призываю копировать оффер конкурентов. Не копируете предложение конкурентов, а отталкивайтесь от него, чтобы усилить и сделать ещё круче. 
6. Попробуйте сформулировать оффер по модели RDB, чтобы коротко и наиболее полно отразит суть вашего предложения.
7. Постарайтесь начать тестирование рискованных предложений без вложений и больших затрат на создание и поддержание инфраструктуры проекта. Скорее всего, вас ждёт длинная череда тестирования гипотез и пивотов, которые могут сильно изменить первоначальную задумку. Нет хуже разочарования, чем потратить несколько месяцев на разработку, а после первых попыток продать обнаружить, что продукт никому не нужен или в нем надо что-то сильно менять.
8. Сначала продайте, потом разрабатывайте. Как можно скорее идите общаться и продавать продукт потенциальным клиентам. Вероятно, что предложения аудитории, каналов продаж и месседжей будут ошибочными, и вы сможете быстро это понять.
9. Изучайте no-code инструменты, чтобы уметь быстро проверить идеи IT-проектов без программирования и привлечения инвестиций. Сделали продукт за несколько дней и быстро проверили продажи – идеально.

Made on
Tilda