Как сделать «убийцу Amazon» и почему это пока ни у кого не получилось

В США же изначально все было по другому. Джефф Безос из своего Аmazon не делал убийцу WalMart, Илон Маск не делал из PayPal убийцу MasterCard, Джек Дорси не делал из Twitter убийцу Facebook. Они находили новые потребности на существующем рынке.

А на российском ИТ-рынке все хотят пустить по миру какой-то чужой сервис или компанию. В e-commerce традиционно «пилят» убийцу Ozon и Wildberries, в Минпросвещения — убийцу TikTok с образовательным контентом. Недавно еще был убийца Google — поисковик «Спутник». И к чему это привело?

Попа как у Ким

К нам, я уверен, как и к большинству нормальных продакшен-студий, периодически приходят заказчики с котлетой денег и говорят: «Сделайте нам, как у Wildberries». Но, если разобраться, они не хотят сайт как Wildberries, на самом деле они хотят зарабатывать как Татьяна Бакальчук и подвинуть в списке «Форбс» Елену Батурину.

И это первая ошибка — все хотят заработать быстрых, шальных, больших денег, но мало кто хочет строить бизнес-модель, которая будет рабочей в долгосрочной перспективе. Во многом причина такого подхода в образовании бизнеса. Люди, взращённые «Бизнес молодостью», «Синергией» и вебинарами про успешный успех, предпочитают зарабатывать на простой «товарке», и им сложно изобрести что-то новое.

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

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

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

Инвестор и рад бы что-то сделать, но не может — денег-то уже нет. В итоге стартап умирает, едва появившись на свет. Потом как у Пелевина: «Тогда берётся второй кредит — в три раза больше первого».

Проблема в том, что и мой знакомый, и другие его аналоги забывают, что «Яндекс», Wildberries и Аmazon далеко не в один день запустили весь тот функционал, который имеют сейчас. У них на это были годы работы, тестирований, факапов, техническая, клиентская поддержка, разные команды разработчиков, и деньги. Понятно, что у стартапа всегда проблема именно с последним. Но для того, чтобы проект начал приносить деньги, в его основе должен лежать продукт, который постоянно развивается. А если не развивается, то должен быть план Б.

Какая-то тактика

Обычно цикл жизни очередного «убийцы Аmazon» выглядит так:

• Предприниматель смотрит на работающий проект, думает над адаптацией к своей нише\географии\компании и думает: «О, тут кажется есть деньги».
• Объявляется «тендер» на разработку сайта/приложения/сервиса.
• Заказчик получает мешок разных предложений от подрядчиков с бюджетом от 10 тысяч до 10 миллионов рублей.
• Выбирает предложение, где можно запуститься на «минималках» по деньгам. Не путать с MVP.
• Продукт разрабатывается и запускается с огромным количеством функций, но не взлетает.
• Предприниматель ещё какое-то время пытается реанимировать проект, вкладывая остаток средств, но в итоге забивает на него.

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

Иной продакт-менеджер может поспорить (и мы бы с радостью), но вот каким мы видим идеальный процесс создания продукта:

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

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

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

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

Тест рекламы. Если непонятно, сколько денег нужно на продвижение, запустите простые лендинги и пробные рекламные кампании. Проведите несколько продаж продукта и оцените отклик потребителя.

Подсчёт финансов. Пора посчитать юнит-экономику со всеми косвенными расходами. Вплоть до стоимости рабочих мест, стоимости своего рабочего времени и печенья. Когда нашли точку прибыли, можно идти дальше.

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

Разработка MVP. Не нужно фаршировать проект всеми возможными функциями — смотри пункт 7. Универсальная проверка: если кажется, что ни от чего отказаться нельзя, значит, можно вырезать ещё процентов 30 функций. «Режем» всё, что не позволяет зарабатывать.

Анализ. После запуска оцените статистику использования MVP, сформируйте новые гипотезы, которые принесут деньги, и начинайте круг заново. Эта штука называется HADI-циклы.

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

Хороший вариант: когда поддержкой продукта занимается тот же партнёр, кто участвовал в разработке. Тогда вероятность сохранить основные смыслы намного больше. Если же работают несколько команд, то ключ в подробной и понятной документации. Такой, чтобы через время потомки могли найти, прочесть и впечатлиться. И пилить уже своего «самоубийцу» вашего проекта.

Фото: depositphotos.com