Как загубить свой проект. 10 антисоветов из реальных проектов.
Привет, меня зовут Валерьян. Я CEO компании ILAVISTA, и последние 9 лет мы занимаемся разработкой. Но последние 5 лет фокус сместился — теперь мы создаем продукты для бизнеса.
Эта статья больше о продуктовой разработке и меньше о корпоративных решениях и стартапах.
- Корпоративные решения — больше про маркетинг и упаковку.
- Стартапы — здесь всё про скорость, гипотезы и «сделать на коленке». Главное — быстро проверить идею и привлечь инвесторов.
- Аутсорс-продукты — когда мы создаём решение на основе чужой экспертизы или адаптируем успешный продукт под новый рынок.
В нашем портфолио за последние 5 лет около 40 продуктов. Часть из них погибла, часть вот-вот закроется. Но есть проекты, которые растут, масштабируются и развиваются. Я задался вопросом: почему при всех прочих равных одни проекты запускаются, а другие не проходят свою собственную "долину смерти". В попытках поиска "волшебной таблетки" и пришел к диаметрально противоположному выводу: нет "волшебно таблетки" но есть точно "таблетки", которые точно не стоит принимать.
Так родилась идея описать 10 проектов, в которых была совершена ошибка, которая не позволила проекту дойти до заветной монетизации, самоокупаемости, прибыли, росту, масштабированию.
Если перефразировать классика: каждый успешный проект - успешен одинаково, каждый неуспешный - неуспешный по своему.
Давайте для начала посмотрим на два проекта.
Пример 1: Сеть наружной рекламы. Задача: не просто автоматизация, а создание экосистемы:
- Агентский доступ к кабинетам.
- Подключение владельцев билбордов.
- Самостоятельное формирование рекламных сеток пользователями.
- Программатик для аукционов.
- Аналитика для всего рынка.
Пример 2: Маркетплейс фермерской продукции. Компания с собственными фермерскими полями, собственным импортом/экспортом и магазинами хотела:
- Продавать свою продукцию.
- Анализировать спрос для развития ферм.
- Привлекать других производителей.
- Выходить на оптовые закупки и экспорт.
- Развивать B2B-направление для фермеров.
Вопрос к читателям: Какой проект запустился, а какой — нет?
Оба проекта имели:
- Одну команду разработки.
- Примерно одинаковый бюджет и сроки.
- Оба строились на базе экспертизы компании.
Ответ на раз, два, три.
Проект фермерской продукции так и незапустился на рынок, а система управления наружной рекламой успешно реализован и развивается дальше.
Почему один провалился?
- Успешный проект делал маленькие шаги, быстро давал результат (даже кривой, но полезный). В кризис он помогал зарабатывать.
- Провальный проект гнался за идеалом, требовал огромных вложений и не приносил деньги. Когда деньги кончились — мотивация исчезла, а продукт был не готов.
Ну ладно, это проекты из разных индустрий. Давайте возьмем одинаковые проекты из одной ниши.
Одна команда, один стек технологий. Почему такая разница.
На мой взгляд, чем проще проект со старта, чем меньше MVP - тем проще привлекать пользователей и тестировать гипотезы.
Золотое правило стартапов, которое давайте перетащим к продуктам: чем больше лайнер - тем сложнее его поворачивать. Проект 1 стал тем самым лайнером. Очень большим и сложным. Любая гипотеза - безумно дорогая для теста с точки зрения разработки, рассказать новым пользователям о проекте - сложно, так как надо долго перечислять преимущества и возможности.
Но об этом проекте я думаю мы напишем отдельный кейс с собственником продукта. Он реально крутой и, на мой взгляд, мощнее даже VC.
Второй проект действовал минимальными шагами. Сделали супер базовое MVP. Сформировали первую простую гипотезу. Достигли ее. Из этой точки начали строить следующую гипотезу. Так как проект простой и легкий, то любые гипотезы проверяются быстро и относительно дешево, что позволяет команде искать точки монетизации быстро и гибко. Результат в цифрах.
В книге «Стрессоустойчивость» описан эксперимент: Первая группа должна была сделать один идеальный кувшин — долго готовились, боялись ошибиться, в итоге многие не закончили. Вторая группа получила задание сделать 100 кувшинов — лепили быстро, не зацикливались на ошибках, и в результате их работы стали качественнее уже к 30-й попытке.
Все эти размышления привели меня к тому, что бы найти 10 ошибок, которые точно не приведут проект к "успешному успеху".
Давайте посмотрим на них.
Ошибка 1. Не слушать команду разработки.
Два одинаковых проекта. Одинаковая ниша - туризм. Проект FindGid (мы писали о нем на VC) - полностью доверился нам и в итоге за три года победил своих конкурентов. Заказчик разрешал нам двигаться маленькими шагами. Мы делали шаг, смотрели результат, формировали гипотезу, двигались дальше. Даже прийдя к выводу: гиды не будут нам платить, мы не расстроились, так как платформа умеет генерировать трафик, удобна для пользователей и готова к высоким нагрузкам. Мы просто переориентировались, забрали все экскурсии конкурентов по рефералке и льем им трафик и тестируем гипотезы дальше.
Второй проект - сервис такси + экскурсии на Байкале, долго разрабатывался, долго не выходил на рынок, ждал зимы на Байкале, большого потока туристов и ажиотаж на сервис. Но Байкал не замерз, проблемы с туризмом и большая и сложная гипотеза потеряла шанс на проверку. Но мы, как команда, настаивали не делать идеал, а запустить MVP и его развивать. Приглашать водителей в сырую версию проекта и получать от них обратную связь. В итоге к этому сезону уже был бы хоть какой-то продукт, который быстро можно было бы быстро адаптировать под новые условия.
У проекта есть еще шанс и мы постараемся создать супер-крутой сервис для туризма на Байкале.
Вывод: выбирайте очень тщательно команду, смотрите их кейсы, обсуждайте риски, слушайте их подход к продукту. И когда выбрали - доверьте им полностью проект. Полная свобода и полная ответственность за результат - вот идеальная формула взаимодействия.
Ошибка 2. Отсутствие UX исследования или конкурентного анализа.
Два проекта в сфере недвижимости, разные рынки, одна команда, одинаковый бюджет, одинаковые сроки. Первый проект - платформа посуточной аренды. Заказчик захотел создать конкурента топовым игрокам. при этом никакой исследования не проводилось. Разработка на уровне ощущений и желаний заказчика. В итоге, когда пришла пора подключать объекты, никто не мог объяснить собственникам, зачем им очередная платформа, как соединить календарь аренды и вообще зачем им тратить на это время.
Второй проект также зашел с задачей создания платформы под недвижимость на одном из рынков СНГ. Но было проведено UX исследование рынка, на основании которого сформированная гипотеза - чего именно не хватает, как отстроиться от конкурентов, как позиционироваться и монетизировать продукт. В итоге - качественная разработка, быстрый запуск за 2 месяца. Сейчас проект находиться на стадии наполнения и формирования новой гипотезы на основе обратной связи от пользователей.
Вывод: Сформировали идею или гипотезу - не спешите ее делать. Сделайте UX исследование или хотя бы конкурентный анализ. Поймите свой продукт, поймите своих пользователей. Изучите рынок, изучите все, к чему привыкли пользователи, изучите что не удобно и что плохо и не повторяйте у себя. Изучите, что круто сделано и заберите это себе.
Подробнее про UX исследования я писал в прошлой статье.
Ошибка 3. Ориентироваться на готовые продукты.
Даже сложно вспомнить, сколько раз к нам приходили с запросом разработки нового Tindera, Ozoon, Avito или любого другого продукта.
"Зачем проводить исследование, если можно взять и скопировать лидера рынка" - говорят мне. Я всегда открываю сайт этого лидера, которого мы собрались копировать и прошу заказчика посчитать продуктовые истории просто на главном экране. Вот к примеру сайт:
Здесь не на главном экране около 40 продуктовых кейсов. Я уже молчу о 10-15 годах разработки, накопленных данных, лояльных пользователях и миллионах долларов на разработку и поддержку.
Или, к примеру, Tinder.
Все думают, что этот сервис про регистрацию пользователей и свайп влево, вправо. Но никто не задумывается, сколько ресурсов спрятано на модерацию, защиту пользователей и всего того, что может похоронить продукт.
Для этого примера я хочу рассмотреть два контентных проекта, которые мы делали. Оба должны были скопировать на другие рынки крутые продукты.
Первый продукт - платформа спортивных новостей и матч-центр. Заказчик пришел с задачей скопировать что-то похожее на sports.ru. Контентная часть, монетизация и рекламный блок были готовы за 2-3 месяца. На истории с матч-центром был тотальный стоп.
В попытке ориентироваться на гигантов и мысль о том, что они уже все придумали, давайте скопируем, привели к тому, что исследование и конкурентный анализ были пропущены. А в процессе оказалось, что реализовать логику матч-центров и все, что строилось вокруг него нереально сделать в бюджете заказчика.
Мы могли бы пойти по пути минимально жизнеспособного продукта - запустить сначала простую контент-платформу с монетизацией, а сложный матч-центр добавлять постепенно, по мере поступления средств. Но вместо этого все ресурсы были потрачены на попытку сразу создать "идеальное" решение, которое так и не увидело свет.
Второй же продукт - платформа о финансовых продуктах в Узбекистане определили своего идеального конкурента, определили MVP для запуска, сформировали гипотезу на монетизацию MVP и пошли в разработку именно с этим. В итоге спустя 4 месяца - 300 000 уникальных пользователей в нишевом продукте.
Вывод: ориентироваться на готовые продукты хорошо. Но нельзя их копировать, так как у вас нет их 10 лет опыта и бюджета. Можно смотреть на больших игроков и копировать их модель. Но делать это надо так, что бы маленькими шагами идти к своим гипотезам монетизации.
Ошибка 4. Игнорировать MVP.
Жесткий, но факт: допустив ошибки 1, 2 и 3, вы гарантированно:
- проигнорируете принципы MVP,
- будете гнаться за "идеалом",
- потребуете от команды невозможного - создать с первого раза продукт, который мгновенно покорит рынок и принесет миллионы.
И знаете что? Такой продукт никогда не выйдет в продакшн. Потому что перфекционизм - это профессиональная болезнь, которая убивает проекты еще до их запуска.
Для примера я взял два проекта - система управления федерацией и бизнес-портал. Кажется, проекты из разных сфер. Но что здесь интересно.
Две противоположные стратегии — два разных исхода. Первый проект задумывался как сложная, многофункциональная система с идеальной архитектурой. Спустя несколько лет разработки он так и не вышел в продакшен, продолжая бесконечно дорабатываться. Второй — простой контентный портал, который стартовал с минимального MVP на WordPress, быстро протестировал гипотезы, а затем переехал на Laravel для масштабирования.
Результат очевиден: пока первая команда бьётся над «идеалом», вторая уже давно работает, развивается и приносит пользу.
Вывод: лучше грубый, но работающий продукт сегодня, чем идеальный — никогда. Всегда делайте MVP, даже если вам кажется это лишним.
Ошибка 5. Брать слишком большой объём.
Эта ошибка похожа на пункт 4. Но немного не про это. Даже если мы уговорили заказчика делать MVP - он старается расширить его максимально.
Суть MVP в том, что это минимальный жизнеспособный продукт. "Минимальный" - очень часто игнорируется в этой фразе.
Разберем два подхода к MVP на примере консалтинговых продуктов.
Первый проект заложил в MVP полный цикл пользовательских историй, включая сложный механизм контроля движения денег через платформу. Пока шла долгая разработка, изменилась рыночная ситуация — и проект упустил шанс выйти на международный уровень. Будь MVP минимальным (без сложных денежных транзакций), продукт вышел бы на полгода раньше, успел бы набрать аудиторию и легче пережил бы кризис, оперативно адаптировав сервис под новые реалии.
Как не надо делать: Включать в первую версию все возможные сценарии• Усложнять продукт до выхода на рынок• Игнорировать фактор времени в конкурентной среде
Второй проект стартовал с предельно простого MVP за 2 месяца. Постепенно, основываясь на обратной связи, мы добавляли функционал. Когда наступил кризис, компания легко адаптировала продукт для глобальной аудитории, сохранив клиентов.
Правильный подход к MVP:• Запускать только ключевой функционал• Наращивать сложность поэтапно• Быть готовым к оперативным изменениям
Вывод: минимальный MVP — это не урезание возможностей, а страховка от рыночных рисков. Чем проще первая версия, тем быстрее вы поймете, куда двигаться дальше.
Ошибка 6. Гнаться за идеалом.
Нам надо идеальный продукт - это путь к тому, что продукт не будет вообще, а не то, чтобы идеальным.
Все идеалы только у нас в голове. Что идеально для пользователя - мы не знаем. Да пользователь и не идет за идеалом. Пользователь идет за решением своей потребности или закрытие своей боли.
Первый проект мы уже упоминали - аналог vc.ru, только в тематике релокации. Он стремился к идеальному продукту, который будет нравится всем и закрывать потребности мигрантов, авторов контента, некоммерческих организаций и коммерческих организаций. К сожалению это привело к тому, что продукт стал идеальным, но супер сложным. И любые изменения требуют того, чтобы сохранить эту идеальность, а это требует пару тысяч долларов на самые мелкие изменения.
Второй проект toping.uz (контентная платформа для Узбекистана) - не старался быть идеальным на первом запуске. За то он и не боялся потерять свою "идеальность" в процессе тестирования гипотез, которые были быстрые и дешевые. Это позволило команде быстро и смело тестировать продукт и искать "идеальность" уже в процессе.
Вывод: Улучшать продукт на основе обратной связи. К идеалу надо прийти в процессе, а не придумывать его со старта.
Ошибка 7. Думать за пользователя.
Главное, что вы должны всегда держать в голове: вы - не ваши пользователи. Все что думаете вы может не иметь никакого отношения к вашим пользователям. Об этом написано много материала, в том числе примеры из разработки платформы для найма водителей в Европе и food Tech можно почитать в прошлом материале.
Главная мысль: вы ≠ ваши пользователи. В foodtech-кейсе мы избежали провала, проверив через AI и исследования, что рынок Германии перенасыщен (80-120 конкурентов!), и нашли узкую нишу — интеграцию подсчета калорий с заказом из привычных магазинов. В логистическом стартапе заказчик-эксперт предложил 400+ экранов, но тесты с водителями показали, что 30% функций бесполезны. Вывод: даже с блестящей гипотезой MVP должен быть минимальным — только так вы проверите реальные потребности, а не свои иллюзии. Без ранних тестов с пользователями вы строите продукт вслепую.
Вывод: даже самые убедительные гипотезы о продукте нужно проверять на реальных пользователях — ваше видение почти всегда отличается от их потребностей. Foodtech-кейс показал, как анализ рынка спасает от провала в перенасыщенной нише, а логистический проект доказал: 30% "нужных" функций оказались бесполезными после тестов с водителями. Правило простое — запускайте максимально простое MVP, тестируйте каждое предположение, и только потом масштабируйте. Иначе рискуете потратить время и ресурсы на продукт, который никому не нужен.
Ошибка 8. Нет гипотезы на первые продажи
Частая ошибка стартапов — сосредоточиться на идеальном продукте, забыв о том, как его будут покупать. Без четкого плана первых продаж даже лучший продукт рискует остаться без клиентов.
Кейс 1 - платформа таможенной сертификации. Команда создала мощный IT-продукт для сертификации и декларирования, но не продумала, как его продавать. Оказалось, что для первых продаж нужна совсем другая функциональность — пришлось переделывать половину системы.
Кейс 2 - Reportix: Сервис для налоговой отчетности в Казахстане сразу заложил гипотезу первых продаж — сделал упор на автоматизацию рутинных операций бухгалтеров. Это позволило быстро выйти на paying customers.
Вывод: Продумывайте путь первых продаж ДО разработки. Первые клиенты должны получить ценность мгновенно — иначе продукт будет не готов к рынку.
Ошибка 9. Продукт под одного игрока
Создавая решение исключительно под нужды одного клиента без страховочных вариантов, вы ставите весь проект под угрозу. Если клиент уйдет — продукт умрет вместе с ним.
Кейс 1 - платформа для криптоинфлюенсеров. Разрабатывали кастомизированное решение под конкретного игрока без юридических гарантий. Когда сотрудничество внезапно прекратилось, продукт оказался никому не нужен — слишком специфичный функционал.
Кейс 2 - сервис для Danone. Изначально делали автоматизацию закупок для Danone, но заложили гибкую архитектуру. Когда компания ушла с рынка РБ и РФ, легко адаптировали продукт под других производителей. Подробнее писали об этом кейсе раньше.
Вывод: избегайте «заточенности» под одного клиента без контракта. Закладывайте модульность и масштабируемость с первого дня. Идеальный баланс: пилотируйте с одним игроком, но проектируйте для многих.
Ошибка 10. Без конкурентного анализа
Игнорирование существующих игроков на рынке — прямой путь к созданию слабого или неконкурентоспособного продукта. Без понимания, к чему уже привыкли пользователи и какой уровень сервиса предлагают конкуренты, вы рискуете потратить ресурсы впустую.
Плохой пример: сервис Upsales - стартап по повышению конверсии сайтов запустился без глубокого анализа конкурентов. После долгого развития команда осознала, что существующие решения предлагают намного более продвинутый функционал и качество. Попытка конкурировать только ценой провалилась — пользователи уже привыкли к высокому уровню сервиса.
Хороший пример: B2B-лидер уходит в B2CКомпания, доминирующая в B2B-сегменте, решила выйти на B2C-рынок. Благодаря детальному конкурентному анализу они:
- Выявили слабые места конкурентов (например, сложный интерфейс или долгая поддержка).
- Усилили свой продукт там, где другие проигрывали.
- Сразу предложили пользователям более удобное и качественное решение.
Вывод:
- Изучайте конкурентов до старта — это поможет понять «планку» и избежать фатальных ошибок.
- Копировать — плохо, но учиться — необходимо. Найдите gaps (пробелы) конкурентов и закройте их.
- Цена — не главное. Если ваш продукт слабее, даже низкая стоимость не спасет. Пользователи выбирают удобство и качество.
Без конкурентного анализа вы строите продукт вслепую. С ним — создаете осознанное преимущество.
Единственная волшебная таблетка, которую я признаю.
Если бы я попробовал бы сформулировать мысль о том, как делать все правильно, я бы предложил следующие этапы, которые мы используем в своей компании при разработке продуктов:
Формируете гипотезу.
Проводите исследование:
- Для кого делаете?
- Какая у них боль?
- Как они решают её сейчас?
- Кто конкуренты?
- Что у них хорошо/плохо?
Создаёте первую версию продукта.
Тестируете гипотезу на пользователях.
Не делаете ничего, пока не найдёте гипотезу, за которую платят.
После монетизации — дорабатываете на основе обратной связи.
И что хочется добавить еще. О чем важно помнить при разработке продукта и формирования MVP.
Выводы.
Не бойтесь запускать «неидеальное». Лучше кривой кувшин в руках, чем идеальный — в мечтах.