Как загубить свой проект. 10 антисоветов из реальных проектов.

Привет, меня зовут Валерьян. Я CEO компании ILAVISTA, и последние 9 лет мы занимаемся разработкой. Но последние 5 лет фокус сместился — те��ерь мы создаем продукты для бизнеса.

Эта статья больше о продуктовой разработке и меньше о корпоративных решениях и стартапах.

В нашем портфолио за последние 5 лет около 40 продуктов. Часть из них погибла, часть вот-вот закроется. Но есть проекты, которые растут, масштабируются и развиваются. Я задался вопросом: почему при всех прочих равных одни проекты запускаются, а другие не проходят свою собственную "долину смерти". В попытках поиска "волшебной таблетки" и пришел к диаметрально противоположному выводу: нет "волшебно таблетки" но есть точно "таблетки", которые точно не стоит принимать.

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

Давайте для начала посмотрим на два проекта.

Пример 1: Сеть наружной рекламы. Задача: не просто автоматизация, а создание экосистемы:

Пример 2: Маркетплейс фермерской продукции. Компания с собственными фермерскими полями, собственным импортом/экспортом и магазинами хотела:

Вопрос к читателям: Какой проект запустился, а какой — нет?

Оба проекта имели:

Ответ на раз, два, три.

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

Почему один провалился?

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

Одна команда, один стек технологий. Почему такая разница.

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

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

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

Все эти размышления привели меня к тому, что бы найти 10 ошибок, которые точно не приведут проект к "успешному успеху".

Давайте посмотрим на них.

Два одинаковых проекта. Одинаковая ниша - туризм. Проект FindGid (мы писали о нем на VC) - полностью доверился нам и в итоге за три года победил своих конкурентов. Заказчик разрешал нам двигаться маленькими шагами. Мы делали шаг, смотрели результат, формировали гипотезу, двигались дальше. Даже прийдя к выводу: гиды не будут нам платить, мы не расстроились, так как платформа умеет генерировать трафик, удобна для пользователей и готова к высоким нагрузкам. Мы просто переориентировались, забрали все экскурсии конкурентов по рефералке и льем им трафик и тестируем гипотезы дальше.

Второй проект - сервис такси + экскурсии на Байкале, долго разрабатывался, долго не выходил на рынок, ждал зимы на Байкале, большого потока туристов и ажиотаж на сервис. Но Байкал не замерз, проблемы с туризмом и большая и сложная гипотеза потеряла шанс на проверку. Но мы, как команда, настаивали не делать идеал, а запустить MVP и его развивать. Приглашать водителей в сырую версию проекта и получать от них обратную связь. В итоге к этому сезону уже был бы хоть какой-то продукт, который быстро можно было бы быстро адаптировать под новые условия.

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

Два проекта в сфере недвижимости, разные рынки, одна команда, одинаковый бюджет, одинаковые сроки. Первый проект - платформа посуточной аренды. Заказчик захотел создать конкурента топовым игрокам. при этом никакой исследования не проводилось. Разработка на уровне ощущений и желаний заказчика. В итоге, когда пришла пора подключать объекты, никто не мог объяснить собственникам, зачем им очередная платформа, как соединить календарь аренды и вообще зачем им тратить на это время.

Второй проект также зашел с задачей создания платформы под недвижимость на одном из рынков СНГ. Но было проведено UX исследование рынка, на основании которого сформированная гипотеза - чего именно не хватает, как отстроиться от конкурентов, как позиционироваться и монетизировать продукт. В итоге - качественная разработка, быстрый запуск за 2 месяца. Сейчас проект находиться на стадии наполнения и формирования новой гипотезы на основе обратной связи от пользователей.

Вывод: Сформировали идею или гипотезу - не спешите ее делать. Сделайте UX исследование или хотя бы конкурентный анализ. Поймите свой продукт, поймите своих пользователей. Изучите рынок, изучите все, к чему привыкли пользователи, изучите что не удобно и что плохо и не повторяйте у себя. Изучите, что круто сделано и заберите это себе.

Подробнее про UX исследования я писал в прошлой статье.

Даже сложно вспомнить, сколько раз к нам приходили с запросом разработки нового Tindera, Ozoon, Avito или любого другого продукта.

"Зачем проводить исследование, если можно взять и скопировать лидера рынка" - говорят мне. Я всегда открываю сайт этого лидера, которого мы собрались копировать и прошу заказчика посчитать продуктовые истории просто на главном экране. Вот к примеру сайт:

Здесь не на главном экране около 40 продуктовых кейсов. Я уже молчу о 10-15 годах разработки, накопленных данных, лояльных пользователях и миллионах долларов на разработку и поддержку.

Или, к примеру, Tinder.

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

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

Первый продукт - платформа спортивных новостей и матч-центр. Заказчик пришел с задачей скопировать что-то похожее на sports.ru. Контентная часть, монетизация и рекламный блок были готовы за 2-3 месяца. На истории с матч-центром был тотальный стоп.

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

Второй же продукт - платформа о финансовых продуктах в Узбекистане определили своего идеального конкурента, определили MVP для запуска, сформировали гипотезу на монетизацию MVP и пошли в разработку именно с этим. В итоге спустя 4 месяца - 300 000 уникальных пользователей в нишевом продукте.

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

Жесткий, но факт: допустив ошибки 1, 2 и 3, вы гарантированно:

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

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

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

