Почему бриф сам по себе не спасает проект
Бриф хорошо собирает желания клиента, но плохо описывает реальную бизнес-логику. В нем почти всегда есть ожидания по дизайну, списки разделов и ссылки на референсы, но редко есть ответы на вопросы о качестве лида, процессе продаж, ограничениях CRM и цене ошибки. Если команда идет в дизайн только по брифу, она слишком рано начинает обсуждать форму решения вместо того, чтобы договориться о сути.
Именно поэтому discovery важен не как красивое название стартовой встречи, а как способ синхронизировать бизнес, маркетинг, продукт и разработку. Когда у всех появляется одна картина цели, следующая работа резко ускоряется: макеты согласуются быстрее, тексты становятся точнее, а разработка перестает строить лишний функционал.
Какие вопросы определяют архитектуру еще до прототипа
Первый вопрос всегда про деньги: где возникает выручка и какое действие считается главной конверсией. Для одних проектов это заявка и быстрый контакт менеджера, для других — самостоятельная покупка, для третьих — запись на консультацию. От ответа зависит буквально все: длина первого экрана, тип CTA, состав формы, логика контента и набор интеграций.
Второй вопрос — про качество обращения. Бизнесу часто нужны не любые лиды, а обращения с правильным контекстом: понятной задачей, релевантным бюджетом, нужным регионом или конкретной услугой. Это меняет подход к полям формы, структуре страницы и тому, как данные потом попадут в CRM.
- Что считается главной конверсией для бизнеса
- Какие данные менеджеру нужны до первого контакта
- Какие ограничения нельзя игнорировать в первом релизе
- Что обязательно автоматизируется уже на старте
Три рабочих артефакта после discovery
Первый артефакт — карта пользовательских сценариев. Она показывает, кто приходит на сайт, с каким контекстом, какие вопросы у человека возникают и в какой точке он должен совершить действие. Это не abstract CJM ради презентации, а каркас для дизайна, текста и структуры страницы.
Второй артефакт — контур MVP. В нем фиксируются функции, разделы, поля форм, обязательные интеграции и все, что точно должно войти в релиз. Третий артефакт — схема событий и лид-маршрута: какие данные фиксируются, что уходит в CRM, что дублируется в Telegram и по каким полям потом оценивается качество обращения.
Как не перепутать MVP с урезанным продуктом
MVP не означает «сделать поменьше». Он означает собрать минимальный, но цельный путь без разрывов. Если убрать второстепенную анимацию, редкие сценарии или дополнительные декоративные блоки — это нормально. Если убрать критичную интеграцию, важное поле квалификации лида или блок доверия, это уже не MVP, а продукт с заложенной проблемой.
Полезно оценивать функции по цене ошибки. Если неверное решение потом затронет архитектуру, аналитику и CRM, его лучше определить до разработки. Если гипотезу можно проверить без дорогой переделки, ее разумно вынести во вторую итерацию. Такой подход дает проекту темп, не жертвуя качеством.
Когда discovery можно считать завершенным
Discovery завершен не тогда, когда документ стал большим, а когда команда без догадок отвечает на прикладные вопросы: что именно входит в первый релиз, какая конверсия считается основной, что должно попасть в CRM, кто увидит лид первым и по каким метрикам оценивается запуск. Если ответы понятны и не противоречат друг другу, проект действительно готов к дизайну и продакшну.
В этом и состоит практическая ценность этапа. Сильный discovery не тормозит проект, а убирает дорогие откаты назад. Он делает так, чтобы каждая следующая итерация усиливала продукт, а не переписывала уже принятые решения.
