Всем привет! Меня зовут Джеймс – я предприниматель. За свою карьеру я успел поработать в Яндексе, руководил несколькими распределенными командами разработки, создал свой IT-продакшен Neattech. io и еще несколько IT-стартапов.
В этой серии постов я поделюсь своим опытом в запуске IT стартапов. Надеюсь, он поможет избежать многих ошибок и вам!
Отсутствие фазы прототипирования, или MVP
❗ Ошибка № 1 по популярности – это отсутствие фазы прототипирования, или MVP.
При запуске IT-продукта с неизвестной unit-экономикой, как и в классическом бизнесе, нет гарантий, что идея окупится и принесет прибыль. Поэтому правильным будет задать вопрос: Как понять сходится unit-экономика или нет без инвестирования $250,000 в разработку?
Многие отвечают «мы сделаем MVP!» (Minimum Viable Product), подразумевая под этим, что выпустят приложение/платформу/сервис с урезанным количеством функций, и таким образом сократят разработку с $500,000 до $250,000.
Но если начать разбираться, что НА САМОМ ДЕЛЕ надо, чтобы проверить unit-экономику, то окажется, что надо понять, например, сможем ли мы привлекать пользователей по цене до $10 и сможем ли мы продавать хотя бы каждому десятому пользователю услуг на $200.
И тогда:
✔ Иногда сразу на старте становится понятно, что экономика не сходится: цифры выглядят нереалистичными.
✔ Если цифры выглядят реалистичными, то оказывается, что для теста достаточно собрать лендинг на Tilda, запустить трафик и проверить стоимость регистрации.
Чтобы проверить окупаемость, достаточно продавать ровно 1 товар/услугу без возможности выбора
Если из 300 пользователей никто не купит, то говорить о том, что получится каким-то дизайном, крутым функционалом или чем-то еще, связанным с IT-блоком, повысить конверсию хотя бы в 30 раз, довольно нереалистично.
Разобрав много стартапов, я пришел к выводу, что большинство IT-проектов в 2022 можно запустить на конструкторе с дизайном за $500, без автоматизации и с 3 фичами. Проверить спрос, unit-экономику, и уже потом инвестировать в разработку.
Дополнительные $250.000 в разработку на старте ничего не изменят. Проект будет либо успешен и без $250.000, либо не будет успешен и с $250.000. Только во втором случае придется зафиксировать убыток в $250.000 и 2 года жизни.
Но есть 10% проектов-исключений, где стартовые инвестиции в разработку могут быть обоснованно больше:
✔ Deep-tech проекты с AI, для которых важна R&D фаза
✔ Системы автоматизации на рынках, где уже есть другие игроки
✔ Проекты с подтвержденной unit-экономикой и спросом
Если ваш проект не попадает в категории выше, и для старта проекта вы планируете более $10.000 на разработку, напишите мне, мы запланируем созвон и поработаем над вашей стратегией запуска IT-продукта.
Отсутствие продуктовых этапов в разработке
❗ Ошибка № 2 по популярности – это отсутствие продуктовых этапов в разработке
Как правило, разработчики не очень понимают, что надо бизнесу, а бизнес не знает как требовать у разработчиков. В итоге получается как есть 🤷♂
Получив задачу «Разработать онлайн-магазин», среднестатистический разработчик приступит к ней в следующем порядке:
1. Сверстать дизайн
2. Разработать API
3. Интегрировать API с Эквайрингом
4. Интегрировать дизайн с API
5. Починить баги
6. Готово!
По времени каждый этап займет от 1 до 4 недель, то есть все 6 этапов могут занять от 6 до 20 недель. Все это время бизнес просто ждет готовности.
Время от времени кто-нибудь спохватывается: "А у нас вообще что-то готово? Я уже ничего не видел 4 недели!"
Разработчик отправляет представителю бизнеса Верстку и комментирует: "Вот, смотрите, весь дизайн уже готов. Осталось буквально 10%!" Бизнес смотрит на это и думает: "Да, действительно практически все готово. В бой, ребята!"
Но, заканчивается все одинаково.
Без преувеличения, за последние 3 года я получил более 10 одинаковых звонков-симптомов:"Джеймс, привет! Инвестировали $100 тыс. в приложение, видим что все практически готово. Надо зарелизиться, но в приложении в различных местах недоработки: там оплата немного некорректно работает, там авторизация. Разработчики уже 3-ий месяц обещают, что на этой неделе исправят, но не получается! Ты можешь помочь? Что делать?"
Я в этот момент улыбаюсь и сообщаю две новости:
✔ плохую: сколько еще потребуется денег на доработку
✔ хорошую: что они позвонили по правильному номеру
Кто знает, как такого не допустить? Напишите свой ответ в комментариях! А я предложу вам свое решение в следующем посте.
---
Больше в моем Telegram-канале: