{"id":13711,"url":"\/distributions\/13711\/click?bit=1&hash=993ce7f10a29e09ef6007450140ef5fcebecd55805799940a93c3efe78cce5e3","title":"\u0411\u043e\u0438\u0442\u0435\u0441\u044c \u043d\u0435\u0434\u043e\u043e\u0446\u0435\u043d\u0451\u043d\u043d\u044b\u0445 \u0431\u0443\u043c\u0430\u0433? \u0412\u043e\u0442 \u043f\u0430\u0440\u0430 \u0441\u043e\u0432\u0435\u0442\u043e\u0432 \u043e\u0442 \u0438\u043d\u0432\u0435\u0441\u0442\u043e\u0440\u043e\u0432","buttonText":"\u0427\u0438\u0442\u0430\u0442\u044c","imageUuid":"9ff620a4-3fae-5002-9694-5d10fe8c5bbf","isPaidAndBannersEnabled":false}

Взлетит или не взлетит. Часть 2: Как мы готовы разделить риски стартапов

В этой статье я расскажу о том, как мы видим взаимодействие со стартапами по модели разделения доходов (revenue sharing) и чем такое партнерство может быть выгодно обеим сторонам.

Взлетит или не взлетит?

Ранее мой партнер Кирилл рассказывал о работе со стартапами по разным моделям, описав весьма общие критерии отбора проектов, с которыми мы готовы сотрудничать. Он упоминал, что для успешного запуска проекта начинающий стартапер должен проработать маркетинг и продажи своей идеи, а также быть готовым уделять этому проекту основную часть времени (за подробностями предлагаю обратиться к первоисточнику). Все это верно для любой модели сотрудничества. Но если речь заходит о модели разделения прибыли при практически нулевых первоначальных затратах стартапа на нашу техническую экспертизу (revenue sharing), к выбору основателя и идеи в основе партнерства мы подходим еще более вдумчиво.

Мы “садимся в ту же лодку”, что и стартап. Поэтому для нас важно, чтобы проект попал в хорошо знакомый нам технологический сегмент, успел проверить основные гипотезы, имел product owner, перспективы масштабирования за рамки локального рынка и дорожную карту развития, по крайней мере на первое время. Далее я подробно остановлюсь на каждом из пунктов.

Правильный сегмент

Нам комфортнее работать в тех областях, в которых мы хорошо разбираемся. Поэтому на роль партнеров мы рассматриваем стартапы из сегментов Ad Tech, Fintech в том числе, работающие с семейством технологий Blockchain. И сразу хочу сделать оговорку, что мы не занимаемся криптовалютами и криптобиржами. Blockchain мы используем для решения проблем реальных секторов экономики.

Проверка гипотез “бережливого стартапа”

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

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

О важности гипотез, кстати, пишет автор признанной методологии выживания стартапов Эрик Рис в своей книге «Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели». Желающие могут найти на VC множество статей по этой книге и в целом по теме “бережливого стартапа”.

Отсутствие ограничений по масштабу

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

Product owner

Обычно в команде стартапа выделяются роли технаря, который отвечает за доставку решения, а также специалиста по маркетингу и продажам, который понимает целевую аудиторию и выступает как своего рода product owner (если оперировать scrum-терминологией). Для успешного взаимодействия по модели revenue sharing нам на стороне стартапа нужен именно такой человек, который будет определять цели развития и их приоритеты. А вот техническую часть проекта мы можем взять на себя.

Дорожная карта

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

К сожалению, для стартапов типичен подход: “Что-то продукт наш не взлетает, давайте вот тут еще реализуем такую-то фичу, тогда точно взлетит”. Но он демонстрирует как раз отсутствие четкого понимания своего места на рынке и перспектив на выбранной целевой аудитории. Нам же на условиях разделения доходов интереснее работать с партнером, обладающим четким видением планируемого MVP, чтобы разработка была прогнозируема по срокам и стоимости.

Scope проекта неразрывно связан с видением итоговой цели.

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

Автор статьи: Максим Коротков, генеральный директор Maxilect

Обращайтесь, если у вас есть проработанная бизнес-идея, но нет команды.

PS. Наши технические статьи вы можете найти в блоге на Хабре. Следите за нашей активностью в социальных сетях: VK, FB и подписывайтесь на Telegram-канал.

0
4 комментария
Dima Kotobotov

есть ли успешные примеры работы по этой схеме?

Ответить
Развернуть ветку
Maxilect
Автор

В мире - да. Мы знаем такие примеры и в России. Для нас это предложение достаточно новое, и мы пока не встретили партнеров, с кем запустили бы работу по такой модели. Мы присматривались, и даже почти начали, но проект заморозили из-за смены приоритетов у партнера.

Ответить
Развернуть ветку
Александр Казанский

Интересует юридическая часть вашего соглашения, как защищены интересы обеих сторон?

Ответить
Развернуть ветку
Maxilect
Автор

На начальном этапе - по договоренности. Чаще всего старт с заказной разработки начинается, чтобы проверить в деле обе стороны. Затем доли в новой компании.

Ответить
Развернуть ветку
Читать все 4 комментария
null