Почему это красный флаг для продукта.

Каждый второй enterprise-клиент приходит с фразой:

«Мы всё продумали. Вот ТЗ, вот Figma. Осталось только реализовать».

Звучит как мечта: чёткие требования, готовый дизайн, понятный scope.  На деле — одна из самых рискованных ситуаций в продуктовой работе.

Почему?

❌Три скрытые проблемы «готового решения»

1. Решение без проблемы  Клиент описывает как, но не говорит зачем.  Пример (реальный): 1. Открываю тз, а там есть кнопка перевода сайта в мобильную версию. Такое примеры "из ряда вон" конечно происходят редко, но происходят. Больше технички как следующий пример. 2. Листинг сначала разделяется по разделам каталога, а потом по кнопке должен выгружать ВЕСЬ каталог в 1 контейнер без обновления ссылки естественно. И приходится тратить кучу времени на такие поиски кота в мешке на десятках страниц документов и макетов в фигме. Самому строить bpmn и просматривать фигму. 🧹Короче BDSM (Business Development, Sales and Marketing)

Вопрос: Какая метрика улучшится? Какая боль исчезнет?  Часто ответа нет. Это значит — фича решает воображаемую, а не реальную проблему.

Результат: после запуска пользователи обходят интерфейс, используют обходные пути или вообще не заходят.

2. Ответственность переложена на вас  Клиент говорит: «Вы же эксперты — сделайте, чтобы работало».  Но если решение не сработает — виноваты вы, а не его внутренняя команда, которая месяц рисовала макеты в отрыве от реальности. Но нужно сказать, что у меня пока не было ситуации, когда не получалось договорится. Да через переговоры по 2-3 часа, но получалось же. Вопрос только в том, что на пересчет затраченного времени получалось окупить такую историю вот на столько👌

🔍 Как оценивать такие запросы? 4 вопроса-фильтра

Не отклоняйте сразу. Но не принимайте на веру. Задайте:

1. «Как вы измерите успех этой фичи?»     → Если ответ: «Пользователи скажут “спасибо”» — тревожный звоночек.     → Идеально: «Сократим время на формирование отчёта с 45 до 15 минут».

2. «Кто конкретно будет это использовать? Покажите реальный кейс»     → Попросите запись сессии, скриншот текущего процесса, цитату от пользователя.     → Если говорят «все HR» — уточните: оператор, аналитик или директор?

3. «Что будет, если мы НЕ сделаем это?»     → Помогает отделить «желаемое» от «критичного».     → Часто выясняется: «Ну… ничего страшного».

4. «Можно ли проверить гипотезу дешевле и быстрее?»     → Предложите прототип, concierge-тест, ручной workflow.     → Пример: вместо разработки экспорта — дайте клиенту Google Sheets с формулами.     → Если им не пользуются — зачем кодить?

💡 Что делать дальше?

• Не отказывайтесь от ТЗ — переформулируйте его в гипотезу.    Вместо: «Сделать экспорт в Excel» →    «Если добавить экспорт в Excel, то HR-операторы сократят время на отчётность на 30%».

• Требуйте доступ к данным и пользователям.    Без этого вы строите продукт по слухам.

• Договоритесь о метриках успеха ДО старта.    И зафиксируйте их в договоре или SOW. Это защитит вас и направит команду.

• Готовьтесь к компромиссу.    Иногда клиенту важно видеть «свой» интерфейс — даже если он не оптимален.    Ваша задача — сохранить ядро ценности, а не бороться за каждый пиксель.

📄Главное

Готовое ТЗ и дизайн — не признак зрелости клиента.  Часто это попытка избежать неопределённости.

Ваша роль — не исполнитель, а партнёр по созданию ценности.  Даже если клиент думает, что «всё уже решено».