Мы запустили MVP за 4 недели — и на первой неделе поняли, что главная фича никому не нужна
Этот проект мы могли сделать «как обычно».Подписать договор, зафиксировать объём, спокойно разрабатывать 3-4 месяца и уже на приёмке узнать, что что-то пошло не так.
Вместо этого мы запустили MVP за 4 недели.А на 7-й день после запуска стало ясно: фича, ради которой проект вообще начинался, пользователям не нужна.
И это сэкономило клиенту около 2 млн рублей.
Контекст: что это был за продукт
Клиент - B2B-компания. Продукт - внутренний сервис для сотрудников, который должен был сократить ручную работу и упростить принятие решений.
Целевая аудитория - менеджеры среднего звена. Запрос выглядел логично: «Если дать им удобный инструмент с аналитикой, они будут пользоваться им каждый день».
На старте все были уверены, что ключевая ценность продукта - одна конкретная функция. Назовём её «умный аналитический модуль».
Главная фича, на которую делали ставку
Этот модуль:
- собирал данные из разных источников,
- автоматически строил отчёты,
- показывал дашборды.
Если делать «по классике», то:
- срок разработки
- 3–4 месяца,- бюджет
- 3-3,5 млн ₽,
- эта фича занимала бы около 60% всего проекта.
Именно её клиент считал сердцем продукта.
Где мы могли повторить старые ошибки?
Раньше в таких проектах мы действовали иначе.
Фиксировали эту фичу в договоре. Подробно описывали в ТЗ. Закладывали как обязательную часть проекта.
А потом, уже после релиза, выясняли, что:
- пользователи ведут себя иначе,
- ценность оказалась не там, а менять что-то поздно
- всё уже зафиксировано.
Мы уже проходили этот путь. И платили за него деньгами.
Что решили сделать по-другому?
В этот раз мы договорились с клиентом на другой подход - осознанно ещё до договора.
- Запускаем MVP за 4 недели.
- В договоре фиксируем не фичу, а гипотезу:«Пользователи будут регулярно использовать этот сценарий».
- Объём MVP ограничен заранее:- без сложной автоматизации,- без интеграций,- без «идеальной архитектуры».
- Цель MVP - не понравиться, а понять, будут ли этим вообще пользоваться.
Бюджет MVP - ≈900 тыс. ₽.
Запуск и первая неделя
Через месяц MVP был запущен.
Доступ получили 40 пользователей. За первую неделю:
- 28 зашли в продукт,
- 6 попробовали «главную фичу»,
- 1 использовал её больше одного раза.
Среднее время использования - меньше 2 минут.
При этом пользователи:
- искали другие сценарии,
- обходили аналитический модуль стороной,
- писали в поддержку с совсем другими вопросами.
Стало очевидно: та фича, которую мы считали ключевой, не решает их реальную задачу.
Момент осознания
В этот момент стало особенно ясно одно.
Если бы эта фича была жёстко зафиксирована в договоре, мы бы сейчас:
- продолжали её дорабатывать,
- убеждали себя, что «пользователи просто не привыкли»,
- и сжигали бюджет на масштабирование ошибки.Но MVP дал возможность остановиться - без конфликтов и штрафов.
Что было бы без MVP
Если считать грубо:
- ещё 2–2,5 млн ₽ ушло бы на разработку,
- +3 месяца сроков,
- жёсткие обязательства по договору,
- давление «доделать, раз уже начали».
MVP не сделал проект успешным автоматически.Он сделал другое - не дал ошибке стать дорогой.
Что сделали дальше?
Мы перераспределили бюджет. Усилили сценарии, которые пользователи реально использовали. Полностью пересобрали приоритеты.
Продукт пошёл в другую сторону - и именно оттуда начал расти.
Главный вывод
Мы сэкономили деньги не потому, что угадали с первого раза.
А потому что не зафиксировали гипотезу как истину слишком рано.
Именно здесь сходятся:
- продуктовый подход,
- MVP,
- договор,
- и реальные деньги бизнеса.
Короткий и практичный чек-лист из этого кейса
Если совсем по делу:
- В договоре фиксируйте цель и гипотезу, а не конкретную фичу.
- Объём MVP - это объём проверки, а не готового продукта.
- Заранее пропишите, что по итогам MVP решения могут быть пересмотрены.
- Право отказаться - это не слабость, а защита бюджета.
Иногда лучший результат проекта - это вовремя понять, что делать не нужно.