Результат очевиден: пока первая команда бьётся над «идеалом», вторая уже давно работает, развивается и приносит пользу.

Вывод: лучше грубый, но работающий продукт сегодня, чем идеальный — никогда. Всегда делайте MVP, даже если вам кажется это лишним.

Эта ошибка похожа на пункт 4. Но немного не про это. Даже если мы уговорили заказчика делать MVP - он старается расширить его максимально.

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

Разберем два подхода к MVP на примере консалтинговых продуктов.

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

Как не надо делать: Включать в первую версию все возможные сценарии• Усложнять продукт до выхода на рынок• Игнорировать фактор времени в конкурентной среде

Второй проект стартовал с предельно простого MVP за 2 месяца. Постепенно, основываясь на обратной связи, мы добавляли функционал. Когда наступил кризис, компания легко адаптировала продукт для глобальной аудитории, сохранив клиентов.

Правильный подход к MVP:• Запускать только ключевой функционал• Наращивать сложность поэтапно• Быть готовым к оперативным изменениям

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

Нам надо идеальный продукт - это путь к тому, что продукт не будет вообще, а не то, чтобы идеальным.

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

Первый проект мы уже упоминали - аналог vc.ru, только в тематике релокации. Он стремился к идеальному продукту, который будет нравится всем и закрывать потребности мигрантов, авторов контента, некоммерческих организаций и коммерческих организаций. К сожалению это привело к тому, что продукт стал идеальным, но супер сложным. И любые изменения требуют того, чтобы сохранить эту идеальность, а это требует пару тысяч долларов на самые мелкие изменения.

Второй проект toping.uz (контентная платформа для Узбекистана) - не старался быть идеальным на первом запуске. За то он и не боялся потерять свою "идеальность" в процессе тестирования гипотез, которые были быстрые и дешевые. Это позволило команде быстро и смело тестировать продукт и искать "идеальность" уже в процессе.

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

Главное, что вы должны всегда держать в голове: вы - не ваши пользователи. Все что думаете вы может не иметь никакого отношения к вашим пользователям. Об этом написано много материала, в том числе примеры из разработки платформы для найма водителей в Европе и food Tech можно почитать в прошлом материале.

Главная мысль: вы ≠ ваши пользователи. В foodtech-кейсе мы избежали провала, проверив через AI и исследования, что рынок Германии перенасыщен (80-120 конкурентов!), и нашли узкую нишу — интеграцию подсчета калорий с заказом из привычных магазинов. В логистическом стартапе заказчик-эксперт предложил 400+ экранов, но тесты с водителями показали, что 30% функций бесполезны. Вывод: даже с блестящей гипотезой MVP должен быть минимальным — только так вы проверите реальные потребности, а не свои иллюзии. Без ранних тестов с пользователями вы строите продукт вслепую.

Вывод: даже самые убедительные гипотезы о продукте нужно проверять на реальных пользователях — ваше видение почти всегда отличается от их потребностей. Foodtech-кейс показал, как анализ рынка спасает от провала в перенасыщенной нише, а логистический проект доказал: 30% "нужных" функций оказались бесполезными после тестов с водителями. Правило простое — запускайте максимально простое MVP, тестируйте каждое предположение, и только потом масштабируйте. Иначе рискуете потратить время и ресурсы на продукт, который никому не нужен.

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

Кейс 1 - платформа таможенной сертификации. Команда создала мощный IT-продукт для сертификации и декларирования, но не продумала, как его продавать. Оказалось, что для первых продаж нужна совсем другая функциональность — пришлось переделывать половину системы.

Кейс 2 - Reportix: Сервис для налоговой отчетности в Казахстане сразу заложил гипотезу первых продаж — сделал упор на автоматизацию рутинных операций бухгалтеров. Это позволило быстро выйти на paying customers.

Вывод: Продумывайте путь первых продаж ДО разработки. Первые клиенты должны получить ценность мгновенно — иначе продукт будет не готов к рынку.

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

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

Кейс 2 - сервис для Danone. Изначально делали автоматизацию закупок для Danone, но заложили гибкую архитектуру. Когда компания ушла с рынка РБ и РФ, легко адаптировали продукт под других производителей. Подробнее писали об этом кейсе раньше.

Вывод: избегайте «заточенности» под одного клиента без контракта. Закладывайте модульность и масштабируемость с первого дня. Идеальный баланс: пилотируйте с одним игроком, но проектируйте для многих.

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

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

Хороший пример: B2B-лидер уходит в B2CКомпания, доминирующая в B2B-сегменте, решила выйти на B2C-рынок. Благодаря детальному конкурентному анализу они:

Вывод:

Без конкурентного анализа вы строите продукт вслепую. С ним — создаете осознанное преимущество.

Если бы я попробовал бы сформулировать мысль о том, как делать все правильно, я бы предложил следующие этапы, которые мы используем в своей компании при разработке продуктов:

Формируете гипотезу.

Проводите исследование:

Создаёте первую версию продукта.

Тестируете гипотезу на пользователях.

Не делаете ничего, пока не найдёте гипотезу, за которую платят.

После монетизации — дорабатываете на основе обратной связи.

И что хочется добавить еще. О чем важно помнить при разработке продукта и формирования MVP.

Не бойтесь запускать «неидеальное». Лучше кривой кувшин в руках, чем идеальный — в мечтах.